RE: Securing a Linux Firewall

["Litscher, Mark" <mcl () Polymer MacLean-Fogg com>]

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.

Mark


-----Original Message-----
From: Paul Robertson [mailto:proberts () patriot net]
Sent: Tuesday, July 23, 2002 4:16 PM
To: Carson Gaspar
Cc: firewall-wizards () honor icsalabs com
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 
noexec/nodev filesystem.

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
accident
> 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" 
> mentality.
>
> - 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
that 
> 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 
> cause.

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 
feeding.

Paul
----------------------------------------------------------------------------
-
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards