[j-nsp] SRX Screen not working

[Pavel Lunin]

31.05.2013 01:50, Luca Salvatore wrote:
> 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.
The right way is to catch a sample attack packet with flow traceoptions
and check why the SRX even bothers to create a session. If you have no
policy, it should not (accurate within "no bugs" assumption). But who
knows? Only way to know for sure is to trace it.
> Does the session limit screening only apply to TCP/UDP?
Not sure, but I believe no. It should count all active sessions for a
given IP.
> Also what is the definition of an invalidated session?
1. Most common case is a session created for "one wing". When, say, a
TCP SYN passed from client to server, but no response from the server is
yet received. Most probably this is your case. Such sessions have, IIRC,
10 seconds timeout.
2. When a TCP RST is sent by one of the parties and the
"tcp-invalidates-session" option is on.
3. I've heard that, when a normal closing condition arises, session is
also first marked invalidated for a very short period before it's
actually teared down. But I don't know much details about that (can
someone on the list elaborate?) However this should not lead to that
high value of invalidated sessions counter .

As I understand, this is a sort of a queue where candidates for
tear-down are placed. And there is a subroutine (like a scheduler),
which scans through the invalidated sessions and decides if it's time to
pull a particular one down and return resources to the pool or maybe
clear the invalidated state and thus make it active back or for the
first time.

--
Pavel