1. Setting Up a Jabber Instant Messaging Server |_Http-Title: Site Doesn't Have a Title (Text/html; Charset=utf-8).

    Sat 05 February 2011

    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-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

  2. Parallel / Distributed Password Cracking With John the Ripper and MPI

    Sat 05 February 2011

    This article has been updated to reflect the changes for John version 1.7.8 as released in june 2011. The most important change is the fact that MPI support is now integrated in the jumbo patch.

    The original John the Ripper off-line password cracker only uses a single processor (core) when performing brute-force or dictionary attacks.

    JtR does not use multiple cores (or machines). However, there is a patch available that enables support of MPI. MPI allows you to distribute the workload of a program across multiple instances, thus cores or even machines, but your application must support it.

    The fun thing with MPI is that it is very easy to create a password cracking cluster. But for now let's just focus on using all these unused CPU cores to help us with cracking passwords.

    I am using Ubuntu and Debian Linux as my platform but Mac OS X works also perfectly.

    install MPI support

    Note: Mac users have mpi support installed by default and don't need to install this.

    • apt-get install libopenmpi-dev openmpi-bin

    download John the Ripper with extra patches

    • Get the john-1.7.8-jumbo-2.tar.gz file.

    extract John & edit the Make file

    • tar xzf john-1.7.8-jumbo-2.tar.gz
    • cd john-1.7.8-jumbo-2/src
    • uncomment the following lines in the Makefile:
      CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT`
      MPIOBJ = john-mpi.o`
      

    Compile John the Ripper with MPI support

    • Run make and choose the most appropriate processor architecture. Example:
      make linux-x86-64 (for 64-bit i386)
      make linux-x86-sse2 (for 32-bit i386)
      make macosx-x86-64 (for 64 bit Mac OS X)
      

    Test john the Ripper

    • cd ../run
    • ./john --test

    Look at the benchmark values of the first test and remember them. Now let's see if MPI does any better:

    • mpirun -np [number of processor (virtual) cores] ./john --test

    Let's asume that you have an iMac 27" with a Core i7 with 4 real cores and hyper threading enabled. This will provide a total of 8 virtual cores.

    • mpirun -np 8 ./john --test

    If you notice a significant increase in performance, you know that MPI is working properly.

    Some benchmarks without and with MPI support (Traditional DES)

    These are the benchmark test results when using a single core on an old Nehalem Core i7 920:

    Many salts: 2579K c/s real, 2579K c/s virtual
    Only one salt:  2266K c/s real, 2266K c/s virtual
    

    These are the benchmark test results when using MPI and thus all 8 cores:

    Many salts: 11015K c/s real, 11015K c/s virtual
    Only one salt:  9834K c/s real, 9834K c/s virtual
    

    And just look at the performance improvement when we overclock from 2,66 to 3,6 Ghz:

    Many salts: 15004K c/s real, 15004K c/s virtual
    Only one salt:  13232K c/s real, 13232K c/s virtual
    

    That is very significant. Now admire how the Core i7 920 @ 3.6 Ghz is blown away by the Sandy bridge based Core i7-2600 @ 3.4 Ghz:

    Many salts: 20007K c/s real, 20209K c/s virtual
    Only one salt:  16881K c/s real, 16881K c/s virtual
    

    Setting up an MPI cluster

    MPI clustering is based on using SSH keys. There is a single master that uses all nodes to perform the computation. The nodes are put into a text file nodes.txt like this:

    node01  slots=2
    node02  slots=2
    node03  slots=4 
    node04  slots=4
    

    In this example, node 2 and 3 are dual-core systems, while node 3 and 4 are installed with quad-core processors. You must create an account on all your nodes with the same name that is used on the master, when running the master process. You also must generate a private SSH key and distribute the public part as the authorized_keys file to all nodes. This is outside the scope of this post. Please note that the SSH private key should be loaded with ssh-agent if used with a passphrase, or do not configure a passphrase on the key. If you do not use a pass phrase, understand that anyone with access to the key can access all nodes.

    You may also have to put the nodexx entries in your /etc/hosts file if the names cannot be resolved by DNS.

    Now I'm assuming that you are able to ssh into all nodes without requireing a password, thus ssh is properly setup.

    * mpirun -np 12 -hostfile nodes.txt ./john --test
    

    Now you should see increased performance, beyond the limit of a single host.

    Some benchmarks

    I ran a password cracking test on some data using a large dictionary. These are the performance differences when using all 8 cores of my Core i7 920 instead of just one:

    single: 0:00:04:48      c/s: 11192K
    mpi:    0:00:01:26      c/s: 46568K
    

    The performance increase is significant.

  3. The Downside of 120 Mbit Broadband Internet

    Sun 30 January 2011

    My Dutch ISP Ziggo provides internet access through DOCSIS cable modems. They are now capable of providging 120 Mbit downstream and 10 Mbit upstream, for an affordable price.

    In a way this is mind boggling. Most people have 100 Mbit home networks that are not capable of handling full capacity. You need at least gigabit gitabit network connectivity on your router and internal network.

    But there is a problem with all this bandwidth mayhem:

    It is useless.

    The only time I see the full 120 mbit in use is when I do a speed test, or when my mac is downloading system updates. Regular downloading (ISO's, big files from web pages), usenet, bittorrent, they cannot provide content with at the speed my connection is capable of.

    The bottleneck is no longer the connection to the home. The whole internet is now the bottle neck. The content providers are the bottle neck. They cannot seem to cope with this use increase in client side bandwith capacity. They often seem to cap users at a specific download rate, that is way below full capacity. Although the connectivity is relatively cheap, if you can't use it, why pay for it? So downgrading to let's say 50 mbit until content providers are able to handle higher speeds seems the smartest thing to do.

    I must say that I think that content providers are the weakest link. But I cannot be sure. It may be possible that the ISP network, especially their transit links, are the limiting factor. If anyone knows more about this, I'm interested.

Page 41 / 73