can loopback UDP disabled freeze windows services, eg. comodo self?


im not sure with switch i do.

i know many windows services use UDP, grin hope not to keep alive :slight_smile:

but is that possible?

and how unsafe // what known attacks are there?


Hey Mike,

I really don’t clearly understand what all the fuss about the local loopback connection is? It is solely and can only be internal to your PC and is not designed or intended to communicate outside of your PC. There’s a good simple article on Wikipedia that explains it relatively simply.

Hope this helps,
Ewen :slight_smile:

hi ewen,

might we talk aside each., there tools for see how windows communicates itself.

might try tool hdd access or so, im sorry this a laptop and i havent all apps here.

then you see explorer.exe open file blah udp port whatever or so, im sorry i didnt use the tools recently.

you see tcp calls, udp calls, etc and that even if you havent “inet- tcp” installed nor your connected to any net.

(all via 127.x.x.x as if you mention close newer application communicates there)

eg: IE wants connect x.x.x.x using tcp port 80

windows nt5 is totally based on “loopback” which is stupid name, its local host.

and local host autotranslates a ip, if you want or not

might this express my thinking.

but tnx for taking time


PS: if this was all blah, sorry

Hi Mike,

Using sysinternals, you can easily see traffic to and from the 127 subnet, but its only coming from itself - the 127 subnet.

AFAIK, this 127.0.0.X address space is absolutely non-routable outside of local PC. It simply can’t make a connection to the outside world, as internet routers are configured to “swallow” packets with this address, similarly to how they swallow 192.168.X.X, 172.16.X.X and 10.0 X.X addresses. The data simply won’t get past the first router to the publicly accessible internet.

I’m aware that the localhost can and is used for things like internal proxies, AV checkers etc, but the traffic on the 127 network never leaves your PC because it simply can’t.

Ewen :slight_smile:

Generally true, but packets go where the router tables tell them to go to get to their destination. The bit with the RFC1918 addresses (, RFC3927 (, and other unrouteables, is that the addresses do leak out onto the Internet. If they’re source addresses, they’ll be happily routed to their destinations. If there is no route, the bits get dropped on the floor, which makes getting an answer back kind of tough.

That does not, however, stop a spoof attack with something like UDP or ICMP traffic. The *ix/BSD DMZ machines here have gotten spoofed packets that make the attempt to look like its something from the inside LAN, but is trying to come in thru the Internet facing door.

True enough but I thought the 127.0.X.X range was absloutely, no exceptions, non-routable outside the host PC. Can you point me towards any info that indicates otherwise? Not doubting you, just got my curiousity up now.

Ewen :slight_smile:


can we make it step by step, for the first:

does comodo option localhost udp blocking harm windows design working internally,

(like eg sysinternal tools say on are windows tcp udp msgs)

im not even talking about outbound or inbounds,

my very first q is, does this switch block that intern communication of windows nt itself?

and if it does, now is the question does nt internally need UDP ?

if this switch wont block it have no action?


Go to a command prompt and run: netstat -an -p udp -b
It’ll show which applications broadcast using UDP on your loopback address. Substitute “udp” for “tcp” if you want to see those too.

For the address block, every configuration I’ve ever seen has had a route on the loopback interface (something akin to this: "route add -net -iface lo0 ), usually added by “the system” during the startup process (in *ix/BSD, that is the “ifconfig lo0 inet” command in /etc/rc). In the Windows world, that is probably hardcoded in the IP stack. But, being a configuration parameter, means I could set the values to be whatever I wanted them to be. Having things work outside the convention that everybody else is using is another question entirely. But, working outside convention is invariably the way to get around security, and put stuff on the wire that is never supposed to be there.

Although 127.X.X.X blocking is enabled is enabled by default in the MS IP stack, you can still manually fiddle the routes and add or modify. Having done this however, you may be able to get a 127.0.0.X packet to leave your system, but this packet would surely get munted by the first properly configured router that is not under the control of whoever is doing the router diddling, and is correctly configured to disallow non-routable packets, wouldn’t it?

If the packet has a destination address, then the very first device that has a properly defined loopback will indeed have lunch.

If the packet has a source address in, then the normal routing to whatever destination will get the packet where it wants to go. But you’ll never get an answer back, because the reply would be eaten by the destination loopback interface. That makes the packet effectively anonymous. But the packet has already delivered its payload.

Consider a UDP packet, source destination being a router or a network connected UPS. You don’t really have to see what you’re doing, to do a lot of damage. SNMP, NTP, RIPv1, etc that all use UDP, and presume that LAN packets are safe. If the LAN border is porous and lets in forged packets, there is a real serious problem. Some (a few, many,most?) ISP’s will check packets inbound for unroutable source addresses. But judging by the amount of crud hitting the 1026 and 1027/UDP ports on the site firewall here, a lot of sites don’t. (Windows Messager ‘net send’ pop-up spam, presumed all forged source addresses)

I see - point taken about the payload already being delivered. I guess we’re just lucky here, as we make BGP and blocking of inbound non-routable addresses the first thing in the router setup process.

Thanks for stirring the grey cells up. :wink:

Ewen :slight_smile: