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.
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:
* 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.
* 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:
* – 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.
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:
* 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.
* 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.
* – 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
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.
Network security has changed a lot over the years, it had to. From wide open infrastructures to tightly controlled environments, the standard practices of network security…
President Joe Biden recently signed an executive order which made adhering to cybersecurity standards a legal requirement for federal departments and agencies. The move was not…
The wide-spread adoption of cloud infrastructure has proven to be highly beneficial, but has also introduced new challenges and added costs – especially when it comes…
Where Modern Observability and Financial Savvy Meet.
Oh no!We didn’t find anything for “”,
