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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
