0

I have a Centos7 server and after years of correctly working, yesterday it started to being unreachable (The server apps I have there were not rechable, the SSH connection gave timeout, etc but the ping worked).

Yesterday it get unreachable, and the only workaround is to stop it and start it again. But after one hour o less, the same happends.

After some research it could be that is because of a SYN flood attack.

Checking the connection logs I see that there are several login attempts, for example:

Jan 26 08:18:08 vsi-prod sshd[2691]: Invalid user aadil from 190.153.249.99 port 59598
Jan 26 08:18:08 vsi-prod sshd[2691]: input_userauth_request: invalid user aadil [preauth]
Jan 26 08:18:08 vsi-prod sshd[2691]: Received disconnect from 190.153.249.99 port 59598:11: Bye Bye [preauth]
Jan 26 08:18:08 vsi-prod sshd[2691]: Disconnected from 190.153.249.99 port 59598 [preauth]
Jan 26 08:18:12 vsi-prod sshd[2695]: Invalid user db2fenc2 from 143.110.241.56 port 54456
Jan 26 08:18:12 vsi-prod sshd[2695]: input_userauth_request: invalid user db2fenc2 [preauth]
Jan 26 08:18:13 vsi-prod sshd[2695]: Received disconnect from 143.110.241.56 port 54456:11: Bye Bye [preauth]
Jan 26 08:18:13 vsi-prod sshd[2695]: Disconnected from 143.110.241.56 port 54456 [preauth]

I disable the port 22 but the issue keeps happening.. Also the request are to port that should be closed (I double checked).

I tried to generate a rate limiter through iptables but it didnt' work neither

sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit 5/minute --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name ssh-limit -j ACCEPT

And lastly, I create the somaxconn but the issue is still there...

net.core.somaxconn = 1024

Is there a suggestion about how to fix it? which setup/tool do I need to do to avoid this scenario?

1
  • 2
    The sshd logs show evidence of the normal background noise of the internet with non-stop abuse attempts ; the fact that there's enough ssh protocol that your sshd can log (invalid) usernames means that that is also not a SYN flood attack and those events are probably a red-herring with regards to troubleshooting your current issue. Second a common mistake is that using iptables -A appends rules at the end of the chain, where they may have little to no effect in combination with the already existing rules in that chain.
    – HBruijn
    Commented Jan 26 at 12:16

1 Answer 1

0

(this should be a comment - but too long / comments don't formatting)

that is because of a SYN flood attack

Are you sure? How did you determine this? Did you check if syn cookies is turned on?

I see that there are several login attempts

Welcome to the internet. I presume you know that these are probably not related to a syn flood. See Tips for coping with a surprisingly high rate of "botnet" sshd login failures?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .