Juniper JN0-230 JNCIA Security Associate – Security Objects Part 2
Configuring Address Objects Welcome back. So we’ve talked about the different address objects that can be created on an SRX device. Now let’s see how we can configure them. So I’m already at the terminal of the SRX device. I’m going to enter configuration mode, and let’s start by taking a look at the output of the show security command. As you can see here, I’ve got a simple configuration. I’ve got three zones configured: trust, trust, and DMZ. Let’s start by talking about the global address book. The way…
Welcome back. So we’ve talked about the different address objects that can be created on an SRX device. Now let’s see how we can configure them. So I’m already at the terminal of the SRX device. I’m going to enter configuration mode, and let’s start by taking a look at the output of the show security command. As you can see here, I’ve got a simple configuration. I’ve got three zones configured: trust, trust, and DMZ. Let’s start by talking about the global address book. The way we can look at it is by using the command set security. And let’s begin with a question mark. Here we can see the keyword “address book.” So configure the security address book. If I put a question mark here, you will notice we have a predefined address book called global.
So on an SRX device, this is a predefined address book. When you create an address in the global address book, it can be used across any zone. When you’re learning about address books, one question may pop up in your mind: do I really need to configure addresses or do I really need to configure an address book? Well, the answer is yes. Let me show you why. So I’m going to use the command to set security policies. This is used to configure a security policy, and we have a dedicated section where we’re going to talk about how to configure a security policy. But right now, I’m going to show you why addresses need to be configured.
So we’ll configure a security policy, set security policies, and I’m quickly going to run through the configuration because right now the focus is not on the security policy from zone trust to zone untrust policy name. And I’m just going to call this “demo,” with a question mark to match the source address. And you will notice here that when you want to match an address in the policy, you only have four options. You can use any of the three predefined addresses, which are any, any IPV 4, or any IPV 6, or you can provide an address from the address book. So every address that you reference in a security policy must be defined in the address book. So that answers why we need to create addresses. Next, we’ll understand how to configure an address.
So edit the security address book and provide a book name. Let’s call this “trust.” This book will contain all addresses that can be found in the trust zone of the SRX device. Let’s start with a set command and a setspace question mark. And the keyword we are looking for is “address notice.” You also have the option to provide a description, which is a recommended practice. And you also have the option to attach the address book to a zone interface or routing instance. Let’s start with a question mark. We need to provide an address name. I’m going to start with ten points. This is not the IP address that I’m trying to reference. This is just the name of the address object: space, question mark. And now we can provide the IP prefix that we want to reference. So that’s going to be ten 1132 set addresses, the name of the address, and then the IP prefix. Press Enter and let’s do a show. So that’s our first address. Let’s make another set of addresses and call it something. Let’s call this an internal LAN and assign it the IP address 10 00:16. Let’s create one more address. Let’s call this one internal land two. And the prefix for this one is 192, 168, ten 00:24. So now we have one address over here that represents a specific host and two addresses that represent subnets. Now let’s combine these two addresses to form an address set. So set the space question mark, and this time we’ll use the keyword address to set the address hyphen to set, and we need to provide a name.
I’ll use the up arrow to change that to internal land hyphen number two. And if we do a show now, we can see that we have an address set called LAN that references these two addresses. Let’s also try to create an IP range object. Now that the address has been established, let us give it a name. Let’s call this one “internal servers” and let’s do a question mark. This time, we’re not going to use this option. We’re going to use the range address keyword. So Range Address, and we must begin with the first address or the range’s lower limit. So let’s provide this one as 1921-6810, and the keyword is “two,” followed by the upper range. So 192, 168, 120; let’s do a show now. And we can see the IP range object here. Let’s also create a wildcard address. The command is set space address, followed by DHCP server address name. That’s the name of my address object. And this time, we’ll use wildcard addresses as the type of wildcard addresses, with ten wildcard masks ranging from 250 to 2525. This represents the IP address 10 x 00:50, and that’s because this octet of the Wildcard mask is set to zero.
Press enter here and let’s do a show. Okay, so we’ve got the addresses configured in the address book, but right now we can’t use these addresses, and that’s because the address book is not attached to a zone. So let’s do that set space question mark thing, and we’ll use the keywords attach, attach, and zone, as well as the zone’s name, trust. Let’s go to the top, and let’s show security. And now we can see the address book called Trust, which is attached to the Trust zone. Let’s quickly create one more address book called Untrust. So configure the security address book. And I’m going to call this one “untrust.” This time, let’s use the DNS address object type. So let’s do Set Address and the DNS server address name. And this time, I’m going to provide an IPV6 address. Press Enter. Let’s do a here and And now we’ll attach this to the untrusted zone. So set the attach zone to untrusted. Let’s go to the top and do show security. So here we have the Untrust address book, and it has an IPV6 address. And I just realised that this address is actually an IP prefix address object. We did not use the keyword “DNS.” So we’ll do that for the next address that we’re going to define in the global address book. This is not a DNS address object type. Only the name says DNS server, butit’s an IP prefix address object type.
So let’s create an address in the global address book of type DNS address. So I’m at the top of the configuration mode, and let’s do Set Security Address Book. And this time, we are going to use the global address book question mark. I’ll use the address keyword and provide a name for the address NTP server. And this time, we’ll use this keyword here, which is the DNS name. And now we’ll provide the DNS name, which is pool NTP.org.When configuring an address object of type DNS, make sure you have a name server configured on the SRX device. Otherwise, your device will not be able to resolve this to an IP address. Okay, so now that we have the addresses configured, let’s try the command that we tried earlier to configure a security policy. Set the zone trust security policies to zoneUntrust policy name, which is the demo match source address. And if I put a question mark here, So here we have all the addresses that we define in the trust address book because that’s attached to the trust zone. So here are the addresses. We also have the address set here. We have the predefined addresses. And also notice that we have the address that is defined in the global address book. But note that we do not have the address that was defined in the Untrust address book. In fact, let me show this to you, sir. The source address will be specified as being on internal Otherwise, yAnd let’s do a question mark. Please provide the destination address here. I’m going to reiterate that right now, we’re not talking about creating a security policy. We’re just talking about the addresses that can be used in a security policy. So don’t worry about the syntax of security policies. We’ll talk about this later on in this course. Keep in mind that the destination address will refer to the destination zone or zones, which is untrustworthy.
So if we put a question mark here, notice we can only see the address that was defined in the untrusted address book and the global address book. So when you define address objects in specific address books, they can only be used in the attached zones. But addresses defined in the global address book can be used across zones. One last thing before we complete this video, I’m going to go back to the top of the configuration mode and let’s try to attach the global address book to a zone and see what happens. So add a question mark to the security address book. We’re talking about the global address book. Let’s try to attach this to a zone. As a result, attach zone trust. The command has been accepted, but let’s try to do a commit check. The commit check can be used to validate the configuration. Press enter and here we can see that itis not allowed to attach the global address bookto a particular interface, zone or routing instance. It is important to keep in mind that a global address book cannot be attached to any zone.
Welcome back. Now, let’s talk about the next type of object that we can create on the SRX, and that is known as an application object. So, applications represent different types of traffic processed by the SRX device. Each application has a transport protocol, like TCP or UDP or ICMP, and a destination port. For example, SSH uses TCP as the transport protocol, and port 22 is the destination port. We can also create groups of applications, and these are known as application sets. Now, Juno has a list of predefined applications, and we can directly use them while configuring the security policies. Or we can create custom applications. When you’re creating a custom application, you need to provide some information, like what the name of the application is, what transport protocol is going to be used, and what the source and destination port numbers are for TCP and UDP-based applications. Or if you’re creating a custom application for ICMP, in that case, you can provide information like what type of ICMP code you want to use for that application.
And finally, we can provide a timeout value. Now let’s get to an SRX terminal and see how we can configure a custom application. All right, I’m here at the SRX terminal. Let’s start by looking at the predefined applications and the command to view. This is actually a hidden command. So we’ll use the command show configuration groups from the operational mode. And if we put a question mark here, you’ll see that I do not have any configuration groups created on my SRX device. But there is a default configuration group called “Juno’s Defaults.” So show configuration groups Junio’s hyphen defaults. Press Enter, and you’ll see a lot of configuration here. This configuration is used by Juno to provide a default configuration for the SRX device. But we’re not interested in all this configuration. We are only interested in your applications. So, control C to exit out. and we’ll add a switch here. Show configuration groups for Juno’s Hyphen default applications, and that will only show the application portion of the configuration from this output. Show configuration groups for Juno’s default applications. Press Enter.
And here we can see the default applications. Let’s examine a few of them. For example, here we have an application called Juno’s SSH. The transport protocol is TCP, and the destination port is 22. Here. We have telnet. Juno’s Hyphen. Telnet. The protocol is TCP, and the destination port is 23. But look at this one here, June’s hyphenated FTP. It has a transport protocol called TCP, a destination port number of 21, and a configuration called application protocol. The protocol keyword specifies the transport protocol, or the lower-level protocol, while the application protocol provides information about the higher-level protocol. So the application protocol, which is FTP, is the higher-level protocol, and the protocol keyword is for the lower-level protocol. Having the information of the application protocol allows the SRX to perform deep packet inspection and intelligently handle these packets; these applications can be directly used when configuring security policies. Now, let’s say we have a custom requirement, so we need to create a custom application. Let’s do that. Control C to exit out, and let’s get into the configuration mode. By the way, if you wanted to view the default applications from the configuration mode, the command is “Show groups,” not “Show configuration groups” that we used in the operational mode. The command is Show groups, and the default group name is Juno’s. Hyphen defaults in applications. Press Enter and you should see that output. OK, to exit, press CTRL-C. And now let’s create a custom application. But before we do that, I’m going to clear my screen, so let’s start from here. So we’ll start with the Edit command, edit space, question mark, and the keyword we are looking for is “applications.” So edit applications, press Enter, and now we are in a specific configuration hierarchy.
Let’s use the Edit command again. Editing space and a question mark. So we’ve got a couple of options over here. We can define an application or an application set. Let’s start with the first application space, “question mark,” and we need to provide an application name. Let’s say we need to define a custom HTTP application that uses the destination port 8080. So let’s say Edit application andprovide a name custom Http.So now we are in the specific application configuration hierarchy. Let’s use the set command “set space,” “questionMark,” and you can see here that we have so many options that we can configure. We can specify the protocol, the source port, the destination port, the application protocol, and so on. The application protocol, as we discussed earlier, allows you to specify a higher-level protocol. Juno’s documentation also refers to this as an ALG, or application layer gateway. The keyword “description” can be used to provide a description for the object that we are creating. We have an option here called “do not translate a query to AAA query.” The SRX device automatically translates IPV-4 DNS objects into IPV-6 DNS objects. If you want to turn that off, this option can be used. And there’s the opposite of this as well. Do not translate an AAA query into a query. The SRX automatically translates IPV 6-objects to IPV 4-objects. If you want to turn that off, we can use the switch over here.
The other important option is the ICMP code. If you’re defining a custom application using the ICMP protocol, you can use the ICMP code keyword to further drill down to individual ICMP codes rather than using ICMP as a whole. So let’s look at some of the options. There is an ICMP hyphen code, a question mark, and you’ll notice here we can go into specific ICMP codes, like, for example, port unreachable, network unreachable, host unreachable, et cetera. So instead of treating ICMP as a whole, we can match specific ICMP codes. I’m going to erase that command. Let’s do the setspace question mark again. The other option is an inactivity timeout. This option allows you to specify the idle timeout that should be applied to this application object. By default, TCP has a 30-minute idle timeout and UDP has a 62-minute idle timeout. I cleared my screen. The other option that we have is an RPC programme number. This can be used to specify a specific RPC programme number if you are using the RPC ALG. And then we have this option called “term.” This option is similar to the term that we saw when creating a firewall filter. It allows you to specify multiple criteria within a single object. And we’re going to use this in a short while. Right now, let’s finish creating this object. So the object name is custom HTTP.
Let’s start with a protocol: space, question mark, and all of these other options. Let’s set it to TCP. Let’s also set the destination port. Set the destination port, and this is a custom HTTP application that is going to respond on port 80 80. And let’s also set an inactivity timeout of 180 seconds. If you do not want the application to time out, the keyword is never. Let’s do a show here. So we’ve set the protocol destination port and inactivity timeout. Let’s go up one level and also create one more custom application called custom HTTPs. So the keyword is “set application” and the application name is “custom Https.” I realised we are missing theinformation like port and protocol. So let’s change this command to edit and then use the set keyword. So now we are in specific application configuration mode. I’m going to clear my screen again. Okay, and let’s do “set protocol” TCP and set the destination port. Let’s say this application uses 8443 as the destination port and an inactivity timeout of 180 seconds. Let’s go up one level, and let’s do a show. So now we have a couple of custom HTTP applications. Custom HTTP and custom HTTPS—let’s combine these two to create an application set. So set the question mark, the application set, and the name of the application set. We’ll call this custom web, and the application will be custom HTTP. I’ll hit the up arrow again and also add custom HTTPs.
So if we do a show here, we have an application set that includes both the custom applications that we created. Now these applications or application sets can be used when creating a security policy. Let me quickly show that to you. I’ll go to the top here, and we’ll use the command to set security policies from zone trust to zone untrust. Don’t worry about the syntax of this command. We’re not talking about security policies right now. We’ll talk about it later on. Right now, I’m just trying to show you how we can use these applications when creating a security policy. So Set security policies from zone trust to zone untrust. And if I do a match here or questionmark we need to provide a policy name and let’s try to match the application mark. And you’ll notice that all of these are predefined applications—anything that begins with Juno’s hyphen—but we can also see the custom applications and the application set that we created. Okay, there’s one last thing that I’m going to show you, and that is how can you specify multiple criteria within the same application object? So, let me clear my screen here, and then we’ll return to editing applications and do a show.
So, as we can see here, the custom HTTP application is configured to use 8080 as the destination port. But think about this. What if we wanted to specify a couple of destination ports within the same custom application? Let’s say we also want to include port 80 88 or 80 88. Let’s see what happens if we configure it directly. So set application and the application name, which is “custom HTTP question mark,” and let’s configure the destination port as 80 88. And if I do a show now, you’ll notice that it replaces that port. We had 8080 here, but after executing that command, it’s now changed to 8088. So how do we specify multiple criteria without overriding the configuration? And that’s where the term “keyword” can be used. So, let’s enter the configuration mode for that specific application, edit application, custom HTTP, and press Enter. For simplicity, we’ll use the set space term set term and provide a term name. I’m just going to call it “Term One,” and this time I’ll specify the destination port as 8080. And again, set term 2 to “destination port 8088.” If we do a show now, we can see we’ve added two destination ports, and we’ll remove this one here. So, remove the destination port and hit Enter. And if we do a show now, we have these common parameters for protocol TCP and an inactivity timeout of 180 seconds. But now the application is configured to respond to 8080 and 8088.
Let’s now talk about an important security feature on the SRX device called screens. Now, before we understand what screens are, let’s talk about the traffic flow on an SRX device. And where in the traffic flow are screens evaluated? So on the screen now, I have the traffic flow diagram. Here we have the ingress packet. The first thing that’s evaluated for an incoming packet is to see whether it belongs to an existing session or not. If the packet belongs to an existing session, it takes the fast path. And notice here in the fast path that the first thing to be evaluated is a screen configuration. If the packet does not belong to an existing session, it takes the first packet path. And even in this path, the first thing to be evaluated or the first thing to be applied to the packet is a screen configuration. That means, regardless of whether the packet belongs to a session or not, screens are always the first configuration to be applied. But make a note here that screens are only applied to egress packets. There is no screen configuration applied to egress packets. Having understood this, let’s now understand what a screen is. In simple words, a screen is a configuration that can be used to detect and block anomalies. An anomaly is something that is not normal or as expected.
So a screen is a configuration on an SRX device that can be used to detect anomalies. It is evaluated right at the beginning of the packet flow so that packets can be dropped as early as possible. And like we saw earlier, screens are only applied on the ingress interface. Let’s understand this with a diagram. So here we have an SRX device that is controlling traffic between a workstation and a server. When the workstation sends a packet to the server, it is intercepted by the SRX device. And since this is an egress packet, it will be subject to screen evaluation. The SRX looks at the packet and allows it to go through when the server responds back. That is also an ingress packet, and that is also a point where a screen will be applied. So it is very important to understand that screens are always applied to ingress packets. The ingress packet can also be a response packet, but it is still considered an ingress packet, and screens are not applied to egress packets. Now, let’s talk about the types of screens that we can configure. Primarily, there are two. The first one is a statistics-based screen. This is used to determine normal network behaviour and form a baseline level. Any activity that falls outside the baseline will be flagged as anomalous. The second type of screen is a signature-based screen.
These screens use patterns or signatures to identify malicious behavior. Let’s look at some examples of statistics-based screens. The first and most common one is ICMP flooding. Now, when you look at it, it looks like we’re talking about a specific type of attack. So here’s the thing: On an SRX device, screens are named exactly after the attack types that they protect against. So while ICMP Flood is a type of attack, the name of the screen that protects against this type of attack is also called ICMP Flood. So we’re not only talking about the attack type but also the screen type that is used to protect against that type of attack. ICMP flooding happens when the attacker sends a lot of ICMP packets to a specific machine. The intent here is to slow down the target machine by sending lots of packets. Another common type of attack is a TCP syn flood. We now know that every TCP connection begins with a three-way handshake. The initiator sends a Syn packet; the destination responds back with a Synac; and the initiator again sends an Acknowledgment packet. When all three packets have been successfully exchanged, the TCP connection is established. The attacker sends a large number of Sin packets to the target machine in a TCP Syn Flood attack. The target machine responds to these sync packets with a sync packet, but it never gets an acknowledgement packet back. As a result, it has a lot of half-open sessions or sessions that have not fully completed the three-way handshake. The attacker keeps sending more and more SIN packets.
The target machine keeps responding back with Synac packets, but never gets an acknowledgement. As a result, the target machine’s resources will be exhausted, and eventually it will crash. Another common type of attack is TCP port scanning. The purpose of this attack is to scan for available services in the hopes that at least one port will respond. And when the port responds, the attacker knows what service is running on that port, and with that information, the attacker can launch a more targeted attack. Another common attack is UDP flooding. This is similar to TCP Sin Flood, where you send a lot of UDP packets to exhaust the target machine’s resources and make it crash. The second type is signature-based screens, and a common signature-based screen is TCP Land. I’m going to reiterate that the name of the attack and the name of the screen are the same. So when we say TCP Land, that’s also an attack type, and that’s also a screen type that you can configure on an SRX device. A TCP/LAN attack occurs when the attacker sends a packet with the same source and destination IP addresses. Since the packet has the same source and destination IP addresses, it will be processed indefinitely.
As a result, the target machine will exhaust its resources and eventually crash. Another common attack from back in the day is TCP Win Nuke. This happens when the attacker sends a TCP packet with the urgent flag set. A TCP packet header has multiple flags that you can set, and one of the flags is the urgent flag. Operating systems that cannot handle these types of packets will crash. I’m sure some of you recall this from the past. This is an example of what could happen if the operating system could not handle a packet like that. TCP syn fragment is another screen type. Here, the attacker sends fragments of syn packets. The target machine will keep waiting for the fragments of the sin packets to arrive. Eventually, its resources will get exhausted, and the device will crash. Then we have the ICMP “ping of death.” This happens when an attacker sends oversized ICMP packets. And then we also have IP spoofing, which is a very popular attack type. Here, the attacker sends a packet with an invalid source IP address to make it appear like it’s coming from a trusted source. These are not the only types of screens that we can configure on the SRX device. There are many different types of screens that we can enable. In an upcoming lecture, we’ll understand how to configure screens.
Welcome back. Now it’s time to configure the screens on the SRX device. This lecture will be slightly longer than the others because we will examine the various screen configuration options as well as simulate an attack to determine whether or not the screen is blocking the attack. It’s going to be slightly longer, but I promise you will enjoy it. Let’s begin. So I’m here at the SRX device, and I’m first going to enter the configuration mode, and the command for configuring a new screen is “edit Security Screen,” and we start with a question mark here. The option that we are looking for is the “IDs with hyphens” option. So we changed the option “Security Screen IDs with hyphens,” and now we need to provide a screen name.
As you can see, I already have a screen configured, but let’s configure a new screen. Call this one an “untrust screen,” because I intend to use it in the untrust zone. You can provide any name for the screen. Mark, I’m going to refer to it as an untrustworthy screen question. And now we can execute the command by pressing Enter. And now we are in specific screen configuration mode. Let’s start with Setspace, the question mark, and notice we have different options available. Over here, we can configure screen values for ICMP, IP, TCP, and UDP. Begin with ICMP set ICMP space question mark. You’ll notice we have different options over here. Some of these options were discussed in the last lecture. The first option here is flooding. So if we do set the ICMP flood threshold, you can define a threshold in terms of the number of ICMP packets per second. So this allows you to define the number of ICMP packets per second allowed for the same destination before any more packets to the same destination for the remainder of the second will be dropped. So in simpler words, this defines the number of ICMP packets that the SRX device will allow per second for a destination. Any packets above that threshold will be dropped. The following option is fragment. This can be used to detect and drop any ICMP packets with the fragment flag set.
So if you look at the ICMP packet header, there is a flag called the “more fragment flag,” and this option can be used to identify any ICMP packet that has the “more fragment flag” set. The next option is ICMP version 6 malformed, and the name is indicative of what it does. It can detect and drop ICMP version 6 malformed packets. The next option here is IP sweeping. Keep in mind that we are talking about IP sweeping. Under the ICMP protocol, a sweep attack happens when an attacker sends ping requests or ping packets to multiple destination IP addresses. If a host replies, the attacker knows that there is a live device on that IP address, and then he can try other attacks on that IP address. The next option here is “Large.” This can be used to detect and drop any ICMP frame with an IP length greater than 1024 bytes. and you can see that over here. The next one is Ping’s death. This can be used to detect and drop oversized ICMP packets. Let’s look at the other option. Insert a question mark. The other option is IP. Let’s give it a try. Configure IP Space Question Mark and there are a lot of options available over here. We’re not going to talk about every available option until a bit later on. I will show you a place where you can go and read more about every option you find over here. Let’s talk about the important ones. The first one here is a bad option. This can be used to identify and drop any incorrectly formatted IPV-4 and IPV-6 packets. These packets are known to cause unpredictable issues. The following is a block fragment. This can be used to identify and drop fragmented IP packets. Let’s now look at the options for TCP.
I’m going to clear my screen, and let’s do Setspace Question Mark sets TCP Space Question Mark, and we have a few options for TCP. The first one here is Finn. No act. This is used to identify and discard any TCP packet with the fin flag set but no acknowledgement flag. These types of packets are used by attackers to identify the operating system of the target or to identify open ports on the target. We spoke about TCP land attacks. This happens when the attacker sends a packet with the same source and destination IP addresses, causing it to be processed infinitely. Next, we have a port scan. This can be used to prevent port scan attacks. A port scan attack happens when an attacker sends packets with different port numbers to scan for available services. If a port responds, the attacker now has more information to try different types of attacks. The other important one is Sinfin. This type of attack happens when the Sin and Fin flags are both set at the same time on a packet. That should never be the case because the Sin flag is used to denote the beginning of a session and the Fin flag is used to denote the end of a session. They both should not be enabled at the same time on the same packet. The next one is sin. Flood. This happens when the attacker sends a flood of SIN packets to the target machine.
The target machine responds to the Sin packets and keeps waiting for the Acknowledgement packets, which never arrive. As a result, the resources of the target machine become exhausted and can lead to a crash. This one, called Sinfrag, can be used to protect against fragmented Sin packets. Let’s now look at the options for UDP set space (UDP space question mark), and here we have fewer options. The first one here is an UDP flood. This happens when the attacker sends a lot of UDP packets to a target machine to slow it down that machine. The other two options can be used to protect against a UDP port scan and a UDP sweep. Now, let me show you a place where you can go and get more information about all these configuration options. So let’s say we wanted to know more about this attack over here or this configuration command over here. Finn, no ACK The way to get more information is to go to Juno’s CLI Explorer. The URL is apps.juniper.net. Clihexplorer. You have a search bar here where you can type in the commands. When you type in the command, do not use the set keyword; simply type the keyword for which you want more information. For example, we want more information about Finn No. ACK. And there we have it. Click on the link, and that will take you to the document that has more information about that command. For example, this command can be used to detect an illegal combination of flags and reject packets that have this combination. So this tool here is very useful to get more information about configuration commands. It’s not only used for commands used to configure a screen but can be used to get information about any configuration command on the SRX device. Back over here. Let’s look at some more options. Setspace and a question mark.
And we have a keyword called “alarm without drop” here. The name is indicative of what it does. When this configuration is set, the screen will not drop the packet, but it will only generate alarms. So if you do not want the screen configuration to drop the packets that exceed your threshold, you can use the command Alarm Without Drop. The other important option is to limit sessions. Let’s take a look at the options available. Set Session Limits, Question Mark and we have a couple of options over here: destination IP-based and source IP-based. This command can be used to configure session limits for individual destination and source IP addresses. So if we want to limit the number of sessions to a specific IP address, we can use this command. Or if we want to limit the sessions from a specific source IP address, we can use this command. setLimit Session, IP-based Destination Question Mark and now we can provide a value in terms of how many sessions we want to be limited to. So, for example, let’s say Mark has 50 spaces, and we can also configure the source IP based on the same command. Right now, I’m not going to configure this. Let’s do a show here. So right now, we do not have any configuration on the screen. Let’s quickly add a configuration and see how we can attach the screen to a zone.
So I’m going to add Set ICMP, and let’s set the value for the ICMP flood threshold. And let’s set this to 50. So this command means we are allowing 50 ICMP packets per second to the same destination. Press Enter. Let’s do a show. So that’s our screen configuration. Now we need to attach that to a zone. We’ll go to the top, and we’ll use the command Set Security Zones. Security Zone is the name of your zone. In this case, I want to attach it to the untrust zone. And then the keyword is “Screen,” “Screenspace,” “question mark,” and the name of the screen is “Untrust Screen.” That’s how you configure a screen under the Edit Security Screen IDs option: you provide a screenname, set your values, and then attach the screen to the zone of your choice. Now let’s see this in action. Let’s start with the security screen. And you’ll notice here: I already have a screen configured. This is called the Trust Screen, and it has been applied to the Trust Zone. Let’s take a look at it. Display security zones. You can see it here. Security zone. Trust. That is what we call the screen configuration over here. Now, the trust screen has a couple of configurations. It has a configuration for TCP sync flooding where it allows ten packets per second.
And it has a configuration for ICMP Flood that allows ten packets per second. I also have logging configured on this device. So let’s show the system log. You can also see it here. I have a file called Messages that accepts log messages from any facility with any severity level. Now let’s see this live in action. Let’s hop over to a device that is connected to the trust zone of the SRX. And this is the device. Now we’re going to use a command to simulate an attack. Before we simulate the attack, let’s go back to the SRX device and commit the configuration just to make sure that the changes are in place. And the other thing I’m going to do is clear all contents of the log file, so the command is “clear log,” and the log file name is “Messages.” Notice that I performed this in operational mode. Now let’s go back to this device. And to simulate an attack, I’m going to use the HPG-3 utility. The command that I’m going to use looks like this: hping(3) and the IP address that I want to attack. In this case, I’m attacking the interface of the SRX device, but you could include any IP address that can be reached by going through the SRX device.
This is a lab machine, so I’m going to target the interface of the SRX device. I’ve added a few flags over here, and these flags are specific to the tool that I’m using. The Q flag is used to provide brief output. The N flag is used to show the target IP. The D flag is used to set the packet size. The F flag is for the flooding that we’re going to simulate. And the P flag is for the port number, and the flood flag is to send a flood of packets. If you’d like to learn more about this tool, I suggest you take a look at the documentation available online. for this tool. I’m going to press Enter, and this is going to cause a SQL flood attack. Press Enter, and right now it is sending SYN packets to this IP address. Control C to exit will stop the attack. And let’s go back to the SRX device, and let’s take a look at the counters. The command is Statistics Question Mark, and the security screen is displayed. And we are going to look at the statistics of the Trust Zone. Press Enter. And here we can see that theSin flood counters have been incremented. So the SRX device detected the attack and the counters have been incremented. Now let’s take a look at the log file.
Display log messages. Press Enter. And clearly, we can see that the SRX device has detected an attack. So here we can see that a flood has been detected from this IP address. At 101-2, that’s where I’m connected. This is the destination IP address, the zone where the attack was discovered, and the interface and action that were to be dropped. If you would like to get more information about this log message, simply copy the keyword that you see here. RT underscore screen underscore TCP in this case. We’ll copy that: Control.C to exit. And we’ll use the Help command Helpsyslog because this is a Syslog message. And we’ll copy and paste the keyword that we see here. Press Enter. And here we can see more information about this message. This is the format that we’re seeing here. This is a TCP attack category, and this message reports an event, not an error. Now let’s try the test one more time with an ICMP flood.
So clear log messages, and I’m going to enter configuration mode and show you the configuration first. So show the Security Screen IDs option. Trust screen. So the current configuration is an ICMP flood threshold of equal packets per second for the same destination. That means the SRX device will allow ten ICMP packets for the same destination in one second, and any excess packets for that second will be rejected. Before we simulate this attack, let’s disable this configuration and see what happens. So, we’ll quickly enter configuration mode, edit the security screen, choose the IDs option, and trust the screen. Okay. And let’s deactivate that configuration. Deactivate ICMP. Let’s do the show. So now we have deactivated this configuration and committed. Now let’s go to the other machine and try to send a flood of ICMP packets.
Here’s the command that I’m going to be using: ping 3, which is the utility, the IP address. The faster flag will send a lot of ICMP packets, and hyphen one is the flag for the ICMP protocol. So we’re going to send a lot of ICMP packets at a quick rate. press Enter, and as you can see, we’re getting a lot of responses. Now let’s go back to the SRX and enable this configuration. “Activate” is the keyword, “activate-based” is the questionmark, and “ICMP” is the command. Press Enter and let’s do a show. And now we can see that this configuration is activated. Let’s do a commit, and let’s go back over here. Before that, let’s clear the logfile from the configuration mode. I’ll use the command “Run clear log messages.” So that’s cleared. Now let’s go back over here. We’ll clear the screen as well, hit the up arrow, and let’s press Enter. And you’ll notice here that it only allows ten ICMP packets per second. It stops any packets for the remainder of that second and then allows ten packets for the next second, and so on. CTRL-C to exit out. Let’s go back over here. Let’s run the command to see the statistics from the configuration mode.
To run any operational mode command, simply prefix that with the run keyword. So Run shows the security screen statistics, questionmark, zone, and zone name. And we can see that it has detected an ICMP flood. Let’s also look at the log file by running “show logmessages,” and we can see here that it has detected an ICMP flood from that source IP address for this destination on the zone and on this interface. And the action was to drop the packet. Let’s do one last configuration change. Let’s do a show here. Let’s change the threshold value from ten to one. So set the ICMP flood threshold at one packet per second. Let’s do a show. So now that the threshold has been changed, let’s commit. Let’s go back to this host here, clear, and let’s try the same command again. And it should only allow one ICMP packet per second this time. Press Enter and we can see that it’s only allowing one ICMP per second. And it’s dropping the last few packets for that second. Control C to exit out. So isn’t that interesting? Screens are very easy to configure and very effective against common attack types. It is best practise to configure screens on the SRX device, at least for zones that are more vulnerable to threats and attacks.