[j-nsp] SRX Screen not working

[Luca Salvatore]

Thanks for the info. The attack we recently saw was using IP protocol 3 (GGP) which is not specifically permitted so I'm unsure how it was allowed to create a session in the first place.

Does the session limit screening only apply to TCP/UDP?

Also what is the definition of an invalidated session?



-------- Original message --------
From: Pavel Lunin <plunin at senetsy.ru>
Date: 30/05/2013 10:37 PM (GMT+10:00)
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SRX Screen not working



30.05.2013 04:41, Luca Salvatore wrote:
> However, we recently had an attack on one of our customers where there was around 400,000 sessions to a single IP address, as shown:
>
> show security flow session summary destination-prefix 202.x.x.x
> node1:
> --------------------------------------------------------------------------
>
> Valid sessions: 5
> Pending sessions: 3
> Invalidated sessions: 384356
> Sessions in other states: 0
> Total sessions: 384364
>
> Any idea why the screen wasn't blocking this?

Most likely invalidated sessions just don't count. To clean up the
session table you better use the aggressive-aging feature. Session
limits per source/destinations are useful when you need to limit users
with a given number of sessions (say, a single torrent client can open
tens of thousand of connections if not limited), but are pretty useless
for DDoS protection (as most of the screen options are though, see below).

Also check out the icmp/udp/syn-flood screen options. On HE SRX the
flood-protection options are performed in hardware (NPC) in contrast to
the session-limits, which are done by SPC, as the NCP have no idea of
what a session is. It might require some basic magic to set the
parameters, as the flood thresholds are measured in pps/cps in contrast
to the number of concurrent sessions. But if you know the mean session
length, which is quite a stable value for a given service and easy to
figure out with session logs, it's worth nothing to calculate the CPS
rate by division of the number of concurrent sessions by it. Take care,
syn-flood parameters are applied in a bunch, so if you leave some of
them unconfigured, you'll get the default values applied, and most of
the are inappropriate for anything from the real world.

This said, the screen options don't much help to protect real services
against real DDoS, as they only narrow down the hole and move the jam a
little further from the server but are unable to distinguish legitimate
packets from the attack. However they are still useful to protect the
firewall itself (just a bit more advanced loopback policers).

--
Pavel
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp