Data Center Hub

Mikko Hyppönen of F-secure has suggested that a new top level domain such as .bank or similar would help alleviate problems of phishing attacks against financial institutions.

Unfortunately the suggestion is a solution which does not cure the actual problem: DNS is insecure. This new top level domain has been the subject of much heated debate, and of course much criticism. I believe I have to count myself in on the criticisms side of the debate at the moment. After reviewing some of F-Secure’s rebuttals of the criticisms, here are some issues I have with the suggestion which F-Secure have not yet addressed. Some of the following are quoted from the F-Secure web log and followed with my own comments.

A new top-level domain will not solve the phishing problem once and for all, so it’s not even worth considering.

This is not a silver bullet. A new top-level-domain (TLD) would not be the end of the phishing problem. But it would be a helpful top-level domain and it would stop a particular subset of phishing completely.

    While it is true that some domains are more trustworthy than others (for example.info domains appear to have the highest level of phishing sites on them ), creating a new top-level domain does not actually solve the problem of phishing-it merely creates yet another domain and as such it is dependent upon a weak DNS system. In fact DNS shows up in the list of top 20 Internet Security attack targets for 2006.

This initiative won’t move further until we find a sponsoring organization that starts to push it and proposes it officially to ICANN. This sponsoring organization is what we are trying to find at the moment.

    Of course the sponsoring organization could officially propose this to ICANN; however, ICANN is not a regulatory agency or governing body. Even know there is presently a .pro domain for doctors and other professionals, creating a .bank domain or another authenticated top level domain does not correct the problem of phishing any more of than a new coat of paint will make a house hurricane resistant.

I do believe the suggestion for a new .bank domain is well intentioned and I don’t question the motives of that- however any new solution which doesn’t correct the actual problem it attempts to solve is not a move in the right direction in my opinion. I believe the move of requesting ICANN to expand its authority is one of the main reasons not to ask ICANN to create a .bank TLD. Given the present state of the domain registration business, there’s no way that a data bank top level domain could be sufficiently authenticated given that there will be likely registrars issuing the domain and not ICANN itself. It is not possible for a TLD such as .bank to be run in the same manner as the .gov domain. There’s not a governing body for domain registration yet. Perhaps the banks themselves can create a group and petition for the TLD but this involves investing money on speculation- something most banks are loathe to do.

On Windows Server 2003 with IIS 6.0 when trying to run a perl CGI (cartit.cgi) which has

use Crypt::SSLeay;

I get the error: “Can’t load ‘C:/Perl/site/lib/auto/Crypt/SSLeay/SSLeay.dll’ for module Crypt::SSLeay: load_file: access is denied” in the web browser after first installing Crypt-SSLeay.
I had already installed a precompiled Crypt-SSLeay package for Windows from: http://theoryx5.uwinnipeg.ca/ppmpackages/

Testing the script from a command prompt gave expected results with no error messages but it refused to run from IIS.

It seemed as if this was a permissions issue, however, based on my solution- it may be the source was linked to some dependency of OpenSSL as it was a requisite for the machine which compiled the Crypt-SSLeay Perl module I am using.

This one had me going around for a bit. Here is what I found. You must install the binary OpenSSL for Windows before installing Crypt-SSLeay otherwise the results will not be what you expect. So if you installed Crypt-SSLeay without FIRST installing the OpenSSL
binary version, you will need to remove the package in PPM. You should then install OpenSSL from a source listed here: http://www.openssl.org/related/binaries.html and finally reinstall Crypt::SSLeay from command prompt as below:

C:\ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd

I uninstalled the PPM, installed the OpenSSL binary version, and finally reinstalled Crypt-SSLeay again. Now at the command prompt when I run the script I get a dialog box stating:
“MSVCR71.dll was not found. Reinstalling the application may fix the problem.”

At which point I went to dll-files.com and downloaded the msvcr71.dll file and placed it in a folder that is in the path (Thanks dll-files.com!). Now the script works from the IIS web server as well as the command prompt.

There are times when drives start to kick out hard read errors. On FreeBSD and most UNIX-like operating systems, you get the errors logged so you have a heads-up before the drive simply dies. With the exception of power surges, ESD, and lightning strikes, hard drives seldom die instantly. They most often carp warnings on errors while continually reallocating data to good sectors silently for days or weeks before giving up completely. Once you see hard error messages though, it is time to replace the drive. Don’t reboot the system if it is running and complaining; rather instead get your new drive prepared by doing a base install of the same version OS with similar partitioning and slices of equal size or greater. Then shut down the system. I usually do not try to fsck the drive if the system has not crashed (in the case of hard errors the drive can no longer tell the good sectors of the disk from the bad sectors -so don’t run fsck as it worsens the data loss). After the new drive is prepared in a new machine, you should be ready to try copying the data over from the old. The information here covers rescuing a FreeBSD system but the basic steps should apply to any OS. It’s not meant to be a step-by-step howto but rather a general overview of the process with some details omitted. If you’re attempting to save a drive, you should already have some detailed knowledge of the process involved so take your steps carefully to avoid data loss. When the machine is still running (and it’s a UNiX-like OS) you may want to try a dump of the file systems over the network to a machine with sufficient capacity for the job. For speed however, copying locally seems to be much faster.

I tend to use dd for saving damaged drives by copying the contents of the old drive to a new one. If you have had a serious amount of errors (and lots of time) you can also try the spinrite program to recover data but if you have hard errors you should simply try to get data off drive as fast as possible using dd to do a sector by sector copy.

We use the dd switch ‘conv=noerror’ to prevent it from dieing on errors and ’sync’ to pad input block to the input buffer size. Don’t specify a block size (bs) with no conversion values other than ‘noerror’, ’sync’, and ‘ntrunc’ and you should have no aggregation of short (empty) blocks which might be safer for copying partitions.

1. Do a base install of target OS so you have the partitions ready first or manually create partitions.
2. Boot in single user mode. (boot –s) freebsd
3. Use dd if=/src of=/dest conv=noerror,sync where src is for example /dev/ad0s1g

Mounting and fscking a bad FS seems to only make the drive worse. Move off data ASAP and then tend to the bad/missing files.

Data transfer from IDE to IDE proceeded for me at about 1.9 MB per second with the bad drive in place so copying 60G of data may take a full workday to copy this way.

Other things to try (Linux):

http://www.garloff.de/kurt/linux/ddrescue/

http://www.kalysto.org/utilities/dd_rhelp/index.en.html A front end for dd_rescue

http://www.simplicidade.org/notes/archives/2005/02/recover_day.html a dd_rescue story

Also you can try this:

Install the new drive in the computer either with the existing drvie as the master or do a fresh base install of the new OS same version as you are replacing.

Boot single user at: ok boot –s

Hit enter for /bin/sh shell, fsck –yp, mount –u / , mount –a , swapon –a

Run sysinstall from /stand/sysinstall or /usr/sbin/

Go to Configure-> Fdisk and add the new drive device. (eg ad2 for secondary master)

In fdisk chose A for auto defaults for entire disk, enter Q to quit

Install standard boot manager when prompted

Returning to sysinstall choose Label for disklabel

Copy the label as closely as possible from the original fstab in /etc/fstab

Create your new partitions on the new drive and use M to re-label / (eg /dev/ad2s1a) only mount point to /mnt and all others as regular /var, swap, and /usr. Type Q to quit and exit sysinstall

Now mount the new file systems eg:

mount /dev/ad2s1a /mnt

mount /dev/ad2slf /tmp

mount /dev/ad2s1g /usr

mount /dev/ad2s1e /var

copy the existing filesystem using tar

# tar –cfk - –one-file-system –ignore-failed-read –C / –exclude=’mnt/*’. | tar –xpvf – C /mnt

# tar –cfk - –one-file-system –ignore-failed-read –C /usr . | tar –xpvf – C /mnt/usr

# tar –cfk - –one-file-system –ignore-failed-read –C /var –exclude=’mnt/*’. | tar –xpvf – C /mnt/var

Shutdown and remove the old drive. Boot the new one single user and fsck it fsck –p and mount it. Reboot and all should be well again.

Installing OpenSRS RCL Version 2.95 gives the following error:

Ciphertext does not begin with a valid header for ’salt’ header mode at ./verify_install.cgi line 621

This occurs because CRYPT CBC 2.17 and higher use salt by default. The OpenSRS scripts need to use randomiv headers.

Solution: edit your CBC.pm file to use randomiv as the default header.

In the CBC version 2.2 CBC.pm change line 55 to use randomiv instead of salt as the default.
50 # header mode
51 my %valid_modes = map {$_=>1} qw(none salt randomiv);
52 my $header_mode = $options->{header};
53 $header_mode ||= ‘none’ if exists $options->{prepend_iv} &
& !$options->{prepend_iv};
54 $header_mode ||= ‘none’ if exists $options->{add_header} &
& !$options->{add_header};
55 $header_mode ||= ’salt’; # default

new line 55 should read:

55 $header_mode ||= ‘randomiv’; # default

and of course you should now find this error resolved. Hopefully you don’t have others as well.

I sometimes tire of the constant amateur brute force attempts to break into my machines. One of the ways to limit these attempts in FreeBSD 6.X and PC-BSD as well as other UNIX like OS machines is by using denyhosts from within tcpwrappers in inetd. denyhosts can be configured to automatically deny SSH or ALL services to a particular host which is busily banging away at an attempt to break into your machine. Naturally, good strong passwords are the best way to limit the possibility of brute force breakins. But denyhosts also has the benefit of simply cutting them off and I like that.
On PCBSD you have denyhosts already set up for use except for changing the name of the default config file. On standard FreeBSD you’ll need to add denyhosts from ports or packages (see further down). Depending on your Linux distro you may already have it. You’ll have to research that on your own and remember the file locations here are for FreeBSD.
cp /usr/local/share/denyhosts/denyhosts.cfg-dist /usr/local/share/denyhosts/denyhosts.cfg

then

vi /usr/local/share/denyhosts/denyhosts.cfg

to check the defaults. I allowed mine to fetch data from the sync server

# To enable synchronization, you must uncomment the following line:
#SYNC_SERVER = http://xmlrpc.denyhosts.net:9911

then /usr/local/etc/rc.d/denyhosts.sh start

[root@PCBSD /usr/ports/lang/php5]# tail -f /var/log/auth.log
Apr 13 08:30:54 PCBSD sshd[84345]: Failed password for root from 69.15.145.108 port 55955 ssh2
Apr 13 08:30:55 PCBSD sshd[84347]: Failed password for root from 69.15.145.108 port 55986 ssh2
Apr 13 08:30:56 PCBSD sshd[84353]: Failed password for root from 69.15.145.108 port 56017 ssh2
Apr 13 08:30:57 PCBSD sshd[84355]: Failed password for root from 69.15.145.108 port 56048 ssh2
Apr 13 08:30:57 PCBSD sshd[84357]: Failed password for root from 69.15.145.108 port 56079 ssh2
Apr 13 08:30:58 PCBSD sshd[84359]: Failed password for root from 69.15.145.108 port 56110 ssh2
Apr 13 08:30:59 PCBSD sshd[84361]: Failed password for root from 69.15.145.108 port 56140 ssh2
Apr 13 08:31:00 PCBSD sshd[84367]: Failed password for root from 69.15.145.108 port 56173 ssh2
Apr 13 08:31:01 PCBSD sshd[84369]: Failed password for root from 69.15.145.108 port 56203 ssh2
Apr 13 08:31:01 PCBSD sshd[84371]: twist 69.15.145.108 to /bin/echo “Server sshd denied from 69.15.145.108″

as you can see from the logs- it stopped an attempt within seconds.

denyhosts contains the deamon log entries.

[root@PCBSD /usr/ports/lang/php5]# tail /var/log/denyhosts
2007-04-13 10:36:38,269 - denyhosts : INFO send daemon process a TERM signal to terminate cleanly
2007-04-13 10:36:38,269 - denyhosts : INFO eg. kill -TERM 92229
2007-04-13 10:36:38,272 - denyhosts : INFO monitoring log: /var/log/auth.log
2007-04-13 10:36:38,273 - denyhosts : INFO sync_time: 3600
2007-04-13 10:36:38,274 - denyhosts : INFO daemon_purge: 600
2007-04-13 10:36:38,275 - denyhosts : INFO daemon_sleep: 30
2007-04-13 10:36:38,276 - denyhosts : INFO purge_sleep_ratio: 20
2007-04-13 10:36:38,276 - denyhosts : INFO denyhosts synchronization disabled
2007-04-13 10:46:38,310 - denyfileutil: INFO purging entries older than: Fri Apr 13 10:26:38 2007
2007-04-13 10:46:38,313 - denyfileutil: INFO num entries purged: 0

this is configured by /etc/hosts.allow - make sure you have these entries:

# denyhosts
sshd : /etc/hosts.deniedssh \
: severity auth.info \
: twist /bin/echo “Server %d denied from %h”
: deny
sshd : ALL : allow

If you’re not familiar with twist, it is part of tcpwrappers. The twist directive replaces the requested
service with some other actions. You can also expand with this directive to include the daemon process (%d) and host name (%h)

See the docs at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/tcpwrappers.html
for more details.

On standard FreeBSD 6.x you should find denyhosts in /usr/ports/security/denyhosts or you may add it as a package with
pkg_add -r - you’ll still need to rename the dist config file as above.

Good luck and may your log files now be shorter.

I frequently am asked about what open source web hosting control panels are available for different platforms and purposes.

Here is a list of some I have found in my travels (in no particular order).

ISPConfig for Linux under BSD License

AlternC for Linux under GPL

GNU Hosting Helper for Linux under GPL

VHCS Virtual Hosting Control System

Web-CP is one of only a few CPs which support FreeBSD as well as Linux. While not a fast moving project, it seems directed by individuals who are seasoned professionals.

RavenCore is a relative newcomer but looks like a promising control panel for Linux based hosting.

ZPanel seems to support Microsoft® Windows® as well as Linux. Some of the features listed seem a bit odd such as “track where your clients while they’re logged in” - I am not sure why I need to know this as an owner of the control panel. Anyway, so far this is the only free (open) Windows CP I’ve found - though I don’t see the license terms on the site.

I saved the most frequently mentioned control panel for last. Webmin is the oldest project and most mature control panel for a Linux or FreeBSD server. While it is mature and configurable, it is designed more as a sysadmin helper tool than as a monolithic web hosting control panel. There is a commercially available CP based on webmin named CP+, it is offered by Comodo and is tightly integrated with their Trustix Linux distribution. CP Plus also supports FreeBSD with slightly less automated installation of programs.