ICMP Destination Unreachable (Communication Administratively Prohibited)

Since Friday I have been seeing some different hits in SNORT. I am getting a lot of "ICMP Destination Unreachable (Communication Administratively Prohibited)" records. Now when I look at the Alerts page it shows Source address as a computer outside my network and the destination address as my web server. How if I look at the "Payload" (attached) it says my web server is the source address and I am trying to ping an external address (which I'm not). Now I googled this and didn't really find much, but there was some comments made about "Spoofing". My question, does this look like my web servers IP address is being spoofed and sending out ping sweeps? :confused:


Thanks

to me its looks like sm1 is sending some TCP packets to your web server with a spoof source address that does not exist. I guess that the TCP packet is a Syn/Ack
When you reply to the TCP probe
- the last router that owns the spoofed source knows the address is not reachable and reply with an ICMP unreachable
- Or a firewall block the traffic and reply an ICMP unreachable (Netfiltyer offers an option to do that).

Maybe someone is scanning u in a decoy mode or is trying to perform a syn dos...

Quote:

---

Now when I look at the Alerts page it shows Source address as a computer outside my network and the destination address as my web server. How if I look at the "Payload" (attached) it says my web server is the source address and I am trying to ping an external address (which I'm not).

---

These two things actually agree. If you try to connect to a machine and it isn't reachable/up, the device that would route the packet there is supposed to send back an ICMP Unreachable packet back to the source to let it know that the machine is down. This is something I would expect to see if your web server was attempting to make a connection outbound to some random IP (it doesn't necessarily have to be caused by a ping sweep).

Quote:

---

My question, does this look like my web servers IP address is being spoofed and sending out ping sweeps?

---

This is much more difficult to answer and the picture you attached is too garbled for me to make much sense of, and without the SNORT alarms or something else too look at, I really can't make suggestions beyond things for you to check for.

1) Do you have any anti-spoofing filters setup at your boundary devices? If not, you really should, ingress and egress filtering can do alot to weed spoofing out as a possibility, essentially telling the router that your internal addresses can not exist on the outside and should not be let back in.

2) Do you have any AV software installed on the web server itself, or have you inspected it for malicious software? Worms like Code Red, Nimda, Sadmind, etc, all spread by choosing another IP at random and then attempt a connection. Since the IP picked is random, the chance of receiving ICMP Destination Unreachable packets are high (assuming you don't block ICMP entirely at your gateways.

My advice is to inspect your web server carefully to ensure that no access has been obtained, either by a worm or by a hacker.

/nebulus

Its hard to say, it could be harmless or it could be a scan from a spoofed IP or a DoS attack. How frequent are these alerts? If its obviously not a DoS attack than its most likely a portscan of some type thats generating the unreachable message.The ICMP message should have the first 8-bytes(I think its 8 :)) of the original packet which generated the error, if you log the packets in detail, maybe that will tell you something.Heres the SNORT page referring to your alert http://www.snort.org/snort-db/sid.html?id=485
Also this is interesting: http://www.geocrawler.com/archives/3.../12/0/4883899/

-Maestr0

EDIT:As nebulus said the pic was a bit garbled and doesnt show any packet contents,try a traceroute to the IP and see if there is something filtering ICMP packets(firewall?) Could be someone is pinging you and a router wont allow a response thru from your webserver.(Blocking ICMP_echoreply maybe?)

Quote:

---

Originally posted here by Maestr0
EDIT:As nebulus said the pic was a bit garbled

---

Yea sorry about that, I was in a hurry. I'll try and give you some clearer info.

This is from the snort logs:

[**] [1:485:2] ICMP Destination Unreachable (Communication Administratively Prohibited) [**]
[Classification: Misc activity] [Priority: 3]
07/07-10:05:51.515319 12.127.88.98 -> 172.XX.X.X
ICMP TTL:238 TOS:0x0 ID:42755 IpLen:20 DgmLen:56
Type:3 Code:13 DESTINATION UNREACHABLE: ADMINISTRATIVELY PROHIBITED,
PACKET FILTERED^@
** ORIGINAL DATAGRAM DUMP:
172.XX.X.X:0 -> 198.112.234.22:0
TCP TTL:50 TOS:0x0 ID:62790 IpLen:20 DgmLen:48 DF
Seq: 0x6C5F473C Ack: 0x0
** END OF DUMP

And the attached should be a clearer pic from ACID.

Thanks for your help gang.

Ok, this is weird... In the dump of text, you have 12.127.88.98 telling you ICMP Destination Unreachable, admin prohibited and in the screenshot you have a 64 address telling you the same thing.

In both cases, the address telling you that ICMP prohibited is not the address that the packet appeared to be going to, which isn't necessarily out of the ordinary; however, the addresses telling you this do not match the networks the packet is attempting to go to, which I wouldn't expect, at least not on the surface.

1) If you traceroute to the IP's in question (the one's purported to be the original packet), do the networks that send you ICMP administratively prohibited come up (Ie, are they along the path and therefore could possibly be responsible for the message). If they aren't, then maybe you have some spoofing going on with crafted packets, for what purpose I can't think of right now...in that case, check your logs for connections from the IP's that sent the unreachable message.

2) Do you allow your webserver to make outgoing connections of any kind? One of the machines in question purported to be a mailserver (and I checked, it is running Microsoft ESMTP); however, the ports didn't match up with what I would expect out of an SMTP session (both very high numbered).

3) The only traffic I can think of that would generate the high ports like that would be the data session of a FTP connection; however, the mail server doesn't have FTP listening, which still leaves the possibility that they were FTP'd to you. Do you run an FTP server on your web server? Do you see those IP's in your logs anywhere?

3) Still need to know whether or not you do ingress/egress filtering to prevent spoofing. If you have the proper ACL's setup, that would allow you to mostly rule out the possibility of a spoofed packet.



/nebulus

Quote:

---

Originally posted here by nebulus200
Ok, this is weird... In the dump of text, you have 12.127.88.98 telling you ICMP Destination Unreachable, admin prohibited and in the screenshot you have a 64 address telling you the same thing.

---

Just to clear that up, these are two different Alerts. One text and one GUI. :p

Quote:

---

) If you traceroute to the IP's in question (the one's purported to be the original packet), do the networks that send you ICMP administratively prohibited come up (Ie, are they along the path and therefore could possibly be responsible for the message). If they aren't, then maybe you have some spoofing going on with crafted packets, for what purpose I can't think of right now...in that case, check your logs for connections from the IP's that sent the unreachable message.

---

I traced the 64.230.219.238 and it appears to the part of the bellglobal network. The 205.233.93.249 address does trace back to mail.nexusds.com.

Quote:

---

Do you allow your webserver to make outgoing connections of any kind? One of the machines in question purported to be a mailserver (and I checked, it is running Microsoft ESMTP); however, the ports didn't match up with what I would expect out of an SMTP session (both very high numbered).

3) The only traffic I can think of that would generate the high ports like that would be the data session of a FTP connection; however, the mail server doesn't have FTP listening, which still leaves the possibility that they were FTP'd to you. Do you run an FTP server on your web server? Do you see those IP's in your logs anywhere?

---

The only connections to this box are inbound HTTP, HTTPS & SMTP, nothing else is allowed.

Quote:

---

Still need to know whether or not you do ingress/egress filtering to prevent spoofing. If you have the proper ACL's setup, that would allow you to mostly rule out the possibility of a spoofed packet.

---

Checked with the Web folks on this one and apparently the is no filtering being done for this box. I am going to be reading up on this, maybe you can point me in the right direction.
The web server in question is running Solaris & Apache.


Thanks Again

Quote:

---

I traced the 64.230.219.238 and it appears to the part of the bellglobal network. The 205.233.93.249 address does trace back to mail.nexusds.com.

---

You missed what I was saying...

If you look at the packet, the IP that is supposidly sending you the ICMP Unreachable's is the 12.127.88.98, but if you look at the contents of the packet, the packet was destined to a different address entirely...unless 12.127.88.98 is along your routepath to the destination mentioned in the original packet (look at your decodes), chances are it is being spoofed somehow...So,

Quote:

---

07/07-10:05:51.515319 12.127.88.98 -> 172.XX.X.X
ICMP TTL:238 TOS:0x0 ID:42755 IpLen:20 DgmLen:56
Type:3 Code:13 DESTINATION UNREACHABLE: ADMINISTRATIVELY PROHIBITED,
PACKET FILTERED^@
** ORIGINAL DATAGRAM DUMP:
172.XX.X.X:0 -> 198.112.234.22:0
TCP TTL:50 TOS:0x0 ID:62790 IpLen:20 DgmLen:48 DF
Seq: 0x6C5F473C Ack: 0x0

---

The original packet was to 198.112.234.22, so do a traceroute there...does 12.127.88.98 show up in the routepath? If it is still not clear what I am wanting and why, let me know and I will take another stab at it.

Quote:

---

Checked with the Web folks on this one and apparently the is no filtering being done for this box. I am going to be reading up on this, maybe you can point me in the right direction.
The web server in question is running Solaris & Apache.

---

While you could do some kind of filtering on the web server, this is not what I meant. I meant setting up ACL's in your boundary routers or firewall to prevent spoofing. Your web server is not really going to know if the packet is being spoofed or not, but your firewall and/or router will because it should be told that 'your' addresses can not show up on the outside interface. If you need me to elaborate a little more I can...

/nebulus

Sorry nebulus, I am going 200 miles an hour here.

Quote:

---

The original packet was to 198.112.234.22, so do a traceroute there...does 12.127.88.98 show up in the routepath? If it is still not clear what I am wanting and why, let me know and I will take another stab at it.

---

I did the and, no, 12.127.88.98 does not show up in the routepath.

Quote:

---

While you could do some kind of filtering on the web server, this is not what I meant. I meant setting up ACL's in your boundary routers or firewall to prevent spoofing. Your web server is not really going to know if the packet is being spoofed or not, but your firewall and/or router will because it should be told that 'your' addresses can not show up on the outside interface. If you need me to elaborate a little more I can...

---

Misunderstood you again here (having a good day), we are in fact performing anti-spoofing filtering at our firewall.

We are still digging into this, today (so far) I have had 124 occurrences of this alert (approx. 300 in last 72 hours). We upgraded our firewall on Friday to Check Point NG (feature pack 3), do you thing this may have anything to do with these alerts?

If the 12.127.88.98 doesn't show up along your routepath to 198.112.234.22, I would say that you are probably seeing spoofed traffic. Now, as far as I can tell, that leaves two possibilities, one someone is sending you spoofed/crafted packets for some reason that I can't envision right now (I am going to do a little research) or two, they are nmapping 198.112.234.22 (or something to that effect) and 12.127.88.98 is along THEIR routepath and they are using nmap in decoy mode with your web server as the source.

If I am thinking of this correctly, which I might not be, kinda zoned out at the moment, if a Hacker is sitting out there and sends a spoofed packet (maybe they left the ping option on) to the 198.112.234.22 address then what I would suspect is the case is that 12.127.88.98 is along their routepath somewhere and it is issuing the ICMP Unreachable; however, I am unable to verify this in that I can not receive a response from 12.127.88.98 when I try to telnet to it, which makes it look like it is down; however, given that it is registered to ATT worldnet, I wouldn't be suprised if it is a router...

My best guess right now is that 12.127.88.98 lies somewhere between the real source of the packet and the destination 198.112.234.22 and that the packet is being routed back to you do to the spoofed source. I am mildly suprised that the firewall didn't notice that an ICMP echo request never went out and then dropped the error message, but not overly suprised. If this scenario is accurate, I wouldn't overly worry about it, there really isn't anything you can do about it anyway (except maybe take note of it in case the 198.112.234.22 admins complain).

As far as the first scenario goes about crafted packets. The ICMP packet you showed appears to have plenty of valid information in it, which is what I wouldn't expect if it was a covert channel, so I put the chances at this at very remote.

Regardless, have a look over your web server security, make sure it is up to date, that there is no suspicous activity on it (unexplained processes, zombie processes, missing log entries, etc), and you should be ok (even if you don't, you are probably still ok). We have disabled all icmp of any kind on our network, so we have those signatures turned off. I would consider disabling all ICMP at your boundary (firewall) and turn off the signatures. There are really other ways to test connectivity without allowing ICMP into your network.

/nebulus

I think Nebulus is on the $, these could very well be forged packets. Some strange things are happening here. We have ICMP packets from 2 totally seperate source IPs. Both packets are code 13. Which SHOULD mean a router wont route them so the ICMP source IP must be a router, except they both appear to be from(sez arin) Canadian ISPs(which you said was not in traceroute). Also, not sure if it matters but the TTL time on both ICMP packets from different ip's are almost identical(2 hops difference).The Canadian ISP seems to have a big spam problem, dont know if its related to this but probably worth checking if there's spoofing afoot. More packets would be great if you have them.

-Maestr0

Quote:

---

Originally posted here by nebulus200
two, they are nmapping 198.112.234.22 (or something to that effect) and 12.127.88.98 is along THEIR routepath and they are using nmap in decoy mode with your web server as the source. /nebulus

---

nebulus,
Exactly along the lines I was thinking. Notice one of the destination IPs (From the dump of a packet supposedly originating from 172.24.x.x)which generates the ICMP was a mail server. Maybe a spammer is spoofing with 172.24.x.x as the spoofed source IP and confusing a router(who ICMPs) along the real route from the spammer? I know the ports dont add up but its the only thing I can think of without more information. Any thoughts?

-Maestr0

Thanks nebulus, Maestr0 & Networker. We have pretty much resigned ourselves to the fact we are being spoofed and have shutdown all ICMP traffic in our DMZ. This will kill all the snort alerts but does not stop the spoofing. I have contacted our ISP to inform them what is going on just in case they receive any abuse reports. I wish there was more we could do, but it would appear life on the internet is a bitch.

Cheers:

DJM,
there is a high possibility that sm evil is bouncing on your web server to build a DrDoS attack against Bell. (If they were stupid enough to generate ICMP unreachable, I think their CPU ressources may be overloaded very quickly.)
If this scenario is correct there is no real danger for ur net, but you have a moral responsability to stop your unwilling cooperation to an evil attack. (U could setup in ur frw a filter IP addy based for few daze)

Quote:

---

Originally posted here by Networker
DJM,
there is a high possibility that sm evil is bouncing on your web server to build a DrDoS attack against Bell. (If they were stupid enough to generate ICMP unreachable, I think their CPU ressources may be overloaded very quickly.)
If this scenario is correct there is no real danger for ur net, but you have a moral responsability to stop your unwilling cooperation to an evil attack. (U could setup in ur frw a filter IP addy based for few daze)

---

Networker, the example I have attached here is just one example of the alerts I am seeing. In the other alerts the destination IP address changes, so whatever is happening is not just targeting Bell. To set up firewall rules to filter all address would be a huge effort. Now we believe a couple of things might be happening. 1) Our address is being spoofed for performing a ping sweep or port scan with something like NMAP. 2) The address is being spoofed for sending out spam (a lot of the servers seem to be mail servers). We are still investigating, but we are not sure there will be anything we can do about it.

Cheers:

I've been seeing the same type of alerts on my snort box. I usually get one or two every few days and have yet to figure them out either. The ICMP messages seem to be directed back to boxes on my LAN, as well as my DMZ, and originate from random hosts on the internet. However, I'm not sure that these ICMP messages are the result of spoofed traffic since all my boxes use private class C addresses. Also, I have all ICMP traffic blocked at my firewall (incoming and outgoing), so it is weird that ICMP Destination Unreachable is making it back to my LAN. I'm fairly new to Checkpoint, but I'm imagining that Checkpoint must regard ICMP type 13 traffic as being part of an already established stream to allow this traffic back to my LAN hosts. Otherwise, it should be dropped. Shouldn't it? Almost exclusively, port 80 is involved in the TCP/IP socket generating these alerts, either as the original source port or an original destination port. This makes some sense to me since we allow outgoing traffic to port 80 from the LAN and incoming traffic for 80 to webhosts on our DMZ, but that's TCP not ICMP.

With all this in mind, I am fairly sure the original packets that trigger these alerts do in fact come from my network, since a spoofed packet with a forged source address like 192.168.0.x would never route back to my LAN. Like you all, I am a bit perplexed though I am not yet ready to call this traffic malicious (even though I am keeping an eye on it). Perhaps something else is going on that is marking these packets as 'droppable' by whatever hosts seem to be performing the filtering and sending back the ICMP messages. But if that is the case, what else could that be?

The only thing I can recommend both of you do is to set up a sniffer at your DMZ and record traffic for say a 24 hour period (all of it, so make sure you have pretty big disks) into a pcap file and then pull it up in something like ethereal. See if you can't find a correlation between the purported sources of the ICMP unreachable (not who sent you the message but rather the source noted in the packet) and traffic you send out. If you can't find any correlation between the messages you are getting back and the traffic you are sending out, then you are suffering from some kind of spoof.

Unless you are seeing very large numbers of these kinds of packets (for example maybe the result of a smurf or some similar type of attack), I wouldn't overly worry about it. Another thing you can do is that if you are seeing these packets from supposidly multiple originations, then you could compare the contents of the packet to see how similar they are (for example, maybe the TTL is all the same), which might indicate that it is all coming from one person, versus drastically different TTL's which might indicate more than one source. If other packets are very similar in their content, you might could even start considering whether or not the same program caused them...

Kind of wish I could help more, but like I said earlier, we don't allow ICMP of any kind, so not really anything more I can do but make some suggestions...

/nebulus

EDIT: You may also want to consider talking to the folks with the dshield project (distributed IDS). They tend to see alot of the bigger picture since they get reports from all over the world and might provide you some interesting insight, hell maybe you can even get a research/white paper topic out of it and a little name recognition...

Like I said, the only thing that makes my wonder about this traffic is that we also block all ICMP traffic, inbound and outbound. So I looked at these alerts and said "Humm, how the hell did that get back through my firewall." Like I said, i see about one of these alerts every two or three days. I am currently suspicious of them, but not overly worried.

Quote:

---

Originally posted here by tolstoy
Like I said, the only thing that makes my wonder about this traffic is that we also block all ICMP traffic, inbound and outbound. So I looked at these alerts and said "Humm, how the hell did that get back through my firewall." Like I said, i see about one of these alerts every two or three days. I am currently suspicious of them, but not overly worried.

---

OK Guys, I am not sure if I am on to something here or not, but tolstoy, do you happen to have an antivirus system which, when it detects a virus, will attempt to send an e-mail to the who "it" thinks sent the e-mail. Because for the way the current batch of viruses spoof e-mail address, which sometimes are totally invalid, I am think we are getting these ICMP responses because the e-mail can't reach its destination.
I am going to try and test this theory but I likely can't get to it until tomorrow. Anyways, do you have this type of system set up tolstoy?

Cheers:

Quote:

---

OK Guys, I am not sure if I am on to something here or not, but tolstoy, do you happen to have an antivirus system which, when it detects a virus, will attempt to send an e-mail to the who "it" thinks sent the e-mail.

---

EDIT: I sounded like an ass when i wrote it the first time...Please let me know if that was it, because it sounds like a very plausible possibility...

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 :( )

Quote:

---

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:

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

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.


Cheers:

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.

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

Quote:

---

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*

Quote:

---

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:

Quote:

---

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

The plot thickens......


-Maestr0

Quote:

---

Originally posted here by tolstoy


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

---

Gee thanks tolstoy, that just made my day ;)

Fact of the matter is, we still have one or two slipping through (even after we reconfigured the firewall), we did manage to stop about 90% of the messages though. We can't shutdown all Ident coming out of sendmail because when we tried, all inbound e-mail was stopped. We are still investigating the one or two that are coming in but the may be because of this port thing, or something else is sending out a request.

The adventure continues.....

I'm still seeing these occassionaly alerts as well. They are being generated by three boxes on my network, one being a sendmail box (just like you), but the other two are Win2k Pro, and are the result of web browsing. I'm a bit worried/perplexed because the traffic triggering these alerts is only coming from those two LAN boxes and is going out over port 80. Right now I'm staring to run daily tcpdumps to try to see what the heck is in the packets that trigger these remote routers to respond with an ICMP message. Hopefully its all benign stuff.

Quote:

---

Originally posted here by tolstoy
Right now I'm staring to run daily tcpdumps to try to see what the heck is in the packets that trigger these remote routers to respond with an ICMP message. Hopefully its all benign stuff.

---

I agree, I believe these to be benign as well, we would just like to locate the root cause (other than the Ident stuff). We are currently running a 'snoop' on our firewall to see what that is going to tell us.

Cheers: