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 <routeh...@gmail.com> wrote: > On Mon, Jun 25, 2012 at 6:56 AM, Pavel Lunin <plu...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp