System Administration

Postfix as a proxy to Exchange server

More and more people seem to be using an open source mail server on linux, such as Postfix, to proxy e-mails coming in from the net and relaying them to their exchange server. I know I’ve had this type of setup since January and it has been working really well for me. It gives you the ability to do advanced spam and antivirus filtering on messages, while keeping the easy to use GUI interface for creating exchange mailboxes. When will we get a great e-mail client so we can finally ditch the Exchange/Outlook setup that most businesses rely on? I know I haven’t found a solution that comes close (I’m sorry, Evolution for Win32 needs to come a bit further, and Thunderbird isn’t even close).

Anyway, once you have this system set up (there are some great instructions here, maybe I will cover this more another day), you may wish to sync up your Exchange users with your postfix “relay users” in order to trash messages coming in who are not addressed to anyone on the Exchange server. This will free up CPU cycles on the exchange server postfix server, and also reduce some bandwidth. Fortunately, Exchange 2000 and beyond use LDAP to publish this information. You can use Perl’s Net::LDAP module to grab this information. Chris Covington put together this nice script to grab the Exchange users and post to a file, which can then be postmapped and used in relay_recipient_maps. I hope you find it as useful as I did! [Local Mirror of the Script]

Third Party Drivers in Remote Windows Installation

There is this great software for doing remote unattended Windows installs called, well, Unattended. It allows you to boot/install different windows versions without any intervention which is great if you are doing a number of Windows installs. This is a bit different than MSFN’s Unattended install which mainly is done off of CD media. MSFN’s site is still a great source of information on these types of installs but we are focusing on the network Unattended software since we are too lazy to have to/want to physically be at the datacenter to do the installs!

If the windows included does not include your drivers, then once unattended (I’ll refer to the sourceforge network version of unattended from now on) installs windows, you will not be able to use the network card to access the PC any more. Therefore, you need a way to install 3rd party drivers directly into the install I386 directory on your server. This article explains the process from a CD standpoint. But let me clarify for our network Unattended install.

First you need to locate the driver that the hardware needs to be usable on this system. Once you are positive which driver the system needs, place the files into /usr/local/unattended/install/os/INSTALLDIR/I386/$OEM/$1/Drivers/DRIVERNAME
Where INSTALLDIR is the name of the windows version you are installing (w2k3 for example) and DRIVERNAME is a unique name for the driver.

Now, according to the previous article you may think that you need to modify the WINNT.SIF file in the I386 directory. However for our remote unattended install server, this file is not used. You need to modify the /usr/local/unattended/install/site/unattend.txt file.

In the [Unattended] section, add the following lines if you do not have them:

OemPreinstall = "Yes"
OemPnpDriversPath= "Drivers\DRIVERNAME;Drivers\SOMEOTHERDRIVER"
DriverSigningPolicy = Ignore

Add each driver using this syntax, separate them using the semi-colon. During the install, it will copy the files in the $OEM$\$1\Drivers directory to C:\Drivers, and because we placed the above lines in unattend.txt, Windows knows to use these drivers during the PNP phase of the install.

Also to clarify the driver types, there are 2 different kinds of drivers during the windows install. The TEXT (TXT) mode drivers are used in the initial phase of the install (like where you hit F6 to install 3rd party drivers), and then there are Plug-and-Play (PNP) mode drivers. The PNP drivers are loaded later in the install process once the system goes to set up the network configuration.

Feel free to contact me if you have any questions on this!

Dead linux users?

Not dead as in dead, but dead as in the user has logged out of the system and for some reason their shell is still open. This might happen if your system crashes before you can log out, there are network problems and you are disconnected, or a number of other reasons. This article explains how to log these “dead” shell users out.

I use the command “w” to find out who is logged in and how long they have been idle. Compare this to the “who” command:

# w
07:47:18 up 73 days, 9:15, 2 users, load average: 0.43, 0.17, 0.11
root pts/0 pool-ip-addr 07:44 0.00s 0.04s 0.00s w
root pts/2 pool-ip-addr 07:45 1:26 0.02s 0.02s -bash
# who
root pts/0 Sep 22 07:44 (
root pts/2 Sep 22 07:45 (

You can also see the command they are currently running, and the TTY they are on. In this case you can see I ran the “w” command, so you can tell that pts/0 is the current session – and pts/2 is the “other” connection. You get this information from the “who” command as well, but “w” adds the idle time (which you can get with who -i, actually). Anyway you can can use either one, it is just a matter of preference.

First find the process list:

# ps fax

10585 ? Ss 0:05 /usr/sbin/sshd
16984 ? Ss 0:00 \_ sshd: root@pts/0
16986 pts/0 Ss 0:00 | \_ -bash
17068 pts/0 R+ 0:00 | \_ ps fax
17033 ? Ss 0:00 \_ sshd: root@pts/2
17035 pts/2 Ss+ 0:00 \_ -bash

Look for the sshd line, this is the ssh server (hopefully you aren’t using telnet any more!)

You can see it shows the pts/0 login, and the pts/2 login.

Find the parent process number of the “other” shell that is logged in. In this particular case, the number is “17033”

Kill that process (Note: you must be the root user to do this, use “sudo” or the like if you are in Ubuntu):

# kill 17033
# kill -9 17033

Which will force the other idle shell to log out.

Check “w” again to make sure they are logged out.

Block brute force password attempts via SSH

If you are a system administrator of a linux system, you may find the following log entries familiar:
Sep 15 02:00:30 sol sshd[16364]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53382 ssh2
Sep 15 02:00:30 sol sshd[16365]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53394 ssh2
Sep 15 02:00:30 sol sshd[16366]: Failed password for invalid user test from ::ffff:61.167.x.x port 53396 ssh2
Sep 15 02:00:28 sol sshd[16366]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16370]: Invalid user test from ::ffff:61.167.x.x

Many, many times over. These are caused by an brute force attack from the remote host. Most likely this is another compromised machine, checking your machine for easy to guess username and password combinations. It could be someone manually trying to run a password cracking program on your ssh server too. In either case, the remote system really has no business touching your machine. This situation needs an automated solution to block this IP from even getting to your machine. Doing this real-time is essential as well.

Enter the Free APF + BFD scripts from R-fx Networks. These programs work in conjunction with one another to monitor for brute password attempts on your system, then ban the attacking host.

First install the APF (Advanced Policy Firewall) script [Download]

Then install the BFD (Brude Force Detection) script [Download]

When it finds a host that has tried and failed to log in too many times, or has tried too many users who don’t exist on your system, it blocks them in your firewall and e-mails you a message:

The remote system 61.167.x.x was found to have exceeded acceptable login
failures on; there was 63 events to the service sshd. As such the
attacking host has been banned from further accessing this system. For the integrity
of your host you should investigate this event as soon as possible.

Executed ban command:
/etc/apf/apf -d 61.167.x.x {bfd.sshd}

The following are event logs from 61.167.x.x on service sshd (all time stamps are GMT -0400):

Sep 15 02:00:27 sol sshd[16364]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:27 sol sshd[16365]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16366]: Invalid user test from ::ffff: 61.167.x.x
Sep 15 02:00:28 sol sshd[16370]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:30 sol sshd[16364]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53382 ssh2
Sep 15 02:00:30 sol sshd[16365]: Failed password for invalid user test from ::ffff: 61.167.x.x port 53394 ssh2
Sep 15 02:00:30 sol sshd[16366]: Failed password for invalid user test from ::ffff:61.167.x.x port 53396 ssh2
Sep 15 02:00:31 sol sshd[16370]: Failed password for invalid user test from ::ffff:61.167.x.x port 53412 ssh2
Sep 15 02:00:31 sol sshd[16372]: Invalid user test from ::ffff:61.167.x.x
Sep 15 02:00:32 sol sshd[16373]: Invalid user test from ::ffff: 61.167.x.x

In my experience it works great and is a very easy to install!

Linux: Mount ISO Image as directory

Here is a handy little shortcut I recently figured out (it took me long enough, didn’t it!).

You can mount an ISO image as a directory in linux. Very nice for when you are remote and want to have a CD on that system.

mount -t iso9660 -o loop imagename.iso /mnt/isoimage

Foxit PDF Reader 2.0

Don’t you hate it when your browser locks up because you unknowlingly clicked on a PDF File? Let’s face it – Adobe’s PDF Format rocks but the reader takes way to long to load and also locks your PC up.

Foxit Software just released Foxit PDF Reader 2.0. If you haven’t tried it already, you need to get this software (Windows Only). Trust me, you won’t be dissapointed.

Download Foxit PDF Reader 2.0

Greasemonkey + Duggmirror Script = Awesome

Greasmoney + Duggmirror

Don’t you hate it when you try to visit a digg story and the site has been dugg? Use the greasemonkey firefox plugin and this duggmirror greasemoney script to add three links to each digg entry – the duggmirror archive, Coral NYU Mirror, and the Google Cache of the page, all with a nice graphical interface. It’s easy too:

  1. Install Firefox (you mean you haven’t already?)
  2. Install Greasemonkey plugin
  3. Restart Firefox
  4. Visit the duggmirror script‘s page and click “install this script”. A little box will pop up at the top of the browser screen, asking you for permission to install it.

That’s it! When you visit digg – you will see the extra links next to the post title. It works in any OS that firefox support (I’ve personally tested on Windows XP, Vista, and Ubuntu).