荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: Lg (创造人生的传奇), 信区: Linux
标  题: Firewalling with IPF
发信站: BBS 荔园晨风站 (Thu Feb 17 10:29:21 2000), 站内信件

Firewalling with IPF
Name:
Email:

Security Portal
Weekly Newsletter


Distributed Denial of Service FAQ

All About SSH

Closet Archives

Kurt Seifried, seifried@securityportal.com, for http://www.securityportal.com/

February 16, 2000 - IPF is the standard firewall for most BSD platforms, and
works on a variety of other operating systems, such as Solaris, IRIX and
earlier versions of Linux. The main advantage (there are other advantages too)
of IPF over most run of the mill OpenSource packet filters is that it is
stateful. The majority of packet filters, like IPFWADM and IPCHAINS are not
stateful, that is to say they don't know anything about the packet beyond it's
source IP / port, and destination IP / port. They cannot for example keep track
of outbound telnet connections, and only allow the returning packets in.
Stateless packet filters work relatively well, but in order to enable certain
protocols properly (such as DNS or FTP) you need to punch big holes in your
firewall (the alternative of course would be to use proxy servers, but this is
not always practical).

The first thing to do of course is get and install IPF, it comes with most BSD
systems, and is quite popular in Solaris as well. Unfortunately the support for
Linux seems to have lapsed with the 2.2 kernels, but if you've got a Linux
firewall still running 2.0.X you might want to give IPF a spin. If IPF didn't
ship with your system you will need to compile support into the kernel, create
the user space tools, luckily the install documentation that comes with IPF is
pretty specific and simple to follow. The following is a quick list of systems
that support IPF (ones with a * ship with it):

OpenBSD *
NetBSD *
FreeBSD (4.0 and up *)
BSD/OS
IRIX
Solaris (for Sparc and Intel)
Some basics
IPF behaves differently then many firewall packages, which can be a bit
confusing at first. Like most firewall packages it reads its ruleset from top
to bottom, however (without the "quick" keyword) it does not immediately drop
or pass a packet when it meets a rule that applies to it, instead it remembers
what the current status of the packet is (pass or block) so the last rule to
apply to it in the list is what decides will happen. You can of course emulate
simple firewall behavior by using the "quick" keyword, in which case the packet
is immediately blocked or passed. Needless to say this can create some very
complex rulesets, so I would advise using the "quick" keyword sparingly. All my
examples are based on an OpenBSD 2.6 box (it shouldn't matter but I thought I'd
mention it anyways), with the external interface being "ne3" (an NE2000 PCI
card) and the internal card "vr0" (a Realtek something or other 10/100 card).

The first decision (as with most firewall software packages) is to decide
whether to make your default policy to allow packets, or to deny packets.
Simply put, if the firewall does not know explicitly what to do with a packet
should it block it, or pass it? It goes without saying that a default denial is
safer then letting data pass by default, if you accidentally enable a service
on a server, then an outside entity (read attacker) can more likely access it
than if the firewall ruleset only allows what it is explicitly told to and
drops everything else. The following would be an example of a default allow
policy, put this at the beginning of your rules:

pass in from any to any
pass out from any to any
If you want to be a bit more paranoid you would use:

block in from any to any
block out from any to any
You can then start adding specific pass or block rules, for example to block
spoofed traffic from network addresses assigned for internal usage:

block in quick on ne3 from 10.0.0.0/8 to any
block in quick on ne3 from 172.16.0.0/12 to any
block in quick on ne3 from 192.168.4.0/24 to any
block in quick on ne3 from 127.0.0.0/8 to any
block in quick on ne3 from 0.0.0.0/32 to any
block in quick on ne3 from 255.255.255.255/32 to any
You probably want to use the quick keyword, assuming ne3 is attached to the
Internet since chances are you will not ever want to let these packets into
your network. You may wish to log them, for example:

block in log quick on ne3 from 10.0.0.0/8 to any
Personally I wouldn't bother logging these since by definition they are spoofed
attacks, and the effort involved in tracing them back to their real source
would be rather expensive for most people.

Default pass
If your default policy is to pass then you should at least block access to the
first 1024 ports, commonly referred to as the "privileged" ports. Your primary
concern will be making sure you block everything you need to, and blocking the
first 1024 ports will greatly simplify matters. You can block these ports
rather quickly by adding the following:

block in on ne3 proto tcp/udp from any to any port 0 >< 1025
This will block all data from ports 1 to 1024 inclusive for tcp and udp data.
You probably want to allow things like access to your mail server, and DNS
server:

#Allow port 25, SMTP
pass in on ne3 proto tcp from any to any port = 25
#Allow port 53, DNS
pass in on ne3 proto tcp from any to any port = 53
You can also use the service names (as they appear in /etc/services), I prefer
to use port numbers (I find numbers easier to read than names), and there is no
chance of someone editing /etc/services and messing things up (don't ask, I
have seen it happen though):

#Allow port 25, SMTP
pass in on ne3 proto tcp from any to any port = smtp
#Allow port 53, DNS
pass in on ne3 proto tcp from any to any port = domain
You might also want to block X windows traffic for example, which uses port
6000 in increments of one for each X server running on a machine typically:

#Block X windows
block in on ne3 proto tcp from any to any port = 5999 >< 6011
the above rule would block ports 6000 to 6010, effectively any "legitimate" X
server. Or if you wanted to let a certain network (say the local university)
connect via X to your box (so you can run applications on your big AIX account
and display them locally for example) you would use something like:

#Block X windows
block in on ne3 proto tcp from any to any port = 5999 >< 6011
#Allow X from the local university, 1.2.3.x
pass in on ne3 proto tcp from 1.2.3.0/24 to any port = 5999 >< 6011
Default block
If your default policy is to block then your main concern will be enabling
various services, and ensuring the holes you are making in the firewall are not
too large. Having a stateful packet filter makes this a lot simpler. Allowing
access to most tcp based services is simple, to allow access to email for
example simply add:

#Allow port 25, SMTP
pass in on ne3 proto tcp from any to any port = smtp
However things get trickier with protocols like DNS (which is UDP based, and
hence stateless) and FTP (which typically has the server making a connection
back to your client machine). For example to allow DNS queries to work, without
letting any remote machine talk to you from port 53 (as you'd have to do with a
stateless firewall):

#Allow DNS queries
pass out on any proto udp from any to any port = domain keep state
To allow access to your webserver you can use:

#Allow inbound www traffic
pass out on any proto tcp from any to 1.2.3.4/32 port = 80
But you can do it somewhat more securely by allowing only SYN packets in,
keeping state (so after the initial SYN packet the following packets in the
stream will be allowed), and allowing for fragments to make it through:

#Allow inbound www traffic but only for properly established connections
pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80 flags S
keep state keep frags
You should use these advanced options as much as possible, they will severely
limit the types of data and packets an attacker can use to probe and attack
your network.

Some interesting rules
IPF makes it very easy to deal with some of the more esoteric (read likely to
be generated by an attacker) packet types found on the Internet. Fragmenting
packets on purpose is becoming a very popular tactic for slipping data past
detection systems, as well there are several attacks based on flooding a target
machine with fragments that can never be reassembled, thus using up a lot
(sometimes all) of the system's resources:

#block ip fragments
block in all with frag
#block packets that are missing data (most likely hostile)
block in proto tcp all with short
be careful however, packets can become legitimately fragmented, and depending
on your network configuration this may result in some problems. One thing that
is good to block for security reasons is ICMP. ICMP has all sorts of
interesting applications for attackers, however you may not wish to completely
block it, ping and traceroute are very useful tools, to allow them and block
other types of ICMP:

pass in quick on ne3 proto icmp from any to any icmp-type 0
pass in quick on ne3 proto icmp from any to any icmp-type 11
block in quick on ne3 proto icmp from any to any
There are dozens of examples of cool things you can do with IPF in the IPF
HOWTO, I suggest strongly that you read it.

Other features
"And that's not all folks, with your download of IPF you will receive not one,
but two ways of passing packets through the ruleset."

To improve the efficiency (and readability) of your rules you can create groups
of rules (using the "group" keyword), and shunt packets to certain groups if
they match a rule. For example, you might take all packets bound for your
webserver farm and subject them to somewhat more specialized inspection than
those going to your internal corporate LAN. You do not want a 400 rule long
ruleset (not inconceivable) that each packet has to fully navigate before the
firewall decides what to do with it. Using groups can increase performance with
minimal effort.

One of my favorite keywords in IPF is "fastroute". "fastroute" passes the
packet through without decrementing the time to live (TTL) counter on the
packet. Each packet has a set TTL so that it cannot get caught forever in
routing loops, and so on. "fastroute" can render the firewall invisible to
attackers if done correctly, and if you are on the edge of a network (say 15
modem links strung together crossing the desert) you probably want to get as
many packets through, and if dropping them because their TTL has expired can be
avoided you might do so.

Advice on creating rulesets
Sit down with a pencil and paper first and write down which services you want
to offer to the world (DNS, SMTP, etc.), which services you want to offer to
select machines (i.e. HTTPS to an ISP you use for dialup so users can check web
based email). Then list which services you will be running but do not want
people to access remotely (i.e. IMAP, NIS). Decide whether you want a default
pass or block policy, and then create your rules accordingly. Document what you
did and why you did it (this will make your life much easier in the future).
Walk through the rules with imaginary packets, would it go through or be
blocked? You may wish to put the "log" keyword on all your rules initially so
you can more easily monitor what is happening to packets (this will generate a
HUGE log file, be careful). Also what does your corporate security policy, and
privacy policy mandate (if you don't have one that's the next thing you might
want to look into)? Some do not allow for logging of user activity, however in
the US, where employers have been found responsible for action users commit
while using their networks/etc, you may wish to log certain types of activity.

A couple of tricks to remember: use netstat (which ships on almost every UNIX
platform, and even NT) to list which ports are in use, the interesting ones are
typically in the "LISTEN" state:

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  *.22                   *.*                    LISTEN
tcp        0      0  *.995                  *.*                    LISTEN
tcp        0      0  *.873                  *.*                    LISTEN
tcp        0      0  *.21                   *.*                    LISTEN
udp        0      0  1.2.3.1.123            *.*
udp        0      0  127.0.0.1.123          *.*
udp        0      0  *.123                  *.*
For example you can see this machine is listening on ports 22 (OpenSSH), 995
(SSL wrapped POP server), 873 (rsync) and 21 (ftp). It is also running a time
server, udp port 123. You can also scan your machines (in the ports tree nmap
is in net, strobe and portscanner are in security), you should definitely do
this once the ruleset is in place, what you see is what most attackers will
see.



Kurt Seifried (seifried@securityportal.com) is a security analyst and the
author of the "Linux Administrators Security Guide", a source of natural fiber
(like beans) and Linux security, part of a complete breakfast (just like a dead
bat =).

Related links:

http://coombs.anu.edu.au/~avalon/ - primary site

http://coombs.anu.edu.au/~avalon/examples.html - excellent document with
examples

http://www.obfuscation.org/ipf/ - IP Filter Based Firewalls HOWTO



--
☆ 来源:.BBS 荔园晨风站 bbs.szu.edu.cn.[FROM: bbs@202.96.191.124]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店