Salient

This guide details how to deploy and setup the HoneyDrop appliance in AWS. This appliance will expose fake services often targeted by cyber criminals. Its purpose is to lure attackers to itself thereby generating logs and alarms indicating that a nefarious actor may be on the network. When a HoneyDrop service is interacted with, the activity gets logged to AWS CloudWatch which can generate alerts to be sent to email or SMS. Alternatively, CloudWatch alarms can trigger Lambda functions to invoke incident response actions on your behalf.

## E﻿stimated Deployment Time

10 Minutes

## What

The HoneyDrop appliance is a low-interaction honeypot meant to be deployed in subnets where critical visibility of malicious activities is needed. The HoneyDrop can be configured to emulate:

*   Windows SQL servers
*   Windows web servers
*   Linux MySQL servers
*   Linux web servers

When the HoneyDrop appliance is interacted with, logs are generated and sent to AWS CloudWatch within seconds for alerting. These alerts can trigger SNS notifications to send emails, SMS messages or launch Lambda functions.

## Why

*   Gain visibility into your AWS VPS network environments.
*   Enhance security posture without needing to install agents on instances.
*   Lure attackers away from high value systems long enough to be identified.
*   Enable automated incident response actions to isolate and quarantine compromised hosts.

## How

The following steps will explain how to setup and deploy the HoneyDrop appliance.

1.  Deploy the [HoneyDrop appliance](https://aws.amazon.com/marketplace/pp/prodview-fvbdhof5t5qa6) from the AWS marketplace into your target subnet. Salient recommends a t3.medium instance size for optimal operation. Note that once the appliance is deployed, the administrative SSH service takes a minute to become active.
2.  Navigate to <https://console.aws.amazon.com/iamv2/home#/roles> and click on "Create role".
3.  Set the trusted entity type to "AWS service" and the use case to "EC2", now click next.
4.  Attach the "CloudWatchAgentServerPolicy" and click next.
5.  Optionally add your keys and click next.
6.  Name the role "HoneyDropRole" and click "Create role".
7.  Navigate back to EC2, <https://console.aws.amazon.com/ec2/v2/home#Instances:instanceState=running>
8.  Right-click on the HoneyDrop appliance, under "Security" click "Modify IAM role"
9.  Select the HoneyDropRole and click "Save".
10. Now, SSH into the HoneyDrop appliance: `ssh -i <private key> ubuntu@<IP address> -p 2222`
11. Update the honeydrop.config file: `nano /etc/honeydrop/honeydrop.conf`

    *   To emulate a Windows SQL server, change the following services to true:
        - smb.enabled
        - mssql.enabled

    *   To emulate a Windows web server, change the following services to true:

        *   smb.enabled
        *   http.enabled
        *   httpproxy.enabled

    *   To emulate a Linux MySQL server, change the following services to true:

        *   mysql.enabled
        *   ssh.enabled
        *   vnc.enabled

    *   To emulate a Linux web server, change the following services to true:

        *   ftp.enabled
        *   http.enabled
        *   ssh.enabled
        *   vnc.enabled
        *   telnet.enabled
12. Finish editing the HoneyDrop configuration file, save it and reboot the appliance.
13. Edit the security group of the HoneyDrop appliance to only allow honeypot ports to be exposed: <https://console.aws.amazon.com/ec2/v2/home#SecurityGroups>:

In the example below, we've setup a Linux MySQL honeypot and are allowing connections to SSH, VNC, and MySQL:

![](/images/honeydroplinuxdiagram.png)

![](/images/honeydropsecuritygroup.png)

And that's it! Your appliance should now be up and running in your environment. Test the services you enabled by interacting with them and see the alerts appear in AWS CloudWatch.

### Setting Up Alarms

Now that your HoneyDrop appliance is set up and configured, it's time to configure some alerts.

First, let's configure the metric filter within CloudWatch Logs. This is necessary to identify events triggered by the HoneyDrop appliance. AWS does a great job explaining the setup [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html), but for the sake of simplicity, navigate [here](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups/log-group/honeydrop.log$23metric-filters) and click on "Create Metric Filter".

Here we will set the filter pattern to "src\_host". This means that any time an event is recorded, the metric filter will be triggered since all HoneyDrop events capture the source host field in their logs. Set the additional parameters according to the image below.

![](/images/cloudwatchmetricfiltersetup.png)

Next, we need to setup our SNS topic. This is the mechanism that will send an email out whenever the HoneyDrop catches an attacker. We'll start by navigating to AWS Simple Notification Service (SNS) and clicking on "Topics", or just click [here](https://console.aws.amazon.com/sns/v3/home#/topics). Now, click on "Create topic". Enter the  details according to the following image.

![](/images/snstopic1.png)

Now we need to subscribe to our topic by clicking on "Create subscription". Set the "Protocol" to email and the "Endpoint" to your email address then click "Create subscription".

*Don't forget to check your email and click "Confirm subscription".*

![](/images/snstopic2.png)

Next, we'll configure a CloudWatch alarm. Navigate to the the "All alarms" pane in CloudWatch, [here](https://console.aws.amazon.com/cloudwatch/home#alarmsV2:) and click "Create alarm" and then "Select metric". Here, we'll select "HoneyDropMetrics", then "Metrics with no dimensions", then check "HoneyDropEvent" and click "Select metric". Now, enter the metric and condition details according to the following images and click "Next".

Now, we'll configure the alarm to send our SNS notification whenever it's triggered. Once our SNS topic is selected, we can hit "Next".

Here, we enter our alarm name and description and hit "next".

![](/images/cloudwatchalarm4.png)

Finally, we can review our alarm and hit "Create alarm".

That's it. Now, whenever our HoneyDrop appliance lures in an attacker, its services will capture the interaction and trigger an SNS email notification - alerting you that bad things are happening.

## T﻿roubleshooting

*   N﻿ot seeing alerts in CloudWatch Logs?

    *   Check to make sure the HoneyDrop is in a subnet where other hosts can reach it and that security group permits inbound connections on enabled services.
    *   E﻿nsure the role attached to the HoneyDrop appliance has the CloudWatchAgentServerPolicy policy attached to it.
    *   Attempt authenticating to one of the enabled services to generate some logs.

## F﻿AQ

*   Does the HoneyDrop appliance support single-AZ, multi-AZ or multi-region deployments? The appliance is a single EC2 instance that can be deployed into any VPC in any region.
*   D﻿oes the HoneyDrop appliance support all regions? Yes, all regions are supported.
*   S﻿hould we use the root user for deploying the HoneyDrop appliance? No, it is recommended to use a non-root user to deploy the appliance.
*   S﻿hould the HoneyDrop appliance be encrypted when deployed? Yes, security best-practice is to encrypt the appliance when provisioned.
*   I﻿s data in-transit encrypted? Yes, data sent to CloudWatch Logs is encrypted in-transit.
*   W﻿hich services used by HoneyDrop are billable? The HoneyDrop appliance incurs Cloudwatch, EC2, and software cost when deployed. For example, a t3.medium HoneyDrop instance costs $0.042 per hour plus $0.05 per hour for software for a total of $0.092 per hour of deployment.
*   H﻿ow can I monitor the health of the HoneyDrop appliance? Check the health of your server by viewing its status in the "Instance State" column in the EC2 Dashboard.
*   H﻿ow does the HoneyDrop appliance get patched and updated? The appliance is set to auto-install security patches on a daily basis.
*   H﻿ow do I handle a non-responsive HoneyDrop appliance? This is very rare, but a reboot should resolve the issue.
*   Is there technical assistance available to help troubleshoot? Yes, we're available to assist and will typically respond within 1 business day. We can be reached by emailing: support at salientengineering.com



HoneyDrop

This guide explains how to deploy and configure the Multi-Port Forward Server in AWS and Azure. The Multi-Port Forward Server is designed to listen on multiple user-defined ports and redirect inbound TCP or UDP traffic to user-defined destination hosts and ports. This creates a versatile network address translation (NAT) and port address translation (PAT) appliance in your AWS VPC or Azure subscription.

### **Estimated Deployment Time**

1﻿0 Minutes

### **What**

Port forwarding or port address translation (PAT) is a method of changing the destination port of network traffic by using a forward proxy.

Network address translation (NAT) is the process of redirecting inbound network traffic destined for an exposed public IP address, to internal private non-routable IP addresses. The process is then reversed when the internal IPs communicate with external IPs.

### **Why**

The Multi-Port Forward Server serves both purposes of NAT-ing at PAT-ing when multiple streams of traffic need to be redirected. This is especially useful in the following scenarios:

1.  Numerous internal servers listen on the same port, but must all be internet-exposed on a single IP address
2.  Only one IP address can be whitelisted but multiple external hosts need to be accessed
3.  Access to internal systems is needed externally, and traffic must traverse on port 443 or 80 to bypass a network firewall dropping all other ports

### **How**

For this tutorial we will deploy a single Multi-Port Forward Server that redirects inbound traffic to multiple hosts internally and externally.

Let’s assume the following network architecture:

*   A VPC or subscription configured with a 172.31.0.0/16 CIDR range
*   Two subnets configured:

    *   One private, with no internet access (172.31.1.0/24)
    *   One public, with an internet gateway configured for internet access (172.31.0.0/24)

    ![](/images/portforward-subnets.png)
*   A Redshift cluster deployed to the private subnet which will be listening on its default TCP port, 5439
*   An Ubuntu server deployed to the private subnet listening for inbound SSH connections on TCP port 22
*   A Port Forward Server appliance deployed to the public subnet will be listening on TCP ports 443, 80, 53, and 22

    *   Inbound TCP traffic on port 443 will be proxied to the Redshift server in the private subnet, destined for port 5439
    *   Inbound TCP traffic on port 80 will be proxied to the Ubuntu server in the private subnet, destined for port 22
    *   Inbound TCP traffic on port 53 will be proxied to portquiz.net, an external host listening on port 3389

    ![](/images/deployedmultiportforwardserver.png)
*   The VPC security group or subscription NSG needs to be configured to allow:

    *   Inbound ports 443, 80, 53, and 22 from an authorized IP address
    *   Inbound ports 5439 and 22 from the public subnet into the private subnet

        ![](/images/multivpcsecuritygroup.png)

Here is an architectural diagram of the setup we’ve just constructed:

![](/images/multi-portforwarddiagram.png)

Now that the infrastructure is setup, we're ready to deploy the Multi-Port Forward Server into the public subnet.

### How to deploy the Multi-Port Forward Server:

1.  Deploy the [AWS Multi-Port Forward Server](https://aws.amazon.com/marketplace/pp/prodview-of6usifaxnkcw) or [Multi-Port Forward Server for Azure](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fatalsecurity1604924013537.multi-port-forward-server?tab=Overview) appliance from the marketplace into your public subnet
2.  If in AWS, disable source and destination checks on the instance, [more info here](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
3.  SSH into the Multi-Port Forward Server
4.  Open the /etc/multiportforward/​multiportforward.config file with vim or nano and update the SPORT, DHOST, DPORT and PROTOCOL entries (source port, destination host, destination port and connection protocol respectively) in JSON format; key names should be descriptive and should not contain any spaces
5.  Save the multiportforward.config file
6.  Reboot the server

![](/images/multi-portforwardserversetup.png)

And that’s it! Your Multi-Port Forward Server should now be forwarding:

*   All incoming port 443 TCP traffic is being directed to your Redshift cluster, deployed in your private subnet, listening on port 5439
*   All incoming port 80 TCP traffic is being directed to your Ubuntu SSH server, deployed in your private subnet, listening on port 22
*   All incoming port 53 TCP traffic is being directed to an external RDP server, listening on port 3389

You can test the connection to your Redshift cluster by entering the public DNS of your Multi-Port Forward Server as the target host using psql:

`psql -h ec2-12-34-56-78.compute-1.amazonaws.com -U awsuser -d dev -p 443`

Again, the same host name can be used to verify the connection to your internal Ubuntu SSH host:

`ssh -i ~/.ssh/Ubuntu.pem ubuntu@ec2-12-23-34-78.compute-1.amazonaws.com -p 80`

And similarly, use the same hostname when connecting via remote desktop.

### Troubleshooting

*   Traffic not being forwarded?

    *   Check the security groups to ensure traffic is being permitted inbound on expected ports.
    *   Check ACLs to ensure traffic is being permitted outbound as expected.
    *   Ensure source and destination checks have been disabled on the instance: [more info here](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)

### FAQ:

*   Does the Multi-Port Forward Server support all regions? Yes, all regions are supported.
*   S﻿hould I use the account root user to deploy this appliance? No, we recommend using a non-root user to deploy this appliance.
*   I﻿s encrypted traffic decrypted by the appliance at any point, either in-transit or at rest? No, the Multi-Port Forward Server facilitates traffic to and from hosts but never decrypts encrypted traffic.
*   D﻿oes the Multi-Port Forward Server require any billable services? Yes, in addition to the appliance subscription, the Multi-Port Forward Server will incur the cost of the EC2 instance selected. For example, the licensing cost for a t2.micro instance would be $0.02 for the software and $0.012 for the EC2 instance, yielding a total cost of $0.032 per hour.
*   H﻿ow large of an EC2 instance should we deploy? We recommend a t3.medium for most production use cases.
*   How can I check the health of my Multi-Port Forward Server? Check the health of your server by viewing its status in the "Instance State" column in the EC2 Dashboard.
*   How can I install system or software patches? Once the system is rebooted, it will auto-install all requisite updates and upgrades.
*   How do I handle a non-responsive Multi-Port Forward Server? This is very rare, but a reboot should resolve the issue.
*   Is there technical assistance available to help troubleshoot? Yes, we're available to assist and will typically respond within 1 business day. We can be reached by emailing: support at salientengineering.com



Multi-Port Forward Server

This guide explains how to deploy a Reverse SSH Server in AWS. The Reverse SSH Server allows multiple clients to connect to the server via SSH on a persistent basis. The clients are configured to port forward their own local SSH service to allow administration of all clients simply by connecting to the Reverse SSH Server and then SSH-ing to the appropriate local ports.This appliance allows clients behind NAT'd environments with private IP addresses to connect outbound to the Reverse SSH Server and be administrate-able. The server and its clients are configured to auto-reconnect if either one gets rebooted.

### **E﻿stimated Time**

1﻿5 Minutes

### **What**

The Reverse SSH Server is an appliance which provides persistent connections to other servers or IoT devices even when those endpoints are deployed in private IP environments and even if the endpoints reboot unexpectedly. These reverse connections allow system administrators to have uninterrupted SSH access to the connected client systems for remote administration.

This persistent connection is provided by SSH over port 22 by default. Authentication to the server is specific to each client and key-based authentication is used. Old clients can be removed from the server and new clients can be added at anytime.

### **Why**

The Reverse SSH Server eliminates the need to track and remember multiple, dozens, or hundreds of IP addresses of endpoint systems which need to be managed. All clients auto-connect to the server and maintain the reverse connection at all times. The Reverse SSH server meets the following needs:

1.  Persistent client connections to single server for easier administration.
2.  Custom client names for ease of administration.
3.  Connection durability - auto reconnects even across reboots.
4.  Ability to change server listening port on initial setup from 22 to 443 or any other port.

### **How**

To begin the Reverse SSH Server deployment, navigate to the AWS marketplace [here](https://aws.amazon.com/marketplace/pp/B08SV2LQRT/?ref=_ptnr_termilus_rssdac) and deploy the appliance.

Configure the security group to only allow inbound SSH. The principle of least privilege means we shouldn't expose any non-essential ports.

SSH into the Reverse SSH Server and create your first client script by running:

`sudo reversessh -a myclient`

The "-a" flag indicates that we're adding a user, and the program will output the client script into your current directory.

> The client script contains a private key used to authenticate to the Reverse SSH Server. Each client will have its own key created. These scripts should be treated as sensitive documents and not stored in any unencrypted locations.

Display the file contents to the screen and copy its content to your clipboard (remember to replace "myclient" with your actual client name):

`cat ReverseSSH-myclient-Client.sh`

Now, in a separate window, SSH into your client machine and create the same client script:

`nano ReverseSSH-myclient-Client.sh`

Paste the clipboard content into this script, save, and close the file.

Make the client script executable:

`chmod +x ReverseSSH-myclient-Client.sh`

Run the client script with sudo privileges:

`sudo ./ReverseSSH-myclient-Client.sh`

Now, back in the Reverse SSH Server window, validate that the client has successfully connected:

`sudo netstat -antp`

If the client successfully connected, its name will be shown on the far right, and its SSH port will be forwarded to be locally accessible to the Reverse SSH Server.

We can now connect to the client machine locally via the Reverse SSH Server by specifying the client's username, forwarded SSH port and the client's RSA key. In our example, the client's username was ec2-user and the port which was forwarded was 56148:

`ssh ec2-user@127.0.0.1 -p 56148 -i ~/.ssh/myclient-id_rsa`

That's it, you can add as many clients as you wish to the Reverse SSH Server.

Here is a diagram depicting a typical AWS architecture:

![](/images/reversesshserverawsdiagram.png)

I﻿n this illustration, we have three clients connecting back to the Reverse SSH Server.

### **Removing a client from the Reverse SSH Server**

On the Reverse SSH Server, we can remove a client by running:

`sudo reversessh -r myclient`

The "-r" flag indicates that we are removing a client. This operation will remove a client from the Reverse SSH Server and terminate any existing connections from that client.

### **FAQ**

*   Does the Reverse SSH Server appliance support single-AZ, multi-AZ or multi-region deployments? The appliance is a single EC2 instance that can be deployed into any VPC in any region.
*   Does the Reverse SSH Server appliance support all regions? Yes, all regions are supported.
    Should we use the root user for deploying the Reverse SSH Server appliance? No, it is recommended to use a non-root user to deploy the appliance.
*   Should the Reverse SSH Server appliance be encrypted when deployed? Yes, security best-practice is to encrypt the appliance when provisioned.
*   Is data in-transit encrypted? Yes, all connections made to the Reverse SSH Server are via encrypted channels.
*   Which services used by Reverse SSH Server are billable? The Reverse SSH Server appliance incurs EC2 and software cost when deployed. For example, a t3.small Reverse SSH Server instance costs $0.021 per hour plus $0.015 per hour for software for a total of $0.036 per hour of deployment.
*   How can I monitor the health of the Reverse SSH Server appliance? Check the health of your server by viewing its status in the "Instance State" column in the EC2 Dashboard.
*   How does the Reverse SSH Server appliance get patched and updated? The appliance is set to auto-install security updates on a daily basis.
*   How do I handle a non-responsive Reverse SSH Server appliance? This is very rare, but a reboot should resolve the issue.
*   Is there technical assistance available to help troubleshoot? Yes, we're available to assist and will typically respond within 1 business day. We can be reached by emailing: support at salientengineering.com



Products

HoneyDrop

Multi-Port Forward Server

Reverse SSH Server