Greetings,
While doing a random, manual check on my server, I found a brute force attack in progress that had been going on for some time. I have APF and BFD installed - BFD had *tried* to firewall the IP addr, but an apparent bug caused it to put a mal-formed IP addr in the APF deny file. The mal-formed IP addr wasn't accepted by the iptables stuff, so .... BFD thought it was firewalled, APF thought it was firewalled, but it wasn't ... When I found the attack in progress, it had been going on for just over an hour - many, many 1000's of log-in attempts (particularily root).

So, here's what the first few lines of encounter looked like:

Nov 17 22:46:58 plesk sshd[15146]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:46:59 plesk sshd[15145]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:47:01 plesk sshd[15146]: Failed password for root from ::ffff:66.195.205.25 port 40061 ssh2
Nov 18 04:47:01 plesk sshd[15148]: Failed password for root from ::ffff:66.195.205.25 port 40061 ssh2
Nov 18 04:47:01 plesk sshd[15148]: Received disconnect from ::ffff:66.195.205.25: 11: Bye Bye
Nov 17 22:47:01 plesk sshd[15151]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:47:02 plesk sshd[15145]: Failed password for root from ::ffff:66.195.205.25 port 39780 ssh2
Nov 18 04:47:02 plesk sshd[15147]: Failed password for root from ::ffff:66.195.205.25 port 39780 ssh2
Nov 18 04:47:02 plesk sshd[15147]: Received disconnect from ::ffff:66.195.205.25: 11: Bye Bye
Nov 17 22:47:02 plesk sshd[15154]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:47:03 plesk sshd[15151]: Failed password for root from ::ffff:66.195.205.25 port 40172 ssh2
Nov 18 04:47:03 plesk sshd[15152]: Failed password for root from ::ffff:66.195.205.25 port 40172 ssh2
Nov 18 04:47:03 plesk sshd[15152]: Received disconnect from ::ffff:66.195.205.25: 11: Bye Bye
Nov 17 22:47:04 plesk sshd[15157]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:47:05 plesk sshd[15154]: Failed password for root from ::ffff:66.195.205.25 port 39943 ssh2
Nov 18 04:47:05 plesk sshd[15155]: Failed password for root from ::ffff:66.195.205.25 port 39943 ssh2
Nov 18 04:47:05 plesk sshd[15155]: Received disconnect from ::ffff:66.195.205.25: 11: Bye Bye
Nov 17 22:47:05 plesk sshd[15160]: reverse mapping checking getaddrinfo for 66-195-205-25.static.twtelecom.net failed - POSSIBLE BREAKIN ATTEMPT!
Nov 17 22:47:06 plesk sshd[15157]: Failed password for root from ::ffff:66.195.205.25 port 40281 ssh2
Nov 18 04:47:06 plesk sshd[15158]: Failed password for root from ::ffff:66.195.205.25 port 40281 ssh2
Nov 18 04:47:06 plesk sshd[15158]: Received disconnect from ::ffff:66.195.205.25: 11: Bye Bye

And here's what BFD eventually tried to insert into the APF deny list:
(this is from the BFD log)
Nov 17 22:50:02 plesk BFD(15539): {sshd} 66-195-205-25.static.twtelecom.net exceeded login failures; executed ban command '/etc/apf/apf -d 66-195-205-25.static.twtelecom.net {bfd.sshd}'.


So, BFD fed '66-195-205-25.static.twtelecom.net' to APF, which accepted it and put it into the deny file. But iptables wouldn't accept it, cause it's not a properly formated IP addr.

When I saw the attack in progress, I tried to execute the ban command manually, and APF would come back and say "already exists in the deny list". I'm guessing that it's using a regular expression to grep for the addr in the list and 66-195-205-25 matched 66.195.205.25 because in a regular expression, the '.' means 'match any character'.

So, the hacker was hacking away, unimpeded .. Once I figured out why the IP addr wasn't being blocked, even though APF said it was, I manually edited the deny list, removing the malformed IP and putting in the proper one, then re-started the firewall ... and the hacker was history, at least for now. But, this means that my server has a basic vulnerability because of this BFD/APF combo bug.

So all ya'll out there running BFD/APF - BEWARE !!!!

- john silvey

Thanks for alerting. Did you submit this bug to R-fx so he can fix it?

I did - but their site looks half-dead. A bunch of the links don't work .. the forums won't come up .. the link to tech support produced a page-not-found. I found a working link to "sales" and sent a short note, but haven't heard anything back.

Also, with a bit of help from somebody else, I discovered that I was not completely accurate in my description. IPTABLES *will* accept a host/network name. So, that wasn't the problem - the problem is that the host/network name is bogus (as warned in the secure log - "reverse name lookup failed"). The bug is actually that BFD picks up the bogus host/network name and executes the APF command with it, and since it's bogus, the actual IP does not get blocked. So, the fix for the bug would be to make sure BFD always picks up the actual IP name, not the host/network name out of the appropriate logfile. So, it seems to boil down to a hacker being able to thwart BFD/APF simply by providing a bogus host/network name.

- js

Well, at least you did what you could. Could you post the patch? Maybe could help others.


( Like I said in another thread not that long ago: half of R-fx stuff is old (two years ago and older ) and some tools are not maintained. For some reason R-fx is "big" in hosting country and I'm not saying that I'm that much better a script hacker, but I am confident that for much of the tools he provides there exist more current or even qualitatively better alternatives.
Have a look here: http://www.linuxquestions.org/questi...80#post2460580 )

I cross-posted to another forum and somebody turned up from r-fx and provided a patch (a new sshd rules file - simply replace your old one with this one). Here's a link to that full thread, and below the link is a cut-n-paste of the patch. Somebody else provided an alternative solution - turning off the use of domain names (and sticking with the basic IP addr) for sshd.

http://www.webhostingtalk.com/showthread.php?t=563425

From the folks at r-fx ...