[SOLVED] Blocking a brute force password hacker

Lop3 · 08-01-2015, 05:43 AM

Someone is hammering away on my webserver trying to brute force passwords. I've added their IP to my ipset blacklist. (and confirmed they're on the ipset by listing all the IPs in the blacklist and grepping theirs etc) and I have a rule to drop everything in that IPset.

iptables-save -C shows my first filter rule is

Code:

[477:19080] -A INPUT -m set --match-set my_blklist src -j DROP

which is clearly active, yet this hacker is hammering away.

I thought perhaps because he has a keepalive connection, but then I tried: `tcpkill -i br0 -9 host 6.6.6.6`...
I've tried running TCPkill
* on the host http://pastebin.com/80vwdn3h
* on the webserver VM http://pastebin.com/96rA1FX5

I see that his port number is changing constantly, which means he is somehow able to establish new connections? This should not be happening. Any ideas?

IP's have been obfuscated, where 1.2.3.4 is my servers IP, 6.6.6.6 is the hacker. and 10.0.0.2 is my webserver VM's IP.

My blacklist was created like so:

Code:

create my_blklist hash:ip
iptables --table filter -I INPUT --match set --match-set my_blklist src -j DROP

On my nat table, incoming HTTP connections are forwarded to my webserver with

Code:

-A PREROUTING -i br0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80

(which would be the first rule that gets matched)

I tried adding this now

Code:

iptables --table nat -A INPUT -m set --match-set my_blklist src -j DROP

But it said The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.

============================

I investigated a little more now. I ran

Code:

iptables -Z

to reset my counters.
Then I found that on the filter table pretty much the only thing getting hit was

Code:

-A INPUT -m state --state ESTABLISHED -j ACCEPT

and my blacklist ipset rule was zero (inactive).

So then I ran tcpkill again for a few seconds.

Then checked iptables -c again. And then I saw the blacklist ipset DROP rule had been active while running tcpkill.
But when I'm not running tcpkill, then the ipset rule is inactive (counter does not go up).

============================

SOLVED: I was dropping INPUT stuff. I needed to drop FORWARD stuff.

unSpawn · 08-01-2015, 06:46 AM

Quote:

Originally Posted by Lop3

SOLVED: I was dropping INPUT stuff. I needed to drop FORWARD stuff.

Thanks for posting.

This thread also clearly illustrates why not posting actual rule sets (as in 'iptables-save;' output) hampers troubleshooting...

sundialsvcs · 08-01-2015, 08:47 PM

The best thing to do is to disable passwords altogether in "ssh," using only digital certificates and not permitting a fall-back to passwords. Now, even though authorized users pass through the gauntlet immediately, no one else can pass. You can't brute-force a certificate.

unSpawn · 08-02-2015, 02:52 AM

Quote:

Originally Posted by sundialsvcs

The best thing to do is to disable passwords altogether in "ssh,"

He's talking TCP/80 here?..