If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

\"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

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?

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.

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)

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?\"

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?

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.

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.

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?

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.

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).

\"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