3CX DLL-Sideloading attack: What you need to know
Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
The instructions in this article describe a way to automatically deploy Sophos Server Protection (Intercept X for Server) agents to all EC2 instances in a given AWS account. The intended goal is to simplify mass rollout and automatic deployment of agents without requiring redeployment of workloads (such as would be the case with cloud-init (UserData) scripting.
Please note that, due to the nature of this solution pushing agents to all workloads in the account it may cause issues with some restricted AMIs (such as Sophos UTM and Sophos Firewall) that are either locked down to a point where local agent installation is not possible or may result in conflicts. This can be addressed by modifying the provided code and/or instructions, or through moving these workloads to a different account. If you need any assistance with applying these instructions to an environment where agent rollout to all workloads is not desirable, contact your Sophos account representative or reach out to publiccloud@sophos.com.
This solution utilizes the following AWS Services to first determine if an EC2 instance has the Sophos agent installed or not, and if not, automate the installation of the appropriate Sophos agent.
AWS Lambda - https://aws.amazon.com/lambda/
AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers.
Amazon Systems Manager (abbreviated as SSM throughout this guide) - https://aws.amazon.com/systems-manager/
Amazon Systems Manager is a management service that helps you automatically collect software inventory, apply OS patches, create system images, and configure Windows and Linux operating systems.
AWS Identity and Access Management (abbreviated as IAM) - https://aws.amazon.com/iam/
AWS Identity and Access Management (IAM) enables you to manage Access to AWS services and resources securely.
AWS CloudWatch - https://aws.amazon.com/cloudwatch/
CloudWatch provides you with data and actionable insights to monitor your applications, respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health.
This solution consists of an AWS Lambda function built in Python, which executes whenever an EC2 instance state changes from "stopped" to "running" (as determined through monitoring with CloudWatch). This function checks the instance state in SSM to determine if a Sophos agent is present in the workload, and if not, will automatically deploy a Sophos Server agent to the EC2 instance using the AWS SSM agent in the workload through the Sophos provided SSM Documents.
As such, this solution requires that the managed EC2 instances have the SSM agent installed, the agent has a role attached with necessary SSM permissions, and that the instances show up as 'managed' in the Systems Manager section. For details on this, see https://docs.aws.amazon.com/ssm/latest/APIReference/Welcome.html.
Please note that the file names used are referenced in various places across the Lambda function and SSM Documents. For this reason it is suggested that you copy/paste the exact file names shown below when creating the Lambda function and SSM Documents.
SophosServerAutoDeployAgent.zip
Included files are:
Note: This step is optional if your instances are already managed through SSM.As mentioned in the prerequisites in order for the SSM agent on an EC2 instance to interact with the SSM service the instance needs to have an IAM role assigned to it that allows the relevant permissions. Luckily, Amazon has a pre-built policy called "AmazonEC2RoleforSSM" that we can use for this purpose.
Note: These steps assume your EC2 instances currently do not have a role assigned If this is not the case, make sure to append the existing instance role with the "AmazonEC2RoleforSSM" policy instead of replacing the existing role on the instance.
Since Sophos Central uses a client-specific installer URL it is of utmost importance to modify the provided SSM Documents with the relevant URL.
You will need to upload the installation scripts that are called by the Lambda function which will install the Sophos Protection Agent to your EC2 instances.
Next, we'll need to create an IAM role to enable the Lambda function to connect to the Systems Manager service and execute the required SSM Documents.
Once you have created the function you can upload the function code provided in the Installation Files by editing the function.
With the function created, the next thing we need to configure is the conditions that cause the Lambda to execute the function. This is handled by the Trigger mechanism, which we'll add to the function in this step.
With everything set up and configured, the last step is to recreate the trigger circumstances and monitor the environment to make sure the desired action (Sophos agent installation) is taking place.
Excellent post.
Could you please update your linux script. I found that the .sh file you pointed to is the old linux installer. I used the SophosSetup.sh url in the Central Admin dashboard.
For our purposes we used your script and modified it to not install Sophos on all machines, but just the machines that have a tag Sophos yes or Yes. This is to prevent a sprawl of sophos licenses used. Especially on very shortlived machines that deploy and terminate quickly.
We also added another variable to the actual SSM documents to allow for --devicegroup (windows) or --group (linux) to automagically add the servers to the right groups. Perhaps this is something to look into for the future?
Is there a way to uninstall the agent once the AWS EC2 instance has stopped (Due to AWS Elastic BeanStalk)
This is a terrible solution. It requires far too many integrations, ssm, lamda, cloudwatch, iam, etc. Too many things have to go right for this to work, and there is limited visibility without building a whole bunch of other things to get alerted when this goes wrong. It also doesn't lend itself well to creating new clusters of autoscaled instances without repeating this configuration every single time. Additionally, iam permissions required to run this must be integrated with any iam roles that are already applied to the instances.
Most importantly, it doesn't even remove the instance from Sophos Central when the instance is terminated.
v good post.