IPtables dShield, eDROP, & DROP

Getting kinda tired of the same old same old showing up in Suricata logging.

Decided to see what I could do about it.

The biggest hitter by far - and I mean BY FAR is the dshield list. Possibly something to do with the line of work and number of hosts / content / domain name density exposed per net block.

Below are two solutions I have implemented with the intention of merely reducing known / likely influencers in my Suricata / Snort stats, and basically drop their traffic at the door.

I appreciate that this is not going to make the world a nicer place, or indeed a more secure one - however given the amount of logging I am seeing from hits to these - it is doing something and reducing the load on the IDS.


First up the nice people at dshield provide a list of networks that are 'at any one time' forming the top twenty networks that they are seeing badness from. Plan is simply - grab list, sanitize - implement.

This assumes that you have created an empty chain - and this is going to flush and repopulate this list periodically. You can do this from cron.

# path to iptables
# list of known spammers
# save local copy here
# iptables custom chain
# check to see if the chain already exists
# check to see if the chain already exists
# flush the old rules
echo "Flushed old rules. Applying updated dsheild list...."
# get a copy of the spam list
wget -qc $URL -O $FILE
blocklist=$( cat $FILE | awk '/^[0-9]/' | awk '{print $1"/"$3}'| sort -n)
for IP in $blocklist
 # add the ip address log rule to the chain
 $IPTABLES -A $CHAIN -p 0 -s $IP -j LOG --log-prefix "[dsheild BLOCK]" -m limit --limit 3/min --limit-burst 10
# add the ip address to the chain
 $IPTABLES -A $CHAIN -p 0 -s $IP -j DROP
echo $IP
echo "Done!"
# remove the spam list
unlink $FILE


The lovely people at Spamhaus which you are no doubt aware of from their Dynamic Blocklists and reputation monitoring - also produce a few lists of use.

The extended and standard DROP (do not route or peer) list ideally would be something that your network team would implement at a router level - however it is equally as easy misappropriated at a firewall level. HOWEVER the issue is its size. IPtables performance runs out of steam really really quickly once tables get larger that 200 entries or so. My solution was to split them up.

Again this assumes that there are a number of chains already in place - this then splits the drop list up into a number of bite sized chunks, and inserts them into chains.

This list is updated every few days or so as opposed to hourly - however again - cron as appropriate.

iptables -F EDROP01
iptables -F EDROP02
iptables -F EDROP03
iptables -F EDROP04
iptables -F EDROP05
/usr/bin/wget http://www.spamhaus.org/drop/drop.lasso -O /tmp/drop.lasso
awk '{outfile=sprintf("/tmp/EDROP%02d",NR/150+1);print > outfile}' /tmp/drop.lasso
for i in $(cat /tmp/EDROP01 | grep -i SBL | cut -f 1 -d ';' )
 ### echo BLOCKING $i 
 /sbin/iptables -t filter -A EDROP01 --src $i -j DROP
iptables -A EDROP01 -j RETURN
for i in $(cat /tmp/EDROP02 | grep -i SBL | cut -f 1 -d ';' )
 ### echo BLOCKING $i 
 /sbin/iptables -t filter -A EDROP02 --src $i -j DROP
iptables -A EDROP02 -j RETURN
for i in $(cat /tmp/EDROP03 | grep -i SBL | cut -f 1 -d ';' )
 ### echo BLOCKING $i 
 /sbin/iptables -t filter -A EDROP03 --src $i -j DROP
iptables -A EDROP03 -j RETURN
for i in $(cat /tmp/EDROP04 | grep -i SBL | cut -f 1 -d ';' )
 ### echo BLOCKING $i 
 /sbin/iptables -t filter -A EDROP04 --src $i -j DROP
iptables -A EDROP04 -j RETURN
for i in $(cat /tmp/EDROP05 | grep -i SBL | cut -f 1 -d ';' )
 ### echo BLOCKING $i 
 /sbin/iptables -t filter -A EDROP05 --src $i -j DROP
iptables -A EDROP05 -j RETURN

This is as much an aide mémoire as an intentional resource, if useful - great.





Leave a Reply

Your email address will not be published. Required fields are marked *