Subject: Security (SANS) & Monitoring tools

From: "Cottrell, Les" <[email-masked]>
Date: Tue, 06 Jun 2000 17:10:32 -0700

The FBI, Justice Department, GSA, the CIAO, CERT/CC, SANS and two dozen
leading security gurus on Internet Security Threats have created a document
on Internet Security Threat. The document is available at the following URL
http://www.sans.org/topten.htm I am not sure of the exact status of this
document, it is still being updated and Alan Paller the Director of Research
of The SANS Institute has said:
"I am faced with the following 
(a) multiple credible people differ on this issue and 
(b) the security issue and the management issue are in conflict
(c) I don't know which one matters more
(d) the positions are held almost religiously.

I am looking for a community-wide process that could get an answer -- one we

could use whenever this type of issue arises.  Discussion groups are too 
often hijacked by zealots who try to win through intimidation. What can we
do?"
In this document they talk about "Perimeter Protection" where they say "In
this section, we list ports that are commonly probed and attacked. Blocking
these ports is a minimum requirement for perimeter security, not a
comprehensive firewall specification list. A far better rule is to block all
unused ports. And even if you believe these ports are blocked, you should
still actively monitor them to detect intrusion attempts. A warning is also
in order. Blocking some of the ports in the following list may disable
needed services. Please consider the potential effects of these
recommendations before implementing them."  then one of the recommendation
is:
"ICMP-- block incoming echo request (ping and Windows traceroute), block
outgoing echo replies, time exceeded, and unreachable messages". 
This document has now been provided to ESnet sites by the DoE CIO. 
It seems to me that this list might have interests in the implications of
these recommendations on network monitoring/measurements and trouble
shooting. There are other concerns such as breaking MTU discovery (see
http://users.worldgate.ca/~marcs/mtu/ ) but they are probably better handled
in another mailing list.
It should not affect the Surveyor/RIPE type measurements. It will, however,
affect AMP, Skitter & PingER measurements if the machines are behind such
blocks. It will also affect on the fly trouble-shooting etc. using ping and
traceroute.

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 07 Jun 2000 08:36:09 +0100

In message <[email-masked]>
, "Cottrell, Les" typed:

most of the recommendations are based on
1/ the attack
2/ a documented weakness in a system that the attack exploits

in many cases, there are two different actions that can be taken
1/the weakness can be fixed rather than 
2/ removing functionality - 
1 is better security practice anyhow - obviously
some vendors are poor at shipping well tested fixes for sucvh things,
so in the real world (TM) one has to fall back on 2  - reduced
functionality

however, the one below appears not to be accompanied byu a documented
weaknness, and imho the reduced functioanlity is therefore not
justified.
 >>blocks. It will also affect on the fly trouble-shooting etc. using ping and

 cheers

   jon

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Thu, 8 Jun 2000 11:03:08 +0200 (CEST)

On Tue, 6 Jun 2000, Cottrell, Les wrote:

> could use whenever this type of issue arises. 

I'm not sure if there is a correct answer here.  The problem appears to be
in (b) and (c) above: there is a conflict between security and management,
and different sites will come up with a different tradeoff between the
two.

> It should not affect the Surveyor/RIPE type measurements.

For our measurements, we have a list of ports that should be accessible on
the box from the outside world and tell people in advance that firewalls
(etc.) should be configured accordingly. It's then up to them to decide if
they want to do this, if security is more important, well, then we simply
cannot do measurements to their site.

> It will, however, affect AMP, Skitter & PingER measurements if the
> machines are behind such blocks. It will also affect on the fly
> trouble-shooting etc. using ping and traceroute.

So, for a document like this, I think all one can do is list the arguments
why one should or should not block ICMP ports, then leave it up to the
site to make the tradeoff.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.535-4414,  Fax -4445
1016 AB Amsterdam                   Home: +31.20.4195305
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

A man can take a train and never reach his destination.
                                               (Kerouac, well before RFC2780).