-
July 11th, 2003, 02:47 PM
#21
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:
-
July 11th, 2003, 05:52 PM
#22
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
-
July 15th, 2003, 02:28 AM
#23
Member
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?
-
July 21st, 2003, 05:21 PM
#24
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:
-
July 21st, 2003, 05:57 PM
#25
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?\"
-
July 21st, 2003, 06:52 PM
#26
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)
-
July 21st, 2003, 07:03 PM
#27
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?\"
-
July 21st, 2003, 07:24 PM
#28
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:
-
July 22nd, 2003, 04:18 PM
#29
Member
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).
-
July 22nd, 2003, 04:32 PM
#30
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
-
Forum Rules
|
|