Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] firewall testing



On 6/17/2014 4:31 PM, Tom Metro wrote:
> Given the complexity of firewall rules, they're highly error prone. A
> small typo could easily open up a hole.

I've not found this to be the case. My experience with implicit deny
firewall policies is that:

Every firewall rule except for the final deny all rule open holes.
That's what firewall rules do.

A rule should not be complicated. If a rule is complicated then it is
trying to do too many things. For example:

  rule 1: allow ssh,http,https from *.local.domain,*privileged.domain
  rule 2: deny all

Rule 1 should be broken out into separate rules for each protocol and
each permitted host range. Six simple rules is easier to manage than one
complicated rule. If you're using a rule compiler (FireWall-1, others)
then it may optimize similar rules by combining them into a single rule
for the network filter. If so then let the compiler do that for you.
That's what it's for.

Most firewall mistakes are in chaining rules in the wrong order. For
example:

  rule 1: deny all
  rule 2: allow ssh from *.local.domain

rule 2 will never be invoked because processing stops at rule 1. Actual
typographical errors are more likely to prevent the rule from working at
all. In some cases it can open the wrong port or source or target
address. Keeping individual rule simple (see above) makes for easier
detection and correction of mistakes.


> Has the DevOps practice of automated testing reached firewalls?

Isn't that what Metasploit is for?

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org