Adding an Nmap Port Scanner

Scenario

To make this tutorial more realistic, practical, and help convey how one might use nmap as well as how Security Groups function, this tutorial will run nmap from a Server that is external to the Deployment you wish to scan for open ports.  It assumes your Deployment is comprised of the following three tiers:

1. Front end load balancers
2. Application Server (or Servers. Possibly a Server Array as opposed to individual Servers)
3. Back end database Servers (master and slave)

Further, this tutorial uses Nmap before and after implementing best practices with respect to Security Groups.  For example:

• Before - Your Deployment uses a single Security Group for all Servers in the Deployment.   This may be fine while in development and test cycle, but this is not best practice for production Deployments.  For example, your 3 tiered Deployment has the following Security Group:
  • One Security Group used by all Servers in the Deployment
  • Ports 22, 80, 3306 and any application specific ports are "open" to all.
  • Security Group that has not been added to itself.  (Note: For testing purposes only during this tutorial, if you already performed this step, you can simply "revoke" it.)
• After - Each tier will have separate Security Groups to minimize exposure and hence tighten up on security.

Nmap

Nmap is a free, open source security tool for scanning ports and reporting on their status.  Their website is http://nmap.org 

This tutorial was originally developed as a lab exercise in the Security module of the RightScale (instructor led training) Operations Course.  As a learning tool, in addition to the objective stated above, it also has the objective of getting students to step through the entire progression from creating a Deployment, adding a Server, ... all the way to installing and running nmap.  Some repetition helps solidify the basics and mechanics covered in your learning curve.  Originally designed as a corporate lab exercise where students worked together, but it can be completed individually or corporately.

Although this tutorial shows Nmap getting installed on its own Server (and even Deployment) as a learning aide, it is quite thin and of course could be installed on an existing Server in a Deployment.

Create a Deployment

Create a Deployment for a Server that will run your nmap port scanner.  You can name it whatever you like.  As an example, "Security Lab" would  work fine.

1. Go to Manage > Deployments. Click New and provide the following information:
   • Nickname - User-defined name for the deployment. 
   • Description - A short, internal-only description of the deployment.

Import a ServerTemplate

Use the following as a guideline to locate and import a "LAMP All-in-one Trial" ServerTemplate from the RightScale Component MultiCloud Marketplace.

1. Go to Design > MultiCloud Marketplace > ServerTemplates
2. Find and select the appropriate ServerTemplate. Browse by categories, perform a keyword search, or use the filter options to find the correct ServerTemplate.
3. Click Import.
    

Once imported, the ServerTemplate and associated RightScripts are considered part of your "local" collection.

Clone a ServerTemplate and Customize it

Although you could use the full LAMP stack, there is no need to.  It will boot faster and you will have less hassle with unneeded Inputs if you trim down the ServerTemplate.  Additionally, as another learning tool, it's recommended you streamline the cloned ServerTemplate so that it is essentially a Linux Server.  The example below uses a Hadoop ServerTemplate, you will want to clone the ServerTemplate you just imported (such as the LAMP Developer ServerTemplate), so that you have an editable copy.  The mechanics of the task remain the same.

Select a ServerTemplate that you would like to clone.  For example, you may have an uneditable ServerTemplate that you imported from the MultiCloud Marketplace.

When you click Clone, an editable (private) copy of that ServerTemplate is added to your 'Local' view.  

By default, a version is appended to the template's name to make it distinct from the original ServerTemplate (for example, v10).  As a best practice, we recommend changing the name of the ServerTemplate to help better distinguish the template.  If you are using one of the ServerTemplates published by RightScale, you might want to keep the original version number in the name so that it will be more apparent when a newer version of that ServerTemplate becomes available in the MultiCloud Marketplace.  (for example, "My PHP App Server v9 (clone)")

Notice that you can also see which ServerTemplate it was cloned from (in this case, PHP App Server v9).

You can now customize your local ServerTemplate by deleting the following unneeded Boot and Operational RightScripts:

• MySQL Database (DB)
• Web

• OK to leave Sys Monitoring, but remove the Monitoring of MySQL and Apache (because they will not be installed). If you forget to delete these RightScripts from your ServerTemplate your Server will strand while booting.

Once your ServerTemplate is cleaned up:

• Rename your cloned ServerTemplate to something more descriptive.  For example, "Simple Linux Server".
• If there are any yellow spheres (indicating a newer revision of a RightScript exists), select the Update to latest RightScripts action button.

Add a Server to your Deployment and Launch

Add a Server to your Deployment.  Remember to name it something descriptive, such as "Nmap Port Scanner".

1. Navigate to the deployment you previously created (where you are adding the server).
2. Even before selecting the Add Server action button, you should select the cloud that the server should be in. Use the Select Cloud drop down menu to make your choice. Remember that if you specified a default Availability Zone for your deployment, you should add the server to a cloud that includes that zone. (e.g. US-East)
3. Click Add Server to add a server to your deployment. The Add Server Assistant opens.  Use the following field descriptions to add a server (example shown is from EC2): 

Field Descriptions:

• Deployment - A Server always exists within the context of a deployment.  Therefore, when you create a Server, you must specify into which Deployment the Server will be added.  Each RightScale account has a "Default" Deployment that's best used for testing purposes.  Select either the "Default" one or another Deployment that you've already defined.
• ServerTemplate - Select the type of ServerTemplate from the pull-down menu.  When launching directly from a ServerTemplate, this has already been decided and will simply be listed in the dialog box.
  • Private - ServerTemplate from your private MultiCloud Marketplace.  That is, ServerTemplates that you either created from scratch, or imported and cloned.  These ServerTemplates are your own copy that you are free to customize.  They maintain their own lineage.
  • Imported - Anything you have imported directly from the MultiCloud Marketplace (which is a static copy).  Additionally, any ServerTemplates that you have subscribed to (which is a HEAD version, changing not a static revision.)
  • Then select the actual ServerTemplate name from another pull-down menu.  (e.g. Simple Linux Server)
• Cloud -  What cloud the Server should be added to.  When adding a Server, this has already been selected via the Select Cloud action button, so in this dialog window you cannot alter it. It is simply displayed for informational purposes.
• MultiCloud Image - Select the MCI to use or leave inherit from the ServerTemplate (default).
• Instance Type - Select the Instance Type (e.g. small, medium, large, etc.) or inherit from the MultiCloud Image (default)
• Nickname - Give a descriptive name for the Server's primary purpose.
• SSH Key - Specify the (previously created) SSH Key to use.
• Security Group - Select the (previously created) Security Group (or Groups) to use for security purposes.
• Availability Zone - Select what Availability Zone (EC2) this Server should be in.  Recall that there are additional charges for traffic across zones.  Servers are typically placed in the same zone, unless the Deployment is working towards high availability across different zones. Some clouds have multiple zones or regions.
• Elastic IP - Specify what EIP (or none) to use for the Server. 
• Associate IP at launch - Normally you will leave this default (checked) so that an IP address is associated with the Server at launch. 

4. Click Add after you have filled out all the fields.

• Select the Launch action button to launch your Server when ready.

Locate the Nmap Distribution

Googling Nmap and perusing their site should lead you to the following distribution:  http://nmap.org/dist

Note:  Web sites and various URL's on the web often change, and are beyond our control.  For the purposes of this Tutorial, we will use specific URL's, but please realize they could change as web sites get revised, and newer software versions become available. (That is the beauty of automating this process at some point, and using a SVN or GIT like repository for code checkout.)

Install Nmap

• SSH into your Nmap Port Scanner Server
• Use rpm to install nmap on your Server.  The version you install may vary, depending on your architecture or more recent releases.  As an  example, for the version we installed the rpm command would be:

rpm -vhU http://nmap.org/dist/nmap-5.21-1.i386.rpm

• You should see something similar to the following as the distribution is retrieved:

Retrieving http://nmap.org/dist/nmap-5.21-1.i386.rpm
Preparing... ########################################### [100%]
1:nmap ########################################### [100%

Learn more about Nmap

Once installed, if you are not familiar at all with Nmap, you should look over the attached version 5 cheat-sheet, and (at least the basics of) the man page.  (Note:  Some browsers require a plug-in to view PDFs. If you have troubles, feel free to download and view the nmap cheat-sheet natively from your own hard disk and copy of Adobe Acrobat Reader, which of course is free and installed on most computers.)

# man nmap

Hint:  Among other possible command line options, pay particular attention to:

• -v (verbose)
• -PN (without this option, particularly if ICMP is not enabled in your Security Group, you will likely get no output from your scans)
• -sV

nmap -v -A -T4 -PN www.YourCompany.com
nmap -v -A -T4 -PN 1.2.3.4   # Where the IP could be of your database Server, or other Server in your Deployment.

Running against a Deployment with a single Security Group

As mentioned previously, having a single Security Group with many ports open is not considered best practice.  Regardless, run nmap against several Servers in your multi-tiered Deployment.  For example:

# Run against your front end load balancers (Tier 1 Servers).  Use their public IP or public DNS name.
nmap -v -A -T4 -PN LoadBalancer1_PublicIP
nmap -v -A -T4 -PN LoadBalancer2_PublicIP

# Run against one of your application Servers (Tier 2)
nmap -v -A -T4 -PN ApplicationServer_PublicIP

# Run against your master database Server (Tier 3)
nmap -v -A -T4 -PN MasterDatabase_PublicIP

Depending on your exact Security Group configuration and which Server you run against, the results from nmap will vary. 

Important!  nmap reports on ports it finds open. That does require something to be "listening" on the other side. For example, even if you have port 3306 open in your Security Group, port 3306 will not be listed as open by nmap on your tier 1 and 2 Servers.  (Because MySQL will not be running on those Servers.)  However, it may be included in the "open list" for your database Servers, depending on your specific Security Group settings.

Nmap has a lot of output to it.  A sample excerpt from a run against a tier 1 Server's public DNS name will look similar to this:

. . .

Initiating SYN Stealth Scan at 21:12
Scanning ec2-174-129-39-115.compute-1.amazonaws.com (10.120.63.195) [1000 ports]
Discovered open port 22/tcp on 10.120.63.195
Discovered open port 80/tcp on 10.120.63.195
Discovered open port 443/tcp on 10.120.63.195
Discovered open port 25/tcp on 10.120.63.195

. . . 

 A similar run against a master MySQL database Server with relaxed security (port 3306 open to the world) could include a line similar to:

Discovered open port 3306/tcp on 184.73.2.8

However, if you have added the Security Group to itself instead of implicitly adding port 3306 for your database Server you will not see port 3306 opened up to the world. 

Make notes of what you have learned.  Having a single Security Group for production Deployment as shown above is far too lax on security.  The next step is to implement multiple Security Groups (for each tier).

Create multiple Security Groups for each Tier in your Deployment

Using a single security group for a multiple-server, multi-tiered deployment may be convenient during the test and development phase of a project, but it is not recommended for production. This document discusses a possible implementation using multiple security groups for a typical three-tier deployment in the cloud. For example, consider a deployment with the following three tiers:

1. Front-end load balancers
2. Application servers (for example, a server array)
3. Back-end database servers (master/slave)

Warning!
Changes to existing security groups already associated with running servers will take effect immediately for new connections. However, you cannot change the security groups assigned to a running server. You must terminate the server (or choose the Relaunch option and change its properties prior to launch) before adding or removing its security groups, as described in Assign Multiple Security Groups to a Server. To better understand the best practices for shutting down and starting up servers in your multi-tiered deployment, see Shutting Down a Multi-Tiered Deployment and Starting Up a Multi-Tiered Deployment.

The primary benefit of creating multiple security groups tailored to your specific deployment is increased security, particularly with regard to the application and database tiers, which generally should not be publicly accessible.

Linux

For Linux-based architectures, create the following security groups.

Note: The example screenshot above applies to a deployment using v12 and 13 ServerTemplates, where TCP 8000 is the application listener port. However, for v14 ServerTemplates, TCP 8080 is the application listener port. Be sure to configure your security group accordingly.

Create a security group for each tier, plus one that's dedicated for allowing SSH access. In the example above, each server should be configured to use two security groups. Each server will have the security group for SSH access and their tier-specific security group.

• SSH access
  • Open TCP port 22 for SSH access.
• HAProxy Load Balancer Tier
  • Open TCP port 80 to any IP to allow standard HTTP access.
  • Open TCP port 443 to any IP for HTTPS access; required for SSL (optional).
  • Enable ICMP if you want to ping the server (optional).
• Application Tier
  • v12 and v13
    • Open TCP port 8000 to accept requests from servers launched with the HAProxy load balancers' security group (e.g. '3tier-lb'). Connections between the load balancers and application servers are made over the private network. 
  • v14
    • Open TCP port 8080 to accept requests from servers launched with the HAProxy load balancers' security group (e.g. '3tier-windows-lb'). Connections between the load balancers and application servers are made over the private network. 
  • Open other application-specific ports, if applicable, such as a port used for administrative purposes or dedicated communications port.
• Database Tier
  • Open TCP port 3306 to accept requests from servers launched with the application servers' security group (e.g. '3tier-windows-app'). Connections between the application servers and the database server are made over the private network. 
  • Open TCP port 3306 to accept requests from servers launched with its own security group (e.g. '3tier-db'), which is used for data replication between the master and slave database servers. Connections between the database servers are made over the private network. 

Windows

For Windows-based architectures, create the following security groups.

Note: The example screenshot above applies to a deployment using v12 ServerTemplates, where TCP 80 is the application listener port. However, for v13 ServerTemplates, TCP 8000 is the application listener port. Be sure to configure your security group accordingly.

Create a security group for each tier, plus one that's dedicated for allowing RDP access. In the example above, each server should be configured to use two security groups. Each server will have the security group for RDP access and their tier-specific security group.

• Remote Desktop Connection (RDP access)
  • Open TCP port 3389 for Remote Desktop Protocol (RDP) access.
• HAProxy Load Balancer Tier
  • Open TCP port 80 to any IP to allow standard HTTP access.
  • Open TCP port 443 to any IP for HTTPS access; required for SSL (optional).
  • Enable ICMP if you want to ping the server (optional).
• Application Tier
  • v12 LTS
    • Open TCP port 80 to accept requests from servers launched with the HAProxy load balancers' security group (e.g. '3tier-windows-lb'). Connections between the load balancers and application servers are made over the private network. 
  • v13
    • Open TCP port 8000 to accept requests from servers launched with the HAProxy load balancers' security group (e.g. '3tier-windows-lb'). Connections between the load balancers and application servers are made over the private network. 
  • Open other application-specific ports, if applicable, such as a port used for administrative purposes or dedicated communications port.
• Database Tier
  • Open TCP port 1433 to accept requests from servers launched with the application servers' security group (e.g. '3tier-windows-app'). Connections between the application servers and the database server are made over the private network. 
  • Open TCP port 5022 to accept requests from servers launched with its own security group (e.g. '3tier-windows-db'), which is used for mirroring between the principal and mirror database servers. Connections between the database servers are made over the private network. 

See also

• Create a New EC2 Security Group
• Add a Security Group to Itself
• Add a Security Group to Another Security Group

Run nmap against your Deployment with multiple Security Groups

Now that you have created multiple Security Groups (and applied them to multiple Servers in the various tiers of your Deployment), re-run nmap and observe the stricter security configuration.  Most notably, you should not see port 3306 open on your database Servers.  Having a database port open to the public is considered a huge security liability.

Post Tutorial Steps

• You could install nmap on a local server and run similar tests to those discussed in this tutorial.  (That is, run nmap against your Deployment from a Server that is completely external to the Cloud.)
• You can also use telnet as a quick and easy tool to test a host and port.  For example:  # telnet www.YourCompany.com 80
• Automate the Nmap process.  If Nmap looks like a tool you may want to use more often, you should automate the process.  Create a "Nmap Installation" RightScript and install it as boot Script in any ServerTemplates where you might want to make use of Nmap.  To help your learning efforts surrounding RightScripts and Inputs, consider doing the following with your installation script:
  • Create a Input named VERSION
  • If VERSION is not set, hardcode it to a specific version (otherwise it should install the version you specify on launch)
  • Enter a Description for your RightScript, and the VERSION Input.
  • Time and interest permitting, make your RightScript "reboot safe".   Hint:  Look at one of our installation RightScripts and notice how we use the RS_REBOOT Input.
  • Make sure your RightScript exits gracefully  upon completion.