Firewall Wizards mailing list archives
RE: Securing a Linux Firewall
From: "Bill Royds" <broyds () rogers com>
Date: Wed, 24 Jul 2002 08:13:28 -0400
What I have done in the past is a bit of a compromise between removing all unused binaries and just disabling them, but leaving them in place. This is a bit of "Security by obscurity" but why not move all unused binaries (after dropping setguid/setuuid etc.) to a separate unmounted partition, while still leaving them on the system. There are not then available for auto-zombies to find and use, not even there for script kiddies to search for with find, but available for the legitimate sysadmin to retrieve from Manhattan. It does have more risk than complete physical removal, but not much, while still maintaining them for use when needed. -----Original Message----- From: firewall-wizards-admin () honor icsalabs com [mailto:firewall-wizards-admin () honor icsalabs com]On Behalf Of Carson Gaspar Sent: Wed July 24 2002 00:14 To: firewall-wizards () honor icsalabs com Subject: Re: [fw-wiz] Securing a Linux Firewall --On Tuesday, July 23, 2002 4:01 PM -0600 John McDermott <jjm () jkintl com> wrote:
This, I believe, presumes that you are *100% sure* that the given binary can grant no additional privs. I am seldom that sure about software.
If it is not setuid, and not setgid, it _can't_ grant you extra privs (ignoring funky capability ACLs and the like).
Then you should care even more. Why leave something around that cen be exploited even if you personally don't know how to use it in an attack? I prefer to err on the side of caution and remove anything not needed.
If it's not running as a daemon, and grants no additional privs, how can it possibly be "exploited"?
One easy solution is to create a CD of the tools you want to use. Most of the debugging tools can be run from a CD with no problem. When you are out of debugging mode and back to production mode, remove the CD.
Ah. Here we run into environment differences. I have a very difficult time intserting a CD into a box in Tokyo with no CD-Rom drive, when I'm in my bedroom in Manhattan.
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.I may be confused, but to me that sounds like "make a list of the few programs the firewall needs and only put those on the jumpstart CD". This means removing all unused packages from the system before creating the "jumpstart"-like CD.
No. "The few programs the firewall needs" is significantly larger (especially under Solaris) than "The few setuid/setgid programs the firewall needs". I assert that the first set is very large, and is very difficult to maintain as the OS changes. You are free to disagree with my assertion.
Also consider - reload-time. I like to have a ghost image (or similar) of my firewall (in addition to a hot copy of the disk if there is money) so I can restore the firewall if it crashes. A smaller system is easier to restore.
I've never had a firewall that I couldn't reinstall from scratch in under 30 minutes. I'm sure I could make that 5 if I trimmed things, but 30 is fine for my purposes.
- audit time. It is easier to audit a system with fewer packages than one with lots of packages. (I am not saying, "make one big package"; I mean "more software is more difficult to audit".)
But you _don't_ _have_ _to_ _audit_ _everything_. Things that don't run at boot, and grant no additional privs, are just noise. They are inert, and there is no earthly reason to care about them. This is the core premise of my approach. All I have to audit are about 5 binaries, and a (sadly much larger) list of shared objects that they depend upon.
BTW, Marcus once wrote about an idea of creating a firewall by starting with a kernel and just a few basic utilities and then *adding* only the necessary software (as opposed to removing the unnecessary). While I have yet to try this, it sounds difficult but probably more secure to me.
This is the "known good" list of all binaries aproach I mention above. It creates unmaintainable boxes, in my experience. -- Carson _______________________________________________ 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
Current thread:
- RE: Securing a Linux Firewall, (continued)
- RE: Securing a Linux Firewall Bruce Platt (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)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall Carson Gaspar (Jul 24)
- Re: Securing a Linux Firewall BORBELY Zoltan (Jul 24)
- RE: Securing a Linux Firewall Bill Royds (Jul 24)
- Re: Securing a Linux Firewall Kyle R. Hofmann (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 26)
- Re: Securing a Linux Firewall R. DuFresne (Jul 26)
- RE: Securing a Linux Firewall Bruce Platt (Jul 23)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 25)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 25)
- RE: Securing a Linux Firewall David Lang (Jul 24)