RFC: my firewall ruleset(s)

Chuck Swiger cswiger at mac.com
Sun Oct 23 10:01:14 PDT 2005


Eric F Crist wrote:
[ ... ]
>> Ugh.  :-)  IPFW knows how to increment rule numbers all by itself;  
>> you can get rid of the "rulenum1=`expr $rulenum1 + 50`" stuff.
> 
> I do this so that I have sufficient space between rules for my own  
> sanity.  By default, IPFW numbers rules that increment by 1.  I have  a 
> need on occasion to add or remove a rule on the fly.  Perhaps there  is 
> a better way?

The default increment should be 100, and it is controlled by:

Automatic rule numbers are assigned by incrementing the last non-
default rule number by the value of the sysctl variable
net.inet.ip.fw.autoinc_step which defaults to 100.  If this is
not possible (e.g. because we would go beyond the maximum allowed
rule number), the number of the last non-default value is used
instead.

>> The breakdown of sh functions like setup_loopback, setup_keepstate,  
>> setup_ntp is fine if you want to play with shell scripts, but it  
>> scatters your IPFW rules into different places.  I'd rather see  
>> something that closely resembles what "ipfw list" gives you.
> 
> The reasoning behind this is so I have a single firewall script for  all 
> of my servers. At some point in the very near future, there will  be a 
> cron job on each server the pulls the current script from a  central 
> source.  Depending on the rc.conf entries on that server, the  firewall 
> script will be executed accordingly.  This allows me to edit  one script 
> and have it apply to multiple systems.  I'm calling the  functions for 
> basic components, rather than writing the whole thing  out each time.

Large-scale firewall deployments (think Cisco Enterprise Manager, or Edition, 
or whatever it's called) use such techniques to manage hundreds or thousands of 
firewalls, but they have several weaknesses, in particular the central 
distribution server becomes a target, which, if compromised, can then be used 
to compromise all of the firewall boxes pulling down rulesets.

One of the whole reasons for setting up multiple firewalls and multiple 
rulesets is to obtain "defense in depth".  Using a central config mechanism 
contradicts that design intention.

Therefore, I am convinced that a firewall ought to be self-contained in terms 
of enforcing a security policy, and should have as little dependence on any 
other host as practical, none at all, if possible.  Other opinions are 
possible, but Microsoft's domain-aware firewall and proxy box is a good example 
of what this can lead to.

>> You could chain several ports together into a list rather than  
>> listing them all seperately as individual rules, IPFW will end up  
>> doing less work.
> 
> Is this a 'good' way to do things?  The server in this instance has  
> really nothing else to do, save serving up a couple website with low  
> traffic.

It's more efficient from the standpoint of IPFW workload, but if the traffic 
volume is low, go with whatever design seems the easiest to work with and 
understand.  I find something like this:

# block all NetBIOS, domain-server, UPnP traffic
add deny log tcp from any to any 135-139,445,5000

...to be more clear than 4 seperate lines, YMMV.

>> You have anti-spoofing for the lookback, lo0 interface, but not for  
>> your other interfaces.  You should add anti-spoofing rules, and  also 
>> block strict and loose source routing [1]:
> 
> Point taken.  I pulled those rules from the default script that ships  
> with FreeBSD.  I did a brief google search on the strict and loose  
> source routing.  Can you share more information?
> 
>> # Stop strict and loose source routing
>> add deny log all from any to any ipoptions ssrr
>> add deny log all from any to any ipoptions lsrr

Sure.  In the early days of TCP/IP networking, people didn't always have 
conventions like default routes and routers which could figure out where to 
send traffic for any destination, so there is a mechanism for routing traffic 
directly, hop by hop, which supercedes the normal behavior of routers and many 
firewalls.  It conceptually resembles the bang-path notation used for UUCP 
email before SMTP email using domains via DNS was available.

It can be used to pretend that traffic from outside your network came from an 
inside IP, or from the firewall itself, which often lets that traffic go 
through.  In practice nowadays, the LSR and SSR options are pretty much *only* 
used for malicious traffic, except once in a while by people writing a TCP/IP 
stack who are testing the option handling code.

See page 15 & 17-20 of RFC-791, http://www.rfc-editor.org/rfc/rfc791.txt:

     The following internet options are defined:

       CLASS NUMBER LENGTH DESCRIPTION
       ----- ------ ------ -----------
         0     0      -    End of Option list.  This option occupies only
                           1 octet; it has no length octet.
         0     1      -    No Operation.  This option occupies only 1
                           octet; it has no length octet.
         0     2     11    Security.  Used to carry Security,
                           Compartmentation, User Group (TCC), and
                           Handling Restriction Codes compatible with DOD
                           requirements.
         0     3     var.  Loose Source Routing.  Used to route the
                           internet datagram based on information
                           supplied by the source.
         0     9     var.  Strict Source Routing.  Used to route the
                           internet datagram based on information
                           supplied by the source.
         0     7     var.  Record Route.  Used to trace the route an
                           internet datagram takes.


[ ... ]
>> You should use the log command more when developing a ruleset, to  see 
>> what traffic you are blocking or permitting, until you've  gotten your 
>> rules and network finalized.
> 
> Is there a way to direct different rules to different facilities or  log 
> files?  This is the primary reason I have not enabled logging more.

You can probably change which facility IPFW logs to, and to change where that 
goes you'd change /etc/syslog.conf.  I don't think you can log individual lines 
to a seperate facility, but you can grep by rulenumber which works just fine.

>> [1]: This is known to hackers as the "how to go through a firewall  as 
>> if it wasn't there" IP option if you don't block these.  :-)
> 
> Thanks for the great input!  I'll work further to develop my script.   
> Part of my reason for getting so involved with the shell scripting on  
> this ruleset is so that I have an actual project with a purpose in  
> front of me to develop my scripting abilities.

You're welcome.

-- 
-Chuck



More information about the freebsd-questions mailing list