Posted on

18-Nov-2007

Forum updates
The OpenVMS forum – using phpBB – has been disabled due to the amount of bogus users that was added using direct access using the web interface. This aought to be prevented by the software, but the current version (2.0.22) has no such facilities. A fellow site supposed an addition to PHPBB named User_Shield that was installed this weekend. The product recommends installation using EasyMOD so in fact TWO modules needed to be installed.

However, it wasn’t very straightforward; the main reason was the way the forums have been set up, but also the security settings which are different on VMS than on Unix.

The forum software is located on one directory, and this can be accessed using the operator web. It requires authentication – for obvious resons – but access sto PHPBB ciode is immediate.To install EasyMod, that is a requirement. Installation also requires the correct URL and domain, a user to access the base directory and WRITE access to all PHPBB files. Part of the installation of EasyMod (and perhaps, other rmodules using EasyMOD) is usage of FTP to copy files to the right places.
Since installation is done using the webserver, and, on VMS, it runs using a non-system account, files not owned by that account need to have W:RE protection (PHP doesn’t take ACL’s into account).

Here, some action was needed.
I added an account WEBMANAGER – normal user account in [200.*] group – that has the base directory as login directory. Next, I made this the owner of all PHPBB files. But since the web server itself is a different group, all files have now be set to W:RWE since some will be copied over in the process of installation.

For the forum, the basic template must be enabled – as stated in the manual.

Next, I could install EasyMod, and using that, installation of User_Shield was easy.

However, though the code is accessible, it could not be used properly in the OpenVMS forum.
This resides on a directory that has no mapping in the server’s configuration, like the blogs, for the same reasons. It’s real location is likewise referenced by a system logical, that is a search list: to the forum’s real location first (holding no more than just the configuration data) and the PHP location second. Because of that, installed additions are accessible by any forum. The data, stored in the MySQL database, will not be present in the OpenVMS forum database. An normal installation requires that the full structure and all files are present – and here, this is not the case. I could copy the whole structure and all files, but I could do all database additions manually, because there were just a few, and using phpmyadmin made it an easy task :).

After the job was done, I disuser’d WEBMANAGER, amd restored the security (all files W:RE). The only thing now is re-eanble the URL on the main page.

There is one more thing
to this that should be mentioned.
Both packages come in ZIP files (at least, I used these) and these seem to be Windows based: each line is terminated with <CR><LF> characters. Moving the files to OpenVMS and unzipping them there implies some errors that can hardly be tracked down due to the fact the files are practically unreadable by humans.
It’s a better way to unzip the files on the PC and copy them to the right position on VMS using FTP, in ASCII mode. It makes your life a lot easier.

Lost images
I found that a number of uploaded files seem to be missing. Luckily, some were still available on the workstation but one, showing a phishing attempt as from PayPal, is still missing and I had to edit the posting that contains the reference.
What caused the loss – perhaps the corruptioin of the disk container?

MySQL does BOOM again
MySQL crashed again, when flusing the data (it looks so) and I lost the reference to the right template. It turned out the watchedog procedure doesn’t work properly if MySQL isn’t up-and-running: there is no entry oin the batchqueue any more…And because logging is disabled, there is no clue on what caused it to disappear…The procedure has now started again.

Posted on

16-Nov-2007

Moving blog files
Tonight I moved all blogs off the normally accessable locations into a place where the blog configuration files cannot be retrieved so easily. Not as text files, that is. You can access the files but they won’t show up as ASCII text since the extension .PHP causes the server to run onto the PHP engine to handle the file. The directory itself cannot be accessed since there is no mapping, so FTP-like access is now out of the question.
It all could be done without interrupting processing: Backup the directories to the new location, redefine the logical and remove the old files. Without restarting the webserver: remember it’s not the Unix Apache derivate named SWS, but the native VMS WASD server 🙂
Since the location like “sysblog” is a logical, referring to the blog directory first, and the WordPress code second, I only needed to alter the definition, on-line and in after that, in the startup procedure. The mapping to disk and directory wasn’t in the webserver configuration so that didn’t need an alteration. Therefore, I didn’t need to reload the mapping. No restart required either: being a eal VMS program, WASD can handle both searchlists and changed logicals on the fly.

Posted on

Hide your data!

If you run WordPress, take care on this issue:

How to access the database is stored in module wp-config.php, in your blogs root directory. This file needs to be readable by the PHP engine, based on the UIC. ACL’s are not enough, the current PHP implementation on VMS doesn’t take these in account.
Not that it would help much, since the PHP engine will run under the webserver’s account (or one closely related, depending on the server). in other words: the webserver will ba able to read the file.
So will any user, if he gains access to the file!
In itself, it doesn’t have to be a problem, but if for some reason, the used has access to the directory itself, your database is wide open.

To prevent this to happen, move database access data: the databnase name, username, password and host at least, eventually the suffix, from wp-config.php and store it in a separate file, that is then included in wp-config.php. Store the file in a location that is NOT accessable over the web.

An example: this is the original wp-config.php:

< ?php // ** MySQL settings ** // define('DB_NAME', 'WPDB'); // The name of the database define('DB_USER', 'MyBlogMgr'); // Your MySQL username define('DB_PASSWORD', 'MyDBPassword'); // ...and password define('DB_HOST', 'localhost'); // 99% chance you won't need to change this // You can have multiple installations in one database if you give each a uniqu $table_prefix = 'prfx_'; // Only numbers, letters, and underscores please! // Change this to localize WordPress. A corresponding MO file for the // chosen language must be installed to wp-includes/languages. // For example, install de.mo to wp-includes/languages and set WPLANG to 'de' // to enable German language support. define ('WPLANG', ''); /* That's all, stop editing! Happy blogging. */ define('ABSPATH', dirname(__FILE__).'/'); require_once(ABSPATH.'wp-settings.php'); ?>

This is the new one:

< ?php require_once('/closet/dbaccess.php'); // Change this to localize WordPress. A corresponding MO file for the // chosen language must be installed to wp-includes/languages. // For example, install de.mo to wp-includes/languages and set WPLANG to 'de' // to enable German language support. define ('WPLANG', ''); /* That's all, stop editing! Happy blogging. */ define('ABSPATH', dirname(__FILE__).'/'); require_once(ABSPATH.'wp-settings.php'); ?>

The included file “closet:dbaccess.php” contains the sensitive data:

< ?php // ** MySQL settings ** // define('DB_NAME', 'WPDB'); // The name of the database define('DB_USER', 'MyBlogMgr'); // Your MySQL username define('DB_PASSWORD', 'MyDBPassword'); // ...and password define('DB_HOST', 'localhost'); // 99% chance you won't need to change this // You can have multiple installations in one database if you give each a uniqu $table_prefix = 'prfx_'; // Only numbers, letters, and underscores please! ?>

Closet is a logical, referring to some location on the system that is inaccesable from the webserver (there is no mapping so the server will not be able to connect to it):

$ DEFINE/SYSTEM CLOSET SECDISK:[SECURED]

and have the directory W:E protection, and all files W:R.

Now the blog is normally accessable, and the sensitive data is hidden for the world.

Posted on

13-Nov-2007

Closed a security hole
The blogs reside on the public area, and when scanning the report on unwanted accessed as derived from the webserver logs, I notices that some way, the full path has been exposed. This means any user has access to the configuration file – that contains database access information. The file needs to be accessable by the web-user (HTTP$NOBODY) – READ at least – to allow database access. There is no esy way to get around it, and certainly not in a short period.
So the only solution was to get the database access data out of that file and store it in a safe place, that cannot be accessed using the webserver directly. It’s a minor change in the PHP code: just include a file containing the sensitive data.
This has been done now -a dn the access data has changed.

This is a change to be proposed to the wordpress team.

MySQL slower – but more stable
At least, I didn’t notice any MySQL breakdown in the past weeks. It’s quite a bit slower – all buffers half as big as before – but considereing the problems encountered, the current preference is stablity above speed.
The batchjob that keeps an eye on MySQL runs every 15 minutes but hasn’t find a MySQL-Server process missing, so far.