Saiweb

For some background you may want to read the Original Story leading to this write up.

The first thing that caught my attention was the fact Logwatch was reported login failures in the order of 1000′s from unassigned.psychz.net without an accompanying fail2ban email notifying me the offender had been banned.

And this as it would turn out was because the attack was clearly intended to defeat such protection methods, this is due to the logged host being unassigned.psychz.net, when the authentication failure is logged, a reverse lookup is made within vsftpd to resolve the host this PTR record returns unassigned.psychz.net, and as such is written into the log.

fail2ban no uses regex to extract the host from the logs, and attempts to make a forward lookup on unassigned.psychz.net (A/CNAME records required) to resolve the ip address, and ban the offending ip, this is where things go awry.

psychz.net maintains their own DNS servers,

1. DNS1.PSYCHZ.NET
2. DNS2.PSYCHZ.NET

These provide a PTR but no A/CNAME record, as such fail2ban can not resolve an IP and the attacking ip is left to run their attack unhindered, see this log file: fail2ban name resolution failure log

The only way therefor to gain the attacking ip was to match the ftp connection times to those of the reported login failures using iptables to log all accesses to ftp, quickly get a count of connecting ip’s using:

A complete log can be found here: iptables.log, and a whois can be found here: whois.txt

Disclosure steps taken:

1. 26/07/10 psychz support informed given deadline of 09/08/10 for resolution
2. Same day standard reply of “thanks for contacting support we are looking into this” …
3. 27/07/0 Attacks continue 173.224.208.0/20 network black holed as a result

   1	iptables -A INPUT -s 173.224.208.0/20 -j DROP

4. 09/08/10 deadline passes without update
5. 25/08/10 this blog post published

Tweet

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
2. has PTR set for
3. Failed login attempts record due to reverse lookup
4. There is no A record, attacker maintains their own nameservers for the
5. fail2ban notes failed logins, attempts to resolve 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.

Outputs

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

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.

Tweet

Again this is a late blog post about some code committed several months ago, in this case the code was committed 09/06/2009

It is a very short python script to force a subversion commit message to be greater than 10 characters in length

Installation:

svn export http://svn.saiweb.co.uk/branches/python/svn_force_message.py /path/to/your/svn/hooks/pre-commit
chmod +x /path/to/your/svn/hooks/pre-commit

Note installation this way will replace your current pre-commit hooks file.

Tweet