In a previous post, we looked at an example of a fictional bookstore company and recommended mirroring strategies for that specific scenario. In this post, we’ll be looking at a fictional bank and recommended mirroring strategies for their network traffic.
For a list of the most commonly used strategies, check out our traffic mirroring tutorial.
GoldenBank
In this scenario, the client is running two different services, in two different private VPCs. The two VPCs cannot communicate with each other. The reverse proxies handle the majority of the traffic and perform basic request validations such as URIs and web methods and possibly also parameters type validation and then forward the request to the frontend servers.
Unlike the previous scenario, the connection between the reverse proxy and the frontend servers is also encrypted in TLS. The frontend servers perform business context validation of the requests and then process them by sending requests to the backend servers.
Close-up App1
Close-up App2
The backend servers in app1 rely on a storage server, while the backend servers of app2 rely on an AWS RDS service.
Following are the details of the security groups of all instances in both applications’ VPCs:
VPC App1
Rev Proxy
(No public IP)
| From | To | Service | Status |
|---|---|---|---|
| any | any | HTTP/tcp | Allow |
| any | any | HTTPS/tcp | Allow |
| 10.0.0.0/16 | Frontend | HTTPS/tcp | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | DNS | DNS/udp | Allow |
| 10.0.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Frontend
(No public IP)
| From | To | Service | Status |
|---|---|---|---|
| Rev. Proxy | 10.0.0.0/16 | HTTPS/tcp | Allow |
| 10.0.0.0/16 | Backend | Custom ports set | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | DNS | DNS/udp | Allow |
| 10.0.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Backend
(No Public IP)
| From | To | Service | Status |
|---|---|---|---|
| Frontend | 10.0.0.0/16 | Custom ports set | Allow |
| 10.0.0.0/16 | Storage | NFS/udp | Allow |
| 10.0.0.0/16 | Storage | NFS/tcp | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | DNS | DNS/udp | Allow |
| 10.0.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Storage
(No Public IP)
| From | To | Service | Status |
|---|---|---|---|
| Backend | 10.0.0.0/16 | NFS/udp | Allow |
| Backend | 10.0.0.0/16 | NFS/tcp | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | DNS | DNS/udp | Allow |
| 10.0.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
DNS
(No Public IP)
| From | To | Service | Status |
|---|---|---|---|
| 10.0.0.0/16 | any | DNS/udp | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Package Cache
(No Public IP)
| 10.0.0.0/16 | any | HTTP/tcp, HTTPS/tcp | Allow |
| 10.0.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.0.0.0/16 | DNS | DNS/udp | Allow |
Here are our visibility recommendations for similar networks:
Reverse Proxies and Front-end servers
Outbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Monitor everything * | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* Even though most of the traffic is encrypted since it would include responses to client requests, the outbound traffic is still extremely valuable. It can indicate the size of the data being sent to the client and assist in detecting large data leaks, it can detect connections originating from the reverse proxy itself and help detect command and control connections, it can also detect connections or connection attempts to other servers other than the frontend servers which can detect lateral movement.
Inbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Drop HTTPS* | reject | TCP | – | 443 | 0.0.0.0/0 | 10.0.0.0/16 |
| 200 | Monitor everything else | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* Since the incoming traffic on HTTPS is encrypted, the only thing it can indicate is its volume over time which can indicate certain types of DoS or DDoS and also the validity of the certificates used. So if the traffic volume is expected to be high, we would recommend excluding this traffic.
Backend servers
Since the frontend servers are contacting these servers with requests that are supposed to be valid after the checks done by the proxy and frontend servers, the traffic volume is expected to be significantly lower than traffic volume to the proxy and frontend servers.
Also, since this is the last chance to detect malicious traffic before it reaches the database, we believe that all traffic from these servers should be mirrored. However, if this is still too expensive for your organization, we would recommend that you use the following mirroring configuration to at least be able to tell if a backend server is behaving abnormally which may indicate that it has already been breached:
Outbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Exclude file service activity ** | reject | TCP | – | NFS | 10.0.0.0/16 | 10.0.0.0/16 |
| 200 | Exclude file service activity ** | reject | UDP | – | NFS | 10.0.0.0/16 | 10.0.0.0/16 |
| 300 | Monitor everything * | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* – Although this rule will also mirror the server’s responses to frontend requests we do recommend that you mirror it since it might also contain HTTPS connections initiated by malware running on the proxy servers to command and control servers. Also, this might include unintended responses that will indicate that an attack (such as XSS or SQL Injection) took place.
** – Since the filesystem activity is usually heavy, we would recommend you avoid mirroring this type of traffic unless it is highly valuable in your application or network architecture.
Inbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Monitor everything else | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
Storage Servers
Outbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Exclude file service activity * | reject | TCP | – | NFS | 10.0.0.0/16 | 10.0.0.0/16 |
| 200 | Exclude file service activity * | reject | UDP | – | NFS | 10.0.0.0/16 | 10.0.0.0/16 |
| 300 | Monitor everything | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
DNS server
Since this server generates a very minimal amount of traffic that is so extremely valuable for detecting so many types of attacks we recommend that you would mirror all traffic in and out of this server.
Package cache server
Since this server is responsible for packages installations on all other servers, the data from and to this server can answer questions like who installed what and when, which can be crucial in a forensic investigation and for detecting installation of malicious tools on the server.
Also, the traffic volume from and to this server is expected to be quite low. Therefore, we recommend that you would mirror all traffic in and out of this server.
Bastion server
Since this server is serving as the only way to manage all other servers, provided that it is being used to update the code on the various servers, install required packages, etc., the traffic volume should be relatively low and the value of the data it can provide is extremely high and therefore we recommend that you would mirror all traffic in and out of this server.
VPC App2
Rev Proxy
(No Public IP)
| any | any | HTTP/tcp | Allow |
| any | any | HTTPS/tcp | Allow |
| 10.1.0.0/16 | Frontend | HTTPS/tcp | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | DNS | DNS/udp | Allow |
| 10.1.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Frontend
(No Public IP)
| Rev. Proxy | 10.1.0.0/16 | HTTPS/tcp | Allow |
| 10.1.0.0/16 | Backend | Custom ports set | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | DNS | DNS/udp | Allow |
| 10.1.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Backend
(No Public IP)
| Frontend | 10.0.0.0/16 | Custom ports set | Allow |
| 10.1.0.0/16 | RDS | DB ports | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | DNS | DNS/udp | Allow |
| 10.1.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
RDS
(No Public IP)
| Backend | 10.1.0.0/16 | DB ports | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | DNS | DNS/udp | Allow |
| 10.1.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
DNS
(No Public IP)
| 10.1.0.0/16 | any | DNS/udp | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | Packages Cache | HTTP/tcp, HTTPS/tcp | Allow |
Package Cache
(No Public IP)
| 10.1.0.0/16 | any | HTTP/tcp, HTTPS/tcp | Allow |
| 10.1.0.0/16 | any | NTP/udp | Allow |
| Bastion | any | SSH/tcp | Allow |
| 10.1.0.0/16 | DNS | DNS/udp | Allow |
This network architecture is quite complex and would require an approach that would combine multiple data sources to provide proper security for it. In addition, it involves traffic that is completely encrypted, storage servers that are contacted via encrypted connections, and also AWS services that cannot be mirrored to the STA.
Here are our visibility recommendations for similar networks:
Reverse Proxies and Front-end servers
Outbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Monitor everything * | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* Even though most of the traffic is encrypted since it would include responses to clients requests, the outbound traffic is still extremely valuable. It can indicate the size of the data being sent to the client and assist in detecting large data leaks, it can detect connections originating from the reverse proxy itself and help detect command and control connections, it can also detect connections or connection attempts to other servers other than the frontend servers which can detect lateral movement.
Inbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Drop HTTPS* | reject | TCP | – | 443 | 0.0.0.0/0 | 10.1.0.0/16 |
| 200 | Monitor everything else | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* Since the incoming traffic on HTTPS is encrypted, the only thing it can indicate is its volume over time which can indicate certain types of DoS or DDoS and also the validity of the certificates used. So if the traffic volume is expected to be high, we would recommend excluding this traffic.
Backend servers
Outbound
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Monitor everything * | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
* – Since this server is expected to communicate with the RDS service, we would recommend mirroring all the traffic from this instance as this will allow the detection of database-related attacks. In addition, the RDS security group should be configured to allow connections only from the backend server (this can be more strict by configuring the RDS itself to allow connections only if they were identified by a certificate that exists only on the backend server) and an alert should be defined in Coralogix based on CloudTrail logs that would fire if the security group is modified.
Also, by forwarding the database logs from the RDS instance, an alert should be defined in Coralogix so it would be triggered if the database detects connections from other IPs.
Inbound
Since the traffic volume here should be quite low due to the validations done by the proxies and front-end servers, and due to the fact that this is the last point we can tap into the data before it is saved into the DB we recommend that you mirror all incoming traffic from this server
| Rule number | Description | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| 100 | Monitor everything * | accept | All protocols | – | – | 0.0.0.0/0 | 0.0.0.0/0 |
DNS server
Since this server generates a very minimal amount of traffic that is so extremely valuable for detecting so many types of attacks we recommend that you mirror all traffic in and out of this server.
Package cache server
Since this server is responsible for packages installations on all other servers, the data from and to this server can answer questions like who installed what when, which can be crucial in a forensic investigation and for detecting installation of malicious tools on the server. Also, the traffic volume from and to this server is expected to be quite low. Therefore, we recommend that you mirror all traffic in and out of this server.
Bastion server
Since this server is serving as the only way to manage all other servers, provided that it is being used to update the code on the various servers, install required packages, etc., the traffic volume should be relatively low and the value of the data it can provide is extremely high and therefore we recommend that you mirror all traffic in and out of this server.
Summary
Just like in any other field of security, there is no real right or wrong here, it’s more a matter of whether or not it is worth the trade-off in particular cases. There are several strategies that can be taken to minimize the overall cost of the AWS traffic monitoring solution and still get acceptable results.
For a list of the most commonly used strategies, check out our traffic mirroring tutorial.
