/etc/init.d/shorewall has the following depend clause : depend() { need net provide firewall } so it is started after the network, at the same time as all other network servers depending that have "need net". This creates an attack window where servers are running and the firewall is not protecting them. On the small-end system I'm building, dropbear, boa and openntpd are all running unprotected for a window that can last 50 seconds (time for the shorewall start script to execute). The depend clause should have "before net", like recent versions of /etc/init.d/iptables. Note that you should avoid using "detect" in /etc/shorewall/interfaces since it only works if the network interfaces are already up.
Hmm looks like it needs a "before net.eth0" to work. Maybe bug 70226 is related.
Anyone in netmon available for comment ?
Ramereth/netmon: please comment
NOTE: There are some "issues" when starting Shorewall before all interfaces are "up". Notably when using interface names in the /etc/shorewall/masq file. So you have a mini-dilemma: Start shorewall before net and remove any references in your shorewall config to interfaces that aren't up yet, or start shorewall after all the interfaces are up and have more flexiblity in some of the shorewall configurations.
"Note that you should avoid using "detect" in /etc/shorewall/interfaces since it only works if the network interfaces are already up." .. and I should more carefully read the previous comments.. sorry.
What about the following scheme, combining the best of both worlds: Use a very simple, restrictive initial firewall with iptables. This firewall should only let those packets through that are needed to get dynamically configured interfaces up (such as dhcp packets). The /etc/init.d/iptables script starts before any other network related scripts. Once the network is up shorewall takes over and (re)defines all firewall rules as desired.
Magnus: I like it... Want to try to write such a startup script ? netmon: It could be put as a shorewall DEPEND (triggered by a local use flag if needed)
Some more details on how to make a combination of /etc/init.d/iptables and /etc/init.d/shorewall work with the current scripts. The aim is to get an initial firewall started before the network is up and to use shorewall with network interface detection later. The initial firewall corresponds to the "stop" state of shorewall: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination This ruleset allows the local machine to establish all connections it needs to dynamically configure the network interfaces while blocking all connections initiated from the outside. It is later replaced when shorewall starts up. Installation howto: 1. Save the following into /var/lib/iptables/rules-save ################### initial firewall start ########################### *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [308:28160] [308:28160] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT #################### initial firewall end ############################ Note: you can also run "shorewall stop" and then save the output of iptables-save into the file. The above is a slightly cleaned up version of this procedure. 2. activate iptables startup script: rc-update add iptables boot 3. add shorewall to the default run level rc-update add shorewall default
my though was for the initscript to look for "detect" in the shorewall files and start before or after depending on that. pros: simple for the user to use shorewall how they want. will optimise for the best security if no detect is used will always work can warn user if it is started after cons: needs the dependancy cache to be updated if the config changes state (from "detect" to interface. - depscan.sh (add note to config file) parsing config files a bit difficult. (just do it)
Daniel: If the shorewall script contains "detect" and is then only started after the network is up it still leaves Koon's problem. A number of services are potentially unprotected if they are run before shorewall is up. Better to start an initial firewall unconditionally and let shorewall take over from there.
Magnus: I like your solution. I'll test it right now... Maybe the default iptables configuration should include your rules-save and SAVE_ON_STOP="no" (otherwise the default script would get overwritten when iptables is stopped).
SAVE_ON_STOP="no" would be an option, but if shorewall goes down before iptables, it sets itself into the stop state anyway and that state is then saved by iptables-save. It might be safer, though, to use SAVE_ON_STOP="no" to have a guaranteed state from which it is always started.
Pulling aliz and base-system as net-firewall/iptables is noherd. We are trying to solve the vulnerability window between network start and firewall start, which can be observed at least with shorewall, and probably with other firewall scripts. There are solutions to manually solve this, but it would be a good idea to find a way of doing this by default (i.e. emerge shorewall should not fetch a vulnerable by default configuration). Hence the security bug. Magnus Kessler has a good manual solution (comment #6 and comment #8) but I can't see how this can be automated to be a default config. aliz/base/netmon: Your opinion on this ?
netmon/base: *bump*
I personally like the solution from comment #6. Maybe an independent script can be added to protect the system during boot-up using iptables, whose rules shorewall flushes before putting its own.
not a base system issue
Perhaps there would be an other way of fixing this. Why not start shorewall directly after all interfaces are up but before any network service is started by considdering the metaservice net only running if not only all the interfaces are up but also shorewall is started. While this would not stop incomming traffic it could do no harm as nothing is listening to it.
(In reply to comment #15) > I personally like the solution from comment #6. > > Maybe an independent script can be added to protect the system during boot-up using iptables, whose rules shorewall flushes before putting its own. I agree with this one and as iptables comes up properly now with baselayout 1.12.x, I think this issue is resolved...
As we saw no objections and after a short talk to security -> marking as FIXED
