Architecturally, Sandfly uses a core server for the database, user interface and REST API. Scanning of remote systems for Sandfly is done by separate scanning nodes. Optionally, the database can be accessed remotely by the server so the customer can host their own distributed and fault tolerant database cluster off the server.
Scanning nodes do the grunt work for contacting and checking hosts for problems. Nodes can be setup to run on isolated segments and communicate back to a single central server.
You can also run multiple nodes distributed across multiple networks. For instance, nodes can run at multiple cloud providers or inside multiple private networks while being controlled at one point.
Finally, nodes can be setup to make use of jump hosts to access isolated networks by first connecting to SSH choke points before connecting to the internal hosts.
The scanning nodes receive orders from the server about what systems to scan, and what problems to look for on the remote hosts with a random selection of sandflies. The nodes perform the required checks by pushing down their sandflies to do investigations and report results. Any suspicious activity found by a sandfly is reported back to the server for user alerting and further actions.
During install we will setup the core server and scanning nodes. The server is comprised of a web server, a REST API and an Elasticsearch database. The nodes have a Rabbit messaging protocol system to talk to the server and multi-threaded high performance scanning engines to manage sandfly deployment and results.
Optionally, during install you can specify a database URL and username/password authentication for Sandfly to use and you can forgo the database setup on the server entirely.
Updated 3 months ago