Rumal, a web GUI for Thug
22 Feb 2016 Pietro Delsante gsoc rumal thug
Rumal was developed by Tarun Kumar during the Google Summer of Code 2015 program, and its goal is to provide a web GUI for Thug. Rumal’s architecture includes a front-end and a back-end: front-end module currently includes two stand-alone daemons and a web server. The latter provides the GUI for Rumal, letting you submit new URLs and browsing results, and it uses two different databases: MongoDB for Thug’s results and metadata, and a relational database for everything that uses Django’s ORM (e.g. users, groups, etc). Analysis tasks also make use of Django’s ORM, and the MongoDB collections are only used to store the final results.
So, once you submit a new URL for analysis, the front-end creates a new Task object, assigning it the initial status value. The front-end daemon (fdaemon) periodically checks the database for new tasks and submits them to the back-end using a set of REST APIs; then, it starts polling the back-end’s APIs for the analysis results. When the analysis is complete, results are retrieved and stored to the local MongoDB database, along with any files downloaded during the analysis, and a full packet capture (pcap) of the network traffic generated by Thug. The task’s status is then updated and marked as retrieved (or failed).
At this point, the third daemon (enrich) takes Thug’s results from Mongo and enriches them with metadata provided by a set of specific plugins: for example, one takes all IP addresses seen during an analysis and performs a WHOIS query on them, while another plugin performs a GeoIP lookup. A third plugin runs the PCAP through an external service (PCAPOptikon) that analyzes it with Suricata IDS.
The back-end module is pretty simple. The web server hosts a set of REST APIs that let the front-end programmatically submit tasks and retrieve results. MongoDB is used by Thug to store its results, while the relational database is used by Django to store tasks, API users and keys, and so on. The back-end daemon (run_thug) reads tasks from Django’s ORM and executes them by launching Thug inside a Docker container. Thug will use the back-end’s MongoDB instance (that is outside of the container) to store its results. Once the analysis is over, the container is destroyed to avoid conflicts that would arise from the reuse of Thug’s global Logger instance. The results and files are then transferred to the front-end when fdaemon requests them through the API.
To be able to test Rumal, you will need to configure both the back-end and front-end environments. They can live on the same host, or on two separate hosts: that’s entirely up to you. You can find the latest version of Rumal on GitHub, along with installation instructions.
Submitting a new analysis task is as easy as logging in and typing a new URL in the box, as shown in the image below. You can also expand the various boxes to access some advanced options that should be familiar to you if you are a Thug user. You will also find a box that lets you decide whether you want to share your analysis with other users or groups: this may be especially useful in multi-user environments.
Once the analysis is finished, Rumal will show you a tree graph with all the web resources that were involved in the current analysis. Clicking a node in the graph will expand or collapse it, while double clicking it will select it. The boxes on the left side will contain details about the currently selected node.
Rumal is a very promising project, but it’s still in an early alpha stage. We welcome feedback and contributors, get in touch at pietro[dot]delsante[at]gmail[dot]com!
- Existing code cleanup
- Consolidate back and front end results into MongoDB, front-end could also switch to Elastic Search, now fully supported by Thug
- Remove requirement of a fully functional Thug install running in the front-end
- Improve data visualization of analysis results
- Move configuration options to external config files
- Parallelize the enrich daemon
- Threads should be replaced by processes whenever possible
- Introduce a message queue for internal communication to improve performance