How to efficiently block a large number of ip-addresses?
Showing results for 
Search instead for 
Did you mean: 

How to efficiently block a large number of ip-addresses?

L6 Presenter

A discussion in a IRC-channel this evening was regarding the ongoing DDoS against wordpress installations all around the world and what to do in order to protect your webservers from the known bad ip addresses.

Using ACLs in for example a modern Cisco router seems to only be able to handle something like 1-10k ace's depending on masks being used etc.

Using iptables locally on the webservers seems to bail out after approx 30-40k lines with 10% cpu usage in kernel space for the linux kernel.

So what other countermeasures can be used?

A BGP based blackholing should be doable - however that only seems to block outgoing (returning) traffic from your network, it wont stop the incoming bad request (at least the syn will reach the server and then become hanging - while udp-traffic will be able to reach your server anyway). Unless im missing something here?

Another possible approach could be to enable HostnameLookups in your apache-server and use something like:

<Directory "/www/">

        Options                 None

        AllowOverride           None

<Limit GET POST>

        Order                   deny,allow



<LimitExcept GET POST>

        Order                   allow,deny



and then in your DNS server make it authoritive for PTR records regarding the ip addresses you wish to block. When bad ip shows up your apache will ask the DNS for PTR-record of this host and if the answers from the DNS is "" (or whatever you wish to call it) the apache will just drop the connection (perhaps with a http error 403 or such in return).

Which boils down to why I created this thread... what can be used if you have a PA device in place?

According to the datasheet the PA-5060 can use up to 40.000 security policies - but this is of course unique security policies.

A single security policy could perhaps be something like:

srczone: internet

dstzone: dmz

srcip: country(blacklist)

dstip: webserver

appid: any

service: any

action: deny

option: log on session end

or for that matter:

srczone: internet

dstzone: dmz

srcip: group(blacklist)

dstip: webserver

appid: any

service: any

action: deny

option: log on session end

So the question is really is it possible and in which way can one setup a custom country (or a custom address group) to hold 200k+ members (mostly /32 ip addresses)?

And as a sidenote - any efficient ways to keep this list easily up2date? There is for example methods to setup dynamic objects where the PA device will load a textfile from a webserver containing the ip addresses to act on as srcip (in this case) - or for that matter using the REST API to push (or withdraw) ip-addresses to blacklist. Will any of these methods work for a list that contains 200k+ ip addresses?

Or does any of you have other suggestions mainly from own experience? :-)


Sorry about that...

But in this context it doesnt seem to matter if you use a dynamic address object or a dynamic block list - the limit is still 25.000 ip addresses on a PA-5000 box, isnt it?

Yes in this particular case using some kind of IPS signature to trigger the DoS-protection is probably the way to go.

But then what?

How many ip addresses can the PA dynamically block by the DoS-protection feature?

Doesnt it too have the same limit of max 25.000 entries on a PA-5000 series box?

Which brings me back to the original question - ignore the wordpress thingy. The use-case is that you need to block 200.000 /32's - how the hell are one supposed to do that nowdays without a major performance drop (and that is without putting 8 x PA-5000 boxes in a line :smileysilly:)?

L1 Bithead

What if you use BGP blackholing in addition to uRPF (IP spoof protection)?  I'm not sure if this is any more efficient than using an ACL on your router, but assuming your router has enough memory to hold all the /32 entries in its routing table, it may be worth a try.  Since the router's core function is routing packets, hopefully a route lookup for uRPF enforcement would be faster than an ACL check.  In theory, if your blackhole route doesn't point towards the internet, then the router should discard any packet from a blackholed IP when it arrives on your internet interface.

View solution in original post

L4 Transporter

We are dealing with the wordpress issue by blocking access to the wordpress login page from the internet. This is done with a simple custom vulnerability signature with default action allow (for inside users) and an exception of block (for outside users).  Content management must be done from the inside or if needed from the outside - they need to us a vpn connection.

Hmm yeah this seems to be the (currently) only proper and practically usuable way to deal with a situation where one would need to block plenty of ipaddresses.

It also has a name :-)

RTBH - Remotely Triggered Black Holes

You would most likely need to up the "maximum-prefix" in your BGP-settings like so (and use a device which can store and use +200.000 routes):

neighbor x.x.x.x maximum-prefix 250000

Which gives - how many routes (through BGP) can various PA-devices deal with?

From the time of last post (2013) BGP FlowSpec was more and more preferred for the granularity of blocking/rate limiting, but even vendors which implemented in routing platforms (JNPR) did not implemented (yet) in firewall platforms. Vendors with ADC & CGN background (ATEN) copes with dynamic block lists of 8 millions of /32.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!