[plug] unknown hosts

[Christian]

On Tue, Dec 12, 2000 at 10:07:34AM +0800, Leon Brooks wrote:
 
> Well, no. The box is only running a specific set of services. If the service is
> not running, an intruder can't connect to it. None of the open services are
> known to have holes. Further, the box is sitting on a LAN which has internet
> access through a masq, so the world at large can't even see it.

1. Services may be added.  This is often the case and the administrator
hastily installing a new IMAP server typically does not think to add new
rules for it.  If you deny by default then this forces the administrator
to think about the security implications of adding the service which at
least gives a chance for the right thing to be done.

2. Holes may be discovered.  Saying that none of the services are known
to have holes is meaningless.  There are very likely holes there yet to
be publicly released.  Blocking by default at least offers some MINIMAL
protection.

3. The box may be moved.  This is similar to (1) in that it often
happens without a reassessment of the machine's security requirements.

4. New entry points to the internal network appear -- sometimes even in
the machines that are supposedly protecting the network.  This once again
often happens without the new security requirements being assessed.
Various different forms of tunnelling exist meaning that machines behind
proxies are still reachable.

These may or may not be likely possibilities but they are possibilities.
Leon's comment is a classic example of way many people approach
security.  In this case there were two ways of doing things: the easy
way and the (very marginally) more difficult but more secure way.  It
was all too easy to recommend the easy way.

It is also a generic example of the shortsightedness that leads to many
security holes.  Programmers and administrators often only consider the
current or expected operational situations without considering how those
situations may change.  Security holes appear when either the situation
changes or the attacker creates a situation that the developer never
considered.

> And just to head off any suggestions about manically
blocking every port in
> sight, the machine operates as both a client and a server, so both outbound and
> inbound (for FTP) connections via non-priv ports have to be allowed. If you
> allow those, there's no real point in blocking off much else since any trojan
> program (cracking tool) can make whatever outbound connects it likes, or listen
> on high ports all it likes.

This is neither here nor there.  It is ludicrous to reason that since
*some* POTENTIAL holes cannot be closed it is pointless to add other
protection mechanisms.  In most practical situations security is a
matter of "defense in depth" where as many protection mechanisms are
combined and used together to gain the greatest degree of security.
Just because one particular aspect cannot be covered due to operational
requirements doesn't mean that all the others are automatically
useless.