Firewall Wizards mailing list archives
RE: Securing a Linux Firewall
From: Paul Robertson <proberts () patriot net>
Date: Tue, 23 Jul 2002 17:16:03 -0400 (EDT)
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
Current thread:
- Re: Securing a Linux Firewall, (continued)
- Re: Securing a Linux Firewall Carson Gaspar (Jul 23)
- Re: Securing a Linux Firewall Paul Robertson (Jul 23)
- Re: Securing a Linux Firewall Mordechai T. Abzug (Jul 23)
- Re: Securing a Linux Firewall Frank Knobbe (Jul 23)
- Re: Securing a Linux Firewall Ng Pheng Siong (Jul 24)
- Re: Securing a Linux Firewall Carson Gaspar (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall Frederick M Avolio (Jul 23)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- RE: Securing a Linux Firewall Paul Robertson (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall John McDermott (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)