[VMC on AWS] "Your Amazon EC2 Abuse Report" Email from VMware support
Article ID: 329872
Updated On:
Products
VMware Cloud on AWS
Issue/Introduction
VMware, AWS, and product users are part of what is referred to as a shared responsibility model https://aws.amazon.com/compliance/shared-responsibility-model/. Part of the shared responsibility model means that customers are responsible for the security of their environment.
AWS monitors for specific traffic flows for known malicious IPs or malicious behavior coming from a customers environment which is what these reports identify. VMC on AWS administrators are responsible to identify and prevent future traffic flows.
Below is an example of an email that VMC on AWS customers may receive.
We have received an Abuse alert activity that resembles a Denial of Service attack against remote hosts. Please find the details below.
AWS Account: xxxxxxxxxxx <-------- This is VMwares shadow account
Instance Id: i-000000000000 <------- This is the instance ID of the VMware ESXi host the active NSX Edge is on
Report begin time:
Report end time:
Remote Ip: x.x.x.x <--------- This IP has been identified by AWS as a malicious source and the SDDC is communicating with it
Private Ip(s): x.x.x.x <--------- This will be the ESXi host the NSX Edge is on. This is reported as all traffic leaving VMC to AWS goes through the NSX Edge. This IP does not represent the problematic VM it only represents the network egress point for the environment.
Public Ip(s): N/A
Remote port(s):
Total packets sent:
Total bytes received:
Total packets received:
Actions Needed:
Block all outbound TCP traffic going out to remote Ip: x.x.x.x
AWS monitors for specific traffic flows for known malicious IPs or malicious behavior coming from a customers environment which is what these reports identify. VMC on AWS administrators are responsible to identify and prevent future traffic flows.
Below is an example of an email that VMC on AWS customers may receive.
We have received an Abuse alert activity that resembles a Denial of Service attack against remote hosts. Please find the details below.
AWS Account: xxxxxxxxxxx <-------- This is VMwares shadow account
Instance Id: i-000000000000 <------- This is the instance ID of the VMware ESXi host the active NSX Edge is on
Report begin time:
Report end time:
Remote Ip: x.x.x.x <--------- This IP has been identified by AWS as a malicious source and the SDDC is communicating with it
Private Ip(s): x.x.x.x <--------- This will be the ESXi host the NSX Edge is on. This is reported as all traffic leaving VMC to AWS goes through the NSX Edge. This IP does not represent the problematic VM it only represents the network egress point for the environment.
Public Ip(s): N/A
Remote port(s):
Total packets sent:
Total bytes received:
Total packets received:
Actions Needed:
Block all outbound TCP traffic going out to remote Ip: x.x.x.x
Resolution
VMware suggests that customers create a deny all rule in the compute gateway for all traffic going to the identified "Remote IP".
Administrators can further identify what VM is sending this traffic by enabling logging on the above mentioned firewall rule then monitoring vRLIC logs to identify the IP attempting to communicated with the identified malicious IP. See below for an example log.
FIREWALL_PKTLOG: 123571f INET match DROP 13313 OUT 80 TCP x.x.x.x/5432->x.x.x.x/50635
Administrators may also use third party antivirus to identify and block the malicious traffic.
Administrators can further identify what VM is sending this traffic by enabling logging on the above mentioned firewall rule then monitoring vRLIC logs to identify the IP attempting to communicated with the identified malicious IP. See below for an example log.
FIREWALL_PKTLOG: 123571f INET match DROP 13313 OUT 80 TCP x.x.x.x/5432->x.x.x.x/50635
Administrators may also use third party antivirus to identify and block the malicious traffic.
Feedback
Yes
No
Powered by
