Louwrentius

I wanted to see how dificult it is to setup an instant messaging server based on open source software. Now I know that it is very easy, unless you are stubborn and do things your own way. In this example, I'm setting up a small IM server that is only for internal company use, but there is no difference if you want to expose the server to the internet.

First a bit background information. There is an open IETF standard for instant messaging called "XMPP" which stands for "Extensible Messaging and Presence Protocol". This protocol originated as part of the open source Jabber IM server software.

Setting up ejabberd

I decided to use ejabberd which is part of the Debian software archive. It is written in Erlang, but I can live with that. This blog posts documents how to setup the IM server with two accounts that can chat with each other. The configuration I use also enforces the use of SSL/TLS so authentication and all messages are encrypted.

Steps to get things running:

• apt-get update
• apt-get install ejabberd
• cd /etc/ejabberd
• edit ejabberd.cfg

Change the following line to your needs:

%% Hostname
{hosts, ["localhost", "jabber.domain.local"]}.

Also enforce the use of encryption like this:

starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}

Must be changed to:

starttls_required, {certfile, "/etc/ejabberd/server.pem"}

Generating a custom SSL certificate

Security wise, it is very wrong to use the default SSL certificate as provided by the installation package for the server certificate. Anyone with access to this key material can decrypt encrypted communication. So you must generate your own server certificate. This is also required because IM clients may verifiy the certificate against the domain name used within the certificate. If there is no match, it will not work or it will at least complain.

openssl req -new -x509 -newkey rsa:2048 -days 365 -keyout privkey.pem \ 
-out server.pem

So this creates a public key (server.pem) and a private key (privkey.pem) which are valid for a year. Feel free to make the certificate valid for a longer period, this is an example. You will have to fill in some stuff, the most important part is this part:

Common Name (eg, YOUR name) []:jabber.domain.local

You are forced to set a password on the private key, but we want to remove this because otherwise the ejabberd service will not start automatically.

openssl rsa -in privkey.pem -out privkey.pem

Just enter the password you entered earlier and you're done. We now have separate files for the public and private key, but ejabberd expects them in one single file.

cat privkey.pem >> server.pem
rm privkey.pem

Set proper file system permissions:

chown ejabberd server.pem
chmod 600 server.pem

Now we are done. Restart ejabberd to use the new settings.

/etc/init.d/ejabberd restart

Security caveats

Please note that the ejabberd daemon provides a small build-in web interface for administration purposes on TCP port 5280. By default it is not protected by SSL or TLS and cannot be used unless you add users to this part of the confiuration file:

{acl, admin, {user, "", "localhost"}}.

Example:

{acl, admin, {user, "admin", "localhost"}}.

The user must also be registered as a normal IM user as described in the next section.

Warning: it seems to me that this interface is not very secure, for example, there is no logout button.

Furthermore, you might consider disabling the following section:

ejabberd_s2s_in

This prevents your IM server from communicating with other IM servers source. But we are not finished. When you install ejabberd, some other services are also started on the system. It is thus very important that you configure your firewall to block these ports. This small nmap port scan output shows some interesting services:

4369/tcp  open  epmd?
5222/tcp  open  jabber  ejabberd (Protocol 1.0)
5269/tcp  open  jabber  ejabberd
5280/tcp  open  http    ejabberd http admin
|_http-title: Site doesn't have a title (text/html; charset=utf-8).
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
36784/tcp open  unknown

Port 4369, 36784 and 5280 should be blocked by your firewall and not accessible from the internet.

Adding users

It is now time to create some IM users. A user account always looks like an email addres, for example:

peter@jabber.domain.local

To add accounts, use the ejabberdctl utiliy:

ejabberdctl register peter jabber.domain.local <password>

Please note that passwords that are entered on the command line end up in your bash_history file, so beware. Also, users running ps aux may be able to see the command for a brief moment. So be carefull.

By registering two account, you can test your new server.

Additional resources

Nice to know: the domain names used for your accounts can differ from the domain used for the IM server.

If you have a Windows Active Directory domain, you could consider authenticating your users against LDAP.

Other resources: - tutorial 1 - tutorial 2

My router decided to change the device name for some USB storage devices. So /dev/sdc was swapped for /dev/sdd and vice versa. The result was some file system corruption on /dev/sdc, because it was used on a remote system through iSCSI, using a different file system from /dev/sdd.

With regular internal disks, attached with PATA, SATA or SAS, the chances are very small that such an event will occur, but it is possible, especially if you start adding/subtracting disks. With USB devices the risk is substantially bigger.

To prevent your system from mixing up drives because there device names change, use file system labels. All information that follows have been stolen from this location. Since this blog is also my personal notepad, the relevant bits are reproduced here.

There are three steps involved, the third being optional:

1. add a label to the file system
2. add the label to /etc/fstab
3. update grub boot manager (optional)

Add a label to the file system

Setting a label when the file system is created:

mkfs.ext3 -L ROOT /dev/sda1
mkfs.xfs -L BIGRAID /dev/sde

Set label for existing file system

EXT3:

e2label /dev/sda1 PRIMARY_ROOT
e2label /dev/sda1

XFS:

xfs_admin -L DATA1 /dev/sdf
xfs_admin /dev/sdf

Set label for swap partition

mkswap -L SWAP0 /dev/sdb5

add the label to fstab

Example of contents of fstab:

LABEL=ROOT          /         ext3    defaults        1 1
LABEL=BOOT          /boot     ext3    defaults        1 2
LABEL=SWAP          swap      swap    defaults        0 0
LABEL=HOME          /home     ext3    nosuid,auto     1 2

Update the grub boot manager

title server
root (hd0,0)
  kernel (hd0,0)/vmlinuz ro root=LABEL=SERVER_ROOT0 rhgb quiet
  initrd (hd0,0)/initrd.img

Most web applications work like this:

The application uses a single database account to perform all actions. Users are just some records in a table. Account privileges and roles are part of this table, or separate tables.

This implies that all security must be designed and build by the application developer. I think this is entirely wrong. There is a big risk:

In such applications, SQL-injection will allow full control of the entire database.

This is something that is often overlooked. And the solution is simple. The application should not use a general account with full privileges. The application should use the database account of the user accessing the application. All actions performed by this user are thus limited by the privileges of this database account. The impact of SQL-injection would be significantly reduced.

The public part of a website is still using an application account, but the privileges of this account can be significantly reduced. To obtain elevated privileges, a user must first authenticate against the application and thus the database.

Please understand another benefit: it is not required to store username/password combinations of privileged accounts on the application server. The configuration file will only contain the credentials of the unprivileged account. An attacker compromising the application server with limited privileges, won't have access to the database with elevated privileges.

I understand that this solution requires a bit more work to setup at the start, but once implemented, it reduces complexity and improves security so much.

Of course, the security of your data is as good as the hardening of your database server. But that's another story.

Zabbix is a populair tool for monitoring servers, services and network equipment. For monitoring hosts, Zabbix provides an agent that can be installed on the hosts that must be monitored.

Based on the supplied documentation and some remarks on the internets, the 'security' of Zabbix agents seems to rely on an IP-filter. It only accepts traffic from a specific IP-address. However, the protocol that is used between the Zabbix server and agents is unencrypted and does not seem to employ any additional authentication.

With a man-in-the-middle attack, pretending to be the Zabbix server, you would be able to compromise all servers running Zabbix. If remote commands are enabled on these hosts, the damage that could be done may be something you don't want to think about. Or maybe you do. Although it is true that for such an attack to be possible, as an attacker you need access to a system within the same network (VLAN) as the server, but none the less, it is just not secure.

Personally I don't think that Zabbix is suitable for high-security environments, due to the lack of encryption of sensitive data and the weak authentication mechanism.

Zabbix should employ at least SSL as a means for encrypted transport and use a password or shared secret for authentication. Even better would be the use of client-side certificates such as implemented by the system management tool Puppet.

[update]

Please note that Nagios agents also seem to work this way, but I have no experience with Nagios so I can't say for sure.

And Nagios is widely deployed in the enterprise...

In this post I will show you how to compile Handbrake for Debian Lenny. Please note that although the Handbrake GUI version does compile on Lenny, it crashes with a segmentation fault like this:

Gtk: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17

(ghb:1053): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(ghb:1053): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(ghb:1053): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed

Segmentation fault

So this post only describes how to compile the command-line version of Handbrake: HandBrakeCLI.

• Issue the following apt-get commando to install all required libraries and software:

apt-get install subversion yasm build-essential autoconf libtool zlib1g-dev libbz2-dev intltool libglib2.0-dev libpthread-stubs0-dev

1. Download the source code at http://sourceforge.net/projects/handbrake/files/

2. Extract the source code and cd into the new handbrake directory.

3. Compile handbrake like this:

./configure --disable-gtk --launch --force --launch-jobs=2

The --launch-jobs parameter determines how many parallel threads are used for compiling Handbrake, based on the number of CPU cores of your system. If you have a quad-core CPU you should set this value to 4.

The resulting binary is called HandBrakeCLI and can be found in the ./build directory. Issue a 'make install' to install this binary onto your system.