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

Discussion: Long-term management strategies

Postby NoelC » Wed Jan 27, 2016 4:52 pm

This isn't a feature request, but I'd like to discuss long-term management of a firewall setup a little bit, and maybe get some ideas.

I've a very nicely working setup right now for Win 7, 8.1, and 10 systems. They're secure and private, yet function normally with the operations that DO require network access. In a nutshell I have many security sites (e.g., ocsp, ssl, certificate management addresses) whitelisted as rules in zones assigned to the proper sets of services in order to run these systems cleanly, yet block everything else that's unknown or unwanted.

This took filling some zones right to capacity (39 rules), since the system, executing normal security operations, DOES contact a good many servers.

The obvious question arises:

How best do I continue to manage this setup long-term?

I can't just keep adding addresses to the whitelists. They have to be managed more intelligently.

The reason I have been able to generate nice, accurate rules is that the Sphinx W10FWC program does a great job of presenting lists of addresses to which contacts are attempted and fail. I use that information to decide what to allow (or reconfigure so that the communcations aren't attempted in the first place).

But it does not help me much with the opposite issue: Determining which rules have become obsolete.

Obviously I could continue to whitelist new addresses and leave the old, obsolete ones in there - but that would ultimately end up with way too many whitelist entries, and cause its own security problems.

An idea that comes into my head is this:

I could craft a job that correlates addresses actually contacted against the zones, and notify me under long-term conditions that particular addresses are either no longer responding or have not actually been contacted by the system in a very long time. In other words, the antithesis of logging and listing what contacts ARE attempted.

This could not only help remove obsolete entries to make room for new ones, but also to help manage mistakes or ranges that have been opened up too widely (e.g., only 1.2.3.4/32 is actually contacted on port 80 when 1.2.3.0/24 all ports has been set into a rule).

Some approaches:
  • Sweep through the registry, extract the whitelist rules (they would have to be specifically identified).
  • Check for each of the addresses still being reachable (server no longer online/at this address check).
  • Check pertinent log(s) for the addresses having actually been contacted by the system (obsolete rule check).
  • Generate a report that would facilitate zone maintenance.

(Not just speaking to the W10FWC folks here) I'd LOVE to hear your ideas on this!

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

Re: Discussion: Long-term management strategies

Postby PietO » Wed Jan 27, 2016 6:31 pm

NoelC wrote:This took filling some zones right to capacity (39 rules), since the system, executing normal security operations, DOES contact a good many servers.
....
(Not just speaking to the W10FWC folks here) I'd LOVE to hear your ideas on this!
-Noel


Sorry NoelC, no idea's neither such a problem: 13 rules is my max in the non-network version of W10-FC (svchost). I was on my way to make a huge list for SKYPE but gave up: "not manageble".
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Thu Jan 28, 2016 5:04 pm

>This took filling some zones right to capacity (39 rules), since the system,

Actually 40 and will be increased as promised. Please stay tuned.

>Determining which rules have become obsolete.

Could ZoneResult: *+Prompt help to revise the rules set anyhow

>I could craft a job that correlates addresses actually contacted against the zones, and notify me under long-term conditions that particular addresses

May be a php/ruby/perl/or so script that parses Settings/Export and access.log, extracts from Settings/Export per-applications rules and looks for the same apps/rules pares one-by-one in the access.log. If the related access.log entries are not found at all or found too old, you can delete the rule in the export.xml and import it then back after the required changes are made.
So the process can be also automated.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Discussion: Long-term management strategies

Postby NoelC » Fri Jan 29, 2016 12:39 am

Thanks. I was looking in the XML, and it's rule 0 through 39 == 40 total.

But even an expansion of rule capacity only puts off the problem. It's entirely possible some of my rules in that list of 40 are already obsolete.

The idea of the script that you mentioned is exactly what I had in mind. I've yet to work out all the details, but ideally a listing would be presented saying, in effect,

"Rule xxxxx may be obsolete; the last time it was actually needed was ddddd".
-or-
"Rule xxxxx may be obsolete; the IP address to which it refers hasn't responded since ddddd"

The only reason for there being two of these is that perhaps the second one could trigger rule obsolescence a little sooner than the former.

>ZoneResult: *+Prompt

Hm, interesting idea, though I can't quite see how in practice it would be helpful. If an individual Rule were allowed to cause a prompt, THAT would help. Or if two different zones could be assigned to a program, THAT would help, since possibly obsolete rules could be moved to the prompting zone. No prompts in a sufficient amount of time and voila, it's obsolete.

Perhaps I'm missing something important here.


PietO, good point about Skype - I only use it on one of my systems and for now it's allowed to do whatever* it wants. That used to make more sense, but it IS now Microsoft software after all.

*Well, not quite whatever, since I do have some important Microsoft addresses shorted out via DNS rules.


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

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Fri Jan 29, 2016 3:07 pm

>The idea of the script that you mentioned is exactly what I had in mind.

You could make a simple step for the start.
Import access.log into a spreadsheet using “|” as separator, sort by program, then by zone, then by time. The result should be demonstrable.
All the rest is a question of VB-scripting probably.


>The only reason for there being two of these is that perhaps the second one could trigger rule obsolescence a little sooner than the former.

Hmm…. Your genuine intention is finding obsolete rules as self-sufficient entities. Right? So, maybe, by-IP checking is redundant.

>ZoneResult: *+Prompt
>Perhaps I'm missing something important here.

It’s another (roundabout) way to make the rules set up to date. The way may be long but if you (preserving a current zone) apply a rule-less zone with Disable+Prompt to an application, you will start accumulating correct enabling rules for the application/zone getting the rules from the repository for instance. It’s kind of training from scratch. However you are right the way may be long and time consumptive.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Discussion: Long-term management strategies

Postby NoelC » Sat Jan 30, 2016 6:54 pm

Okay, I see what you mean: Essentially you're suggesting to just build the rule set back up again per things accessed going forward - much like the initial effort. Thanks for clarifying. This may be more trouble, and I'm not willing to give up on developing a method to sniff out obsolete rules just yet.

Thanks again for the ideas for using the access.log file. I use Gnu (unix-like) tools in batch files most often for scripting, and I can easily see how I can use SED to get the specifics from the Access.log. I'll need to reconfigure slightly so that both allowed and denied events get into the Access.log file now...

Hmm... A product improvement idea...

Perhaps you could consider adding a "Last Matched Date" indication in your product that tracks the last time a given rule was actually exercised. If that information were to be shown right in the rule editing dialog, it would be pretty easy for a user to go through the list and look for any rules that haven't been needed for a given time horizon (e.g., 6 months). In general that could also help sniff out issues where a specific rule is no longer needed because a more general one was added further up in the list.

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

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Sun Jan 31, 2016 3:27 pm

> Essentially you're suggesting to just build the rule set back up again

Just as one of possible approaches.
Complete revision may make sense.


>Thanks again for the ideas for using the access.log file. I use Gnu (unix-like) tools in batch files

Oh yes, it’s much more friendly for scripting and various “sheaves binding”

>Hmm... A product improvement idea...
>Perhaps you could consider adding a "Last Matched Date" indication in your product that

Nearly the same is available in the Events pane, just sort by the Time column.
The time is updated per-used IP/Port however. So you would have multiple entries for the same app/zone/rule, you should just find the latest.

Unfortunately the events pane has a hard coded string limit, just not to include a million events of “6 months” cached.
However the eldest event estimates the real time “horizon”.

Putting the last triggered time stamp into application assigned zone/rule directly would cause rather a potential inconsistency.
For now applied to application zone (with rules) is self-sufficient, transparent and easily moveable/distributable/updatable through the entire network.
If any “context” is added to the entity, the entity will lose the transparency and the time stamp update policy will be foggy enough.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Discussion: Long-term management strategies

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

It's too tempting to use the F9 key to reset all the events in the Events pane as an aid to short term management, so trying to maintain long-term Events pane stability is probably not the best approach.

For now a scheduled job that will accumulate the proper long-term info that could then be used to help manage the rules in zones would be a good first step, and I'll be pursuing that. I will post here about what I develop.

Regarding context... As you mentioned there are statistics gathered in the Events pane. Of course any tool to aid with management of firewall configurations needs such statistics gathering to help the user. I'm just thinking of another layer, something that's more long-term. It could be stored with the system just the same as the data for the Events pane, and presented in the zone dialog with the associated rule. Food for thought.

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

Re: Discussion: Long-term management strategies

Postby NoelC » Sun Feb 14, 2016 4:06 am

I went through a cycle of zone maintenance today, and was able to successfully maintain my whitelist of allowed security servers.

I looked in both my DNS server log and W10FWC Access.log for each address or range of addresses I had set up in my "System Operations with CRL" zone. It was easy to see all accesses to the address and also the times (most importantly, time of most recent access, and what names resolved to the address).

  • If accesses to the address(es) specified by a rule have been made recently, and they appear security related, it remains right where it is in the zone.
  • If no accesses have been made in the month my logs now cover, I put the entry in a list (in my notes) to consider it for removal (I haven't been logging long enough to say that any entry is truly no longer needed yet).
  • If accesses to the address appear to be not actually security-related, then it may have been a mistake to add it, so I removed it.
  • I discovered a typo I'd made, because an address was not accessed, but one that had only one digit different was attempted (and blocked) many times.
  • I was able to make *just* enough room by removing entries to add several new addresses seen accessed (e.g., pki.google.com), though I am still right at 40 entries.

Zone rule list management WILL be manageable long-term, I think, with the information I am logging.

Doggone CDNs muddy up everything and make things more difficult. Some of the addresses I saw in my logs were the same for literally hundreds of different server names. That starts to make me think that the firewall is going to have to get smarter about name resolution, and integrate that in with address blocking somehow.

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

Re: Discussion: Long-term management strategies

Postby VistaFirewallControl » Mon Feb 15, 2016 2:12 pm

>though I am still right at 40 entries.

So do you still need the limit increased?
The option is scheduled, however unfortunately we have some more urgent things to do.
So sorry for the delay.

>That starts to make me think that the firewall is going to have to get smarter about name resolution, and integrate that in with address blocking somehow.

How the DNS option works.
The option uses DNS cache only.
The reason is simple, DNS resolution may be mutable/dynamic and reverse DNS resolution may be limited.
So if a program goes to an XYZ.com, DNS resolves it to a.a.a.a, a real DNS request for resolving a.a.a.a may be ambiguous (*) and will cause the network activity. The latter may be massive if you refresh a related pane entirely, what is not good.
(*) Imagine you have multiple virtual sites hosted in the same server/IP. The situation is typical for web hosting providers. So when you go to XYZ.COM you receive a.a.a.a as IP.
But when you try to resolve a.a.a.a back to a name you may receive another (maternity, provider's) ABC-host.com instead of expected XYZ.com.

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.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Next

Return to Remote/Network/Cloud protection

Who is online

Users browsing this forum: No registered users and 1 guest

cron
suspicion-preferred