Juniper Firewall Syn flood causing High CPU

Hello,  

We have a Juniper SSG140 firewall that faces the Internet.  We get Syn Flood's every now and then that cause a huge spike in CPU and cause packet loss/performace degradation.  Here are our settings.   We don't get too much incoming traffic but enough.  Can you recommend and best practices for us?  Thanks.

set zone "Untrust" screen syn-flood timeout 10
set zone "Untrust" screen syn-flood alarm-threshold 100
set zone "Untrust" screen syn-flood queue-size 5120
set zone "Untrust" screen syn-flood attack-threshold 100
set zone "Untrust" screen syn-flood source-threshold 100
set zone "Untrust" screen syn-flood destination-threshold 100
L8CAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
Juniper has an paper on handling such network DoS, old but useful still.
The "Implementation Guidelines" from the shared pdf by pergr is good start..
 http://jncie.files.wordpress.com/2008/09/801003_protecting-the-network-from-denial-of-service-floods.pdf

Another useful doc below - SYN flood falls under the "Session Table Flood" (see pg 31).
http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_AttackDetection.pdf

Specifically in the table 3 of pg 48, state the recommended default SYN Flood protection parameters for proxying the threshold of traffic. In general below is their approach
• “Source-Based and Destination-Based Session Limits” on page 32
• “Aggressive Aging” on page 34
• “CPU Protection with Blacklisting DoS Attack Traffic” on page 36
• “Prioritizing Critical Traffic” on page 38

There is no good number and it is no "number game" ...  having a baseline on normal traffic helps to differentiate the anomalous and include DoS and DDoS. In this case having STRM helps to have a “birds-eye view” of the entire security posture and setting the baseline to compare

Baseline establishment ....
The first step in evaluating your flood state is to establish a traffic baseline under normal network operating conditions . Normal operating conditions are defined as average traffic and application flow crossing the network edge devices averaged over time while the network is not under attack . The period used could be as short as a day, but a week is a good starting time interval for traffic analysis . The basic idea is to monitor your network traffic and determine protocol distribution, connection rates and average session durations under normal (non-flood) circumstances . Given this baseline information, one can make some assumptions about abnormal traffic patterns
that indicate a traffic flood . Even if there is no firewall in place, simple counters on a router can provide some insight into what’s going on

Also DDoS and DoS is not restricted into the L2-L4 level, L7 such as HTTP flooding is common and primarily past attack such as Slowloris and Slow POST etc hinge on Web Server memory resource based on HTTP handling of request (start/end). So if you looking at that Web Appl FW is to consider ... there is Junos DDoS Secure and Junos Webapp Secure
http://www.juniper.net/us/en/products-services/security/ddos/
http://www.juniper.net/us/en/products-services/security/junos-webapp-secure/
0
L8CAuthor Commented:
Thank you both for the help.  One quick question (well , it might not be so quick), is how to properly monitor the network for a baseline test?  Should you use a separate spanning port and monitor with a packet capture utility?  Or should you log with the Firewall?

Thanks again!
0
Managing Security Policy in a Changing Environment

The enterprise network environment is evolving rapidly as companies extend their physical data centers to embrace cloud computing and software-defined networking. This new reality means that the challenge of managing the security policy is much more dynamic and complex.

btanExec ConsultantCommented:
Logging via firewall is definitely a must specifically for syslog in sense of a norm traffic into a NOC perspective or SIEMS specific architecture, while packet capture either inline tap or SPAN is to understand the session flow or netflow to paint a more complete picture together with the log. But note that SPAN definitely will pump up FW resource so ideally you should take it from the inline tap on the router or switch. Syslog should be piped via a separate VLAN if possible not to impact the main infra VLAN traffic.

Eventually, I see the duration of such capture can be over a few days or week to accurately paint a baseline or simply within hr of the single day depending on whether you want to have a quick but more targeted view or long term. Both is good to build some sort of graphs and static
0
L8CAuthor Commented:
I'm having trouble understanding exactly what happened.  The configuration says that it will allow 100 SYN packets a second, if it goes over that then it will start proxying addresses.  If it proxies 100 SYN packets a second, then it logs every time over a 100 in the syslog.  But the firewall should ALSO drop every SYN packet over 100/second from a single source IP address (is this logged?).

Not to mention we have a 128 session limit per Source IP.  But our log file shows this.

system   emer  00005  SYN flood! From x.x.x.x:35789 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
system   emer  00005  SYN flood! From x.x.x.x:35790 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.

There are over 300 logs in this form in the matter of 1 second from the same IP/ different source port.

But also within those log messages there are a few of these:

Src IP session limit! From x.x.x.x:35873 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 7 times.

So are the thresholds source IP based or Source IP/Port based?  If it was the former, then I think there should be one log file that states the SYN Flood happened 300 times instead of 1 time per port number.   Any advice?
0
btanExec ConsultantCommented:
From the pdf  (see Table 3: SYN Flood Protection Parameters - pg48)
http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ce_AttackDetection.pdf

Threshold is not triggered based on Transport Layer ports (TCP ports or UDP ports).

When the number of SYN segments from the same source
address or to the same destination address reaches a
specified threshold, the security device begins intercepting the
connection requests and proxying the SYN/ACK segments.

• Attack Threshold: The attack threshold is triggered based on the number of requests
to the same destination IP address and ingress interface port (physical or logical port
like a subinterface) per second that are required to activate the SYN proxying
mechanism.

Suppose the attack threshold is 20pps to the same destination IP address and ingress
interface. If there are 20 pps to the same destination IP address but to distributed
incoming interfaces, then the attack threshold is not triggered.

And also option explanation
http://www.juniper.net/techpubs/software/junos-security/junos-security95/junos-security-swconfig-security/id-34128.html


Attack Threshold: This option allows you to set the number of SYN segments (that is, TCP segments with the SYN flag set) to the same destination address and port number per second required to activate the SYN proxying mechanism. Although you can set the threshold to any number, you need to know the normal traffic patterns at your site to set an appropriate threshold for it. For example, if it is an e-business site that normally gets 20,000 SYN segments per second, you might want to set the threshold to 30,000 per second. If a smaller site normally gets 20 SYN segments per second, you might consider setting the threshold to 40.

Alarm Threshold: This option allows you to set the number of proxied, half-complete TCP connection requests per second after which JUNOS software enters an alarm in the event log. The value you set for an alarm threshold triggers an alarm when the number of proxied, half-completed connection requests to the same destination address and port number per second exceeds that value. For example, if you set the SYN attack threshold at 2000 SYN segments per second and the alarm at 1000, then a total of 3001 SYN segments to the same destination address and port number per second is required to trigger an alarm entry in the log. More precisely:

-The firewall passes the first 2000 SYN segments per second that meet policy requirements.
-The firewall proxies the next 1000 SYN segments in the same second.
-The 1001st proxied connection request (or 3001st connection request in that second) triggers the alarm.

For each SYN segment to the same destination address and port number in excess of the alarm threshold, the attack detection module generates a message. At the end of the second, the logging module compresses all similar messages into a single log entry that indicates how many SYN segments to the same destination address and port number arrived after exceeding the alarm threshold. If the attack persists beyond the first second, the event log enters an alarm every second until the attack stops.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
L8CAuthor Commented:
This part is what is messing with me.  You posted from the document:

For each SYN segment to the same destination address and port number in excess of the alarm threshold, the attack detection module generates a message. At the end of the second, the logging module compresses all similar messages into a single log entry that indicates how many SYN segments to the same destination address and port number arrived after exceeding the alarm threshold. If the attack persists beyond the first second, the event log enters an alarm every second until the attack stops.

But we have over 350 log entries from one Source IP during the same hundredth of a second that says it Occured 1 time each.  Here's a truncated example:

2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36115 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36112 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36110 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36108 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36107 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36105 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36103 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36102 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36101 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36099 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.
2013-10-10 10:48:21   system   emer  00005  SYN flood! From x.x.x.x:36100 to y.y.y.y:80, proto TCP (zone Untrust, int ethernet0/2). Occurred 1 times.

If the documentation states it compresses all similar messages into one log entry, then why didn't it do this for us?  Unless Source Port plays into it.
0
btanExec ConsultantCommented:
They never mention for source port though but destination port. May be good time to poll the support
0
L8CAuthor Commented:
I will do that.  Thank you for all of your help.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.