System iNetwork

March 2005

March 31, 2005 11:46 AM

Hot Off the O'Reilly Press: IPv6 Network Administration

IPv6 is coming! IPv6 is coming!

OK, maybe not as fast as we once thought, but it is coming. IPv6 is the replacement for IPv4, which has been running out of address space for a while now, and which has a mess of secrurity flaws that are the main reasons for such vermin as spam and viruses. IPv6 may not get here before you die, but just in case it does, you're well advised to be up to speed on it. And a great way to get up to speed is this new O'Reilly tome by Niall Murphy and David Malone.

There have been a lot of books and articles about IPv6 over the last few years. They all warn (a bit too ambitiously, it turns out) of the impending demise of IPv4, and they all sing the praises of IPv6: enough address space to give every star in the sky a public IP, ironclad security, the end of address spoofing, seamless interplanetary roaming, and Quality of Service up the wazoo. But none of these prior publications ever told you how, exactly, to make the transition to IPv6. This book does exactly that. In fact, its motto is "The chief thing is not to study, but to do."

The book starts out with the obligatory IPv6 background story. You can skim the first chapter if you're already a believer. But then Murphy and Malone do something completely uncalled for: They sing the praises of IPv4. Unlike their Chicken Little predecessors, these authors acknowledge that IPv4's death has been greatly exaggerated. They expound on the amazing resilience of the IPv4 Internet, which has scaled far beyond the protocol's original designers. They tell the tale of life-saving workarounds, such as network address translation and auto configuration, which bought time for us all. And they talk about IPv4's future. Yes, there is one!

In chapter 3 the writers roll up their sleeves and dig into the meat and potatoes of IPv6. This is necessary, if somewhat dry, knowledge, but Murphy and Malone liven up the discussions with wry quotes and footnotes. A classic one on the dangers of underestimating user needs: "As Bill Gates is alleged to have said, '640k should be enough for anybody.'" The authors point out some non-obvious features of IPv6, such as the lack of broadcast addresses -- multicast packets are used to accomplish the same functions more effectively, and more safely. This chapter spares no subject, covering every IPv6 protocol aspect: packet and address formats, header compression, routing, security, QoS, and mobile capabilities.

Once you understand the basics (I had to read Chapter 3 several times to get the hang of it), you're ready to deploy an IPv6 network, right? Wrong. IPv6 is not a seat-of-your-pants endeavor. You must plan your network design carefully, and the authors show you how to do that in Chapter 4. You'll learn how to get IPv6 address space, how to connect to the IPv6 Internet, and what you'll need to do to transition your existing infrastructure to IPv6 without crashing the network. It's sort of like doing brain surgery on yourself. While you're driving on the freeway. During rush hour. The authors provide helpful examples.

In Chapter 5 you finally get to configure something! This discussion explains the nuances of Linux, Macintosh, Unix and Windows configuration, router setup, troubleshooting procedures, and the proverbial Gotchas waiting for the unwary. Only after reading this chapter you'll be wary and wily, and IPv6-qualified.

The remaining chapters cover maintaining and monitoring IPv6 networks, details of how IPv6 effects the most popular IP services, such as HTTP, FTP, and SMTP, and the intricacies of coding IPv6 applications.

No IPv6 book is complete without a prediction of future events. This one is no different, other than that the authors are brutally realistic. They point out, with classic understatement, that IPv6 still has a few loose ends, such as DNS. Then they pontificate on some of the future new applications that IPv6 might spawn. Thankfully, they refrain from putting a date to the IPv4 Apocalypse -- the first pundits I've seen take this high road.

You must own this book. Or get into real estate.

http://www.oreilly.com/catalog/ipv6na/

Posted by mbeckman on March 31, 2005 at 11:46 AM

Unplugging the Enterprise: The Ointment and the Fly

Enterprise IT administrators have their hands full maintaining control of corporate wireless gear, which may go roaming where it shouldn't, exposing sensitive corporate data to prying WiFi sniffers. Even if you employ the gold standard of WiFi security -- a VPN connection back to the ranch -- it's difficult to prevent users from connecting a corporate laptop at the neighborhood Starbucks, resulting in a potentially disasterous security compromise.

Another bane of WiFi administrators is the complexity of making roaming users' online experience equal to their wired one. A big difference for VPN client connections is the difficulty of accessing such network services as printers and file shares, which often expect to attach at login, but which can't because the user isn't on the WiFi network at login.

Fortunately, there is a fix, called Layer Two (2) Tunneling Protocol (L2TP). Also, there is a fly, named password encryption.

Normally a WiFi user must log in with a local computer account before activating a VPN client to gain secure WLAN access. This means maintaining two sets of login credentials, and leaves a window for user mischief between the local login and the VPN login. Worse, since the user isn't on the WLAN at login, startup scripts requiring enterprise LAN connectivity -- for example, those that mount file shares -- will fail. This makes WLAN behavior perplexingly different from the user's wired hookup.

The silver bullet workaround uses an L2TP VPN tunnel that can be initiated at logon time using a Windows network dialer -- the kind you create by going to Network Services and clicking on Add a New Network. L2TP is an extension to the PPP protocol that merges the best features of two other tunneling protocols: PPTP from Microsoft and L2F from Cisco Systems. It employs IPSEC encryption, so it's more secure than PPTP, but being PPP-oriented, it can work like a high-speed modem connection. Hence the L2TP dialer.

The procedure varies depending on the host WLAN VPN appliance you use, but the payoff is the same for all: a user can choose the L2TP VPN dialer right on the login screen. And no VPN client software is required either -- you can set up L2TP on any modern Windows machine right out of the box. Once the dialer is configured, you can lock the user out of the computer except when it's safely VPN'd into the WLAN and joined to the Windows domain.

But what bout that fly I mentioned? It's a subtle, but maddening one. To authenticate L2TP users, your VPN gateway appliance must be configured to pass login requests to a Windows domain controller using the RADIUS protocol. The problem is that passwords in the domain controller are encrypted using Windows' proprietary encryption, which isn't a supported L2TP IPSEC authentication method. So the VPN server must send the password in the clear to the RADIUS server, where Windows will compare it with the one stored in the DC. The problem with that is that Windows' native encryption is one-way by default, so you have to siwtch all WLAN users' Active Directory profiles to two-way encryption. The password the user enters is still encrypted over the VPN tunnel, so no undue WiFi password exposure exists, but there is a hidden glitch waiting to bite everyone when they first roll out L2TP.

Have you seen the fly yet? Here's another hint. If you're like most network admins (such as myself), you'll want to test your brand spanking new L2TP login with a test account that you freshly create. And it will work smashingly, wonderfully well. You'll be slapping yourself on the back over how cool it is to have L2TP working right from login.

Then, just before going home at 4:00 p.m. (a reward for your L2TP cunning), you'll try to enable one of your existing users for L2TP access. You'll switch their Windows profile to use reversible password encryption, and then try to log them in through the WLAN.

And it will fail.

It will fail at 4:30, at 5:30, at 7:30, at 9:30 and at midnight when your spouse calls to tell you not to make noise when you come home. Maybe by dawn the fly will hit you right between the eyes. Or maybe not until Saturday. For me, it was Saturday.

The fly is this: even though you switch a user profile from one-way to reversible password encryption, that doesn't make the password THAT IS ALREADY STORED reversibly encrypted. Think about it. Making the stored password reversibly encrypted would require being able to decrypt the current password and re-encrypt it, but since it's already one-way encrypted, that's impossible. A Catch 22 of the First Order.

To make it work, you must reset the user's password. That's it. That and 37 hours of overtime.

Note to Microsoft: A warning pop-up from Windows when changing a user profile to reversible password encryption would have been helpful here.

Posted by mbeckman on March 31, 2005 at 10:47 AM

March 11, 2005 11:06 AM

Dust.Page.US Spyware Worm spreads, but You Can Block It

A new worm is afoot, tentatively called the dust.page.us worm because it downloads and installs spyware on victim computers from the site of the same name. Blocking traffic to the dust.page.us site appears to stop the virus from successfully infecting new systems. The IP addresses associated with this name are subject to change, however, so some cleverness is required to block access to it.

At this writing, lookup of the dust.page.us domain name yields the following IP addresses:

nslookup dust.page.us
    Name:   dust.page.us
    Address: 24.45.69.153
    Address: 69.56.179.10
    Address: 130.74.201.43
    Address: 158.65.196.156

You could just block these addresses in your router or firewall, but the worm author can easily change or add to the list by simply updating the DNS entry for dust.page.us. A quick fix is to intercept DNS lookups for the name and return a bogus private IP address, such as 192.168.255.254. The exact procedure for doing this varies with DNS server, but it�s not complex. Simply create a zone file for the fully qualified name and give it a single A record with the bogus IP address.

If you use a DNS server supplied by your ISP, you might want to notify them of this problem and suggest they incorporate the block in their DNS. By doing so they'll greatly reduce the spread of the worm.

As an adjunct to this technique, you should log all references to this domain name and IP address; any computer on your network looking it up or probing the address is likely infected with the worm. Virtually all firewalls support blocking and logging by IP address, and many support domain name blocking as well.

Hopefully the operators of the page.us domain will shut down the site soon.

Posted by mbeckman on March 11, 2005 at 11:06 AM

ModSecurity: Open Source Application Firewall

Many successful network penetrations use attacks against Web-based applications: SQL server injection, HTTP path evasion, embedded argument manipulation, and cross-site scripting - to name just a few. The problem is that ordinary network firewalls don't inspect application-layer data, and so can't protect against these attacks. ModSecurity is a nifty open-source application firewall that anyone can deploy at low cost to help protect Apache-based Web servers against common application vulnerabilites.

ModSecurity is a rule-driven security scanner that runs as a plug-in module to Apache. You can run the plug-in directly on your Web server, or set up a separate server running Apache with ModSecurity in reverse-proxy mode. In either case, ModSecurity receives all HTTP requests, filters them, and passes the safety-checked requests on to your application server. ModSecurity also looks at your application server's response to detect possibly successful intrusions. Configured correctly, ModSecurity adds very little overhead to application Web serving.

The rules database lets it detect various attacks, and you configure the actions you want from ModSecurity for each detected violation: report, repair, or reject. The rule syntax is based on the open source Snort IDS; you can enhance the base rule library with custom detection rules of your own devising.

Rules come in two varieties: input and output. Input rules guard against malformed requests and other attacks from the Internet; output rules check HTTP responses to make sure they don't contain sensitive information. The rule set to protect against the most common Web application attacks is surprisingly short: just 15 lines. You'll customize this base set for your specific application language. Currently Java, PHP, and Web Services are supported.

Output rules guard against information leaks by watching for telltale strings such as "Command Completed", "Index of /cgi-bin", and "file(s) copied". Such strings indicate an attack, such as remote command execution, has partially succeeded; output filtering prevents the attacker from reaping the fruits of his attack.

Download ModSecurity today from:
http://www.modsecurity.org

Posted by mbeckman on March 11, 2005 at 10:08 AM

March 1, 2005 10:17 AM

Windows XP SP2: Is It Safe?

According to a Denver Post story today, network security developer StillSecure recently conducted a "honeypot" test, in which it put out-of-the-box computers running Linux, Mac OS X, and Windows XP SP1 and SP2 on unprotected Internet connections to see if they could withstand attack. The short results: over the course of seven days, only Windows XP SP1 succumbed (and it fell in 18 minutes). But the excercise glosses over an important issue with Windows SP2.

In the test, all four computers were connected to the Internet just as they came, out of the box, with the exception of Windows XP SP2, which was allowed to "automatically" install the latest Microsoft security patches. None of the other systems had any patches installed at all. Reportedly the computes sustained 46,255 scans during week-long test. Out of those scans, only a handful of dedicated attacks ocurred: eight for Linux, three for Mac OS X, and sixteen for Windows XP SP2. SP1 died almost immediately, ultimately becoming a remotely-controlled "bot" system doing the bidding of some hacker overlord.

My first reaction to this test is to cry "unfair!" Why was SP2 patched during the test, while Linux and OS X were not? In my opinion, StillSecure's test protocol is hardly cricket. My own tests of SP2 show that when unpatched it falls to infection within an hour. StillSecure seems to have sweetened its honeypot in SP2's favor.

StillSecure reportedly permitted SP2 its patches because it can install them automatically, but that only happens if the user elects automatic updates, and many don't. Mac OS X also has the option to automatically apply patches, and you can purchase Linux distributions with the same feature. All three prompt the user let patches download and install automatically.

Beyond the obvious problem of its test bias, StillSecure's reported results obscures a fact that may be too subtle for non-expert users: a Windows system (or any other,for that matter) can become infected in the time it takes for patches to be downloaded and installed. I've seen it happen many times, leading to my recommendation for the SwatBox to protect a Windows computer during the vulnerable update process (see my December 2004 column at E-ProMag.com).

Unfortunately, a huge number of home- and small-office Windows users connect to the Internet with no firewall protection, and also bypass automatic updates. That Windows XP SP2 still ships in a vulnerable configuration for these users is a huge failure on Microsoft's part. I'm glad that Microsoft is beefing up security, but I'm not happy to see security professionals gilding the lilly.

Posted by mbeckman on March 1, 2005 at 10:17 AM