When and how to use an S3 bucket as a Relay
Written by Robert Littlefield
There may exist an environment in which you wish to limit inbound communications to your Shared Services VPC and/or limit communications to the internet from a specific, non-shared services VPC.
Having an S3 bucket act as a Deep Security Relay would allow Agents to only need to talk back to a DSM in a Shared Services VPC on port 4120 (by default). Adding an S3 Endpoint to each VPC would also limit outbound communication to the internet from each non-shared services VPC to get Pattern Updates as well as Module Plugins.
A VPC endpoint enables you to create a private connection between your VPC and another AWS service without requiring access over the Internet, through a NAT device, a VPN connection, or AWS Direct Connect. Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.
To create this environment you would:
- Create S3 bucket called relaybucket
You would still need a Relay server, likely in your shared services VPC, that is able to go out to the internet and grab all of the Pattern Files and new Agents.
- Once this is setup, you can create a CRON job to run this command on the Relay server to push the Relay contents to your S3 bucket : aws s3 sync /var/opt/ds_agent/relay/www s3://relaybucket/ –acl public-read
- This will place the /var/opt/ds_agent/relay/www directory in the S3 bucket and make it publicly readable (for all of the Agents to see)
For the script above to run, the Relay server will need AWS CLI. If the Relay is being ran on AWS Linux, the CLI will be installed by default. Any other OS will have to have the AWS CLI installed manually.
You will also either need to generate IAM credentials for the user running the CRON job on the Relay for S3 Sync, or the Relay Instance itself can be provided with an IAM role that allows it to write to the S3 bucket.
Once the environment above has been created, all that is left to do is configure Deep Security to use your new S3 Relay as the primary update source and as the Alternate Software Update Source. Both of these settings are found in Administration –> System Settings –> Updates Tab.
At this point, you will need to create a new Relay Group called S3 Bucket (Administration –> Relay Groups –> New…) . This Relay Group will remain empty, meaning no Relays will be assigned to it. The relay group will be assigned to all Instances you wish to use the S3 Endpoint as a Relay. Natively, this will generate Alerts in the environment regarding empty Relay Groups, but this can be turned off by navigating to the Alerts tab à Configure Alerts –> Search for “Empty Relay Group Assigned” –> Double Click the message –> Select the “Off” radio button.
Your instances that are assigned the S3 Relay group will now use the S3 endpoint in the VPC and will get all updates that the CRON job has copied over. It is a good idea to setup CloudWatch to monitor the CRON job and ensure that this process continues to run as expected to ensure you have the latest available security updates and agent patches available to your infrastructure.