m0unds

CLOSED Firewall issues w/EIS .7538 on Creators Update

Recommended Posts

Hey,

Someone in the stable product forum posted about an issue with Windows' firewall status being misreported post-creators-update. I ran into an issue with the current beta (.7538) wherein EIS reports the product firewall is functioning, Windows says: 1. Emsisoft isn't mentioned as product managing the firewall, 2. The Windows firewall is off. (reported by both Windows Security center and the Windows Firewall applet itself).

 

In this state, the firewall is actually stopped and EIS' firewall doesn't do anything to inbound packets (I'm able to ping the system despite explicitly blocking ICMP echo for testing purposes)

Would you guys like me to see if I can reproduce this and provide logs, or is it something you're already aware of & tracking?

 

Thanks

Chris

Share this post


Link to post
Share on other sites
7 minutes ago, stapp said:

Devs usually love logs m0unds :)

haha, yeah - I'm already collecting, just wanted to be sure before I uploaded or whatever :)

Share this post


Link to post
Share on other sites

Does Security and Maintenance show that EIS is on like in the following screenshot?

Win_10_CU_Firewall_Status.png

Share this post


Link to post
Share on other sites

Yeah, but the windows firewall snap-in also shows the firewall is off. I sent in logs last night after reproducing the failure w/the current beta release. I included a screenshot of the windows security center, windows firewall snap-in and EIS product firewall state

 

*EDIT* my phone didn't load the second screenshot when i viewed it - the second screenshot in my case shows the firewall is off.

 

eis_firewall_borked.thumb.png.bb7cba32bad4366f4888fd1d54a3abd8.png
Download Image

Share this post


Link to post
Share on other sites

This Firewall status issue is related to the new Windows Defender Security Center only.

As you can see , the Security and maintenance screen shows that the EIS firewall is activated and functional.

We are working on a fix to have our FW have a correct status in the Defender Security Center

 

Share this post


Link to post
Share on other sites

Hi Frank,

That's not the case. As I mentioned, the security center *and* windows itself (firewall snap-in) indicate the firewall is off. EIS says it's enabled. I just performed portscans of the machine with EIS firewall in the following states: Private network, Public network, Broken Private Network (EIS on, but windows saying the fw is off) and Broken Public Network (EIS on, but windows saying the fw is off) and it's plain to see EIS isn't blocking inbound traffic like it should be in this state. I'm attaching screenshots for illustrative purposes:

fw_working_private.thumb.png.b658c6ca92bbe4042523c0f181a836cf.png
Download Image

fw_working_public.thumb.png.4318ea9e61c958b7da97ef8607e5d773.png
Download Image

fw_broken_with_windows_dialogs.thumb.png.5ea7e17a04b5e1bfe21e351450bf64b2.png
Download Image

fw_broken_in_priv_mode.thumb.png.18dba4097d185acda2100fcfa28b7bb1.png
Download Image

fw_broken_in_pub_mode.thumb.png.2034cc9d2b7192470c2b4e3e7bd55f7c.png
Download Image

 

I sent in diagnostic logs referencing this thread using the support tool in EIS. I hope this added info helps to clarify the issue I'm seeing

 

EDIT: Also, whatever the profile EIS sets for outbound FW processing when the windows FW dies is how the product remains after the FW dies. E.g., during my test, I broke the FW with EIS set to public network. In the "failed" state, my machine can't reach network shares (indicating public network mode in EIS). Switching EIS back to "private network" while in the broken state doesn't fix it. If I then go to the firewall snap-in or security center and let windows "Fix" the firewall, THEN reset the profile to Private, everything is back to working. If I switch EIS from Public to Private in the broken state then let windows "Fix" the firewall, it stays in public mode until I manually switch it from Public to Private.

 

Thanks,

Chris

 

Edited by m0unds
Had time to make more informative screenshots, inserted them into the post

Share this post


Link to post
Share on other sites

I've also managed to replicate a similar situation on a fully patched machine running Win10 without the creators update.

  1. Installed EIS 7538
  2. Rebooted
  3. Verified EIS firewall profile for the network is set to private
  4. Execute port scan of the system, observe open ports (135,139,445,2869,3389,5357 - machine is behind NAT, RDP doesn't matter)
  5. Toggle firewall off in EIS, wait 30 seconds
  6. Execute port scan of the system, observe open ports again (135,139,445,2869,3389,5357)
  7. Toggle firewall back on and switch profile to "public network", wait 30 seconds
  8. Execute port scan of system, observe open ports again (135,139,445,2869,3389,5357)
  9. Reboot system with EIS still set to public network
  10. Execute portscan, all ports show closed/filtered

Share this post


Link to post
Share on other sites
On 5/31/2017 at 9:10 PM, m0unds said:

I've also managed to replicate a similar situation on a fully patched machine running Win10 without the creators update.

  1. Installed EIS 7538
  2. Rebooted
  3. Verified EIS firewall profile for the network is set to private
  4. Execute port scan of the system, observe open ports (135,139,445,2869,3389,5357 - machine is behind NAT, RDP doesn't matter)
  5. Toggle firewall off in EIS, wait 30 seconds
  6. Execute port scan of the system, observe open ports again (135,139,445,2869,3389,5357)
  7. Toggle firewall back on and switch profile to "public network", wait 30 seconds
  8. Execute port scan of system, observe open ports again (135,139,445,2869,3389,5357)
  9. Reboot system with EIS still set to public network
  10. Execute portscan, all ports show closed/filtered

Hello,

Thank you for the input.

EIS should block those ports for public networks only. Technically, when you switch the network type - you tell the firewall core

which rules should be active. For example - rules blocking those tcp/udp ports are "enabled" for the public networks only.

This means, that the rule should work for the public networks and shouldn't for the private ones.

So, the ports being seen as open while in "private" network - is an expected situation.

About the nmap.org and other tests from outside - did you make sure that you didn't actually test your router ?

(by either connecting the system directly to the internet, or by setting up your router to forward the ports being tested)

Share this post


Link to post
Share on other sites
50 minutes ago, Andrew F. said:

Hello,

Thank you for the input.

EIS should block those ports for public networks only. Technically, when you switch the network type - you tell the firewall core

which rules should be active. For example - rules blocking those tcp/udp ports are "enabled" for the public networks only.

This means, that the rule should work for the public networks and shouldn't for the private ones.

So, the ports being seen as open while in "private" network - is an expected situation.

About the nmap.org and other tests from outside - did you make sure that you didn't actually test your router ?

(by either connecting the system directly to the internet, or by setting up your router to forward the ports being tested)

Hi Andrew,

That's actually what I was trying to illustrate - showing the ports that are expected to be open in public and private network firewall profiles, and then showing what happens when Windows says the firewall is in a "disabled" state.

The problem isn't that the ruleset is changing - the problem is that when Windows indicates the firewall is disabled, EIS' inbound filtering seems to not be working, which leads me to think something might be amiss with both Windows and EIS. That's why I included different nmap results with different profiles active (done from within my LAN, so directly testing the system with EIS installed).

When Windows indicates the firewall isn't working and I change EIS from private to public, the open ports I see are the same regardless. If use the firewall snap-in in Windows or the Security Center to re-enable the firewall, then I see the ports open that should be.

i.e. Private - sharing, RDP, etc ports should be open if the svcs are active on the system. Public - nothing should really show up because ostensibly the network is untrusted. When Windows says the firewall is enabled, and there's no "failure" state, it works exactly like that. If I trigger the inconsistency, it doesn't matter which profile I select, because EIS is allowing all inbound traffic (as evidenced by my nmap screenshots).

Thanks,

Chris

Share this post


Link to post
Share on other sites

Thanks for explanation.

Would it be possible to reproduce this and get a set of debug logs?

(Please make sure to reboot after enabling debug logging).

(Thank you in advance).

But again... did you make sure that you didn't test your router ?

About what windows shows - there's a bug with displaying the status of our firewall module in the windows defender,

so the information there isn't correct.

I believe there will be a notice in the changelist when this will be fixed.

Share this post


Link to post
Share on other sites
3 hours ago, Andrew F. said:

Thanks for explanation.

Would it be possible to reproduce this and get a set of debug logs?

(Please make sure to reboot after enabling debug logging).

(Thank you in advance).

But again... did you make sure that you didn't test your router ?

About what windows shows - there's a bug with displaying the status of our firewall module in the windows defender,

so the information there isn't correct.

I believe there will be a notice in the changelist when this will be fixed.

Sure thing.

I sent debug logs the day before yesterday using the support function in EIS, when I posted the issue, but I can generate more and send them if you need me to.

I'm positive I didn't test my router - the device I was using to test is in the rack under my desk, and is connected to my wired LAN :)

I've seen the bug and this seems different because it's not only occurring within security center, but also in maintenance and security as well as the firewall snap-in itself.

I'll keep an eye out for that bug fix when it's available

 

Thanks!

Chris

Share this post


Link to post
Share on other sites

I performed some more testing and took additional screenshots w/the security and maintenance cpanel open, since that's how you guys were diagnosing whether EIS was working. It does indeed show EIS is working, but port scanning still shows inbound filtering is borked. Outbound filtering by EIS seems to work though, but profile changes are impacted while in the "Failed" state. See below for screenshots and more info.

eis-private-working.thumb.png.83662d03af6dc112006798529118ca5e.png
Download Image

eis-private-broken.thumb.png.9c10028601c333756d71052885d0c870.png
Download Image

eis-public-working.thumb.png.db6e17faa8efb12e14194477fa2a1208.png
Download Image

eis-public-broken.thumb.png.b15ff8533f9978043d49836ee162b06f.png
Download Image

Additional info:

Outbound traffic control by EIS remains in whatever profile the product is set to when I toggle EIS' firewall off/on (causing the Firewall status issue w/Windows Security Center and Windows Firewall cpanel).

If EIS is set to Public and I toggle the firewall off, it will still control outbound traffic, but inbound is no longer filtered.

If I change the profile to private while in the "failed" state, and use "turn on" in Windows Security Center to turn the Windows firewall back on, it will still filter traffic according to EIS' Public network profile UNTIL I change the profile in EIS to Public, and then back to Private.

Likewise, if EIS is set to Private and I toggle the firewall off, it will still apply the product's rules for Private networks and inbound traffic will no longer be filtered (ports that have no explicit ruleset are open, just like on Public mode w/the firewall broken)

If I change the profile to Public while in the "failed" state, and use "turn on" in WSC to turn the Windows firewall back on, it will still filter inbound traffic according to EIS' Private network profile UNTIL I change the profile in EIS to Private and then back to Public.

 

@Andrew F. - I collected more logs and uploaded them with a text file that outlines the test cases I used while the log collection was running. Let me know if you need any additional testing.

I hope this helps.

Share this post


Link to post
Share on other sites
On 6/2/2017 at 4:20 PM, Andrew F. said:

@m0unds Thanks, I've received the logs.

Will try to reproduce it.

Hey,

Any luck reproducing it?

Thanks,

Chris

Share this post


Link to post
Share on other sites

Yes , Firewall issues,  now after the "component missing" is fixed . Just seems slow with , sometimes no connection @ all.

Why did you try to fix something that was not broken (win7 64)?  I know broken win 10, what a mess. These last two updates were hideous.

Working fine for two years, now broken.

Thanks a lot.

.7583

By the way, sent logs over and over.

 

 

Share this post


Link to post
Share on other sites
8 hours ago, m0unds said:

It's been a month. Any luck reproducing this?

Hi,

Sorry, I must have missed the notification email for your reply somehow.

And - yes, reproduced. Should be fixed for next release.

Share this post


Link to post
Share on other sites
10 hours ago, Andrew F. said:

Hi,

Sorry, I must have missed the notification email for your reply somehow.

And - yes, reproduced. Should be fixed for next release.

Hi,

No problem at all. Glad to hear it'll be fixed.

Thanks,

Chris

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.