Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Luciano Miguel Ferreira Rocha (strangensk.yi.org)
Date: Fri Sep 14 2001 - 15:32:13 CDT
On Thu, Sep 13, 2001 at 11:52:23PM -0600, Rob 'Feztaa' Park wrote:
> However, firewalls can protect open ports from bad traffic. If you look at
> my "clever firewall rules" thread, you'll see that I have an iptables rule
> that drops all packets that are neither a) SYN packets nor b) part of an
> existing connection. It is safe to assume that a packet that meets this
> requirement is malicious; it is likely somebody running a FIN/NUL/XMAS
> portscan against the system. So the firewall can protect you against that,
> as well.
The firewall needn't protect against bad traffice, the kernel already does that.Also, your firewall rules may protect you from a FIN/NUL/XMAS portscan, but does
not protect you against the more normal SYN and connect(2) scans.
> Also, if you have a daemon that you need locally, but not remotely (say,
> mysql or X windows), you can use your firewall to close those ports, even
> though there are daemons listening on them. I run mysql, because apache
> needs to access it locally, but there is no need for anybody to access it
> remotely, so that port is closed by the firewall. Some daemons may have an
> option to make them only accessible locally, but not all do, and a
> firewall is an easy, centralized way of controlling which ports are open
> and which are shut.
I'm still to find a daemon that doesn't have an option to bind(2) only to
localhost/127.0.0.1 or that I couldn't change the source in order to make
it bind to a specific address.
However, I do agree that it's easier to use a firewall to controll the open
ports, but then you also have a problem in some protocols that related
connections are hard to keep track of.
> I think a firewall is even more useful for client-only machines than it is
> for servers because then the firewall becomes the proverbial weak link in
> the chain. In the first case, the strength of the firewall is mostly
> irrelevant because a poor daemon is the weakest link in the chain. In this
> case, since the firewall is now the weakest link, ensuring it is very,
> very strong will ensure that the entire chain is strong.
> As an example, imagine the person using this client machine downloads a
> an unknown program, which turns out to be a trojan. Granted, this isn't so
> much of a problem on linux because said user is not likely to have root
> access, so we'll assume that this machine runs windows. The user has
> downloaded a trojan, and is now accepting connections from the attacker -
> the client has unwittingly become a server! If the firewall is configured
> to prevent any unsolicited incoming traffic, then the presence of the
> trojan server is irrelevant because the firewall won't let anybody connect
> to it anyway.
> So, a firewall on a client has now turned a malicious attacker's backdoor
> into something that is a needless and useless waste of processor cycles at
Yes, that is very usefull, but you're forgetting the trojan as in most cases
ilimited access to the machine, so it may be able to disable the firewall or
to disguise as a normal apllication connecting to a web server, for example.
But the world isn't a perfect one, that's why we have the need for firewalls,
hids, nids, etc. The point is to have adicional redundant security, either
to protect our server or to protect others servers in the case it becames
-- Luciano Rocha, strangensk.yi.org
The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen