Only Logging DNS traffic; tcpdump shows other traffic available

Having an issue where Suricata is only logging Port 53/DNS traffic and refuses to log other traffic into eve.json.

Confirmed other traffic is being captured in tcpdump on necessary ethernet port; cannot find any issues from within suricata.yaml and could use some assistance. Part of the yaml below:

 - http:
            extended: yes     # enable this for extended logging information
            # custom allows additional http fields to be included in eve-log
            # the example below adds three additional fields when uncommented
            custom: [referer]
            # set this value to one among {both, request, response} to dump all
            # http headers for every http request and/or response
            # dump-all-headers: [both, request, response]
        - dns:
            # This configuration uses the new DNS logging format,
            # the old configuration is still available:
            # https://suricata.readthedocs.io/en/latest/output/eve/eve-json-output.html#dns-v1-format

            # As of Suricata 5.0, version 2 of the eve dns output
            # format is the default.
            #version: 2

            # Enable/disable this logger. Default: enabled.
            #enabled: yes

            # Control logging of requests and responses:
            # - requests: enable logging of DNS queries
            # - responses: enable logging of DNS answers
            # By default both requests and responses are logged.
            #requests: no
            #responses: no

            # Format of answer logging:
            # - detailed: array item per answer
            # - grouped: answers aggregated by type
            # Default: all
            #formats: [detailed, grouped]

            # Types to log, based on the query type.
            # Default: all.
            #types: [a, aaaa, cname, mx, ns, ptr, txt]
        - tls:
            extended: yes     # enable this for extended logging information
            # output TLS transaction where the session is resumed using a
            # session id
            #session-resumption: no
            # custom allows to control which tls fields that are included
            # in eve-log
            #custom: [subject, issuer, session_resumed, serial, fingerprint, sni, version, not_before, not_after, certificate, chain, ja3, ja3s]
        - files:
            force-magic: no   # force logging magic on all logged files
            # force logging of checksums, available hash functions are md5,
            # sha1 and sha256
            #force-hash: [md5]
        #- drop:
        #    alerts: yes      # log alerts that caused drops
        #    flows: all       # start or all: 'start' logs only a single drop
        #                     # per flow direction. All logs each dropped pkt.
        - smtp:
            #extended: yes # enable this for extended logging information
            # this includes: bcc, message-id, subject, x_mailer, user-agent
            # custom fields logging from the list:
            #  reply-to, bcc, message-id, subject, x-mailer, user-agent, received,
            #  x-originating-ip, in-reply-to, references, importance, priority,
            #  sensitivity, organization, content-md5, date
            #custom: [received, x-mailer, x-originating-ip, relays, reply-to, bcc]
            # output md5 of fields: body, subject
            # for the body you need to set app-layer.protocols.smtp.mime.body-md5
            # to yes
            #md5: [body, subject]

What version are you running and how?
This part of the config is not enough to find the potential issue, please post the whole config ideally.

Hello,

Sorry for the delayed response and lack of information; appreciate your reply.

Running Suricata 6.0.4 on an ubuntu server. Please see attached yml. Appreciate your time.
suricata.yml (68.5 KB)

I ran with your suricata.yaml for a few minutes and saw dns, tls, http, and some others so I don’t think its your configuration file.

Check the stats.log, or maybe post it here. Maybe it has some clues.

Thank you, please see attached.
stats.log (4.2 KB)

Which capture method is used? Ideally post the exact command with arguments that is used to run suricata.
In the stats.log you can see that tls, ntp, dhcp, krb was seen as well.

Hello,

I am picking up an existing Suricata install and trying to wrap my arms around the in’s and out’s of both Suricata and this specific configuration. Apologies if this is not the information you are looking for. Below is suricatasc info and attached is --dump-config.

capture-mode
Success:
“AF_PACKET_DEV”
running-mode
Connection lost, trying to reconnect
Success:
“workers”
version
dumpconfig.log (17.7 KB)

Success:
“6.0.4 RELEASE”

Hmm when suricata is running can you ps auxfww | grep suricata and paste this?
How long was the run with the stats.log you posted some days ago?

root 10376 0.0 0.0 14436 1064 pts/0 S+ 16:45 0:00 _ grep --color=auto suricata
root 9500 16.8 2.8 807800 236448 ? Ssl 16:05 6:49 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid --af-packet -D -vvv

The stats.log was set to default, 8 seconds.

What network card and what driver is used?
What distribution and which kernel version?
Can you post a stats.log that did run several minutes and had a change to see more traffic?

ASIX AX88179 USB 3 External Ethernet adapter; default Microsoft driver
Hyper-V Host with Ubuntu 18.04 VM running kernel 4.15.0-167
Attached is a longer stats.log

stats.log (416.9 KB)

I should note that we are able to collect appropriate traffic on the host and VM; the issue seems limited to Suricata application log collection.

Based on the stats.log you also see http, ntp as well.
To rule out the capture method you could try to capture the traffic with tcpdump to create a pcap and run the pcap against suricata to see if it makes any difference.

Thank you Andreas,

I’ve been tied up but do plan to do this as soon as possible. Thanks for the help.