13.2 Optional Settings for Network Inputs

Splunk Enterprise Certified Admin SPLK-1003

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the Splunk Enterprise Certified Admin Exam

2 Chapter 1: Splunk Admin Basics

1.1 Splunk Enterprise Architecture & Core Components

3 Chapter 2: License Management

2.1 License Types, Stacks, Pools & Licensing Architecture 2.2 License Violations, Rolling Window Warnings & Troubleshooting

4 Chapter 3: Splunk Configuration Files

3.1 Splunk Configuration Directory Structure 3.2 Configuration Layering, Precedence & Resolution Rules 3.3 Using btool to Inspect & Debug Configurations

5 Chapter 4: Splunk Indexes

4.1 Index Structure: Directories, Buckets & Bucket Files 4.2 Bucket Types & the Hot-Warm-Cold-Frozen-Thawed Lifecycle 4.3 Checking Index Data Integrity 4.4 indexes.conf Options: Paths, Bucket Sizing & Volumes 4.5 The Fishbucket: File Tracking, CRC Collisions & Re-reading Files 4.6 Applying a Data Retention Policy

6 Chapter 5: Splunk User Management

5.1 Splunk Roles, Capabilities & Custom Role Design 5.2 User Account Administration, Search Restrictions & Limits

7 Chapter 6: Splunk Authentication Management

6.1 Integrating Splunk with LDAP 6.2 Other Authentication Options & Enabling Multifactor Authentication

8 Chapter 7: Getting Data In

7.1 CLI Administration & Basic Data Onboarding Workflows 7.2 Forwarder Types: Universal Forwarder vs. Heavy Forwarder

9 Chapter 8: Distributed Search

8.1 How Distributed Search Works 8.2 Roles of the Search Head and Search Peers 8.3 Configuring Search Peers & Distributed Search Groups 8.4 Search Head Scaling & Search Head Clustering (SHC)

10 Chapter 9: Getting Data In – Staging

9.1 Ingestion Pipeline Stages: Input, Parsing, Merging, Typing & Indexing 9.2 Pipeline Component Placement & Queue Management 9.3 Splunk Input Options

11 Chapter 10: Configuring Forwarders

10.1 Forwarder Setup & outputs.conf Load Balancing 10.2 Indexer Acknowledgment, Data Cloning & Forwarder Routing

12 Chapter 11: Forwarder Management

11.1 Deployment Management & the Deployment Server 11.2 Deployment Apps & Deployment Clients 11.3 Server Classes, Client Grouping & App Deployment Strategies 11.4 Forwarder Management Monitoring & Troubleshooting

13 Chapter 12: Monitor Inputs

12.1 File & Directory Monitoring Mechanics 12.2 Monitor Input Tuning: Whitelists, Blacklists & CRC Settings 12.3 Deploying a Remote Monitor Input, Network Shares & Archives

14 Chapter 13: Network and Scripted Inputs

13.1 Creating Network Inputs: TCP & UDP 13.2 Optional Settings for Network Inputs 13.3 Scripted Inputs & PowerShell Data Collection

15 Chapter 14: Agentless Inputs

14.1 Windows Management Instrumentation (WMI) Inputs 14.2 HTTP Event Collector (HEC) Architecture & Administration

16 Chapter 15: Fine Tuning Inputs

15.1 Input-Phase Processing & Default Metadata Assignment 15.2 Character Set Encoding & Handling Binary Data

17 Chapter 16: Parsing Phase and Data

16.1 Line Breaking & Event Segmentation 16.2 Timestamp Extraction, Time Zones & Clock Skew Handling 16.3 Validating Event Parsing with Data Preview

18 Chapter 17: Manipulating Raw Data

17.1 Transformation Mechanics: props.conf & transforms.conf 17.2 Data Masking, Redaction & SEDCMD 17.3 Event Routing, Dynamic Index Assignment & Filtering to nullQueue

13.2 Optional Settings for Network Inputs

Key Takeaways Explain This Topic AI

connection_host sets host from reverse DNS (dns, the TCP default), the sender IP (ip, the UDP default), or leaves it as configured (none).

queue = parsingQueue (default) sends network data through parsing; queue = indexQueue skips line breaking, timestamps, and transforms.

queueSize (default 500KB) sets the in-memory input queue, and persistentQueueSize (default 0) adds a larger disk-backed queue.

UDP inputs request a receive buffer with _rcvbuf (default 1,572,864 bytes), and acceptFrom allows or denies senders by IP, CIDR, or DNS name.

Ports below 1024 need root or CAP_NET_BIND_SERVICE; a common alternative is to listen on a high port and redirect with iptables or nftables.

Last updated: September 2026

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

Setting Applies to Default Purpose

connection_host TCP, UDP dns for TCP , ip for UDP How host is set: reverse DNS, sender IP, or none (keep the stanza/default host)

• source / sourcetype TCP tcp:<port> / tcp-raw Metadata when not set explicitly
• source / sourcetype UDP udp:<port> / udp:<port> Metadata when not set explicitly
• index TCP, UDP default (the main index) Destination index
• queue TCP, UDP parsingQueue Send data to parsingQueue (normal) or straight to indexQueue (skip parsing)
• queueSize TCP, UDP 500KB In-memory input queue
• persistentQueueSize TCP, UDP 0 (off) Disk-backed queue used when the in-memory queue fills
• _rcvbuf UDP 1572864 bytes Socket receive buffer requested from the OS
• acceptFrom TCP, UDP * Allow or deny senders by IP, CIDR, or DNS name ( ! prefix denies; first match wins)
• rawTcpDoneTimeout TCP 10 seconds Idle time after which the last event on a connection is considered complete

no_priority_stripping / no_appending_timestamp UDP false / false When true : keep the syslog <priority> field; do not append a timestamp and host

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.