User ID | Palo Alto Firewall Training

modern firewalls have come a long way they don't just allow and block traffic based on ip addresses and port information anymore among other things firewalls can filter traffic by checking who you are and what groups you're in in a palo alto firewall this is called user id and we're going to see how this works traditional firewalls look at ip addresses and ports and will allow or block traffic based on that generally applications were allowed based on the port they would use and users were allowed based on their ip addresses for a while now we've had next-gen firewalls they can permit or deny traffic based on a larger range of information like application and user information on a palo alto firewall the user id feature collects usernames and group membership from your network we can then create security policies to control traffic based on that let me show you what i mean we might have an active directory domain that contains all of our users and groups we then create a group of users who are allowed to access webmail a security policy references this group and allows webmail applications for these users while the rest are denied this is handy as other rit staff can update this group without needing to get us as the security administrators involved there are three primary advantages to this approach we can see if a particular user is using risky apps or if a user is doing something they shouldn't we can control access to resources based on users and groups as well as limiting the transfer of sensitive data and if there is a security incident we can find out which users were involved let's look at what we need to implement user id we'll look at how it works first and then we'll look at some configuration later the first part of the puzzle is collecting a list of users and groups in your environment this must be collected from a directory service such as active directory using ldap or an api this means that the firewall needs to authenticate with the directory service so you will need a suitable service account once we have a list of users the firewall needs to map traffic to those users it tracks source and destination ip addresses and aligns that traffic to a user this may sound simple but it can be tricky after all ips can be dynamic think of dhcp for example and on top of that a single user may have more than one device to cope with this the firewall has several methods of mapping traffic to users the methods that you use will depend on your environment the options available to you include integration with active directory and exchange or some other directory service if you have terminal services or citrix xenapp you can put an agent on each server you can display a captive portal to users when they try to access resources which requires them to enter a username and password if you have logins through radius the firewall can pass syslog messages for log on and log off events if you're using globalprotect that's clearly a place where a palo alto firewall can natively collect user information if there's a proxy server in your environment you can append particular headers to the http traffic as the traffic passes through the firewall it can read the user info from the headers and finally there's client probing where the firewall queries each client for user information however client probing is not a recommended approach anymore so all this is great but there is a catch as we've seen users are mapped to rp addresses if you have nat in your environment ips may be changed before the firewall sees them which can break user id keep this in mind when you're planning your deployment the firewall can use the server and security logs from a domain controller or exchange server to see who is logging on and from which ip addresses they're logging on from this is done with an agent there are two types of agent the first type is the windows agent which is installed on a domain member server it does not need to be installed directly on the domain controller or exchange server when a user logs in the domain controller logs this information the server agent periodically asks the servers for these logs which it uses to build a list of users and ip address mappings which it then sends back to the firewall for this to work each domain controller must be configured to log successful login events this can be combined with a feature called credential detection this detects whether corporate account details are being used to log on to specific websites however this is out of scope of our video an alternative to this is the panos agent it runs natively on the firewall this doesn't need to be installed it's just already there this follows the same principle as the windows agent it puts a little more load on the firewall but it's a bit simpler so it may be better for small networks if you have remote sites with domain controllers and exchange servers or you have multiple palo alto firewalls running user id you'll probably want to use the windows agent if you have terminal services or xenapp there's a different agent you can install on each of these servers the trouble with these type of servers is that there are multiple users but they all have a single source ip that is the ip of the server so when a user logs in this agent allocates a range of ports to the user and reports this back to the firewall all of that user's traffic will come from one of these ports so the firewall can then map the source ip and port combination to that particular user if you have users that aren't in a directory perhaps guests or local linux users you might consider using a captive portal this displays a web-based logon page when a user tries to access a network resource the user can authenticate here and will be allowed or denied access this is quite flexible and can incorporate single sign-on ntlm saml multi-factor authentication client certificates and more if you have a wi-fi deployment the controller will probably use radius to authenticate users what we can do here is configure the controller to send syslog messages to the firewall the firewall can then pass these messages for the logon and log off information and collect the user to ip mapping logoff information is included to keep these mappings fresh this isn't just limited to wi-fi of course it can be used for any radius or 802.1x enabled device as long as syslogs can be used we could run into trouble if we're using a proxy server for internet access why it's common for proxy servers to use their own ip addresses not the real ip of the client this would make it appear that all the users have the same ip address to resolve this issue the proxy server can be configured to add the x forwarded four header if you're not familiar with this this is where additional information is embedded into the http request the x forwarded 4 header contains the ip address of the original client when the request passes through the firewall the firewall reads this header to get the user to rp mapping for security this header can optionally be stripped out before sending the http request to the internet the last type of user mapping is client probing this uses wmi or netbios to query clients for information at regular intervals this is considered a legacy solution the other methods we've talked about should be used whenever possible instead this is considered legacy for two reasons first this can generate an unnecessarily large amount of traffic second it has potential to leak client information which is of course a security risk let's start preparing for our user id deployment there are three areas that we're going to look at in this section we'll think about the mapping methods that we'll use in our environment we'll look at the service account requirements and we'll see how to configure ldap to collect users and groups when selecting the methods that we want to use start by considering where the users are logging in from specifically think about the zones and subnets that the users are in are the users in active directory do you have some other directory service do you have linux servers with local accounts what about multi-actor systems do you have any terminal servers or xenapp services in your environment is radius or tacacs used anywhere this could be for administration for wi-fi for device authentication or something else if you're using radius is it integrated into active directory or is it standalone how do you access the internet is there a proxy server involved somewhere and remember finally to never use client probing next you will need one or more service accounts i use one service account for all tasks which includes ldap queries as well as the windows agent or pen os agent you may prefer to use a separate account for each task there are several permissions that need to be configured and assigned to the service account which are summarized here once the service account is ready you can think about ldap configuration this allows the firewall to collect user and group information from your directory service just remember this only collects a list of usernames and groups it does not map ip addresses to users yet there are two parts to ldap config an ldap profile and binding the profile to user id for our example we're going to configure ldap for active directory we can have up to four domain controllers in each profile to add a domain controller enter the name the ip address and the ldap port that you want to use the port is probably 389 or 636 depending if you use regular ldap or secure ldap if you're using secure ldap make sure you enable it with the box at the bottom on the right we select the type of directory service we're using which is active directory in this case you need to put in the base tn which is part of the ldap query this is a path to where the users are within the domain this could point to the root of the domain or to a specific ou the bind dn is the service account that you created earlier this can be entered in the domain username format or as a upn like i have done here you can change the timers if you want but generally it's best to leave them as they are now we have the profile we can map it to user id with group mapping for the most part i leave these settings as default only specifying the ldap profile and making sure it's enabled the user domain for example can be automatically detected but if we want to we can override it with the settings here this is also where you would add in filters if you want user id to work only with particular groups let's take a look at configuring the windows agent to collect login events step one is to download the windows agent installer from the palo alto support portal you will need a valid login for this find the version that's closest to the version of your firewall notice how there are two files one is for credential detection which is an entirely different technology next install the agent on your domain member server i don't recommend installing this directly on the domain controller or exchange server the install is easy so i won't show you that part if you have branch sites with their own domain controllers or exchange servers you should consider installing an agent at each site the reason for this is performance the agent will collect full logs from the windows servers not just log on and log off events however it will only send a summary of these logs to the firewall which is less load on the wan links when you're done grant the service account full access to the installation folder in the app under user identification and setup we can enter our service account details under discovery add the servers that we want to monitor the simplest way is to click auto discover and then to manually add anything that's missing you'll probably find that domain controllers will work automatically while exchange servers will need to be added this is also where you would add other information sources if you have them like a syslog listener or a novel server the best practice is to list the subnets that your users will log in from and exclude all others i'm not going to be doing that for this demo finally commit your changes just like you would on the firewall i have found that it often says not responding for a while during commit you can verify your settings in the user identification tab check that your service is running and that the servers are connected if it's not connected you may have to go back and check the configuration of the surface account we also need to configure the firewall to integrate with the agent there can be more than one agent on each firewall and multiple files can use the same agent we simply need to enter the rp address of the agent and the port that it's running on that's 5007 by default and of course don't forget to commit your changes when you're done we're nearly done so far we've collected a list of users we've added a method of mapping traffic to those users now it's time we did something with that information our first task is to enable user id this is done per zone and should only be enabled on trusted zones user id information is really used in the security policy this is just like any other security rule however the user or group is added as the source of the traffic everything else is configured as normal as a matter of best practice we should create a security policy to stop user id traffic from leaking outside the network to do this create a rule to allow the palo alto user id agent application from agents and servers that we're monitoring only between trusted zones then create another rule to block this application to all other locations if you're using high availability confirm that config sync is enabled this is really optional but it helps failovers to complete as fast as possible there are two ways we can confirm this is working in the cli we can see the user to ip mapping from the web console we can take a look at the other traffic logs this will show us traffic as normal as well as usernames associated with this traffic keep in mind that your security policies need to be configured with logging to see this and that's how you configure user id on your palo alto firewall this really does add a deeper level of security to your network

Channel: Network Direction

Views: 5,043

Keywords: Network direction, Palo alto, Firewall, User id, Ngfw, Source user, Security policy, Visibility, Control, Reporting, Active directory, Ldap, Radius, Tacacs, Captive portal, Agent, Terminal services, Xenapp, Syslog, Proxy server, X-forwarded-for, Global protect, Client probing, Credential detection, Exchange

Id: wBcqyQfM-jU

Length: 15min 40sec (940 seconds)

Published: Mon Sep 07 2020