To install and use Nmap port scanner against one of your Deployments in the Cloud. Display what ports are open/closed, and check that against your Security Group configuration. Finally, apply additional security measures by configuring multiple Security Groups for each tier in the Deployment.
Table of Contents
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:
Further, this tutorial uses Nmap before and after implementing best practices with respect to Security Groups. For example:
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.
Nmap is a great port scanner tool to add to your security toolkit. However, in and of itself, it cannot secure your Deployment and applications. Although Nmap is used by many security experts, this tutorial is a learning tool. It will not teach you everything you need to know about Nmap. Please consult their documentation and/or a security expert for that.
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.
Use the following as a guideline to locate and import a "LAMP All-in-one Trial" ServerTemplate from the RightScale Component MultiCloud Marketplace.
Once imported, the ServerTemplate and associated RightScripts are considered part of your "local" collection.
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:
Once your ServerTemplate is cleaned up:
Add a Server to your Deployment. Remember to name it something descriptive, such as "Nmap Port Scanner".
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.)
rpm -vhU http://nmap.org/dist/nmap-5.21-1.i386.rpm
Retrieving http://nmap.org/dist/nmap-5.21-1.i386.rpm Preparing... ########################################### [100%] 1:nmap ########################################### [100%
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:
nmap -v -A -T4 -PN www.YourCompany.com nmap -v -A -T4 -PN 184.108.40.206 # Where the IP could be of your database Server, or other Server in your Deployment.
Note: You can run against public IP addresses or DNS fully qualified hostnames (even from a Server external to your Deployment, depending on your Security Group configuration).
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 220.127.116.11
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).
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:
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.
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.
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.
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.
© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.