Re: Ftp attack

On Tue, Jun 28, 2005 at 10:15:12AM -0500, [email protected] wrote:
> There's no standard for this, so clients use whatever "brilliant" formula
> their developer came up with.  So, for example, some download accelerators
> say "open as many connections as it takes to get me the file in 1 MB
> chunks".   Our FTP site has lots of files sized in the hundreds of GB, and
> so a client like this will abruptly open, say, 200 connections.  As wuftpd
> can't limit number of client connections per IP you're effectively
> defenseless; you can set the max public connections but then though they
> don't crash your server they do DoS other users.

There is a hostlimit/hostcount patch (I have heard that it is included in still
not yet released v. 2.7/2.8). I do not remember where it was available - my
copy is in ftp://sunsite.icm.edu.pl/private/rzm/ .

> On another note, these download accelerators show up in your logs as
> separate downloads with sizes smaller than the entire filesize (that's how
> you can ID them).  But note that the i/c flag is NOT set reliably by them -
> in theory, they'd set it right, and you could tell a download accelerator
> session by it having a batch of i's and one final c.  For a variety of
> reasons this is never the case.  Do not trust it.
> All the log analysis tools out there that do FTP do NOT handle this
> correctly either, and so if you are relying on any of those for FTP stats
> you are getting inflated numbers (as one download accelerator would look
> like 10+ downloads of a single file).  We had to write a custom FTP log
> preprocessor that would try to identify accelerator sessions and boil them
> down into one line for later processing.

Do you mean problems with number of files counting? It should not matter for
counting number of bytes.

R.
-- 
Pluńmy na tę skorupę i pchnijmy ją do głębi, czy coś takiego. o. T. Rydzyk