Hello!
Short question:
Could not find out how to test the firewall in the luci webinterface before saving the confiiguration.
(On other systems i usually do this with a timed reboot to prevent locking me out with misconfigured firewall rules)
Thank you in advance for any hint!
Robert
What do you mean by test?
The web GUI displays the proper order of the firewall rules before needing to save or apply.
Once an iptables firewalls rule is committed, it's operational. If you don't want to lock yourself out of the router, you must avoid making erroneous firewall rules.
You have three options to choose from in the LuCI web GUI (in this order):
If you're having issues with iptables and locking yourself out, you should perhaps make explicit INPUT rules for access to the web GUI and SSH. Hope this helps.
Some OS implementations have a "failsafe" script that can be use when applying rules. The script captures the current rules, apply new rules, and, if a "console interrupt" is not seen within a timeout period, automatically reverts to the previous rules. Such scripts can be very helpful for devices that are only accessed through the network.
One could likely write such a script using uci. Hooking it into LuCI would be more challenging.
Thank you for all suggestions!
The link from jow looks very promising.
But how do you configure your firewalls right now?
To some routers i have to drive the whole day if i make a mistake.
that is not really practical.
In the meantime i could deactivating luci-firewall an write my rules in a "boot-script" which is running at boot time.
then i could make a "test-script" with timed reboot.
if it works i could copy "test-script" to "boot-script".
Sill leaving the possibility to copy the wrong script...
Any better workaround's?
Can i run fw3 on a different configfile?
Robert
Somthing like IOS:
reload in 0:03
modifying "running-config"
see if it works
copy running-config startup-config
Personal I’d use GNU screen, then run sleep 120; reboot in it and configure the firewall in another terminal session or via LuCI.
Alternatively something like cp /etc/config/firewall /etc/config/firewall.bak && sleep 120 && cp /etc/config/firewall.bak /etc/config/firewall; reboot to restore the config on failure.
To cancel the process press Ctrl-C or run killall -9 screen.
Sorry i'm a newbie in iptables!
is it really foolproof to put somthing like:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
in the first row of "/etc/firewall.user"
Is it not possible to overwrite these rules in the webinterface?
Robert
If you desire to prevent lockout, yes...also, the rules you noted were not correct to prevent a lockout:
Prevent lockout from WAN:
iptables -I FORWARD -p tcp --dport 22 -i eth0.2 -o br-lan -j ACCEPT
iptables -I FORWARD -p tcp --dport 80 -i eth0.2 -o br-lan -j ACCEPT
Prevent lockout from LAN:
iptables -I INPUT -p tcp --dport 22 -i br-lan -j ACCEPT
iptables -I INPUT -p tcp --dport 80 -i br-lan -j ACCEPT
I advise you understand the ordering of rules and the differences between the usage of the -I and -A arguments in iptables. Also understand that the entire firewall is reloaded each time a save is made, so the rules will always be loaded in the same order.
See:
and
You can also place the rules at the very top of the web interface, that would make the rules first - and prevent lockout. I advise not using /etc/firewall.user unless you're unable to add the rules through the LuCI web GUI.
Remember to remove these rules after you're comfortable you won't lock yourself out.
Thank you for correcting my rules.
When i put the rule in the webinterface i can delete it by accident.
I'd like to put the rules in some other place, if this makes sense.
Would "/etc/rc.local" be a better place?
Robert
It makes sense...I suppose I just don't understand how you'd accidentally delete the rules you're planning to add...you could just add comments to help you remember.
NO, if you insist on placing the rules in a location other than the LuCI web GUI, the proper place is in fact:
/etc/firewall.user
Be sure you understand iptables, and the -I and -A arguments if you prefer to use this file. You have to properly write the rule (in the proper order and arguments) for it to prevent your lockout.
Ok I'll do so!
Thank you again for your very helpful suggestions!
I really appreciate it.
Robert
Wanted to try out this failsafe mechanism but could not get it to work.
Do you need to activate any special options in menuconfig?
(i only activated luci)
patch went through without errors...
Robert
If wanting to ensure a rule is processed first, above all others in any config, use -t filter -I <chain> #.
iptables -t filter -I INPUT 1 -p tcp --dport 22 -i br-lan -j ACCEPT
iptables -t filter -I INPUT 2 -p tcp --dport 80 -i br-lan -j ACCEPT
fw3, issue: fw3 printI went through the iptables manual and it's not easy to unerstand for me.
(I need more time...)
Is there any possibility to crate a rule for all interfaces?
I also don't understand why you suggest only INPUT rules.
How does the ssh-packet finds it's way back?
Robert
The rules were just an example, and to keep things sane, I simply used the rules @lleachii used as an example in their previous post.
iptables commands in /etc/firewall.user should only be used when it's either not possible, or not efficient, to utilize /etc/config/firewall for an arbitrary rule.
iptables' man page explains what each command parameter does and how to utilize them.
iptables --help
If you'r looking to create a rule for WAN SSH access, perform the following:
/etc/config/firewall#
##::[[--- OpenWrt Firewall Config ---]]::##
####################################################
##----- Scripts -----##
####################################################
config include
option path '/etc/firewall.user'
####################################################
##----- NAT Redirects -----##
####################################################
# SSH #
#---------------------------------------------------
config redirect
option target 'DNAT'
option proto 'tcp'
option src 'wan'
option src_dport '43775'
option dest 'lan'
option dest_ip '192.168.1.1'
option dest_port '22'
option name 'Allow Redirect WAN -> LAN (SSH)'
Yes, but I highly advise you understand iptables at this point - to write the rules yourself. You are entering dangerous security paradigms to open your admin ports to all interfaces.
First, I also suggested FORWARD, if on the WAN. But I have only suggested LAN INPUT rules because your firewall is configured by default to allow OUTPUT. So, unless you've completely erased or altered your default rules, this should be the case.
If you are referencing routing of the packet to its destination, this thread has only covered firewalling. If you are not clear on Linux (OpenWRT) routing, I might suggest creating another thread.
Don't feel bad, I personally find the iptables syntax close to completely unreadable. This is one of the reasons why the LuCI interface is relatively simple on its firewall options -- meets most users' needs.
One recommendation:
iptables works, and how they will impact your securityRemember that in the unlikely case that it is a firewall rule that "locks you out" of the router, you can boot into "failsafe" mode and access the router on 192.168.1.1 and "fix" what is messed up with the firewall.
I know, but the reason why am so picky on this topic is that i'v to drive a day by car to do this:(
@JW0914:
Thank you, i'v implemented your suggestion and opened only the lan port on "22"
and redirected the wan port to 22 on the device.
(guess it's because scripts trying to use port 22,
but i tried out myself to brute-force ssh and i could not imagine how such scripts really find out long passwords for a reasonable amount of hosts)
Robert
"One" is a "reasonable" discovery
Remote management, yes, I agree that making reasonably sure that you aren't locked out is a "good" reason.
Moving your outside port off 22 may help keep your logs cleaner, but is "security by obscurity". With the port-forward, you've changed a single-point configuration into now into a three-point one (WAN open port, forward port, LAN open port).