IPS: dropped packets with no `signature_id` and questions about the flow event

Help
1

Hello,

I just deployed Suricata version 6.0.1 on Debian. It runs as IPS using NFQUEUE. I have a few questions regarding the log of Suricata. I am not sure if it is the correct place to ask these questions.

Q1: In the log (eve.json), there are indications that a packet has been dropped but there is no signature_id or any explanation as to how this package was dropped, below is one of the packet example. Is it expected behaviour when the event_type is drop?

{
  "timestamp": "2022-02-02T03:07:28.522681+0100",
  "flow_id": 738519213471990,
  "event_type": "drop",
  "src_ip": "MY_HOST_IP",
  "src_port": 11111,
  "dest_ip": "107.148.179.232",
  "dest_port": 23,
  "proto": "TCP",
  "drop": {
    "len": 40,
    "tos": 0,
    "ttl": 64,
    "ipid": 0,
    "tcpseq": 1804907497,
    "tcpack": 0,
    "tcpwin": 0,
    "syn": false,
    "ack": false,
    "psh": false,
    "rst": true,
    "urg": false,
    "fin": false,
    "tcpres": 0,
    "tcpurgp": 0
  }
}

Q2: what is the "event_type": flow"? I have seen these a lot in the log. It summarises the data exchanged between my host and the target system?

{
  "timestamp": "2022-02-02T03:08:59.558183+0100",
  "flow_id": 738519213471990,
  "event_type": "flow",
  "src_ip": "107.148.179.232",
  "src_port": 23,
  "dest_ip": "MY_HOST_IP",
  "dest_port": 11111,
  "proto": "TCP",
  "flow": {
    "pkts_toserver": 1,
    "pkts_toclient": 1,
    "bytes_toserver": 44,
    "bytes_toclient": 40,
    "start": "2022-02-02T03:07:28.522486+0100",
    "end": "2022-02-02T03:07:28.522681+0100",
    "age": 0,
    "state": "new",
    "reason": "unknown",
    "alerted": false
  },
  "tcp": {
    "tcp_flags": "00",
    "tcp_flags_ts": "00",
    "tcp_flags_tc": "00"
  }
}

Q3: what happens when the queue is full? So the data is not processed and Suricata is not able to block them?

Thank you,
TS

2

Q1: Do you have an alert event as well for this flow_id? But sometimes the internal engine might drop packets if theyr’e too broken.

Q2: A flow is a network flow, so more or less the complete connection from the first syn to the last fin. It is helpful metadata.

Q3: you can use --queue-bypass if you want to avoid that scenario, but besides that this is a potential bottleneck if the queue grows to full and Suricata isn’t fast enough.You could also run Suricata on more queues with the balance nfqueue feature.

3

Thank you for your answers.

Q1: There is no alert event for this kind of flow_id. What does it mean when the packets are too broken? And what are the criteria/rules that suggest a packet is too broken?
Q3: So my assumption is correct? when a queue is full, a packet is not dropped and then the attack can still happen, assume that my system is infected by a Mirai variant malware?

4

There is no full list but too many missing packets, non-rfc compliant traffic etc.

The packet doesn’t have to be accepted, this depends on your setup. AFAIR by default all packets will be dumped into the nfqueue and unless you set the bypass option they will stay there and you will just end up with the packets being stuck. So no traffic at all is passed at that point or only partial.

5

Thank you for your reply. So now I set up two queues to reduce this kind of scenario. I will update more information.

By the way, in my previous message, I said that when the queue was full, the packets were not dropped because (apparently) I did not forward all the network traffic of my system which ran in a docker container.

I have another question, in my log, I noticed that Suricata alerted TCP packet too small whose sid is 2200033, it is from a decode rule

{
  "timestamp": "2022-02-18T01:04:27.840387+0100",
  "event_type": "alert",
  "src_ip": "redacted",
  "src_port": 0,
  "dest_ip": "redacted",
  "dest_port": 0,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2200034,
    "rev": 2,
    "signature": "SURICATA TCP header length too small",
    "category": "Generic Protocol Command Decode",
    "severity": 3
  },
  "payload_printable": "",
  "stream": 0
}

And I think this one was also the same, it was just it was not complete. I think this happens because at that time there were too many packets to process.

{
  "timestamp": "2022-02-18T01:04:27.840387+0100",
  "event_type": "anomaly",
  "src_ip": "redacted",
  "src_port": 0,
  "dest_ip": "redacted",
  "dest_port": 0,
  "proto": "TCP",
  "anomaly": {
    "type": "decode",
    "event": "decoder.tcp.hlen_too_small"
  }
}

My question is what happens to these packets? Are they dropped or allowed to pass? The first one is allowed to pass as shown in the action field, but what happened to the second one?

6

That should be the same packet and anomaly detection enabled shouldn’t drop as well.

7

In this case, do you have any ideas how to write a rule to drop these kinds of packets, the anomaly ones as I showed?

8

No, IMHO this feature is not intended to harshly drop packets since an anomaly can be seen with a lot of valid packets as well. It should be just an additional indicator.

9

In fact one of my systems was compromised by a Mirai botnet and when I checked the log of Suricata, I noticed it sent a lot of packets to different destinations on port 23.

Following is one of the many log records shown in the eve.json. It is the only information that was recorded, no payload, etc only tcp information. This reminded me of the question that I asked earlier, what is that flow event type? The flow event was recorded after the packet was processed and sent to the destination already?

Can I use any information below to write a new rule to drop/block these packets? I checked there was already a rule that targets Mirai botnet, but apparently Suricata did catch any on my system. FYI, I changed this rule from alert (original action) to drop.

drop tcp $HOME_NET any -> $EXTERNAL_NET 23 (msg:"ET SCAN Behavioral Unusually fast outbound Telnet Connections, Potential Scan or Brute Force"; flow:to_server; flags: S,12; threshold: type both, track by_src, count 30, seconds 60; reference:url,www.rapid7.com/nexpose-faq-answer2.htm; reference:url,doc.emergingthreats.net/2008230; classtype:misc-activity; sid:2008230; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

{
  "timestamp": "2022-02-17T08:19:44.237400+0100",
  "flow_id": 1566494677995330,
  "event_type": "flow",
  "src_ip": "redacted",
  "src_port": 22471,
  "dest_ip": "redacted",
  "dest_port": 23,
  "proto": "TCP",
  "flow": {
    "pkts_toserver": 1,
    "pkts_toclient": 0,
    "bytes_toserver": 40,
    "bytes_toclient": 0,
    "start": "2022-02-17T08:18:43.986946+0100",
    "end": "2022-02-17T08:18:43.986946+0100",
    "age": 0,
    "state": "new",
    "reason": "timeout",
    "alerted": false
  },
  "tcp": {
    "tcp_flags": "02",
    "tcp_flags_ts": "02",
    "tcp_flags_tc": "00",
    "syn": true,
    "state": "syn_sent"
  }
}
10

This rule will only trigger when the requests to a target are fast enough.

Just the plain flow might not be enough but parts of it could help like the target IP maybe. Ideally you catch a dump and can match on other patterns.