Test Drive: GFI LanGuard 2014 LanGuard worked well in the lab and may prove more beneficial to IT operations than security teams.
[One in an occasional series of IT security product reviews by John Sawyer, a security professional who has worked both as a penetration tester at InGuardians and as a member of the security team in a large enterprise.]
Vulnerability scanners are nothing new. They've been used for years as a part of the security team's toolset for identifying network security issues, by operations to validate patch management, and leveraged by auditors performing compliance audits. Scanners look for outdated software, known vulnerabilities, and misconfigurations so that companies can clean up the low hanging fruit that is easily exploitable by attackers.
I've used quite a few different vulnerability scanners since I first started working as a systems administrator in the late '90s and then transitioned in to security in 2002. Some of them no longer exist, while others have changed owners, gone from open-source to closed-source, or sprung up as new products.
When GFI contacted me about taking a look at its LanGuard 2014 vulnerability scanner, I was immediately interested. For one, I'm a sucker for trying out new tools and products. If it's something that might make my life easier as a penetration tester and security researcher, then I want to take it for test drive to see if it lives up to the hype. Secondly, I'm constantly being asked what tools I would use if I were in someone else's shoes -- and I wouldn't dare make a recommendation for something that I haven't used myself or heard good things about from someone I trust.
Quick and easy install
Since I'm notorious for jumping right in without reading the documentation, I spun up a Window Server 2008 R2 instance, downloaded the installer, and launched it. The install was quick and easy with the only real decision being whether or not I wanted to use a Microsoft Access or SQL Server for the database backend. I opted for the Access database because I only planned to interact with around a dozen endpoints and didn't need the additional performance provided by MS SQL Server.
After the installation, I opened up the LanGuard 2014 interface and it recommended that the local Windows server be scanned. The dashboard began to display the server's current health status after a few minutes and indicated there were a couple of missing patches and configuration issues. Before getting too deep into the scan details, it's worth mentioning that the LanGuard interface is a Windows application. This distinction may be important for some. The scanners that I use on a regular basis use a web interface. Personally, I don't have much of a preference of one interface over the other, as long as they do their job well presenting the information and options I need while still being responsive while in the middle of large scans.
It wasn't until after I'd scanned the local server and started looking at the missing updates that I realized that LanGuard included remediation capabilities -- something that's definitely not in the vulnerability scanners I'm used to. At this point, I started digging into the documentation to see what other fun could be had... uninstalling unwanted software, pushing custom software packages, mobile device scanning, and a few more things that sounded interesting. I quickly pushed the missing patches to my server, rebooted it when the prompt came, and then began scanning other systems in my lab in order to try out the new features I'd just read up on.
I installed the LanGuard agent on a couple of Windows systems to see if there was much of a difference between agent-based scans and agentless ones. Other than the fact that agents are supported only on Windows and other systems (Linux, OSX, mobile devices) require agentless scans, there wasn't a difference in results. However, this was across only a few systems compared to a large corporate network. When scanning hundreds or thousands of systems, agents would certainly be a requirement because they can perform scanning independently of the server and report back their findings as scheduled.
A quick scan of various systems turned up results that allowed me to test out some of the features I'd found in the documentation. The first was uninstalling unwanted software. Nmap seemed like a good target for automated uninstallation since it was on a few different systems. Following the documentation, it took about four steps and less than five minutes to configure Nmap as unwanted, validate that it could be uninstalled automatically on one system, and start a scan on my other systems. Of course, the software I
1 of 2