[j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

[Tim Eberhard]

While it's true that like all flow based devices the session table is
susceptible to session table attacks. There are some major built in
protection schemes put into place to limit the effectiveness and
protect the SRX. For the record your proof of concept would take a lot
of pps to fill up the session table given that it's UDP and UDP has a
default time out of 60 seconds...

You have source/destination based session limiting screens which are
highly effective and handled in hardware. Syn flood protection, udp
flood protection and others. Additionally you have the option to
include aggressive age out of idle sessions in the event of the
session table reaching the upper limits of capacity. In that event the
session table will start aggressively removing idle sessions until it
reaches a proper session table size.

While no single feature is a silver bullet there are at least a good
amount of options in the way of protecting your SRX session table and
the SRX itself. Hardening your device to such attacks is critical if
you are going to have any level of access in putting the SRX as your
outside internet facing device.

I 100% agree with Stefan by the way, using stateless firewall filters
for a layered approach is also recommended if you plan on replacing
your DIA router. For the record, using such stateless firewall filters
there is no session built there is no passing go. The packet is just
dropped to /dev/null (or null0 depending how you look at it). No
session is ever created for traffic dropped by a firewall filter.

I hope this helps,
-Tim Eberhard

On Mon, Jun 25, 2012 at 7:06 AM, Scott T. Cameron <routehero at gmail.com> wrote:
> On Mon, Jun 25, 2012 at 6:56 AM, Pavel Lunin <plunin at senetsy.ru> wrote:
>
>>
>>
>> >> This is exactly what happened. The session table filled up. One of
>> >> our security guys took down our edge 650 cluster from a single unix
>> >> box out on the net.
>> > This is what happens when you use a stateful box for an internet router.
>> >
>> > a  router with a covering aggreate and some knowledge of the more
>> > specifc on the interior would inexpensively discard traffic bound for
>> > unreachable destinations.
>>
>> 1. First, sorry for writing this once again, but it's just not the case.
>> Any more or less smart stateful device, whether SRX or anything else,
>> must not create session states for packets falling under a discard
>> route. And SRX does not, I checked. Filling up the session table is
>> caused by either a bug or (rather) a design/config mistake.
>
>
> I'm not sure I agree with this assessment.
>
> The SRX is very quick at disposing of invalid sessions, generally.
>  However, it is easily susceptible to DDOS if you let it reach the session
> table.
>
> Here's some quick POC code:
>
> http://pastebin.com/FjgavSwn
>
> You can run this against some non-operational IPs, but present via, say,
> discard route in your config.  You will see the invalid sessions rise
> dramatically via 'show sec flow sess sum'.
>
> I am no expert, but you can see how quickly this could be abused by someone
> who was intent on disrupting your network -- and they wouldn't have to use
> cheap perl code to do the job.
>
> Malicious user aside, a legitimate application trying to hit an invalid IP
> would give the same result.  Self-made DDOS are very common in my
> experience.  In one case, we had an "updater" application which would
> update drivers and software for our hardware.  It was installed on millions
> of computers.  One day, the service was shutdown and new software was
> distributed with the products.  Many users, however, never updated, and the
> software was very aggressive in calling home.  Without knowing this, a /24
> was pulled down to the SRX, and the updater instantly filled the session
> table.
>
> Scott
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp