Page 1 of 1

Immediate drop

Posted: Mon Dec 05, 2016 7:44 am
by faris
Is there a way to totally kill all connections from a particular IP?

We've been suffering from brute force attacks on Plesk itself, resulting in server load skyrocketing and the database becoming inaccessible.

When I see this happening, I immediately blacklist the IP in question, which adds it to the block list in the ASL firewall, but this does not kill off the existing connections from this IP, which continue to cause problems.

The same thing can happen with an email spam attack when the sender keeps sending via an existing open connection.

For Plesk, the safest thing to do is restart psa, but just today this took ages due to the high load.
For email, you tend to have to find the qmail-smtp processes and kill them off manually.

All of this is inconvenient and in some cases difficult to do when you are in panic mode.

So...

Is there a way to immediately stop an IP in its tracks? To drop all related connections -- everything, basically, from a particular IP?

Re: Immediate drop

Posted: Mon Dec 05, 2016 8:59 am
by prupert
The package dsniff (in EPEL) provides a command called "tcpkill" which you can use to kill TCP connections. I think it is as simple as

Code: Select all

tcpkill host <offending-ip>

Re: Immediate drop

Posted: Mon Dec 05, 2016 9:46 am
by faris
That looks perfect but it comes in a collection of tools that would typically be used for bad things - which raises some concerns.

Still, one would hope that a package in epel would be trustworthy.

Re: Immediate drop

Posted: Tue Dec 06, 2016 1:14 pm
by prupert
What are your concerns exactly?

Re: Immediate drop

Posted: Wed Dec 07, 2016 6:32 am
by faris
I'm just being too cautious, that's all.

I tend to assume packages of this nature are more likely to be a target for "subversion" than others.

Re: Immediate drop

Posted: Thu Dec 08, 2016 6:47 pm
by mikeshinn
So when ASL shuns an IP, its going to block any additional traffic from that IP (shun rules come before any other INPUT rules, unless you add something custom to override that). So did you mean you want to kill off any half open connections before the kernel times them out, or kill off any threads or applications that IP might have been using, or both, or something else?

Re: Immediate drop

Posted: Mon Jan 09, 2017 12:50 pm
by faris
I don't honestly know the technical situation on what's happening, so I'd better describe a couple of the issues:

1) spammer connected on port 25, authenticated using guessed or stolen credentials and sending spam, one after another, in one long connection. Adding IP to firewall ineffective. Must kill qmail-smtp for qmail or whatever the postfix equivalent is to stop emails being added to the queue.

2) Attacker attempting to brute-force Plesk admin login and causing a DoS as a result. Adding IP to firewall is ineffective. Must restart sw-cp-server to kill attack. (We nevertheless really need a rule to look for and block Plesk 12/Onyx failed logins ASAP please, as discussed in a support case a month or two back)

Re: Immediate drop

Posted: Wed Jan 11, 2017 9:19 am
by scott
How are you doing the drop? If its coming in as an Add (-A) its not going to do anything since its going to land after a NEW or otherwise RELATED,ESTABLISHED rule. -I INPUT 1 is going to put the rule at the very start of the list. Normally specifying the 1 here is kind of overkill, but if you're running into a situation where you cant be sure that the VPS kernel is ignoring a rule (and they DO) because of the position in the stack, this is a way to debug that.

Re: Immediate drop

Posted: Wed Jan 11, 2017 10:21 am
by faris
Ah!

I've just been doing an asl- bl [ip] rather than manually adding a rule.

And of course asl -bl adds them after the state=related/established rule.

So how about this instead then:

killip.sh

Code: Select all

#!/bin/bash
#usage: killip.sh IP

#KILL THEM NOW
iptables -I INPUT 1 -s $1 -j DROP

#BLACKLIST THEM SO THEY DON'T COME BACK
asl -bl $1
Is it worth adding iptables -I INPUT 2 -d $1 -j DROP as well?

Re: Immediate drop

Posted: Wed Jan 11, 2017 7:16 pm
by scott
Yes absolutely what you're doing there will totally work. In a product Im a little more reluctant to do it that way (and we used to, for the record) since you may want to have something that always comes before that (whitelists, etc).

Using -I and a position on INPUT guarantees it will be the very first thing netfilter is going to process in the stack which is a great way to see when/where the firewall component is starting to break down (just keep adding til it dies) or how other parts of the policy affect performance.

Re: Immediate drop

Posted: Thu Jan 12, 2017 2:44 pm
by mikeshinn
The establish/related rule is being moved to after the blacklist family.

Re: Immediate drop

Posted: Sun Jan 15, 2017 8:58 am
by faris
Is this in v5?

Re: Immediate drop

Posted: Mon Jan 30, 2017 9:58 pm
by mikeshinn
Yes.