Firewalls that don't fully protect?

I had a hunch, and it's starting to look to me like that hunch was correct.

Basically I took a look at a Windows 7 VM (bridged Ethernet, "public" firewall profile) using nmap. No ports showed as open; zero, zip, nada. nmap couldn't even tell it was Windows.

Next a bunch of well known freeware firewalls. For now I'm withholding which ones; I'm hoping to get some feedback from the mods/admins on what would be reasonable to divulge. I think users should know this stuff, but OTOH I also think there are people who shouldn't (read: script kiddies).

Anyway....

Brand A: Cranked network protection up to the maximum preconfigured setting.
=> 5 open ports exposed
=> Queried me on a bunch of connection attempts, but AFAICT failed to stop any

Brand B: Firewall level raised to highest default that actually allowed browsing.
=> 3 open ports exposed
=> no prompts during nmap scan
=> nmap scans caused the trial license to expire immediately (?!)

Brand C: set "application security to maximum" whatever that means.
=> No ports exposed whatsoever, same results as with Windows FW; everything is blocked silently

Will take a look at others tomorrow. For now my tentative conclusion is that users of firewall/HIPS software should be careful about the configuration - default settings (even "maximum" ones) may be inferior to the Windows built in firewall, allowing network attacks in some situations. Stay tuned...

 

Really open? Or listening at your PC? Or closed? You should be more specific to avoid doing a scoop ending up in yet another amatorial / questionable test

 

There has been some mention here in Wilders some time ago about most (if not all) firewalls not starting at the beginning of Windows start up and thus allowing early outgoing (and perhaps incoming) traffic. Some doubt remains about the performance in this issue about Windows Firewall though. Several other well-known software firewalls failed.

 

The strange thing is that a professional test has been made and even in that one Windows Firewall looks good and PROFESSIONAL compared to PAID products.
There is a thread regarding that right here on this page ,you should look into it fax.
And even that test has been attacked by vendors or unofficial vendor staff as being unprofessional.
Unfortunately crapware exists in the firewall world and they also want our money for something that doesn t do what they say or claim.

 

Not arguing about other tests or how good windows is ... but just the above test ... as you know open ports or listening the localhost is different than open ports towards the Internet. I have seen also users in panic towards open ports to the internet to then discover they were actually closed ports. Also users in panic mode due to testing with external services (e.g. grc) that are unfortunately not always giving reliable results, and so on and on... testing firewall is a bit tricky...

 

@fax: this was a test of internet-facing open ports. I used VM with a bridged connection, and pointed nmap at it from the Linux host.

Bridged networking operates on OSI layer 2, and knows nothing about packets. No NAT stuff is involved; on the network the VM should appear as a separate machine.

@Q Section: I've seen that mentioned, and it seems pretty weird. Making a firewall start before interfaces come up should be trivial, shouldn't it? :/

 

Then I would take care to confirm your results by using an non-VM machine as many security tools do not support VM type of setup.
You have to mimic as much as possible real enviroment conditions.

 

Re ports: yes, I mean fully open, accepting inbound connections. Some of the port numbers were high, possibly random. The VM was installed from a legitimate Windows 7 install DVD that same night.

I'm pretty sure virtualized guest status should never have an effect on the networking stack or firewall drivers, but honestly I don't know enough about Windows internals to say. If the firewall drivers are using a privilege level other than 3 or 0 I suppose weird things might happen.

I think we can rule out the possibility of deliberate misbehavior when VM status is detected, though.

For now I'm going to stick with what I said at the beginning of the thread: if you use Windows with a third-party firewall, don't panic... but do review the firewall's settings and make sure it's actually blocking all the inbound traffic you expect.

 

I know by experience that certain third party firewall drivers acts very weird in virtual environments, thats why I have pointed it out. This may bias your results, not the results of windows itself...

 

Interesting, thanks. In that case I will set up an old laptop for pentesting experimentation. It would be very interesting indeed, if products I'd earlier found ineffectual suddenly started working when run on physical hardware.

 

At least, whatever is the result, it will be bulletproof...

 

Arrival of GUI or the taks-bar icon, if that's what you mean by "interfaces" is not an indicator of when the firewall driver(s) started (or not) working according to the rules, built-in, or user-made. Drivers normally start well before.

 

@act8192: no, that is not what I mean at all.

I don't know exactly how network interfaces work on Windows, but on UNIX they must be enabled, IIRC with a system call, even after the drivers have loaded. When e.g. Ubuntu boots, at least as I understand it:

Runlevel 1, single user
1. The networking and firewall drivers are loaded, but network interfaces remain inactive. The kernel will not allow connections at this point.
2. The initscripts bring up the loopback (lo) interface using ifconfig. This is strictly local and does not use any ethernet hardware.
3. If the UFW firewall configurator is enabled, it loads its configuration into the iptables firewall. This happens before any external network interfaces become active. Note that if iptables is compiled into the kernel, by default it is always running, but allows all traffic until rules are applied.
Runlevel 2, multiuser
4. Now that the firewall is configured, ethernet cards and whatnot are brought up using ifconfig. By the time they start accepting connections, the firewall will only allow stuff on its whitelist.

 

Got it. Network interfaces, thanks.
Loadorder.exe which works on XP and Win7:
http://technet.microsoft.com/en-us/sysinternals/bb897416.aspx
will show sequences of when things are loaded in relation to firewall driver.
Only someone familiar with what exactly the MS drivers do can tie the logic. Not me.

 

Further information about firewalls not loading soon enough at the start of Windows are written in the following thread which is VERY useful:
https://www.wilderssecurity.com/thre...not-loading-their-drivers-fast-enough.356387/

 

Thanks for being the one to figure this out.
Looking forward to new information.

 

Those guys may release a new test next year ,until then you are on your own in deciding what to use.Some "amateurs"( i call them users) may still post some findings but that s it

If users post here what they think is wrong then maybe vendors will be stimulated to enhance their software and not allow everything in ,just to satisfy "noob" users and give them the sense that the software is smart (when in fact allows everything) to avoid rage.
Now days i find HIPS quite stupid ,tons of questions at which the software responds by itself or to which the user says Yes just to get rid of the annoyance.

 

Strange...even the most basic 3rd party firewalls should block port scans.

 

It's normal for some ports to be open on a Windows system to other computers on the same network if file sharing etc. is enabled (non-"public" profile for the built-in firewall). However, you used "public" profile for the built-in firewall, which closes those ports and shuts down file sharing.

You should test whether those same ports are open to the Internet, using https://www.grc.com/x/ne.dll?bh0bkyd2 or similar.

 

AV-Comparatives Firewall Test 03/2014

 

https://www.wilderssecurity.com/threads/windows-7-open-ports.302044/page-2#post-1960523

 

@MrBrian: Like I said, I was using a VM on a bridged connection, which does not involve any NAT or packet routing. I suppose the FW might be blocking all IPs outside of of the LAN, but that wouldn't do a whole lot of good if you're on e.g. a public wifi network.

Re profiles, I made sure to set each firewall to the most restricted default setting that still allowed outbound connections. A restrictive default profile should IMO be expected to block all unsolicited inbound traffic. If it doesn't, it's not doing its job.

Re file sharing - coming from the Linux world, my POV is that it should be blocked by default if there is no good reason for using it. In fact I'd go further and say that Windows should have the services off by default, and allow them to be enabled as needed through a graphical wizard or such.

We can all argue until we're blue in the face about the utility of inbound firewalls of course. I would say that they're useful, as long as Windows still has listening ports that cannot easily be closed. But my point is, the most restrictive functional default on some 3rd party firewalls still seems to allow inbound connections on some listening ports.

The only way I can see this not being the case, is if Virtualbox somehow interferes with the low-level techniques used by firewall programs. I'll concede that this is a possibility, because I know almost nothing about how hardware emulation and VT-x work, or how it could interfere with firewall software. But I'm going to cover that. Watch this space...

Edit: I will start a new thread for the test on real hardware.

 

@Gullible Jones: I see your point of emphasis now.

 

Some of the papers in this thread do similar tests, if I recall correctly.

 

Thank you @MrBrian! I've just started reading "Testing and Analysis of Personal Firewalls", I'll see if that mentions anything I did not think of...

Edit: the tests from the paper:
hxxp://publications.lib.chalmers.se/records/fulltext/127990.pdf

are much more thorough than what I was planning. Nessus I don't have access to, Wireshark I'm not expert enough to use, Engage I've never heard of.

I will throw in Metasploit as well as nmap if I can find relevant open ports though...