The INPUT 6 and FORWARDS depends on where the following rule is located in your 2 tables.
ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
The -j countrydropin and countrydropout should be below the above rule so that only NEW connections are sent through the 1000's of rulesets.
The vlan2 is whatever your wan (public IP) interface is. For most it is probably vlan2, but can change to ppp0 for some PPPoE users.
Add to your cron
Code:
@weekly /opt/ipblock/ipblock.sh
Takes a few seconds to finish on the R7000, but it doesn't delay start-up. It shouldn't run more than once at a time because of the lock file. Hope someone finds this useful. Thanks goes to JAMESMTL for helping to polish this script.
Last edited by badmoon on Sat Apr 18, 2015 15:18; edited 10 times in total
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Thu Apr 09, 2015 19:34 Post subject:
I run similar geo & TOR blocking scripts and you can significantly reduce processing time and router cpu utilization by simply using iptables restore for your block chain(s). In my case I whitelist countries and blacklist tor exit nodes and it literally takes only a few seconds to process and load some 25K IPv4 and IPv6 rules. Also running on an R7000.
James,
thank you for adding.
Care to explain the process a little more on adding this to reduce the cpu load?
I have added this thread to the suggested list of URLs for users in the sticky. _________________ Router currently owned:
Netgear R7800 - Router
Netgear R7000 - AP mode
One of the largest reasons for using the iptables-save and iptables-restore commands is that they will speed up the loading and saving of larger rule-sets considerably. The main problem with running a shell script that contains iptables rules is that each invocation of iptables within the script will first extract the whole rule-set from the Netfilter kernel space, and after this, it will insert or append rules, or do whatever change to the rule-set that is needed by this specific command. Finally, it will insert the new rule-set from its own memory into kernel space. Using a shell script, this is done for each and every rule that we want to insert, and for each time we do this, it takes more time to extract and insert the rule-set.
To solve this problem, there is the iptables-save and restore commands. The iptables-save command is used to save the rule-set into a specially formatted text-file, and the iptables-restore command is used to load this text-file into kernel again. The best parts of these commands is that they will load and save the rule-set in one single request. iptables-save will grab the whole rule-set from kernel and save it to a file in one single movement. iptables-restore will upload that specific rule-set to kernel in a single movement for each table. In other words, instead of dropping the rule-set out of kernel some 30,000 times, for really large rule-sets, and then upload it to kernel again that many times, we can now save the whole thing into a file in one movement and then upload the whole thing in as little as three movements depending on how many tables you use.
Ideally for these types of large firewall rules you would use ipsets instead of iptables chains as it is the fastest way of handling large rulesets but that is not supported natively by dd-wrt at this time.
I'll attach an example of my script in a bit as I'm on my iPad.
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Thu Apr 09, 2015 22:44 Post subject:
Here are examples of my IPv4/IPv6 geo-blocking and TOR exit node blocking scripts.
Note there are additional lines in the scripts used for reporting and are not needed for simple blocking. I have additional scripts to block static IPs and report blocked packets and bytes which I have not included.
Pay attention to where the chains are inserted into the iptables rules as you want them to be inserted after the established & related state rule so that they are not processed needlessly and to allow LAN access to blocked IP addresses.
For IPv6 you would also want to ensure the rules are placed after the accept echo request rules
Execution times for these scripts are measured in seconds
**** sample scripts deleted to avoid confusion
Last edited by JAMESMTL on Mon Dec 14, 2015 5:47; edited 1 time in total
Nice addition jamesmtl. I'll take a look at your layout. One thing I have noticed so far is 14k rulesets in iptables runs terrible on the R7000 once you start putting any kind of load through it. 1400 seems to run just fine. I'll have to find that "sweet spot".
Here are examples of my IPv4/IPv6 geo-blocking and TOR exit node blocking scripts.
Note there are additional lines in the scripts used for reporting and are not needed for simple blocking. I have additional scripts to block static IPs and report blocked packets and bytes which I have not included.
Pay attention to where the chains are inserted into the iptables rules as you want them to be inserted after the established & related state rule so that they are not processed needlessly and to allow LAN access to blocked IP addresses.
For IPv6 you would also want to ensure the rules are placed after the accept echo request rules
Execution times for these scripts are measured in seconds
Thanks for posting. Could you post a stripped down version of your scripts just for blocking? Also, what purpose does the TOR script serve? If I am not running IPv6, can I just comment out the IPv6 stuff? Could you also post your counter script?
JamesMTL, I made the changes you suggested and it works great. iptables-restore loads really fast (0.77 seconds) for 14k rows. I had not moved the -j below the state RELATED,ESTABLISHED. Moving that took care of my speed issue.
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Fri Apr 10, 2015 17:31 Post subject:
@badmoon
Your line inserting the block chain into the input table
iptables -I INPUT 6 -j countrydrop
Should really be
iptables -I INPUT 6 -i vlan2 -j countrydrop
Where vlan2 is the WANIF
The reason for doing this is to strictly limit parsing the block chain to incoming requests over the WAN. The way it is now all connections being established from the LAN to the router are forced to be evaluated by the block chain.
Example every time you want to access a website your computer will need to do a DNS lookup and that connection between the computer and router will needlessly be evaluated.
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Fri Apr 10, 2015 17:44 Post subject:
@bird333
I'll add a stripped down version and my counter reporting script to the examples. However if your just looking for straight IPv4 badmoon's script should work just fine.
The TOR exit mode blocking script is used to block request to your router originating over the TOR network
Hmm, would that cover outbound to a blocked country? After you make the outbound connection, wouldn't anything inbound be considered established and therefor bypassed.
JAMESMTL wrote:
@badmoon
Your line inserting the block chain into the input table
iptables -I INPUT 6 -j countrydrop
Should really be
iptables -I INPUT 6 -i vlan2 -j countrydrop
Where vlan2 is the WANIF
The reason for doing this is to strictly limit parsing the block chain to incoming requests over the WAN. The way it is now all connections being established from the LAN to the router are forced to be evaluated by the block chain.
Example every time you want to access a website your computer will need to do a DNS lookup and that connection between the computer and router will needlessly be evaluated.
