full-disclosure - DoS protection in N-Tiered Web Apps?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0FD9D979B9535D4890AE309799B6D1E59DA4AC@lansingemail.seqnt.com>
From: mlachniet at sequoianet.com (Lachniet, Mark)
Subject: DoS protection in N-Tiered Web Apps?

Okay, so I asked about this in another thread, but it wasn't really
picked up, and I don't want to let it go.

There is a fairly serious (and obvious) risk of Denial of Service in
many web applications that rely on back-end databases.  As a previous
message stated, on many web apps, small HTTP requests can result in very
CPU intensive queries taking place on the back-end database.  In
addition, large numbers of HTTP requests can "clog the pipe" between the
web logic and the database server, resulting in large backlogs of
queries, and possibly even license exhaustion.  This is no big surprise,
though it might be difficult to stop.  

Maybe there should be a new name - "asymmetrical data query warfare" or
something? (j/k)

The solutions I am aware of include establishing protection at the front
end (requiring authentication, for example) and using fast hardware and
software, and load balancing to accommodate the load.  There are other
options, too, but they all seem to have pros and cons.

However, it seems that a more graceful solution would be to build in
some kind of "gatekeeping" logic into the web application itself.  For
example, creating a state table such that each individual IP address,
session or user ID could only monopolize a single thread between the web
app and the database server.  

At least in this way, you could actually guarantee some SLA parameters a
little bit better than hoping for the best.  TCP/IP QoS wouldn't seem
appropriate here, and the database probably isn't smart enough to know
about sessions, so it would seem that this would *have* to happen at the
application level.  

So, my question is, how are people dealing with this problem, if at all?
Does anyone know of example code that  would perform this function?   Or
another way to accomplish this same goal at a reasonable cost?  I'll be
the first to admit that my own knowledge is lacking here, which is why I
am asking.  Maybe this is already built into several platforms and I
just never heard about it.

Thanks,

Mark Lachniet