Re: SCO 5.0.7 AS FIREWALL
From: Jeff Liebermann (jeffl_at_comix.santa-cruz.ca.us)
Date: 05/25/05
- Next message: Jeff Liebermann: "Re: SCO 5.0.7 AS FIREWALL"
- Previous message: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
- In reply to: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
- Next in thread: Mainak Yajnik: "Re: SCO 5.0.7 AS FIREWALL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 25 May 2005 10:10:57 -0700
On Wed, 25 May 2005 05:42:36 -0400, Tony Lawrence <foo@pcunix.com>
wrote:
>I still don't agree that the benefits are dubious. My major argument is
>that anyone can screw up - me, the guy who writes the fw firmware, your
>cat, the neighbors dog - we all make mistakes.
Sure. I'm constantly running into virus/worm/trojan infected Windoze
boxes with long expired anti-virus software. When they inevitably ask
"how could I have caught such a thing?", they act surprised that they
have to do some updating. Add Windoze UnPnP, that can drill holes in
the firewall automagically, and security is compromised.
>If the fw people
>accidentally pass port 22 from an address I didn't approve, my sw filter
>rules hopefully still reject it. If I bollixed that or accidentally
>disabled the whole thing, hopefully my ssh config will still protect me.
> If there's some new bug in ssh that nobody knew about, maybe one of my
>pam rules will help me or my snort logging will let another part of my
>defenses kill the session.
Sounds like security through complexity. The obstacle course method
of implementation has its benefits. If one firewall is good, then 2
or 3 are obviously better. Throw in a few layers of encryption,
virtualize everything, tunnel, encrypt, and authenticate every packet,
and perhaps the security will be adequate. Of course, diving into a
rogue web site, and clicking on the inevitable "Install this free
utility" link, will bypass all the packet level security and probably
dump an executable on you machine for later exploitation. Snort and
IDS firewalls are a good idea as they provide the necessary logs to
analyze what went wrong and from where it arrived.
>The guy I was arguing with says that I might as well worry about a red
>headed nun with a machine gun bent on my demise, but I don't agree:
>maybe HE doesn't make mistakes, but I sure do, and so do most of the
>people I know. I have no reason to believe that fw engineers or the
>authors of the sw filters etc. are immune to that.
Methinks you're both wrong. There's no standard method of protecting
a network. Such things are sized and configured by what one it trying
to protect and by the size of the clients budget. Applying your level
of protection to the average home user is ridiculous. Yet, it's
probably insufficient for a large corporate gateway.
As for mistakes, most of the ones I've seen are in Cisco IOS
configuration. I learned IOS the hard way, doing battle with
misconfigured firewalls. It's incredibly easy to do it wrong or
half-way when configured manually. There are lots of templates around
for initial configuration. I've been using (and abusing) Firewall
Builder:
http://fwbuilder.org
with the modules for various specific firewalls and systems.
As with nuclear treaties, the watch words are "trust, but verify"
which means that a firewall isn't considered functional until it
survives a series of exploit tests. The problem is that most firewall
tests that I've used are huge traffic generators and rather invasive.
Even NMap scans, at high speed, will cause a firewall to go comatose
for a few minutes. The result is that most firewalls are installed,
configured, and never tested. The first indication of a problem is an
intrusion. It's kinda like backups. Nobody does backups until AFTER
they have lost data. Nobody test firewalls until after they've been
proven porous or misconfigured. Even then, the testing is long,
tedious, and tends to generate large log files.
However, that's only half the problem. Firewalls are great for
preventing unauthorized intrusions from the internet. They do very
little for preventing leaking sensitive documents and information from
the client machines. If I can run a program on the client machine,
then I can use ftp, email, rcp, scp, or even http, to send something
to a designated recipient. Few of the firewalls do anything for this
problem.
At this time, my customers are more concerned with internal leaks,
than external intrusions. This is especially true of HIPAA
requirements. I've installed sniffers that look at the contents of
outgoing email for keywords and obvious internal documents. Anyone
sending an encrypted, compressed, or binary file is instantly tagged
as a problem. While testing the system, we caught an employee selling
customer lists delivered via email.
Incidentally, most (not all) of the personal Windoze firewalls have a
problem. All that's necessary to fool an outgoing filter is to rename
the rogue program the same as an authorized program. The firewall
doesn't know the difference.
http://grc.com/lt/leaktest.htm
ZoneAlarm does it right by encrypting the authorized program names,
but few of the others bother. Oh well.
Anyway, I can go on forever on the topic of security. Some of the
above is why I consider firewalls to be of marginal value, but still a
necessity. I require my customers to have them, and I monitor them as
time permits to make sure they're working. Real security means
reading LOTS of log files looking for suprises and anomalies. I'm
partial to dedicated security appliances and firewalls. The SCO
server has better things to do than carefully inspect every packet.
-- Jeff Liebermann jeffl@comix.santa-cruz.ca.us 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 AE6KS 831-336-2558
- Next message: Jeff Liebermann: "Re: SCO 5.0.7 AS FIREWALL"
- Previous message: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
- In reply to: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
- Next in thread: Mainak Yajnik: "Re: SCO 5.0.7 AS FIREWALL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
