Recently in Virtual Private Servers Category

Normally, a user is someone listed in the system's database file /etc/passwd. There is no need for a flesh-and-bone user equipped with a password and ready to log in. Many users listed in the system database are simply immaterial daemon users, like mysql, listed for the operating system to be able to assign a name (especially a UID in the form of a number) to a running process.

But at least these daemon users own processes, i.e. the mysql database server, and of course, real objects like files and directories are owned by those users. In a well run environment these users do not have a password, so their account cannot be abused by somebody else, and almost always the shell that would be started if someone could log into this account is the binary /sbin/nologin, which does exactly what's on the tin, denying login.

And then there is another breed of users that seem to be ordinary fellows in the system and still do not exist as a user in the normal sense. These virtual users do have the ability to run certain programs, they all have a mailbox in which their private messages arrive and they all need a password to access their home directory, in which all their assets are being stored, but strangely enough there is no trace of them in the system's user base and password file. One can argue that because the virtual users don't have a valid number (UID) they are no users, and in a strict sense this is certainly true. But how can they own files and use a mailbox, just like other users do?

Hunting down the virtual users

We all know that in order to have a mailbox, there has to be a mailbox file (usually in /var/spool/mail) that is owned by the user respectively. And if someone is attempting to read this mailbox, there has to be some kind of authentication, so the password must be stored somewhere. At this point a real (daemon) user comes into play, the postman Tom, who of course has a valid UID listed in the file /etc/passwd, which is in fact 555 on my system.

Tom works at the heart of the mail delivery process, managing the virtual user's home directories and their mailboxes, and he is the only real user necessary to serve hundreds of virtual users on the system.

Virtual home directories and mailboxes

For every virtual user Tom creates a home directory that is used by IMAP to store the virtual user's inbox and various index and logfiles individually.

All these files have been created by Tom for each of the virtual users. In order to provide this infrastructure, we have to make sure that Tom is able to use the virtual user's password when needed, and most importantly to handle the authentication process for them as well. The following lines of code show how the configuration of DOVECOT has to be changed for Virtual Domains.

All passwords are stored in the file /kx/horde/htpasswd in the usual way required by the apache web server. This is important for two reasons, because the dovecot process can use this file to authenticate virtual users by changing permissions to apache for authentication, and simultaneously this file allows other web-based software to access the virtual user's homes with the same password. We will have a look at this later.

Getting all email in the right direction

By now we have managed to install mailbox access for virtual users via IMAP without the need of registration of all these users in the system's database. What we do not have in place is a mechanism to fill up the virtual user's mailboxes with incoming mail.

As you may suspect another important part of the mail delivery process has to be adjusted to ensure that the virtual users who can have totally different email-addresses will receive their mail without hassle. This time we need to add a few lines to the POSTFIX configuration file and we have to create a mapping between the email addresses and the (real) virtual users, who are supposed to read the mail.

The pivotal point here is the text file "kx/dovecot/virtual_mailbox_map" in which each email address is followed by the virtual user's name. But before postfix can use this database to deliver mail it has to be hashed, i.e converted into a database file "kx/dovecot/virtual_mailbox_map.db" with the postmap command below.

Extending our infrastructure

The most important benefit of this system is not to have virtual users in the system's user database and being able to treat them as ordinary users at the same time. As some users tend to choose a weak password this will help to limit the damage that can be done to the system considerably. But once virtual users are established with an email address and password in the manner I have described, it seems to be an obvious idea to use these credentials for another purpose, to organise a file system-like structure for virtual users, to store their data as well. Fortunately such a file storage can be easily set up using the HORDE framework, and in particular the gollem module, that can be configured to use the file system or a MySQL database to store the virtual user's files while making them available for upload and download via a browser-enabled interface.

Have you ever listened to someone who had been fallen victim to a burglary, someone whose home had been broken into by a criminal, entirely ignoring his privacy, snooping around in his personal belongings and making a total mess of everything coming across his way? It is nearly impossible not to feel the pain yourself this person has been through.

And in the online world things are not that different. After all the effort you've put in to getting a Virtual Private (!) Server going, and after furnishing it with something you think is valuable and worth protecting, you can easily get into a similar rage about people starting to break into your VPS the minute you have finished to make it a venerable target for those careless and often thoughtless digital scumbags on the Internet.

A brief look at the file "/var/log/security" shows how your virtual home is under attack right at the moment.



I sincerely welcome any and all attempts possible to counter the disgusting actions of those, who in most cases are not even remotely aware of or capable to understand, what the software does they are (ab)using.

Statistics of a Break-In Attack

Let's have a look at such an attempt to abuse the ssh service at my VPS. It is recorded in the very first hours this machine became visible on the Internet.

During the best part of an hour the attacker had tried 583 passwords to break into my digital home, nearly every 4 seconds a failed ssh connection was recorded in my logfiles, not unsurprisingly targeting the root account. As it turned out, the IP address was not bound to a registered domain name, so it could even be a innocent user's PC taken-over by the attacker.

Counter-Measures

Some people have suggested trying to play "hide and seek" with the culprits by switching the native port 22 which is used by SSH to something like 51679. Even though that may reduce the rate of attacks, it surely won't deter those who use port scanners to find the port used for SSH.

Others rely on periodically updating their "/etc/hosts.deny" file blocking access from IP-addresses that have proven to be suspicious. This may solve the problem for those attacks that always start at the same hosts, but attackers changing their base frequently will still enjoy an open door, once they are using a freshly taken-over host machine.

I have been taking a different approach, namely to change the response of my firewall to incoming ssh requests. I changed the rules so that only 3 attempts per 2 minute period are being served. This reduced my server's susceptibility greatly, as the automated attacks tend to break off after very few tries and don't return.

The following lines added to my firewall script did the job: