RE: ICMP blocking on PIX .4.4.1

[GibsonB () gruntal com]

Essentially any protocol can be compromised and used for nefarious purposes.
Port 80 is one of the most exploited ports on the Internet.  That doesn't
mean that we should shut down web browsing.  What you do is minimize a black
hat's ability to use Port 80 to exploit your network.

This is why a Firewall is much better suited to control diagnostic
protocols.  An SPF can recognize direction in UDP and ICMP.  Thus you can
control how these protocols are used.  A router is very poor at controlling
either protocol.

Traceroute and ping invaluable tools for quick diagnostic analysis.
Alternative tools may be able to do the same but they are so ubiquitous and
simple to understand.  They also pose their own set of problems.

ICMP can used to carry malicious traffic but I am unaware of ICMP ever being
used in an gain access exploit.

-----Original Message-----
From: R. DuFresne [mailto:dufresne () sysinfo com]
Sent: Friday, May 05, 2000 1:53 PM
To: GibsonB () gruntal com
Cc: nawk () real-secure com; firewall-wizards () nfr net;
phred () pacificwest com; jseymour () LinxNet com
Subject: RE: [fw-wiz] ICMP blocking on PIX .4.4.1



Is not loki still an possible way to tunnel out via ICMP in this fashion?
Thus compromising a security policy?  My understanding, and please, do
correct me if I'm interpreting incorrectly is that not all ICMP and all
connectionless protocol traffic is safe and warranted.  And in such cases
that UDP and some ICMP is blocked, disabling pings and traceroutes, there
are alternative tools that can be used to do the same kinda of
diagnostics.  Just as with fingerd output, UDP and ICMP can be helpful
tools to aid an outsider in getting information from the inside that is
best not being made public, and or hosing up your routing scheme <i.e.
ICMP redirects>.

Thanks,

Ron Dufresne

On Fri, 5 May 2000 GibsonB () gruntal com wrote:

> I don't agree with this. ICMP is an invaluable tool for diagnostics.  If
you
> shut it down then you are limiting your ability to troubleshoot problems.

> What you want to do is allow ICMP to go out but not to come in.  Ideally
> what you want to do is allow certain types of ICMP out(ie Echo requests)
and
> only certain types of ICMP to come in(ie Echo Reply, Time exceeded,
> unreachable).  This is not easily done in a router.  
>
> Actually blocking connectionless protocols in general is not easy thing to
> do in a router.
>
>
>
> -----Original Message-----
> From: User nawk [mailto:nawk () real-secure com]
> Sent: Saturday, April 29, 2000 12:57 PM
> To: R. DuFresne
> Cc: firewall-wizards () nfr net; phred () pacificwest com;
> jseymour () LinxNet com
> Subject: Re: [fw-wiz] ICMP blocking on PIX .4.4.1
>
>
> Hi,
>
>     That is exactly how it should be done. You want ICMP and spoofing
> stopped on the router. Firewalls are a great device, but not perfect.
> Cisco's ACL do a much better job on blocking. Just make sure the lists are
> not to long so the CPU of the router does not get saturated. Think of it
as
> what if you or someone makes a mistake on the firewall and now you opened
> yourself up. All it is are layers of defense. If you really want to be
anal,
> setup ACL on your border routers, then apply your rules on the firewall
and
> last setup another router behind the firewall with ACL again. This way the
> attacker has to pass all three to get into your network.
>
>
> Thanks
>
> ----- Original Message -----
> From: "R. DuFresne" <dufresne () sysinfo com>
> To: "Jim Seymour" <jseymour () LinxNet com>
> Cc: <nawk () real-secure com>; <firewall-wizards () nfr net>;
> <phred () pacificwest com>
> Sent: Thursday, April 27, 2000 6:06 PM
> Subject: Re: [fw-wiz] ICMP blocking on PIX .4.4.1
>
>
> > It's always been our impression that veiwing security as an 'onion' on
> > pulls all the onoins skins together to form as tight a security system
as
> > possible to deal with the security policy at hand.  This would include
> > ACL's in routers to deal with ICMP/UDP and spoofing there, as well as
> > backup those rules in the firewalls rule sets, just in case one device
> > barfed up and packets slipped by it.
> >
> > Even the most recent issue of sysadmin mag has an article titled:
> >
> > The Use of Routers in Firewall Setup
> >
> > May 2000 vol 9 # 5
> >
> > Thanks,
> >
> > Ron DuFresne
> >
> > On Thu, 27 Apr 2000, Jim Seymour wrote:
> >
> > > nawk <nawk () real-secure com> wrote:
> > > > I think it's best practice to block things like icmp and spoofing
> > > > on your routers not firewall. The firewall is just to block things
> like
> > > > ports and provent access to your internal network.
> > >
> > > Two schools of thought on that.  The consultant that installed our
> > > first Gauntlet firewall (TIS was offering at the time free installs
and
> > > one day of training for up to three people) recommended that the
router
> > > be stripped of *all* packet filtering rules so that the firewall would
> > > see everything.  His logic was that Gauntlet was much more capable at
> > > detecting and reporting activity than was the firewall router.
> > >
> > > My feeling was that sufficient rules to protect the *router* itself
had
> > > to remain.  So that's what I did: the router has only enough rules in
> > > it to protect *it*.  The firewall gets everything else.  (Except when
I
> > > get really fed up with something.  Then I block it at the router.)
> > >
> > > Note also that there is a potential problem in simply out-right
> > > blocking all ICMP at the router.  If you're running a mail gateway on
> > > the firewall (as I do [Postfix]), blocking ICMP path MTU discovery can
> > > lead to SMTP sessions timing-out on large emails.  (See, for example:
> > > http://msgs.SecurePoint.com/cgi-bin/get/postfix9904/37/1.html.)  And I
> > > don't see any particular reason why others shouldn't be allowed to
ping
> > > my firewall.
> > >
> > > Allowing ICMP (or any connection-less protocol, such as UDP) *through*
> > > the firewall is another issue entirely.  Connection-less protocols are
> > > not safe.  Cannot be made safe.  Other than perhaps allowing syslog
> > > from the router to a syslog host, specifically, I don't see any
> > > particular reason to allow any UDP through a firewall.
> > >
> > > As regards the original poster's query: I don't know the PIX firewall,
> > > but wouldn't it be possible to log on to the PIX and run your pings
and
> > > traceroutes from there?  Less convenient, to be sure.  But far safer
> > > than allowing UDP through it, I should think.  I'll take safety over
> > > convenience any day.
> > >
> > >
> > > Regards,
> > > Jim
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >         admin & senior consultant:  darkstar.sysinfo.com
> >                   http://darkstar.sysinfo.com
> >
> > "Cutting the space budget really restores my faith in humanity.  It
> > eliminates dreams, goals, and ideals and lets us get straight to the
> > business of hate, debauchery, and self-annihilation."
> >                 -- Johnny Hart
> >
> > testing, only testing, and damn good at it too!
>
>
> ***********************************************************************
> Gruntal & Co., L.L.C.'s e-mail system is for business purposes only.  
> Messages are not confidential.  All e-mail may be reviewed by 
> authorized supervisors, compliance or internal audit personnel.
> E-mail will be archived for at least three years and may be produced 
> to regulatory agencies or others with a legal right to access such
> information.  Gruntal will not accept trade order instructions via
> e-mail.  Please telephone your Account Executive to place trade orders.
>
> Gruntal & Co., L.L.C.
> ***********************************************************************

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior consultant:  darkstar.sysinfo.com
                  http://darkstar.sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!


***********************************************************************
Gruntal & Co., L.L.C.'s e-mail system is for business purposes only.  
Messages are not confidential.  All e-mail may be reviewed by 
authorized supervisors, compliance or internal audit personnel.
E-mail will be archived for at least three years and may be produced 
to regulatory agencies or others with a legal right to access such
information.  Gruntal will not accept trade order instructions via
e-mail.  Please telephone your Account Executive to place trade orders.

Gruntal & Co., L.L.C.
***********************************************************************