Photo by FLY:D on Unsplash

Introduction

This is Part 2 of a multi part blog series, focusing on the NSX Advanced Firewall for VMC on AWS.

If you have not already reviewed Part 1, click here

DISCLAIMER: In this post I will be running vulnerability scans and attacks against a purposely vulnerable web application. Utilizing tools within the Kali Linux distribution to attack a VM running OWASP Broken Web Applications Project.

I have deployed these VM’s to an isolated network, with no external connectivity. Never perform an internal or external penetration test without written approval from the system owner!

Setup IDS/IPS Profile & Rule

In this section we will setup an IDS/IPS profile and rule. NSX Distributed IDS/IPS takes advantage of the VMware intrinsic understanding of workloads, you can turn on the signatures that are applicable to the workload. This results in better throughput, without the need to run all signatures simultaneously. See this blog post for more information.

1. Login to the VMware Cloud Services Portal
2. Select the VMware Cloud on AWS tile
   

3. Click the name of the relevant SDDC
   

4. Click the Networking & Security tab
5. Click Distributed IDS/IPS within the Security section
6. Click Profiles
7. Click Add Profile
   

8. Enter a name for the profile and click Save. In this example I am accepting the defaults, but you can tailor profiles to meet your requirements. e.g. If you click Products Affected, you can limit to the scope to particular products. e.g. Linux, Window, Apache etc. This results in better throughput. You can also select specific Signature Severities, Attack Types, Attack targets and CVSS
   

9. Verify that the newly created profile has a status of sucess. If not, click the arrow to refresh

10. Click on Rules, then Add Policy then give the policy a name
    

10. Select the check box next the name of the policy, then click Add Rule
    

11. Name the new rule, and hover over select IDS Profile and click the pencil
    

12. Select the IDS profile we created earlier and click Save
    

12. Hover over Destinations and click the pencil
    

12. I already have a group created for the isolated network where the OWASP Broken Web Applications & Kali Linux VM’s reside, so I’ll select that and click Apply
    

12. In this example we will leave the Sources and Services to Any and Applied to field set to DFW. This will result in all traffic with a destination of the isolated network being inspected by the IDS/IPS engine. This is a basic example, but you can tailor the IDS/IPS rules just like you can with the Distributed Firewall. You can also leverage groups you have already created for DFW with the IDS/IPS policy. e.g. maybe you already have a group defined for workloads that are subject to PCI. We will also leave the Mode to Detect Only. We will revisit this later and change to Detect & Prevent. Click Publish
    
    NOTE For IDS/IPS to work, Distributed firewall (DFW) must be enabled. If traffic is blocked by a DFW rule, then IDS/IPS can not see the traffic

Running scans against the Web Server

Is this next step, I will leverage the tools Nmap to scan the server and Nikto to scan for vulnerabilities

In this environment, the Kali Linux server is 172.16.10.200 and the OWASP Broken Web Application is 172.16.10.100

1. From a session on the Kali Linux server I run nmap -sV -v 172.16.10.100, to initiate a scan of the server which also probes the application ports in an attempt to get application level information. In the output you can see that nmap has detected a number of open ports, the application version running on those ports, and details about the Operation System
   

2. Now that I know that server is running HTTP on port 80, I’ll run the Nikto tool to perform a vulnerability analysis on port 80. From a session on the Kali Linux server I run nikto -h 172.16.10.100 -p 80
   Example analysis below, detailing version information, allowed HTTP methods and potential vulnerabilities that an attacker could exploit
   

Review IDS/IPS Events

Now that we have generating some potential harmful traffic, lets review the IDS/IPS event for details

1. Within the VMC on AWS Cloud Console select Networking & Security, Distributed IDS/IPS, Events
   In this example there have been 58 unique intrusion attempts, 19 critical, 38 high and 1 medium. You can also filter this view based on signature criticality, attack type and more. The bottom pane details each event in more details. Lets explore one in the next step
   

2. Expand any of the events, this will present complete details about the event. e.g. Criticality, information about the attacker and target, signature ID, protocol, number of VMs Affected, 2 in this example CVSS score and CVE number if applicable. The purple bar indicates that the intrusion activity was detected only. Which makes sense, as this matches how we configured the rule earlier. Click the purple bar
   

3. Review more details about the intrusion attempt, then click Close
   

Change IDS/IPS Rule to Detect & Prevent

Now we will change the IDS/IPS rule from Detect Only to Detect & Prevent

1. Within the Distributed IDS/IPS section, click the Rules tab. Click the caret to expand the rule, change the Mode to Detect & Prevent
   

2. Click Publish
   

Rerun scans against the Web Server

1. In this step I re run the Nikto tool nikto -h 172.16.10.100 -p 80
   

2. Notice the difference in the output, I no longer see details around vulnerabilities I did in the early step. No details on the allowed HTTP methods. Also note that the Nikto scan terminated with 20 errors and gave up!
   

Review IDS/IPS

Lets switch back to the IDS/IPS events and review.

1. Within the VMC on AWS Cloud Console select Networking & Security, Distributed IDS/IPS, Events
   

2. I then expand one of the events in the bottom pane. Note the details indicate Nikto Web App Scan in Progress, the difference this time is that the attempt was prevented. As indicated by the green bar in the bottom right
   

3. Double clicking the green bar, I’m presented with more details. Note the Action is Drop/Prevent (Prevented). Click Close when you have finished reviewing
   

Conclusion

In this post we walked through how to leverage the NSX IDS/IPS solution to successfully prevent an intrusion attempt against the web server.

If you have any questions, pleae leave a comment below, or contact me via Twitter

• NSX
• VMC