Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Nmap Development: Re: Detecting upstream filters

Re: Detecting upstream filters

From: Ryan Permeh <ryan_at_eEye.com>
Date: Tue, 27 Feb 2001 12:29:29 -0800

one of the problems here is that there isn't nessecarily an icmp unreach
sent on a blocked port. sometimes it just drops the packet and enters the
"filtered" state because no response was read. this may not even work when
an intermediate decides to send an ICMP packet, because, if i remember
correctly, pcap filters are placed to collect input, and intermediates are
not in the filters collected.
Signed,
Ryan
eEye Digital Security Team
http://www.eEye.com

----- Original Message -----
From: "Rasmus Andersson" <rasmus_at_pole-position.org>
To: <nmap-dev_at_insecure.org>
Sent: Tuesday, February 27, 2001 4:20 AM
Subject: Detecting upstream filters

> Hi folks
>
> When NMAP tells you a port is filtered, you do not know if that filter
> is in the target itself or somewhere between you and the target. I once
> was mislead by that fact and thought that my customer's firewall
> filtered BO, while it was actually filtered by his ISP. Fortunately I
> saw my mistake before making a fool out of myself.
>
> My idea is to detect any ICMP-unreachable that originates from an
> intermediate host [any host except the target], and include that in the
> output, something like this:
>
> Port State Service
> 21/tcp open telnet
> 25/tcp open smtp
> 12345/tcp filtered* NetBus [* by fw.isp.urg (172.16.17.18)]
>
> I'm not good enough to make this addition, however I made a proof of
> concept patch half a year ago that just trashes the output when the ICMP
> is parsed, instead of adding it to the table later. The detection part
> is really simple, but I didn't manage to digest enough source to get the
> output stuff right.
>
> Some of you wizards should be able to implement this while sleeping.
> Please do, I need it :-)
>
> Slainte
> Rasmus
>
> > From: Fyodor [mailto:fyodor_at_insecure.org]
> > Sent: Thursday, June 15, 2000 9:19 AM
> > To: Rasmus Andersson
> > Subject: Re: Detecting upstream filters [was Re: Protocol scan with
> > nmap]
> >
> > > The above lines remind me of a suggestion I made a while ago that
> > > whenever NMAP gets an ICMP unreachable from an other address than the
> > > one scanned (i.e. a filtering intermediate router), NMAP should add
that
> > > info to the output, something like this:
> >
> > Please save this message. I'm going to start an nmap-dev list for
> > development discussions and this would be a perfect topic. I don't have
> > the bandwidth to start a features discussion on the nmap-hackers list
> > (which has 10,000 members). But dev will be smaller and won't kill my
> > mail server :).
> >
> > Cheers,
> > -F
>
> ---------------------------------------------------------------------
> For help using this (nmap-dev) mailing list, send a blank email to
> nmap-dev-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
>
>
>

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Feb 27 2001

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos