mtchang / rt-n56u

Automatically exported from code.google.com/p/rt-n56u
0 stars 0 forks source link

Easier way to edit default IPTables rules. #847

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Currently from what I can see the default IPTables rules can't be edited once 
the firmware has been compiled (correct me if I'm wrong). This is great except 
for the fact that I need to extend on these rules to work with my IPSet 
blacklist more efficiently.

At the moment I am using the following script to scan the syslog for dropped 
IP's (from the default IPTables rules) among other things on a cronjob set 
every hour. This works great but isn't ideal when you are being hit by hundreds 
of thousands of IP's and syslog only lists the 1024 most recent lines.

What I would like to-do is add the following line to certain default IPTables 
rules to dynamically update my IPSet blacklist rather then having to scan 
syslog for them which isn't ideal in such cases.

"-j SET --add-set Blacklist src"

I am unsure how possible or easily done this may be due to the fact the rules 
are coded in to work with the GUI options and whatnot, but a way to modify 
these either from the GUI or SSH so I could do as stated above would be great 
and hopefully could help others wanting to extend on the default rule-set.

Thanks again for all your hard work supporting this router.

IPset script - http://pastebin.com/YFNJywrC

Original issue reported on code.google.com by c_u_late...@hotmail.com on 15 May 2013 at 3:57

GoogleCodeExporter commented 9 years ago
IPSet tables filled slow, best way to fill IPSet tables in script
/etc/storage/started_script.sh (called in background after router started)

iptables rules needed reload in  
/etc/storage/post_iptables_script.sh

/etc/storage content needed save via
mtd_storage.sh save 
or via WebUI (>= -058 build)

Original comment by andy.pad...@gmail.com on 16 May 2013 at 9:06

GoogleCodeExporter commented 9 years ago
Thanks for the reply. I don't think I explain my issue clearly so hopefully you 
understand what I'm trying to achieve.

I know about these files and utilize them in conjunction with the script above 
which I have modified today to use the IPSet save/restore functions to be more 
efficient with larger lists (takes seconds to restore thousands of IP's rather 
then adding them manually from a list which I was previously doing).

Now currently my setup is as follows;

1) "/opt/bin/firewall" is executed on start-up which restores the IPSets and 
creates new IPTables rules
2) A cronjob runs every hour and scans "/tmp/syslog.log" for "DROP" entries and 
adds the IP's to the blacklist and saves it.

This works on a small scale, but it isn't ideal in a situation where a random 
botnet is flooding random ports with thousands of IP's every second as syslog 
only has a certain number of entries to prevent over-sized log files. Here's an 
example of what my syslog looks like after seconds of being attacked;

/opt/home/admin # cat /tmp/syslog.log | grep DROP | wc -l
1038

As you can see, it takes merely seconds/minutes for over 1038 lines of my 
syslog to be DROP messages from the kernel due to the attacking botnet's size.

What I want to-do is edit some of the default IPTables rules with the following 
so rather then having to scan syslog for dropped messages IPTables will update 
my IPSet blacklist dynamically which would be a much cleaner solution.

"-j SET --add-set Blacklist src"

At the moment I believe that the default rules are coded into the firmware and 
at some point during the boot process copied to;

/tmp/ipt_filter.default
/tmp/ipt_filter.rules

The problem is they can't be modified after building the firmware and nothing 
from /tmp is saved on reboot. I am aware I can use IPTables to destroy and 
recreate certain rules with the extra addition but I feel this isn't a good 
long term solution.

So what I am asking is a way to edit the rules listed in /tmp that will carry 
over if the router is rebooted so that IPTables can self manage the blacklist 
dynamically when IP's are dropped which at this point I believe is not 
possible. Below is my updated script which should give you a clearer idea of 
what I'm trying to achieve.

http://pastebin.com/2mMj5NLU

Lines 144 - 152 are how I am setting up my blacklist on reboot

Lines 80 - 95 are how I am currently scanning the syslog on a cronjob to update 
the IPSet blacklist

Hopefully this makes sense. Thanks again.

Original comment by c_u_late...@hotmail.com on 16 May 2013 at 11:00

GoogleCodeExporter commented 9 years ago
Seems like maybe I was over-thinking a solution to have IPTables manage my 
IPSet blacklist dynamically, solved the problem by adding a rule to the logdrop 
chain and removing the default rules manually.

iptables -D logdrop 1
iptables -I logdrop -m state --state NEW -j SET --add-set Blacklist src

Feel free to close this issue.

Original comment by c_u_late...@hotmail.com on 16 May 2013 at 4:01