Endpoint Protection

I'm trying to figure out how I can essentially disable all other adapters except the adapter that is connected to a network to ensure that the computer in question can only be connected to a single network at any given moment.  The concern is if the computer is connected to the corporate network and at the same time connected to a rogue wifi AP or a cellular network (EVDO).  If connected at the same time there is potential for a bridge connection to be established.

At first my plan of attack was to simply write the firewall rules to only allow traffic to/from the corporate network once a connection to the corporate network was established.  However, this would require writing generic rules based on subnets/neworks.  However, if the user is connected to a corporate network with a 10.10.10.x network via a wired connection and also connects to a wireless AP or via EVDO and gets a similar network addressing scheme, in theory that traffic would still be allowed to/from the machine to that secondary network.

Does SEP have the capability to disable all other network adapters (regardless of what type - wireless, USB, ethernet, etc) other than the connection that is currently connected?

Have you tried doing the following in your FW config?


To add a network adapter to a rule

In the console, open a Firewall Policy.

See Editing a policy.

On the Firewall Policy page, click Rules.

On the Rules tab, in the Rules list, select the rule you want to edit, right-click the Adapter field, and then click More Adapters.

In the Network Adapter dialog box, do one of the following actions:

To trigger the rule for any adapter, even if it is not listed, click Apply the rule to all adapters, and then go to step 8.

To trigger the rule for selected adapters, click Apply the rule to the following adapters, and then check the check box in the Enabled column for each adapter that you want to trigger the rule.

To add a custom adapter for the selected rule only, click Add.

In the Network Adapter dialog box, select the adapter type and type the adapter's brand name in the Adapter Identification text field.

Click OK.

Click OK.

Click OK.

Let me know if this was helpful,
Thomas

We can limit FW rules based on adapter, yes, but how can you identify WHICH adapter is connected first and then block all others?  The scenarios are endless, the user can connect via wireless first or ethernet first or EVDO first or USB ethernet adapter, whatever, the goal is to allow the first connection/adapter and then block all the rest.   The rule above assumes you know which adapter is being used in the first place.

This is going to be difficult to implement if your network is dynamic. If you have a public class B or C, for example, you can do a generic fwall block rule that allows traffic to your corporate network and block everything else. I.e., don't do it on a hardware level (adapters), but do it on a network layer (fwall/protocol). 

 
I've thought about the network layer but the scenario still exists that you could have another adapter connected to another network with a similar IP scheme and if the FW rules are based on IP addressing/resources it will allow the traffic to the other network.  

If you're running private IP addressing internally, then you are screwed. If you're running a public IP address block, then it may work. Here's how I'd approach it:

- Create a location called "Internal Wired, Protected" and specify the following conditions:
1. If system connection type is "Ethernet" AND
2. If system has one of the following addresses "1.2.3.4/255.255.0.0"
where address in quotes is your publically-accessible IP range

- Create a fwall rule assigned to this location that has the following:
Rule 1: Allow any to any using Ethernet adapter
Rule 2: Block any to any using any adapter 

Both fwall and location rules and conditions are from my memory, exact wording is probably different, but you should get a general idea. What you're doing, in an essence, is allowing only Ethernet adapter (Wired) with your particular IP to go out; everyone else will get dropped using fwall rule.
Now, if you want to enable wireless access that's on the same public network, you'll need to create another locationc called "Wireless, Protected" and do the same steps as above, substituting connection type to either "Wireles" or utilizing "Wireless SSID is" condition. Again, the more dynamic your network is, the harder it gets.
Lastly, Symantec in its infinite wisdom, considers VPN connections to be Ethernet connections. This applies to Checkpoint, Cisco and PPTP VPNS, and if you have a condition "Connection type is Ethernet", VPN connections will be treated as Ethernet and appropriate policies applied, even if you specify a NOT clause that explicitly states "AND Connection type is NOT PPTP". In this case your PPTP VPN connection will be still treated as an Ethernet. Just a friendly warning.
:-)

Unfortunately EVDO networks are considered ethernet as well.  And to confirm, yes, I'm talking about private IP addressing.

You're SOL, sorry.
The only option is to use DEVVIEW.EXE or whatever the tool that scours the registry and gets the list of all hardware adapters, and block/allow them via WMI and/or VBS.
If you're lucky and you're using relatively similar hardware across your enterprise, this might just do the trick. Lots of work, though. 

 
That's a LOT of hardware ;-)

Interesting.  That would be a nice feature to add to have the option only to allow a single active connection (IP based) blocking any other Internet/network connection regardless of adapater type (now network adapters could be just about anything - modem, bluetooth, wired, wireless, EVDO, etc, etc).

What you want is to be able to disable bridging. It's a limitation of WMI, really, as it's very difficult to query a status of all adapters, identify one with your "allowed" IP and dynamically block the rest. This becomes impossible when you're using private IP addressing because things like VMWare may be using your address space already, and then your entire policy you worked on for days goes out of the window.
Ask me how I know. 

Even without the use of bridging, a client machine could still be compromised via an open connection (EVDO) and then ultimately once the machine is compromised, the other network connection is available to the attacker. 

To solve this issue I created different locations.

The trick is to fix the

Trust location ethernet (this location disabled all adapters but ethernet)
Untrust location ethernet (this location disabled all adapters but ethernet)
VPN connection ethernet (this location disabled all adapters but ethernet)

Trust location WiFi (this location disabled all adapters but WiFi)
Untrust location WiFi (this location disabled all adapters but WiFi)
VPN location WiFi (this location disabled all adapters but WiFi)


The trick to make it work is to have good triggers for the different locations but it is definately possible (it works fine for us)

I'm curious how in the scenario described you resolve the issue of two possible things:

1) In your trusted ethernet location, how do you solve a client from having 2 physical ethernet connections and being connected to 2 different networks hard-wired?  Out there but possible.  

2) More likely, with EVDO cards being recognized as ethernet, in the above scenario, what were your rules to actually prevent a hard wired connection and a EVDO connection simultaneously when they are both recognized as ethernet?

Answer to questions:
 
1) Since we only have the firewall enable on notebooks we do not have the problem with 2 physical ethernet connections at the same time. However you can customize the location rule by using the physical device id from windows. This might be a problem if you have many different brands of network adapters (could be quite a list of adapters to add to the allowed rule).

2) I have one notebook with EVDO that even though it is found as ethernet do still work with this simple rule (it could of course be different between brands and drivers.) As mentioned above you can always specifically allow only a special kind of device ID (network adapter) and disallow all other. 

Editing and deleting custom network adapters
You can edit or delete any custom network adapters that you have added. You cannot edit or delete a default network adapter. Before you can delete a custom adapter, you must remove it from all the rules that reference the adapter. The settings that you edit change in all rules that reference the adapter.

To edit a custom network adapter

In the console, click Policies.

Under Policy Components, click Network Adapters.

In the Network Adapters pane, select the custom adapter you want to edit.

Under Tasks, click Edit the Network Adapter.

In the Network Adapter dialog box, edit the adapter type, name, or adapter identification text.

Click OK.
___________________________________
To get the device id of a network adapter -> Open Device Manager -> Network Adapters -> choose the correct adapter -> Properties -> Details -> Device Instance Id -> Copy (PCI\VEN_....) the string to the rule in SEP.

You can also get the string from the registry. Under this key: {4d36e972-e325-11ce-bfc1-08002be10318}