0

Right now netstat lists 200 - 4000 connections to the same IP in India. Seems like some kind of flooding attack to me.

e.g:

tcp        0      0 [removed] 182.65.238.[removed].in-:mysql TIME_WAIT

I've tried to kill current connection with this command but this didn't work

iptables -t filter -I INPUT 1 -p tcp -m tcp -s 182.65.238.[] -j DROP

tcpkill -i any -9 host 182.65.238.[removed]

I've added the IP to ufw and even ban it with fail2ban but I cannot get rid of the open connections.

Two Questions:

  1. how to kill/close all tcp connections from this IP
  2. any chance of logging this kind of pattern in order do ban it with a fail2ban jail or set up some iptable chain limitions like for "regular" dos attacks?

systeminfo:

  • ubuntu 20.04
  • nginx
  • ufw
  • fail2ban
  • syn cookies enabled
  • maybe relevant: additional ufw rules I'm using
# Enter rule
-A ufw-before-input -p tcp --dport 80   -j ufw-http
-A ufw-before-input -p tcp --dport 443  -j ufw-http

# Limit connections per Class C
-A ufw-http -p tcp --syn -m connlimit --connlimit-above 50 --connlimit-mask 24 -j ufw-http-logdrop

# Limit connections per IP
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --set
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --update --seconds 10 --hitcount 20 -j ufw-http-logdrop

# Limit packets per IP
-A ufw-http -m recent --name pack_per_ip --set
-A ufw-http -m recent --name pack_per_ip --update --seconds 1  --hitcount 20  -j ufw-http-logdrop
jan
  • 1
  • 1
  • 2
    Why do you have MySQL listening on a public interface? – vidarlo Aug 09 '22 at 09:41
  • @vidarlo thx - how do you see that? There is a mysql version installed but not running! Could this be a problem? How to fix it then? Doesn't ufw take care of open/listening ports? Current settings: UFW 22/tcp ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH ALLOW Anywhere 143 ALLOW Anywhere 587 ALLOW Anywhere 25 ALLOW Anywhere 993 ALLOW Anywhere – jan Aug 09 '22 at 10:08
  • 1
    @vidarlo double-checked with "netstat -tulpn | grep LISTEN" and there is no 3306 open or mysql listening. – jan Aug 09 '22 at 11:06
  • Rogue connection attempts or scans should be (silently) dropped at the outmost perimeter - either the WAN firewall or the WAN switch, if present. – Zac67 Aug 09 '22 at 12:15
  • @Rogue thank you for your comment, which makes sense but I still don't know how to implement your general advice and how to kill the present tcp connections. I Also don't understand why you guys are thinking that the mysql ports are listening, the mysql port is used on the remote and not local site... – jan Aug 09 '22 at 12:30
  • btw ss | grep 182.65.238.[removed] doesn't find any connections at all...confuses me totally – jan Aug 09 '22 at 12:33
  • If the connections originate from your server, and your applications are not using that server, then it means your server is likely compromised and you should act according to https://serverfault.com/questions/218005/how-do-i-deal-with-a-compromised-server – Tero Kilkanen Aug 09 '22 at 18:26
  • for http/https for anykind of linux woudl be `fail2ban` the first option – djdomi Aug 09 '22 at 18:54
  • @TeroKilkanen and djomi, what's the point in commenting without even reading the post? Yeah fail2ban is running - like I said and no it's not from my server as I also mentiond in my post. – jan Aug 09 '22 at 19:30
  • How have you determined that the origin is not your server? DDoS attacks typically target open services on the Internet, and the destination of the connection is MySQL port, so this matches a DDoS where the target is the remote MySQL instance. There is no point for someone to try a DoS attack from a fixed IP address and port to your server, since that is trivial to block. Based on the information you have presented, server compromise looks most likely to me. – Tero Kilkanen Aug 09 '22 at 20:24
  • To better understand the issue, add the output of `ss -npt` to your question, which shows the processes related to these connections. If they are not visible in `ss`, that is another indicator of a compromised system. Please also clarify where did you obtain the first example in your question, what tool etc. – Tero Kilkanen Aug 09 '22 at 20:28
  • @TeroKilkanen I've underestimated the effort you've put into your answer, I apologize for that. I used `netstat -anp` for my first output. `ss -npt` does not show theses connections. The Remote Host Ip is listet on 4 Blacklists by the way. Can you explain the syntax of 182.65.238.[removed].in-:mysql what does the **.in-** mean? I couldn't find anything in the manpage or google... – jan Aug 09 '22 at 21:07
  • It is the reverse DNS entry of the IP address. `.in` is the top-level domain of India, which means that the IP address is most likely located in India. – Tero Kilkanen Aug 10 '22 at 17:14

0 Answers0