Tcp flood

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Tcp flood

L3 Networker

Hi,

today from 15.10 to 16.10 I received more than 15600 calls from the same IP. The Windows 2012 server already has a function against SYN ATTACK and TCP FLOOD, and I see it on the tcp-rst-from-server log monitor, but they are very small compared to those aged-out. It's been a month since I get continuous attacks and this sends my web application down. These attacks always come from different IPs. Block an IP but then a new one will appear even after days.

Here an example with some hidden fields for privacy.

 

attacco.jpg

 

I need to understand what kind of limit apply to DoS Protection rules. Have I to apply Aggregate or Classified type?

Actually I apply the rule to Aggregate mode with these settings:

 

SYN FLOOD


Action: SYN Cookies
Alarm Rate 30
Activate Rate 100
Max Rate 1000
Block Duration 300

UDP Flood
Alarm Rate 100
Activate Rate 1000
Max Rate 4000
Block Duration 300

 

ICMP Flood

 

Alarm Rate 100
Activate Rate 1000
Max Rate 4000
Block Duration 300

 

Other IP Flood


Alarm Rate 100
Activate Rate 1000
Max Rate 4000
Block Duration 300

 

I did not enable Zone Protection on the interface but I created a rule in Policies -> DoS Protection. I did a test by setting the rule in Protect and I find many logs but I'm afraid it's too restrictive and blocking even those who really need to connect to websites.

Here the screen

flood.jpg

 

I match one only syncookie-sent and this maybe restarted my application!

Besides, I can not understand what the firewall is blocking because TCP FLOOD makes not visible attacker and victim.

 

Please help me!

 

3 REPLIES 3

Cyber Elite
Cyber Elite

ok so with syn cookies you'll want to activate as early as possible since it is a low cost deterrant

I usually activate at 0c/s (this is also the default)

the alarm is only useful to warn you about irregularities so i'd put that closer to the max rate, as not to flood your log file with useless warnings, so at 90-95% of the max

 

in the case of a DoS profile with a DoS policy, an aggregate is going to count all connections to a resource (all sources combined hitting your server) while a classified profile is only going to count unique source/destination connections

 

so you could say

aggregate connections max 40.000  (this number should correspond to what your server is expected to process in total)

classified connections "source-ip only" max 300 (this number should be where client connections become suspicious)

 

this will protect your server from exceeding it's capacity and also protect it from lone flooders

 

DoS rule

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

FYI: UDP and ICMP flood use RandomEarlyDrop, here the Activate Rate is where packets will start to get discarded, so the setup is a little different from syn cookies:

 

activate should be at a point where resources are already taxed and it becomes acceptable to randomly discard packets in favor of resources. The % of packets being discarded increaces the closer the total packet rate gets to the 'max'

(eg , activate is at 9.000pps, max is at 10.000pps, at a packet rate of 9.100pps 10% will be discarded, at 9.200pps 20% will be discarded and so on)

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L0 Member

Even I have this problem in out env. I tried all the options in zone protection profile, but as the max connections are reached, even legitimate traffic is also getting dropped (aged-out); not sure what is the best option or solution to fix this issue

  • 8831 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!