So my friend chats me up

Saying he won $4K on a scratch off lotto ticket. What did he get with his loot? A 1TB SSD drive. It’s amazing a mere quarter century ago this would have gotten you say 10 megabytes on an MFM hard disk that was well less than fast. Amazing how technlogy moves forward. That means that you’re looking at roughly 100,000 times the storage capacity and incredibly better performance. If that happens again in 25 years we will be using drives with 1,000,000,000,000 megabytes of capacity. Provided the robots don’t kill us all first.

SolusVM New Update

Hi everyone, a long anticipated update has finally been released for SolusVM today.

New features in build SolusVM Enterprise v1.2.04

Us at Beyond Hosting have been delaying the launch of Xen Containers simply because there was no way to rate limit them.    It’s also nice to see how they build their PHP modules, everything for WHMCS is ioncube encoded and hard to modify if needed.

The three iptables commands every DC tech should know

Even if you are working for a dedicated company that has fully unmanaged servers there are two Iptables commands you should know for situations that come up. The reason for this is that as a DC tech you are ultimately obligated to ensure client access to their server. This being said, the first command you should know is:

iptables -I INPUT -j ACCEPT

This command makes it so that ALL traffic is accessible by remote systems and provides NO filtering. The reason this is important is because if you do enough DC work someone will lock themselves out of their server. Commonly speaking the symptoms of this are no access, and the trace route’s last hop will be the cabinet switch before their server. When you’re done adding this rule be sure you ping out and if you can ping into the server before returning to the NOC. You can save your self many steps in a day this way.

The other command you should know is:

iptables -I INPUT -s  <sourceip> -j DROP

Where the IP in question is an attacker. Big attacks tend to get null routed however in a lot of cases smaller attacks may be plausible to block at the server especially if they don’t over run the network connection to the server entirely. Script kiddies are also very adaptive so it may be easier to block traffic server side than to add a ton of null routes.

iptables -I OUTPUT -d <destip> -j DROP

This command is the last one in our iptables survival toolbox. The reason this is here is that an out bound DoS can saturate an uplink rather quickly. This can make a machine unable to be SSHed into to isolate and remove the script. If the person is DoSing one IP address and you know it, all you have to do is make it so all traffic going to them is dropped. Even if the script continues to run getting the traffic off the NIC is enough to restore access without majorly disrupting the server further by stopping Apache.

This guide contains some extreme basics of IPtables. The learning curve for it is fairly steep, however with most Linux commands this is due to its intrinsic power.

How to interpret logs

In a previous blog I promised to show how to use pipes to read log files better. This can be an intimidating process to say the least, lets give an example.

[root@DNS01 logs]: ls -lh
-rw-r--r-- 1 root root    0 Mar 28 04:02 access_log
-rw-r--r-- 1 root root 320K Mar 24 22:14 access_log.1
-rw-r--r-- 1 root root 327K Mar 24 03:36 access_log.2
-rw-r--r-- 1 root root  94K Mar  6 21:48 access_log.3
-rw-r--r-- 1 root root 1.7M Feb 28 03:10 access_log.4

Notice I have almost a megabyte of access logs here. This is a sandbox that only I really play on. I’ve got WordPress, Drupal and a few other minor things installed. Nothing special virtually NO traffic. Regardless, when we do:

[root@DNS01 logs]: cat access_log* | wc -l
16176

There are over 16,000 entries! That is a lot of text to go through, and these are TINY compared to what you can see on a production server which is likely millions of lines. Without a good question we will not get a good answer, so we have to know the data we are looking for and how to narrow down your data pool to only the entries you need, or at the very least an amount you can go through manually. Some times this means that you wouldn’t even know the log file that you were looking for. At this point, you could use grep in the capacity

grep searchterm -ilr /logdir/*

and this should give you some file names where you can process data at. I don’t usually have to do this unless I am unfamiliar with the application. If you’re getting an error with a configuration this is a GREAT way to find out what configuration file contains the parameter you need to set.

Getting back to the task at hand, which is how to interpret our findings lets just say that I was looking for some PHP code that was causing trouble. Because network traffic monitoring is set up, I know that I had an outbound flood to the IP address 122.222.233.234. I can grep for the IP in question in the apache logs to find out what and where is happening. These can be set up in a few different ways, so assuming you’re on CPanel I would run

[root@DNS01 logs]: grep 122.222.233.234 -ilr /etc/httpd/domlogs/*

and see if anything came up with this IP address in the actual page title. It would likely only be entries for one or two PHP pages, and they would likely be highly suspicious. Lets say that we found a script called suspicious.php mentioned that had this IP in the get string, and it was mentioned a ton of times in one domain’s log. We could find out how many times this was mentioned by running:

[root@DNS01 logs]: grep 122.222.233.234 -ilr /etc/httpd/domlogs/domain.com | grep suspicious.php | wc -l

and this would tell us the number of times it has been ran. Depending on the attack script this can be thousands of log entries. Lets say we wanted to see if they had been doing anything else on the server, but the suspicious.php access entries were so numerous that we have thousands of lines to search through. Instead of searching through these we would just run:

[root@DNS01 logs]: grep 111.222.254.254 -ilr /etc/httpd/domlogs/* | grep -v suspicious.php

Where 111.222.254.254 is the IP that accessed suspicious.php. This would eliminate any entries that contained suspicious.php from being shown. We can do this multiple times with different terms as necessecary. By the gradual inclusion or exclusion of terms we can process the logs into usable data. It takes a bit of time but you can track compromises, spammers and other server side problems with this. You can even do it in real time. Lets say you had a 503 error. All you would do is run:

[root@DNS01 logs]: tail -f /etc/httpd/log/error_log | grep 

Where is the IP of the computer you are accessing the problem page with. This will filter out any requests by other IP addresses. It would be virtually impossible to use tail -f by its self on a server with high traffic because the entries would scroll too fast. This way it shows only the entries you give. This works great for email sending problems as well, lets say you don’t think your email is being sent out. All you have to do is run:

[root@DNS01 logs]: tail -f /var/log/exim_mainlog | grep 

Where the email is the sending or receiving address. This will show you flow of the email through the server.

How to rebuild an initrd

To start off with, what’s an initrd? This is the initial ram disk that the system sets up to boot from. It has the Linux kernel in it, a basic set of modules and a few other things. After so long in the boot process the system gets switched over to the main partitions and then boots up the rest of the way.

How do we know we have a problem? That’s fairly simple. If we have a system that gives an error pertaining to a “switchroot” and panics we can scroll up and see if the drivers aren’t there. In the most recent case I had to deal with, it was due to there not being any 3ware modules. I have seen this happen in the past with drives moved between systems as well with radically different chipsets (think AMD versus Intel chipsets.)

Switchroot errors can happen due to a ton of reasons, these include the FS not being in existance, files missing from the FS or the modules not being loaded for the hardware in question. Use your head when you get them, but if you seem to have the above problem the solution is pretty simple.

All you have to do is run the /sbin/mkinitrd command. This is as simple as doing something along the lines of:

/sbin/mkinitrd initrd-2.6.18-194.el5PAE.img -v 2.6.18-194.el5PAE

Provided there isn’t a file with that name in the FS, a few moments later you will have a fresh initrd with whatever modules are loaded on the system at the time provided the kernel you are using has them available to it. Pretty cool huh? I will get more in depth with initrd at a later date, you can even hack them to make your own mini OS with.

Pipin ain’t easy (unless you read this guide)

I have gone over more than a few Linux based commands at this point, so I want to introduce a new way of using them; Pipes. Pipes are really cool because they will let you take the command and put its output into another command. There are a nearly infinite amount of ways to use them as well. Enough with the introductions, lets get on to the commands. Lets say that I want to determine the number of connections currently open at the moment on port 80. We can do the command

netstat -anp

And it will give us a distinct number of entries. We are left looking for traffic that is on port 80, and we have a bunch of lines we don’t care to bother with quite frankly. This is where the pipe comes in.

netstat -anp | grep :80

This will show any traffic that is to port 80, or any traffic that is going to port 80 on a remote server. Lets say we have a huge amount of traffic though, and want to just get a count. If you have a high use server counting by hand is a nuisance at best and virtually impossible at worse. At this point we would just throw the results of our grep into another pipe like this:

netstat -anp | grep :80 | wc -l

And then we have a raw number of accounts used on port 80. Pretty neat. Because pipes are an infinitely versatile tool we can use them for dealing with static files or dealing with the server in real time using utilities like tail. Want to know more about tail? Check out my next blog, I’m going to show some of the tricks on server side troubleshooting.