SRX Defense
If you happen to be using a Juniper SRX Firewall to protect your infrastructure, whether it’s located at the outer perimeter of your network or within an inner security zone, there are native attack prevention capabilities called “screens” built into Junos allowing the prevention of basic network layer attacks. As this is by no means a comprehensive solution or a substitute to protect against sophisticated dos and other advanced layer ¾ attacks, it certainly provides a basic layer of defense from the casual attacker. There are screen options for IP, TCP, UDP, and ICMP which are typically applied to an “untrust” zone within the configuration of the SRX. The “untrust” zone is defined as the area that is not to be trusted (how original), such as the public Internet, or other areas of the network that do not have strict policies set. Out of the box, the SRX sets untrust vs trust zones.
In this review, we will focus on setting common screen options associated with TCP, and we will examine the difference in output from an nmap scan to determine if the target infrastructure has screens enabled or a similar defensive mechanism.
Configure TCP Screen for Syn-Flood Protection
After logging into the target SRX and changing to configuration mode, you will need to edit the screen for tcp:
1.) test@srx-fw# edit security screen ids-option screen-config
set tcp syn-flood alarm-threshold 1000
set tcp syn-flood attack-threshold 500
set syn-flood source-threshold 50
set syn-flood destination-threshold 2048
set syn-flood timeout 20
2.) test@srx-fw# set security zones security-zone untrust screen screen-config
3.) test@srx-fw# show security screen
ids-option untrust-screen {
tcp {
syn-flood {
alarm-threshold 1000;
attack-threshold 500;
source-threshold 50;
destination-threshold 2048;
timeout 20;
}
4.) commit
Verifying the presence of a TCP Screen for Syn-Flood Protection
After screen options has been enabled, you should be able to detect the presence of syn flood protection through a standard nmap scan. Below shows the before and after scenario of when screen options is enabled to protect against a syn-flood.
Before Screen Options Enabled
The output above uses the nmap syntax “nmap -v -T5 -A -Pn <target>”. Notice the host comes back with one port open.
After Screen Options Enabled
The output above uses the nmap syntax “nmap -v -T5 -A -Pn <target>”. Notice the host comes back with multiple ports open.
If you telnet to one of these open ports that is different from what was opened when screen options wasn’t configured (tcp port 443), notice we cannot bind to that port.
This is due to the screen option we set for a tcp flood above. It “confuses” the attacker in thinking the port is open, but it is not.
As there are ways to defeat screen options, hopefully this gives you some basic insight as to how to configure screen options and what the diff looks like from an attackers pov.
