Pencils down

This post concludes my Google Summer of Code 2010 project. I'm about to write a nice summary including features and status of the VoIP module which will be available either on the dionaea website or on the Honeynet Project (or both :) ). Then, we have to do a bit of code cleanup (get rid of TODO lines not needed anymore, making sure that names and license texts are at the top of each file) so that we can upload the code to Google. In order to make the VoIP honeypot available to other people, there's probably some work (bug fixes, more features and settings) left beyond the scope of GSoC. I'm sure I'll keep working on the code and keep in touch with the folks from HNP.

Incidents

With most of the important (basic) SIP functions in place, the remaining time of GSoC is reserved for logging. That's what makes a honeypot truly useful after all. Dionaea uses so called incidents that can contain arbitrary values and that are logged to a sqlite database. So far, I've written incidents for incoming and outgoing SIP messages plus incoming RTP metadata (so that an analyst can see the whole conversation), as well as additional information about successful and failed challenge response authentications. We'll have to extend dionaea's logxmpp and readlogsqltree script to accommodate these new VoIP-specific incidents.

Working on the details

Looking through the git diff output of last week's work, I notice that I've been doing a lot of work on little features and fixing bugs.Unfortunately, that has stopped the implementation of more features almost completely with the exception of new parameters for the config file.

The biggest problem is the dumping of RTP traffic. It worked fine in the stand-alone client, but dionaea handles connections a little bit different so I'm still trying to figure out how to get it to work (again). It also took me a while to adept the challenge response authentication mechanism so I'm quite positive that RTP dump will be properly working soon as well. I implemented authentication in a more generic way so that all methods of a SipSession instance can use it to authenticate incoming requests. We want to be able to detect all kinds of spoofing or BYE attacks after all.

SIP module integrated

Integrating SIP into dionaea was quite a smooth ride. Writing a mock connection class for the stand-alone honeypot that has the (almost) same interface as dionaea's connection class helped a lot.

My mentor extended dionaea to support pyev (for timer callbacks) and UDP-style sendto(), two features I need for SIP. The timer is for artificial delays between SIP responses to make the honeypot appear more human-like. UDP-style sendto (actually it is setting the remote host and port before calling the connection.send method) is necessary because SIP messages are all going through the same socket, even when multiple clients are involved (the media part (RTP) however uses dedicated channels for each connection).

I'll further improve integration and some features (I might have to hunt down some bugs, particularly those involving multiple clients/race conditions). Testing will happen the week after. GSoC seems to go by quite quickly now.

Successful test integration

This week I had a deeper look at the dionaea source code, particularly the services and python modules part. After some consultation with my mentor, I got my test module loaded and working as soon as it's included in dionaea's config file (serve=["sip"]).

The basic connection class in dionaea is a little bit different from the one I used in the stand-alone client. However, I modeled my class close to dionaea's so there shouldn't be too many differences to slow the integration process down. Next week I'll move the majority of the features to the dionaea module. Then, I'll still have a little bit more time to improve detection of VoIP attacks and dionaea-specific logging.

Dionaea integration starts

After talking to most of my (co-)mentors and people interested in the VoIP honeypot about the features I've implemented in the stand-alone honeypot version over the last seven weeks, it is time to integrate these features into dionaea. Most of the implementation should be straight-forward since I've copied part of dionaea's interface while building the SIP and SDP handler. However, I'm sure there'll be some hiccups.

I'll keep working on the stand-alone client as well, mostly bug fixes and getting the main features right so that I can start deploying it and get as much data as soon as possible.

SIP Digest Authentication

This post is a little bit late because implementing challenge-response authentication took a few days longer than expected. First, I had to figure out how the response has to be calculated. I couldn't find anything in the official RFCs (3261 and 2617) or in the SIP books I've got laying around. I turned to sipvicious and found the complete calculation there (# is the MD5 hash function): #(#(user:realm:secret):nonce:#(request-method:sip-uri)) where user, realm and secret have to be set by the user and sip-uri is simply "sip:user@domain".

I still have to test this against sipvicious and of course against real traffic on the internet -- although I don't have much hope that there's much going on on our /24 subnet in New Zealand. This week is testing week so I hope to finish most of the functionality so that I can start implementing my honeypot as a dionaea module.