Remote Worker Communication

Overview

In quokka, "remote workers" are python programs that run in the background and perform various functions on behalf of the quokka server. Today, those functions are few:

• Packet capture
• Port scans (extended)
• Traceroute

Remote workers were created out of necessity - the functionality required by either scapy or nmap, which perform the underlying functionality, require root access, and since running as root is a bad idea for a web server, these functions were 'outsourced' to the external python programs.

Initial Implementation

As external Python programs, there needed to be a means of communication between the quokka server, and these external programs. Initially, quokka opted to use two separate communication methods, in significant part due to the nature of the first such functionality, packet capture:

• quokka --> capture-worker: This would use a messaging tool, in our case 'rabbitmq', which is a popular messaging service. There is one message, sent from quokka to the capture-worker, instructing it to begin packet capture.
• capture-worker --> quokka: This would use HTTP, sending captured packets to the quokka server, as each packet is received.

"Remote" workers

Because of this implementation, the capability to run these workers on different systems was a possibility. Messaging functionality like rabbitmq has the ability to pass messages across different systems, since part of the 'destination' is the IP address to which the message is being sent. So, sending commands to capture packets (or later, to initiate port scans or traceroutes) would naturally be supported if the worker was running on a remote system.

For communication of result data back to the quokka server, HTTP by its very nature is designed to be communication between different systems, so that was also always possible. And so, these workers are able to run remotely.

The following diagram shows the mechanics of a remote worker:

In the image above, the user initiates a request (packet capture, extended port scan, traceroute). This request gets put onto the message bus (rabbitmq), and sent to the remote worker. The worker is always listening on the message queue for requests; once received, it performs the operation, and sends the results back to the quokka server using HTTP. Quokka receives the response data, stores it in the database, and eventually the UI retrieves the new data and displays it for the user.

Using HTTP rather than messages

In some situations, it may be impossible to implement a messaging service such as rabbitmq. For example, rabbitmq uses port 5672; if you are running inside an organization that blocks most traffic, you may need to poke a hole in a firewall in order to allow port 5672 traffic. Or, if your workers are separated from the quokka server by the public internet, you may not even be able to get port 5672 traffic between the remote worker and the quokka server.

In these situations, another mechanism is required. Thus, quokka supports the use of HTTP for delivery of commands to remote workers.

The following figure shows remote worker using HTTP to receive commands waiting to be delivered:

In this image above, you can see the worker 'heartbeat', which is present for all workers (including those using messaging, described earlier). However in this case, the heartbeat does more than just report status; it also checks to see if there are any outstanding, undelivered 'commands' for this remote worker.

If any undelivered commands are found in the DB, they are copied into the heartbeat reply, and the worker will receive these and execute them as directed. Thus, packet capture or port scan or traceroute commands are delivered to remote workers that are using HTTP as their command-delivery mechanism.