Re: [PLUG] Quick & dirty IP blocking

[David Coulson <david@davidcoulson.net>]

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.

David
___________________________________________________________________________
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