To combat worms and spam, I arranged for the implementation of two email products: Microsoft Exchange Server 2003 and NetIQ MailMarshal SMTP. Moving to Exchange 2003 was more than merely a security decision. The most important byproduct for UtahWISP was the tight Windows Server integration that let the company create one account for each customer, who would use the same account for Web services, disk storage, and email. Other important features were reliability, performance, and scalability. One feature that was particularly important to UtahWISP was the ability to provide Web-based email functionality through Outlook Web Access (OWA).
With Exchange in place, I worked on installing NetIQ's MailMarshal. MailMarshal is an email-content security product that can either integrate directly with Exchange or operate as a separate SMTP gateway. I chose to use the SMTP version because I wanted to keep the gateway separate from Exchange and because UtahWISP had no particular need for the integration features. Although MailMarshal would probably be more appropriate in a corporate environment, in which management can more closely enforce policies, I had to configure it to be a little more conservative for a WISP by blocking only those email messages that clearly contained viruses and by blocking only the most obvious spam. Nonetheless, shortly after installation, I witnessed a nearly 30 percent reduction in email volume making it to the Exchange server. Every piece of spam that doesn't get past the gateway and every blocked virus reduces the number of packets traversing the wireless portion of the network.
So far, I had successfully limited many unnecessary packets on the network. Although the difference was significant, it still wasn't enough. Watching the NetCrunch network map, I still saw occasional ping timeouts across the network.
Managing network resources. The next step was to control the actual traffic traversing the network. Rather than install a firewall and completely block certain types of traffic, I chose instead to throttle this traffic. For that purpose, I chose Packeteer's PacketShaper 6500, a network traffic shaper that lets you set rules that give high priority to certain types of traffic and limit the bit rate of other types of traffic. For example, I could give Web browsing high priority but limit P2P traffic to dialup-comparable speeds. Furthermore, UtahWISP's customers had service plans that allowed for certain levels of bandwidth. Up to now, the company had enforced those limitations via the wireless APs, but with PacketShaper, UtahWISP could more accurately control bandwidth for each user and report on actual usage.
I let the PacketShaper device collect statistics for a few hours, then looked at some of the charts. I knew UtahWISP experienced a lot of P2P traffic, but I had no idea how much until I actually saw it charted. In fact, the P2P bandwidth was so great that on the chart it dwarfed all other traffic combined. Furthermore, I was surprised to see just a few users taking up a large majority of the bandwidth. Some users had five or more P2P applications running at once. Having a birds-eye view of the network was extremely helpful in determining where to go next. I set limitations on all P2P traffic and gave protocols such as HTTP and DNS high priority on the network. Finally, I put all customers in separate service classes based on the service plan they had purchased.
After setting all the rules, I enabled packet shaping and immediately saw an astonishing reduction in network traffic, as the PacketShaper chart in Figure 3 shows. With the P2P traffic out of the way, I could now identify other network problems that the P2P traffic previously dwarfed. For example, I noticed one customer with an unusually large number of outgoing email messages—indicative of a spammer or, more likely, a virus infection. UtahWISP's technical support personnel contacted the customer to help eliminate the problem.
The DMZ and Server Hardware
Although the initial problem was solved, I decided to go one step further by examining UtahWISP's demilitarized zone (DMZ). A DMZ is a special network segment isolated from both the Internet and the internal network. I was surprised to find that the company didn't have a DMZ and instead placed all critical servers and all office PCs on the same network that its customers used. If Utah-WISP's servers were ever compromised, they could serve as excellent launching points for other attacks within the network. To build a DMZ, I implemented the Network Engines NS6300 ISA Server appliance.
The Network Engines appliance is a server with Windows 2003 and ISA Server 2004 pre-installed—everything was installed, hardened, and ready for basic configuration. I soon had a fully operational DMZ that was completely isolated from the rest of the network. I decided to create another isolated network for all office PCs. The appliance had six network ports on the front: one for the outside connection, one for appliance management, and four more for creating isolated networks.
With UtahWISP's DMZ servers now secure behind a firewall, I examined the servers themselves. The hardware was sufficient for the company's needs, but I knew that Web server performance would improve drastically if I upgraded the existing 256MB of RAM to 4GB, so I installed eight 512MB Micron Technologies modules to upgrade the critical servers. Although I didn't perform official before-and-after speed tests, I definitely noticed an overall speed improvement after the RAM upgrade.
The Server Rack
My goal was a complete network makeover, so I looked at UtahWISP's cluttered server rack. To manage its various servers, Utah-WISP had an unkempt row of monitors, keyboards, and mouse devices next to the server rack. Throughout the rather frustrating upgrade process, I would frequently grab the wrong mouse or type on the wrong keyboard. Furthermore, standing at the server bench for extended periods was uncomfortable.
The solution to this problem was a Belkin OmniView 16-port KVM switch with 25' cables. Belkin uses a cable design that combines keyboard, mouse, and video for two servers on one cable. This design let me easily connect all the company's servers to the KVM switch and control everything from a single, comfortable desk location nearby.
From Belkin, I also acquired an Omni-Guard 3200VA rackmount UPS to replace the four older UPS systems currently in place. This one UPS provided as much power capacity as the old systems, using about 25 percent of the space. Colored network cables let me easily distinguish different network segments.
The Final Meeting
After weeks of working on the network, I sat down with UtahWISP's administrators for a final meeting to review the upgrade. The network administrator told me that network speeds had improved by as much as 50 percent, and customers who had been experiencing the most problems had noticed even greater improvements. Furthermore, with the new components in place, the network administrator was better able to track down specific problems. The network makeover was complete, and the customer was satisfied.
See Associated Image
See Associated Image
Mark Burnett (mburnett@xato.net) is an independent security consultant and author who specializes in Windows security. He is an IIS MVP and the author of Perfect Passwords and Hacking the Code (Syngress).
Register
