How to Protect your Network with Security Tools For Junos

There are methods to protect and block damage to your network and data. Although there is no single solution for all types of attacks, the following excerpt from Junos Security can help you understand and use the tools available with your SRX.

---

Many different tools are available for different layers of protection. You can use these methods in combination to form a complete layered network security solution. Learning how to properly use the features available to you on the SRX will better protect your network and the performance of your SRX.

Firewall Filters

Firewall filters are stateless filters that can block or drop traffic based on Layer 2 or Layer 3 header information. For those of you who are familiar with the Cisco IOS firewalls, firewall filters are the equivalent of access control lists (ACLs). Firewall filters are applied to the ingress or the egress interface, and you can use them to drop traffic as quickly and efficiently as possible.

---

Note: It’s highly recommended that you apply firewall filters to the inbound port to control traffic before the SRX processes it. Why spend cycles processing traffic just to drop it as it exits the interface?

---

You can use firewall filters to block unwanted traffic altogether. For example, on the perimeter of many networks, firewall filters block large network segments from which attacks tend to originate, such as APNIC; during the days of the SQL Slammer attack, many networks blocked port 1434 to prevent a flood of propagation attempts from infected hosts.

Although it’s possible to block this type of traffic with security policies, it’s simply more efficient to block it with stateless firewall filters. Firewall filters are applied as traffic enters the interface before any kind of session, screen, route, or policy lookup is done, as shown in Figure 7-1. This means the SRX spends as little effort as possible to drop this traffic.




If you experience a large-scale attack that impacts your SRX’s performance, often you can put a firewall filter in place to mitigate and block the traffic more efficiently.

A firewall filter is composed of the following:

Match condition



Action



Interface

---

Note: Firewall filters cannot be used on aggregate Ethernet interfaces.

---

The following snippets show some quick examples of matching different traffic and taking actions. Obviously, firewall filters are very customizable and can be configured in hundreds of different ways. These examples simply show you at a high level the ways in which you can use firewall filters.

In the following output, a firewall filter is used to count ICMP packets and pass them along:

juniper@SRX5800# show firewall filter count_icmp
term 1 {
    from {
        protocol icmp;
    }
    then {
        count icmp_packets;
        accept;
    }
}
term 2 {
    then accept;
}

Here is an example of a firewall filter to block a source network. If a large number of attacks are coming from a netblock, it might make sense to block them at a firewall filter level.

juniper@SRX5800# show firewall filter badnetwork
term 1 {
    from {
        source-address {
            198.133.219.0/24;
        }
    }
    then {
        count badnet;
        discard;
    }
}
term 2 {
    then accept;
}

Here is a quick firewall filter to block the SQL Slammer worm. In this example, anything matching the destination port of 1434 will be dropped to a bit bucket.

juniper@SRX5800# show firewall filter block_slammer
term 1 {
    from {
        destination-port 1434;
    }
    then {
        discard;
    }
}
term 2 {
    then accept;
}

Screens

A screen is a built-in tunable protection mechanism that performs a variety of security functions to keep the network safe. Screens are extremely efficient and can be tuned to operate in a small enterprise or in the largest carrier networks. Screens are widely used to add additional protections both at the edge of the network and to internal segments to protect the network from attacks and internal misconfigurations that could impact network availability. Screens are good at detecting and preventing many types of malicious traffic.

Screen checks take place very early in packet processing to make mitigation as efficient and fast as possible. Although they take more processing power than a firewall filter, they are able to look deeper into the packet and at the entire session flow, essentially enabling the SRX to block very large and complex attacks. On the higher-end SRX models, many of these screens are handled in hardware, so the traffic is dropped extremely close to the ingress interface.

When you compare the packet processing in Figure 7-1 to that in Figure 7-2 you may notice that the screen checks take place on both the slow path and the fast path. Once a session is permitted by policy and is established, the SRX continues to monitor that connection for signs of any malicious traffic or flooding beyond its preconfigured thresholds. If it sees any malicious traffic, it blocks and drops the packets.




Screens are evaluated on the inbound zone. So, as a session is created, only the source zone’s screens are applied to the traffic. When traffic comes into the Untrust zone destined for the Trust zone, only the Untrust screens are evaluated.

Screens are grouped into screen profiles, and those profiles are then applied to a zone. This is different from the NetScreen way of applying screens and allows for a single profile to be applied to multiple interfaces.

---

Note: Be careful when designing screens, as even return traffic will not be evaluated by the Trust’s screens since the traffic is a part of the initial session that was created with a source zone of Untrust. Additionally, you can use alarm-without-drop when deploying any new screens to research what traffic would potentially be dropped by the screen profile.

---

Security Policy

Security policies are stateful and can drop traffic based on Layer 3 header information. They are less efficient than firewall filters and screens, but they can be more powerful in terms of evaluating entire flows of traffic at a Layer 3 level, and thus enforce states based on that information, as shown in Figure 7-3. You can use security policies to allow certain types of connections from specific sources or networks.




Say you wanted to block port 1434 inbound, but you needed to allow the network’s SQL servers to initiate communication or allow a specific host inbound. In this situation, a firewall filter might not be the best option; the easiest solution would be to write a security policy allowing the traffic from the internal trusted SQL server outbound. This would permit return traffic for any SQL connection initiated from the internal SQL server, but would still deny any inbound requests from the outside.

IPS and AppDoS

IPS and AppDoS are the most powerful, and thus, the least efficient method of dropping traffic on the SRX, because IPS and AppDoS tend to take up the most processing cycles. That’s because they take place after the policy lookup (see Figure 7-4) and they look deep into the packet or the entire packet flow to try to determine if the traffic is malicious.




IPS and AppDoS have the ability to dig deep into the packet flow and compare it with known attacks or known patterns of attacks. This enables the SRX to block attacks all the way up to Layer 7 flow information.

For example, you can use IPS instead of dropping all inbound port 80 or HTTP traffic into your network so that you can drop malicious attempts at performing a SQL injection attack that could potentially compromise your backend databases.

AppDoS, on the other hand, has the ability to look at patterns of traffic-and-block based on known behaviors. For example, in a DDoS attack with legitimate infected hosts or a botnet, a protection mechanism such as a SYN cookie or SYN proxy just isn’t enough because the infected hosts will respond to the SYN-ACK. Instead, AppDoS can evaluate the traffic patterns and determine that these 10,000 hosts are all doing a simple HTTP request every two minutes. Since it’s not normal human behavior to wait precisely 120 seconds before repeatedly requesting data, the AppDoS process starts blocking those attempts from getting to the internal server, mitigating the DDoS attempt.