Generic Protocol Command Decode

Help
1

Have just set up a new sensor with 10G intel NICs running 6.0.1 and I am seeing lots of STREAM and TLS decode events. I then found the docs on nic_setup and worked my way though all the steps (bar installing latest drivers and ethtool because I don’t have build tools on my sensors).

from evebox for the last hour (traffic is very light):

Signature
21414 SURICATA Applayer Detect protocol only one direction
10331 SURICATA STREAM Packet with invalid timestamp
7750 SURICATA STREAM 3way handshake SYNACK with wrong ack
6654 SURICATA STREAM Packet with invalid ack
6256 SURICATA STREAM ESTABLISHED SYN resend with different seq
5965 SURICATA STREAM 3way handshake SYN resend different seq on SYN recv
5417 SURICATA STREAM ESTABLISHED invalid ack
4275 SURICATA STREAM 3way handshake wrong seq wrong ack
2784 SURICATA STREAM ESTABLISHED packet out of window
2655 SURICATA TLS certificate invalid subject
2

I use those STREAM events mostly for debugging tasks, since they fire quite a lot on production environments where you just have to deal with broken traffic that would trigger such rules.
The applayer one indicates that there is unidirectional traffic which makes it rather difficult to analyze.

So if you want those gone, either disable them for production or try to narrow down the broken traffic which might be lot of work and most of the times hard to fix :slight_smile:
Although fixing unidirectional might be just some config issue on the mirror port for example.

1 Like
3

What Suricata version are you using? Which platform?

4

6.0.1 on linux.

I have now tried to suppress these alerts by setting

evelog[types][anomaly][enabled] to ‘no’

but this has no effect?

I would still like to know what sort of numbers I should expect – the link is 10Gbps and normally runs at about half capacity but at the moment it is nearly empty. Sane folk are on leave (as I am ; )

5

The anomaly switch will disable only those anomaly logging events (not the rules/alerts).
If you want to disable the STREAM alerts , they are usually distributed with Suricata -

So you can just disable those (with suricata-update for example).

You still have the counters for those though in stat.log/eve.json

6

I want to disable all protocol-commande-decode rules.
I added this line in “disable.conf” :
re:classtype:protocol-command-decode
I see that it does the job since I do not see anymore these alerts.
But I am not sure if this is the perfect way to handle this, so I would appreciate your advices.

7

an alternative is
re: stream_event

I found one stream event rule that did not have the category set…

8

I get this very broken tcpdump trace (see below). My server (10.10.200.164) dutifully replies to the SYNs to an obvious broken or malicious client (75.183.234.180) that is using source port 80.
My question is why is Suricata alerting with resend with different acks?
As you can see, ACKs seem legitimate; Is suricata getting confused by the source port being 80?

03/10/2021-19:56:43.704523 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:56:48.730139 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:56:48.730480 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:56:52.770404 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:57:00.117941 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:57:13.101787 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:57:57.633964 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:57:57.634433 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:58:02.102512 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:58:02.102624 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:58:10.943018 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80
03/10/2021-19:58:28.850221 [] [1:2210004:2] SURICATA STREAM 3way handshake SYNACK resend with different ack [] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 10.10.200.164:443 → 75.183.234.180:80

19:56:40.665825 IP 75.183.234.180.80 > 10.10.200.164.443: Flags [S], seq 714790283, win 5840, length 0
19:56:40.665922 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:56:41.866019 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:56:43.866037 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:56:47.866028 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:56:56.066022 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:57:12.066018 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 1131111674, ack 714790284, win 26883, options [mss 8961], length 0
19:57:50.860042 IP 75.183.234.180.80 > 10.10.200.164.443: Flags [S], seq 215330200, win 5840, length 0
19:57:50.860141 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0
19:57:52.061983 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0
19:57:54.062018 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0
19:57:58.062016 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0
19:58:06.061998 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0
19:58:22.262031 IP 10.10.200.164.443 > 75.183.234.180.80: Flags [S.], seq 2227896315, ack 215330201, win 26883, options [mss 8961], length 0

9

Actually, I see this behavior also when the source port seems legitimate. But still can’t explain why suricata thinks the ack in the synack is bad…

10

Are you also seeing this when the TCP session isn’t being reused (so unique 5 tuple)? Can you share a pcap?

11

test2.pcap (4.2 KB)

12

BTW, testing on Suricata was very helpful in finding a couple of minor bugs in our TLS mirror. Now the SSL mirror is completely transparent to Suricata’s TCP stream decoder.
We use dummy0 for replaying packets locally because dummy0 can be set to a large MTU of 65536 with no repercussions. This allows to capture packets from servers with large MTUs and pcap over TCP becomes more efficient for SSL mirroring.
I am able to get it to work with:
suricata -k none -c /etc/suricata/suricata.yaml --pcap=dummy0
but if set the config to:
pcap:
interface: dummy0
and completely comment out af-packet and then execute:
suricata -k none -c /etc/suricata/suricata.yaml -i dummy0
Seems like Suricata still tries to use af-packet and I get these errors:
11/3/2021 – 23:19:08 - - [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Frame size bigger than block size
11/3/2021 – 23:19:08 - - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn’t init AF_PACKET socket, fatal error
11/3/2021 – 23:19:08 - - [ERRCODE: SC_ERR_FATAL(171)] - thread W#01-dummy0 failed

Ultimately, I would like to be able to do:

suricata -k none -c /etc/suricata/suricata.yaml -i eth2 -i dummy0
using AF packet or PF_RING for eth2 and pcap for dummy0
is there a way to do this?

13

No, you can only use a single capture method at a time. So if you need to use libpcap you would use --pcap. Untested: --pcap=eth2 --pcap=dummy0.

14

That works. I verified that I can also replay to eth2 so that everything is on one interface. The only thing is that eth2 needs to have sufficiently large MTU.