Juniper JN0-230 JNCIA Security Associate – Security Policies Part 4

11. Intrusion Detection and Prevention

Welcome back. Let’s now shift our attention to another topic called intrusion detection and prevention, also known as IDP. So IDP is the process of monitoring and analysing network events for threats. IDP is responsible for identifying suspicious activities and stopping them. Now, in some of the earlier videos, we’ve spoken about some other prevention and filtering techniques, like applying screens or configuring security policies. So at this stage, you may wonder, if we already have those checks in place, why do we need another check called intrusion detection and prevention? To help you understand this, I’ll use an analogy. Let’s say we have a person who is going to the airport to catch a flight. Now, when you’re at the airport, the first thing you need to present is a valid ticket. Now, think of this ticket as your security policy. To proceed to the boarding gate, you must have a valid ticket with a source destination and your travel date.

Think of the ticket as the security policy you configure on the SRX device. It functions as a first line of defense. Now, once you’ve passed this layer of check, before you can board the aircraft, you still need to scan your baggage to ensure that you’re not carrying any prohibited items. Think of this as the intrusion detection and prevention process. While you have a ticket to get into the airport, you still need to prove that you are not carrying any prohibited items that are similar to IDP. I hope that with this example, you have an understanding of why we need to further examine traffic after it has been allowed through initial checks such as screens and security policies. Now, let’s talk about enabling IDP. The first step is to instal the IDP license. So to use the feature, you’ll need to have the IDP licence for IDP. Next, you will download and instal the signature database. These two steps are similar to what we saw earlier in the lecture on application firewalls. Once you’ve installed the signature database, you will then configure the IDP policy, and then you will enable a security policy for IDP inspection. Here’s an example of what the policy will look like: It is almost similar to the security policy. In fact, it is a security policy with an extra configuration. So the command is to set security policies for the zone. Then we have a two-zone configuration, followed by a policy name. Then we are permitting the traffic and invoking the application services.

This time we’re invoking the IDP policy. And here we have the name of the policy. So, as you can see here, IDP is part of the security policy configuration. It’s not a global configuration that you would activate, and all traffic gets examined. For IDP, you enable that on a per-policy basis. Now, this kind of an approachhas a couple of advantages. Number one, you are selectively enabling IDP for the required traffic only. So all traffic passing through the SRX device may not need to be examined for threats. There could be traffic that you know is trusted traffic and does not need to be examined. So applying this on a per-policy basis allows you to define what traffic needs to be examined by IDP. The second advantage is that since only selected traffic is being inspected, it does not add an unnecessary load to the IDP engine. Now, let’s understand where in the packet flow IDP is applied. So here we have the packet flow diagram. When the packet comes in, the first thing that we check is for any screen configurations. Then we apply the NAT configuration. Then we have the route and zone lookups, then the policy lookups. Then we have source N, and then we have services. This is where IDP is applied. So the IDP examination is pretty late in the packet flow lifecycle. It has to go through the screen checks, net processing, route and zone lookups, policy lookups, and then we have the IDP examination. Now let’s talk about the different stages the packet goes through as part of IDP processing. From the examination perspective, we do not need to know the stages involved in IDP processing. But knowing about this will help us understand IDP better. Let’s talk about it. So, as part of IDP processing, the first step is fragmentation processing. Then we have flow setup, SSL decryption, reassembly, application identification, protocol decoding, signature detection, and IDP and IP actions. Now let’s talk about each of these stages. In brief, the first step is fragmentation processing. At this stage, IP fragments are reordered and reassembled.

The reason for this step is that packet fragmentation is a common technique used for evasion. To get the full picture, the SRX device must reassemble the fragments. Any duplicates, overlapping, or incomplete packets are discarded. This step is important because it prevents attacks that rely on evasive techniques such as fragmentation. The flow is set up next. The Juno’s device checks to see if the traffic belongs to an existing session. We have seen what the session table looks like in one of the earlier lectures. But the session table of the IDP processis different from the firewall session table. So the IDP has a separate state table or session table from the firewall state table. Next. We have SSL decryption. Now, this step only applies if it is configured. And in this step, SSL traffic is decrypted. We know that SSL and TLS are protocols used to encrypt traffic. That is, once the packet has been encrypted, you cannot see inside to determine the contents. SSL and TLS encryption are used to secure end-to-end communication between two parties. While this makes the communication channel secure, it also allows attackers to use these encrypted channels to propagate malicious stuff like malware. Because the packet is encrypted, inspection devices cannot see inside it to determine its contents. Now, SSL decryption is a technique that allows the SRX device to decrypt the packet and look inside to see what the contents of the packet. The next step is reassembly. For the IDP device to function effectively and prevent attacks, messages must be reassembled if they span multiple packets. At this stage, packets are ordered and reassembled to create complete application messages. This prevents messages from evading the IDP. Next, we have the application identification step. At this step, Juno determines the application associated with the traffic. Traffic is inspected even if the application cannot be determined. This is very important.

The SRX device will try to identify the application associated with the traffic by inspecting the traffic. But even if the SRX device cannot identify the application, the traffic will still be inspected as a byte stream or a sequence of bits and bytes. So the SRX device will try to identify the application, but if it can’t do it, it will still inspect the traffic. Next we have protocol decoding. Decoders are used to verify protocol integrity and ensure that RFC standards are met. RFC, or Request for Comments, is a body that’s responsible for setting standards for protocols used on the Internet. So at this step, the SRX device uses decoders to verify that protocol integrity has been maintained. Different parts of a protocol, such as the header, message, body, and other fields, are verified to ensure compliance with RFC standards. Then we have the signature detection process. Signature attack objects are used to look for specific patterns and identify known attacks. Juno’s provides predefined attack objects, and as an auger, you can also create custom attack objects. Information such as protocol, service and context information is used to detect attacks. The context information piece is very important. Think about this. We have a couple of users in the organisation who are talking about malware over email communication. Now, this communication should not be marked as an attack just because they are referencing malware or talking about malware in their email communication. This cannot be marked as an attack. So the context information makes the detection precise and relevant.

And finally, we have IDP and IP actions when an attack object has been matched. In other words, when a signature has been matched, the Juno’s device will execute an IDP action on the session. And there are a number of actions that we can configure. Let’s quickly go through them. The first one is “no action.” When this action is configured on the IDP policy, no action is taken. Now, this is typically used when you only want to generate logs for traffic. Next. We overlooked the connection. When this action is configured, it stops scanning traffic for the rest of the connection if an attack match is found. Following that, we have differentiating service marking. This allows you to assign a service differentiation value to the packet and then pass the packet normally. Then we have classes of service. Now, this is used to assign a specific forwarding class to the packet. meaning you want the packet to be treated differently. So you would apply a forwarding class to that packet. The next action is to drop the packet. Like the name suggests, this action will cause a matching packet to be dropped before it can reach its destination. But the connection is not closed. The next action is to drop the connection. This causes all packets associated with the connection to be dropped and prevents further traffic for the connection from reaching the destination. Next, we have a closed client. This action closes the connection and sends a reset packet to the client but not to the server. Next is closed. Server this. action, closes the connection, and sends a reset packet to the server but not to the client. The next one is “client and server,” and it’s self-explanatory. It closes the connection and sends a reset packet to both. The client and the server And finally, we have the recommended action. When you configure the action as recommended, the action recommended by Juno will be applied to the traffic. Like I said earlier, at the JNCIA level, we do not need to know the details of every step; we only need to know what an IDP is, what it is used for, and how to configure a simple IDP policy. In the upcoming lecture, we’ll see how to do that.

12. Configure IDP Policies

And here you can see all the predefined attack groups If you wanted to get more information about any of these, you could type in the name of the attack group and press Enter, and it would show you more information about that configuration. If you want to see detailed information about the IDP policies, like the ones that we saw here, for example, this one here, DMZ Services, If you want to see more information about that, there is a command for that too. It’s almost the same command: run, show security, IDP, question mark, attack, question mark, attack list, question mark. And the key word is policy. Question mark. And here you can see all the policy names. For example, if we wanted to look at more information about the DMZ Services policy, provide the name and press Enter, and you will see all the information about that policy. Like I said earlier, it is optional to download the predefined policy template, but if you do, it provides you with a good starting point to configure IDP. It is also possible to create custom policies, and the command is simply “Set Security IDP Question Mark.”

The keyword we are looking for is “IDP policy question mark.” Now you can provide a new policy name here and start configuring your custom IDP policy, or you can provide the name of a preexisting IDP policy and customise it based on your requirements. All right, so now that we have the policy templates, let’s see how to apply them to a security policy. So we’ll first navigate to edit security policies, press Enter, and we’ll begin with a show. So over here, we can see we have a policy from the untrusted zone to the DMZ zone. It’s matching any source address or any destination address in an https application. The action is configured to allow and log a session in it. Now let’s say we want to configure IDP inspection for this policy. So we’ll use the set command set from zone Untrust to zone DMZ, then the policy name, the then statement, the permit question mark, and the keyword “application services question mark.” The keyword we are looking for is IDP policy. IDP hyphen policy conundrum And now we can provide the policy name. Let’s say we wanted to apply the recommended policy. press Enter, and if we do a show now, we can see that we are permitting the traffic, but we are also invoking the application services, and we have the IDP policy configured here called “Recommended.” Let’s go ahead and commit to change. Commit completed. The last thing we’re going to look at is how to verify that IDP is enabled. So we’ll go back to operational mode and use the command “Show Security IDP Status,” which is going to show us status information about IDP. Right now, all the counters are set to zero, and that’s because there is no traffic passing through this SRX device. We could also use one more command, which is Show Security Policies Detail, which is going to provide detailed information about the policy. So here’s the policy name, which is “Untrust to Trust,” and you have some information about the policy. And we can see that intrusion detection and prevention are enabled down here. All right, so that’s a basic configuration of IDP on the SRX device. I hope you have a good understanding of why IDP is required and also an appreciation of how easy Juno makes it to configure IDP on the device.

13. Integrated User Firewall

So far, IP addresses and application information have been used as match criteria with our security policies. Now it’s time to add one more attribute that can be used as match criteria. Let’s talk about the integrated user firewall. The User Firewall feature is a mechanism that allows you to use user information as match criteria for security policies. So the security policies that we have configured so far look like this. So we had the SRX device, and we had some hosts for which we wanted to control access. And our policy looked like this: We used to match the source address, destination address, and application. Now we’re going to configure security policies that allow us to control access for specific users. So here we’ve replaced the machine or device with a user called Alex. The security policy looks almost the same, but with one addition. Here, along with source address, destination address, and application information, we’ve added one more criteria called source identity. We’ve specified the active directory domain name and the user name for that user.

So now we are able to control traffic not only using IP addresses but also the source identity or the identity of the user. As you can imagine, this adds a lot of flexibility when configuring security policies. So the user firewall feature retrieves user-to-IP address mapping information from the Windows active directory. The SRX device pulls the event log of the active directory to determine who is logged into the device. Once the SRX device has this information, it then queries the LDAP service to retrieve username and group membership information. Once it has collected all this information, i.e., once it has the IP address, username, and group membership information, it builds its own authentication table. User information is used to enforce user- or group-based policy control. In the example that we saw a couple of slides ago, we used username as match criteria, but we could also use group names. Juno’s recommends deploying this feature in an environment of up to one or two SREX devices, supporting up to two Active Directory domains and up to 20 domain controllers.

If you have more than two SRX devices, or if you have more than two Active Directory domains, or if you have more than 20 domain controllers, Juniper recommends using a feature called Juniper Identity Management Service, or Jims. So, to summarize, this is what it looks like. We have a user called Alex who’s trying to access the Internet, and we want to use security policies to regulate access for Alex. The first information that the SRX needs to know is the IP address to user mapping for Alex. And the SRX device obtains this information by querying the domain controller’s event logs, which provide the SRX with information about user-to-IP mapping. It then uses that information to query the LDAP service in order to determine Alex’s user and group membership information. Once it has all the information, it then constructs its own authentication table and uses that information in security policies to regulate access for the user. Here’s how the information looks on the SRX device: We have a lab on this, and we are going to configure it so we can see the output live on the SRX device. But just so that you can understand better, let’s take a look at the output. The first command displays the user group mapping for the domain lab local’s Users group.

And as you can see here, the SRX device has been able to retrieve three user names configured on that group, which are Administrator, Alex, and Sham. And the second output shows the authentication table that the SRX has constructed. So here’s the domain lab local, here are different IP addresses, and the user names are the users that are logged on to those devices. These user names can be used as match criteria while configuring the security policies. Moving on, some important things to keep in mind are that the minimum required Active Directory operating system is Windows 2003, and the minimum required client operating system is Windows XP. Juno does not support tracking for non-Windows Active Directory users, and multiple users logged onto the same PC are not supported. Another important thing to keep in mind from a security perspective is that the LDAP authentication being performed is simple authentication, which means the username and password are sent in plain text and can be read over the network. To avoid exposing the password, you can configure simple authentication within an encrypted channel. To summarize, the User Firewall feature allows you to use source identity or user identity as a match criteria in security policies. In the upcoming lecture, we’ll understand how to configure this on the SRX device.

14. Configuring Integrated User Firewall

Welcome back. Now that we’ve understood the concepts of an integrated user firewall and the flexibility that it adds to security policy configuration, it’s now time to configure this on the SRX device. But before we get to configuration, let’s take a look at the configuration scenario. So here we have the SRX device. On one side of the SRX device is the Internet, and on the other side, we have three devices. The first device is the domain controller for the domain lab local, and the remaining two devices are connected to the domain lab local. This device is being used by a user called Sham, and this device is being used by a user called Alex.

Now we’re going to configure integrated user firewalls so that the SRX device can get the user mappings from the domain controller. And then we’ll use the source identities—meaning the identities of these users—as match conditions in the security policy. So only one user, in this case Sham, will be allowed to access the Internet, while all other users, which include Alex and the administrator of the domain lab local, will not be able to reach the Internet. The IP addresses of these devices look like this. The first one is 10 dot 1 dot 20 dot 50. The second one is 10 120 60, and the third one is 10 120 70. Now, the IP addresses of the devices will not matter because we are not going to use them to match conditions in the security policy. But instead, we’re going to use the user identities as match conditions in the security policy. Also, to get access to these three devices, which are sitting behind the SRX device, I have another host, which is called the bastion host.

So I have a Bastion host connected to the SRX device. And from here, I’m going to initiate connections to all three devices. So I hope the configuration scenario is clear. We have the Internet on one side of the SRX, and we have domain-connected assets on the other side of the SRX. We are going to configure the integrated user firewall so the SRX device can get the user mappings from the domain controller. Once the SRX device gets the user identities, we’ll use those as match conditions in the security policy, and we’ll configure the policies in a way that only one user will be allowed to access the Internet, while all others will not be allowed. Now let’s get to the terminal of the SRX device and take a look at the configuration. All right, I’m here at the terminal of the SRX device, and as you can see, I’m already in configuration mode. Now, for the purposes of this demonstration, I’ve already configured the user firewall on the device, and that’s because the configuration is really long. There are a lot of commands that need to be configured to get the user firewall working. So I’ve already configured that. But we’ll take a look at all the commands that I’ve used for configuration. We’ll begin with show services. Press Enter, and here we can see that under “Show Services,” we’ve configured User Identification, and we need to provide the information about the domain and the username and password required for the SRX device to query the domain. So under Active Directory Access, we’ve defined the domain name, which is “Lab local,” and we’ve provided the credentials of a user that the SRX can use to probe the domain. In this case, the administrator provided the username and password. And as you can see, the username and password are encrypted. It is never shown in clear text in the configuration.

Then we’ve defined the domain controller. DC One is a name that I’ve provided on the SRX device for the domain controller. It does not have to be the actual name of the domain controller. It’s just a way to identify the domain controller on the SRX device. And here I’ve provided the IP address of the domain controller. Ten, 120, and 50 Next, we need to configure LDAP information so that the SRX device can grab the user group mappings. LDAP, as you know, stands for “Lightweight Directory Access Protocol,” and it provides the SRX device with a mechanism for interacting with the directory services. It is normally used for authentication and storing information about users and groups. So LDAP is the protocol that the SRX device will use to query the LDAP server and retrieve the user for group mappings. First, we need to define the base distinguished name. The base distinguished name identifies the entry in the directory from which searches are initiated. In this case, the domain name DC equals Lab, and DC equals Local. DC stands for domain component. Then we need to provide LDAP credentials. Now, in my case, the LDAP credentials are the same as the domain controller credentials. So I don’t need to define this again. But I’ve done that. If you do not define the LDAP username and password, it will default to the Domain Controller username and password. An important thing to note here is that the User Firewall feature that we’re configuring collects user and group information by reading Domain Controller event logs. It also queries LDAP services and probes domain joined assets.

So the user account that you configure here has to have those permissions. So make sure you are using an account that has all the required permissions. Next, we’re going to look at Show Access, and as you can see here, we’ve defined a profile called Profile One. A profile is a set of attributes that will define how to access the device. First, we have the authentication order, which specifies the authentication mechanisms to be used. The first one in the list is LDAP. And then we have a locally configured password. And then we define a set of LDAP options. The first one is Base, a distinguished name. It’s a set of properties that define the user. In this case, we’ve provided a common name that equals “users.” The built-in domain component Lab is equal to Common Name, and the domain component is equal to Local. Now you will get this information from your domain controller. So if you need this information, you can get it from your Active Directory administrator. Then we need to define the search properties. And the first one is the search filter. This is used to find the user’s LDAP distinguished name, or DN. Here we’ve defined the search filter as Sam’s account name. Now the Sam account name attribute is specific to ActiveDirectory, and it is used to support clients and servers from older versions of the Windows operating system.

Then we define the admin search properties. And for that, we’ve defined the distinguished names as Administrator, Users, Lab, and Local. And we’ve also included the password. And finally, we’ve defined another property under LDAP Server No. TLS certificate check. This tells the SRX device that it does not need to validate the server certificate. The following configuration is shown below. Display your security user identification. Press Enter. And here we can see that the authentication source for the users is configured as an Active Directory authentication table. The Active Directory authentication table will be generated by polling the domain controllers for source identity information about active users. Each entry in the authentication table will tell the SRX device the IP address associated with that user. And knowing the IP address is important because that’s how the SRX device will allow or deny the traffic. So that’s the configuration of the user firewall. With this configuration, the SRX device will be able to communicate with the domain controller to get the user mappings. Now we’ll configure the security policies that will use the identities that the SRX device gets from the domain controller. So let’s begin by discussing security ration, the SRAnd as you can see here, I’ve got three policies configured. The first two policies are from zone trust to zone untrust. While the last policy is a global policy, let’s first begin with the global policy. So let’s make Show Security Policies global, and we’re only looking at this configuration here. In fact, I’m going to clear my screen and type the command again.

So we are only looking at that configuration. The purpose of this policy is to allow traffic from the SRX device to be tapped for any unauthenticated or unknown user. So, as you can see here, we’ve provided a policy name. We’re matching any source and destination address. We are not talking about zones here because it’s a global policy. We defined the application as any except for the source identity. We’ve configured this as an “unauthenticated user” or “unknown user.” This will allow the SRX device to go and fetch the IP for user mapping. Once the SRX device gets that information, it will then write it to its own firewall authentication table. So as you can see here, we’ve permitted the traffic and configured firewall authentication using the profile that we configured earlier for the Domain Lab local. The goal of this policy is to allow the SRXdevice to go and retrieve the IP to user mappings. Now, once we have that information, we can then start controlling traffic. And for that, we’ve configured a couple of security policies from Zone Trust, because that’s where all our users are, to Zone Untrust, because that’s where the users want to go, which is the internet. So here I’ve got two policies configured. The first policy is to allow a specific user to make a note here. These policies are different from what we’ve been configuring so far.

We say any source address and any destination address, which means it doesn’t matter which computer the user is logged into. What we are really looking for is the source’s identity. If we are able to identify that the user who’s logged in is this specific user, then we want to permit any application traffic and log that. And then we have another policy called “Block Others,” which is going to block traffic from any other user. So that means if this user is trying to access the Internet, he’s going to match this policy. But all other users will match this policy, and their access will be rejected and logged. Now it’s time to test the configuration. Let’s log into the devices. All right, I’m here at the bastion host. From here, I’m going to initiate connections to all three domain-connected computers. The bastion host has grey wallpaper, while the others have blue wallpaper. As a result, it’s easy to tell that I’m on the bastion host. So from here I’m going to initiateconnection to the domain controller first. That is 10 120 50, and I’m going to log in as the domain administrator, lablocal administrator, and I’ll enter my password. All right, so I’m logged in as the administrator on the domain controller itself. Let’s try to ping the internet from here. So, eight pings. And as you can see, our traffic is being rejected, so we are unable to reach the internet from the domain controller. Now let’s go back to the bastion host and try the same thing from the machine where Sham is logged in. So that’s going to be 10 120 60.

I’ll provide my password. All right, we’re logged in. Remember, this is the user that has been allowed access to the Internet. Let’s give it a try. Ping eight, eight, eight. Okay, so that’s working. Let’s also try web traffic. Let’s go to Juniper Net. So that’s working as well. Now let’s go back to the bastion host and try the last user, which is Alex, and that is on port 1270. Enter the password and log in. All right, I’m logged in here. Let’s open up the command prompt and try to ping (8888).And as you can see, the request is being rejected. So the user’s firewall is working. Well, the machine where Sharm is logged in for Internet access is working fine, but all other users are not able to access the Internet. Now that we’ve seen the configuration and tested it, let’s go back to the SRX device and perform some verification. Now, let’s return to the SRXdevice and perform some verification. and let’s start by looking at the log file. So we’ll say “Show log,” the log filename, which I’ve configured as a traffic log. and we’re going to match ICMP. Okay, so here we can see that the first session is for the administrator’s machine: 10, 120, and 50. We can see that it was the administrator and that traffic was denied. That was denied, as we can see, and it was matched by the policy called Block others. And here’s the other traffic that was generated by the user called Sham.

So we can see that the ICMP traffic created this session, which matched this rule called Allow Sham. So the logs are looking good. Let’s perform some more verification. So the command we’re going to use is “Show Services,” “User Identification,” “Active Directory,” and let’s put a question mark here. This is the first time that we should be verifying the domain controller status. This tells us if the SRX device is connected to the domain controller. So here we can see that DC one is ten120-50 and we are connected to the domain controller. The next command is similar, so that’s showservices user identification, active directory access statistics, question mark, IP user mapping, and press enter. And here we can see that the SRX device has been able to fetch records from the domain controller. The next command we’re going to look at is again similar to the last command. So far, we’ve covered user identification and active directory access. But this time we’re going to use the keyword “user group mapping,” a question mark, and then we’ll say “status” and press Enter. So here we can see that the last query status was success. The next command we’re going to look at is very interesting, so that’s showsServices, User Identification, and Active Directory Access.

And the next portion of this command is actually a hidden command, so we need to type it out completely, and that is the Active Directory Authentication table. So that’s a hidden command, and we need to type it out with a question mark. And we’ll say everything. Show services user identification active directory access active directory authentication table all, and that’s going to show us the user records that have been fetched from the domain controller. Now, we don’t see Alex here, and that’s probably because there is no traffic being generated from his device. But if we go back to the device and initiate some traffic, that should come up here as well. Any traffic that is coming from non-domain assets is going to be shown here under the null domain. Like you can see, this device is not a domain-connected computer. Now let’s also look at some more verification. Show services: user identification, active directory access, the group mapping question mark, and we’ll specify a group name because that’s what we configured earlier. In addition, we will specify the domain name lab local. And here we can see Alex, so we can see the administrator, and we can see Alex and Sham. Don’t worry about this user. This is a default user account used by Active Directory for Kerberos’ authentication purposes. So that’s not a user account that we care about. So we’ve got administrators, Alex, and Sham. There’s one last verification command that we’re going to look at. I lost my connection there for a second, so I had to refresh, and I cleared my screen.

The last command we’re going to look at is showServices User Identification, and the keyword we are looking for is authentication table, which allows us to specify an IP address and view the user mapping for that. For instance, 10 is greater than 120 and less than 50, indicating that the mapping for that IP address is administrator. Let’s take a look at 60, and we can see that the mapping for that is with the user sham. So that’s how we configure the integrated userfile wall on the SRX device. As you can imagine, this has many use cases. We may want to allow certain types of traffic for certain groups of users in the organization, or we may want to prioritise traffic from specific groups of users over traffic from other groups of users. There are numerous use cases, and as you can see, it also adds flexibility to the configuration of security policies.