Breaking Apart Blockade — Part two
In part one of breaking apart Blockade, we focused on the browser extension that enables us to block malicious infrastructure. In this post, we will cover the less technical, but necessary server-backend where data is stored — the cloud node.
When building the first version of Blockade, one of the primary goals was to create an end-to-end solution without the need for a server (serverless architecture). The reason for this design choice was to reduce operating costs, a need for technical support, and eliminate a lot of the traditional security problems headaches (uptime, vulnerabilities, patches, etc.) with hosting a server. Today, Blockade’s public architecture runs within Amazon and subscribes to the serverless concept. While that works for the core backend, many users still want the option to host their own server and so the cloud node was created.
Node Architecture
Blockade cloud nodes are written in Python, leverage Flask to render API endpoints, and use MongoDB to store content. Nodes are designed to run one instance per server, but could be adjusted depending on the web server deployment. Once installed and running, users can access documentation directly from the cloud node. Each API call is documented with request parameters, sample cUrl calls and sample response data.
Functionality is split into two different components, core endpoints for the extensions and administrator actions. For any call into the Blockade cloud node, users can specify an optional database name within the URI in order to use a different backend Mongo collection. Leveraging this name would allow users to split their indicators up by specific segments instead of placing them all into one large collection.
Extension Endpoints
Blockade browser extensions have two core functionalities — getting indicators and sending back alert events to the cloud node. Each extension can have any number of cloud nodes configured and will reach out to the cloud node on a regular basis for updates or data dumps. These API endpoints do not leverage any form of authentication as they are considered to be public, but slight modifications could be made to the code to create more privacy.
Administrator Actions
One of the greatest benefits of using Blockade over some hosted threat list is the ability to control data and who has access to it. When first deploying a cloud node, users must configure an administrator user who can then be used to create additional administrators or analyst accounts. These users each get a username and API key that can be used to submit indicators to the cloud node which in turn get automatically sent out to all Blockade instances.
Node Interaction
Unlike a traditional threat list where indicators may be pre-processed before being sent to blocking devices, Blockade simply consumes the data from the cloud nodes and restricts users from accessing those resources.
While cloud nodes expose a micro API in order to publish indicators, we recommend using our analyst tool-bench when possible. This toolset abstracts the API away from the user and introduces a number of safety checks and performance enhancements that run against indicators prior to being published in the cloud. Using the toolset ensures that analysts who have access to your cloud node do not accidentally publish incorrect indicators.
