RE: [fw-wiz] Securing a Linux Firewall

From: Bruce Platt (Bruce@ei3.com)
Date: 07/23/02 

From: Bruce Platt <Bruce@ei3.com>
To: Carson Gaspar <carson@taltos.org>, firewall-wizards@honor.icsalabs.com
Date: Tue Jul 23 17:32:02 2002

I guess it depends on what you fear most and what systems you need to
maintain. This thread started off as how to secure a firewall. By nature
they should be limited to what is needed and that's all.

I don't care if a determined, knowledgeable attacker does damage or if it's
done by a clueless kiddie.

What I do care about is denying successful attacks be they the sort that
cracks a hole in the fw, crashes a process due to stack overflow, or grants
access by privilege elevation.

That's all I'm going to say on this topic. I think we have different views.
I've used up my self-imposed limit on reply characters today :-)

Regards

-----Original Message-----
From: Carson Gaspar [mailto:carson@taltos.org]
Sent: Tuesday, July 23, 2002 4:43 PM
To: firewall-wizards@honor.icsalabs.com
Subject: RE: [fw-wiz] Securing a Linux Firewall

--On Tuesday, July 23, 2002 4:22 PM -0400 Bruce Platt <Bruce@ei3.com> wrote:

> Everything on the box that you don't need is a potential way for someone
> to grab control of an executable which can cause damage. Just because the
> image isn't executed during init processing doesn't mean that someone
> can't start it up some other way.

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.

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.

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

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.

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

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. 

-- 
Carson
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

Relevant Pages

  • RE: Is this as bad as it seems?
    ... The network being protected by the router or firewall is still vulnerable to ... > circumvented - the administrator has explicitly allowed HTTP traffic on ... this exploit has the effect of allowing the attacker to send *INBOUND* HTTP ... The HTTP server (located on the internal network or anywhere else that is ...
    (Security-Basics)
  • [NEWS] Multiple Firewalls Ruleset Bypass through FTP Revisited
    ... a new attack method affected most leading firewall ... connect to a restrictive port. ... resend control strings supplied by the attacker that a vulnerable firewall ... Connect to FTP server and log on ...
    (Securiteam)
  • [VulnWatch] vulnerabilities in fortigate firewall webinterface
    ... Several vulnerabilities in web interface of Fortigate firewall of which ... attacker to obtain a username and password of the Fortigate. ... Username and MD5 hash of password are stored in cookie. ... WEB FILTER LOG PARSES UNFILTERED SESSION DETAILS ...
    (VulnWatch)
  • [Full-Disclosure] vulnerabilities in fortigate firewall webinterface
    ... Several vulnerabilities in web interface of Fortigate firewall of which ... attacker to obtain a username and password of the Fortigate. ... Username and MD5 hash of password are stored in cookie. ... WEB FILTER LOG PARSES UNFILTERED SESSION DETAILS ...
    (Full-Disclosure)
  • Re: What can I do about breakin attempts?
    ... are not just more secure, but also much easier to manage/handle; ... is a potential attacker). ... as long as there are no serious security flaws known about ... Passwords are simply not as secure as encrypted keys. ...
    (comp.os.linux.security)