David Coulson on 4 Feb 2012 05:26:49 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Quick & dirty IP blocking

On 2/3/12 9:09 AM, Paul W. Roach III wrote:

Nullroutes don't affect incoming traffic, they affect outgoing traffic. This means that their packets will still hit you (and whatever service is on the other end of the port in question), but your replies will be nullrouted into the bit bucket.

Depends. In the networking world, null routes can also be used to drop inbound traffic at a router when it is enforcing unicast reverse path filtering - Basically if you have a static route for a subnet pointing to Null0 (The cisco version of a null route), and a packet comes in from that subnet from a different interface (e.g. upstream Ethernet or PPPoE), the router will drop the packet as it did not originate from the interface on which packets delivered to that subnet will be routed to.

While Linux does support RPF, I don't believe the way the 'blackhole' type in iproute2 works will utilize RPF. The significant downside of using blackhole directly on a Linux system when you are running services on the same box (e.g. HTTP, SSH, FTP) is you will end up with many TCP connections in a SYN_RECV state which by default is only 1024 or something pretty small - Even increasing it to a higher number puts you in a position where you can quickly lose the ability to create new inbound TCP connections, resulting in a DoS - Which probably causes more issues than whatever you were trying to block in the first place.

iptables is certainly the way to do it if you don't have the ability to block it further upstream on a firewall or router. I typically create a 'BLACKHOLE' chain in iptables which is called before most of my service ACCEPT rules, but also after rules to allow for management access to the box. If you want to block something, just throw it in the BLACKHOLE chain and even if you screw it up you don't get locked out of your own system. The obvious advantage of iptables is you have more detailed logging, so you can determine when the malicious activity ceases, plus you can get very granular with the types of response you send to the source when you drop a packet. I've had instances where just doing a DROP will cause the attack to continue for a long time, or even ramp up, but doing a '-j REJECT --reject-with tcp-reset' will make it stop pretty quickly.

Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug