Rule 2210008 - help interpreting results

Rules
1

Dear Suricata community,

I have activated the stream events rules (I know I shouldn’t because of many false positives), and I get tons of these results:

09/09/2020-05:09:53.894356  [**] [1:2210008:2] SURICATA STREAM 3way handshake SYN resend different seq on SYN recv [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 51.91.21.58:443 -> 188.44.77.158:443
09/09/2020-03:53:02.482568  [**] [1:2210008:2] SURICATA STREAM 3way handshake SYN resend different seq on SYN recv [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 187.193.226.34:53 -> 188.44.77.158:443
09/09/2020-00:04:15.761328  [**] [1:2210008:2] SURICATA STREAM 3way handshake SYN resend different seq on SYN recv [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 74.91.124.9:30120 -> 188.44.77.158:443
09/08/2020-22:37:00.559047  [**] [1:2210008:2] SURICATA STREAM 3way handshake SYN resend different seq on SYN recv [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 172.248.68.59:80 -> 188.44.77.158:443
09/08/2020-14:17:07.687170  [**] [1:2210008:2] SURICATA STREAM 3way handshake SYN resend different seq on SYN recv [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 185.239.242.248:3389 -> 188.44.77.158:443

(just a few examples, many rule hits for each IP).

It’s not that I’m shocked by the large number of rule hits (as I said, I’m aware that there can be lots of false positives). But what’s striking me is the source port - this doesn’t look like normal traffic; why should a connection to my https port come from these well-known ports? And the source ports are almost systematically well-known.

So I wonder what this means - could it be part of something like a ddos scheme - trying to provoke a reply to the (spoofed?) source IP? Does it make sense that in such a case that specific rule is triggered (I only get hits for this one rule). Might it be an idea to turn that rule into a drop rule?

Oh, and it’s only ports 80 and 443, although there are other open ports.

Thanks for any hints!

2

This is an example how a conversation looks like:

# tcpdump -ASs 0 -n -i eth0 host 163.172.219.92 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:27:47.252806 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 164781189, win 5840, length 0
E..(........g7.
...\.P.P	.\.....P.............
19:27:47.253317 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
19:27:47.262562 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 1010212639, win 5840, length 0
E..(........g7.
...\.P.P<6......P...G.........
19:27:47.308535 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 663114706, win 5840, length 0
E..(h.......g7.
...\.P.P'.S.....P.............
19:27:47.365740 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 544015977, win 5840, length 0
E..(.L.....8g7.
...\.P.P m.i....P....Q........
19:27:47.447113 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 1971776976, win 5840, length 0
E..(D.......g7.
...\.P.Pu.......P.............
19:27:47.511418 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 378824576, win 5840, length 0
E..(.B.....Bg7.
...\.P.P..g.....P.............
19:27:47.752028 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 1955699401, win 5840, length 0
E..(	4....CQg7.
...\.P.Pt.......P.............
19:27:48.263504 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
19:27:48.444335 IP 103.55.143.10.80 > 163.172.219.92.80: Flags [S], seq 1755919768, win 5840, length 0
E..(......D.g7.
...\.P.Ph.5.....P.............
19:27:50.279496 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
19:27:54.471514 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
19:28:02.663414 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
19:28:18.791514 IP 163.172.219.92.80 > 103.55.143.10.80: Flags [S.], seq 1470621328, ack 164781190, win 64240, options [mss 1460], length 0
E..,..@.@......\g7.
.P.PW...	.\.`...........
3

What of those IPs are yours?

I did a small host check on the IPs on your first post on the left side, some seem to be dynamic IPs for ISPs. So it could be some DOS attempt.

4

My IPs are 188.44.77.158 in the first and 163.172.219.92 in the second post. These are from two different servers that show the same phenomenon.

But against who? I don’t think it can be against me, because the amount of traffic is not enough for that.

5

Hmm DOS wasn’t the right term it’s maybe just random garbage that might be embedded in some scripts. Might becoming interesting if there is some specific pattern in the payload but for know I would see it as attempts that won’t succeed.

6

Thank you for these insights! So I assume that it’s nothing too serious, I will try setting it as a drop rule and see whether it creates problems.

7

After a few days, the drop rule did not seem to create any problems. So I’ll keep it this way and consider the question solved. Thanks again!