Well, you learn something new every day. Firewall alert setting ‘very high’ does indeed create a connection specific allow rule (for the specific dest port too) when ‘remember this’ is ticked.
As far as SVCHost being implemented for certain app updates, that’s what experience has shown to be the case. Specifically Ad-Aware, Adobe ARM and JRE updates. Each app has its own components and each component requests IP address connections from time to time. After granting internet access for the app (and establishing the appropriate permanent rule), SVCHost chimes in and says: “ME TOO!” This is easy enough to configure; just allow SVCHost access to the same zone as for the previously created app update rule. What I’ve found is that SVCHost requests access to some of the updater app’s zones (but not all of them). For example, JRE updater apps comprises:
each app has IP addresses unique to themselves - but over time - its becomes apparent they share common connection zones. For that puporse I create a filegroup and allow the file group access to the zones in common (and remove the duplicate rule from each app seperately). Now for all the zones defined, i.e., common, jusched, jucheck, jaucheck, javaw & deploy, SVCHost shares ONE ZONE w/ONE app, i.e., jaucheck (and that specifically to a particular domain: qwest.net)
As far as UDP protocol goes, I’ve seen no need to allow UDP except on port 53 (for DNS); my rules are exclusively TCP outbound to port 80 (or 443 as the case may be). To handle DNS I created a filegruop of EVERY app that needs DNS access to port 53; no alert rule necessary since every other app has one and will intercept any unspecficed in/out IP protocol connection attempts.
As far as WAU, I don’t have (a) specific rule(s), albeit wuaclt.exe and wupdmgr.exe ARE in the DNS filegroup. Those two apps probably are handled by SVChost, i.e., this is normal status for SVCHost:
Image Name PID Services
svchost.exe 620 DcomLaunch
svchost.exe 680 RpcSs
svchost.exe 756 AudioSrv, CryptSvc, EventSystem,
lanmanworkstation, Netman, Nla, RasMan,
Schedule, SENS, ShellHWDetection, Themes,
svchost.exe 892 Dhcp, Dnscache
svchost.exe 1160 Wecsvc
svchost.exe 1704 TermService
svchost.exe 308 TapiSrv
But I sure as heck aint giving SVCHost carte blanche to phone home whereever it wants. IF I can resolve the SVCHost connection destination IP address domain name to something reasonable, e.g., MS edge-cache network (MSECN), or Sun.com, etc. I’ll allow it w/out question. If the domain name is returned as unknown, then I ensure that SVCHost isn’t hijacked, i.e., no extra occurances of SVCHost processes are executing, and that ALL services associated w/each instance of SVChost are reasonable (and no instance of SVChost w/out an associated service is running). IF that is the case, then I cadd the IP address to the [SVCHost - ? ? ?] zone.
Otherwise if the domain name can be resolved I add the IP addres to the zone with that domain name OR create a new zone with the new domain name (and make a TCP allow out-rule to the new zone). The latter being on port 80 explicitely (unless the request is explicitely to port 443; or both 80 & 443 as the case may be). I’ve found that some port 443 zones become port 80 / 443 zones, and some IP in previously port 80 exclusive become 80 /443 shared, but some port 80 and 443 IP adderss zone remain exlusive to either port 80 or 443 as defined.
Furthermore, I’ve never seen SVCHost access the [CRL] zone, i.e., CA issuing domains, e.g. Verisign; that appears to be the explicit purvue of the individual updater apps (which interestingly enough is NEVER accessed on port 443). But those apps aacesing [CRL] ALL have domeains / zones that access port 443.