Of Firewalls And Pricetags
Chuck Bearden
cbearden at sparc.hpl.lib.tx.us
Wed Apr 1 12:34:00 EST 1998
On Tue, 31 Mar 1998, jpapier wrote:
> We're ready to offer up our home page on our own computers via the
> beloved Apache web server. However, I'm balking at firewall pricetags.
> Is anyone using reliable security software at a reasonable price?
> Other solutions to security?
>
> Thanks
> JP
>
> --
> Jeff Papier
> Network / Internet Librarian
> South Brunswick Public Library
> Monmouth Junction, NJ
I've heard it said that firewalling a webserver with anything more
than a packet filter is probably a waste, the idea being that
machines that permit such wide access to their services probably
ought to be regarded a priori as "dirty", and be made untrusted
by machines containing more sensitive data (e.g. patron circulation
records).
For a machine doing web serving, I would take a two-pronged approach:
secure the host as much as possible, and implement a home-grown packet
filter using Linux and a couple of NICs. I'm assuming you are running
some flavor or variant of Unix, althought I do realize that there is
an Apache for NT. With a webserver, I would probably lay the emphasis
on securing the host (though don't omit the packet filter if your
network topology can accommodate it.
Some basic thoughts--
Host security:
1. Audit the services you offer; shut down those that aren't
necessary, and take every precaution to secure those that are. These
are the only entrances into your system for someone who doesn't have
physical access to the machine.
Use "netstat -a" to look at all listening ports and track
down the corresponding services in inetd.conf and comment out those
that aren't needed, then restart inetd. For those not started by
inetd, use /etc/services to figure out what files in the initscripts
(/etc/rc.d...) are starting unnecessary services and unset the
executable bit so that they don't get started up when you reboot.
For services that are necessary, as well as for the kernel, keep up
to date on announced vulnerabilities and patches/updates. I'm chiefly
familiar with Red Hat Linux, which has a very nice package management
system for updating applications. The Apache manual has some useful
tips on securing Apache.
For necessary services started from inetd, implement tcp_wrappers so
that you can control IP addresses and hostnames from which users can
connect to those services. If you are ambitious, you can also use
tcp_wrappers to sound alarms (virtually, not literally) when folks try
to connect to suspicious ports (where, of course, the expected
vulnerable application won't be running).
2. Audit system integrity with tripwire. tripwire will calculate a
variety of cryptographic checksums and signatures for files you choose
on your system and store the info in a database. Put tripwire and
database on a read-only floppy, and run it nightly from cron. It will
be practically impossible for an intruder to modify system binaries to
leave backdoors into your system without being detected.
3. Audit account security: who really needs an account on this
machine? Enforce good passwords. Can you get away with giving users
non-shell accounts (e.g. popmail, Samba, chrooted guest ftp, with fake
shells in /etc/passwd), so that someone compromising that account
can't execute arbitrary commands on your system? Make "su" executable
only by members of a trusted group to make it harder for other users'
accounts to be parlayed into more privileged access.
4. Use ssh (Secure Shell) for remote logins to your machine instead
of telnet or rlogin, especially for users who will be su-ing to root.
Ssh encrypts the session so that someone who has a foothold in your
network can't sniff your login pasword, or even worse, your root
password as you "su".
Packet filtering firewall:
1. Linux box (even 486 with 16MB or 32MB RAM would probably do nicely)
with 2 NICs; IP forwarding & firewalling (and maybe some other options)
enabled in kernel.
2. Install ipfwadm; deny all inbound connection attempts initially
and then enable only those needed from the outside (e.g. to port 80
of the webserver). This is the part that will take the most thought
and planning, especially if other machines are to be behind the
firewall as well. Proper configuration here can also reduce
vulnerability to certain denial-of-service attacks as well (e.g.
ping of death, winnuke).
3. Run as few services on the firewall as possible; perhaps a mail
transport agent to forward mail to servers behind the firewall, and
DNS. Create no extraneous accounts, and permit logins only from the
console. Make the firewall machine distrust the webserver.
4. If your firewall protects other more sensitive hosts as well,
place the public machines (e.g. www server) on a different subnet than
the more sensitive machines, and deny the public machine the right to
initiate connections to any host in the more private subnet (i.e. by
denying all TCP traffic from the webserver that does not have the ACK
bit set). I think Thomas Edelblute gave more or less the same advice.
There is of course more to be said about these matters, especially
with respect to the packet filter rules. Those can get extremely
complex, and I'm by no means an expert.
Here's a good place to start for learning about firewalls and their
capabilities:
http://www.clark.net/pub/mjr/pubs/fwfaq/
I've got a few more links on my personal web site at:
http://www.hal-pc.org/~cbearden/links.html#security
There's an interesting package I've heard of called Sinus, a packet
filtering firewall under GNU Public License for Linux. I haven't
tried it, but it looks quite interesting, and it may be a bit more
sophisticated than the basic ipfwadm filter.
http://www.ifi.unizh.ch/groups/ikm/SINUS/firewall.html
You can probably tell that I find this kind of thing fascinating. To
be honest, I am an amateur enthusiast rather than a grizzled veteran
of hacker wars.
I hope this helps.
Chuck Bearden
Network Services Librarian
Houston Public Library
Houston, TX 77002
713/247-2264 (voice)
713/247-1182 (fax)
cbearden at hpl.lib.tx.us
More information about the Web4lib
mailing list