# Lots of connections in SYN_RCVD?



## Bobi B. (Oct 1, 2018)

Greetings, All!

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


```
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!


----------



## VladiBG (Oct 1, 2018)

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.


----------



## ekingston (Oct 2, 2018)

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.


----------



## Bobi B. (Oct 2, 2018)

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?


----------



## VladiBG (Oct 2, 2018)

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


----------



## Bobi B. (Oct 2, 2018)

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.


----------



## SirDice (Oct 2, 2018)

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)?


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


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.


----------



## Bobi B. (Oct 5, 2018)

SirDice said:


> Nine times out of ten those are bots looking for easy ways in. Nothing more, nothing less.


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.


----------



## SirDice (Oct 5, 2018)

Bobi B. said:


> Okay, bots looking for an unlocked doors are 24/7, I agree. But how would a SYN flood help their case?


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.


----------



## CyberCr33p (Mar 21, 2020)

Does a timeout exist for SYN_RCVD state?


----------



## SirDice (Mar 23, 2020)

All states have a timeout, but I can't find where this is documented. I know it's somewhere.


----------



## VladiBG (Mar 23, 2020)

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).


----------

