RE: [fw-wiz] Securing a Linux Firewall
From: Litscher, Mark (mcl@Polymer.MacLean-Fogg.com)
- Next message: BY: "[fw-wiz] PIX - MSN"
- Previous message: Stephen P. Berry: "Re: [fw-wiz] Securing a Linux Firewall"
- Maybe in reply to: Marc DVer: "[fw-wiz] Securing a Linux Firewall"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Litscher, Mark" <mcl@Polymer.MacLean-Fogg.com> To: email@example.com Date: Tue Aug 6 10:20:03 2002
How many OS's have the option of mounting a file as a filesystem using a
loopback device? Move all of your utilities to file mounted as a filesystem
through the loopback interface. Then when you are finished working, unmount
the file that contains your utilities and encrypt it. Your utilities are
inaccessible to anyone without the decryption key, and you can still decrypt
and mount your utilities when needed.
From: Paul Robertson [mailto:firstname.lastname@example.org]
Sent: Tuesday, July 23, 2002 4:16 PM
To: Carson Gaspar
Subject: RE: [fw-wiz] Securing a Linux Firewall
On Tue, 23 Jul 2002, Carson Gaspar wrote:
> If the binary grants no additional privileges, then it can do nothing the
> attacker couldn't do already. If you can execute shell code, you can copy
> bits onto the box (at your current privilege level) - assuming there is at
> least one writable directory on the box.
s/can/may be able to/, it depends on the ammount of space the attacker has
to work with- also the attacker may only have write access to a
You also may be running an architecture that the attacker doesn't have
easy access to- which could give you enough time to notice the attack.
> So far, the only comments I've received that make sense are:
> - Not having the binary in the expected location prevents skript kiddiez
> attacks from suceeding
> In my opinion, this provides minimal additional security. My threat model
> is a determined attacker, not a clueless scriptoid.
That depends on your maintenance cycles, how closely you watch the
software you're running, etc. As with all else, it's a tradeoff. It can
also be thought of as defense in depth for an admin error.
> - If the binary isn't on the box, nobody can enable the service by
> True. But I feel that a regular system config audit is a better way of
> confirming that nobody's done anything unfortunate.
Again, there's an argument for defense in depth.
> There are a few reasons I don't like the "strip everything off the box"
> - It frequently makes debugging problems nearly impossible, as the
> necessary tools are not present.
This is almost always true.
> - Every time a patch or a new OS version is released, the set of files
> are required changes. Also, new privileged binaries may appear.
The file set shouldn't change that often. If you're nuking "not known"
binairies, the process you use to audit the nuking should catch anything.
> I've had to maintain "jumpstart"-like images for secure servers.
> Maintaining a "known-good" list for privileged binaries is relatively
> straightforward. Maintaining a "known-good" list of _all_ binaries is a
> nightmare. I further assert that maintaining a "known-bad" list is a lost
It depends on how you approach it, I've gone through the exercise of "what
functionality do I need, and can I stuff it all in a static binary that I
maintain control of which requires authentication to execute?" path
before- I'm not sure it's always worth the additional effort, but it
sometimes might be if you have boxes that you have to leave out in hostile
environments for long periods of time without a great deal of care and
Paul D. Robertson "My statements in this message are personal opinions
email@example.com which may have no basis whatsoever in fact."
firstname.lastname@example.org Director of Risk Assessment TruSecure Corporation
firewall-wizards mailing list