Improving Stealth. Secret Backdoor for svchost ? Firewall 3.0.22.349, XP+SP2

Help for v3
#1

Hi

For several weeks I took unusual risks, culminating in Firewall upgrade Firewall from 3.0.14.xxx to 3.0.22.349 (which went better than I feared).
Meanwhile the world did not stand still, and my ISP (TalkTalk) swapped out BT hardware from the local phone exchange, and installed their own. For the previous year I was on a standard fixed 2.2 Mbps service, but with the new hardware I got a new VARIABLE service of “MAX ADSL with Inter-Ratio Profile”, which upon power-up (before “connection” and submission of password etc.) determines how small a share I will get of the country’s bandwidth - so now my download is any one of several discrete values between 1728 and 2016 Kbps, and upload between 128 and 384 Kbps.

I noticed strange messages from 255.255.255.255., which I had never seen before. I did not know if this was due to the new equipment and service from TalkTalk, or if it was due to the Firewall upgrade, but I was too busy with risky experiments and decided to investigate later.

Last weekend I restored the system image captured before I took risks, eliminating any damage I may have caused, and then replaced the restored 3.0.14.xxx with 3.0.22.349. I then started investigating; I added logging to IP Out to see if 255.255.255.255 was banging away of its own accord, or if it was answering something, and saw that svchost was initiating the transactions which surprised me, and really horrified me when I realised this appeared to be sending a 255.255.255.255 broadcast around the world.

I do not know why source 255.255.255.255 has recently appeared, and as a matter of interest would appreciate advice upon why, e.g. :-

  1. New hardware or Software at TalkTalk;
  2. New upgrade of Firewall which detects/logs what previously went unseen;
  3. svchost has detected a change of internet/protection, and is trying to beat the system;
  4. something else.

Question 5)
Why is the first action “Asked” in the image Fire_Events_StartUp.gif ? It never asked me. On every occasion, immediately the modem told the ISP my password and the connection was established, the very first message is IGMP, and the action was always logged as “Asked”, but it never asked me, there was never any pop-up, and the internet responses started within 1 second. This seems to me an error in the log. Also, where is the Asked rule - the ONLY ask I can see in Application rules is the final rule for the email client.

I have now temporarily enhanced my stealth by new Network Global Rules (Global_Rules_Query.gif) pending any suggestions and advice. I am pleased to say that almost nothing is knocking at my door so far after 5 hours with two dynamic IP addresses - but I have had some good days in the past.
I am also pleased to say that with tighter stealth I can still receive emails, and still purchase from Play.com on a secured link, and if you can read this I can still post on my favourite forum !!!

My changes to the Stealth Wizard rules are :-
To exclude 255.255.255.255 from what is allowed by IP Out from Any etc.
To change the final Block and Log from IP IN to IP In/Out so the above IP Out 255.255.255.255 is caught
To preceed everything with a Block and Log of Multicast 224.0.0.22
To add a ICMP PORT UNREACHABLE Rule. As it stands this is redundant.

Question 6)
If ICMP PORT UNREACHABLE is changed to ALLOW, would it improve operation for a solitary P.C. that is not behind a corporate firewall, and would it be a useful enhancement to the Stealth Wizard “FRAGMENTATION NEEDED”. I ask this because I found these quotes on
http://en.wikipedia.org/wiki/PMTU_blackhole#Problems_with_PMTUD which states :-
‘Many “security” devices incorrectly block all ICMP messages’ (including FRAGMENTATION) and
“However, in order for TCP to operate most efficiently, ICMP unreachables (type 3) should be permitted.”

Question 7)
Is it safe to ALLOW ICMP PORT UNREACHABLE ? I ask because somewhere (so many Google links, so little time) I read that a message from 255.255.255.255 could be via an anonymous proxy server, which suggests to me a hacker covering his tracks.

I am very surprised to observe that now I have tighter stealth, svchost has a tantrum. It still sends a solitary UDP from port 138 to port 138 at 720 Second intervals, just like it used to,
BUT the 1932 Second interval sequence has changed,
instead of sending a solitary Port 138 to Port 138 message that caused 3 or 4 “Destination Unreachable” internet responses which the Firewall blocked,
svchost now reacts to the IP OUT block by repeating itself 6 times at 2 Second intervals, and to double its chances every other attempt is instead from Port 137 to Port 137.

This unexpected reaction of 6 attempts instead of 1 tells me that svchost is reacting to the change of protection, which is why I posed (3) above as a possibility.

HOW does svchost know. Now the Firewall blocks its IP OUT, svchost makes 6 desperate attempts at getting a response, but when the inbound response was blocked just once was enough - did svchost have a secret backdoor though which it could see the answer that should have been blocked ?
I hope there is a mundane explanation, but would appreciate expert assurance - hence my provocative title.

Regards
Alan

[attachment deleted by admin]

#2

How in the world do you have time to type all this? Did you reformat yet or still dealing with a corrupted OS? In all honesty Alan your better off with a NAT router. Very cheap to buy and protects better then any software firewall ever could. I use Comodo for the HIPS and program control. If you want the best protection a hardware firewall is the route to go.

#3

What you’re describing is part of the normal DHCP sequence of how your machine gets an IP address assigned to it by your ISP. The sequence goes something like this.

You boot up your machine. It doesn’t have an IP address at this point, and needs to get one by asking your ISP servers for an address. But not having an address, how to send the query? Classic chicken-egg problem.

The solution is to use predefined, special purpose addresses. Specifically 0.0.0.0 and 255.255.255.255. These addresses are not used for anything else, and do not route over the Internet, or anywhere for that matter.

Your machine will send a DHCP request, with the “it’s me” address of 0.0.0.0, requesting a DHCP at 255.255.255.255 for an address. Your ISP has a router (or at least one special purpose box) that will recognize that special address, and will reply. The IP address request has an identifier tag, so answers can be distinguished if there are multiple PC’s all asking for a DHCP address. The ISP router assigns an IP address, puts that into the request with the ID tag, and sends it back. Your machine will be listening, sees a reply come back with those special addresses, sees the matching ID tag in the reply, and takes the IP address in the reply as the IP assignment. Now you have a real live, Internet routable, IP address.

As to why you’re seeing these now, and not before, is because the ISP changed their hardware. CFP typically recognizes the DHCP sequence, and allows it. At least in the more recent CFP versions. Earlier versions had some difficulty with DHCP, so that may be why you’re seeing CFP log of these kinds of packets.

The IGMP stuff, and addresses in the 224.0.0.x address space, are part of router protocols. It’s how your machine talks to the ISP routers. Again, it’s standard stuff. The 224.0.0.0 thru 239.255.255.255 addresses are called multicast addresses. These are special purpose “multicast” addresses that typically do not route over the Internet, without some special effort.

An ICMP port unreachable packet is safe to receive. It means that something send from your machine couldn’t get to where ever it was going. The where-ever sent back an ICMP saying “sorry, not here”. Its like a telephone answering machine that can’t take a message.

The port 137 and 138 stuff is part of Windows LAN networking. Useful if your have several machines on a LAN, but useless to downright dangerous for a single PC talking to the Internet. You want these to never ever be accessible from the Internet. Which sounds like what you’re doing. On blocking outbound, it’s CFP that is telling svchost the “sorry, not available” with a fake ICMP (that’s the effect, if the detail is different).

Does this help to understand what’s happening?

#4

Good explanation grue.

#5

Vettetech

There are only a few “anomalies” on my machine - but if there were zero it would not be Windows !!!

The fact that just one of the many links to the Comodo help file is not working is no problem - I think I know what the answer should be any-way. It would be horrendously inconvenient if I reformatted - the Computer is 4 years old with software pre-installed, and the only CD’s were Recovery discs plus a Hewlett Packard Printer CD. Much software has been downloaded and installed in the three years before I was given this machine, and for my first 6 months I was not aware of Portable Apps and so I added and installed more. If I make a clean start I will get a clean operating system, but if I copy the downloaded programs from an archive image I suspect most will fail to run until I restore relevant information to the registry, and I will either have to accept their loss, or go hunting on the internet to download again. So I will only contemplate a reformat if this “corrupted OS” gets very much worse.

Grue155

I have 45 years experience as a design engineer, with extensive real-time embedded software design for the last 35 years. I have witnessed, and also anticipated and forestalled, many design failures, hence my habit of assuming the worst - especially when I do not know what is happening.

Thank you for the information, which really does help me to understand what is happening, and has removed my fear that svchost had a backdoor to Internet replies.

Just one (for now) follow up question about multi-cast etc. :-
78:148.120.148 was my dynamic IP Address earlier today, and
78:148.112.1 was the Server IP address I connected to
Sometimes the log shows blocked intrusion attempts by many different IP addresses between these two limits, and even a bit above or below. Are these legitimate attempts by my ISP, or are they hackers that can take advantage of my multicast or broadcast because they are connected to the same Server IP address ?
Sorry, paranoia is a life long habit !!!

Regards
Alan

#6

Your ISP, probably like most ISP’s, don’t do any routing of multicast addresses. If they do, they’d likely charge for it, as it takes special router configurations to support what multicast is designed to do. That limits multicast to the same “LAN segment”, just like a broadcast. In the typical ISP setup, the Lan segment comprises their router, your connection, and the only the other immediate connections to that very same ISP router by other customers. You can use “tracert” from a Windows command prompt to get the path from your machine to any destination on the Internet. Your ISP router is going to one of the very first items listed in the tracert output. If the destination is talking to that router, tracert will stop with the next line of output. It’s a good diagnostic tool, but can be sometimes confusing to interpret. If you have a question, you can post the result here.

There is a lot of junk on the Internet these days. We have Windows to thank for that, as most of that junk is aimed at trying to compromise Windows machines. If you’re seeing traffic inbound to your machine on ports 135, 137,138,139, or 445 (the Windows networking ports), then you’re seeing probes aimed to find anything that is connected. They probe >all< addresses, connected or not, and are not aimed at anybody in particular. Traffic like that has come to be considered noise in the firewall logs, as there is so much of it.

Your ISP address space seems to be 78.144.0.0 thru 78.151.255.255. If you’re seeing traffic that is doing probes on the Windows ports that is within that IP address range, then your ISP likely has customers who got careless with their security, and has had their machines taken over.

If you’re not seeing any probes from addresses outside your ISP, then it’s a real good indication that your ISP is one of the good guys on the Internet, and they’re firewalling at their network edge to keep the junk out.

If you have a question about something in your logs, you can post your log here, and we’ll try and make sense of it. If you have a question about your CFP rules, I’d suggest running the Config Reporting Script described in a sticky topic at the top of this forum page, and post the report for ideas on any changes that might be needed.

All in all, it sounds like you’re doing things right.