iptables not working

[mbeijen]

For some reason my iptables is not working.

I created a file in /jffs/scripts/firewall-start and in there:
#!/bin/sh
iptables -I INPUT -s 85.25.207.201/255.255.255.0 -j DROP

File permissions are set correctly:
-rwxrwxrwx 1 admin root 67 Aug 21 15:57 firewall-start

And the rule gets loaded in iptables:
admin@ROUTER:/jffs/scripts# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- static-ip-85-25-207-0.inaddr.ip-pool.com/24 anywhere

I am trying to stop an bruce force attack from 85.25.207.201

Any help is very appreciated!
Marco

 

[ColinTaylor]

How do you know it is not working? Just because you are dropping the incoming packets doesn't mean you've stopped the person sending them.

Instead you could try turning on DoS protection in Firewall > General

 

[vdemarco]

I have this in my nat-start script


#!/bin/sh

# block incoming traffic from some countries.
ipset -q --destroy BlockedCountries
ipset --restore < /jffs/scripts/ipset.save
iptables -t nat -I PREROUTING -m set --set BlockedCountries src -j DROP

--
my ipset.save file looks like this

-A BlockedCountries 202.40.15.0/24
-A BlockedCountries 110.52.0.0/15
-A BlockedCountries 202.41.130.0/23
-A BlockedCountries 218.104.0.0/17

....

I create the ipset.save file

by doing a

ipset --save > /jffs/scripts/ipset.save


--

to add a entry to the upset table

ipset -A BlockedCountries 202.40.15.0/24


let me know if you need any more info.

 

[mbeijen]

Still not working, getting an error when I run it. This is what happens:

admin@ROUTER:/jffs/scripts# ./nat-start
ipset v4.5: Set already exists
ipset v4.5: Set BlockedCountries is already defined, cannot be restored
Restore failed at line 2:
Try `ipset -H' or 'ipset --help' for more information.


admin@ROUTER:/jffs/scripts# cat nat-start
#!/bin/sh

# block incoming traffic from some countries.
ipset -q --destroy BlockedCountries
ipset -N BlockedCountries iphash
ipset --restore < /jffs/scripts/ipset.save
iptables -t nat -I PREROUTING -m set --set BlockedCountries src -j DROP

admin@ROUTER:/jffs/scripts# cat ipset.save
# Generated by ipset 4.5 on Thu Aug 21 22:01:27 2014
-N BlockedCountries iphash --hashsize 1024 --probes 8 --resize 50
-A BlockedCountries 85.25.207.201
-A BlockedCountries 202.40.15.0
-A BlockedCountries 212.129.8.167
COMMIT
# Completed on Thu Aug 21 22:01:27 2014


Any suggestions?

 

[vdemarco]

Still not working, getting an error when I run it. This is what happens:

admin@ROUTER:/jffs/scripts# ./nat-start
ipset v4.5: Set already exists
ipset v4.5: Set BlockedCountries is already defined, cannot be restored
Restore failed at line 2:
Try `ipset -H' or 'ipset --help' for more information.


admin@ROUTER:/jffs/scripts# cat nat-start
#!/bin/sh

# block incoming traffic from some countries.
ipset -q --destroy BlockedCountries
ipset -N BlockedCountries iphash
ipset --restore < /jffs/scripts/ipset.save
iptables -t nat -I PREROUTING -m set --set BlockedCountries src -j DROP

admin@ROUTER:/jffs/scripts# cat ipset.save
# Generated by ipset 4.5 on Thu Aug 21 22:01:27 2014
-N BlockedCountries iphash --hashsize 1024 --probes 8 --resize 50
-A BlockedCountries 85.25.207.201
-A BlockedCountries 202.40.15.0
-A BlockedCountries 212.129.8.167
COMMIT
# Completed on Thu Aug 21 22:01:27 2014


Any suggestions?

You are creating the block list so you can't restore it
This line

ipset -N BlockedCountries iphash

is causing the problem

I have just this

# block incoming traffic from some countries.
ipset -q --destroy BlockedCountries
ipset --restore < /jffs/scripts/ipset.save
iptables -t nat -I PREROUTING -m set --set BlockedCountries src -j DROP

 

[Alfred]

ipset blocking doesnt work on RT-AC66U ?

Hello, I seem to have a possibly related issue.

I tried to block Tor nodes and countries with the script in:
https://github.com/RMerl/asuswrt-merlin/wiki/Using-ipset
but it doesnt seem to work on my RT-AC66U with Merlin build 376.44 (3-Aug-2014). This is the first time I tested ipset. I tested open ports with ShieldsUp from grc.com

ipset v4.5, protocol version 4.
Kernel module protocol version 4.
iptables v1.3.8

First I tested with blocking all of US, using CIDR from https://www.countryipblocks.net/country_selection.php
That failed.
Then I changed the script so that all probe nodes of grc.com were added as if it were Tor nodes, and I added 4.0.0.0/8 as nethash for "country blocking" (was already present in the US CIDR):

admin@RT-AC66U:/tmp/home/root# ipset -L
Name: TorNodes
Type: iphash
References: 1
Header: hashsize: 1024 probes: 8 resize: 50
Members:
4.79.142.207
4.79.142.204
4.79.142.199
4.79.142.203
4.79.142.202
4.79.142.200
4.79.142.201
4.79.142.205
4.79.142.206
4.79.142.193
4.79.142.195
4.79.142.192
4.79.142.194
4.79.142.196
4.79.142.198
4.79.142.197

Name: BlockedCountries
Type: nethash
References: 1
Header: hashsize: 1024 probes: 4 resize: 50
Members:
4.0.0.0/8


admin@RT-AC66U:/tmp/home/root# iptables -L (output cropped)
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere set BlockedCountries src
DROP all -- anywhere anywhere set TorNodes src

Looking at the above output as the iptables novice that I am, it seems that it should work, but it doesn't. ShieldsUp (grc.com) keeps saying that I failed.
The port I am testing is being forwarded by the virtual server webui to my NAS. When I deploy firewall GeoIP blocking on my NAS, ShieldsUp says that I passed (full stealth). However, I want to block on the router instead of the NAS.

I have read a remark somewhere else on this forum, stating that it might be related to the RT-AC66U using an old version of iptables (1.3.8).

Is that the cause?
Can anyone confirm that blocking with ipset is, or is not, working with an RT-AC66U ?

Kind regards

 

[RMerlin]

The INPUT chain is for connections terminates on the router itself. Use the FORWARD chain for connections terminated on a lan device.

Sent from my Nexus 4 using Tapatalk

 

[ColinTaylor]

The INPUT chain is for connections terminates on the router itself. Use the FORWARD chain for connections terminated on a lan device.

I was wondering if it would be better to drop unwanted packets at the PREROUTING stage as per vdemarco's post. Is there any disadvantage to that?

 

[sinshiva]

I was wondering if it would be better to drop unwanted packets at the PREROUTING stage as per vdemarco's post. Is there any disadvantage to that?

to elaborate on RMerlin's post;

every rule added to the prerouting chain must be inspected by all traffic hitting the router and passing through. ie, random internet bot scans, traffic destined for servers listening on the wan side of the router itself, traffic port forwarded to devices behind the lan and traffic initiated from the lan side.

with the input chain, rules are only processed for random internet bot scans and traffic destined for services listening on the wan side of the router itself

with the forward chain, rules are only processed for portforwarded traffic and traffic initiated from the lan side.

so, the prerouting chain really should only be used as a last resort. if you are trying to protect/filter traffic for the security of the lan, use the forward chain

 

[Alfred]

replaced INPUT with FORWARD:

[ -z "$(iptables-save | grep TorNodes)" ] && iptables -I FORWARD -m set --set TorNodes src -j DROP

This resulted in blocking grc.com completely. I couldnt access the website anymore.
However, I want to be able to access grc.com, but want to block unsollicited traffic coming from it. Is the FORWARD chain still the way to go for that?

I tried the following, but it didn't block unsollicited probes from grc.com to a forwarded port. It didn't seem to do anything.

[ -z "$(iptables-save | grep TorNodes)" ] && iptables -I FORWARD -m state --state NEW,INVALID set --set TorNodes src -j DROP