We’ve already talked a bit about the Windows NT domain authentication strategy and some dangers of the Web. Now we mention a few points about working in a broad networking environment. Windows NT does not encrypt its networking traffic for confidentiality (hiding the date from prying eyes) or integrity (assuring you can detect when data has been maliciously modified in transit). This again is left to third party suppliers. Microsoft does assure confidentiality for its Remote Access Services (RAS) including when RAS traffic is carried by an intranet via the PPTP protocol. And U.S. citizens you can now get industrial-grade 128-bit encryption rather than the otherwise marginal 40-bit keys limited by U.S. export regulations. While I have always been suspicious of RAS’s key exchange algorithms, I’m willing to take them at face value. It is at least theoretically possible to "hijack a session" on an Windows NT network. When the server establishes the remote session we described early in this article, it initially authenticates the user based on name and password. The system never sends the password across the network but instead uses a classic challenge-response technique. Once authenticated, the server sends an unprotected tag to the client and serves subsequent requests based on the presentation of that flag. An eavesdropper can easily read the tag and submit its own requests. While this is not an easy task, the only major barrier is that it gets into the arcane details of the networking protocols which are not widely available. However, this protection is classic "security by obscurity" which is little security at all. Is this a security flaw? Not in my book. A security flaw is when a vendor promises one thing and delivers something weaker. Microsoft makes no pretense that its networks protect against these kinds of attacks. It does mean however that you should look to various add-on products if you deem this a threat to your site. If you are connecting your network to an intranet or (gulp!) the Internet, you simply must do it through a firewall. Pick your favorite brand. The best of the bunch have application proxies that are quite smart about monitoring and screening certain kinds of intranet protocols. We use the Microsoft Proxy Server at our site, but there are many effective firewalls on the market. Windows NT’s own native network sharing services, including file and printer sharing, and named pipes (which support many forms of RPC), can be easily and reasonably well isolated from an intranet to which your LAN is attached. First, you can bind these services to the NetBEUI protocol only, rather that NetBIOS-over-TCP/IP. Since NetBEUI protocol cannot pass out onto or in from a TCP/IP network, no outside agent can attempt to gain direct access to these services. Even if you choose to use NetBIOS-over-TCP/IP, this protocol scheme used UDP and TCP port numbers 137 through 139. If you configure your intranet gateways and routers to block these ports in both directions, you isolate these native NT services from the intranet. Of course, with either scheme your Windows NT systems cannot serve requests from the intranet. If you need to do so, encrypting protocols are your only effective protection
|
|
|
|
|
|
|
|