Re: Ftp attack
[email protected] Tue, 28 Jun 2005 11:08:08 -0500
| Newsgroups | gmane.network.ftp.wuftpd.user |
|---|---|
| Message-ID | <OF9A998CF8.9483EDAA-ON8625702E.0058249E-8625702E.00589B86@natinst.com> |
Yes, I mean counting number of files downloaded. We use our FTP site here
for lots of things that business users want reporting on - how many times
did this or that driver or demo software get downloaded, for example.
Number of bytes, they don't care about. If you had a list of all the files
and their size, you could make a stats program that would "do the math" and
figure it out, but that is actually kind of thorny (what happens when they
update the files and sizes change, etc.).
Ernest
Rafal Maszkowski
<[email protected]>
Sent by: To
owner-wuftpd-ques [email protected]
[email protected] cc
Gopinath Rao <[email protected]>,
[email protected],
06/28/2005 10:59 [email protected]
AM Subject
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