Blocking incoming IP in the PREROUTING nat table chain?

[Johan162]

I'm trying to put in some country blocks already in my router to avoid my server logs being filled up by attacks from certain countries. So in order to have these rules inserted before any virtual server NAT redirection i have added these rules in the nat table's PREROUTING chain which, in my understanding, is the earliest possible action the router takes with incoming packets.

Something like
iptables -t nat -I PREROUTING -p all -m set --set blacklist src -j DROP

where the "blacklist" is an ipset hashlist of all addresses to block. This seems to work well but since I'm far from an expert on iptables (nor do I want to be ... ) I was just seeking a second opinion if this is the "right" way to do it?

 

[mstombs]

I have done this, and it works on our routers, but apparently it is wrong and is even prohibited on Ubuntu full Linux PC setups.

The "nat" table is not intended for filtering, the use of DROP is therefore inhibited.

The only reason I can think it is that is inefficient checking all incoming messages. The correct location will be in the filter FORWARD chain, after the ACCEPT for ESTABLISHED/RELATED, and also in the INPUT chain?

 

[Johan162]

Thanks for the view. I guess that makes sense. So am I right in my understanding that the filter table FORWARD chain rule will be applied to all packets that have been forwarded by the nat table to their designated servers? (The original reason for me to put it in the nat table was that the INPUT chain in the filter table is not applied to packets forwarded by the nat table)

I guess one should also add some state check so that the rule will not be applied to ESTABLISHED connections to avoid blocking responses from servers in blocked IP ranges when the connection is established from the source. I'm really only interested in blocking all script-kiddies who run port scans and tries lookup-brute-force attacks on standard ports.

Anyway, even if this might be wrong it works and the load this puts on the ASUS router CPU seems to be neglectible.

I had hoped to not have to spend more time on reading up on iptables but that might be inevitable ...

 

[mstombs]

Tomato has built in targets for this sort of thing, so blocks can be applied to both FORWARD and INPUT, my asuswrt router doesn't - so its actually quite messy Inserting your rules into the FORWARD chain at the correct location - so if it works leave it! Is there a way this can be implemented through the GUI?

There is a built in "logdrop" target you can use to get a log message for all dropped packets - useful for proof testing, if not for production use.

There are also differing views on the net as to whether you should just drop or "reject with rst" (can't remember exact syntax). In the former case a probe might just repeat its request after a timeout, the latter may encourage a script kiddie that his message has been actively refused so he can move quickly on to probe a different port!

 

[sfx2000]

I'm trying to put in some country blocks already in my router to avoid my server logs being filled up by attacks from certain countries. So in order to have these rules inserted before any virtual server NAT redirection i have added these rules in the nat table's PREROUTING chain which, in my understanding, is the earliest possible action the router takes with incoming packets.

Something like
iptables -t nat -I PREROUTING -p all -m set --set blacklist src -j DROP

where the "blacklist" is an ipset hashlist of all addresses to block. This seems to work well but since I'm far from an expert on iptables (nor do I want to be ... ) I was just seeking a second opinion if this is the "right" way to do it?

Most iptables implementation probably won't let you do this...

Let me ask a question - what exactly are you trying to do? It sounds like you have a server of some type behind the router, and getting connections from countries you'd prefer not to be able to connect...

I'd shy away from tweaking IPTables directly on the router, and instead, pass the packets back to the server, where then you can apply various rules against...

 

[Johan162]

... Let me ask a question - what exactly are you trying to do? It sounds like you have a server of some type behind the router, and getting connections from countries you'd prefer not to be able to connect...

I'd shy away from tweaking IPTables directly on the router, and instead, pass the packets back to the server, where then you can apply various rules against...

Well, I already done the tweaking on my Asus router which allows dropping packages in the nat table. Since I cannot use the normal filter tables INPUT chain (the re-routed packages doesn't reach the INPUT chain) I just wanted a sanity check where these rules ideally should be put since I suspected that the nat-table was not really the supposed place.

The reason is really very banal. My router normally sits idle and I just wanted to see if I could stop all the script-kiddies before they reach my servers already on the router. I can of course use the iptables on my servers to block (which I btw also do). I just thought that since my router have a full linux kernel why not make use of some of the cycles on the router to block some countries where 80% of the break-in attempts come from.

I normally shy away from moving well known ports to some random place to avoid the scans since it just causes issues for legit users.

 

[RMerlin]

The INPUT chain is for traffic terminated at the router, while the FORWARD chain is for traffic intended for your LAN. That's where you'll want to do your filtering.

 

[Johan162]

I thought I would follow RMerlins advice and put my blocking rules in the FORWARD chain instead. Looking at the FORWARD chain (in FILTER table) one thing confuses me. The policy is DROP and the first few rules are:

target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID

What I don't understand is that rule #2 basically accepts all incoming traffic on all protocols to all destinations. Since that rule will match everything I though that the chain would stop processing at that stage. However there are several rules after that one so I must be wrong. Then the DROP rule comes along and drops all packages (rule #3) but that doesn't match all packages either since there are more rules.

I clearly misunderstand something here so can someone shed some light on this apparent contradiction?

 

[RMerlin]

I thought I would follow RMerlins advice and put my blocking rules in the FORWARD chain instead. Looking at the FORWARD chain (in FILTER table) one thing confuses me. The policy is DROP and the first few rules are:

target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID

What I don't understand is that rule #2 basically accepts all incoming traffic on all protocols to all destinations. Since that rule will match everything I though that the chain would stop processing at that stage. However there are several rules after that one so I must be wrong. Then the DROP rule comes along and drops all packages (rule #3) but that doesn't match all packages either since there are more rules.

I clearly misunderstand something here so can someone shed some light on this apparent contradiction?

You are not viewing the complete rule.

iptables -L -v

Then it will make more sense.

 

[Johan162]

Just quick writeup if someone finds this thread and wants to do a similar thing.

Recap of what I wanted to do:
Block as much traffic as possible already at the router based on country whitelist. Main reason is that I have a number of virtual and physical servers on my local net which I need in my work and I wanted to avoid having to add the same block rules individually on all of them.

To do the following you need to have enabled both JFFS and SSH to be able to login to your router and use JFFS filesystem to store some temporary files. It is then a good idea to create a subdirectory under /jffs where you do all the work described below.

STEP 1 - Get country ip-address range
Aggregated country IP lists can be downloaded from http://www.ipdeny.com/
For example to block a country download the complete ipset with:

wget -P . http://www.ipdeny.com/ipblocks/data/aggregated/[COUNTRY-CODE]-aggregated.zone

Where you replace [COUNTRY-CODE] with the appropriate two letter country code.

STEP 2 - Create whitelist using ipset
Create a whitelist (I used the name "whitelist") using ipset. If the whitelist exists you should first delete it

ipset -X whitelist

You can then create a new whitelist with the following (the hashsize does not strictly need to be set but the larger hash the quicker it will be for the lookup at the expense of some memory)

ipset -N whitelist nethash --hashsize 16384

STEP 3 - Add the country range to the whitelist
Then it is time to populate the whitelist. You could use the following construct for each country list you have downloaded

for i in $(cat [COUNTRY-CODE]-aggregated.zone ); do ipset -A whitelist $i; done

Do not forget to add the local addresses as well, i.e.

ipset -A whitelist 192.168.0.0/16
ipset -A whitelist 127.0.0.0/24

STEP 4 - Add a drop rule in the FORWARD chain
Finally add a drop rule in the FORWARD chain in the filter table to block everything NOT coming from a source in the whitelist. Exactly on what row you want to add the rule depends on your existing rules in the FORWARD chain. But you should add the rule as high up as possible as long as it is after the rule to allow existing and related connections, in my case this will be the third rule.

iptables -I FORWARD 3 -p ALL -m set ! --set whitelist src -j DROP

This should of course be automated in a shell script and a few times a year you should probably also refresh the whitelist from the latest country IP address ranges.