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@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
On 07/21/2018 03:48 AM, Leon Fauster via CentOS wrote:
Am 20.07.2018 um 18:52 schrieb Nataraj incoming-centos@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.disabled
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 https://www.google.com/search?client=ubuntu&channel=fs&q=mysql+possi...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I would still use tcpdump and/or wireshark to find out more what is going on and if all the incoming connections seem correct, you may have to tune some parameters to allow a greater number of connections. Also, if you have iptables connection tracking turned on, this might need to be bypassed for connection on your database port. Connection tracking does not always work well for large numbers of connections. But check to see weather one or more clients are somehow failing to connect and retrying the connection at a high rate for some reason.
Also Try https://www.google.com/search?client=ubuntu&channel=fs&q=mysql+possi...
and maybe this:
https://help.marklogic.com/Knowledgebase/Article/View/182/0/possible-syn-flo...
Nataraj
-
Leon Fauster -
Nataraj