- Accepting and handling tasking requests.
- Accepting requests for uploading new malware samples and forward the request to Holmes-Storage [2].
- Allow for automatic task-execution upon sample upload.
- Check user credentials for both types of requests.
While most of these are straight forward, the first of these points requires some additional explanation:
In the previous system, if a user wanted to execute a certain service task (e.g. extract static information about a PE-file by executing the PEInfo-service on it), he had to push a JSON-object describing the task directly into a RabbitMQ [3]-queue. Holmes-Totem [4] listens on that queue and starts the corresponding service with the corresponding parameters.
With the release of Holmes-Gateway, there are various improvements to this workflow:
- The user has to authenticate himself first.
- The tasking structure is validated before pushing it to RabbitMQ.
- Holmes-Gateway allows the admin to define different queues for different service tasks. This means, it is possible to have separated queues for services which usually take a large amount of time and such that usually only take a small amount of time. Thus the former sort does not block the latter sort.
- Holmes-Gateway allows different organizations to perform tasks on malware-samples of partnering organizations without getting access to these samples.
In order to achieve these improvements, there are two separate parts of Holmes-Gateway, called the "Master-Gateway" and the "Slave-Gateway" (sometimes also referred to as "Organizational Gateway"). The user does not directly communicate with RabbitMQ anymore. Instead he sends a list of tasking-JSON-objects via HTTPs to his organization's instance of Master-Gateway, along with his credentials. The Master-Gateway has a configuration, which allows the admin to define a routing of tasks based on the task's source.
Based on this configuration, the Master-Gateway chooses a Slave-Gateway of a partnering organization (or its own organization), which supposedly has access to the source, the sample belongs to. The Master-Gateway then batches tasks for the same Slave-Gateway together, creates a ticket valid only for this tasking-list, signs it with his private key, encrypts the task-list and the ticket, and sends everything to the chosen Slave-Gateway.
The Slave-Gateway decrypts everything and checks the ticket. If everything is alright, it validates the task and finally pushes it into the queue, which is configured for the corresponding service. From there, the task is picked up by Holmes-Totem and processed as before.
This whole workflow is visualized in the picture below.
In addition to the implementation and design of Holmes-Gateway, my task included writing CLI-tools to help with executing these tasks. These tools can be found in Holmes-Toolbox [5]. For detailed information about how to use these tools, I refere the reader to the Readme-files in the corresponding GitHub-Repositories.
[3] RabbitMQ
Keine Kommentare:
Kommentar veröffentlichen