Since our queries will be running on the Planet-Lab network, we have a responsibility to keep them secure. A lot of thought has gone into how to lock down the nodes from the web interface so that a compromise on the web interface will not affect the nodes.
Backend / key storage server
This machine will be heavily firewalled to mostly do outgoing connections. The planet-lab SSH key needs to be stored on it in plain text so that it can be used to run commands on nodes and return their results.
Incoming SSH access to for the user connecting from the frontend / django server is restricted to the get_requests.py script. Commands are passed to the script through the parsing of the SSH_ORIGINAL_COMMAND variable, for example:
user@infotrace$ ssh user@backend weekly
SSH_ORIGINAL_COMMAND will thus be "weekly" but this will not be executed. Instead, the get_requests.py script is run as it's the ssh forced command; it can then inspect the SSH_ORIGINAL_COMMAND env. variable according to the given parameters and either act on them or report suspicious behavior.
Infotrace / Django server
The django server is a much larger attack surface than the backend server, though the backend is more sensitive due to the key storage.
Python alternatives to suhosin?
OSSEC (Open Source Host-based Intrusion Detection System) looks awesome:
http://www.ossec.net/
Some further ideas for locking things down:
http://www.sublimation.org/scponly/wiki/index.php/Main_Page
Comments (0)
You don't have permission to comment on this page.