Monday, October 13, 2008

Smart-ISP Configuration for Postfix.

note: This is another 'no-brainer, don't forget this again' type post, but I thought i'd put it here incase anyone else can make use of it.

Recently, I was told that a client needed to forward all their corporate mail via their local ISP and that I should set that up for them using their existing, internal-only mail handling Postfix server.

The key additions to their /etc/postfix/main.cf file was (aside from configuring SASL, which you should do anyway and setting the relayhost parameter correctly) was:


+++ mydestination =
+++ local_recipient_maps =
+++ local_transport = error: no local delivery service


and:


+++ myorigin = the outbound domain name you need.


Then, you need to comment out (with a #) the local transport method in your /etc/postfix/master.cf file.

Remember that, brain!

Friday, October 10, 2008

Clickjacking, 1999 Called...

Betanews isn't something I read often anymore, but this article intrigued me.

It's amazing that after nearly 10 years of active development on the web, standards and the rest -- and the best idea people can come up with for preventing clickjacking is using security=restricted to break frames (aka. frame busting code).

Using mod_security, you can at least write filtering rules that eliminate iframes and other annoying content at the server level and for Firefox users, NoScript does an excellent job of handling it at the desktop level (after, of course enabling the "Forbid IFRAME" option.)

For Internet Explorer users, I don't know what to tell you -- something tells me that's why the Internet remains as it is.

I often wonder if the whole IFRAME tag will be removed from HTML 5.0 -- with all the forward-thinking ideas that CSS 2.1 and 3.0 bring to the table, the only people seeming to use frames on new pages now, seem to be those wishing to exploit it.

Saturday, October 4, 2008

VSFTPd Configuration for Non-Interactive Users

note: This article is intended for a technical audience -- you should use extreme caution when modifying a production system -- caveat emptor.

This is one of those 'it's not broken until you trip over it' things that I wish i'd known about earlier, in posting it here -- i'm hoping other people can find it without wasting the amount of time I did.

So, I had reason to set up a new VPS box with the LAMP stack, SSH/SCP and VSFTPd for FTP use -- my usual command says something like:

useradd -n --gid www-data -s /bin/false [username]


In a nutshell, this:



  • Does not create a new group specific to the user.


  • Makes the user's primary group www-data (useful for users being able to access / upload / modify their own web code).


  • Sets the default shell to /bin/false, which does not allow the account to login interactively.



However, when you use an FTP client, it bails out with a 530 error, telling the user either their username or password are wrong.

So, the next step is to reset their password and try again -- nope, no difference.

Try changing the shell from /bin/false to /bin/bash with chsh though:

chsh -s /bin/bash [username]


... and everything works correctly.

We don't want to use /bin/bash though, because (amongst other things) it allows interactive logins via SSH or the console, which poses a security risk for the other users of the box.

Ubuntu & Red Hat (and probably a whole bunch of others) include the nologin command, which does exactly what we want (provides a message that the user cannot login, and exits).

OK:

chsh -s /sbin/nologin [username]


Try FTP.

It still errors.

As it turns out, the reason it errors is due to it not being included in the /etc/shells file that VSFTPd and other system daemons use to determine if your shell is valid.

Turns out, it's a very easy thing to fix -- simply:

echo /sbin/nologin >> /etc/shells


note: Some distributions ship this as /usr/sbin/nologin -- you may wish to run whereis nologin first to determine where your copy is.

Try FTP again.

:)

Thursday, October 2, 2008

Disabling Control-Alt-Delete on Linux Servers

A colleague rebooted a server unintentionally by having the keyboard plugged into the wrong machine (or, more correctly, typing on a keyboard not connected to the box he was looking at)

After the users swore at him a little, he rang for advice -- luckily, in these days of event driven machines, on a recent Linux distribution (RHEL 5 / Ubuntu 8.04) disabling the C-A-D on critical machines is easy.

First, open /etc/event.d/control-alt-delete.

Now, change the line:


--- exec /sbin/shutdown -r now “Control-Alt-Delete pressed”


To:


+++ exec /bin/echo "Control-Alt-Disable has been disabled"


Save the file and restart the machine, the next time you press Control-Alt-Delete, you'll get a nice message saying things were disabled, rather than a bunch of angry users.