Firewalls of today not loading their drivers fast enough ?!

Outpost Firewall 8.1.2 in Block All policy leaks DNS requests in between Windows boot and it s icon showing up in the task bar.
Private Firewall in Locked mode does the same ,until the GUI shows at start up lets stuff go tru

Windows Control 4 though when set on High filtering seems to block any DNS request.

This DNS requests are benign being made legitimate having in mind the contents ,but what if we get infected ?!

Windows 7x64 OS.

So ?!

 

Windows Firewall Control is a front end for Windows Firewall with a few more great additions. Windows Firewall is loading at boot time. The other firewalls use their own driver to filter the traffic and they are loaded with a little delay than Windows Firewall. Windows Firewall uses Base Filtering Engine and this one is right in the core of the operating system which loads first.

 

Of course.

 

that is not true. your observations are flawed.

outpost loads it's drivers (sandbox64.sys & afw.sys) at the lowest OS level before the network is active (see loadord utility from sys internals), and the actual firewall service (acs.exe) is the started. it is then in a block everything mode, until it reads your config and the rules. this occurs even before a user logs in. what you see is the dns requests being allowed after these rules allow that action. the gui (graphic user interface) is just that, an interface for the firewall and the user, and has nothing to do with when the firewall actually starts working. it can pop it's icon onto the notification area at any time, or not at all.

in fact, i run outpost to start in background mode which does not run the gui at all. i then use start-up delayer to run the gui app (op_mon.exe) after all the other startup items, as it's not needed until the start-up is finished anyway. you are protected even when it is not running.

note that while the windows firewall service is running (at very close to the same time as agnitum's service) the actual windows firewall is turned off by outpost in the security centre. the firewall service has other uses besides the firewall.

 

In my posts i point the interface loading only for the readers to understand when the DNS calls are made.I don t care about the GUI load here.

There is no flaw in what i am doing here in my opinion.

I have installed the firewall on a Windows 7 x64.
This system receives network aces thru a box that has OpenSUSE running on it which behaves as a router regarding this matter.

Using Wireshark i just sniff all the interfaces to see if anything wrong happens , i do this regularly.

So my test method which is by no means a very scientific one is simple.

Start wireshark ,switch the firewall to BLOCK ALL ,restart the PC with the outpost in this mode then look at the traffic the machine is generating until the desktop is up and running.
What i see are DNS calls being made at start up even though the name of the policy and the default behavior of the software should be to NOT allow ANY kind of traffic.
Calls are made to the Microsoft networks so the traffic is benign.This is the only PC connected at the test time.

In my opinion this means that some executable have enough time at start up to send this requests.At the time the interface loads and you see it loaded the Block ALL does the job.

Wireshark also shows ARP stuff being made ,but this is nothing to worry about.

So if the drivers are loaded and they by default BLOCK all traffic until the ruleset /policy is loaded and the DNS leaks are being made in spite of that , what does it mean ?!
I think something is wrong here.
Maybe my AMD FX 6300 based machine is to fast to stay blocked at boot ?!

 

Went ahead and installed ZoneAlarm latest in the Pro version as the dam..d free version downloader was sitting doing nothing or very slow.

So after installing this one i have enabled the Block traffic policy and restarted PC.
Opposed to Private Firewall and Outpost 8.1.2 the policy seems to work different, no DNS request are being made at PC boot up neither other UDP TCP packets ,but there is some PING stuff happening between the PC and the gateway along the ARP ,much more normal behavior.

So this one loads faster or properly it seems.

 

Can you clarify further how you are testing?Im not sure i understand exactly how you are using wireshark.Is it on a host machine or on the machine with outpost installed?.Outpost block all policy by default allows local traffic.Maybe thats what you are seeing?

 

Interesting thread. To followup ellison64's questions, I'd like to see small excerpts of logs or screenies of
1. Wireshark packets on the box where it runs clearly telling what IP belongs where and clearly showing the time of the packets
2. Outpost firewall log for the time involved, as acs.exe kicks in to look for its updates, news, and protection - will not be possible before acs starts, but any log around that time might be useful, most important when it started logging
3. Outpost packet log for the same stuff
and whatever indicates the location of DNS server and remote connections occuring before Outpost service starts

 

Wireshark is running on the Gateway ,made with OpenSUSE ,machine that runs all kind of things when needed.This one serves network to LAN machines.
I would through out of the window my Netgear wireless if i wouldnt have the need of wireless

I have forgot to add something ,maybe relevant ,the DNS Client service is off on the Windows machine.

I always tend to look for the effects of an action ,the outcome is what matters.
They say the Outpost driver loads the first and by default it denies all traffic until the Policy (Block All in this case) and ruleset is loaded
Those DNS calls say otherwise.

I have installed Jetico 2 and see what it does ,set the Block All policy and set it as default ,rebooted ,looked in the Wireshark log.This one does TCP connectivity while the machine is booting not only DNS calls.Of course they were Windows domain stuff again .But what if some malware impersonate this window of opportunity?!

If you are interested of what this firewalls block ,start running your own sniffers and see what they do.Some settings don t do what they should do ,i mean blocking.
Advertisement is nice and catchy ,but ... some firewalls seem to fail when you use some advertised features.

 

I have already run wireshark ,with outpost in block all mode and only see local traffic (my printer) in logs....In fact network and sharing center shows no internet access at all (disconnected) in block all.Ive also run loadord and can confirm that the outpost driver loads before the network driver.Because outpost and wireshark is on the same machine i can only test after windows has loaded,and wireshark is started,so i cant test before boot up.Can you post screenshots or logs of whats leaking before boot up?

 

I can post screens ,but i need to reinstall OFP.
Are you running XP or Windows 7 ?!


LE:
Here you go some screens made under OpenSUSE ,saved by GIMP to it s file type.You can open them with Okular or Gimp or whatever supports .xfc files.
Uploaded here as the forum doesn t take them.

http://www.sendspace.com/file/eh3bwn
http://www.sendspace.com/file/jrhijq

Download on your own risk of course ,i uploaded them clean.

2 screens taken on the Wireshark log ,my IP-s are blanked here and there , but you can see the external and internal and who initiates as well as the servers it connects or calls.
Block All set as policy for Outpost.
It s more than DNS requests it s TCP connectivity.
Block All doesnt work practically.
Microsoft Essentials installed.

MAKE sure you download the picture and not something else people ,look careful on the download page and what you click ,click download from sendspace , a lot of nice download buttons in there

 

The two addresses i see seem to be Link Local Multicast Name Resolution which is local traffic and would be expected in in block all mode and windows NCSI service.
http://blog.superuser.com/2011/05/16/windows-7-network-awareness/

Im not an expert on firewalls or traffic ,but in my limited knowledge i dont see anything in those logs to be worried about.Of course you could argue that block all should block local traffic as well but outpost docs clearly state that local traffic is allowed in block all mode

 

The question is little bit tricky.

Generally all Windows drivers have a specific loading position.
The position is determined by driver group and it's position.

Loading order of the groups is stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder in List.

The group and position is stored in driver's registry service. For example HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip. Group is in Group and position in Tag. The Tag itself is not the number of position, but a link into list of the PNP_TDI group stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList.

Example: PNP_TDI group has value: 0x2 0xA 0x7 => two items, first to load has Tag 0xA, 2nd 0x7.

These settings are important when another driver might hook a vital function for filtering traffic and thus hide it from the firewall driver.

As there are usually two firewall drivers (NDIS for filtering packets and WFP for filtering connections/applications). Now NDIS driver requires running TCP driver, and your drivers are somehow connected to each other. That means the TCPIP is loaded first, then NDIS and then WFP.

However that calling order might leak few packets between TCPIP and NDIS. The cure has a name - WFP boot filters. So when firewall is configured correctly the loading order is as follows:

WFP boot filters are activated
...
TCPIP starts
our NDIS starts
...
our WFP starts
...
Base Filtering Engine service (usermode part of WFP) starts, boot filter are turned off, regular filters are turned on
...
firewall service starts applying the filters and/or deciding over traffic by them.

Rules for the firewall in files are not available until disk drivers and minifilters are up, so during boot you can use only CurrentControlSet registry key. That's why firewalls usually don't filter during boot or the rules are limited to simple conditions.

(The whole process is simplified, there are also other aspects like NDIS filter classes, WFP rules options, ntdll firewall service etc.)

So back to your question - firewalls start at the right time, however the user configuration is usually loaded later (when the service is started). So there can be situations where some firewalls might leak few packets during boot.
However that should not be a problem as only drivers could send packets in the time frame and when your system is clean (of rootkits) you are fine.

For those interested in details:
Introduction to WFP
Drivers load order
ELAM Drivers
NDIS Filter drivers
Windows OSI model

 

OK, then firewall won't help as any malware driver can speak directly to TCPIP or any NIC driver and send anything it wants. Or it can even act as a NIC driver.
Message is clear - never install unsigned or unknown drivers.

 

Thanks for the posting.

As we can see in the pictures it s more than local traffic taking place.

The strange thing is that ,if the build in firewall is blocking boot up properly being in the core of the OS ,there is a 3-rd party firewall that blocks traffic at boot up much better.
ZoneAlarm does only some local ICMP.So in spite of it s weak points ZoneAlarm driver seems to do it s job properly.

Outpost FIrewall ,Private Firewall and Jetico 2 seems like they have a problem.

In the Outpost forum i could see another guy observing something similar and using a nice workaround ,a script to delay the network card initialization.
Firewall makers could implement this to avoid risks i think.

Maybe the network cards drivers are involved here as well so i ll mention that the network card is an Intel (as you can see in the pictures) Gigabit Desktop CT one ,i tend to not use the mobos integrated cards.

 

What I see in the picturesis the normal multicast traffic and windows itself checking whether it has an internet connection by using that second address.so that it can show in the tray icon whther there's an internet connection or not.When I tested with wireshark In earlier post I noted that tray icon was showing no connection to internet.I don't see any evidence in the pics of any traffic getting out...only local traffic and the windows thing checking if it has a connection or not.Why as you have observed some firewalls don't show this maybe because they block local traffic as well?.I'm not an expertvso maybe a firewall guru might make more sense of it all.Forgot to mention I'm using windows 7 32 bit

 

The firewall is in Block All mode and in spite of that we have traffic at start up.

Those packets are captured on another PC mate , that is at the other end of the network cable ,those packets got tru the firewall.
The machine calls DNS to check for connectivity and then initiates connections that complete.LLMNR traffic is one part of the story ,TCP traffic is something else

That server IP is not in my LAN so it s not local traffic.

This does not happen with the build in firewall when in high filtering mode or with Zone Alarm in block traffic mode.

I presume Block All should indeed be Block All.

If you consider that this is normal ,no problem.

Observed the issue and posted ,maybe agnitum and the others look into it ,and some other strange default settings (reported in another topic) in this firewalls.

Firewalls should first stop/filter the traffic and then show off their HIPS.

I wonder how the Security Suites do the firewalling stuff as most of the people install the bloat and move on.

To bad no one like Stem is testing this so called firewalls ,for some you pay money for 100% so called protection ,that by default are prone to be exploited.

 

How is it not local traffic when its initiated from your pc to the gateway which has wireshark on?.The query doesnt get any further because outpost blocks any internet connection.I honestly cant see any problem there.I agree it would ne nice if stem or paranoid2000 could chime iin though.Havent heard from them for a while so i hopecall is well with those guys.

 

Yep, but I would say it has been a bit more than a while in Stem's case.

https://www.wilderssecurity.com/member.php?u=39078

 

Hmm paranoids was 2010.Where has the time gone!

 

Is there any way that I can see those .xcf files in 32bit WinXP or 64bit Win7?

 

Other than concur with ellison64, here's my contribution to this thread - I saved those GIMP xfc files in Linux Mint as std png, attached.
I understant snap. Less so with snap1. Yeah, where's Stem or PhantOm?

 

I believe that what Sm3K3R is trying to demonstrate is that even with firewall options set to block all traffic, there is generated traffic at boot of the client pc that makes it out through the nic unto the next endpoint. Regardless of whether traffic is local or exits out to the WAN, in my opinion, the firewall should have blocked the packets.

I do notice the tcp handshake from the second screenshot between internal ip and a WAN ip 82.112.106.9. Now that is definitely not local and confined to LAN multicast and if it is observed during client bootup, I'd be questioning the firewall's capability considering the firewall option is set to block all traffic.

 

Here's more information -
https://www.wilderssecurity.com/showthread.php?t=297492
specifically post#6 by kronckew (in VM?) providing a bit more detail than his post in this thread.

It could be that the connection to akamai in the second shot still have to do with what Microsoft does very early. In which case the sandbox and the drivers mentioned might take care of the security part.
But since the unix time is rough to decode and since we still haven't seen what and when Outpost logged, it's really rough to be convinced that the http SYN packets went out before the the service started.

Edit: ignore the below picture. All wrong It was under Block MOST setting, not Block ALL. For correction see post #32

My router has decent logging, and indeed, few microsoft connections happened between the time IP was issued and Outpost was well on its way. When those events happened in relation to drivers loading I don't know. What I see is this:


OT: The puzzler to me is that win update connection because Win update service, BITS, and Win firewall are all disabled I suppose M$ does some funny things very, very early.

 

In the link i posted i post 12 it says that if theres an internet connection there should a http 200 ok bit of text after the transmission.If i assume this link is correct in its analysis then ttheres no internet connection shown in the pics.aThen theres the second IP address apparently showing handshake but with out of order packets.I'm still iinclined to bbelieve theres nno iinternet connection and something elesw iis going on on the lan side ir set up.Whether block all should block lan and wan is irrelevant because outpost block all allows lan as stated in its help files.Id love more info and analysis on that second ip address though.This is a really intresting thread for non experts like myself....has it really connected out ?....is it incorrect logging ...p.Cmon firewall experts..get involved and put me out of my misery
?