CentOS - Jul 2018 - database node / possible SYN flooding on port 3306

Hi folks,

I have here a database node running

# rpm -qa | grep mysql-server
mysql55-mysql-server-5.5.52-1.el6.x86_64

on

# virt-what 
vmware


that seems to have a connection problem:

# dmesg |grep SYN |tail -5
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.
possible SYN flooding on port 3306. Sending cookies.


I adapted already following:

# sysctl -a |grep -E 'maxconn|syn_backlog'
net.core.somaxconn = 2048
net.ipv4.tcp_max_syn_backlog = 2048


but ListenOverflows and ListenDrops values are still high
 
# cat /proc/net/netstat | awk '{print $21 "-" $22 }'
ListenOverflows-ListenDrops
13568-13568

any suggestion? 

--
Thanks,
LF

On 07/20/2018 03:56 AM, Leon Fauster via CentOS wrote:
> Hi folks,
>
> I have here a database node running
>
> # rpm -qa | grep mysql-server
> mysql55-mysql-server-5.5.52-1.el6.x86_64
>
> on
>
> # virt-what 
> vmware
>
>
> that seems to have a connection problem:
>
> # dmesg |grep SYN |tail -5
> possible SYN flooding on port 3306. Sending cookies.
> possible SYN flooding on port 3306. Sending cookies.
> possible SYN flooding on port 3306. Sending cookies.
> possible SYN flooding on port 3306. Sending cookies.
> possible SYN flooding on port 3306. Sending cookies.
>
>
> I adapted already following:
>
> # sysctl -a |grep -E 'maxconn|syn_backlog'
> net.core.somaxconn = 2048
> net.ipv4.tcp_max_syn_backlog = 2048
>
>
> but ListenOverflows and ListenDrops values are still high
>  
> # cat /proc/net/netstat | awk '{print $21 "-" $22 }'
> ListenOverflows-ListenDrops
> 13568-13568
>
> any suggestion? 
Use tools like tcpdump/wireshark? and further examination of logfiles to
determine where your attack is coming from, i.e. single IP address or
multiple ip addresses (BOT attack).

If attack is impairing your Internet service, contact your ISP.? Most
decent ISP's should deal with this situation for you.

If attack is not impairing your service and you choose to deal with it
yourself, then, if from a fixed IP address block that IP from your
firewall if you have one, otherwise, use IPtables on the server.? If
your having bot attacks, or blocking attack causes source IP address to
be changed, then look at fail2ban.? Basically you want to configure
fail2ban to limit the number of requests per unit of time and block IPs
that exceed that.? Also, consider weather your database needs to be
publicly accessible from the Internet.

Nataraj

> Am 20.07.2018 um 18:52 schrieb Nataraj <incoming-centos at rjl.com>:
> 
> On 07/20/2018 03:56 AM, Leon Fauster via CentOS wrote:
>> Hi folks,
>> 
>> I have here a database node running
>> 
>> # rpm -qa | grep mysql-server
>> mysql55-mysql-server-5.5.52-1.el6.x86_64
>> 
>> on
>> 
>> # virt-what 
>> vmware
>> 
>> 
>> that seems to have a connection problem:
>> 
>> # dmesg |grep SYN |tail -5
>> possible SYN flooding on port 3306. Sending cookies.
>> possible SYN flooding on port 3306. Sending cookies.
>> possible SYN flooding on port 3306. Sending cookies.
>> possible SYN flooding on port 3306. Sending cookies.
>> possible SYN flooding on port 3306. Sending cookies.
>> 
>> 
>> I adapted already following:
>> 
>> # sysctl -a |grep -E 'maxconn|syn_backlog'
>> net.core.somaxconn = 2048
>> net.ipv4.tcp_max_syn_backlog = 2048
>> 
>> 
>> but ListenOverflows and ListenDrops values are still high
>> 
>> # cat /proc/net/netstat | awk '{print $21 "-" $22 }'
>> ListenOverflows-ListenDrops
>> 13568-13568
>> 
>> any suggestion? 
> 
> Use tools like tcpdump/wireshark  and further examination of logfiles to
> determine where your attack is coming from, i.e. single IP address or
> multiple ip addresses (BOT attack).
> 
> If attack is impairing your Internet service, contact your ISP.  Most
> decent ISP's should deal with this situation for you.
> 
> If attack is not impairing your service and you choose to deal with it
> yourself, then, if from a fixed IP address block that IP from your
> firewall if you have one, otherwise, use IPtables on the server.  If
> your having bot attacks, or blocking attack causes source IP address to
> be changed, then look at fail2ban.  Basically you want to configure
> fail2ban to limit the number of requests per unit of time and block IPs
> that exceed that.  Also, consider weather your database needs to be
> publicly accessible from the Internet.

Actually the database node is a backend system in a private network, so
"all"
traffic is legitimate. The main traffic comes from the web node (cms/php).
Resources
of the db node seems all to be okay (cpu/mem/load). So i do not see any
bottleneck ...

--
LF