ICMP Destination Unreachable (Communication Administratively Prohibited) - Page 3
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 33

Thread: ICMP Destination Unreachable (Communication Administratively Prohibited)

  1. #21
    I'd rather be fishing DjM's Avatar
    Join Date
    Aug 2001
    Location
    The Great White North
    Posts
    1,867
    Originally posted here by Maestr0
    Forgive me if I havent understood you correctly but I dont see how that would matter since the AV software will connect to it's SMTP server (which should be valid) and then send an e-mail to the forged adress which will return a 'message un-deliverable(550)' from the destination SMTP server (If it even exists otherwise the local SMTP will be unable to establish a connection). Even if the AV has its own SMTP server and tries to identify the source IP in the mail header, it should still try to establish a valid session on port 25.An ICMP code 13 means a router refused to route the packet, not that that the destination host was unavailable. Why would a router not in the packet traceroute be sending a code 13 for what was theoretically a handshake to port 25 somewhere ?(these ports still dont add up )
    Maestr0, it is my understanding that an ICMP type 3, code 13 can be returned for any number of reasons. If a device is set up to not route various traffic (ICMP, SMTP, TCP, UDP) it can return a destination unreachable message (which is the default on various routers).

    Now having said this, the situation with the antivirus e-mail may not be my problem as I am receiving way more ICMP messages than I am virus hits.

    The investigation continues..........

    Cheers:
    DjM

  2. #22
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    An ICMP type 3 code 13 is used when a router has been told explicilty to deny a packet. A destination or network or host un-reachable would be a type 3 code 0-5. I am becoming increasingly convinced you are recieving ICMP backscatter from a DOS attack or SPAMing (perhaps using your block to avoid ingress filtering?), This is by no means a solid hypothesis but this would explain the apparently random high src/dst ports . If you could post more details on the amount of this traffic you are seeing and some packet dumps I would be very interested to see them. Here are some links you may want to examine and see if you think it may apply to your situtation.

    -Maestr0


    Links:

    http://www.mynetwatchman.com/kb/security/backscat.htm
    http://www.isse.gmu.edu/faculty/pammann/821/Saket1.ppt
    http://citeseer.nj.nec.com/cache/pap...3detecting.pdf
    http://citeseer.nj.nec.com/cache/pap...3framework.pdf
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  3. #23
    Member
    Join Date
    Feb 2003
    Posts
    35
    I, as well, am still seeing a few of these alerts on my IDS. Though I have not figured them out, I can attest that they are NOT the result of spoofed traffic, but are the result of hosts on my LAN communicating with hosts on the Internet (at least this is the case in my environment). Why do I think this, because -- 1) The original source address is a class C private address: 192.168.0.x. Someone using this address as a spoofed source would not be able to route traffic back to my LAN. 2) Because I have been able to recreate the alerts by sending packets to the destination hosts and ports listed in the alerts and have sucessfully triggered an ICMP 3 type 13 alert from the very same filtering device listed in the alert.

    All of my alerts are triggered on destination ports 25, 80 and 53. Why? Because these are open outgoing ports on my firewall. So what does this mean to the original poster of this thread? That perhaps he or she is seeing alerts flagged on port 25 not because of spoofed mail (which I also very highly doubt is the case), but because port 25 is open outgoing on his or her firewall. The commonality between all the destination ports listed in my alerts is that they are all permitted outgoing ports on my firewall. Since just about all else is blocked, I only get alerts triggered on these ports.

    I am still perplexed a little by these alerts since they all indicate that ICMP traffic is making it back through my firewall, which would mean that Checkpoint must considers these messages to be part of the original stream and hence in the state table (I also sometimes see ICMP source quench make it back through to my LAN). I have tested and verified that all ICMP traffic is blocked at my firewall. Yet, these control type ICMP messages still get back to my hosts. There is no commonality among hosts triggering these alerts; they are of all types--Linux, Unix, Windows, servers, PCs and hardware devices. I guess I'll have to post something for the Checkpoint gurus on this one.

    Could it simply be that our boxes are sending legitimate traffic to sites that decide (for one reason or another) to filter out the traffic? Though I do not have a dump of the original traffic that triggered the ICMP 3-13, it does seem to me that I am getting these messages back as a result hosts on my LAN going about their normal business. Does anyone else have any suggestions before I starts trying to tcpdump everything?

  4. #24
    I'd rather be fishing DjM's Avatar
    Join Date
    Aug 2001
    Location
    The Great White North
    Posts
    1,867
    Well I think we finally tracked this down. I was sure it had something to do with SMTP traffic and it looks like it did. Our Sendmail lives in our DMZ, now Sendmail sends out Ident protocol packets to determine who is at the other end. If there is a router or firewall in the way that is BLOCKING Ident traffic (at their end), then we will get back an ICMP Destination Unreachable. Sendmail needs to send out Ident traffic but doesn't need to receive it. We reconfigured our firewall and all seems fine now.


    Cheers:
    DjM

  5. #25
    Senior Member
    Join Date
    Apr 2002
    Posts
    712
    Ummm... I might be missing something here... but, tracing to the original destination address, as indicated in the payload, the source address (of the "attack") comes back with a dest_unreachable... indicating that the route goes through your "attacking" host and that you/it can't get to the ports on the server in-question... (mail.nexusds.com)

    Code:
    traceroute to 205.233.93.249 (205.233.93.249), 30 hops max, 40 byte packets
    [...]
     8  64.125.30.158  84.689 ms  80.973 ms  82.536 ms
     9  64.125.12.38  82.477 ms  81.985 ms  84.070 ms
    10  206.108.103.121  83.577 ms  82.821 ms  83.219 ms
    11  206.108.103.113  91.802 ms  93.423 ms  93.983 ms
    12  64.230.242.102  92.680 ms  94.281 ms  94.056 ms
    13  64.230.229.10  93.024 ms  92.928 ms  92.665 ms
    14  64.230.219.238  94.574 ms !X *  94.844 ms !X
    Yeah, ICMP dest unreachables could be used by a malicious source to map your network, but... in this case I think (qc.sympatico.ca) might be doing it's job and saying you "can't reach that host on those ports," etc. Do you have something from that host that's trying to connect? Perhaps something trying to "phone home" or the like?

    Ever hear of Nexus Data Systems? Perhaps they did a web page or form for you and it's sending mail or data back to them or something...???

    Bah... teach me to reply and not read to the end of a thread... yeah, ident would do it. One of the reasons you should always reject/refuse (as compared to drop) identd... thanks to MS for not following yet another standard.
    \"Windows has detected that a gnat has farted in the general vicinity. You must reboot for changes to take affect. Reboot now?\"

  6. #26
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    DjM:

    Thanks for the update, would have given you some green for it but apparently anticode thinks I have been too nice to you. On one note, why not just turn off the ident part of sendmail rather than have your firewall reject it?

    http://www.ussg.iu.edu/usail/mail/op/op-sh-2.9.html
    http://www.luci.org/luci-discuss/200301/msg00006.html

    Jist: look for line:
    #O Timeout.ident=5s

    in your sendmail.cf
    set it to 0 and no more idents...

    /nebulus
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  7. #27
    Senior Member
    Join Date
    Apr 2002
    Posts
    712
    Originally posted here by nebulus200
    [B]DjM:

    Thanks for the update, would have given you some green for it but apparently anticode thinks I have been too nice to you. On one note, why not just turn off the ident part of sendmail rather than have your firewall reject it?
    When people say "turn off," the net effect is that the connection's rejected - so it's essentially the same thing... the difference being that rejecting it at the firewall keeps it from even entering the network -- but it should be rejected (ie. told the connection's refused) rather than dropped (ie. ignored), so-as to speed up the outgoing SMTP process.

    ...then again, timeout refers to "outgoing request," so it's sendmail's return ident to an incoming SMTP request. So... yeah, exactly opposite. *smacks self in head*
    \"Windows has detected that a gnat has farted in the general vicinity. You must reboot for changes to take affect. Reboot now?\"

  8. #28
    I'd rather be fishing DjM's Avatar
    Join Date
    Aug 2001
    Location
    The Great White North
    Posts
    1,867
    Originally posted here by nebulus200
    DjM:

    Thanks for the update, would have given you some green for it but apparently anticode thinks I have been too nice to you. On one note, why not just turn off the ident part of sendmail rather than have your firewall reject it?

    http://www.ussg.iu.edu/usail/mail/op/op-sh-2.9.html
    http://www.luci.org/luci-discuss/200301/msg00006.html

    Jist: look for line:
    #O Timeout.ident=5s

    in your sendmail.cf
    set it to 0 and no more idents...

    /nebulus
    Thanks nebulus, the cowboy that admin's the sendmail server seems to think he needs it turned on, after reading the first link you provided, I have my doubts now too. I am going to pose this question to him.

    Thanks again.

    Cheers:
    DjM

  9. #29
    Member
    Join Date
    Feb 2003
    Posts
    35
    Originally posted here by DjM
    Well I think we finally tracked this down. I was sure it had something to do with SMTP traffic and it looks like it did. Our Sendmail lives in our DMZ, now Sendmail sends out Ident protocol packets to determine who is at the other end. If there is a router or firewall in the way that is BLOCKING Ident traffic (at their end), then we will get back an ICMP Destination Unreachable. Sendmail needs to send out Ident traffic but doesn't need to receive it. We reconfigured our firewall and all seems fine now.


    Cheers:
    If ident is triggering these snort alerts, the original destination port listed in the alert should be 113. In some of the alerts you have posted, I have seen other destination ports referneced beside 113. I would not chalk this one up to ident traffic originating from your sendmail box unless all of your alerts specifically reference 113 (unless of course ident uses other ports I am unaware of).

  10. #30
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    The plot thickens......


    -Maestr0
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

Posting Permissions

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