[j-nsp] Juniper SRX3600 have a bug i think

[Phil Mayers]

On 15/05/15 20:27, Cahit Eyigünlü wrote:
> root> show security monitoring performance

This came across mangled for me; all wrapped into one line, so unreadable.

> SRX start dropping packets after 500k pps of the udp attack.

That sounds about right.

The 3600 spec sheet claims ~270k sessions/sec for TCP 3-way handshakes. 
So, I'd expect the policy inspection speed to be about that, so 500k PPS 
UDP seems about right for the box to fall over, for relatively unique 
5-tuples.

Firewalls are not routers. They don't perform well in this kind of 
scenario, IME.

> We can not use threshold limit because it drops the real connections too while under attack.

What is "threshold limit". Do you mean the "screen" options?

> we cannot use session limit because the attack does not create session

Do you mean that you have a "deny" policy, hence no sessions? Or you 
have a "permit" policy, but the session isn't being created for some 
other reason?

The solution to your problem will depend on what the traffic looks like. 
What does the distribution of source and dest IP/port look like in your 
UDP flood?

You could consider using S/RTBH in front of the firewall, driven by 
something like netflow/sflow; have a router eat the traffic statelessly 
before it hits the expensive stateful processing.

We actually use the "screen" function in logging-only mode, and process 
the logs in realtime to do trigger S/RTBH. This allows us to whitelist 
some stuff that tends to false-positive the screens, as well as 
implement better timeout/backoff behaviour, while still using the SRX to 
do the "counting".

TBH you haven't really given enough information.