On Mon, Jan 31, 2000 at 04:14:58PM +0900, Steve Frampton wrote:
: You've got a decent firewall set up (hopefully with Linux, right? What
: kind of moron would spent $18,000 on Firewall-1 when Linux can do the same
: thing?), applied all your updates, and don't have local shell
: users? Okay, chmod a+r the log files then. :-)
What kind of moron? Let's see...
The kind of morons that want to do:
Remote user VPNs - guys in the field with laptops dial into an ISP and
establish encrypted sessions that can even be authenticated using X.509
digital certificates. I'd say that's a pretty big one.
Content-based filtering - automagically run all inbound and outbound email
through a virus scanner, or filter web traffic for weed out pr0n and other
stuff that some sites, like say, schools, want filtered.
Authenicate certain types of traffic against third party sources - SecurID,
Axent Defender, X.509 CA, LDAP, RADIUS
Have user authentication/tracking that ties into a DHCP/DDNS server. This
is *extremely* useful in DHCP environments with short lease times. So
the person who attacked that server in the DMZ zone has a different IP
address now? No big deal, you're using a solution like MetaIP to do
DHCP/DDNS, so you've got User-Address Mapping support between the two
products. BTW - MetaIP also runs quite well on Linux.
Site-site VPNs using multiple encryption schemes (ISAKMP, Manual IPSEC
Key Exchange, or Check Point's own FWZ)
Have an actual *state* based firewall. On an ipchains firewall, one needs
to leave all ports >1024 *OPEN*, to accomodate reply traffic. Let's see,
what are some services that run up there? Hmm.. X, NFS, Oracle's TNS
listener, and many others. Maybe you want that kind of functionality,
but 99% of us don't. The ipchains code has come a long way, but it's
also got a longer way left to go.
That previous paragraph begs the question, "Ok, so how does FW-1 handle
that?". State based packet inspection. The firewall sees internal person
at address X talk to server Y (on the other side of the wall), using local
port 1093, and remote port 80 (that is, a typical HTTP connection). FW-1
knows this connection is currently taking place, so when it sees the reply
traffic from server Y, with his local port 80, and the recipient X, with
remote port 1093, and it's within a reasonable amount of time, the
traffic is permitted to pass. No such animal for ipchains. You've got
the same functionality as a router with ACLs.
The bottom line is the people who pay $18k for FW-1 are the people who
are in need of functionality that ipchains cannot provide, or want to
provide similar functionality to ipchains in a better implemented
methodology.
Now for those of you getting the rope ready to string me up, stop and think.
Linux is great, wonderful, perfect for a number of tasks. The vast
majority of my servers run Linux (except for the IIS4/SQL7 duo that some
customers demand). Linux isn't perfect for everything, at least right
out of the box. One of those applications is as a firewall using ipchains.
FW-1 4.1 is going to be shipping for Linux soon. It's going to run on
RedHat 6.0 and 6.1. It's even in RPM format (I've got the beta running
in my lab of mad science...).
--
Jason Costomiris <><
Technologist, cryptogeek, human.
jcostom {at} jasons {dot} org | http://www.jasons.org/
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
