Background Intelligent Transfer Service support?

If some software use BITS download/upload files (svchost.exe TCP Out), You only allow/block the svchost.exe, but don’t know who create this connections.
Bypass the Application Rules, blackdoor?

ex: You create application rule block some connections for Chrome.exe, but Chrome.exe can use BITS download files (Chrome Component Updater).

You don’t want to be arbitrarily blocking behavior of applications. A very critical system application is SVCHOST. The default installation has the file included in the Windows System Application file-group. That file-group has Windows System Application predefined policy access rights.

In general CIS alerts you to unrecognized application behavior. If there’s no reason to suspect that one’s system is compromised, then allowing application behavior is acceptable provided the application is known to be trusted by the user.. If the user has insufficient knowledge concerning normal functionality of their system, then CIS can operate semi-autonomously based on various assumptions. However, this is usually a trade-off with respect to functionality; inevitably CIS will prohibit operation of applications due to false positive, i.e., it is more conservative than necessary. In general CIS functions adequately. The Windows System Application predefined policy is affectively that of super-user God access rights to the system and the internet. For the most part that works well unless one just has to know and can’t stand their machine doing stuff without their knowledge.

However, if the user takes full control of their system by implementing paranoid mode, and by removing system components from Windows System Application file-group and takes the reins over control, then the user must be familiar with intricate nuance of their system functionality.

First off, SVCHOST is a very enigmatic and mysterious process; it is a service Service that hosts services essential to O/S functionality. Whatever it does, wherever it phones to is no reason for concern provided that there’s no reason to suspect that it, or the system in general, has been compromised. With regards to SVCHOST, there’s a simple means to detect whether it has been compromised:

Tasklist /FI "IMAGENAME eq svchost.exe" /svc pause

Open notepad, paste the above into it, and save it with CMD extension in some location where you store custom utilities. Then create a PIF on the desktop to launches the CMD file. I call mine SVCHost Process tool and it points to Process_tool.cmd. Any time there’s an alert for SVCHOST this, or SVCHOST that, or whatnot, launch the SVCHost Process Tool icon on the desktop and examine what it displays.

You will see an instance of SVCHOST running multiple times and each will be hosting multiple services. Its not important how many SVCHost process are running, or understanding what each services that the various SVCHOST process are hosting, but to instantly recognize something amiss in the services list.

A big red warning flag flapping in the gale force wind is an SVCHOST process with out a PID. That’s bad, and it intimates the system is seriously compromised, in that the particular image executing can’t be terminated. Again, BAD.

Another BAD thing is an SVCHost executing w/ out a service listed, or the service is gibberish. Very BAD. Less bad than the first Bad, but BAD nonetheless.

Lastly, any SVCHost image executing that has a new service listed. That service must be investigated to ensure that service is to be trusted. If none of the foregoing are evident, then SVCHOST is golden - good to go - and let 'er rip, Snip. There’s no need to fully comprehend precisely what its doing.

That comes with time; the user can investigate each and every single service hosted by SVCHOST and be utterly confident that they know, Oh, that’s that, and this does that, and what not. But its NOT necessary to know; its just a bunch of cool-guy smart ■■■ gibberish.

What’s important is to look at that list and instantly detect something new, something different and / or something unusual. That last part is what should leap out of the screen at the user: unusual. THAT needs to get investigated.

Other than that, allow, remember and SVCHost goes away and leaves the user in peace.

As far as any browser, the purpose of browsers is to browse. So that’s all a browser should do: browse. it needs certain minimal permissions to do its job: it needs TCP out from the NIC to IP address ANY source port ANY to destination port on port 80 and 443. Pretty much that’s it.

Certain web-pages may host content on different ports. That’s handled on case by case basis, e.g., some Flash content may stream on port 6667. The page [at] www.somepage.com will load from the web-server port 80, but embedded link for some freaky-cool uToob video will be www.somepage.com\freaky-cool-video and it gets served on port 6667; you get an alert: Browser wants to access bla-bla-bla IP address on port 6667! WOAH! Freak out?

No. Just allow, but don’t remember that. You don’t need a rule for each internet IP address for every stinkin’ 65,000 ports available; you may NEVER even go back to that web-site. But each and every web-site will use 80 and sometimes 443 (https). So you want to see freaky-cool video? Then you have to allow browser access to that IP address on port 6667 for that one incident. Then go on your merry way.

However, if you find that web-site ALWAYS has different freaky-cool videos there, and you go back there a lot to see them, then you may consider to make a rule for THAT ip address to hook into port 6667.

My browser rules are:

TCP out from local_0 to local_127 source port Any to destination port Any
TCP out from in [NIC] to Any source port Any destination port in [HTTP PORTS]
TCP out from in [NIC] to Any source port Any destination port in [Adobe RTMP]
TCP out from in [NIC] to in [Webcs.yahoo] source port any destination port in [5050 / 843]
TCP out from in [NIC] to in [Amazonaws] source port any destination port 6667
Block IP out from in [NIC] to in [W.X.Y.Z / 255.255.0.0] source port any destination port any
Block IP out from in [NIC] to in [A.B.C.D/ 255.255.255.0] source port any destination port any

That’s it. My system runs, CIS is fat dumb and happy and for the most part so am I. Downloads in the browser get alerts for odd port access, and for saving files first into the temp internet folder and then ultimate where it gets saved. Big deal. BITS for Windows updates gets handled by SVCHost and as I splained, I don’t care what it does or where it goes as long as its not compromised.

I have about 150 IP domains for SVCHOst that it can phone home to without bothering me - and it does for the most part. If I’m really concerned, I can look up the IP domain owner using WHOIS and get a handle on who they are. Invariably they’re companies like Verizon, AT&T, Nextel, Level3, MS block 1, MS Global, MS this, MS that, Akamai, etc. It doesn’t matter what the heck SVCHost is updating with BIT, e.g., Adobe Flash, Java, Windows, etc. Its getting it off of the internet backbone that has been constructed by the top 10 global communication corporations. You’ve got to trust something.

But if I see it phoning to We-hack-you-dead.com, uh, well, that don’t sound so good. Never happen in 10 years of using CIS. Again: as long as SVCHost is sound, I trust what it does implicitly. I just build its rules as it asks for IPs because the more IP’s it can go to, the less it bothers you.

Like here’s an example: it asks one day to go to 134.170.51.189. I make the TCP allow out to that on port 80. three months later it asks to phone to 134.170.51.254. I sort my IP from highest to lowest so now I see the first one. I change the first rule to range 134.170.51.189 - 134.170.51.254. Now he’s got a whole bunch of IPs to hit with that one rule and won’t bother me about it. Maybe a year later he wants to go to 134.170.51.18. Well, gee, I’ll just change that to a netmask and give him the entire domain, i.e., 134.170.51.0 / 255.255.255.0 End of story cause now he’s got 255 IP with that one rule.

Capische?