nano SIEM
Integrations

Splunk HEC

Ingest logs from Splunk forwarders, Cribl, and other HEC-compatible sources

Splunk HEC

nano accepts logs via the Splunk HTTP Event Collector (HEC) protocol on port 8088. This lets you forward data from Splunk Universal Forwarders, Splunk Heavy Forwarders, Cribl Stream, and any other tool that speaks HEC — without changing your existing log shipping infrastructure.

How It Works

Splunk HEC is a simple HTTP JSON protocol. Clients POST events to /services/collector/event (single event) or /services/collector (batch) with a token in the Authorization: Splunk <token> header.

nano's Vector pipeline listens on port 8088 and accepts HEC events natively. The Splunk sourcetype field is used for routing — nano maps it to source_type to select the correct parser.

Prerequisites

  • A running nano instance with port 8088 accessible
  • A Splunk forwarder, Cribl Stream, or any HEC-compatible client

Step 1: Get the HEC Token

nano uses a shared authentication token for HEC ingestion. This is the same token used for HTTP ingestion (VECTOR_AUTH_TOKEN).

For production deployments, this token is set via environment variable on the nano Vector service:

# Check current token (in docker-compose or k8s deployment)
echo $VECTOR_AUTH_TOKEN

Step 2: Configure Your HEC Client

Splunk Universal Forwarder

Configure the UF to send to nano instead of (or in addition to) a Splunk indexer.

Edit outputs.conf on the forwarder:

[httpout]
httpEventCollectorToken = your-nano-token
uri = https://your-nano-instance.com:8088/services/collector

[httpout:nano]
httpEventCollectorToken = your-nano-token
uri = https://your-nano-instance.com:8088/services/collector

Or use outputs.conf with the HEC output:

[tcpout]
defaultGroup = nano-hec

[tcpout:nano-hec]
server = your-nano-instance.com:8088
token = your-nano-token
useHTTP = true

Splunk Heavy Forwarder

Add a new output to forward to nano. In outputs.conf:

[httpout:nano]
httpEventCollectorToken = your-nano-token
uri = https://your-nano-instance.com:8088/services/collector

Cribl Stream

Create a Splunk HEC destination in Cribl:

  1. Go to DestinationsSplunk HEC
  2. Configure:
FieldValue
Endpointhttps://your-nano-instance.com:8088/services/collector
HEC Auth TokenYour nano token
Backpressure behaviorBlock

Fluent Bit

Fluent Bit has a native Splunk output plugin:

[OUTPUT]
    Name        splunk
    Match       *
    Host        your-nano-instance.com
    Port        8088
    Splunk_Token your-nano-token
    TLS         On
    TLS.Verify  Off

curl (Testing)

Send a test event to verify connectivity:

curl -X POST https://your-nano-instance.com:8088/services/collector/event \
  -H "Authorization: Splunk your-nano-token" \
  -d '{
    "time": 1705312800,
    "sourcetype": "test_app",
    "source": "test",
    "host": "myhost",
    "event": {
      "message": "Test event from curl",
      "level": "INFO",
      "user": "admin"
    }
  }'

A successful response returns:

{"text": "Success", "code": 0}

Batch Events

Send multiple events in a single request (no array wrapper — just concatenated JSON objects):

curl -X POST https://your-nano-instance.com:8088/services/collector \
  -H "Authorization: Splunk your-nano-token" \
  -d '{"time": 1705312800, "sourcetype": "test_app", "event": {"message": "Event 1"}}
{"time": 1705312801, "sourcetype": "test_app", "event": {"message": "Event 2"}}
{"time": 1705312802, "sourcetype": "test_app", "event": {"message": "Event 3"}}'

Step 3: Understand sourcetype Routing

The sourcetype field in HEC events is the routing key. nano uses it to determine which parser processes the event — just like Splunk uses it to select the correct parsing pipeline.

How Routing Works

When a HEC event arrives with "sourcetype": "WinEventLog:Security":

  1. Vector extracts the sourcetype field from the HEC payload
  2. A routing transform maps sourcetype to nano's internal source_type
  3. The event is forwarded to the matching parser

Common Splunk Sourcetypes

Splunk sourcetypenano source_typeLog Type
WinEventLog:Securitywindows_eventWindows Security Event Log
WinEventLog:Systemwindows_systemWindows System Event Log
XmlWinEventLog:Securitywindows_eventWindows XML Event Log
pan:trafficpalo_altoPalo Alto Traffic
pan:threatpalo_alto_threatPalo Alto Threat
cisco:asacisco_asaCisco ASA Firewall
syslogsyslogGeneric Syslog
linux_securelinux_authLinux Auth Log
access_combinedapacheApache/Nginx Access

Step 4: Create Log Sources in nano

For each sourcetype your forwarders send, create a log source with a matching parser:

  1. Navigate to FeedsNew Feed
  2. Select "Sample from existing data" if events are already flowing, or "I have sample logs" to paste examples
  3. Set the source type to match the sourcetype your clients send
  4. The AI generates a parser for the log format
  5. Publish to deploy

Windows Event Logs (Common HEC Use Case)

If you're forwarding Windows Event Logs via Splunk UF:

  1. Paste a sample Windows Security event (XML or rendered text, depending on your UF config)
  2. nano's parser will extract fields like EventCode, Account_Name, Source_Network_Address, etc.
  3. Set source type to windows_event
  4. Publish

Palo Alto via HEC

If Palo Alto logs flow through a Splunk forwarder with sourcetype=pan:traffic:

  1. Paste a sample Palo Alto CSV traffic log
  2. The parser extracts fields like src_ip, dst_ip, action, rule, app
  3. Set source type to palo_alto
  4. Publish

Step 5: Verify Ingestion

Search Your Data

Navigate to Search and query using either field name:

source_type="windows_event"

Or the Splunk-compatible alias:

sourcetype="WinEventLog:Security"

Both return the same results.

Check Feed Health

  1. Go to Feeds → select your log source
  2. On the Overview tab, verify:
    • Status: Healthy
    • Event Volume chart: Events arriving
    • Last Event: Recent timestamp

Check for Errors

If events aren't appearing:

  1. Test HEC connectivity:

    curl -v -X POST https://your-nano-instance.com:8088/services/collector/event \
      -H "Authorization: Splunk your-token" \
      -d '{"sourcetype": "test", "event": "hello"}'
    • 200 OK with {"text":"Success","code":0} — connection and auth working
    • 401 — wrong token
    • Connection refused — port 8088 not exposed or firewall blocking
  2. Check Vector logs:

    docker logs nanosiem-vector 2>&1 | grep -i "splunk\|hec\|8088\|error"
  3. Check ingestion errors in nano at SystemIngestion Errors

Migrating from Splunk to nano

If you're migrating from Splunk, the HEC integration makes it straightforward to run both systems in parallel:

Dual-Forward Strategy

Configure your forwarders to send to both Splunk and nano simultaneously:

# outputs.conf on Splunk Universal Forwarder
[tcpout]
defaultGroup = splunk-indexers

[tcpout:splunk-indexers]
server = splunk-idx1:9997, splunk-idx2:9997

[httpout:nano]
httpEventCollectorToken = your-nano-token
uri = https://your-nano-instance.com:8088/services/collector

This lets you:

  1. Build and validate nano parsers against real production data
  2. Compare search results between Splunk and nano
  3. Migrate detection rules gradually
  4. Cut over source by source when confident

Cribl as a Router

If you use Cribl Stream, it can route data to both Splunk and nano simultaneously:

Sources → Cribl Stream → Splunk HEC (nano)
                       → Splunk Indexers

This is often the cleanest approach for parallel operation.

HEC Payload Reference

Single Event

{
  "time": 1705312800,
  "host": "webserver-01",
  "source": "/var/log/nginx/access.log",
  "sourcetype": "nginx:access",
  "index": "main",
  "event": {
    "remote_addr": "203.0.113.50",
    "request": "GET /api/users HTTP/1.1",
    "status": 200,
    "bytes": 1234
  }
}
FieldRequiredDescription
eventYesThe log event (string or JSON object)
sourcetypeRecommendedMaps to nano source_type for parser routing
timeNoUnix epoch timestamp (seconds or milliseconds). If omitted, nano uses receipt time
hostNoHostname of the originating system
sourceNoLog file path or data source name
indexNoIgnored by nano (included for Splunk compatibility)

Raw Event

For plain-text logs, send the raw string as the event value:

{
  "sourcetype": "syslog",
  "event": "Jan 15 14:23:45 fw-01 %ASA-6-302013: Built outbound TCP connection 12345 for outside:203.0.113.50/443"
}

Troubleshooting

"Invalid token" response

  • Verify you're using Authorization: Splunk <token> (not Bearer)
  • Check the token matches the VECTOR_AUTH_TOKEN environment variable on the nano Vector service

Events received but wrong sourcetype

  • Check that the sourcetype field is set correctly in your forwarder config (props.conf or inputs.conf)
  • For Cribl, verify the sourcetype is preserved in the pipeline (check for transforms that modify it)

Timestamp issues

  • HEC accepts Unix epoch in seconds (1705312800) or milliseconds (1705312800000) — Vector handles both
  • If time is omitted, nano uses the receipt time
  • Ensure your forwarder is sending timestamps in UTC

Large events being dropped

  • Vector's HEC source has a default max body size. For very large events (>1MB), check Vector logs for size-related errors
  • Consider splitting large events or increasing the Vector buffer size

Next Steps

On this page

On this page