13.2 Optional Settings for Network Inputs

Optional Settings for Network Inputs

Blueprint objective 13.2 asks you to describe optional settings for network inputs. Beyond the port, a TCP or UDP input can set how the host is assigned, where data goes, how much it buffers, and who may connect.

Quick Reference

Host, Queue, and Metadata Assignment

The settings that most often matter on the exam are connection_host (how host is set) and queue (whether the data is parsed).

Deep Dive: connection_host Options & Pitfalls

The connection_host setting determines how the host metadata value is derived:

• connection_host = ip (the default for UDP inputs): Splunk sets host to the sender's IP address. There is no lookup, so it is fast and predictable.
• connection_host = dns (the default for TCP inputs): Splunk sets host to the reverse DNS name of the sender's IP. Splunk notes that the forward and reverse DNS entries should match for this to work correctly.
  • With dns, host values depend on your DNS being fast and correct. Many administrators use ip for busy syslog inputs and map addresses to names with a search-time lookup.
• connection_host = none: Splunk leaves host as set in inputs.conf, typically the receiving instance's host name. A source type with a host-override transform, such as the built-in syslog source type, can still set host from the event text, and Splunk's spec notes that such a transform takes precedence.

Deep Dive: queue Selection

• queue = parsingQueue (default): the data goes through the parsing pipelines, so Splunk applies character encoding (CHARSET), line breaking (LINE_BREAKER), timestamp extraction (TIME_PREFIX, TIME_FORMAT), and transforms.
• queue = indexQueue: Skips the parsing, merging, and typing pipelines. Data goes straight to indexQueue.

  • [!CAUTION]

  • With queue = indexQueue, no line breaking, timestamp extraction, or transforms are applied to that data. Use it only for data that needs no parsing.

Buffering: queueSize, persistentQueueSize, and _rcvbuf

[udp://514]
connection_host = ip
sourcetype = syslog
_rcvbuf = 16777216
queueSize = 10MB
persistentQueueSize = 5GB
acceptFrom = 10.20.0.0/16, !10.20.99.0/24, *.net.corp.example

• _rcvbuf asks the operating system for a larger UDP socket buffer (default 1,572,864 bytes). If the OS refuses the size, Splunk keeps halving the request until it succeeds. On Linux, net.core.rmem_max caps what the kernel will grant.
• queueSize sets the in-memory input queue. persistentQueueSize adds a disk-backed overflow queue and must be larger than the in-memory queue. Persistent queues help absorb short outages of the downstream pipeline for network and scripted inputs. They do not help while Splunk itself is stopped, because nothing is listening on the port.
• acceptFrom rules are evaluated in order, and the first match wins. It supersedes the older [udp://<remote server>:<port>] form.

Privileged Port Constraints on Linux (Ports Below 1024)

Common network logging protocols use well-known privileged ports:

• Syslog: UDP 514 / TCP 514
• Secure Syslog: TCP 6514
• SNMP Traps: UDP 162

On Linux, ports below 1024 are privileged: only root or a process with the CAP_NET_BIND_SERVICE capability can bind to them.

The Security Imperative: Never Run Splunk as Root

Running Splunk Enterprise as the root superuser allows splunkd to bind directly to port 514. However, running Splunk as root is a severe security anti-pattern:

• Any security vulnerability in Splunk's web server, REST API, or custom Python scripts could grant an attacker complete, unrestricted root access to the underlying host.
• Files created by Splunk will be owned by root, breaking permissions if Splunk is later transitioned to a service account.
• Run Splunk under a dedicated, unprivileged service account (typically named splunk).

To let an unprivileged Splunk service account receive traffic sent to privileged ports, use one of two common approaches:

Approach 1: Linux File Capabilities (setcap)

Linux capabilities divide traditional superuser privileges into discrete units. The capability CAP_NET_BIND_SERVICE allows a binary to bind to sockets below 1024 without granting any other root privileges.

To grant this capability to splunkd:

# Set capability on the splunkd binary
sudo setcap 'cap_net_bind_service=+ep' /opt/splunk/bin/splunkd

# Verify assigned capabilities
getcap /opt/splunk/bin/splunkd
# Output: /opt/splunk/bin/splunkd = cap_net_bind_service+ep

• Caveats:
  • File capabilities belong to the binary file, so replacing splunkd during an upgrade removes them. Re-apply setcap after each upgrade.
  • If Splunk runs under systemd, you can grant the capability in the service unit (Splunk's generated unit is Splunkd.service) instead:

    [Service]
    User=splunk
    Group=splunk
    AmbientCapabilities=CAP_NET_BIND_SERVICE
    CapabilityBoundingSet=CAP_NET_BIND_SERVICE
    

Approach 2: Port Redirection via Kernel Firewall (iptables / nftables)

A widely adopted, upgrade-resilient method is configuring Splunk to bind to a high, unprivileged port (such as UDP 1514 or TCP 1514 in inputs.conf), and using kernel packet filtering to redirect incoming traffic from port 514 to the higher port.

Using iptables:

# Redirect incoming UDP 514 to UDP 1514
sudo iptables -t nat -A PREROUTING -p udp --dport 514 -j REDIRECT --to-ports 1514

# Redirect incoming TCP 514 to TCP 1514
sudo iptables -t nat -A PREROUTING -p tcp --dport 514 -j REDIRECT --to-ports 1514

Using nftables:

sudo nft add table ip nat
sudo nft add chain ip nat prerouting '{ type nat hook prerouting priority -100; }'
sudo nft add rule ip nat prerouting udp dport 514 redirect to 1514
sudo nft add rule ip nat prerouting tcp dport 514 redirect to 1514

In inputs.conf, the stanza simply listens on the high port:

[udp://1514]
connection_host = ip
sourcetype = syslog

This approach survives Splunk upgrades and maintains strict unprivileged process isolation.