FTP distributed denial of service attack (fwd)
grunion at NRAO.EDU
Mon Mar 25 02:52:39 GMT 2002
I'm not quite sure how to say this... but I feel strongly that a report
needs to be made.
One of NRAO's main ftp servers (ftp.cv.nrao.edu, currently 22.214.171.124)
has experienced a fairly intense and sustained distributed denial of
service attack since about 10:30pm US/Eastern last Wednesday night. We
disabled ftp service on Thursday morning, set up an alternative server the
same day, and blocked port 21 to that IP at our gateway router.
Looking at the router deny logs and at the counters in the router itself,
it seems that about 1 in 10 deny packet is being logged. Over the period
Mar 21 12:46:48 through Mar 23 04:02:00, there were 113313 "denies"
logged. These came from 2640 unique IP addresses, the top 10 offenders
#pkts IP Address
The "flood" continues despite my attempt to contact the responsible ISP
for the top two contenders (europeonline.net; either they or the
downstream company has been "declared bankrupt") and clearly I cannot
reasonably contact the ISPs for the remaining 2636 addresses (4 were in
the 126.96.36.199/24 block).
The origin of this seems to be an attempt to use our server to distribute
warez. About 18 hours before this barrage began, someone uploaded three
files to an "Incoming" area on our ftp server. We have these incoming
areas set up as lockboxes; you can write but not read (standard feature of
ProFTPD). Two of the files were windows registry editing scripts, the
third was a self-extracting zipped archive of a proprietary OCR scanning
package (probably with the license keys unlocked -- my speculation).
About 12 hours later, an additional file was deposited, one that contained
a URL= that pointed at the deposited "warez". And a few hours after that,
the barrage commenced. It did not take down the server (proftpd by
default throttles such attempts by limiting the max # of instances of
itself to 30) and had virtually no effect on the other (web) functions of
the server. But it did render ftp service to the system virtually
Less than an hour after the barrage commenced, we got a complaint from a
"user" on a directv/telocity connection that he/she could not get the
deposited file(s). We have not answered this "complaint" (yet) but have
contacted directv and exodus.
At this point, I'm at a loss as to what to do. The contact I had with
europeonline did indicate the source IPs in these packets are not forged.
I suppose we could put a honeypot of sorts in place; put a replacement
file in "the" incoming area, allow anyone to get it, just make it do
something harmless (or nothing, make it a block of /dev/zero), or a mail
message to the vendor of the stolen software... but I don't want the
server to melt down either (it's pretty robust, but every machine has its
Have you heard of any other reports such as these? If so, I'd really like
to know and to share strategies for an effective response. If not, well,
now you know about this one!
- Pat Murphy
Division Head, NRAO/CV Computing
NRAO Computer Security Committee
NRAO Abuse Group
------- end -------
More information about the unisog