Posted on

From China

…with love?
You MUST be desparate to get in contact knocking on the wrong door that often…..

The FTP log shows a massive amount (probably by some bot) trying to access the system over FTP:

%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from 211.155.129.201 at 6-MAY-2008 11:33:49.27
%TCPIP-E-FTP_LOGFAL, remote interactive login failure Administrator
-TCPIP-I-FTP_NODE, client host name: 211.155.129.201
-LOGIN-F-NOSUCHUSER, no such user

and it goes on, and on, and on…: Hundreds of entries.
No answer. Of course not. It might work on a Windows box. This one isn’t 😀

I don’t even HEAR you knocking 👿

The address resides in China:

% [whois.apnic.net node-2]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inetnum: 211.155.128.0 - 211.155.143.255
netname: HDBMAN
country: CN
descr: Haidian District, Beijing, China 100086
admin-c: LH43-AP
tech-c: HL2-AP
status: ALLOCATED PORTABLE
changed: shenzhi@cnnic.cn 20050629
changed: ipas@cnnic.net.cn 20050711
mnt-by: MAINT-CNNIC-AP
source: APNIC

...
inetnum: 211.155.128.0 - 211.155.143.255
netname: HDBMAN
country: CN
descr: Beijing Haidian Broadcast & TV Netowrk Information Co. Ltd
descr: Haidian District, Beijing, China 100086
admin-c: LH43-CN
tech-c: HL2-CN
status: ALLOCATED PORTABLE
mnt-by: MAINT-CNNIC-AP
mnt-lower: MAINT-CN-HDBMAN
changed: shenzhi@cnnic.cn 20050629
changed: ipas@cnnic.net.cn 20050711
changed: ipas@cnnic.net.cn 20051102
source: CNNIC
...

I don’t think it feasable to complain for this single event. Or drop by: I’ll there this weekend, but I doubt it will come ever near this place.

Google keeps trying
once in a while:
%TCPIP-I-FTP_SESCON, FTP SERVER: session connection from crawl-66-249-73-115.googlebot.com at 7-MAY-2008 19:49:19.30
%TCPIP-I-FTP_NODE, client host name: crawl-66-249-73-115.googlebot.com
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_OBJ, object: perl
%TCPIP-I-FTP_CHINFO, TCPIP$FTPC0001F: Failed to set default directory
%TCPIP-E-FTP_BADDIR, invalid directory
%TCPIP-I-FTP_USER, user name: anonymous
%TCPIP-I-FTP_SESDCN, FTP SERVER: session disconnection from crawl-66-249-73-115.googlebot.com at 7-MAY-2008 19:49:20.98

which is obvious since this directory and it’s (outdated) contents have been removed some time ago. And anonymous PTF is no longer on the webpages that Google is allowed to crawl. IS google accessing based on “memory”?

Posted on

06-May-2008

It’s not PHPWASD!
Having some spare hours, I tried the same tests I did yesterday on the most basic PHP code that comes with MOD_PHP: PHP_RULES.PHP. It just this:

$ type cgi_bin:php_rules.php
<?php
echo "<HTML>";
echo "  <head>";
echo "    <title>Mod_Php Rules</title>";
echo "  </head>";
echo "  <body>";
echo "    <p>";
echo "    <h1 ALIGN=\"CENTER\">Mod_Php Rules !!</h1>";
echo "    </p><p>";
echo "    Resistance is futile....";
echo "    </p><p>";
echo "    <hr />";
echo "  </p></body>";
echo "";
?>
$

Now THAT rules out any fancy stuff. But even that didn’t work – same problem as before.
To rule out PHPWASD, I did the same tests using plain, vanilla PHP.EXE. Again, old and new should not be mixed because that is asking for trouble (but now I got at least SOME idea what happened).
Again, using the ‘old’ PHP.EXE and PHPSHR.EXE casued no trouble at all, and using new PHP.EXE and PHPSHR.EXE gave the very same ACCVIO message – properly handled by the software. A mixture of old and new crahed PHP.EXE, but with different causes.

Because this rules out WASD and PHPWASD completely, the issue has been put on ITRC with this log report.
Without latest code, listings and mapfiles, or building tools it’s hard to find out. And time is a scarce commodity.

Why Mark has no trouble on any of his sites, is unclear…

To be continued

Posted on

05-May-2008

More on the PHP ECO-2 update
It seems I was not the only one with problems.
From the WASD mailing list, it seems there has been some change in an interface to PHPSHR routines and Mark daniel has updated PHPWASD to reflect this change. Tonight I downloaded and installed this new version, and linked both the old and new PHPSHR versions (getting two distinct images, of course).

Now I could test more thoroughly than before, and I used the php_info.php script for that, ruling out some potential problems elsewhere.
When linked using the old PHPSHR and using the old one, all is well and the page shows up nicely.
When linked to a different version than run with, PHPWASD simply crashed and the reason (ACCVIO) is found in the logfile only. The screen just states the result is not CGI-compliant.
When linked using the new version and run with it, another ACCVIO occurs but this time, it shows on the screen.

With this result, I enabled debug output and it seems that the PHP engine breaks – somewhere – if logical PHPWASD$INI is undefined. A situation that cannot be handled. But since this logical is typical for the WASD environment, I wonder why this happens. What could be: some fields in this interface could well be readonly or undefined, or defined differently.

I mailed the results to Mark – pushing the problem onto ITRC may not help (though you never know). The logging is available in this location.

To be continued – no doubt.

By the way: the extensions in the kit have been copied to the WASD environment and are used – except the MySQL one. The problem is not within these modules 😉

Posted on

02-May-2008

PHP update
I checked the HP MOD_PHP site tonight ro see if the long awaited update was now available. And indeed, HP has released it silently: PHP1.3 ECO 2. A few issues I ran into seems to have been solved now: The HPARITH error that ocurs now and then seems to be solved, and some other issues.
So I downloaded it, and also installed a new version of PHPWASD. You need to install the PHP update, the files are dated 3-Apr-2008 (the older ones date 16-Sep-2005), copy the files to PHP_ROOT:[BIN] – which is, in my case, NOT the Apache PHP environment – and then @INSTALL UPDATE the WASD PHP engine, it will use the PHPSHR found on PHP_ROOT:[BIN].

Don’t forget to run the PHP_STARTUP procedure. Don’t forget NOT to purge..

WordPress SEEMS to work but when accessing the admin page to enter a new post, it doesn’t come that far. In an attempt to show feeds incorporated in the database by default, access violations are reported, and any other access after that will have the same effect, as shown in the logfile:

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFFFFFFFFF8, PC=00000000001CF540, PS=0000001B
and subsequently; I got:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000000000, PS=0000001B
Later, the first one occurred on different accesses.

It’s not the WASD engine, because after redo the update with the previous PHPSHR (by renaming the latest, erring, version to another extension and re-installing the image) the problem was solved.

Perhalps it’s the MysSQL engine?
Not just that. All extensions need to be copied as well. Not that it helps a lot – It’s no use trying without, as it turned out, Reversing PHPSHR also requires the extensions to be reversed – that is: deleted from the WASD environment.

All in all: WASD 1.3.4 is fine, but a new PHPSHR also means that all changes must be re-applied. Unless, of course, the new MySQL extension is a 4.1.14 as well. But the release notes don’t mention it….However, it also reqquires that this ECO-2 is included in the kit – and the kit is NOT UPDATED.

That means a message to Engineering!

Posted on

01-May-2008

Mail stastistics for April

Total messages    : 4150 = 100.0 o/o
DNS Blacklisted   : 2991 =  72.0 o/o (Files: 30)
Relay attempts    :   50 =   1.2 o/o (Files: 23)
Processed by PMAS : 1109 =  26.7 o/o (Files: 30)
        Discarded :  361 =  32.5 o/o (processed),   8.6 o/o (all)
     Quarantained :  456 =  41.1 o/o (processed),  10.9 o/o (all)
        Delivered :  292 =  26.3 o/o (processed),   7.0 o/o (all)

8 slipped the filter and were rejected by the SMTP itself, and only one survived and showed up. No unexpected false negatives – there were a few but these were new subscriptions and these could be expected.

As usual, logfiles have been archived.

Checking the logs
In the webserver logs, last weeks log contained 235 lines (out of 5750) containing “rejected requestst” – llocations that are probed and do not exist, exploiting product weaknesses. There have been just two attempts to test if the system could be breached or abused over PHP code. Otherwise the same w00tw00t rubble and proxy links that usually show up.

I also checked login failures that I cannot explain. That is: I know when I ran into exhausted passwords, and most of these come from the local network and these can be ignored. This is the ANALYZE/AUDIT output, I left out the lines I can explain. Most of the ones I found in the webserver and FTP logs already.

Nothing new. Using usernames like “Adminstrator” (what won’t wok anyway because it’s over 12 characters in size) show the expected target machine. No way, of course. And systems where “Oracle”, “Postgres” or “Mysql” can hardly be taken serious. Can they? (If so, that sysadmin needs at least an education in basic security before he’s allowed to access the system again – if at all)