Skilled hackers perform target reconnaissance before an attack, identifying target machines, collecting service banner information, OS type, application versions and other valuable data. In theory, if you can detect recon activity and reply with bogus responses, you can then later block any traffic destined for a bogus target.
That's the idea behind ActiveScout, the first offering by startup security vendor ForeScout Technologies. ActiveScout basically inserts an ink dye into response traffic to mark suspicious traffic. It monitors traffic for suspicious requests, and replies to them with bogus information about what hosts and services are available. Should ActiveScout see that bogus data reappear in another connection attempt, it can block the attack and alert admins for further action.
ActiveScout has two primary components: The Scout sensor and the GUI-based management console. An optional management server allows enterprises to aggregate and control multiple Scouts. ForeScout also offers an add-on "Enterprise Heads-Up" module, which disseminates attack intelligence to all Scouts on a network, instructing them to block specific traffic even if they haven't seen recon activity.
The Scout sits immediately outside the firewall and sniffs all traffic. It monitors and "learns" what hosts and services are running behind the firewall. Traffic destined for a nonexistent host or port, such as a ping sweep or port scan, is seen as possible recon traffic. The Scout tags recon traffic with an identifier called a "Mark," which is a bogus user, host or port data. Traffic, regardless of its IP source, destined for a particular Mark is called a "Bite," and triggers an e-mail alert.
The Scout can monitor and alert admins of malicious activity, or it can respond automatically. By injecting a TCP reset onto the wire or by using the OPSEC interface to add a rule to Check Point's FireWall-1, ActiveScout can block a detected attack without admin intervention. Only FW-1 is supported out of the box, but ForeScout supplies an API for integrating ActiveScout with other firewalls. For organizations that don't use FW-1 and choose not to integrate ActiveScout with their firewall, ActiveScout will only be able to do TCP resets and will not be able to block UDP and ICMP traffic.
For enterprises uncomfortable with automated responses, ActiveScout will kick off an alert to an admin, who can manually drop and block the connection.
ActiveScout comes on a single bootable CD-ROM that contains both the Scout sensor software and the management GUI interface. Scouts run on a hardened, customized version of Red Hat Linux 7.2, which is also included.
Once the initial OS and software installation is completed, ActiveScout will walk admins through a series of questions to do the basic configuration. This initial installation gets the Scout up and running even before the management console is installed, though all configuration settings can be modified through the management console later.
The Scout is a full Linux system, so console and SSH access are available for looking under the covers. There's even a command-line tool called "fstool" that allows configuration of Scout functions. But the GUI allows configuration of everything, so you'll never have to log directly into the Scout.
The GUI-based management console can be installed on any off-the-shelf box running Windows, Linux or Solaris. The wizards made installation of the console on a Windows machine a snap. It requires little configuration beyond the initial setup.
The ActiveScout management console is impressive. The main screen is a map of the world, which displays in near real time the geographic location of the sources of scans and Bites. Admins can drill down on suspicious traffic to get lots of details, including the full packet payload.
In addition to configuration and alerts, the GUI provides an audit trail for administrative tasks, and a variety of built-in and customizable reports. The reports may be exported in various formats, including CSV and PDF. And there are many bar charts to show to management, such as "Scan Type Statistics" and "Bite Events Over Time."
ActiveScout correctly handled everything I threw at it. The system correctly marked Nessus scans and triggered e-mail alerts when traffic with Bites hit the test target. This is particularly interesting, since this kind of scan is similar to what happens when some automated tools scan a subnet for servers/services to exploit.
The Scout reported no false positives, such as incorrectly reporting legitimate traffic as malicious. As expected, though, it didn't report attacks to legitimate hosts and ports, or "low and slow" attacks that had no prior recon. Some may see this as a major problem, but ActiveScout isn't designed to detect these kind of attacks. Fast and noisy attacks against legitimate hosts and ports (a la Nessus) were detected.
Source address spoofing has little effect in bypassing ActiveScout, since its actions are based on the bogus information provided to the attacker and not tied to a particular IP source. Keep in mind that legitimate intelligence is returned along with the Marks, meaning that there's a slim chance that the attacker will get lucky and only attack real hosts and services.
By default, ActiveScout will only block malicious activity, as identified by a returning Mark, for four hours. The HoneyNet Project concludes that recons precede most major attacks by roughly three days. Thus, it may be worth considering increasing ActiveScout's default timeout (four hours) for reorganizing tagged malicious activity.
Like any point solution, ActiveScout doesn't stand on its own. It doesn't replace firewalls, IDSes or well-thought-out security designs. However, it may help reduce IDS alerts and false positives, since it blocks recon traffic and some attacks outside the firewall.
ActiveScout does well in detecting attacks that were telegraphed by reconnaissance activity, and it's intended to guard against known and unknown attacks by skilled, methodical hackers--who are more dangerous than worms and script-kiddies.
Just how many attacks occur without recon isn't clear. Some say it's less than 5 percent of all malicious activity, but The HoneyNet Project is finding a trend toward automated attacks with little or no traditional recon.
The blind "find it and immediately attack it" approach of newer automated tools means there's virtually no recon or warning before a strike, giving them the ability to sidestep ActiveScout. On the other hand, it's their nature to scan vast numbers of hosts and ports very quickly, so the odds are that they will probe nonexistent hosts and services that will trigger ActiveScout to create a Mark.
It may sound like there isn't a lot to this product. In a way that's true, but that's also a good thing. It's well known that complexity is the enemy of security, so any product that can add a layer of security in a very simple way, with virtually no administrative overhead, is worth a look. ActiveScout won't solve an enterprise's security ills, but it may more than pay for itself by blocking just one serious attack.