Endpoint Protection

Hi

According to Symantec (See KB below) the default FW rule "allow all applications" should allow only traffic initiated from the client, and block communication initiated from the outside. But after testing it seems like this is almost like putting the fw in pass-through as all communication from the outside is also allowed.

For example: I activated the Utorrent webgui over custom port 666. If this rule only allowed communication from the inside and out. Shouldn't access to the website be blocked if tried accessed from another machine?

I only have this rule activated / Allow all IP and other default policies are disabled.

http://www.symantec.com/business/support/index?page=content&id=TECH102745&actp=search&viewlocale=en_US&searchid=1295466007521

Torb

As I understand it, a stateful firewall will allow inbound communications that are a response to an outbound request.

For example: I activated the Utorrent webgui over custom port 666. If this rule only allowed communication from the inside and out. Shouldn't access to the website be blocked if tried accessed from another machine?

Access to a website URL is not dependent on the firewall rule.  Probably you're using a web browser (Firefox, IE, etc.) to access the web GUI. I don't understand what another machine has to do with it.  If another machine tried to access the same web GUI with the same firewall rules, it would be allowed, too.

There are ways to block URLs with the SEP firewall by way of restricting to approved websites.  For example:

How to Restrict Users to Specific Web Sites by Creating Firewall Rules for Managed Clients
http://www.symantec.com/docs/TECH92097

(SEP's NTP is not really intended to be a web content filter.)

sandra

It's just an example to test the rule.

The Utorrent WebGUI is a service running on machine A on port 666.

IF machine B connects to Machine A on port 666 shouldn't it be blocked?
(Machine A doesn't initiate the connection)

Since Symantec policy says that the "Allow all Applications" only allows all applications outbound, but not inbound.

I believe that the "Allow All Applications" will allow every single application on machine A that has an open port to get accessed from Machine B.

Any comments?

Machine A runs an application that allow connection on port 666 (in this example Utorrent Webgui service that runs on custom port 666)

So are you saying that this is actually occurring with the "allow all" rule only in place?  Does turning on all logging lend any insight?

If you are interested in blocking specific applications and ports, I would not rely on an "allow all" rule to do it ;)

sandra

I am interesting in finding out if the KB article is correct or not.

http://www.symantec.com/business/support/index?page=content&id=TECH102745&actp=search&viewlocale=en_US&searchid=1295474505678

The above is just an example.

What i was thinking (if the rule works as mentioned in the KB)

For Clients

Rule 1: Allow all connections to/from Server subnet (This enables Remote tools, sw deployement etc)

Rule 2: Allow all applications on the Client to initiate an outbound connection, but block inbound connections (unless statefull packets initiated from the client). Little configuration on the client, but blocks other clients that are not servers to initiate RDP/netshare etc to the client..)

I understand what you are saying, I would expect the uTorrent port to not be accessible remotely in that situation as well. 

Maybe part of the confusion could be in the difference the implicit behavior the SEP firewall uses between the Local/Remote and Source/Destination designations.  Notice how the article mentions “If the Source/Destination option were selected, all inbound traffic would be allowed”.  I don’t know if you’re using the default Local/Remote setting but that could possibly present a source of confusing results.  If you go to page 445 of the Admin Guide, like the article mentions, it explains the difference between the two methods pretty well (note this is the RU5 admin guide version not RU6A).

But I would rather not rely on implicit behavior of the Local/Remote being outbound only and Source/Destination being inbound.  For me, that is too “automated” when working with something like a firewall.  I prefer to explicitly define the traffic patterns in the rule set rather than trusting implicit behavior.  This is also a best practice to add a rule blocking all traffic in both directions at the bottom rather than relying on an implicit deny all like in a Cisco ACL (as the default firewall rule correctly does).  This is perhaps more management overhead but for me it is more clear and there is less chance of a confusing traffic situation happening, like the uTorrent thing. 

When working with the SEP firewall I find the Local/Remote concept to make sense overall but, coming from a typical perimeter firewall background, for me it is more intuitive and less prone to error to standardize everything on Source/Destination. 

So my recommendation would be to ditch the default firewall policy, create a new firewall policy to use as a base, and make copies of the base as needed to add traffic based on your needs.  The base policy could have a “block all” rule at the bottom, an “allow IP outgoing” rule above that, and a “block IP incoming” rule at the top.  The stateful firewall will allow all applications like web browsers and email clients to work, and you can add other “allows” near the top for remote access, icmp, etc.  Many of the default firewall rules can be copied to your new policy like the ping, IPv6 stuff and fragmented packets. 

Hope this helps.

Thanks for the followup Clamu.

The symantec KB is infact  incorrect. I tested it more and it do allow all traffic both inbound and outband.

To fix this I modified the Service list in the rule to only allow outbound traffic.
Now the rule works as intended.

My rule set is now:
One rule to allow all traffic out from the clients(statefull). And one rule that allows all server communication inbound.

Torb