Results 1 to 9 of 9

Thread: Cisco IDS reporting strange ICMP DoS attempts

  1. #1
    Senior Member
    Join Date
    Mar 2003
    Posts
    372

    Cisco IDS reporting strange ICMP DoS attempts

    So we are running a few Cisco IDS/IPS blades on our network. One of them has been reporting some strange activity to our external SMTP load balancer IP address, and occasionally to one of our external nameservers. It is seeing this a /lot/ but only a few times from each IP address, and no where near what a real DoS or DDoS would be.

    My quick research has shown this as a possibility as we are seeing ICMP Hard Error with Port Unreachable flag.

    Has a botnet stumbled across our IP range, or do we have a pissed off customer that is trying to craft ICMP Hard Errors in an attempt to reset connections for legit traffic?

    This started on Thursday 11/2 and has been steady since then.

    Here is a copy of the event from one of our IDS boxes.

    Code:
    evIdsAlert: eventId=1161202650020384082  vendor=Cisco  severity=medium  
      originator:   
        hostId: sanitized
        appName: sensorApp  
        appInstanceId: 548  
      time: November 8, 2006 9:50:48 AM UTC  offset=-480  timeZone=PST  
      signature:   description=ICMP Hard Error DoS  id=2157  version=S158  
        subsigId: 1  
        sigDetails: Port Unreachable  
      interfaceGroup:   
      vlan: 1007  
      participants:   
        attacker:   
          addr: xxx.xxx.xxx.xxx sanitized locality=OUT  
        target:   
          addr: xxx.xxx.xxx.xxx sanitized locality=OUT  
      riskRatingValue: 63  
      interface: ge0_0  
      protocol: icmp

    I'm open to any suggestions or comments.

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

  2. #2
    Senior Member
    Join Date
    Mar 2004
    Posts
    119
    I would need to know a little bit more about your network structure before I could answer that. Is the load balancer in the DMZ with the sensor?

  3. #3
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    Hookup a sniffer and capture some of that traffic. That will quickly tell you what it is..

    You should only receive an ICMP port unreachable if you send an UDP packet to a closed port. A TCP packet to a closed port should return a RST.

    As I said, capture the ICMP traffic, information on what caused the ICMP port unreachable is contained in the ICMP message. Wireshark will show all the info.
    Last edited by SirDice; November 8th, 2006 at 09:27 PM.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  4. #4
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    Net2Infinity Well yes and no. The NAT address to the balancer is in the DMZ with the sensor, but the physical device resides inside of our network behind a PIX.

    The PIX is also seeing these ICMP packets to the internal address but is stopping them.


    SirDice I would love to do that, but getting approval for a sniffer on that segment is a work of god sometimes. Unless I can show them that we are being impacted, and right now we aren't, then I doubt they are going to let me hook up a sniffer to chase down /why/ we are seeing these Hard Errors.

    We have a very large pipe, and some very beefy equipment. It is going to take a lot to bring us down. So right now I'm chasing this event just for my own "enjoyment". I'm curious as to why I'm seeing this suddenly and what it could possibly mean for us.

  5. #5
    Senior Member
    Join Date
    Mar 2004
    Posts
    119
    I would look at your access-lists to see what traffic you are allowing from the outside interface to the DMZ. Sounds like you are allowing all ICMP inbound.

  6. #6
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    Quote Originally Posted by Net2Infinity
    I would look at your access-lists to see what traffic you are allowing from the outside interface to the DMZ. Sounds like you are allowing all ICMP inbound.
    actually we aren't. We have some Fixup rules on the firewall that make it look like the balancer has ports open but in reality it doesn't. I've gone through all of the ACLs and no ICMP is allowed inbound. The PIX is reporting it to the internal IP simply because it is a NAT'd address for the same box... no traffic is really making it there.

    That was one of the first things I was worried about also. ICMP inbound = bad.

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

  7. #7
    Senior Member
    Join Date
    Mar 2004
    Posts
    119
    I think there is some confusion as fixup merely allows application inspection it doesn't actually open any ports. Since you mentioned fixup's I will assume you are running 6.3 code. At this point in time the only way to determine if its a false positive is to run a sniffer like previously suggested.

  8. #8
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    If you can't run a sniffer, just do the next best thing and capture on the pix itself:

    I don't have the exact syntax in front of me, but it should run something like this:

    access-list acl-capture permit ip host blah1 host blah2
    access-list acl-capture permit ip host blah2 host blah1

    capture mycapture acl-capture

    copy /pcap capture:mycapture tftphost:mycapture.pcap

    And you just got yourself a nice pcap file to analyse...


    Ammo
    Credit travels up, blame travels down -- The Boss

  9. #9
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    well I pulled some strings and popped a sniffer on there. I used my laptop with Wireshark... I captured about 20 minutes of activity and it took over 1.5 hours to process the cache from that capture. The capture file was 1.2G!

    I'm going to be looking at this capture to find out what those packets really look like, but I'm sure it is going to take a while.


    *EDIT* heh, after I disconnected the laptop from the monitor port it cached data for another 30 minutes. Plugging in to a gig port on a Catalyst 6500 is a bad idea sometimes.
    Last edited by Lv4; November 9th, 2006 at 06:48 PM.

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •