Graylog CEF inputs for firewall and security logs

How Graylog CEF inputs receive firewall and security appliance logs

Security teams need firewall, proxy and security tool logs to reach Graylog without gaps, and many of these appliances emit Common Event Format (CEF) messages. Graylog provides four CEF input transports: CEF TCP, CEF UDP, CEF AMQP and CEF Kafka. TCP and UDP are the direct network paths from the appliance, while AMQP and Kafka suit designs where a broker sits between the appliances and Graylog and absorbs bursts. The choice comes down to what your appliances can send, whether a broker already exists in your environment, and how much loss you can accept if a listener restarts. Confirm with each vendor which transports and CEF versions its appliance supports, because the input can only parse what arrives.

Graylog documents that CEF inputs support TLS on TCP only. UDP has no encryption in this input, so any firewall log that carries user names, internal addresses or policy detail across a network you do not fully control should travel over TCP with TLS, or through a broker secured on its own terms. Plan the certificate lifecycle at the same time as the listener, including who renews the certificate, where the private key is stored and how the appliance is configured to trust the Graylog node. Verify the TLS path with a test event before you rely on it, and confirm the current input options in the Graylog CEF inputs documentation.

Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so legal and procurement teams should review it before standardizing on Graylog. The license question does not change how the CEF inputs behave, but it does affect how you describe the platform in policy documents and vendor reviews. The input behavior described here follows Graylog's own documentation for the version you deploy, and your team should confirm each option against that version's docs before going to production.

What you need before creating a CEF input

A CEF input only works when the Graylog platform, the network path and the appliance export settings agree. Work through these cards before you create the input, so a missing port rule or certificate does not surface later as silent log loss.

Graylog version and platform

Confirm the Graylog release you run and read the matching documentation, since the current docs cover version 7.2. Graylog runs as server nodes with MongoDB for configuration and a search backend, either Graylog Data Node or self-managed OpenSearch. Check the compatibility matrix for your exact MongoDB and OpenSearch versions, and note that OpenSearch 1.x use is deprecated since Graylog 7.0. A supported pairing comes first, because input settings are the easy part.

Running server nodes and storage

Make sure at least one Graylog server node is healthy, with MongoDB reachable and a search backend that accepts writes. Size storage from your expected daily ingest, using the documented guidance of daily ingest multiplied by retention days and by 120 percent. Confirm that the message journal has enough SSD space, since the architecture guidance suggests 3 to 5 times daily ingest. A firewall vendor's log volume can grow quickly after a policy change, so ask the appliance team for their peak estimate.

Network paths from each appliance

Map every appliance, proxy and security tool that will send CEF to the Graylog input node or load balancer, including its source address and the transport it uses. Confirm the input port you plan to bind, and make sure no other service already uses it. Routing through NAT, a log collector or a load balancer can change the source address that Graylog sees, which affects any allow lists downstream.

Firewall rules for the input port

Open the chosen port from each sending appliance to the Graylog input node in the direction the transport requires. For TCP, the appliance initiates the connection, so the host firewall and any network firewall between them must allow that session. For UDP, confirm that the appliance sends to the correct address and that no intermediate device drops fragments. Document each rule with its owner so that a later change in the appliance estate does not break ingestion without notice.

Certificates for TLS on TCP

CEF inputs support TLS on TCP only, so plan the certificate before you choose that transport. Obtain a server certificate and private key whose subject or SAN matches the name the appliance connects to, and identify the CA chain the appliance must trust. Confirm with the appliance vendor whether it can present or validate the chain, and whether it needs a client certificate. Record the expiry date and assign a renewal owner.

Broker, topic and credentials for AMQP or Kafka

If logs reach Graylog through a broker rather than directly, define the broker host, the queue or topic, and a dedicated consumer account with read access only. For Kafka, confirm the topic name, consumer group and the TLS or SASL mechanism the cluster enforces, since unsecured listeners may be mixed in. For RabbitMQ, confirm the queue and the vhost permissions. Ask the team that runs the broker who owns retention and replay, because Graylog consumes what the broker still holds.

Appliance CEF export settings

Before you create the input, ask the appliance vendor which CEF version, transport, port and field layout its export uses, and whether it can send full field names or only short keys. Graylog uses the CEF key as the field name by default unless the full field names option is set, so your searches and dashboards depend on that choice. Confirm these settings in the vendor documentation for your model and firmware, and test with a single appliance before enabling the rest.

Choosing TCP, UDP, AMQP or Kafka for CEF delivery

For most firewalls, proxies and security tools that can send CEF directly, a TCP listener with TLS is the default choice. TCP gives the sender feedback when a connection fails, and the CEF input supports TLS on TCP, so events can be encrypted between the appliance and Graylog. This keeps the architecture small because no broker sits between the device and the Graylog inputs.

Encryption in transit: TLS is available on the CEF TCP input, which matters when logs cross segments or sites.
Fewer moving parts: the appliance connects straight to the Graylog input, so there is no broker to patch or monitor.
Connection handling: confirm whether the appliance reconnects automatically and how it behaves when Graylog is unreachable.
Certificate management: plan who issues, renews and installs the certificates on both the appliance and the input.
Load distribution: a single TCP listener is one connection target, so plan how multiple appliances or nodes are addressed.

Before you choose this path, confirm the appliance's CEF output supports TCP and TLS and which certificate formats it accepts.

Configuring the CEF input step by step

This sequence takes a firewall or security appliance from an unconfigured port to verified CEF messages searchable in Graylog, with a check at each stage so problems surface before the appliance is in production use.

Choose the transport and port plan
Decide between CEF TCP, CEF UDP, CEF AMQP and CEF Kafka before touching Graylog. Your choice depends on what the appliance can send and how your network carries the traffic. Record the protocol, the listening port and the Graylog node that will accept the messages, and confirm that no other input already uses that port on the node. Confirm the transport with the appliance vendor's documentation. The step is done when you have a one-line plan per source that names the protocol, port and receiving node.
Create the CEF input on a Graylog node
In the Graylog web interface, open the input configuration, select the CEF input that matches your transport, and bind it to the dedicated port on a specific node. Give the input a clear title that names the source, such as the firewall model and site. If you run several Graylog server nodes, start the input on the node you planned, then confirm in the input list that its state shows as running. The check is a running input with no error message on the node details page.
Set the field naming option
Decide whether CEF extension keys should appear as short keys or full field names, and set the full field names option on the input to match. Graylog uses the CEF key as the field name by default, so the choice affects every search and dashboard that follows. Write the decision in your runbook, because changing it later changes the field names your searches depend on. The check is a test message with a known extension key, where you confirm the resulting field name in the message details matches your plan.
Enable TLS on the TCP input if you use it
If the transport is TCP and the appliance supports encrypted syslog, enable TLS on the CEF TCP input and supply the certificate and key the input expects. Graylog documents TLS for CEF inputs on TCP only, so UDP, AMQP and Kafka transports do not take this step. Confirm that the certificate chain is trusted by the appliance, because a mismatch usually shows up as connections that open and then drop. The check is a connection from the appliance that stays established and produces messages in the input's message count.
Point the appliance at the Graylog port
In the firewall or security appliance, configure a syslog or CEF destination with the Graylog node address, the port and the protocol you chose, and set the message format to CEF. Enable the log types you need, such as traffic, threat or authentication events, and start with a narrow set so volume stays predictable. Make sure firewall rules between the appliance and the node allow the traffic in the direction it flows. The check is that the appliance reports the destination as active and sends a test or live event.
Confirm messages arrive in search
Open the Graylog search page and filter for the input or the source address of the appliance. Confirm that messages appear with the CEF fields you expected, and that the timestamps and source host look correct. If the input shows received messages but the search returns nothing, check the time range and the index set the input writes to. The check is a search result that returns events from the appliance within the last few minutes.
Route the messages into a stream
Create a stream with a rule that matches the appliance source or the input, and assign it to an index set that fits the retention you have planned for security events. Repeat your search and confirm that messages now appear under the stream. Routing into a dedicated stream lets you apply access controls, alerts and dashboards to this source without affecting others. The check is that the stream's message count increases while the appliance keeps sending, and that the same events are visible when you search by stream name.

How CEF key names become searchable fields

By default, Graylog's CEF inputs use the CEF extension key as the field name, so a firewall extension such as src or dpt lands in Graylog as a field with that short name. The full field names option changes this behavior and writes the long, descriptive names instead. The choice is made per input, which matters because the same appliance family can send extensions that map to different names depending on how the input was configured. Decide this before the first sources connect, not after dashboards exist.

The trade-off is between short names that match vendor documentation and long names that read clearly in search. Searches, dashboards, streams and any content pack you import all reference field names, so a mismatch means widgets show no data without raising an error. If one team has built queries against short keys and another expects long names, you end up maintaining two naming styles. Record the chosen option in your input configuration, and make sure every new CEF input in the cluster follows the same convention unless there is a documented reason to differ.

Test with real appliance samples before you standardize. Capture a representative set of events from each firewall, proxy and security tool, including the vendor's CEF version and any custom extensions, and send them to a test input with each naming option. Then check which fields appear, whether the values are correctly typed, and whether your saved searches and dashboards return results. Confirm the exact extension keys with each vendor, because CEF implementations differ in what they emit. Treat the result as the reference for the production naming standard.

Mapping CEF header and extension fields in Graylog

This table compares the CEF header fields and extension keys that a firewall or security appliance sends with how Graylog names them by default and with the full field names option. Read each row as a check to run against a sample message from your own device, because vendors differ in how they use keys and value sets. The main takeaway is that default key names let you start quickly, while normalization in pipeline rules or streams keeps searches and alerts working across vendors.

Field	What it carries	How to handle it in Graylog
Device vendor and product	Make and model of the appliance in the CEF header	Confirm the exact strings your device sends, then normalize spelling variants in a pipeline rule before building streams
Device version	Firmware or software version reported by the appliance	Confirm the format for your vendor and keep the raw value so parsing changes after upgrades stay visible
Signature ID and name	Event class identifier and the event description	Confirm the signature ID stays stable across firmware. Group alerts on the ID, since vendors may reword the name
Severity	Numeric level set by the device, typically on a 0 to 10 scale	Confirm the vendor scale, then map it to your own priority levels in a pipeline rule
Extension keys with default names	Short CEF keys such as src, dst, spt, dpt and act	Default field names are the CEF keys. Confirm each key in test data and check for collisions with fields from other inputs
Extension keys with full field names	Long-form names applied when the full field names option is set	Use this option for consistent naming across sources. Confirm the resulting names in a test message before building dashboards
Device-specific action and category values	Vendor text such as allow, deny, block or drop	Normalize values into one shared set with pipeline rules. Confirm the full value list from the appliance's log documentation
Timestamps and host fields	Device time and host fields that can differ from receive time	Confirm which timestamp Graylog uses and the time zone the device writes, then compare against the appliance clock

Securing CEF input traffic and access

A CEF input is only as trustworthy as the path it listens on and the accounts that can change it. The cards below cover encryption on TCP, source restrictions, the unencrypted nature of UDP, and the credentials used by AMQP and Kafka pull inputs. Work through them together before any firewall begins sending production traffic.

TLS on the CEF TCP input

Graylog's CEF inputs support TLS on TCP only, so this is the one transport where the stream from a firewall or proxy can be encrypted in transit to the Graylog node. Plan the certificate chain, its subject names and the renewal process before the input is created, and confirm that the appliance can present or trust the CA your team uses. Test with a non-production sender first, and check the certificate expiry date on every node that runs the input.

Restricting source addresses

Limit which hosts can reach each CEF listener at the host firewall and at the network layer, so only the known firewall management or log-forwarding addresses can connect. Map each appliance to its own port or input where possible, which makes it easier to tell which device sent a message and to close one source without affecting others. Review these rules whenever a device is replaced or its management address changes.

UDP carries no transport encryption

CEF over UDP is sent without any transport encryption or delivery guarantee, so anyone on the path can read or spoof the messages and packets can be dropped under load. Treat UDP as acceptable only where the network segment is controlled and the loss risk is understood. Where confidentiality or integrity matters, prefer TCP with TLS, or move the traffic through a broker that the appliance can reach over an encrypted link.

Least-privilege access to inputs and streams

Give operators and automation accounts only the Graylog roles they need to manage CEF inputs, and separate the right to create an input from the right to read the streams that hold firewall data. Firewall logs often carry user names, internal addresses and blocked destinations, so restrict who can view raw messages. Confirm the role and sharing model in your edition before you grant access to a broader group.

AMQP and Kafka credentials

The CEF AMQP and CEF Kafka inputs pull messages from a broker, so the Graylog side holds a broker account whose permissions decide what can be read. Create a dedicated user with access only to the queue, topic or consumer group for that feed, and store the password in Graylog's managed configuration rather than in shared notes. Rotate the credential on a fixed schedule and after any staff change.

Broker encryption and authorization settings

Apache Kafka can run TLS and SASL on its listeners, and security is optional, so a cluster may accept unsecured clients beside secured ones. Check which listeners are encrypted, which SASL mechanism the Graylog input uses, and whether ACLs deny access to resources that have no explicit entry. Confirm these settings in your Kafka version's security documentation before pointing a CEF Kafka input at the cluster.

Why CEF logs stop arriving or parse wrong

This table lists the failures teams most often hit when CEF logs from a firewall or security appliance do not reach Graylog or do not parse as expected. Each row gives the likely cause and the first fix to try, so you can check the network path, transport, authentication and input settings in order.

Symptom	Likely cause	Fix to try first
No messages on a TCP input	Host firewall, security group or network ACL blocks the CEF TCP port between the appliance and the Graylog node	Confirm the port is open from the appliance's source address to the input's bind address, then check the input shows as running in Graylog
Gaps or missing events on a UDP input	UDP has no delivery guarantee, so packets drop when the input or the Graylog node is overloaded or the socket buffer fills	Compare appliance send counts with Graylog throughput, raise the receive buffer on the input if available, or move to TCP where the appliance supports it
TLS connection rejected on a CEF TCP input	Certificate chain not trusted by the appliance, expired certificate, hostname mismatch or the appliance sending plaintext to a TLS port	Confirm the appliance trusts the Graylog certificate chain and that the certificate is current, then match the sender's transport mode to the input
Messages arrive through AMQP or Kafka but nothing is indexed	Broker authentication failure, wrong virtual host or topic, or the consumer group using the wrong offset or access rights	Check broker logs for authentication or authorization errors, confirm the queue or topic name and credentials, and verify the Graylog user can read it
Fields appear under short keys such as src or dpt	CEF input uses the CEF key as the field name by default	Enable the full field names option on the input if your searches, pipelines or content packs expect the long names, then re-check existing rules
Expected fields are missing or named inconsistently across sources	Mixed naming settings on different CEF inputs, or a vendor log that does not follow the CEF extension keys you assumed	Use one naming setting per input, document it, and compare a sample raw message with the parsed fields before writing extractors
Messages land in the default stream and alerts do not fire	No stream rule matches the CEF source or fields, so messages fall through to the default stream	Create a stream rule on a stable field such as the input or device name, then confirm the stream receives new messages before enabling alerts

When a vendor-specific input or content pack is the better choice

A generic CEF input is the right starting point when a device can send CEF and you only need its events in Graylog as structured fields. It becomes the weaker choice when the product has its own log format, when vendor-specific fields need to be parsed into consistent names, or when a content pack already ships dashboards and searches for that product. In those cases, a dedicated input or a Graylog content pack for the product may save parsing work. Before deciding, check the vendor's log export options and Graylog's documentation for that specific product, because a device that calls its output CEF may still use vendor extensions that a generic input will not map the way you expect.

The check should start with what the appliance can actually send. Confirm the exact export format and syslog transport the device supports, whether it offers CEF at all, and which fields it includes in each event type. Then search Graylog's inputs and content packs for that product name and read what each one covers, including its supported versions. If the product's major version changed recently, verify that any content pack targets your release. Compare the field names a content pack produces against the names your existing searches, alerts and dashboards use, since switching inputs can silently break detections that rely on the older names.

Plan for the decision to be revisited. A content pack or dedicated input is a dependency that must be installed, tested and updated alongside Graylog itself, and some of these features depend on an Enterprise or Security license. Record which parser handles each source, test with sample events from a non-production device, and keep the generic CEF configuration documented as a fallback so that a vendor change does not stop log collection.

Questions teams ask before setting up CEF inputs

How much does it cost to set up CEF inputs in Graylog?

Graylog Open is free to download and run, with no volume limits and community support, so the software itself carries no license fee. The costs are the infrastructure to run Graylog, MongoDB and the search backend, the people who configure and test the inputs, and any Enterprise or Security license you choose. The CEF inputs themselves are part of the open-source edition. According to the Graylog pricing page, Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Ask any partner for a fixed-scope quote based on your appliance count, transports, TLS needs and test plan, and confirm current edition pricing directly with Graylog.

How long does a CEF input setup take?

No duration figure is supplied for this work, so treat any timeline as something to agree in writing rather than assume. The main drivers are how many firewalls, proxies and security tools send logs, how many transports you use (TCP, UDP, AMQP or Kafka), whether TCP connections need TLS and certificate handling, and how much testing you require before cutover. A small set of appliances on one transport with plain UDP moves quickly. Many appliances across several transports with TLS, parsing checks and a documented rollback take longer. A scoped plan from DeployOpen would break these drivers into deliverables and timelines before work starts.

What does the team need to provide before setup starts?

The work depends on access and decisions that only your organization can supply. Expect to provide a list of appliances and the log types each sends, network paths from each device to the Graylog inputs, the firewall rules that permit those paths, and a named owner for each appliance's log settings. You also need a decision on transport and field naming, plus certificates and a trust chain if you use TLS on TCP. Access to a test Graylog cluster that matches production is important so that inputs can be verified before live traffic moves.

Can our internal team set up CEF inputs without a partner?

Yes, if your team has administrators who can run Graylog, change settings on firewalls and proxies, manage certificates and read message parsing output. The Graylog CEF inputs documentation covers the four transports, the field naming option and TLS on TCP, so the configuration itself is well documented. The harder parts are usually cross-team coordination with network and appliance owners, testing that each device sends the expected fields, and planning for growth. Assess these honestly. If the team is stretched, a partner can take the build and testing while your staff keep ownership of the running system.

Which transport should we choose for firewall logs, TCP, UDP, AMQP or Kafka?

Choose based on delivery needs, not habit. UDP is the simplest to configure but offers no delivery acknowledgement, so messages can be lost under load or network faults. TCP is the usual choice when you need reliable delivery from the device and supports TLS in Graylog. AMQP and Kafka pull inputs suit cases where a broker already sits between appliances and Graylog and buffers traffic. Adding a broker adds components to run, patch and monitor, so only introduce one if your architecture already needs it. Confirm that each appliance can send to your chosen transport before you commit.

Does TLS apply to every CEF input?

No. According to the Graylog inputs documentation, CEF inputs support TLS on TCP only, so UDP, AMQP and Kafka CEF inputs cannot be encrypted by the input itself. If logs cross untrusted networks or carry sensitive data, plan encryption for the TCP path and confirm how the other transports are protected in your network, such as by isolated segments or encrypted broker connections. Certificate issuance, rotation and the trust chain on each appliance also need owners, because an expired certificate stops log delivery silently.

How do we test CEF inputs before relying on them for security monitoring?

Test each appliance and log type against the input before you depend on the data. Confirm that messages arrive on the expected transport, that TLS handshakes succeed where used, and that the CEF fields appear under the names you chose, either the CEF key default or full field names. Check that searches and any alert conditions match the real events, and that a message is not dropped during a short outage of the path. Record the results so auditors and your own team can see what was verified. The test scope should match the number of appliances and transports, and should be agreed in the written plan.

When is a vendor-specific input or content pack a better choice than CEF?

A vendor-specific input or content pack is usually better when the vendor has a dedicated Graylog input or a documented content pack for the product, because those provide parsing and fields that match the vendor's log format and reduce custom work. CEF is a good general route when a device emits CEF and no dedicated input fits, or when you want one consistent pipeline across several vendors. Check the Graylog inputs documentation and your appliance's documented output format first. Some vendor content may need an Enterprise or Security edition, so confirm licensing before choosing that path.

How DeployOpen scopes and delivers CEF input work

DeployOpen plans and builds Graylog CEF inputs inside your own infrastructure, starting from a written scope that names each firewall, proxy and security tool and the transport it will use. We test each source against the input before it reaches production, then document the configuration so your team can run and change it. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

We list every firewall, proxy and security appliance that will send CEF, with its vendor, model and firmware version.
The written scope records the transport for each source: CEF over TCP, UDP, AMQP or Kafka, and whether TLS applies.
We agree the field naming choice and whether a vendor-specific input or content pack is in or out of scope.

How we build

We configure the CEF inputs, bind them to the right nodes and set up streams that route each source's messages.
We enable TLS on the CEF TCP inputs where the scope requires it and confirm the certificate chain each sender trusts.
We test every source with sample events, checking parsed field names, timestamps and message volume against the agreed plan.

How we hand over

You receive a source inventory with input type, port, transport, TLS status and the owning team for each sender.
The documentation covers the sender-side settings the firewall administrator must match, such as protocol, port and format.
We walk your engineers through the test results, known parsing gaps and the steps for adding a new appliance later.

How we support

Ongoing support covers input changes, Graylog upgrades that touch CEF parsing and troubleshooting of dropped or malformed events.
Continuous testing and upgrades are available as a retainer, so new appliance sources follow the same tested path.
Before a Graylog upgrade, we confirm the documented changes that could affect your existing CEF inputs and fields.

Graylog CEF inputs for firewalls and security appliances