Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable

Oh, shit spotted.

Isn't that just a stupid idea?

ZOMG !!!11

No. What part of RFC 792 didn't you understand?

Why? They're harmless.

No.

Yours, VB.

Whatever

Wrong. ICMP Type 30 was an experimental protocol - see RFC1393. If you are trying to block windoze imitation version of traceroute, your block of ICMP type 8 already does so. The real LBL traceroute uses UDP, defaulting to ports 33434 and above. There is also a TCP version of traceroute which defaults to probing port 80.

See RFC0792 - specifically the last paragraph on page 1. Then grab a copy of RFC1122 and 1180, and learn how networking operates. BRIEFLY, when a remote host tries to connect to a port that has no server running, the network stack (part of the operating system kernel) will either return a ACK/RST TCP packet (see my reply in the thread "Please help me interpret a suspicious netstat SYN_SENT TCP port 1058 ?") which says "I heard you, but go away", or it returns an ICMP Type 3 Code 3 error which says "Nobody here at that port". Either one ends the conversation.

If you think that not responding to any Internet traffic is the way to go (Gibson's so-called "stealth mode"), you really need to look at the concept of traceroute again, to see why such action is a waste of your bandwidth.

Old guy

Are the IP addresses the addresses of the DNS servers that your PC is configured to use?

If a DNS server is responding slowly, your PC can give up waiting for the response. When the response finally arrives, it is rejected with the ICMP [3] because the PC is no longer expecting it.

This is certainly not the only cause of an ICMP [3], but it is the most common cause if you are adequately blocking unsolicited inbound packets.

ICMP, TCP and UDP can all elicit ICMP type 3 responses.

IBTD. Blocking responses in some cases actually saves bandwith.

Think about all those Blaster-, Sasser- and SQHell-infected Windows machines. They're sending you SYN requests on Port 135, 445 and 1434 - they simply keep on sending 4 requests simulataniously and then take the next target, not caring at all about a RST/ACK oder Port Unreachable. And that doesn't just apply to malware, but also to certain P2P clients.

Or what about ports

Actually, I suppose any IP protocol could elicit an ICMP type 3.

There's usually no internet activity when I get ougtoing ICMP [3] Destination Unreachable. That means I'm not using downloading/sending email or surfing. Windows has an icon on the system tray that lites up during internet activity. It is dark when these warnings pop up.

So what? It's about incoming connections, that can be issued by anyone without even knowing who you are or what you've been doing. Port scans, networks worms, misrouted packets, load balancers, stupid P2P clients, left-overs from your dynamic IP, misunderstanding about you being any kind of server, ...

It's not like that Kerio PFW would be useful for any kind of network diagnostics.

As a matter of fact, yes. I checked just right now.

Thank you for your explanation. It looks like the dialup icon on the system tray doesn't light up when the delayed response from the DNS is received. I thought the response was being initiated initiated from my PC without provocation.

Depends. If the malware is running it's own stack, that may send a single SYN per connection attempt, but the normal stack makes three tries, so a ACK/RST or ICMP type 3 is better as it sends a total of two packets. At home, I don't bother responding to UDP inbound - it's just the usual windoze messenger spam, and is frequently using spoofed source addresses, so an ICMP Type 3 would probably be sent to an innocent host. At work, the messenger spam was such that we finally said the hell with it, and port shift any outgoing UDP out of the 1025-1050ish range so their won't be any legitimate inbound traffic for those ports, and let our upstream silently drop such inbound. At a half Meg per day per IP address, that adds up when your pipe is handling something larger than a /16.

But that wasn't what I was referring to. My reference to Gibson's ludicrous "stealth mode" concept and the hint about traceroute should be the clue.

As above. Two packets verses three.

I rarely see a need to use eBay, and so gave it a quick try while sniffing the wire. Result? All traffic to/from was to a single host (66.135.192.124 which seems to be in San Jose). A second try a few minutes later got a different IP (66.135.208.90), but also appears to be San Jose. No indication of load balancing. Actually, Akamai started that a long time ago, using pings to map the world. Pretty much a dead deal now, as many people are blocking/ignoring pings, but in general, the load balancing is done at the DNS stage now - you resolve the IP based on what your IP is.

Old guy

How 'bout clearing up this distinction between real and imitation traceroute. I just don't understand the contention surrounding Microsoft's traceroute. Do they both not accomplish the same thing? I would argue that ICMP echo is the proper protocol for a traceroute because a firewalled target host is most likely to reply to an echo request. I would place hping above all other traceroute utilities. Hping can perform traceroutes with many protocols and ports.

You're going to get just one small packet from the DNS server. The program that lights the icon probably doesn't bother for something that small.

Personally I have KPF configured to block outbound ICMP [3] without logging.

The original is from Van Jacobson, 4.3BSD.

It sends UDP packets with a very small TTL and waits until the ICMP TIME_EXCEEDED answer arrives from each gateway along the route to a host.

I'd like to see that you're right. But ICMP echo filtering is a widespread disease in the days of "Personal Firewalls" and "stealthing".

With hping, you can do completely other things than a traceroute, too. It's a packet generator, not a traceroute utility.

Yours, VB.

Why?

Yours, VB.

Dur, that's how they all work regardless of the protocol used. However, I think it's important that the target host respond to the protocol used, else you end up with something like the following.

$ traceroute6 chia.arin.net traceroute6 to chia.arin.net (2001:440:2000:1::21) from

2001:5c0:8ec3:0:211:11ff:fe33:e364, 64 hops max, 12 byte packets 1 2001:5c0:8ec3::1 0.457 ms 0.407 ms 0.276 ms 2 2001:5c0:8fff:fffe::47b8 102.617 ms 95.600 ms 100.919 ms 3 2001:5c0:0:5::114 98.775 ms 91.677 ms 100.761 ms 4 if-5-0-1.6bb1.mtt-montreal.ipv6.teleglobe.net 299.767 ms * 92.365 ms 5 gin-nto-bb1.ipv6.teleglobe.net 108.094 ms 108.747 ms 111.834 ms 6 2001:458:26:2::80 107.852 ms 107.602 ms 102.479 ms 7 2001:458:26:2::280 100.458 ms 108.500 ms 102.924 ms 8 v6-paIX01.kddnet.ad.jp 190.904 ms v6-laix01.kddnet.ad.jp 176.987 ms 174.142 ms 9 v6-otecore01.kddnet.ad.jp 425.197 ms 308.387 ms 314.791 ms 10 hitachi1.otemachi.wide.ad.jp 296.599 ms 299.514 ms 301.235 ms 11 pc6.otemachi.wide.ad.jp 303.013 ms 310.295 ms 309.180 ms 12 2001:200:0:1800:230:48ff:fe74:2a45 319.727 ms * 301.925 ms 13 2001:fa8:ffff:1:204:6dff:fe8c:9080 321.189 ms 448.551 ms 307.665 ms 14 2001:468:ff:16c1::5 411.853 ms * 401.939 ms 15 3ffe:1810:0:2::1 404.213 ms 406.186 ms 405.514 ms 16 sl-bb1v6-sj-t-13.sprintv6.net 334.737 ms 328.794 ms 324.678 ms 17 sl-bb1v6-rly-t-1002.sprintv6.net 335.771 ms 327.331 ms 330.071 ms 18 2001:440:1239:7000::2 338.957 ms 340.456 ms 339.440 ms 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * ^C

...Instead of a properly terminated trace such as the following.

$ traceroute6 -I chia.arin.net traceroute6 to chia.arin.net (2001:440:2000:1::21) from

2001:5c0:8ec3:0:211:11ff:fe33:e364, 64 hops max, 16 byte packets 1 2001:5c0:8ec3::1 0.442 ms 0.478 ms 0.275 ms 2 2001:5c0:8fff:fffe::47b8 92.846 ms 102.113 ms * 3 2001:5c0:0:5::114 97.087 ms 96.163 ms 100.448 ms 4 if-5-0-1.6bb1.mtt-montreal.ipv6.teleglobe.net 99.260 ms 99.862 ms 99.252 ms 5 gin-nto-bb1.ipv6.teleglobe.net 108.600 ms 107.541 ms 100.478 ms 6 2001:458:26:2::80 100.484 ms 107.144 ms 100.234 ms 7 2001:458:26:2::280 99.727 ms 103.130 ms 110.612 ms 8 * v6-laix01.kddnet.ad.jp 177.931 ms 178.747 ms 9 v6-otecore01.kddnet.ad.jp 297.058 ms 311.786 ms 304.711 ms 10 hitachi1.otemachi.wide.ad.jp 306.942 ms 308.863 ms 305.462 ms 11 pc6.otemachi.wide.ad.jp 304.704 ms 343.326 ms 305.250 ms 12 2001:200:0:1800:230:48ff:fe74:2a45 306.936 ms 311.780 ms 299.318 ms 13 2001:fa8:ffff:1:204:6dff:fe8c:9080 318.009 ms 309.576 ms 308.896 ms 14 2001:468:ff:16c1::5 404.754 ms 407.919 ms 401.516 ms 15 3ffe:1810:0:2::1 414.368 ms 403.424 ms 404.818 ms 16 sl-bb1v6-sj-t-13.sprintv6.net 329.278 ms 327.598 ms 326.887 ms 17 sl-bb1v6-rly-t-1002.sprintv6.net 328.773 ms 332.057 ms 337.292 ms 18 2001:440:1239:7000::2 332.050 ms 336.726 ms 330.032 ms 19 2001:440:2000:10::13 340.905 ms 339.877 ms 341.678 ms 20 2001:440:2000:1::21 338.959 ms 342.310 ms 333.781 ms

Which would you consider more likely: A firewall that blocks echo requests without stealthing udp 34000-35000 (or whatever the hell ports it is) or a firewall that stealths udp and allows echo requests.

Mind that I'm not accusing anyone of getting overzealous in this thread, but I've seen some fierce debate in the past on this subject and I fail to perceive the superiority of udp trace over icmp. The fact that the original used udp is completely irrelevant as far as I'm concerned

Unclear.

Yours, VB.

Which of the following behaviors would a firewalled host most likely exhibit:

a) allow echo / deny udp b) deny echo / allow udp

Thanks, Ken.

DNS servers are dynamic.

Also, I'm an end user. My firewall doesn't shield some kind of LAN. There is really nothing to see behind the firewall.