How we tested antimalware gateways

We primarily looked for the ability to identify and block malware (such as keystroke loggers, browser hijackers, bots, adware, rootkits, dialers, data miners and trojans). The ability to correctly recognize and thwart phishing attempts was also important. We established a variety of corporate policies regarding Internet access, and we expected the gateway products would enforce them.

We wanted the gateways to prevent malware from sending data from our network (such as "phoning home"), identify already-infected clients, scan traffic quickly, receive frequent malware definition updates (or get quick responses from "just-in-time" queries of the vendor's malware signature database) and produce helpful reports on infection attempts and traffic statistics.We collected a suite of 100 malware samples, and we moved the collected material to an isolated, quarantined network. We thus were able to simulate the Internet within our lab.

The quarantined network consisted of three subnets:• Subnet 1 had 25 client machines with a variety of operating systems, including Windows 2003, XP and Vista as well as Red Hat Linux and Macintosh OS X.• Subnet 2 contained Web servers (Microsoft IE, and Apache), three e-mail servers (Exchange, Notes and Sendmail), a file server (Windows 2003 Server) and two database servers (Oracle 8i and Microsoft SQL Server).• Subnet 3, simulating the "Internet," had Web servers and clients that contained the malware instances and which sported "bad guy" IP addresses and URLs. Systems on the first two subnets accessed the third subnet as if it were the real Internet. We configured the routers and DNS entries to reflect the actual IP addresses and URLs from which the malware was obtained.

The quarantine wasn't absolute, however. A dark, ominous cloud (the Internet) threatened our "Phish Phry" outing – i.e., we had to configure our firewall to allow some of these gateway products to access the real Internet for their "just-in-time" queries of vendor malware databases. The test bed was otherwise perfectly insulated from the outside world.

To measure performance, we used two time-synchronized protocol analyzers on the Internet and local network sides of the Internet connection and examined the resulting packet captures to know the time taken by the appliance to forward or discard each network message.

The gateway products connected our simulated "Internet" to the other two subnets. Client and server machines started off in a pristine state for each test.

Our clients and servers attempted to download malware from the simulated "Internet." We noted how well the products identified malware traffic and blocked attempts by the malware to send data back to the source. We gauged success or failure by examining each machine for malware after each test. We looked for running malware processes, new program files (EXE, DLL or OCX, possibly marked with the "Hidden" attribute) and directories as well as Registry and Start Menu changes.

Return to main test.

This story, "How we tested antimalware gateways" was originally published by Network World.


Copyright © 2009 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon