Lots of connections in SYN_RCVD?

Bobi B.

Bobi B.

Greetings, All!

Last few days I've noticed there are lots of connections to my box stuck in SYN_RCVD:

Code: 
root@bb:~ # netstat -4n
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 192.168.0.245.80       167.114.41.148.42781   SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.6393    SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.62556   SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.29530   SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.56068   SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.27180   SYN_RCVD
tcp4       0      0 192.168.0.245.80       167.114.41.148.36199   SYN_RCVD
...
... more of the same following, up to about 60. Foreign addresses rotate from a pool of about 15 addresses, several of which are grouped in few /24s, others are seemingly unique (this data is collected in about half on hour via observation and shell one-liners, so it might be incorrect). Each host opens 50-60 connections, after they disappear the next one starts. Nothing unusual in web server's logs, apart from standard garbage.

The box is a small personal server running a handful of jails, including a personal web site, hid behind a pf(4) (the machine is directly connected to the Internet 24/7).

The funny thing is I've noticed this since network LED usually doesn't blink that much. Any idea what is this and if or what should I do about it? Thanks!
 
Looks like syn flood attack. You can reduce your tcp_syn_age in IPFW and use limit src-addr rule to reduce the maximum amount of simulation connections per IP.
 
I noticed the same thing but since the maximum I'm seeing is well below what my web server can handle, I'm just monitoring in case it gets worse.
 
This is attack against me (why? nothing significant running on this machine) or they are using my box to attack someone else (amplification attack)? So, basically, I cannot mitigate this kind of attack completely?
 
It's not necessary to be an attack as it's originating only from the same ip range. It bay be cause also from mis configured routing or firewall that block your traffic to this network. In the TCP 3-way handshake you receive the syn packet then your site reply with syn-acknowledgment but the client never receive it because of missing route or blocking firewall or it receive it but didn't respond with ack.

The ip address that you report is also reported in ipdb as DoS attacker from other users so it may be a zombie computer. The proper way is to contact the owner of that CIDR range at abuse@ovh.ca and noc@ovh.ca and report this.

DoS attack: TCP SYN Flood] attack packets in last 20 sec from ip [167.114.41.148], Monday, Oct 01,2018 20:22:08
[DoS attack: TCP SYN Flood] attack packets in last 20 sec from ip [167.114.41.148], Monday, Oct 01,2018 20:21:46
[DoS attack: TCP SYN Flood] attack packets in last 20 sec from ip [167.114.41.148], Monday, Oct 01,2018 20:20:58

https://www.abuseipdb.com/check/167.114.41.148
 
Originating addresses are in several /24s, some of which are quite far apart, and there are/were unique addresses as well.

Also traffic is inbound, to the local web server, not outbound. Besides there is nothing that interesting on the site to cause such a flood :-)

As I wrote, I use pf(4), not ipfw(8), but I'll take a look at man pages.

Thank you for the pointers.
 
Bobi B. said:
This is attack against me (why? nothing significant running on this machine) or they are using my box to attack someone else (amplification attack)?
Click to expand...
Nine times out of ten those are bots looking for easy ways in. Nothing more, nothing less.

Bobi B. said:
Besides there is nothing that interesting on the site to cause such a flood
Click to expand...
Bots don't care about your site or what's on it. All they care about is getting a foot in the door so they can use your system to attack others. The source address is most likely some poor guys website that got broken into (the foot in the door) by a bot running on somebody else's broken website.
 
SirDice said:
Nine times out of ten those are bots looking for easy ways in. Nothing more, nothing less.
Click to expand...
Okay, bots looking for an unlocked doors are 24/7, I agree. But how would a SYN flood help their case? I mean, I kind-a miss what's the point of doing SYN flood, apart from when making a DoS attack, which seems rather pointless considering what the target is.
 
Bobi B. said:
Okay, bots looking for an unlocked doors are 24/7, I agree. But how would a SYN flood help their case?
Click to expand...
A lot of these bots are quite buggy. I've seen bots do requests containing literal variables instead of the content of the variable, but also some really brain dead connection code and whatnot. So I wouldn't be surprised if the bot does stupid things.

But it could be some feeble attempt at a (D)DoS by somebody that clearly doesn't quite understand how a (D)DoS actually works.
 
All states have a timeout, but I can't find where this is documented. I know it's somewhere.
 
syncookies(4)

rexmtlimit

Maximum number of times a SYN,ACK is retransmitted before being discarded. The default of 3 retransmits corresponds to a 45 second timeout, this value may be increased depending on the RTT to client machines. Tunable via sysctl(3).
 
My jail was suffering this SYN_RCVD attack.
Almost 200 syn zombie connections and increasing...

Also my natd process was consuming a lot of cpu process in top and increasing % a lot.

Code: 
# netstat -an | grep 10.0.0.XXX | grep SYN_RCVD
tcp4 0 0 10.0.0.XXX.443 179.191.168.95.37727 SYN_RCVD
tcp4 0 0 10.0.0.XXX.443 179.191.168.171.18314 SYN_RCVD
tcp4 0 0 10.0.0.XXX.443 179.191.168.110.21927 SYN_RCVD
tcp4 0 0 10.0.0.XXX.443 179.191.168.165.19538 SYN_RCVD
...
..
.


What I did:
1 ) Create a Table in my ipfw then add a rule to deny IPs in this table: deny ip from "table(10)" to me
2 ) run a script to add all zombies IPs that is flooding with SYN_RCVD to this table in ipfw


Bash: 
#!/bin/csh

foreach IP (`netstat -an | grep 10.0.0.XXX | grep SYN_RCVD | awk '{split($5, a, "."); print a[1]"."a[2]"."a[3]"."a[4]}' | sort | uniq`)
        echo "BLOCK $IP"
       
        if !( { grep -q $IP /root/block/syncBlock.txt } ) then
                echo "$IP" >> /root/block/syncBlock.txt
               ipfw table 10 add $IP
        else
                echo "$IP already exists"
        endif
end


After some minutes the syn_rcvd attack stopped.
My natd back to normal
 
You must log in or register to reply here.
Back
Top