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.

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?

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

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

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

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.

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

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

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

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.

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.

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

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.

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.

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,

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.

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

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.

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.

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

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.