Deploying Cloud Defender in Amazon Web Services

Alert Logic® Cloud Defender™ is a security solution that provides network intrusion detection, vulnerability assessment, log management, and web application security as a managed service for customers both on premises and in the cloud.

This article covers the recommended best practices for deploying Cloud Defender into an Amazon Web Services (AWS) Virtual Private Cloud (VPC). Deployment scenarios outside of AWS are not covered here, but information regarding deployments in other environments can be found in the Alert Logic documentation.

This article assumes that you have used Amazon Web Services before and are familiar with services such as EC2 and VPC. If you are new to AWS, please read the AWS Getting Started documentation prior to utilizing this guide to deploy Cloud Defender.

Note: The following information applies only to customers with Alert Logic® Cloud Defender™ entitlements.

Preparing to Deploy Cloud Defender

Cloud Defender leverages several AWS APIs, as well as the Amazon CloudTrail service, to build and maintain an asset model of your environment. Following AWS best practices for allowing a third party access to resources in your AWS account, we leverage a Cross Account IAM Role. Preparing your account involves:

Configuring CloudTrail to send notifications to SNS
Creating an SQS queue that will be subscribed to the SNS topic used by CloudTrail
Allowing our service to retrieve CloudTrail logs from S3
Allowing read-only access to discover other services within the account.

There are two options you can choose from when creating the Cross Account IAM Role:

Fully Automated Deployment

This option allows Alert Logic to automatically perform the required configuration changes needed to prepare for deployment. It does require access to make some modifications to services within your AWS account. Specifically, the IAM Role allows us to make the following changes:

If CloudTrail is not enabled, we will enable it. Enabling CloudTrail is considered a best practice by AWS and the first CloudTrail is provided at no cost other than the S3 storage. If you already have CloudTrail enabled, we will leverage the existing Trail.
If CloudTrail is not already configured to send SNS notifications to an SNS topic, we will create a new SNS topic and update the CloudTrail configuration to send notifications to that topic. If you already have CloudTrail configured to send notifications on an SNS topic, we will leverage the existing topic and make no changes to your CloudTrail configuration.
We will create an SQS queue and subscribe the SNS topic that CloudTrail has configured to send notifications to. This queue is watched by our service to detect when changes to your environment occur.

Minimal Permission Deployment

This option allows you to provide a less permissive policy to the role. With this deployment option, you will need to make all of the above configuration changes to your account manually.

You can read more information about the two options above, including the policy documents and requires steps to perform the manual deployment, in our Configure Alert Logic Cloud Defender AWS Cross Account Role Access documentation.

Deploying Alert Logic Appliances

Cloud Defender is deployed by installing agents on AWS EC2 instances, which will mirror traffic to Alert Logic appliances that run within your VPC. This model has many advantages over host-based inspection, such as reducing resource utilization on the protected instances and allowing a much larger signature set while not impacting instance resources. Compared to models that only leverage a network appliance and that only inspect ingress and egress traffic, the combination of agents and appliances allows for the inspection of all traffic within a VPC, including traffic that goes between instances within a VPC and traffic as it enters or leaves the VPC.

Choosing the Size and Number of Alert Logic Appliances

The amount of traffic that an appliance can inspect is determined by the instance size that is used. The table below shows the supported instance types and the amount of traffic that can be inspected:

AWS Instance Type	Supported Bandwidth
c5.large	280 Mbps
c5.xlarge	850 Mbps
c5.2xlarge	1.5 Gbps

Determining the amount of network traffic, and thus the correct instance type, for your appliance can be accomplished using Amazon CloudWatch Metrics to aggregate the NetworkIn and NetworkOut traffic across all instances in the VPC. Additionally, metrics about the amount of traffic inspected by each appliance are available in the Alert Logic console. As part of the managed service, Alert Logic will continuously monitor the health of your appliances and notify you if your appliances become overloaded. Once you have determined the correct size and number of appliances for your deployment, consider purchasing AWS Reserved Instances to lower EC2 costs. The appliances will be running 24x7, so they are a great fit for High Utilization Reserved Instances.

Choosing a Deployment Architecture

How your VPC is architected and the amount of network traffic that will need to be inspected will determine how appliances are deployed. Alert Logic recommends that you deploy an appliance in each AWS Availability Zone (AZ). This ensures that traffic from the agent to the appliance will not need to cross an AZ boundary. Alternatively, you may choose to place the Alert Logic appliances in a shared services VPC that is peered with other application VPCs. Due to data transfer costs and the additional configuration steps required, using a shared services VPC is recommended only when protecting several small VPCs where the data transfer costs will be significantly less than the EC2 cost of running additional appliances.

Typical Deployment

The recommended and most common architecture for deployment includes at least one appliance in each AZ that has instances being protected. Appliances can be launched into an existing subnet or their own dedicated subnet, provided the following are true:

The subnet route table must provide a route to the Internet.
The subnet NACL must allow traffic from the VPC CIDR range on port TCP/777 and allow traffic from the appliance to the Alert Logic IP addresses defined in the security group section on ports TCP/443 and TCP/1438.

When there are multiple appliances available to agents within a VPC, newly installed agents will query the Alert Logic service to get a primary and secondary appliance and will prefer an appliance in the same AZ as itself. This process is automatic and does not require any additional configuration. it ensures that under normal circumstances, traffic from the agent to the appliance remains in the same AZ. This follows AWS best practices and avoids data transfer charges from AWS. Should an appliance fail, agents will fail over to an appliance in a different AZ as the agent. Once an appliance is online in the same AZ as the agent, it will get an updated preferred appliance from the Alert Logic backend and begin sending traffic to that appliance.

Shared Services/Peered VPC Deployment

Architectures that use a shared services or administrative VPC that is peered to application VPCs can deploy a single set of appliances into the administrative VPC and configure agents in the peered VPCs to forward traffic across the peering point to the appliances. This design choice will incur VPC Peering data transfer costs from AWS for traffic that goes between the agents and the appliances. The VPC Peering connection, route tables, and security groups must all be configured to allow traffic from the application VPCs to communicate with the appliances on ports TCP 7777 and 443 priority deploying agents.

To enable agents in a peered VPC to automatically be assigned to appliances in another VPC, the following one-time configuration steps must be performed prior to deploying agents:

Each of the peered VPCs that will contain agents must be initialized on our backend. To do this, you need to deploy a single appliance into each VPC. This appliance is only temporary and can be terminated at the end of this section.
Once the appliance has booted and is visible in the Alert Logic console, navigate to Configuration > Network IDS > Policies > Assignment from the Alert Logic console home page.
You should see an assignment policy for the newly created VPC and the shared services VPC. In the screenshot example above, vpc-bcf440d7 is the peered application VPC and vpc-c0fa4ea4 is the shared services VPC.
Click on the pencil icon to edit the assignment policy for the shared services VPC. Make a note of the instance IDs of the appliances in the policy.
Edit the assignment policy for the application VPC by clicking on the pencil icon. Remove the appliance that was created in step #1 and add the appliances from the shared services VPC to the assignment policy for the peered VPC. Click Save.
In the AWS EC2 console, terminate the appliance that was created in step #1.

Note: These steps should only be completed once from each peered VPC. If you add additional appliances to the shared services VPC, you will need to update the peered VPC assignment policy to include the new appliances.

Agents will still be assigned a primary and secondary appliance from the list of available appliances. Because they are not in the same VPC, however, the assignment will be round-robin and will not take AZ affinity into consideration.

Appliance Deployment Steps

Once you have determined the number and size of your appliances, as well as where they will be launched, you will need to create a security group that the appliances will use. You should use the same security group for all the appliances in your VPC.

In the EC2 console under Network & Security, click Security Groups and then Create Security Group.

In the Create Security Group window, choose the VPC where the appliances will be deployed and provide a name and description. Add the Inbound and Outbound rules, as shown in the tables below. Note that the outbound rules are dependent upon which data center your account is provisioned in. The examples below show a security group for a VPC with a CIDR range of 10.0.0.0/16 and an Alert Logic account provisioned in the US data center.

Inbound Rules

Source	Destination	Protocol	Port	Description
*Agent(s) CIDR	Appliance	TCP	443	Agent updates
*Agent(s) CIDR	Appliance	TCO	7777	Agent data transport (between agent and appliance on local network)

*Agent(s) CIDR should be the CIDR range of the VPC that contains your agents. If you have multiple VPCs using VPC Peering then you will need to add the CIDR range for each VPC.

Outbound Rules for US Data Centers

Source	Destination	Protocol	Port	Description
Appliance	8.8.4.4	TCP/UDP	53	DNS
Appliance	8.8.8.8	TCP/UDP	53	DNS
Appliance	208.71.209.32/27	TCP	443	Updates
Appliance	204.110.218.96/27	TCP	443	Updates
Appliance	204.110.219.96/27	TCP	443	Updates
Appliance	204.110.218.96/27	TCP	4138	Event transport
Appliance	204.110.219.96/27	TCP	4138	Event transport
Appliance	208.71.209.32/27	TCP	4138	Event transport

Outbound Rules for European Data Centers

Source	Destination	Protocol	Port	Description
Appliance	185.54.124.0/24	TCP	443	Updates
Appliance	185.54.124.0/24	TCP	4138	Event transport
Appliance	8.8.8.8	TCP/UDP	53	DNS
Appliance	8.8.4.4	TCP/UDP	53	DNS

Launch the Alert Logic appliance by accessing the private AMI. The private AMI will be shared to your AWS account(s) during the provisioning process. If you need to add additional accounts in the future, Create a Ticket in the Alert Logic Support Center to have the images shared with your AWS accounts. The AMI IDs for all current regions are listed below.

Region	Image ID	Image Name	Location
ap-south-1	ami-00fea52fb02d7a158	Alertlogic TMC - P15	Mumbai
eu-north-1	ami-02e1060567ea6751a	Alertlogic TMC - P15	Stockholm
us-east-1	ami-0123a7ce575cf7828	Alertlogic TMC - P15	Virginia
us-east-2	ami-0a1f3c41aa6202b46	Alertlogic TMC - P15	Ohio
ap-southeast-2	ami-04e83a130038b4162	Alertlogic TMC - P15	Sydney, Australia
ap-northeast-1	ami-02a38f262bef42fbb	Alertlogic TMC - P15	Tokyo
sa-east-1	ami-0788ced3eefd3829c	Alertlogic TMC - P15	Sao Paulo
ap-southeast-1	ami-065080b026b96dbbf	Alertlogic TMC - P15	Singapore
ca-central-1	ami-03425de77706f2451	Alertlogic TMC - P15	Canada
ap-northeast-2	ami-0416ce87b5c3251cb	Alertlogic TMC - P15	Seoul
us-west-2	ami-0b2b60d06fb352cf0	Alertlogic TMC - P15	Oregon
ap-east-1	ami-0108990e176bcc46a	Alertlogic TMC - P15	Hong Kong
me-south-1	ami-0df563b310715fd35	Alertlogic TMC - P15	Bahrain
us-west-1	ami-0ff56e02e16b4d5ec	Alertlogic TMC - P15	N. California
eu-central-1	ami-069bcb10e420963e2	Alertlogic TMC - P15	Frankfurt
eu-west-1	ami-0af1970a486c17636	Alertlogic TMC - P15	Ireland
eu-west-2	ami-001dae8374cdea97e	Alertlogic TMC - P15	London
eu-west-3	ami-0e88b6530c8dfc7a5	Alertlogic TMC - P15	Paris

Launch the Alert Logic appliance either from the AMI section of the EC2 console or the EC2 Launch Wizard in the Alert Logic console. To launch the appliance using the AMI section of the EC2 console, choose Private Images from the AMI console. To launch the appliance using the EC2 Launch Wizard, check the Shared with me box from the Launch Wizard.
Select the instance type to use for the appliance based on the sizing determined earlier - either a c5.large, c5.xlarge, or c5.2xlarge. Other instance types will show as available options, but these are the only types currently supported. Click Next: Configure Instance Details.
On the Instance Details page, choose the VPC subnet where you will launch the appliance. Alert Logic recommends that you launch the appliance into a private subnet. If you choose to launch into public subnet, make sure that the Auto-assign Public IP option shows Use Subnet setting (Disable), as the appliance will need to have a static Elastic IP (E IP) assigned to it. Should you need to stop and restart the Network Interfaces section, assign a static IP address for the eth0 interface, ensuring that the IP address you select is valid for the subnet chosen. Click Next: Add Storage.
On the Add Storage page, keep the default options and click Next: Add Tags.
Adding tags to your instances is optional but a good practice. If you choose to add tags to your instances, at minimum you should add a Name tag to the appliance to help identify the instance. Click Next: Configure Security Group.
On the Configure Security Group page, from the Assign a security group field, choose Select an existing security group. Select the security group created previously and click Review and Launch.
On the review page, click Launch. You will be prompted to select a key pair to associate with the instance. Because the appliance does not allow any inbound SSH access, choose the Proceed without a key pair option from the drop-down and check the acknowledgement box. Click Launch Instances. Repeat these steps for each appliance that you need to deploy.

Deploying Alert Logic Agents

The Alert Logic agent supports both Alert Logic Threat Manager™ and Alert Logic Log Manager™ and will automatically enable the components based on your entitlement. Once you have installed the agent, you will need to associate it with your account. If you have completed the steps under the Preparing to Deploy Cloud Defender section above, agents will automatically be claimed and assigned to an appliance. To ensure that the agent is installed on all instances within a VPC, Alert Logic recommends that you leverage a deployment tool such as Chef, Puppet, instance user-data, or Amazon CloudFormation. If you leverage a set of golden AMIs, you can add the agent to these images. Agents can also be manually associated to your Alert Logic account using the unique registration key.

The auto-claim method described above is recommended, but if you have a single AWS account associated with more than one Alert Logic account, you will need to provide the unique registration key. The sections below include instructions for both automated and manual agent registration. If you plan to use manual agent registration, you can obtain your Alert Logic unique registration key from the Alert Logic console. Your registration key is available from the Alert Logic console under Settings (three gray dots in top right corner) > Support Information > Unique Registration Key.

Agent Deployment Using User Data

When launching an Amazon EC2 instance, you can utilize the user data field to pass a bash or PowerShell script to the instance. The script is only executed on the first boot and can be used to deploy and configure the Alert Logic agent.

For Linux instances, the following bash scripts can be used to install and configure the agent:

RPN-Based Linux Distributions

Installation Using Agent Auto-Claim

#!/bin/bash
wget -O /root/alagent.rpm https://scc.alertlogic.net/software/al-agent-LATEST-1.x86_64.rpm
yum -y install /root/alagent.rpm
echo " *.* @@127.0.0.1:1514;RSYSLOG_FileFormat " >> /etc/rsyslog.conf
/etc/init.d/al-agent start
service rsyslog restart

Installation Using Unique Registration Key

#!/bin/bash
wget -O /root/alagent.rpm https://scc.alertlogic.net/software/al-agent-LATEST-1.x86_64.rpm
yum -y install /root/alagent.rpm
/etc/init.d/al-agent provision --key <Alert Logic Key> --inst-type host
echo " *.* @@127.0.0.1:1514;RSYSLOG_FileFormat " >> /etc/rsyslog.conf
service rsyslog restart
/etc/init.d/al-agent start

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.

Debian-Based Linux Distributions

Installation Using Agent Auto-Claim

Installation Using Unique Registration Key

#!/bin/bash
wget -O /root/alagent.deb https://scc.alertlogic.net/software/al-agent_LATEST_amd64.deb
dpkg -i /root/alagent.deb
/etc/init.d/al-agent provision --key <Alert Logic Key> > --inst-type host
echo "*.* @@127.0.0.1:1514;RSYSLOG_FileFormat" >> /etc/rsyslog.conf
service rsyslog restart
/etc/init.d/al-agent start

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.

Windows Server

For Windows instances, the following PowerShell scripts can be used to install and configure the agent.

Installation Using Agent Auto-Claim

<powershell>
$url = "https://scc.alertlogic.net/software/al_agent-LATEST.msi"
$output = "C:\Windows\Temp\alagent.msi"
(New-Object System.Net.WebClient).DownloadFile($url, $output)
Start-Process -FilePath C:\Windows\Temp\alagent.msi -ArgumentList "/log c:\Windows\Temp\al-agent_install.log /quiet PROV_ONLY=host REBOOT=ReallySuppress" -passthru | wait-process
#Stop Log Agent Service
Stop-Service "AL Agent"
#Start Log Agent Service
Start-Service "AL Agent"
Set-Service al_agent -startuptype "automatic"
</powershell>

Installation Using Unique Registration Key

<powershell>
$url = "https://scc.alertlogic.net/software/al_agent-LATEST.msi"
$output = "C:\Windows\Temp\alagent.msi"
(New-Object System.Net.WebClient).DownloadFile($url, $output)
Start-Process -FilePath C:\Windows\Temp\alagent.msi -ArgumentList "/log c:\Windows\Temp\al-agent_install.log /quiet PROV_ONLY=host prov_key=<Alert Logic Key>
REBOOT=ReallySuppress" -passthru | wait-process
#Stop Log Agent Service
Stop-Service "AL Agent"
#Start Log Agent Service
Start-Service "AL Agent"
Set-Service al_agent -startuptype "automatic"
</powershell>

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.

Agent Deployment with Customized AMIs

If you have a set of base AMIs owned by your account that are used for all instances within your deployment, you can add the Alert Logic agent to these images.

NOTE: As AMIs are immutable, if you create a new set of AMIs that contain the Alert Logic agent, you will need to update your deployment tools so that they use the new AMIs that contain the Alert Logic agent.

Create a new instance from your base AMI. This instance will be updated to include the Alert Logic agent and then a new AMI will be created from this instance.

RPM-Based Linux Distributions

Installation Using Agent Auto-Claim
Log in to the instance via SSH and perform the following steps:

wget https://scc.alertlogic.net/software/al-agent-LATEST-1.x86_64.rpm
sudo yum install -y al-agent-LATEST-1.x86_64.rpm
sudo echo "*.* @@127.0.0.1:1514;RSYSLOG_FileFormat " >> /etc/rsyslog.conf

Installation Using Unique Registration Key
Log in to the instance via SSH and perform the following steps:

wget https://scc.alertlogic.net/software/al-agent-LATEST-1.x86_64.rpm
sudo yum install -y al-agent-LATEST-1.x86_64.rpm
sudo /etc/init.d/al-agent configure --key <Alert Logic Key> --inst-type host
sudo echo "*.* @@127.0.0.1:1514;RSYSLOG_FileFormat " >> /etc/rsyslog.conf

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.

Debian-Based Linux Distributions

Installation Using Agent Auto-Claim
Log in to the instance via SSH and perform the following steps:

#!/bin/bash
wget -O /root/alagent.deb https://scc.alertlogic.net/software/al-agent_LATEST_amd64.deb
dpkg -i /root/alagent.deb
echo "*.* @@127.0.0.1:1514;RSYSLOG_FileFormat" >> /etc/rsyslog.conf

Installation Using Unique Registration Key
Log in to the instance via SSH and perform the following steps:

#!/bin/bash
wget -O /root/alagent.deb https://scc.alertlogic.net/software/al-agent_LATEST_amd64.deb
dpkg -i /root/alagent.deb
/etc/init.d/al-agent provision --key <Alert Logic Key> > --inst-type host
echo "*.* @@127.0.0.1:1514;RSYSLOG_FileFormat" >> /etc/rsyslog.conf
service rsyslog restart
/etc/init.d/al-agent start

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.

Windows Server
Create a new instance from your base AMI. Once it has booted, log in using a remote desktop client and run the following PowerShell script to download and configure the agent.

Installation Using Agent Auto-Claim
$url = "https://scc.alertlogic.net/software/al_agent-LATEST.msi"
$output = "C:\Windows\Temp\alagent.msi"
(New-Object System.Net.WebClient).DownloadFile($url, $output)
Start-Process -FilePath C:\Windows\Temp\alagent.msi -ArgumentList "/log c:\Windows\Temp\al-agent_install.log /quiet INSTALL_ONLY=1
REBOOT=ReallySuppress" -passthru | wait-process
Set-Service al_agent -startuptype "automatic"

Installation Using Unique Registration Key
$url = "https://scc.alertlogic.net/software/al_agent-LATEST.msi"
$output = "C:\Windows\Temp\alagent.msi"
(New-Object System.Net.WebClient).DownloadFile($url, $output)
Start-Process -FilePath C:\Windows\Temp\alagent.msi -ArgumentList "/log c:\Windows\Temp\al-agent_install.log /quiet INSTALL_ONLY=1 prov_key=<Alert Logic Key>
REBOOT=ReallySuppress" -passthru | wait-process
Set-Service al_agent -startuptype "automatic"

NOTE: Replace <Alert Logic Key> with your unique registration key obtained from the Alert Logic console.
Once the agent installation is complete, prepare your Windows instance to create a new image. Launch the EC2Config application on the instance. In the General tab, check the Set Computer Name and User Data boxes.
On the Image tab, choose the appropriate options for the Administrator password. If you are not joining your Windows instances to a domain or maintaining a consistent local administrator password on your instances, select Random to generate a password.
Click Shutdown with Sysprep, which will place the instance into a stopped state.

Creating a New Base Image

Once the agent has been installed, find the instance that had the agent configured in the AWS Console and stop it. Create a new AMI from the stopped instance, as shown in the example below.

Agent Deployment Using Automation Tools

Several open-source projects for deploying the Alert Logic agent are available on our GitHub page:

Chef: https://github.com/alertlogic/al_agents
Puppet: https://github.com/alertlogic/alertlogic-agents
Ansible: https://github.com/alertlogic/al-agents-ansible-playbooks
Saltstack: https://github.com/alertlogic/al-agents-saltstack-module

The above steps and information should complete your deployment. If you have additional questions, Create a Ticket in the Alert Logic Support Center.

Articles in this section

In This Article