Re: ICMP Destination Unreachable, Administratively Prohibited

From: Chris Brenton (cbrentonat_private)
Date: Thu Feb 13 2003 - 15:26:46 PST

  • Next message: Russell Fulton: "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
    > Snort logs, which are appended below. 
    
    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
    > from an educational network in Beijing, China, that arrived at a time when
    > no-one was using the boxes from which the TCP sessions were supposed to have
    > originated.
    
    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
    > unix boxes, printers, and PCs. 
    
    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
    > active on the outbound ports, e.g. port 1432 on 131.156.X.AA in the logs
    > below.
    
    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
    > appears to be a Genuity router, 4.24.204.90 .  That was what initially caught
    > my eye.  Outbound SSH traffic from a printer just isn't that common around
    > here.  ;-)
    
    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
    -- 
    ************************************** 
    cbrentonat_private
    
    '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
    



    This archive was generated by hypermail 2b30 : Thu Feb 13 2003 - 19:07:20 PST