Arxceo’s tiny IPS works well, but needs management wares

Arxceo’s tiny IPS works for the SOHO, but is low on enterprise manageability

Arxceo’s newest intrusion-prevention system looks more like an MP3 player than an IPS. The 5.5-by-1.5-by-1-inch Ally IP100 is the very little brother of the full-size Ally IP1000 security appliance that boasts a fairly impressive feature set, including signature-based deep packet inspection/payload inspection, DNS protocol enforcement and dynamic blacklisting of malicious attacks, to name just a few.

How we did it

Archive of Network World tests

Subscribe to the Network Product Test Results newsletter

The company has positioned the Ally IP100 for the small office/home office (SOHO) market, but company officials say it would also be well suited for an enterprise-branch deployment. In this Clear Choice Test, we found that while it has a host of useful security features, it lacks the necessary manageability features to be widely deployed across an enterprise network.

Installing the Ally IP100 is straightforward but requires that you power off all the devices to be connected to it. The Ally IP100 has only two ports, which are clearly labeled for LAN and WAN/Internet connections. After you’ve connected to your network and powered it up, browsing to a URL specified in the instructions provides Web access (internal only) to the device so that you can configure it. For the majority of this test, we retained the stock configuration, making changes only as needed to accommodate the network.

Our two test environments can be divided into active and passive networks (see “How we did it”). Active means that services were being offered to systems on the Internet as there would be in a branch-office situation. Passive refers to a network that provides only outbound access to the Internet, such as a telecommuter working from his residence. Our tests revealed that the Ally IP100 was far better suited to a passive environment than an active one.

Trying to implement the Ally IP100 in a network where different servers offer services to external users got complicated very quickly. While the Ally IP100 does offer an impressive list of IPS features, it doesn’t let you segregate those features by host machine. This limits your ability to configure the Ally IP100 to protect different systems with different requirements.

The Ally IP100 considers any traffic it deems unknown as Unavailable Destination traffic, and any source IP address is immediately added to the Unavailable Destination Blacklist. For example, to avoid unnecessary traffic from automated worms, we intentionally ran our production Secure Shell server on a different port (1234) than the standard SSH port (22).

Immediately after installing the Ally IP100, we could no longer connect to the server via SSH. When we checked the Ally IP100 log, our remote client had been added to a blacklist, and all subsequent traffic dropped. Because the Ally IP100 doesn’t know what service uses Port 1234, it assumes the traffic is malicious and implements a rule to disallow subsequent traffic from the originating IP.

The preferable solution would be to add an entry into the Unavailable Destination Whitelist. This creates an “allow” rule for traffic destined to a non-standard port. Unfortunately, the firmware revision we first tested had a bug, which would not let entries be entered properly into this whitelist. This forced us to implement the less-preferable solution of running the server on the standard port, until the new firmware was received and installed. It is interesting to note that while the SSH server was running on Port 22, an SSH denial-of-service worm was able to bypass the Ally IP100 and put the server in an unusable state. Once the new firmware was installed, and the whitelist modified, the server was restarted on the non-standard port and ran trouble-free for the remainder of the test.

Our testing showed that the Ally IP100 performed much better in the passive environment. Because there were no services offered, the product can be more aggressive in classifying inbound packets as malicious and as a dynamic blacklister, the Ally IP100 does a fair job.

Usage issues arise when either there are valid inbound packets and/or there are multiple protected hosts each with different requirements.

The Ally IP100 is not IP addressable, which prevents active targeting of the device. The signature-based deep packet inspection/payload inspection feature seems counterproductive in that it doesn’t use signatures that a user can verify and/or modify, nor does it receive updates. Also, as mentioned previously, the worm-propagation feature doesn’t stop everything.

The inability to discriminate between hosts with different requirements, a lack of a centralized management console and the quirky requirement of powering down connected equipment prevent this device from being a true enterprise player. Further, a relatively limited policy implementation won’t give an administrator the freedom to tailor the configuration to anything but the simplest of environments. That said, there are some enterprise-worthy features, such as Syslog and SNMP event capability. A dedicated event interface would be nice, but the ability to integrate easily into an existing security information-management infrastructure is a big plus.

Stover is an independent consultant with more than 10 years network and security experience. He can be reached at sam.stover@gmail.com.

Stover is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.