Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 1 subscriber
  • Views 2603 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Getting firewall to work right, is there an easy way?

DSM1

I am testing firewall setting, I come from a Cisco mc and csa agent background where basically the console see's what each client is doing that is blocked by user PC, etc, and I can create rules and exceptions around this to allow things. I can't really find a good way to set this up, is there a firewall basics? I have tried to set up where the agent can allow, (2 steps, is a pain for some users they don't know what to do) so we are trying to baseline this, but it does seem to relay to the console for me to approve or use as a base line. It was suggest I baseline and agent or a couple agents, and export the logs, then import them to the server, but this sounds really backwards since the console is suppose to be where you manage it all at.

Any one had any luck setting up the firewall to work properly, appears there are other posts about it it being nothing but trouble, to the extend of some using GP to manage windows firewall instead, is that what most are doing? I have allowed my remote untidily to run from the interactive agent, approved the exe in hips, but it still won't connect so loosing my remote capabilities to a client is a no flyzone for me. This is probably one of the major issues I need to resolve before I give the go ahead to consider it for purchase, and its seems like it doesn't function as it should or documentation is lacking.

Any suggestions.

:38861


This thread was automatically locked due to age.
Parents
  • 0

    Hello DSM1,

    it's already past the end of my working day - meanwhile, if you haven't already done so, please take a look at Best Practice: Firewall settings guide and referred articles (especially the Administrator roll-out guidelines for Sophos firewall version 2.0 - but just for information, please read details below). Time permitting I'll post a more detailed reply tomorrow. It is tomorrow - I'll append here.

    It's hard to adapt to the look and feel and processes of a competitor product (which also might or might not be equivalent to the one you're used to). You didn't say which features you used before and which you intend to use. E.g. process verification (aka checksumming) while very useful can be a pain in conjunction with automatic updates. So no details for now, just an outline.

    A few basics about SCF first. As you mange your computers in groups they (and their use) should be as identical (on the application level) as possible. There are no per-machine or per-user policies. One way to work around this (if you trust your users and intend to give them the firewall as a "tool") would be setting the mode to Interactive. But permanently changing the configuration on a machine requires sufficient user rights, in addition you may neither touch the policies not move a computer to a different group - not feasible except for very special endpoints and their users.

    Endpoints do send the events to the console and you can use the Event Viewer to create rules from them. This is fine for a small number of (occasional) events. It has no "intelligence" though - i.e. you neither see which events you've already dealt with and created rules from nor does it correlate events in any way - and it doesn't give you the option to mark, hide or delete events.

    Firewalls (not SCF in particular) can be and are very complex and their configuration is not a simple task - one easily doesn't see the wood for all the trees. It's a good idea to define a concept (how does it fit into your network - you likely have a firewall and/or access lists, what's its main task - protecting desktops and/or roaming laptops, restricting applications ...) and make a staged approach.  

    Now to the doing 

    export the logs, then import them to the server

    It's not the logs, it's the configuration (in SCF speak). This is  should be Method 1 (the preferred one) in the roll-out guide. Personally I think it isn't as easy as it seems from the description. The mentioned setting does not create any rules on the endpoint - it does send events to the console though - you'd have to consult the logs on the endpoint for creating the rules (and collecting the checksums) and this would be a pain. Instead I'd recommend Interactive (what you called where the agent can allow) which enables you to immediately create a rules from events. Perhaps this is what should be under Method 1 ... I'm not sure. Anyway, the last step would be exporting the configuration an importing it in SEC:

    There are some pitfalls - e.g. what constitutes the LAN (which is implicitly used by certain default settings). SEC applies what it considers the LAN, in case of a segmented network this could be just the server subnet and not the address range you expect. Another one s the order in which rules are applied (there's a section in the Help).

    As to your remote problem - if it doesn't work the log should tell you why it has been blocked (although it might be hard for a "beginner" to interpret the reason - but feel free to ask).

    Christian

    :38867
Reply
  • 0

    Hello DSM1,

    it's already past the end of my working day - meanwhile, if you haven't already done so, please take a look at Best Practice: Firewall settings guide and referred articles (especially the Administrator roll-out guidelines for Sophos firewall version 2.0 - but just for information, please read details below). Time permitting I'll post a more detailed reply tomorrow. It is tomorrow - I'll append here.

    It's hard to adapt to the look and feel and processes of a competitor product (which also might or might not be equivalent to the one you're used to). You didn't say which features you used before and which you intend to use. E.g. process verification (aka checksumming) while very useful can be a pain in conjunction with automatic updates. So no details for now, just an outline.

    A few basics about SCF first. As you mange your computers in groups they (and their use) should be as identical (on the application level) as possible. There are no per-machine or per-user policies. One way to work around this (if you trust your users and intend to give them the firewall as a "tool") would be setting the mode to Interactive. But permanently changing the configuration on a machine requires sufficient user rights, in addition you may neither touch the policies not move a computer to a different group - not feasible except for very special endpoints and their users.

    Endpoints do send the events to the console and you can use the Event Viewer to create rules from them. This is fine for a small number of (occasional) events. It has no "intelligence" though - i.e. you neither see which events you've already dealt with and created rules from nor does it correlate events in any way - and it doesn't give you the option to mark, hide or delete events.

    Firewalls (not SCF in particular) can be and are very complex and their configuration is not a simple task - one easily doesn't see the wood for all the trees. It's a good idea to define a concept (how does it fit into your network - you likely have a firewall and/or access lists, what's its main task - protecting desktops and/or roaming laptops, restricting applications ...) and make a staged approach.  

    Now to the doing 

    export the logs, then import them to the server

    It's not the logs, it's the configuration (in SCF speak). This is  should be Method 1 (the preferred one) in the roll-out guide. Personally I think it isn't as easy as it seems from the description. The mentioned setting does not create any rules on the endpoint - it does send events to the console though - you'd have to consult the logs on the endpoint for creating the rules (and collecting the checksums) and this would be a pain. Instead I'd recommend Interactive (what you called where the agent can allow) which enables you to immediately create a rules from events. Perhaps this is what should be under Method 1 ... I'm not sure. Anyway, the last step would be exporting the configuration an importing it in SEC:

    There are some pitfalls - e.g. what constitutes the LAN (which is implicitly used by certain default settings). SEC applies what it considers the LAN, in case of a segmented network this could be just the server subnet and not the address range you expect. Another one s the order in which rules are applied (there's a section in the Help).

    As to your remote problem - if it doesn't work the log should tell you why it has been blocked (although it might be hard for a "beginner" to interpret the reason - but feel free to ask).

    Christian

    :38867
Children
No Data