Help understanding UDP flows and alerting

[noob_17]

Hello,

I already had the opportunity to expose this doubt here in the forum but the answer I got was not clear enough.

Moreover, I also discussed this matter (by private message) with @jufajardini who helped me in some sense and suggested I should expose this doubt again in the general forum.

So the doubt arose around this rule:

alert udp $EXTERNAL_NET any → $HOME_NET 5060 (msg: "ET VOIP INVITE Message Flood UDP"; content: "INVITE"; depth:6; threshold: type both , track by_src, count 100, seconds 60; reference:url,[doc. emergingthreats.net/2009698;](http://doc.emergingthreats.net/2009698;) classtype:tryted-dos; sid:2009698; rev:1; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

I am aware that this rule throws an alert whenever the number of packets “INVITE” exceeds 100 within 1 minute.

However, checking the alerts, I notice that the number of packets is always 1:

{"timestamp":"2022-05-26T13:03:02. 367332+0100","flow_id":1139748701117156,"in_iface":"enp2s0f1","event_type":"alert","vlan":[x],"src_ip":"x","src_port": 5218,"dest_ip": "x", "dest_port":5060, "proto": "UDP", "community_id": "1:l+MotXIB6yBwded2+MzymYVNPus=", "alert":{"action": "allowed", "gid": 1, "signature_id": 2009698, "rev":1, "signature": "ET VOIP INVITE Message Flood UDP", "category": "Attempted Denial of Service", "severity": 1, "metadata":{"created_at":["2010_07_30"], "updated_at":["2010_07_30"]}}, "sip":{"method": "INVITE", "uri": "sip:100@x", "version": "SIP/2. 0","request_line":"INVITE sip:100@x SIP/2.0"},"app_proto":"sip","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":435,"bytes_toclient":0,"start":"2022-05-26T13:03:02.367332+0100"}"stream":0

@jufajardini suggested that

“since we are dealing with UDP here, and these are ‘INVITE’ packets, I think Suri might consider each new packet to be part of a new stream, since Suri will only consider a UDP stream to be established after there are packets flowing in both directions. What I think is happening is that Suri is detecting a lot of traffic like that, but the threshold causes you to only see very few alerts. If the destination changes, that is considered something new, since you are tracking by src, right, so these will trigger if Suri sees 100 within 60 seconds, if I remember the rule correctly.”

One way to test this is to create a similar rule, but changing the threshold variables, and see how that affects the alerts it sees. If you don’t use both types, but type threshold, maybe you see more alerts/packets for the same stream?

After testing the proposed solution, the problem remained. The alerts only show up 1 "packet_toserver". I cannot understand why this is happening and would appreciate an explanation if this is normal behavior

Sorry for the long post.

[bsmith (Bryant Smith)]

@noob_17 Are you testing the rule with a pcap or live traffic generating the “INVITE” request continuously? My first thought is that it may be because you are using threshold of type both which will generate 1 alert when you reach 100 in 60 seconds and then stop. If the pcap or traffic never reaches the second count of 100 in 60 seconds then you won’t get another alert, just the first one.

Also, can you provide a pcap and I can try and play with the signature a bit?

[noob_17]

@bsmith Thank you for your reply.

`

My first thought is that it may be because you are using threshold of type both which will generate 1 alert when you reach 100 in 60 seconds and then stop

`

I get this point, the alert is generated after reaching 100 in 60 seconds. But my question is not related to the amount of alerts itself. My question has to do with the fact that we can see in the alert that the number of packets is “1”. So, if the alert is generated after detecting 100 or more packets in 60 seconds, why does my alerts only show 1 “network packet” in the logs.

[bsmith (Bryant Smith)]

I think @jufajardini is correct in that Suricata may be treating each UDP packet as part of a new stream. I looked at some UDP alerts I have and they all have 1 packet whereas my TCP alerts have a more appropriate number of packets to server and client.

[noob_17]

Thank you for your reply. Do you think there is a possible solution to this “problem”?

[bsmith (Bryant Smith)]

The only solution I can think of is to calculate it yourself using the alert data and flow data. Might be difficult to do since the request may be incrementing the source ports, so using a 5-tuple wouldn’t match up. I can use Brim to calculate it. This may not be a solution for you though. There also maybe something you can do with Lua scripting and create the output logs you’d need. Otherwise you may have to infer the amount of packets. Since only 1 will trigger every 100 attempts in 60 seconds, you know there’s at least that number but it could be higher.

For each INVITE request, does the source port change?

[noob_17]

I believe not. it is getting really confuse to understand this