UNIX Security Firewall
Tom
firewall to deploy on a small unix system?
Ean Kingston
>
> Hey guys, I've got little security experience. What would be the best
> firewall to deploy on a small unix system?
The word 'best' is very subjective. It depends a great deal on what you
want to do with your firewall, your budget, your previous experience
(flavours of UNIX, etc.), your timetable.
If you want to learn about the how and why of firewalls, I would
suggest any of these:
IPFW on FreeBSD
IPFilter on FreeBSD, OpenBSD, Solaris (sparc and intel) and many more.
netfilter on Linux (or whatever the new Linux firewall is called).
Don't bother with ipchains on Linux.
The latest release of these firewalls all include NAT and statefull
inspection. I run IPFW on FreeBSD at home (which also has 'traffic
shaping') and have setup IPFilter on Solaris (both Sparc and Intel) for
clients with a budget.
--
Ean Kingston E-Mail: eanki...@home.com URL: http://www.hedron.org/
I am currently available for contract work in Canada. I have excellent
skills in UNIX and Network administration with a strong background in
computer security. If this fits your needs check out my resume, which
is available online at "http://www.hedron.org/Resume.rtf".
ji...@vega.starshine.org
> Hey guys, I've got little security experience. What would be the best
> firewall to deploy on a small unix system?
This question cannot be answered. There is far too great a gap
between the information provided and the information that has been
requested.
First observation: if you are not confident of your expertise
in this field then you should ask where to learn more or how to
find some qualified assistance.
If this is a business system you should look to hire a consultant
(and ask how to qualify prospective consultants as there are
plenty of charlatans in the business). If this is for personal
use or for a small non-profit you might find someone to volunteer
their expertise. A good consultant will ask lots of questions about
your requirements (as in policies) *and* will listen to your needs.
A great consultant will go beyond recommending and/or implementing
systems that enforce your policies and will (offer to) teach you about
the subject as they do so. (Feel free to make that an explicit
requirement). A bad consultant will try to keep it all mysterious,
recommend a cookie cutter solution ("just like we do it for all our
customers") and generally try to ensure that you'll need to call them
back frequently for maintenance and upgrades.
When I'm consulting I routinely recommend to my customers that they
have pairs of mutually disinterested consultants; one to implement
and another to audit. I will fulfill either role (and will teach
as I go). I think this is particularly important for security work;
implementation/configuration and auditing are vital but distinct
tasks that should NOT be done by the same parties.
Back to your request: there is no such thing as a "firewall."
The term "firewall" is a buzzword used by many different companies
to sell products; and by many people to describe vastly different
combinations of software, hardware, and practices. There are
products called "firewalls" which are usually routers or application
gateways (or proxies). (Some people will undoubtedly nitpick the
terminology, here; but let's focus on the concept).
Any modern router will offer packet filtering. Each router has
its own language for describing the packet filtering rules that
it can enforce. Any version of UNIX can be configured as a router,
and most modern flavors of UNIX also include packet filtering
features or have readily installable software which can provide
packet filtering. (For example Linux has, over the years,
supported ipfw/ipfwadm, ipchains, and the new iptables natively,
in its kernels; and has supported Darren Reed's ipfilter package
among others).
Any version of UNIX can also support application level proxies
(programs which accept connections on selected interfaces or
from selected networks, selectively relay requests over that
channel to other interfaces or networks and relay back the
results).
The destinctions between "packet filtering" and "proxying" have
blurred over the years, since many products and packages are
hybrids. For example the IP masquerading features in many
routers (and in Linux) must go beyond simple IP header re-writing
and "reach into the payload" to support some protocols such as
FTP, IRC, RealAudio, etc. Under Linux these are accomplished
through a fair number of application specific kernel modules.
A good "firewall" is comprised of packet filter components at
the border and interior routers/interfaces, and a set of
proxies on a "DMZ" network/interfaces which is squeezed between
the interior and exterior networks. In some/many cases this
is accomplished by a single system with three networking
interfaces (called a "three-legged firewall"). Other cases
use pairs of separate routers each of which have two interfaces
such that they share one network segment (the DMZ) while one
(the border or "edge" router) connect to the external network(s)
(usually the Internet) and the other connects to the internal
network (LAN) or internetwork.
There are often redundant or conceptually adjacent "mirrors" of
these "firewalls" which provide for additional capacity and
redundancy. So a "firewall" might consist of a pair of
three legged systems or a quartet of dual-homed routers;
and some number of "bastion hosts" on the DMZ. Naturally the
bastion hosts might be duplicated for redundancy and capacity
reasons. Ideally the DMZ would consist of clusters or farms
of systems such that each cluster would be dedicated to a specific
task: NTP, DNS, mail exchange, HTTP/web (public) HTTP/web (extranet)
etc. This provides maximal isolation (systems on the DMZ are
"mutually untrusting" --- none of them accepts traffic from
any of the others) and considerable scalability and redundancy.
In larger organizations there may be more elaborate requirements
with multiple different DMZ segments (possibly a different
isolated network segment for each business partner, and segments
for various remote offices, departments and classes of telecommuters).
It's also becoming common for larger and even mid-sized organizations
to have "internal firewalls" which protect the server rooms from
the "client LANs." (Especially important to prevent the effects of
a misconfigured or malicious client from "stealing" a server's
IP address; which can be eliminated by using different IP address
blocks and network segments for servers and clients).
So you can see how the question: "which firewall should I install
on my UNIX system?" is somewhat meaningless. Of course I've
described the larger, more professional configurations.
At the bottom end of the scale you could simply use a common
Linux system running a 2.2 kernel and the ipchains utility that
comes with any mainstream distribution. You could use a 2.4
kernel and the netfilter/iptables support for it. iptables has
some very nice improvements over 2.2 (something that amounts to
"stateful packet filtering" support though it's not called
by that phrase possibly due to legal/trademark and patent
concerns, for example). There are even netfilter modules that
allow one to filter traffic based on the MAC/frame addresses
(a bit lower level then TCP/IP). There are also a number of
"port forwarder" and "packet relayer" proxy utilities for Linux
and several SOCKS compatible and FWTK (firewall toolkit)
inspired proxies as well.
A single Linux system can be used as a simple "firewall" or
stacks of Linux boxen can be used as components throughout a
more complex firewall. Of course one should be wary of any
"monoculture" solution. If you have a multi-layer firewall
(recommended) then you should use different types of systems
for at least one of the layers. If consider your Cisco routers
with their extended ACL packet filters to be one layer, then
use Linux or BSD as a different layer. If you have Linux
or BSD on x86 hardware as routers on an outer layer, use the
other, preferably on some other platform, SPARC, PowerPC,
etc, on the next layer.
Technodiversity, like biodiversity, can limit the extent of
any single bug.
Of course there's a lot more to say about firewalls then I
could put in a USENET posting. There's much more to the
subject than I know.
I'd recommend O'Reilly's _Buiding_Internet__Firewalls_ (2nd
Ed., Chapman, Zwicky, and Cooper) and _Internet_Firewalls:_
_Foiling_the_Wily_Hacker_ (Addison Wesley, by Cheswick and
Bellovin) as the best introductory texts on the subject.
Cheswick and Bellovin's book is somewhat dated, and I've been
waiting for the rumored 2nd edition. If you only read one of
them, go with the former. For general UNIX security (which also
covers Linux to a >90% applicability) I'd start with O'Reilly's
_Practical_Internet_and_Unix_Security_ (2nd Ed., Garfinkel and
Spafford).
--
Jim Dennis
Jim Bash
> Don't bother with ipchains on Linux.
>
> The latest release of these firewalls all include NAT and statefull
> inspection. I run IPFW on FreeBSD at home (which also has 'traffic
> shaping') and have setup IPFilter on Solaris (both Sparc and Intel) for
> clients with a budget.
Would you be willing to expand a little on why not ipchains with Linux? It
seems to be the most common recomendation around here (actually that was a
couple years ago and I haven't kept up to date). All my experience is Sun
OS4x and Solaris but I was considering adding a linux intel box in front to
filter between our internal machines and our web server/anonymous
ftp/zserver, etc box. (I've stayed away from linux so far because there
seem to be SO many bugs that come to me via CERT, bugtraq, etc.--and I know
I'd have trouble keeping up with them:-)
I'm reasonably techie but sysadmin has no budget in my university research
lab so I try to pick this stuff up in my spare time. I had actually assumed
I could use ipfilter with Linux, perhaps part of what you are saying is
I'll only be able to use ipchains? Sorry if this is in a FAQ, point me in
the right direction and I'll RTFM :-)
TIA for info. URLs that will help bring me up to speed would be fine.
jim b
Jim Bash
per ipfilter FAQ at http://coombs.anu.edu.au/ipfilter/ipfilfaq.html#Linux
ipfilter isn't available and doesn't work under linux, with the exception
of Red Hat 4.2 (but "Is expected to work reasonably well with any 2.0.31+
kernel, on a
non-glibc system). Being Sun workstation oriented I don't yet know what the
last sentence means in terms of linux, but I'll get there :-)
jim b
Alex Witt
Jim,
I think one other reason is that I do not believe that IPCHAINS does
stateful inspection. Though I have not worked with it much, if it is a
purely static filter, you need to leave many more holes open to allow
things to work than you do with a stateful firewall. IPTABLES,
available in Linux 2.4.x kernels does support stateful inspection.
Alex
ji...@vega.starshine.org
However, one should beware of stateful inspection. It has
its limits and some systems (such as early Linux 2.4.x netfilter
and iptables) have implemention bugs (i.e. the use of the
"RELATED" target could be tricked through bogus/unvalidated
FTP PORT commands into opening "un-RELATED" connections
through; possibly to un-RELATED hosts).
Stateful inspection and "related" handling are hacks to
support active FTP and similarly bad protocol designs. *Many*
firewall software bugs have been found in early attempts to
support active FTP. It remains one of the biggest headaches
to network security specialists and many networks simply
implement a policy requiring all FTP to be in passive mode or
through old-fashioned application layer proxies.
Often in security design and strategy "simpler is better."
--
Jim Dennis
Ian Gregory
> Stateful inspection and "related" handling are hacks to
> support active FTP and similarly bad protocol designs. *Many*
> firewall software bugs have been found in early attempts to
> support active FTP. It remains one of the biggest headaches
> to network security specialists and many networks simply
> implement a policy requiring all FTP to be in passive mode or
> through old-fashioned application layer proxies.
Stateful inspection, as with the "keep state" rule in IP Filter
is certainly not a hack to support active FTP because it doesn't
support it.
The "keep state" rule is useful because for example you can block
everything incoming and outgoing and then allow only certain
TCP packets outgoing, and only if they have just the syn flag set.
If you keep state then the return packets are allowed back but
nothing else gets in.
Use of "keep state" improves security because you only have to
open a one way hole in your firewall and is difficult if not
impossible to sneak a rogue packet through the other way by
making it look like part of the same connection. Without stateful
inspection you have to open a two way hole.
But "keep state" only applies to a single connection, it does
nothing special in the case of FTP (active or passive) to then
allow the subsequent FTP DATA connection through, that has to be
independently allowed by the ipf rules.
Supporting FTP is difficult. On the server side active FTP is easy
but passive is a major headache. On the client side passive mode
is easy and can be handled with a simple "keep state" rule but
active requires the use of a more complex ipnat "proxy" rule.
I agree that complexity is the enemy of security.
--
Ian Gregory
Systems and Applications Manager
Learning and Information Services
University of Hertfordshire
Sriranga Veeraraghavan
> Hey guys, I've got little security experience. What would be the best
> firewall to deploy on a small unix system?
Hi,
You should probably take a look at OpenBSD (http://www.openbsd.org).
It has been audited for security problems and is quite secure. It is
also well documented and runs on a wide range of older cheaper
hardware.
If you are interested in using OpenBSD I would also recommend that you
pick up a copy of Building Linux and OpenBSD Firewalls by Wes
Sonnenreich and Tom Yates.
HTH,
----ranga
Bernd Eckenfels
> things to work than you do with a stateful firewall. IPTABLES,
> available in Linux 2.4.x kernels does support stateful inspection.
be aware that statefull inspection is a registred marketing hype and has
nothing to do with "stateful ip filter". Stateful inspection is a technique
where you can actuelly inspect the content of a tcp connection in the packet
firewall without an application level proxy. this is not, what iptables want
to do.
besides iptables ith the connection tracking module you can use the sinus
firewall (sifi) which does also stateful filtering.
Greetings
Bernd
Akop Pogosian
> Ean Kingston wrote:
>> Don't bother with ipchains on Linux.
>>
>> The latest release of these firewalls all include NAT and statefull
>> inspection. I run IPFW on FreeBSD at home (which also has 'traffic
>> shaping') and have setup IPFilter on Solaris (both Sparc and Intel) for
>> clients with a budget.
> Would you be willing to expand a little on why not ipchains with Linux? It
> seems to be the most common recomendation around here (actually that was a
> couple years ago and I haven't kept up to date). All my experience is Sun
> OS4x and Solaris but I was considering adding a linux intel box in front to
> filter between our internal machines and our web server/anonymous
> ftp/zserver, etc box. (I've stayed away from linux so far because there
> seem to be SO many bugs that come to me via CERT, bugtraq, etc.--and I know
> I'd have trouble keeping up with them:-)
I haven't used the new Linux 2.4 netfilter yet but I think that the
Linux 2.2.x ipchains is definitely not as robust as IP Filter. First,
Linux ipchains does not support statefull packet filtering. Here is
the section from IP Filter HOWTO on this topic:
http://www.obfuscation.org/ipf/ipf-howto.html#TOC_20. It is up to you
to decide if this is a useful feature. I think it is. It is supported
in Linux 2.4.x netfilter.
Second, the ipchains REJECT target does not return TCP reset packet to
TCP connections or return ICMP unrecheable packet for UDP connections.
The bottom line is that you can't hide your firewall with ipchains. A
good port scanner like nmap can easily detect not only the fact that
you're running a firewall but also what ports you are filtering. IP
Filter gives you an option to completely hide your firewall. I heard
this feature has been implemented in the Linux 2.4.x netfilter but
like I said, I haven't used it yet. We're still running Linux 2.2.x on
our systems.
-akop
ji...@vega.starshine.org
> Jim Bash <jb...@uic.edu> wrote:
>> Ean Kingston wrote:
>>> Don't bother with ipchains on Linux.
>>> The latest release of these firewalls all include NAT and statefull
>>> inspection. I run IPFW on FreeBSD at home (which also has 'traffic
>>> shaping') and have setup IPFilter on Solaris (both Sparc and Intel) for
>>> clients with a budget.
>> Would you be willing to expand a little on why not ipchains with Linux? It
>> seems to be the most common recomendation around here (actually that was a
>> couple years ago and I haven't kept up to date). All my experience is Sun
>> OS4x and Solaris but I was considering adding a linux intel box in front to
>> filter between our internal machines and our web server/anonymous
>> ftp/zserver, etc box. (I've stayed away from linux so far because there
>> seem to be SO many bugs that come to me via CERT, bugtraq, etc.--and I know
>> I'd have trouble keeping up with them:-)
> I haven't used the new Linux 2.4 netfilter yet but I think that the
> Linux 2.2.x ipchains is definitely not as robust as IP Filter. First,
> Linux ipchains does not support statefull packet filtering. Here is
> the section from IP Filter HOWTO on this topic:
> http://www.obfuscation.org/ipf/ipf-howto.html#TOC_20. It is up to you
> to decide if this is a useful feature. I think it is. It is supported
> in Linux 2.4.x netfilter.
As always one must balance utility and functionality vs.
simplicity and robustness. In general it is more likely that
a more complex bit of code has (as yet undiscovered/unpublicized)
bugs than a simpler bit of code. Certainly there is greater
complexity in implementing stateful packet filter than
simpler packet filtering. (Of course it is possible that
the specific implementations of either could be unnecessarily
complex for other reasons).
> Second, the ipchains REJECT target does not return TCP reset packet to
> TCP connections or return ICMP unrecheable packet for UDP connections.
> The bottom line is that you can't hide your firewall with ipchains. A
I'm pretty sure this is wrong. Linux ipfwadm and ipchains supports
*both* reject and deny/drop for packets. ISTR that "reject" is
more "active" in that it returns the ICMP "administrative deny"
while the "deny" target silently drops packets with no out-of-band
control message being generated. (According the the man page the
REJECT target will refrain from generating ICMP in response to
other ICMP packets; presumably to avoid recursive "ping pongs"
of messages between any pair of firewall/routers).
Reading the iptables man pages (apt-get -f install iptables,
Gosh! I like Debian) I see that it allows you to specify
any of six different ICMP "unreachable" types (host, net, port,
or protocol unreachable, and net or host prohibitted).
> good port scanner like nmap can easily detect not only the fact that
> you're running a firewall but also what ports you are filtering. IP
> Filter gives you an option to completely hide your firewall. I heard
> this feature has been implemented in the Linux 2.4.x netfilter but
> like I said, I haven't used it yet. We're still running Linux 2.2.x on
> our systems.
> -akop
My suggestions on when to use REJECT vs. DENY have to do with
the "publicity" of the destination IP addresses. If you're
selectively blocking some ports on an address which is otherwise
"visible" (you have any public DNS record referring ot it then
you might was well return a "don't go here" message of some sort.
If you use DRIP (direct routable IP addresses) on client systems,
or one some systems on your DMZ that are otherwise "hidden" (to which
no public reference is made) then you can drop any traffic destined
thereto on the floor (causing scanners and attackers to wait for
TCP timeouts and slowing them down).
(Better yet you can take some of those unused IP addresses and
set up "tarpits" (which I'd prefer to called fly ointments) a la
LaBrea).
Here's an example: I manage a system which is used by employees
and a small number of external contractors/vendors and business
partners as a secure file transfer system. (It requires rsync over
ssh, doesn't permit any passwords, requires host keys and user
account keys, etc). We don't permit users to access this liason
server from just any old machine --- they must provide us with
an SSH v2 host key and an IP address. Those IP addresses are
allowed to send packets to the ssh port on the liason server
(other hosts won't get that far --- the packet filters are on a
Cisco border router).
In this case the rules *should* look like:
src $ALLOWED_ADDR dst $LIASON_SSH accept
src $ALLOWED_ADDR dst $LIASON_ICMP accept
src $ALLOWED_ADDR dst $LIASON_OTHER_PORT reject + log
src $OTHER_ADDR dst $LIASON_ADDR drop
src $LIASON_ADDR dst $ALLOWED_SSH accept
src $LIASON_ADDR dst $ALLOWED_ICMP accept
src $LIASON_ADDR dst $ALLOWED_OTHER reject + log**
src $LIASON_ADDR dst $OTHER_ADDR reject + log**
... (not in any particular packet filtering syntax).
The idea is that anyone who's allowed to talk to ssh on
liason should get a quick/polite rejection if they try to
talk to any other port (ICMP should be allowed, at least
for things like source quench and some other types). Traffic
to liason from other hosts should be dropped but traffic from
liason to other hosts should be rejected (and logged).
Notice that I log things that are "suspicious" (why would
one of my allowed users try to access any other services
on this dedicated system) and I don't bother logging other
traffic (I know I'm getting port scanned all day every day).
I'd consider any packets purporting to be *from* liason to
"other" hosts or ports as *highly* suspect since it would
suggest that my liason server is compromised or that someone
internally is trying to spoof using one of our other internal
addresses. (In other words I'd spend more effort looking into
those events than the occasional authorized host/user poking
around on other ports. The latter might warrant a mild
admonishment and warning: "We saw the following traffic ...
which is against our policy. If you were unaware of this you
should check your configuration on ... and consider auditing it."
The former would be treated as an incident and I'd schedule
a formal (clean reboot from CDR) audit for that system.
--
Jim Dennis