OpenHack 1: Attacked and Hacked!
OpenHack 1: Attacked and Hacked!
Security is hard.
PC Week Labs didnt need to set up the www.hackpcweek.com interactive security test to prove this statement-its a reality PC Week readers live with every day. But we did need to set up the site to determine how IT managers can most effectively safeguard their companies mission-critical data. The number and scope of the attacks against the site reflect the immense challenge IT faces in securing e-business.
And security will only get harder. Companies are distributing their systems, both geographically and architecturally, and this will lead to complexities as yet unseen for managing security. As Web sites grow, so will companies have to grow their security policies. They must establish in-house expertise for system auditing and make sure that security budgets keep pace with development budgets.
Hacking is a popular sport. Using our intrusion detection software and our firewall logs, we monitored in real time the status of our Web site. What we found was astonishing. A press release announcing that the site was up hit the wire on Sept. 20 at 8:30 a.m. ET. Seven minutes later, we registered the first hack attempts against the site. In total, more than 40,000 people visited the site.
We were subjected to every sort of denial-of-service and spoofing attack, all of which were headed off by the firewall. We were also port-scanned several thousand times.
One of the most interesting attacks was the synchronized assault. This involved simultaneous attacks against our servers that were obviously meant to be highly visible and diversionary, pulling attention away from more nefarious activity.
One of the hardest things about maintaining security is keeping things simple. Both Windows NT and Linux install many unnecessary, nonsecure services by default (think SMTP Message Transfer Agents, Telnet and FTP servers, and news servers). Administrators should strive to keep as little as possible on each server. The fewer windows for opportunity, the better.
The hack that felled www.hackpcweek.com teaches a very important lesson: Security doesnt stop at the operating system.
PC Week Labs went to great lengths to take the same security measures on the Linux and Windows NT servers running the site that any IT manager worth his or her salt would implement. The successful hacker, known as Jfs, bypassed the firewall, the intrusion detection system and a locked-down server to exploit a hole in a CGI script on the Linux server, which was running Red Hat Linux 6.0.
The successful attack against our Linux server was a methodical assailment by a hacker with intimate knowledge of C, PERL and The Home Office-Onlines PhotoAds classified-ad engine application. PhotoAds is publicly available (at www.hoffice.com), as is information on its known security holes and fixes. Companies that dont keep on top of application fixes will be at the mercy of hackers who do.
Also contributing to the hackers success were incomplete security updates on our test site. At the time we began the tests, Red Hat Software Inc. had 21 security updates available for Red Hat 6.0, which had been out for only a couple of months. (PC Week Labs will apply the patches to the Linux server and update the scripts for further testing.) While any operating system needs patches and updates, there is no central repository for testing or approving patches to the Linux system. Kernel patches can be obtained from a verified source such as kernel.org, but most other components have no central infrastructure.
This problem is exacerbated by the distributed nature of todays enterprise and the need to test and verify any patch before it is installed on a mission-critical server. The only option for Linux is to use a utility called autorpm, which polls a server for updates and automatically installs them. But no administrators in their right minds would use this sort of utility because they would have no idea what was being installed on their servers.
: No Code Stone Unturned">
No code stone unturned
All code must be rigorously audited, even simple scripts that run on a Web site. In fact, for sites to be secure, administrators must have intimate knowledge of every application, every API and every part of the network infrastructure.
This comes at a cost that rises quickly relative to presence online. For any site to be considered secure, PC Week Labs estimates that a company must dedicate at least 8 hours per week. Assuming a 40-hour work week (OK, we know thats low-balling the average IT managers week, but we have to figure the math somehow), this equates to at least one person dedicating 20 percent or more of his or her time to Web security. With the base salary of a decent administrator starting at around $65,000, this amounts to a little more than $1,000 per month for a base-package site to remain securely online. For sites with more servers, more software and more connections to the Internet, the costs rise quickly.
The hackpcweek.com site also showed us that some simple security measures, such as complex passwords, are great in theory but nearly impossible in practice. The hackpcweek site comprised six servers. Imagine how difficult it was to remember passwords such as [Athl!g. We couldnt and had to rely on a list of log-ins and passwords stored on a laptop. If this laptop had been compromised, our entire site would have been vulnerable.
After going through these tests, we cannot understate the importance of a good firewall. We used Axent Technologies Inc.s Raptor firewall and blocked every port except Port 80 for regular HTTP traffic. This configuration is about as simple-and safe-as it can get.
Proxying firewalls require more processing power than stateful inspection firewalls. The Raptor firewall provides a circuit-level proxy. We chose this because it terminates both ends of a connection and acts as an arbitrator. A stateful inspection firewall, in contrast, is basically souped-up packet filtering.
Administrators must also be sure to dedicate enough horsepower to their firewalls. We installed the Raptor firewall on a Hewlett-Packard Co. LPR server with two Pentium IIs running at 450MHz. This level of horsepower is necessary because every session going in and out of the servers has to be monitored. This is not an area where you want to skimp.
Opening new doors
Many companies are outsourcing portions of their Web development, which presents the need for administrators to audit code produced by third parties. Companies should make technology transfer a major part of any outsourcing agreement and should add in extra time to train internal staff on the new code. The concept of open source adds a new twist to the problem of security. While having access to source code should make code more secure through peer review, this is not always the case. Often, security holes can be the result of specific configuration options, not necessarily bad code.
The bottom line is daunting: Dont let your guard down--ever.