GSoC 2016 – Rumal take 2

The Honeynet Project was accepted once again as a Mentoring Organization for Google Summer of Code 2016, and we are extremely proud of this.

Rumal was developed during GSoC 2015 by Tarun Kumar, and is now in its early alpha stage. We are also working on a Dockerized version to make things even simpler to install and test.

As you may know, Rumal is composed by two separate projects, a front-end and a back-end. You can find a detailed description about both of them in this other blog post, and a picture of Rumal’s general architecture can be found below.


Both front-end and back-end still need a lot of work before they can be used in production: here are some points we would like to investigate during GSoC 2016.

  • Both front-end and back-end should avoid using two different databases each (MongoDB for Thug’s results and a relational database for Django’s users and models). We should consider dropping the relational DB and using Mongo for authentication/authorization. Some further readings here and here.
  • Communication between front-end and back-end now happens through a set of rest APIs; this should be changed to use some messaging queue system such as RabbitMQ or Redis. This would avoid polling loops with sleep times, which introduce a lot of delay.
  • The enrich daemon in the front-end project supports plugins. The current interface for plugins is powerful, but it may be improved both in the python part and in the visualization part, giving plugin writers more control about how their data is generated and shown to the end user.
  • The enrich daemon should also be able to process multiple tasks in parallel. Processes should be used instead of threads whenever possible.
  • The backend daemon run_thug is now using the subprocess Python module to launch Thug in a dockerized environment. While this works pretty well, we may want to look into Docker’s own python API instead.
  • Visualization of analysis results should be thoroughly tested with real analysis data, and adjusted to give a better idea of what the real outcome is. (e.g. is that site actually malicious or suspicious? what are the key indicators of compromise?)
  • The whole code base – specially the JavaScript code used in the front-end’s GUI – needs some rethinking, some clean-up and a better exception handling.
  • Thug supports analyzing sites through proxies. Proxy support was kept into account while developing Rumal’s GUI, but it still needs to be implemented in the code.
  • Rumal was designed to serve both as a stand-alone GUI to be run on a single machine, but also as a sort of social network or collaboration tool where multiple users can share analyses, comments, etc. This part still needs to be fully implemented.
  • One of the main features we thought about while designing Rumal was the ability to search among different analyses to find similarities and differences, but also to compare two or more analysis results in a visually descriptive way. This part still needs to be fully implemented, too.

Also, the lack of a structured documentation is a problem that may stop people from trying out Rumal and contributing to it. We definitely need to address this in GSoC 2016.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s