RE: [fw-wiz] Securing a Linux Firewall

From: Litscher, Mark (mcl@Polymer.MacLean-Fogg.com)
Date: 08/06/02


From: "Litscher, Mark" <mcl@Polymer.MacLean-Fogg.com>
To: firewall-wizards@honor.icsalabs.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.

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



Relevant Pages

  • [Full-disclosure] BSD Securelevels: Circumventing protection of files flagged immutable
    ... By mounting an arbitrary filesystem, it is possible to mask files ... different levels of security. ... With Linux an attacker can even intercept the password input to lower ... Administrators should furthermore not rely on securelevels ...
    (Full-Disclosure)
  • BSD Securelevels: Circumventing protection of files flagged immutable
    ... By mounting an arbitrary filesystem, it is possible to mask files ... different levels of security. ... With Linux an attacker can even intercept the password input to lower ... Administrators should furthermore not rely on securelevels ...
    (Bugtraq)
  • Re: freebsd-security Digest, Vol 187, Issue 4
    ... I was so transfixed on Josh stating that the attacker could as well ... just mount a filesystem with suid root binaries and how that would be ... more useful than a buffer overflow in the filesystem driver. ... In the past we have considered remote DOS type attacks to be a security ...
    (FreeBSD-Security)
  • Re: LKM Trojan installed
    ... Of course, if the cracker has gotten root, they can chattr it right ... the first thing I'd do as an attacker is to find all ... chattr'd files on the filesystem since they're probably important. ... come in and modify things again. ...
    (Focus-Linux)
  • [UNIX] Buffer Overflows in Mandrake Linux printer-drivers Package
    ... * escputil: a utility to clean and align the heads of Epson Stylus ... Multiple vulnerabilities have been found in the tools mentioned above, ... exploitation provides an attacker with 'sys' group privileges. ...
    (Securiteam)