FireBlock thwarts inside threats before they hit

Imagine having an employee whose only job is to monitor the secure servers and directories behind your firewall and immediately thwart any attempt to access them. Well, swap “device” for “employee” and shake hands with a new kind of security appliance that can significantly reduce your exposure to the risk of internal users accessing unauthorized resources–one of the hardest security problems to guard against.

Palisade Systems’ FireBlock is the only product I’ve seen that can actually stop unauthorized connections as they’re attempted. The device sits wherever you want it on a network segment; next to a firewall or in front of a server farm are good choices. Each device includes two network adapters. With one adapter, the device passively examines packets’ source and destination addresses and TCP ports. When it sees a connection from or to a destination and port that you have not previously authorized, it sends a reset packet out via the other adapter to the client or device that originates a connection, forcing the connection to drop. Palisade owns a patent for its unique technique of passive network traffic blocking.

Lots of network monitoring applications can passively monitor and log packets. The problem with these other monitoring products is that gleaning valuable information from the logs they produce is like trying to find a politician with scruples. Even worse, once you’ve learned what you need to, you then have to know what action to take to prevent future intrusions–if the damage has not already been done. FireBlock disconnects intrusion attempts in real time.

Palisade also offers an appliance called SmokeDetector that acts as a decoy to attract attacks. It can emulate the IP responses of eight different operating systems, and you can set a single appliance to mimic as many as 19 hardware configurations. Because there’s no legitimate reason to access a SmokeDetector, any attempt to access it indicates at worst an attack, at best an overly curious user. The device logs all attempted accesses and sends alerts to administrators.

Both FireBlock and SmokeDetector are managed by Palisade’s FireMarshal software. FireMarshal queries a domain controller to get the local TCP/IP addresses. Using a graphical interface, you use the addresses to set rules for FireBlock. You can group addresses into what Palisade calls enclaves, so you can manage by address or by group. FireMarshal can control multiple FireBlocks and SmokeDetectors.

While Palisade’s products are a quantum leap in capability for protecting internal resources, they’re still at an early stage of development, but the company knows where it needs to improve. For instance, FireMarshal’s rules assume you’re using static IP addresses. If you use DHCP to assign internal IP addresses, you need to create rules based on ranges of IP addresses, and make sure your DHCP server assigns addresses using the same range assumptions. Future versions will take DHCP into account. They’ll also be able to interface with LDAP servers to take directory information into account when creating rules.

A firewall can’t do what FireBlock does. It can limit access to segments of your network, but it doesn’t have the fine-grained control to limit access to specific resources to just certain IP addresses using specified ports. While a firewall does passive monitoring and blocking, FireBlock does passive monitoring and active blocking. Even intrusion detection software can only notify you of trouble.

Securing resources from improper internal access is a common headache for IT departments. FireBlock may be the cure.

IPv6–what’s in it, and what’s in it for you

While you probably know that the IETF drafted an IPv6 specification for the next generation of the Internet Protocol, you may not be familiar with its specifics–or why it’s important to enterprises.

IPv6 increases IP address space to 128 bits, thus increasing the pool of addresses from IPv4′s 2^32 to 2^128, or 340,282,366,920,938,463,463,374,607,431,768,211,456–a high number commonly referred to as “plenty.” IPv6 also simplifies IP headers to improve packet handling. Even though IPv6 addresses are four times longer than IPv4′s 32-bit addresses, IPv6 packet headers are only twice the size of IPv4′s.

Throughput is always an issue where network traffic is concerned. Network pipes are more likely to become clogged as traffic from more devices traverses them. IPv6 adds quality-of-service (QoS) capabilities, so senders can request, and devices can apply, special handling to different kinds of traffic. That’s something bandwidth management devices like Packeteer’s PacketShaper can do today by deducing traffic characteristics from packet headers. Making QoS information explicit will help routers process packets more quickly, making it easier, for example, to give real-time multimedia higher than default QoS, while simple file transfers might get lower.

IPv6 also includes provisions for extensions, which are optional header elements within each packet, placed between the transport layer header and the IP header. Routers along a packet’s path can ignore extension headers, making them an efficient way to add capabilities relevant only at a packet’s destination. The current IPv6 spec defines extensions for extended routing, meaning you can specify an explicit route from source to destination; fragmentation, which lets destination routers reassemble fragmented packets more easily; authentication, to ensure a packet has not been altered while in transit; and encapsulation (data privacy), among others.

Those are the major differences between IPv4 and IPv6 packets, in a nutshell. Read Robert M. Hinden’s paper or Adrian Estala’s Web page for additional information about the IPv6 spec.

You don’t need to worry about converting your network to IPv6 this year. But Gartner predicts that vendors will have related products widely available in the 2005-2008 timeframe. What can you do until then? Plan for IPv6 by trying to purchase networking hardware whose firmware will be capable of being upgraded to the new protocol, if it’s not already. That may not be necessary, given the far horizon for widespread IPv6 implementation and the average effective life of networking hardware, but it pays to be prudent. Microsoft expects to support IPv6 in its XP client and .Net Server protocol stacks in upcoming releases; a developer-oriented version of IPv6 is available for XP today. Similar projects are underway for Linux and other operating systems. You can keep up with IPv6 developments at hs247.com.

Some vendors have already taken IPv6 action. Last year, Cisco Systems added support for IPv6 to version 12.2(1)T of its IOS software. Microsoft just gave IPv6 a boost by urging attendees at its WinHEC conference to “build native support for IPv6 in every application [and] piece of hardware.” Other hardware and software vendors are working on their own implementations. A Next Generation Transition Working Group is working to assist the industry with the transition from IPv4 to IPv6.

You can already get your own IPv6 addresses from the American Registry for Internet Numbers if you can prove you need them. But don’t feel you have to hurry–we’re not about to run out of addresses. There are many times more addresses available than the total number of humans who ever lived, or the number of square inches of Earth’s surface. Or, in technical terms, plenty.

Fatter isn’t fitter

I recently talked about how blade servers are the next step in the growing trend toward server consolidation. There’s another trend afoot that extends consolidation out to the desktop: thin-client computing.

Thin clients–stripped-down hardware devices that lack local storage and load their operating systems and applications from a server–work for organizations that want absolute control over their client environments and enhanced security and manageability. They’re also a good choice for environments that don’t demand much variety in software, such as order entry or point-of-sale terminals. Now they may be poised to make a move into a wider circle of office applications.

In thin-client shops, all the software maintenance occurs on the server side. That makes a thin-client environment especially easy to recover in the event of a catastrophe–assuming, of course, that you store your backup media offsite. No vital documents are stored unprotected on the thin-client devices.

Leading players in the space include Wyse Winterm, TeleVideo TeleClient, IBM NetVista, Maxspeed MaxStation, NCD NC-900, and ThinSTAR (which Neoware Systems just acquired from NCD). The clients work with server-side software, typically Windows 2000 Terminal Services or Citrix Metaframe XP in Windows-centric networks.

Despite a higher price tag to get into the game, thin-client computing should lower your total cost of ownership over time. In fact, Gartner Group estimates that over five years a thin client will cost $12,700 less in support and maintenance than an unmanaged PC. Though fat clients appear to be a more fiscally responsible choice at first glance, thin clients will save you more money in the long run. For example, compare IBM’s NetVista N2200, which retails for $579 without a monitor or hard drive and with a 233MHz National Semiconductor Geode GXLV processor, to Dell’s SmartStep 150D, with a 1.2GHz Celeron processor, 128MB of RAM, 20GB hard drive, and 17-inch monitor, for $609. Then bear in mind you need extra server-side software to make the thin client work, to the tune of $100 to $300 (give or take) per user.

But consider what you gain by giving up the hard drive and local applications. Thin clients demand less in the way of maintenance. Once you set up the hardware, you should never have to touch it again; there’s no hard drive, fan, or other moving part that can fail. Client software management issues go away–though nowadays you can minimize client software headaches even on standard PCs by locking down desktop configurations using central policy management software and employing automated software distribution for updates. Security is also improved–the devices don’t include diskette drives or other writable removable media.

Of course, there are obvious drawbacks to thin clients. For one thing, thin clients demand more powerful servers, or a greater number of them, and tend to generate more network traffic. Thin-client computing is clearly not advisable for users running a lot of processor-intensive applications on their clients. However, it’s perfectly feasible to buy those users a few Pentium 4s and give thin clients to the rest of the organization. The same server that hosts the thin clients can manage the fat ones as well.

But I think we’re on the cusp of a change. Until recently, neither thin-client hardware nor server-side software were mature or powerful enough to handle the range of applications running in many organizations. That’s changing. In addition, many organizations now use switched Fast Ethernet, diminishing the network traffic congestion problems thin clients used to cause. If thin client vendors can meet customers halfway by lowering their prices to the level of the major computer vendors’ low-end machines, they may make up the lost revenue in greater unit volume.

For one, Sun’s thin-client push seems determined to knock the PC off its perch. Sun is working to make its Sun Ray thin clients work over busy networks or slower connections, such as DSL which could be used for remote client access. To make that possible, Sun is testing software that compresses data according to its type to reduce bandwidth requirements. However, the technology requires more processing power in the thin client for decompressing the data.

If you haven’t at least tried Windows Terminal Services or Metaframe, you should consider doing so before your next scheduled replacement of a large portion of your current clients. If you’ve been running thin clients, I’d like to hear your thoughts on the pros and cons.