It has been some time ago that I have seen this, but it’s all too familiar:
%%%%%%%%%%% OPCOM 3-OCT-2007 08:58:52.20 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: 41.22-244-81.adsl-dyn.isp.belgacom.be
Status: NOPRIV -- File access violation
Object: WEB_DISK2:[public.anonymous.071003094018p]
It is another script: this time it starts with the attempt to create a directory – signalled in OPERATOR.LOG – where the directory is read-only:
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from 41.22-244-81.adsl-dyn.isp.belgacom.be at 3-OCT-2007 08:58:51.62
%TCPIP-I-FTP_NODE, client host name: 41.22-244-81.adsl-dyn.isp.belgacom.be
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK2:[public.anonymous.071003094018p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0001A: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: 41.22-244-81.adsl-dyn.isp.belgacom.be
Accessing directories simply doesn’t work. Mainly, because I didn’t setthings up as a Windows (or Linux) box:
%TCPIP-I-FTP_OBJ, object: /pub/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /_vti_txt/
%TCPIP-I-FTP_OBJ, object: /_vti_cfg/
%TCPIP-I-FTP_OBJ, object: /_vti_log/
%TCPIP-I-FTP_OBJ, object: /_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /incoming/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /public_html/
%TCPIP-I-FTP_OBJ, object: /upload/
%TCPIP-I-FTP_OBJ, object: /wwwroot/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /web/
%TCPIP-I-FTP_OBJ, object: /www/
%TCPIP-I-FTP_OBJ, object: /html/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /~temp/
%TCPIP-I-FTP_OBJ, object: /tmp/
%TCPIP-I-FTP_OBJ, object: /~tmp/
%TCPIP-I-FTP_OBJ, object: /outgoing/
%TCPIP-I-FTP_OBJ, object: /anonymous/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /anonymous/incoming/
%TCPIP-I-FTP_OBJ, object: /anonymous/pub/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
all fail with:
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0001A: Failed to set default directory
%SYSTEM-W-BADIRECTORY, bad directory file format
%TCPIP-I-FTP_USER, user name: anonymous
It all took just over 2 seconds:
%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from 41.22-244-81.adsl-dyn.isp.belgacom.be at 3-OCT-2007 08:58:53.47
Would belgacom.be be able to track the kid?
UPDATE
They did. Not that they can do a lot, but at least they replied.
UPDATE 2
And they stated they will take action to prevent this happening again.
They have send a responding message telling what action is taken upon the abuse-signal: They will track the person down, monitor his behaviour and remove the account on next abuse. I would even have accepted “We won’t do anyting because … “. Perfect! A lot of companies can take Belgacom as an example of how to react properly.