topic Re: Large User-ID Deployments in General Topics

Large User-ID Deployments

steveo — Thu, 19 Apr 2012 21:27:20 GMT

All,

We're in the process of migrating from a WCCP Proxy implentation for URL filtering to the Palo Alto solution (LOTS of work needs to be done obviously!) and we're starting to work with the User-ID Agent and have some questions..

First, I'm curious how large of User-ID implentations are out there user wise? We have about 16k users system wide, anyone out there with that many or more? Using AD? What agents are you using? How many AD servers, and Agent servers?

Anything we should be aware of with a large install like this?

I'm also curious about how you handle devices that won't have a user associated with them, something like an IV Smartpump, we're a healthcare org so we have TONS of devices like that in the wild..

Thanks much!

-Steve

Re: Large User-ID Deployments

mikand — Fri, 20 Apr 2012 07:22:40 GMT

Regarding your second part...

Is it possible for you to place those IV Smartpumps etc on their own VLANs and then tag these all the way to your PAN (these devices should already be on their own segments since many of them can be considered to be SCADA like systems meaning most likely vulnerable along with few updates to protect themselfs)?

That way you could setup these VLANs as their own zones (or the same zone but block intra-zone communication) and apply their own (most likely more limited) security profiles compared to your regular linux/windows clients. For example only allow specific urls and such.

Otherwise if your devices can login to your AD they can be recognised by other methods such as WMI, Netbios etc. Another method is if they can auth against your Exchangeservers which then will be able to notify your PAN device who is using the current ip. Personally I would still prefer the VLAN method (given that you use protected vlan so the devices cannot spread bad things between themselfs and private vlans on all L3 nodes so the IV-VLANs isnt automagically routed to your other VLANs).

Re: Large User-ID Deployments

steveo — Fri, 20 Apr 2012 15:31:15 GMT

Yes, non-PC type devices typically are on their own subnet, but they wouldn't really have their own zone since they all reside behind trusted like the rest of our inside network.

As far as the PA goes is there a list or something that either says 'These networks/IPs enforce User-ID checking' and the networks that aren't listed won't enforce it, or the other way around where we say 'These networks/IPs do not enforce User-ID checking' but everything else do enforce.. ?

Does that make sense?

Thanks!

-Steve

Re: Large User-ID Deployments

Jeff_K — Fri, 20 Apr 2012 18:38:42 GMT

Yes, you can write security policies as you describe.

We're running over 30 User-ID Agents (version 4.1.2). They're collecting AD account logon information from the security logs of our Windows domain controllers. We found it best to place one (or more for redundancy) at each site ... they can consume a considerable amount of bandwidth if you have an agent monitoring a domain controller over a WAN link.

We have yet to address the many wireless devices in our company that do not log on to our Windows domain ... Android phones and tablets, iPads, warehouse barcode scanners, etc. The plan is to glean user/IP information from the RADIUS MS-PEAP authentication records and feed it into the User-ID Agent using it's API support.

Jeff

Re: Large User-ID Deployments

ucteam — Sat, 21 Apr 2012 04:25:46 GMT

Enviroment I've worked on:

13k+ active users (expected to double in the next couple of years)

120+ domain controllers

180+ remote sites with WAN links varying from 4Mb - 10Gb

Centralised internet gateway

Very dynamic network, sites been mobilised/ demobilised usually on a monthly basis

My opinion its great for large centralised and static enviroments.. were all you users are in a central location... However if you have a large disparate or spread out enviroment you might hit some issues with some of the undocumented limitations of the UserID agents/ architecture.

-Each firewall can only talk to a maximum 100 userID agents

-Each agent can only monitor a maximum of 100 domain controllers

So if you have more than 100 DCs you CANT just push an agent out to all of them so that sec logs can be locally read and user-ip maps sent to FW..

Or the other way if you wanted to use a central agent to monitor multiple DCs (which unfortunately tends to generate alot of traffic across the WAN).. then you would need to install a minimum 4 agents servers.. (ie. 2 agents cos single agent can only monitor max 100dcs.. and another 2 needed to provide redunadncy)

I really hope PA will increase these seeminly arbitrary limitations in the near future..

(amazinly the older agent by "default" would only let you connect to a max of 10 domain controllers... you'd have to edit a xml config file to get them to talk to more.)

Some recommendations

As PA recommend.. whatever your primary authentication method, it's usually worthwhile setting up captive portal/ NTLM auth as fallback authentication mechanism for any web users/ clients which slip through the cracks. Just be aware when setting up for NTLM authing that some browsers (e.g firefox) require manual configuration in order to support NTLM.. and they also maintian their own separate list of trusted RootCA's i.e they dont refernce the local windows certificate store (which you might be updating via grou policy etc)... so firefox users might get cert warnings when hitting the CP/NTLM redirect.

Regarding you IV Pumps/ or SCADA style equipment, if you do already have these devices in dedicated VLANs but you cant trunk them all back to central layer 3 interface to push them through a dedicated interface/ zone on the firewall natively... you can potentially virtualise your network at a layer 3 level. Utilise a combination of VRF or VRF-LIte to create a separate virtual layer3 network instance and you could use mGRE or IPSEC/VTI to tunnel this traffic across your regular network back to a central interface connect through the firewall providing complete network isolation for your sensitive devices and then... apply appropriate policies on that zone/interface.

Otherwise yes as you mentioned it is possible to put a non-authenticating policy before your standard user web browsing authetnicated policy.. and as long as you specifying the trusted destination which can be accessed without authentication this could be considerded an acceptable level of security (depedning on your risk model). Which you could also further secure by creating a custom application signature and only allow the specifically required type of traffic. I find this suitable for things like printers etc that want to phone home across the net to their vendors to order more consumables or notify of problems etc.

e.g

Permit

***FROM***

src = 10.0.0.0/8 (be specific if you can.. but dont have to)

user = any (ie. dont require authentication)

***TO***

dst = 1.1.1.1/32 ( be specific)

port = TCP 577

App = IVPUMP (create custom app signature)

I believe Cisco's got big whitepaper on TrustSec/ NAC 2.0 style stuff spefically focussed on medical enviroments which may be of interest to you

http://www.cisco.com/en/US/docs/solutions/Verticals/Healthcare/bnac_adg_2.0.html

As already mentioned if you do implement a NAC solution these devices will be authenticated automatically by the NAC system (by profiling, eap or MAC address etc), you can then plug into these systems using syslog and the extensibile UserID api to get that auth information to the firewall. Enterasys has whitepapers out on doing this with Palo Alto currently, but should work for most any standard system.

Re: Large User-ID Deployments

steveo — Mon, 23 Apr 2012 18:15:25 GMT

Thank's much for the detailed response, very helpful! As far as having separate VLANs for IV Pumps,etc, they, and many other VLANs like them are in place across our network with each site being unique so it probably wouldn't be feasible doing what you mentioned..

Good ideas though!

Thanks again!

-Steve

Re: Large User-ID Deployments

ucteam — Tue, 15 May 2012 22:47:13 GMT

Oh yeah I should have mentioned.. depednding on your configuration you might have to exclude these IVPump/ SCADA devices from your captive portal policy (if you use CP for fallback authentication).

This exclusion can be done based on source ip/subnets or destination ip/subnets and protocols.