[Dshield] Blocking Offending Countries
cbrenton at chrisbrenton.org
Wed Jun 29 11:42:14 GMT 2005
On Wed, 2005-06-29 at 01:19, jayjwa wrote:
> -> I understand the desire to believe that blocking IP connections
> -> by country is somehow increasing security. I would like to point
> And yet it does, at least in my case. I seriously cut down on the number
> of weird log entries I had to follow up on, spam I had to report, and
> other incidents to take time away from what I really wanted to be doing
> with my computer.
Its not just you. Quite a few environments have been banning address
blocks they don't need access to for quite some time. I've documented
cases where staff requirements have been reduced through this practice.
> To this day, I've never, ever got one single piece of
> legitimate traffic from China, which is what I was initially bringing up.
This is the key requirement and I think Johannes said it best. It comes
down to business need. If you don't need access to those networks, why
expose yourself to additional risk?
The analogy I use in the SANS 502 track is port filtering. Most
environments have a ton of systems listening on TCP/445 and yet they
choose to filter this port at their perimeter. Is it "racist" to filter
this port? Obviously not. Its all about business need and exposure to
risk. If there is no business need to communicate with this port across
the Internet, then permitting access to it is exposing yourself to
unneeded risk. IMHO exposing yourself to unneeded risk is bad security.
> One of my first posts stated that I don't usually do it, and I don't like
> to, but China was a rare exception based on the lack of responses I got
> from all the ISP's that I tried to contact there, and on content after
You are far more forgiving than myself. My experience has been that nine
out of ten times e-mailing the remote admin or tech contact results in:
1) A full/dead mailbox
2) No response
3) Contacting the actual attacker who has now social engineered you into
reveling how closely you watch your perimeter and possibly what tools
you use (if you send them log entries).
For me, a single malicious payload results in a 'whois -h whois.arin.net
xxx.xxx.xxx.xxx'. If the results produce a country that I don't need to
communicate with, the entire block goes /dev/null. No more future
> -> In any case, I have never seen an accurate
> -> listing of IP blocks by country,
> http://www.blackholes.us/ is pretty close, I think.
This does get a little sticky. For example filter a block listed as
'Sweden' and it will quite possibly include a few addresses that
actually terminate in 'Norway'. Then again if you are not doing business
in Sweden, you are probably not doing business in Norway either.
> plus all of the slots in my iptables
> listing for which I see packet and byte counts.
Just to bring this conversation back to a technical spin, here's a
little trick I use with iptables that might make life a bit easier for
you. I don't use iptables-save & iptables-restore, but rather load the
rules from a custom script. Here is my IP block filtering section:
# Banned IP addresses. The file BANNED must be in the current
# directory and each line is a single IP or CIDR block to ban.
iptables -N EVILBLOCKS
while read BANNED ; do
iptables -A FORWARD -i eth0 -s $BANNED -j EVILBLOCKS
done < BANNED
iptables -A EVILBLOCKS -s 0/0 -j LOG --log-prefix " BADGUY "
iptables -A EVILBLOCKS -s 0/0 -m limit --limit 3/m -j REJECT
As mentioned above, the file BANNED must exist in the same directory as
this script unless you change the above to include a full path name. The
file BANNED includes one IP address specification per line, like
So when you load your rulebase the chain EVILBLOCKS gets created. The
forward rule sends all IP's listed in BANNED to this chain. Their
traffic is then logged with the prefix BADGUY and the transmitting host
gets back an ICMP host unreachable (this makes it appear that you have
no firewall and the host is just off-line). Rate limiting is used to
minimize the amount of ICMP traffic.
More information about the list