Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Firewalls
[Top] [All Lists]

Re: Wierd ICMP in logs

Subject: Re: Wierd ICMP in logs
Date: Wed, 22 Sep 2004 18:24:54 +0200
Hello Mark,

Sunday, September 12, 2004, 8:51:20 PM, you wrote:

M> I am running openBSD with PF for my firewall.

M> I found these wierd entries in my log file:
M> Sep 12 10:37:59.896280 rule 1/0(match): block in on xl0:
M> 24.21.214.129 > 68.*.*.*: icmp: host 192.168.1.100 unreachable [tos
M> 0xc0]
M> Sep 12 10:37:59.905766 rule 1/0(match): block in on xl0:
M> 24.21.214.129 > 68.*.*.*: icmp: host 192.168.1.100 unreachable [tos
M> 0xc0]
M> Sep 12 10:38:06.194229 rule 1/0(match): block in on xl0:
M> 24.21.214.129 > 68.*.*.*: icmp: host 192.168.1.100 unreachable [tos
M> 0xc0]

M> My question is why is it saying host 192.168.1.100 unreachable?

It refers to the IP on the internal network of the recipient of the
packet that triggered this. In other words, there is NATing going on
at that 24 box. 

I remember there was an old linux netfilter NAT problem causing this.
The tos 0xc0 indicates the icmp was sent by a linux box.


It went like this: A host on your network (the 68 box, or one it NATs
for) tried to do a tcp connection (most likely) to that box (likely
port 80, but anything would go...) but the 24 box could not get an arp
reply from what it knew as 192.168.1.100, so it spit back an
unreachable. (Which was caught in your logs).

When the box on your network did not get a response, it tried again.
Same thing happened, and you got your second log entry.

Still not having gotten a response, it did what most boxes are
configured to do: Try a third time. Not getting a response there, it
gave up and gave the user an error.

(Had it gotten the first icmp unreach, it would have given up, and not
sent the two other SYNs.)

M> Thats an internal IP on my network, how can this 24.21.214.129 IP
M> be pinging IP's on my internal network? Is there something i can do
M> to block this? I am currently blocking all external icmp traffic.

Many of the ICMP messages will be beneficial as incoming, esp the
unreachables.

M> PS: I have * out my ip address.

M> Thanks


-- 
Best regards,
 Marius                            mailto:mahuja@c2i.net

Attachment: pgpeHkM94wtoK.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>