Re: ICMP Destination Unreachable, Administratively Prohibited

On Thu, 2003-02-13 at 17:35, Neil Dickey wrote:
>
> I have noticed what appears to be a new ( to me, anyway ) sort of scan in my

Doubtful this is a some kind of a scan. These are ICMP type 3 packets, which never stimulate a response. This means that whether it reached your internal host, or got blocked by a firewall, no reply would be returned. No reply means that its not very useful as a scan. This also rules out you being the quiet host end of an idle scan.

> I'm getting a "Dest. Unreach." signal

Just because no one is in your office, does not mean that no one is using your systems. ;-)

> Eight different machines at our site were involved, including

Based on this info, I'm leaning towards someone is spoofing your address space (maybe decoy packets?). Reasoning is below.

> I checked the unix boxes, and nothing was

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

To be honest, this is not very reliable. If the box is whacked I doubt you would see anything in the logs even if there was a purp on the system generating this traffic. As a .edu you are probably restricted from controlling traffic across your perimeter, but you may still want to consider a firewall to log all passing sessions. That way you would know for sure if it came from your network.

> The "original" traffic was supposed to have been directed at port 22 on what

There are some other interesting tid bits in the payload of each of the traces you posted:

1. TTL The TTL in each stimulus packet is 124. UNIX flavors are going to use a starting TTL or 64 or 255. The only thing close to this is Windows at 128 but that would imply the Windows box is 4 hops from the router. Regardless, you say multiple OS types generated these packets and they would not all have the same starting TTL. This tells me the packets probably did not come from your network, but at a minimum they are crafted.
2. Sequence #'s and IP IDs The sequence numbers are linear and the IP IDs range from 11103 --> 11326. The chances of this happening in the wild are about on par with someone who does not play the lottery actually winning. This tells me that all of the original stimulus packets originated from the same system.
3. Flag settings All of these packets have the ACK flag set. This implies that the original source IP had already established a connection with the router, which of course is not the case. My guess is at one time this router used regular extended access lists to protect itself which would have permitted this packets to sneak through. The owners have up setup Reflexive filters which do have the capability of filtering out bogus ACK packets.

So I can tell you for certain that the packets are crafted. As for whether they originated from your network, hard to say. Two things will tell you for certain:

1. If you logged outbound traffic (this option is out)
2. Find out from the owner of the router if any other source IP was used during these probes.

If other source IP's were used, it may not have come from your network. If your IP address space was the only thing spoofed, the attacker would need to sniff the replies somehow which implies they own one of your boxes or possibly a box up stream.

HTH,
C

-- 
************************************** 
cbrenton@chrisbrenton.org

'find / -name \*yourbase\* -exec chown us:us {} \; '


----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: 
http://aris.securityfocus.com