Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable
in [Firewalls]
|
Prev: Dynamic Routing
Next: Daemon Alert - Nokia
From: Dubious Dude on 25 Feb 2006 01:52 I have a rule in Kerio Personal firewall to block incoming ICMP [8] (Echo Request) and [30] Traceroute. I am still getting outgoing ICMP [3] Destination Unreachable. Doesn't [3] need an incoming ICMP to provoke it? Thanks.
From: Volker Birk on 25 Feb 2006 05:59 Dubious Dude <Shifty(a)eyes.com> wrote: > I have a rule in Kerio Personal firewall to block incoming ICMP [8] > (Echo Request) and [30] Traceroute. Why? They're harmless. > [3] Destination Unreachable. Doesn't [3] need an incoming ICMP to > provoke it? No. Yours, VB. -- Wenn Du "Ich sehe die Mathematik als einzigen Bereich an, wo es klare Beweise gibt." und "Ich fuehle mich in einem Anzug unwohl." als Aussagen mit aequivalentem Meinungsinhalt betrachtest, hast Du mit Deinem Gleichnis recht. (Michail Bachmann zu Thomas Wallutis in d.a.s.r)
From: Moe Trin on 25 Feb 2006 15:12 On Sat, 25 Feb 2006, in the Usenet newsgroup comp.security.firewalls, in article <dtov45$48d$1(a)emma.aioe.org>, Dubious Dude wrote: >I have a rule in Kerio Personal firewall to block incoming ICMP [8] >(Echo Request) Whatever >and [30] Traceroute. 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. >I am still getting outgoing ICMP [3] Destination Unreachable. Doesn't [3] >need an incoming ICMP to provoke it? 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
From: Ken Sims on 25 Feb 2006 17:22 Hi - On Sat, 25 Feb 2006 01:52:34 -0500, Dubious Dude <Shifty(a)eyes.com> wrote: > I am still getting outgoing ICMP >[3] Destination Unreachable. Doesn't [3] need an incoming ICMP to >provoke it? 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. -- Ken http://www.kensims.net/
From: Moe Trin on 25 Feb 2006 21:38
On Sat, 25 Feb 2006, in the Usenet newsgroup comp.security.firewalls, in article <46c59bFacp6nU1(a)news.dfncis.de>, Sebastian Gottschalk wrote: >Moe Trin wrote: > >> 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. > >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. 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. >Or what about ports <1024 except of DNS, identd and wanted services? I'm >no server, and if anyone accidently believes I'm one they're so badly >wrong that I don't care sending them a notice. As the port scans and >other random bunch is a much bigger source, you can easily filter that >away without any problems. As above. Two packets verses three. >But one should only blacklist bad examples as told above, as in general >responses do have their usage. Just take a look at eBay's load balancing >- when connecting, you're receiving certain TCP connections from certain >servers from all over the world. Respond to them, and they'll figure out >who got the fastest response and will redirect you there. 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 |