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



Security Incidents: Re: ICMP time exceed in-transit packets

Re: ICMP time exceed in-transit packets

From: Chris Brenton <cbrenton_at_SOVER.NET>
Date: Tue, 28 Dec 1999 09:37:23 -0500

Rob Quinn wrote:
>
> > 22:32:06.344676 210.207.190.33 > sanitized.84.0: icmp: time exceeded in-transit
>
> You get these back from tracerouting, or when a packet takes too many hops,

Actually, it is extremely doubtful that this traffic is normal as you
will never see a type 11 get returned to a network address. Time
exceeded packets are only returned to transmitting hosts. So unless you
have a .0 host, this traffic is bogus.

I running one of the SANS teams which is monitoring Y2K intrusion
attempts. You can check it out at:
http://www.sans.org/y2k.htm

One of the things we have been seeing a lot of over the last 2-3 days is
this exact traffic pattern. What's happening is an attacker sends an
echo-request with a spoofed IP address and a very low TTL value. This
gets bounced by a router in transit and a type 11 is sent to the spoofed
address. I'm still trying to work out the rational as to *why* they are
doing this (its difficult to ID the true attacker system but requires a
lot of packets to be an effective DoS).

Please note that the source IP address you are seeing in your logs are
simply a backbone router. They are not the true IP address being used to
launch the attack.

It would be cool if you could post your logs to <intrusion_at_sans.og>.
This gets the word out to the groups and allows us to correlate your
data with data collected at other sites. If you post real IP addresses,
we will convert them to bogus addresses before posting the analysis. I'm
working on a method of tracking these spoofed packets back to their
source and the more data the better. ;)

Since I'm on the subject. The link above is also a good learning tool
for figuring out what to look for in your logs. There are lots of
examples of suspicious traffic along with an explanation of what you are
looking at.

Happy hunting,
Chris

--
**************************************
cbrenton_at_sover.net
* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
Received on Dec 31 1999
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]