Testing the Locks: Validating Security in a Linux Environment
The last lock to test is, in many cases, the first entrance into your network, the perimeter. Let's test it by placing our VM outside the network and then performing a network map against our publicly facing IP address(es) to verify that only allowed services are allowed in or out of the network. We use the time-tested Nmap application for this role.
Although Nmap is on the BackTrack VM, you need to update to the latest version to use the handy new topology tab of the zenmap front-end GUI. Download Nmap from the project's site, and install on the VM with the usual ./configure, make, make install sequence. Type the command zenmap from a terminal to bring up the GUI. Enter a host, host range or network as the target, select Regular Scan from the Profile drop-down list and click on Scan. This performs a cursory scan of the host/networks and identifies open ports and other available information about the host, such as OS and app versions (Figures 8 and 9). Be patient; this process may take a while. Use Nmap's results to verify that only allowed hosts and services are accessible from the outside.
After running Nmap, we can start to envision how an attack against our network might take place. Assume we can glean our network's external IPs from public DNS or whois records. With this information, we run a network map against those IP addresses and identify host OS and application versions. With map results in hand, we scan said hosts for vulnerabilities as discussed in section 3 of this article. If we are lucky, we find one and run an exploit against it to take control of the box. If all we wanted was to own the box, mission accomplished. But, if we wanted to own other hosts or the network, we might begin a new map from the inside or sniff with a tool like Wireshark from the owned box. If we passively sniff traffic instead of map, we are less likely to set off any IDS alarms. At that point, we notice SSH traffic to a particular machine, so we attempt to gain a remote shell against it. Hopefully, there aren't any glaring openings in our local configuration, as we checked for in section 1, or we might lose another box or boxes.
Although this is not a standard blueprint for attack by any means, it is a possible avenue for attack. There are too many methods, techniques, hacks, cracks and attacks to document at length here. By performing regular assessments like the one shown in this article, we can lower the risk of attack, but not eliminate it. Unfortunately, it is a lot harder to play defense than offense. The bad guys do not focus on one aspect of security (or insecurity), and all they need is a single opening in the network, the OS or the application to be successful. Hopefully, after sampling the tools here, you can test your own locks and get the peace of mind that your network, your systems and your security measures work.
Jeramiah Bowling has been a systems administrator and network engineer for more than ten years. He works for a regional accounting and auditing firm in Hunt Valley, Maryland, and holds numerous industry certifications including the CISSP. Your comments are welcome at email@example.com.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Keeping track of IP address
1 hour 37 min ago
- Roll your own dynamic dns
6 hours 50 min ago
- Please correct the URL for Salt Stack's web site
10 hours 2 min ago
- Android is Linux -- why no better inter-operation
12 hours 17 min ago
- Connecting Android device to desktop Linux via USB
12 hours 46 min ago
- Find new cell phone and tablet pc
13 hours 44 min ago
15 hours 13 min ago
- Automatically updating Guest Additions
16 hours 21 min ago
- I like your topic on android
17 hours 8 min ago
- This is the easiest tutorial
23 hours 43 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?