Changing activation policy
Phil Whineray <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.firehol.user,gmane.comp.security.firewalls.firehol.devel |
|---|---|
| Message-ID | <20120519165315.GA9261@pdw-compaq> |
For sanewall I think I should change the activation policy for the FORWARD chain from ACCEPT TO DROP. Could people please let me know if this will adversely affect them and if possible test what effect it has? Just add to the top of your config: SANEWALL_FORWARD_ACTIVATION_POLICY=DROP If you are using firehol the equivalent would be to add: FIREHOL_FORWARD_ACTIVATION_POLICY=DROP There are two other policies for INPUT and OUTPUT, also set to ACCEPT during activation. This as-designed, to avoid intefering with establish connections whilst restarting and eliminated the risk that the host becomes inaccessible to the admin if something goes wrong whilst restarting the firewall remotely. However, when using the "all" service the rules generated for the reverse direction of flow ACCEPT any related packet, thus: route all accept for an outgoing router creates a firewall which permits any _incoming_ traffic for a connection which has already been established. As is necessary to make the rule work. In combination though, there is a short window when the firewall is being constructed during which external hosts will be able to connect to a local server and that that connection will not be severed once the firewall is complete. Individually specified services do not suffer from this problem because they perform a check on the related traffic to ensure it belongs to an accepted service, so the connection will be severed shortly after it was started, which is how FireHOL is documented as working. If anyone (me at home, for instance) is using "route all accept" on a gateway this adds a same risk for ingress traffic. The FireHOL documentation warns against using "client all" on production servers but not "route all". By changing the forward activation policy I hope to close this gap where it matters most (on gateway firewalls) but not add to the risk of failure (since to restart the firewall remotely the connection in question must have its traffic matched by INPUT and OUTPUT). This will interfere with existing connections but my hope is that DROPing will mean that the packets are retried as normal (for TCP, anyway) so things should not be too badly affected. The truly paranoid may want to set: SANEWALL/FIREHOL_INPUT_ACTIVATION_POLICY=DROP SANEWALL/FIREHOL_OUTPUT_ACTIVATION_POLICY=DROP to be sure. Regards Phil ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/