When Fail2ban Fails to Ban - Dissecting the Hack

Most of the time when I review our log watches each morning I become enraged at the number of automated attacks,

But ever so occasional I find one that frankly intrigues me.

Today is just such an occasion where I have had multiple Brute force login attempts, the ingenious part is this attack has been designed to bypass tools such as fail2ban, blockhosts etc, and this is how

  1. Attack is launched from XXX.XXX.XXX.XXX
  2. has PTR set for sub.domain.tld
  3. Failed login attempts record sub.domain.tld due to reverse lookup
  4. There is no A record, attacker maintains their own nameservers for the domain.tld
  5. fail2ban notes failed logins, attempts to resolve sub.domain.tld to an IP but fails, due to missing A record
  6. Attacker can continue brute force attempts unhindered by being banned

I am still reading into how to counter this and will update this post as I figure out how to work around it, it’s a very sneaky and frankly quiet clever method of working around most automated blacklisting/banning tools.

Update 1: One method I am trialing is the “log target” feature of iptables, in an attempt to match login failure times to the iptables log, I’ll post back with results.

iptables -A INPUT -p tcp --dport ftp -j LOG

Outputs

Jul 23 11:45:57 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=47423 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 SYN URGP=0 
Jul 23 11:45:57 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=45370 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK URGP=0 
Jul 23 11:45:57 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=46896 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK URGP=0 
Jul 23 11:46:01 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=63 TOS=0x00 PREC=0x00 TTL=55 ID=38502 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK PSH URGP=0 
Jul 23 11:46:02 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=32551 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK URGP=0 
Jul 23 11:46:02 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=59735 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK URGP=0 
Jul 23 11:46:04 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=66 TOS=0x00 PREC=0x00 TTL=55 ID=23116 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK PSH URGP=0 
Jul 23 11:46:07 132 kernel: IN=eth0 OUT= MAC=<mac addr> SRC=<connecitng ip> DST=<server ip> LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=40246 DF PROTO=TCP SPT=3865 DPT=21 WINDOW=65535 RES=0x00 ACK URGP=0

Update 2: Defeating the hack

Now granted this would be a lot worse had the attacking IP been dynamic, fortunatly in this case it’s not

grep kernel /var/log/messages | awk '{print $9}' | sed 's/SRC=//' | uniq -c | sort

390   173.XXX.XXX.XXX
      4 195.XXX.XXX.XXX

Ip’s have been masked to prevent anyone complaining or threatening legal action (again) for inferring you should block their ip / network range … and me firing off the obligatory “Well if you policed your own network I wouldn’t have to post this no would I” email,

Maybe I am just being Cynical in my “old” age …

Any how as you may have guess I’m black holing the ip with the 390 connection entries.

Thanks

Being as I spoke to a load of people during the course of this I realy can not remember who contributed what to this solution, so I’ll just have to thank you all let me know if you want a crediting link.

Comments