enterprise console 5.1 - view firewall logs remotely?

Hello Neon,

didn't have time to complete this post earlier but wanted to add some remarks.

Centrally deploying firewall settings is a challenge, regardless of the product you use.

My goal is to make as few policies as possible

That's a good idea. But then you wouldn't necessarily reach this goal (quicker) by combing through dozens of logs for individual workstations. Agreed, it is handy for troubleshooting - but this is not the same as setting up a comprehensive policy in the first place.

Trusted LAN (full trust inbound and outbound) [...] I don't think this is good layered security.

What constitutes a layer is defined by the way you look at it - and even within a specific frameworks the layers and their meaning are in practice not always clearly differentiated. Thus the meaning of LAN is also not unambiguous. Furthermore you have to be pragmatic - of course you could assess all connection attempts on what you define as your local LAN. Then you'd have to understand what they are for and whether they are necessary or not. If you look at the Windows Firewall settings (Win7/2008) you'll get a picture of the task. Now you could try to understand and recreate or transcribe all these settings.

If you're thinking about protecting an endpoint from other endpoints on the LAN - look at it this way:

1. all your endpoints on the LAN (should) have adequate AV/HIPS protection 
2. if an unknown threat nonetheless gets in and it's trying to write itself to shares it will be able to do so if you (have to) allow NetBIOS
3. if the threat manages to subvert the system or a trusted application it will be able to use the connections allowed for these   
4. if attempts some other connection it will be blocked as unknown application so it won't be able to connect even if the LAN is marked as trusted

It might therefore not be reasonable to put significant effort into developing a large and complex set of rules for your LAN (again, LAN could be your entire network if it is small and rather homogenous, one or more subnets, or select addresses) but instead marking it trusted - the difference being between pretty open and wide open. You still have checksumming as well as AV and HIPS.    

IMO good layered security is not each layer tuned to the max but a balanced concept which

• ideally covers the full spectrum of threats
• implements protection where it's most effective (and efficient)
• complements protection on other layers
• provides a fail-safe where feasible
• and, last but not least, is manageable

Thus no client firewall is a replacement for a perimeter firewall. OTOH something like checksumming can only be done on the client. As you shouldn't put all your eggs in one basket a combination of both is best but even this won't give you complete security. I'd rather trust the LAN than pass on checksumming - the challenge is to factor in (the recommended) automatic updates and there OS updates in particular. You don't really need access to an individual client's logs for this though.

As final remark: Ever wondered why there is no Sophos firewall for servers? It's not that they wouldn't have the smarts to come up with one. For one thing, it wouldn't make much sense to protect the servers with a general profile. Simple management and particular (and granular) settings are a contradiction. For the same reason you shouldn't concentrate too much on individual clients (though that's not to say that SEC shouldn't provide some more details and a better interface in the Event Viewer).

Christian

Hello Neon,

didn't have time to complete this post earlier but wanted to add some remarks.

Centrally deploying firewall settings is a challenge, regardless of the product you use.

My goal is to make as few policies as possible

That's a good idea. But then you wouldn't necessarily reach this goal (quicker) by combing through dozens of logs for individual workstations. Agreed, it is handy for troubleshooting - but this is not the same as setting up a comprehensive policy in the first place.

Trusted LAN (full trust inbound and outbound) [...] I don't think this is good layered security.

What constitutes a layer is defined by the way you look at it - and even within a specific frameworks the layers and their meaning are in practice not always clearly differentiated. Thus the meaning of LAN is also not unambiguous. Furthermore you have to be pragmatic - of course you could assess all connection attempts on what you define as your local LAN. Then you'd have to understand what they are for and whether they are necessary or not. If you look at the Windows Firewall settings (Win7/2008) you'll get a picture of the task. Now you could try to understand and recreate or transcribe all these settings.

If you're thinking about protecting an endpoint from other endpoints on the LAN - look at it this way:

1. all your endpoints on the LAN (should) have adequate AV/HIPS protection 
2. if an unknown threat nonetheless gets in and it's trying to write itself to shares it will be able to do so if you (have to) allow NetBIOS
3. if the threat manages to subvert the system or a trusted application it will be able to use the connections allowed for these   
4. if attempts some other connection it will be blocked as unknown application so it won't be able to connect even if the LAN is marked as trusted

It might therefore not be reasonable to put significant effort into developing a large and complex set of rules for your LAN (again, LAN could be your entire network if it is small and rather homogenous, one or more subnets, or select addresses) but instead marking it trusted - the difference being between pretty open and wide open. You still have checksumming as well as AV and HIPS.    

IMO good layered security is not each layer tuned to the max but a balanced concept which

• ideally covers the full spectrum of threats
• implements protection where it's most effective (and efficient)
• complements protection on other layers
• provides a fail-safe where feasible
• and, last but not least, is manageable

Thus no client firewall is a replacement for a perimeter firewall. OTOH something like checksumming can only be done on the client. As you shouldn't put all your eggs in one basket a combination of both is best but even this won't give you complete security. I'd rather trust the LAN than pass on checksumming - the challenge is to factor in (the recommended) automatic updates and there OS updates in particular. You don't really need access to an individual client's logs for this though.

As final remark: Ever wondered why there is no Sophos firewall for servers? It's not that they wouldn't have the smarts to come up with one. For one thing, it wouldn't make much sense to protect the servers with a general profile. Simple management and particular (and granular) settings are a contradiction. For the same reason you shouldn't concentrate too much on individual clients (though that's not to say that SEC shouldn't provide some more details and a better interface in the Event Viewer).

Christian