Discussion in 'other firewalls' started by alexandrud, May 20, 2013.
Also Emsisoft, AdGuard, etc., etc., etc.?
Does WFC can filter traffic based on account name?
It will be not a problem if Windows would use one-binary-per-service, but unfortunately it is not.
Does WFC can filter traffic based on account name or group account belongs to? One may block svchost from SYSTEM and Administrator accounts while working on account belonging only to account belonging only to users group. Malware infection most likely would infect this work account, because most things would be done from this account.
WFC does not do any packet filtering and is not aware of any active connection.
Ok. WFC uses Windows Filtering Platform. Does Windows Filtering Platform allow to filter packets based on user account name?
WFC is just an alternative UI for Windows Firewall. Windows Firewall does the filtering based on the existing firewall rules. Windows Firewall is just an implementation over the Windows Filtering Platform. WFP is very capable but you have to call it by using C++. Maybe the author of Simplewall can answer this question since he took this route and he has more knowledge about this. His product talks with WFP directly from C++.
@popescu if I remember correctly, if a program uses a dll as a service to perform updates and other net activities it will connect under the svchost.exe name.
The default allow rules (wf) do not have an svchost.exe rule for a reason... and if you create an svchost.exe rule for a specific service, windows firewall will warn you for the risks in doing so...
@Rainwalker I have uploaded v184.108.40.206 and v220.127.116.11 here in case you still need it.
edit: replaced (wfc) with (wf).
The recommended WFC rules include a svchost.exe, wide open on TCP /80,443
Sorry I meant wf instead of wfc. I never used the wfc recommended rules.
Both downloads seems to be dammaged.
those versions are still available via binisoft official website
Can you post a screenshot? On my end they download and extract correctly.
v18.104.22.168 should have a SHA-256 hash
v22.214.171.124 should have a SHA-256 hash
same hashes as those from the binisoft links @yeL posted.
Thank you folks. I have the downloads.
Same. Both in working order on this end as well. Thanks
And you should know you can tighten that rule considerably. I've actually tried really hard to help you.
I'm not author of Simplewall, but WFP can filter by User ID.
See FWPM_CONDITION_ALE_USER_ID at .
Individual rules for services, running through svchost.exe, worked in Windows 7, but did not work in Windows 8.1 and Windows 10.
tried both Firefox and Edge.
Update the version of the archiver!
yes, this was the problem, thanks!
BITS is often overlooked, but it is a very viable method of circumventing protections - https://attack.mitre.org/techniques/T1197/
Solution: tighten firewall rules for C:\Windows\System32\svchost.exe
Of course it's best not to allow the malware to run in the first place.
Easy to say, impossible to do it.
There is no way to "tighten" firewall rules for svchost.exe as long as you do not know who or what generated the request and who or what is on the other end of communication (IP)
You are wrong! I would suggest you spend some time and effort researching basic networking fundamentals.
I may be wrong, but this is what I found:
This is an "official' answer from Microsoft
For security purposes, the IP address for the Windows Update web site constantly changes and it is not a fixed address. Also, there is no official publication of the IP addresses. We normally advise against defining IP addresses on the firewall for this purpose. Instead, we suggest either allowing all outbound connections to http & https ports or defining the DNS addresses as permitted destinations for traffic via the firewall.
For up-to-date information about the IP's being used by Windows Update, use the DNS system, as this is the only reliable up to date source of information. If you use DNS, make sure the following destination hosts are specified:
Thanks for your understanding.
@popescu I do not understand this "debate".
If you do not want dlls that run as services to connect through the "svchost.exe" name -> do not create a rule for "svchost.exe" (not even for specific services).
If you do not trust a program that wants admin rights to install, you should not install it, in the first place.
A program that runs with admin rights can modify/create/delete outgoing WF rules at will, and the only way to restrict it is by enabling the group policy (not available in windows home).
Separate names with a comma.