firewall rule configuration - system rules, non specified app rules?

Two part question....

Rules that are created without an application specified show under the Detail view as applying to "All" applications.

Rules that are created without an application specified show under the Application specific view as "Rules with no Application assigned."

But they do not appear to apply to "All Applications" as the nomenclature in both instances would seem to apply - they appear to actually be applied ONLY to any application that does not have ANY other rule specified.

Such that if I create a rule without an application specified to block all TCP/UDP to a specific server (or range of addresses, for example, 192.168.1.1) then as long an application (such as Firefox) as has no rules specified for it, it cannot browse the web server at 192.168.1.1. Nor can it browse this server if I permission it individually to allow access to specific servers other than 192.168.1.1.

But as soon as I create any rule for Firefox that allows it to browse web servers without specifying a remote address, then suddenly, Firefox can browse this "presumably blocked" web server regardless of the rules that from the nomenclature used to describe them would appear to be blocking it from doing so.

Testing seems to confirm this.

If this is by design, then how do I establish a rule that denies all traffic to/from all applications to/from a specific address, without specifically denying each application that is specifically permissioned with it's own rules?

Second part...

What is a "System" rule, as opposed to a rule that fits in the other two categories (app specified, and no app specifed)? Are there certain processes with Windows that return "System" as the "application name" to which these rules apply, or does the name "System" convey that they are applied differently?

(Now for the grouse... why isn't this stuff documented so that technical staff who are responsible for configuration and support can do something besides "guess" about how it works?)

Thanks,

 

You seem to have the same kind of questions than me... The problem is that nobody seems to want to answer to technical question here.... The will answer simple questions, but nothing else... I think I will go with another compagny.

 

I had an answer for this.... The applications rules take priority over the "all applications" rules.

So... there is no easy way to block a specific IP for all apps...

But, why would you need to do this?...

 

It's not so much every I would want to block all access to/from a particular IP , but that I would want to set up some "global" rules that block access to a particular port at all IP's (and then if circumstances dictate, permission an "allow" for the trusted zone).

For Example:

In my corporate environment, I have a mail server (actually, Exchange).
Policy dictates that all users must utilize our server for all business related email.

So hypothetically, I might want to establish a rule in the rule set that says all traffic to any IP/port 25 is denied (especially as so many exploits attempt to spam from the workstation). Alternately were I not using Exchange, I might want to establish a rule that says any attempt to access any IP/ port 25 not in the trusted zone is denied (and exclude the legitimate mail relay from that rule).

Now let's say I install a new browser. As long as I don't need to permission it specifically, we're fine. But the moment I permission it specifically, the whole thing breaks down. Regardless of what permissions I were to give it, I STILL don't want it to be able to talk to any mail server (probably not even my own, actually, if I had one). Nor do I want any widget or add-on that installs under it to have access to any IP/port 25, either. But if I have to replicate this (and every other global rule) every time I permission a new application, then the whole thing is a house of cards. And the moment I have to let a user switch to interactive mode - why, I'm better off without it installed.

Consider another example - I see no reason at all why any machine in my zone should ever try to open or allow a connection to NETBIOS for any machine not in the trusted zone. And that applies to every application on the machine, both those installed now and any that might be installed later. Again, permissioning an application to be able to connect to an IP at port 80 shouldn't in anyway permission it to open a NetBios connection, which the current ruleset configuration essentially does. (Assuming of course that the questions I need answered don't contradict what I currently understand to be the case.)

Does that make sense?

 

Seems to be complicated for nothing...

If you use policy-based mode, everything without a rule will be blocked, so there is no need for block rules...

So you set ess in policy-based mode and you just make specific rules for the apps... Let's say firefox, you make one rule with firefox, any ip, and 80 as the remote port... You also make a second rule, with the IP of the mail server and the port 25 as remote... So firefox will be able to connect to everything to port 80, but won't be able to connect to port 25 unless it it to the ip you specified...

Everything else will be blocked... unless you create other rules!...

 

I just don't see the need for block rules in policy-based mode since everything without rules is blocked... So I use the policy-based mode and some "allow" rules...

 

I understand what you are saying about policy mode. If I knew exactly what each application that each user was going to use needed, and where the application was going to be installed, and enough warning that either was going to change that I could ensure that I had the rule set created and downloaded to their machine in advance to permission it, it'd be a done deal and I wouldn't be agonizing over this.

(( Which come to think of it, is more or less what interactive is when I use it on my own system -except that I'm applying the expertise on the fly if you will. ))

The problem is that I can't actually run most workstations in policy mode, because end-users end up needing to be able to permission SOME things themselves (because applications update, and servers change etc.) - and in order not to hamper their ability to perform their work (or mine!) , I have to set many (most, actually) of them to interactive mode.

Which is where the block rules come in. Just because I need to allow them to permission a new app for something, doesn't mean I don't want to block the things that I know darn well I don't want them to do with it.

The problem is that the configuration of the rule set doesn't translate well from a single user/single system environment to a single administrator/many systems with many different configurations well.

And add in the fact that anything more technical than "where's my password?" just don't seem to "have answers", and it's been frustrating.

TTFN.

 

I didn't thought about those issues... Then you are right... I don't know how you could do that.... I will think about it for a day or two... If I find something, I will let you know!

 

Hello K12RS,

For browser restrictions, you may want to look at the "web access- Address management".

The system service for netbios, with default rules is restricted to the trusted zone. It is not an open rule that can be used by any other 3rd party application.

- Stem

 

Sigh.

Ok, so that we don't get off track, let's forget I said browser - I don't install a new browser.

Let's say instead my user installs a new application widget provided by a business partner that allows them to securely download reports from their servers, one that needs permission to access to a dynamically allocated port on a number of Internet based servers, both server and port which might change from request to request, and which I don't have (and can't get) a comprehensive list of.

(This by the way is not an "example" - it's actually what happens. Trying to substitute examples seems to be confusing the issue to no end)

I STILL don't want this application to "surprise" me by making a connection to a mail server (somewhere) - or to be ABLE to make an unexpected connection to ports 135/137/138 on any machine (either local or remote) - or make it possible for my user's to inadvertently permission it to do so.

Am I the only one who sees this as an issue?

Or is there something I'm just not getting about this?

TTFN

 

If you need to manage a lot of pc's, the only way would be to use the policy-based mode... If you use the interactive mode, you won't be able do what you want...

It's a choice between trusting users and full security....

 

You placed the tracks in your first post, so please forgive me thinking your first post was what you meant.

It is possible to make some predictions. For example with the "widget provided". it will not collect reports from netbios ports.
Could it also be predicted that the reports will not be retrieved via e-mail?


If those 2 predictions are true, then you could set a policy of "automatic with exceptions"


Example:
Set rules to allow specific e-mail clients to collect/send mail
Set rules to block all remote ports for e-mail

Any program installed will then be able to make all outbound for dynamic IP/Ports, but will be blocked from the remote e-mail ports. The only problem would be if the user created specific rules, but that would not be needed unless the application needed access to those restricted ports.

Similar rules can be made for other ports.


- Stem

 

Thank you, Stem.

That seems to be a valid way to address the issue, although it removes the valuable component of an application is (essentially) "denied until specifically permissioned" aspect of the firewall.

But it would definately solve this particular problem.

Thanks!

 

Hi K12RS,

Whichever type of firewall is installed, be it rules(order) based, or Policy(priority) based as with ESS, you lose such control due to unpredictable installs and unpredictable port/IP access needs of those installs that you put forward as needed.

- Stem