RE: [fw-wiz] Securing a Linux Firewall

From: Bill Royds (broyds@rogers.com)
Date: 07/24/02


From: "Bill Royds" <broyds@rogers.com>
To: "Carson Gaspar" <carson@taltos.org>, <firewall-wizards@honor.icsalabs.com>
Date: Wed Jul 24 08:30:49 2002

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


Relevant Pages

  • Re: [fw-wiz] Securing a Linux Firewall
    ... If it is not setuid, and not setgid, it _can't_ grant you extra privs ... > programs the firewall needs and only put those on the jumpstart CD". ...
    (Firewall-Wizards)
  • Re: spyware removal problem
    ... firewall installed or, at the very least, do you have the XP firewall turned ... there's no way of knowing if removing it might cause some ... ripple effect on your system and that brings us back to clean install. ... >> installing a first-rate Internet Security program to help protect ...
    (microsoft.public.windowsxp.basics)
  • Re: on-line Messenger Service exploitation in Windows XP
    ... >The problem is a service allowing unauthenticated, unsolicited connections. ... Removing the service is beneficial if there is likely to be an attempt to ... >Adding a firewall covers it up...like bandaid covering up a port. ... far more worrisome than just Messenger (which is irritating, ...
    (microsoft.public.security)
  • Re: [fw-wiz] Securing a Linux Firewall
    ... >> can grant no additional privs. ... Suppose that your firewall has the option to run an outside program on a fixed ... the firewall will not be bugfree, and the attacker will be able to execute ...
    (Firewall-Wizards)
  • Re: How to prevent my IP address from being bcast
    ... >but verifying that your firewall is doing it's job. ... ISPs are not taking ... >responsibility for removing the people that are violating their AUPs, ...
    (comp.security.firewalls)