Testing the Locks: Validating Security in a Linux Environment
The second set of locks to validate is on your network. Any comprehensive security assessment must include validation of your network's correct operation. There is no better way to validate this than by simple observation. The first tool to use for this is the Wireshark network protocol analyzer. Wireshark puts your network card in promiscuous mode and captures any traffic broadcast on your local network segment. It may be necessary to take samples on different parts of your network or use span ports to get a good representation of normal traffic.
To start the program, open a terminal inside the VM and type wireshark. Once open, click on the Capture menu and then on Interfaces. On the Interface options window, click Start next to eth0 to start the capture (Figure 3). If you use something other than the BackTrack VM to run Wireshark, you might select a different interface. Click on the Capture menu again, and then click Stop to end the capture. When finished, save the capture to a file. I recommend that you take captures of no less than five minutes at random times during the day. The capture files will be big (longer capture = bigger file) if you have a busy network, but in my experience, five minutes is enough for most small-to-medium networks. Scan the capture files to identify unusual traffic, and validate any network-level policies you may have in place. For example, many networked printers, by default, broadcast NetBIOS for discovery on Windows networks, but you may not allow NetBIOS traffic on your network. Captures also can help find rogue-user PCs or VMs running without approval. Many people are surprised the first time they run a capture. The shortcoming of captures is the time required to analyze them. That is where our second network tool, Snort, comes in.
Snort is many things, but traditionally it's used as an intrusion-detection system (IDS). An IDS patterns network traffic against a database of known attack signatures to alert administrators to potential intrusions. Unlike Wireshark, Snort aggregates and analyzes the data it collects providing a thousand-foot view of the network. When using Snort, you should be aware of two things: IDSes are sensitive to false positives, and they do not alert on normal traffic. Snort is useful as an assessment tool, because it can tell you whether there are any major problems on your network in a short amount of time.
The BackTrack team conveniently has packaged Snort with the BASE Web front end in the distribution. From the KDE menu, select Services→Snort→Setup and Initialize Snort. You will be prompted by the setup script to enter root and Snort user passwords for MySQL in order to create the needed tables. At the end of the script, open a Web browser and enter http://youripaddress/base/base_db_setup.ph, and on the page that loads, click on the Create Base AG button. Now, click on the Main Page link (Figure 4) to access alert information. Unlike Wireshark, Snort should be run over a longer period of time (more than 24 hours in most cases) to provide a good sampling of network data.
The third set of locks to test is found in the operating systems and applications on your network or, more specifically, in the vulnerabilities that exist on them. A reasonable approach to finding these vulnerabilities is to perform one or more broad vulnerability scans across the network, followed by any application-specific scans for our critical apps. Let's use the Security Administrator's Integrated Network Tool (SAINT) as our primary scanner.
SAINT normally allows only two IP addresses for scanning for 15 days, but BackTrack users can use up to ten IP addresses for up to a year by using the registration page found under the KDE menu: BackTrack→Vulnerability Identification→SAINT Exploit→SAINT Exploit License. From this Web page, click the Get License button at the bottom of the page and provide the necessary information on the registration page. Proceed with registration, and generate a key for use with the scanner. Once the key has been entered on the VM, launch SAINT from the same KDE folder as the License link, but click on the SAINT link instead. This launches the Web front end. Click the Scan Set-Up tab. Enter the IP addresses or range you want to scan (Figure 5). Under the Scanning Level section, check off Exhaustive and Full Port Scan. In the Firewall section, select No Firewall Support. You can play with any of these options to tailor the scans to your needs. Click Scan Now at the bottom of the page when finished. The results are displayed when the scan is finished (Figure 6). You should review and document the scan results, and wherever possible, remediate discovered vulnerabilities.
This broad scan with SAINT should be followed up with more specific scans against your most valuable (and therefore juicier targets) machines. As an example, let's scan a Web server using another tool found on BackTrack, Nikto. Nikto is a mature, simple scanning tool and an excellent resource for locking down a Web server. Assuming you have a Web server in your environment, launch a Nikto shell from the VM under the KDE menu BackTrack→Penetration→All→Nikto2, and from the resulting shell, type:
nikto.pl -h yourwebserveripaddresshere
As you can see, the output is straightforward and can be redirected to a file easily for later analysis (Figure 7). As with SAINT, you should follow up this scan by documenting the results and fixing any discovered issues.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released