Welcome
Welcome to vistafirewallcontrol

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

Discussion: Long-term management strategies

Re: Discussion: Long-term management strategies

Postby NoelC » Mon Feb 15, 2016 4:12 pm

Yes, I would still find a rule list size limit expansion useful.

It's not urgent - I don't want to seem like I'm pushing you around - but it would be VERY helpful. I appreciate your being willing to consider it.

Unfortunately, based on the Sphinx firewall limitations and some things learned since yesterday (more on this below), to carefully whitelist the servers needed for allowing proper operation of the cryptography service (CryptSvc) (e.g., to do things like check certificate chains or for certificate revocation) I really do seem to need more than 40 entries.

After yesterday's list maintenance, I've found that the server name ctldl.windowsupdate.com is contacted regularly by CryptSvc to check for certificate revocation. This is expected, per this info:

http://serverfault.com/questions/714637 ... using-wsus

So the cryptography service (CryptSvc) legitimately needs to be able to contact ctldl.windowsupdate.com. The addresses used for this activity have been observed as:

23.14.84.24
23.14.84.48
23.14.84.57
23.14.84.162
23.14.84.163
23.14.84.177
23.14.85.27
23.14.85.48

I *had* been allowing these addresses through a 23.14.84.0/23 rule, but now I've removed it and filled the list with other recently contacted certificate revocation list servers. I removed that entry because it was ALSO seen to allow other sites, so at the moment ctldl.windowsupdate.com is now blocked. I'd like my certificate management / security subsystem to work properly.

Ideally, with a deeper list limit (than 40), I could re-add JUST the addresses seen actually contacted above, since there are just 8 addresses - way less than the 512 that were allowed by that overly permissive rule I removed.

Thinking outside the box a bit, an option that could help circumvent the need for more complex lists would be the ability to break the requester down to the individual service. I know you have technical issues with making that identification, but... With that ability I could be more liberal with a simpler zone (possibly assigning the wider range of addresses, or even "Allow All" without so much risk) for CryptSvc, yet still for example be able to block other services from contacting servers online.

Based on my observations, CryptSvc is recognized by the Sphinx firewall as the same svchost process that is involved in doing Windows Updates. This gives rise to a fundamental conflict, since it's impossible to tell whether the server is being contacted for a certificate revocation check or - perhaps - a secret, unsanctioned update. We already know there are ways Microsoft can do secret updates.

Thank you for the conversation and willingness to consider my input.

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby NoelC » Mon Feb 15, 2016 4:51 pm

VistaFirewallControl wrote:So WxFC uses local DNS cache always and only. Looks like it’s the only way to find genuine XYZ.com that was initially resolved.
You can use “ipconfig /displaydns” for the reference.


By the way, I wanted to mention separately: The DNS cache lookup apparently isn't always working.

I can see entries where my DNS server was contacted for each of the requests highlighted in this screen grab, yet W10FC isn't showing any names.

Image

Image

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby NoelC » Mon Feb 15, 2016 4:56 pm

And lastly, what I meant by:

...That starts to make me think that the firewall is going to have to get smarter about name resolution...


Was just some future thinking about what you might want to consider for future enhancements in this day and age of multiple virtual sites and how they relate to addresses.

If a future version of the firewall software were able to hook into the process for name resolution, then use that additional information to have users define rules by name instead of address... You can see the utility in that.

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Mon Feb 15, 2016 5:26 pm

>Yes, I would still find a rule list size limit expansion useful.

OK, we will keep the option scheduled.

>the ability to break the requester down to the individual service.

CryptSvc is implemented in svchost formally.
So we can generally rely on WFP ability to identify separate svchost instances.
You can try to add a new entry for svchost with user name “NT_Service\CryptSvc” (should be listed in the Users combo).
The by-service identification is spite of it’s declared is a WFP responsibility area.
There are many evidences that by-service identification is not implemented in full at least, but it may be Windows version dependent. There is a sense to try though.

>By the way, I wanted to mention separately: The DNS cache lookup apparently isn't always working.

Actually any DNS cache entry has its TTL (TimeToLive), so any entry may be washed out.
WxFC supports the TTLs. The question is what “ipconfig /displaydns” says for those IPs. The results should be equal.
Hmm.. May be WxFC should forcibly increase the TTL. It might make the resolving not absolutely correct, but….. What do you think?

>Was just some future thinking about what you might want to consider for future enhancements in this day and age of multiple virtual sites and how they relate to addresses.

We can’t affect DNS principles, but all the rest is probably possible.

>If a future version of the firewall software were able to hook into the process for name resolution, then use that additional information to have users define rules by name instead of address... You can see the utility in that.

Honestly we think about nearly the same. We would like just to avoid hooks and trying to find another way to catch the DNS traffic. In spite of DNS requests are generally made in the name of svchost, hooking may have negative consequences. Hope you understand. Anyway we are thinking in the same direction.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Discussion: Long-term management strategies

Postby NoelC » Mon Feb 15, 2016 6:03 pm

>Actually any DNS cache entry has its TTL (TimeToLive), so any entry may be washed out.

That occurred to me just after I posted, and I bopped my forehead. :)

I'm not sure I'd want the TTL changed by the firewall software. Let me think on that.

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby NoelC » Mon Feb 15, 2016 6:17 pm

VistaFirewallControl wrote:You can try to add a new entry for svchost with user name “NT_Service\CryptSvc” (should be listed in the Users combo).
The by-service identification is spite of it’s declared is a WFP responsibility area.
There are many evidences that by-service identification is not implemented in full at least, but it may be Windows version dependent. There is a sense to try though.

Good idea, but unfortunately I'm not seeing the necessary entry here (Windows 8.1)...

Image

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Mon Feb 15, 2016 7:38 pm

>I'm not sure I'd want the TTL changed by the firewall software. Let me think on that.

Not the original TTLs. WxFC just uses TTL to remove the entries from its own cache.
Obviously WxFC may not hurry up to follow the TTLs strictly.
The entire system will not be affected anyway.

> “NT_Service\CryptSvc”

It’s a puzzle. What is the control panel version. Could you send the Control.exe to support for the verification.
Actually the panel adds a set of ”NT SERVICE/*” users automatically and unconditionally for svchost.exe (OS version independent). It’s just a combobox AddString.
Just additionally tried on 8.1. The users were added successfully.
Could it be the slash (or space) prevented the strings from the combobox insertion anyhow on the specific system?
The curious thing is the users addition is pretty straightforward.
Something like
if (fullpath includes svchost.exe)
{
combobox.AddString(_T("NT SERVICE/wuauserv"));
combobox.AddString(_T("NT SERVICE/Dhcp"));
combobox.AddString(_T("NT SERVICE/Dnscache"));
combobox.AddString(_T("NT SERVICE/LanmanWorkstation"));
combobox.AddString(_T("NT SERVICE/LanmanServer"));
combobox.AddString(_T("NT SERVICE/CryptSvc"));
combobox.AddString(_T("NT SERVICE/BITS"));
combobox.AddString(_T("NT SERVICE/NlaSvc"));
}
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Discussion: Long-term management strategies

Postby NoelC » Tue Feb 16, 2016 5:27 am

Sorry it took me so long to respond, I got bogged down in something unrelated after I posted.

I do agree that looking back in time for the last cached DNS entry, regardless of whether it expired, would improve WxFC's output. I don't see a downside, assuming it's always the most recent resolved address displayed. Since I keep my systems up for as long as possible between reboots, I expect all the entries would ultimately be filled in with names for me.

Regarding the missing entries... I have new info: If I look at one of the svchost entries automatically added by initial Detection, the entries you expect are there. The are just not there if I add the entry manually through the Add button. Perhaps there is an alternate path through the software for manually-added entries?

Image

What I'm running is a beta build:

Image

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Discussion: Long-term management strategies

Postby PietO » Tue Feb 16, 2016 9:47 am

NoelC wrote:After yesterday's list maintenance, I've found that the server name ctldl.windowsupdate.com is contacted regularly by CryptSvc to check for certificate revocation. So the cryptography service (CryptSvc) legitimately needs to be able to contact ctldl.windowsupdate.com. The addresses used for this activity have been observed as:

23.14.84.24
23.14.84.48
23.14.84.57
23.14.84.162
23.14.84.163
23.14.84.177
23.14.85.27
23.14.85.48

I *had* been allowing these addresses through a 23.14.84.0/23 rule, but now I've removed it and filled the list with other recently contacted certificate revocation list servers. I removed that entry because it was ALSO seen to allow other sites, so at the moment ctldl.windowsupdate.com is now blocked. I'd like my certificate management / security subsystem to work properly.

Ideally, with a deeper list limit (than 40), I could re-add JUST the addresses seen actually contacted above, since there are just 8 addresses - way less than the 512 that were allowed by that overly permissive rule I removed.

-Noel


as you know the DNS <=> IP translations is not one-to-one in both directions; e.g DNS=>IP depends on actual Server load-distribution and configuration. In order to keep this manageble at firewall ip-level, i saw only one option: define this DNS=>IP translation at host-level fixed. For your ctldl.windowsupdate.com i've got one entry "104.93.82.170" at the moment. As so now and then (once per year or so) the fixed-assigned ip-adresses do not offer the assigned-function anymore due to Microsoft server-reconfiguration, i have to change one fixed assignment.

This process could in theory be automated by a weekly routine that check the actual DNS-translation (for a fixed set domains) and changes the Hosts-file and WxFC-rules. For me personally: i prefer to do this manually thus realising what's ongoing. In this way, i will never hit the 40 rules limit.

FYI: the tests done in the past together with Sphinx-soft on the WFP-functionality for specific svchost-users (e.g. cryptserv) revealed that this is in general not working correctly/reliable on Windows7. Another firewall (Windows Firewall Notifier) was also struggling with this Windows behaviour thus i abandonned this route.
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Tue Feb 16, 2016 11:57 am

Noel,

>I do agree that looking back in time for the last cached DNS entry, regardless of whether it expired, would improve WxFC's output.

OK, We will try to improve the TTL making it not too strict in the next build.

> Regarding the missing entries... Perhaps there is an alternate path through the software for manually-added entries?

Exactly!
So please try to set the NT_SETVICE\CryptSvc username on the exiting svchost entry.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

PreviousNext

Return to Remote/Network/Cloud protection

Who is online

Users browsing this forum: No registered users and 0 guests

cron
suspicion-preferred