Ask Us About... Security, September 2000

By Joel Scambray

One of the most encouraging developments in software over the last few years is the growing promotion of security to first-class feature status. Microsoft Windows® 2000 is at the forefront of this trend, embedding standards-based security technologies such as Kerberos, IPSec, and SSL (TLS) into the core product. This month we begin a discussion of these core features about which readers have expressed the most interest in the AUAS mailbox, as well as some third-party add-ons that can be used to make networked Windows systems more secure.

Using IPSec filters

Q: I know I am being hacked. A person connects to my server on a specific port. I feel so helpless. Is there a way to block the access to a specific TCP/UDP port?

A: Why not block access to all ports instead of just one? On Windows 95/98, you will have to rely on a third-party tool like Black Ice or Zone Alarm. Protection features are built in to the operating system on Windows NT, and Windows 2000 provides even more ways to keep out nosy neighbors.

NT allows specific TCP/IP filters to be configured via the network Control Panel | Protocols | TCP/IP Protocol properties | Advanced| | Enable Security, Configure. Be aware that this will severely restrict Internet browsing and other client-oriented activities on this computer, since it will even block legitimate reply packets from remote servers. Also, the TCP/IP filters don't block ICMP very well, and they require a reboot to enable (or if any changes are made). Both Black Ice and Zone Alarm are much better on NT Workstations or Win 2000 Professional.

Windows 2000 maintains the TCP/IP filtering functionality, but also provides a new way to block access to ports: IPSec filters. Most people consider IPSec purely for its communications features, and don't take advantage of the access control-related capabilities of the Win 2000 IPSec implementation..

On Win 2000, creating IPSec filters can be done using the Administrative Tools | Local Security Policy applet (secpol.msc). In the GUI, right-click on "IPSec Policies on Local Machine" node in the left pane, and then select "Manage IP filter lists and filter actions."

I actually prefer to use the ipsecpol.exe command-line utility for managing IPSec filters. It facilitates scripting, and I think it's easier to use than the many-faceted graphical IPSec policy management utility. Ipsecpole.exe is available through the Windows 2000 Resource Kit and within the Windows 2000 Internet Server Security Configuration Tool. The following ipsecpol commands leave only port 80 accessible on a host:

ipsecpol \\computername -w REG -p "Web" -o
ipsecpol \\computername -x -w REG -p "Web" -r "BlockAll" -n BLOCK -f 0+*
ipsecpol \\computername -x -w REG -p "Web" -r "OkHTTP" -n PASS -f 0:80+*::TCP

Specifically, these two commands create an IPSec policy called "Web" containing two filter rules, one called "BlockAll" that blocks all protocols to and from this host and all other hosts, and a second called "OkHTTP" that permits traffic on port 80 to and from this host and all others. If you want to enable ping or ICMP (which I strongly advise against unless absolutely necessary), you can add this rule to the Web policy:

ipsecpol \\computername -x -w REG -p "Web" -r "OkICMP" -n PASS -f 0+*::ICMP

For more information on how to use ipsecpol, type ipsecpol -h at a command line.

Also, note that port 500 (UDP) and, on Win 2000 domain controllers, port 88 (TCP/UDP) won't be blocked by these filters, as they may be required for performing IPSec authentication (88 is Kerberos, and 500 is Internet Key Exchange, IKE). Service Pack 1 included a new Registry setting that allows you to disable the Kerberos ports, by turning off the IPSec driver exempt rule:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \IPSEC:
NoDefaultExempt

Name: NoDefaultExempt

Type: DWORD

Max: 1

Min: 0

Default: 0

IKE traffic is always exempted and not affected by this registry setting. Kerberos and RSVP traffic are no longer exempted by default if this registry is set to 1.

(Thanks to Michael Howard of the Windows 2000 Security Team for setting me straight on the command syntax and the new Registry setting).

IPSec on NT?

Q: Is there a current or soon to be deployed patch that will allow us to connect to NT4 using IPSec, or will this only be supported on Win 2000 and beyond?

A: To my knowledge, you will have to rely on third-party IPSec implementations for NT 4. Some intrinsic changes to the protocol stack were made in Win 2000 to support IPSec (among other things), and those changes just aren't there in NT 4.

SSH - not just for UNIX anymore

Q: I've heard a lot about SSH for remote management of Windows. What is it?

Secure Shell (SSH) has been a mainstay of secure remote management on UNIX-based systems for many years. It is a mature protocol, currently in its second major release, and it is under development as an Internet standard. See The Secure Shell FAQ for more information.

SSH differs from IPSec in that it operates at the application layer, rather than the network layer. Thus, it will only secure those specific applications that are sent over an SSH tunnel, whereas all applications sent via IPSec are tunneled transparently. The simplest way to think about SSH is as an encrypted telnet session. Some implementations of SSH include the scp (secure copy) and sftp (secure ftp) utilities that allow encrypted file transfer as well. For anyone remotely managing a Web server or other critical system, SSH is far superior to telnet due to the protection it offers against eavesdropping, man-in-the-middle, and spoofing attacks, to name three.

There are plenty of SSH clients out there, as the FAQ indicates. I've used commercial SSH clients from F-Secure Corp. and Van Dyke Technologies, which are solid and reliable. One important thing to note is the SSH1 and SSH2 are actually different protocols, and compatibility issues may result when trying to mix and match client and server. I have also had bizarre results when using the most recent versions of some commercial SSH clients when using advanced features—it sometimes pays to back down a revision to eliminate problems.

The real problem for Windows users is the lack of available SSH servers, which have traditionally been UNIX-based (no commercial Windows SSH servers exist, to my knowledge). Recently, I was pointed towards a free and simple to install SSHD1 package that may help SSH to become more widespread on Windows (it is based on another package that has been around for awhile, and the work of a few others).

This package installed effortlessly on Win 2000 (you will note the error "execv /bin/sh failed: No such file or directory" while installing—this is safe to ignore, just answer yes to prompts). Within seconds, I had a secure SSH1 connection to my IIS 5 Web server using Van Dyke's SecureCRT:

This sshd package does make some changes to the system, but none appear to be of enormous consequence. Besides copying necessary files and generating keys, the basic changes are: cmd.exe is copied to the root directory C:\ (this may have security implications for interactive users), instsrv from the NT Reskit is run to install srvany.exe as a service, and a .reg file is imported to the registry to configure the srvany service to run c:\winnt\sshd.exe.

This sshd uses standard NT logon credentials, and using a packet capture tool to monitor several sessions, all I saw was gibberish, indicating the daemon was indeed encrypting traffic between server and client.

Once sshd is running, you have more than secure command-line access to your server. Using the pscp.exe utility from the free puTTY Win32 Telnet/SSH Client you can copy files over an encrypted connection. It works like so:

pscp [local_path]file.txt administrator@192.168.234.41:[remote_path]file.txt

One of the other great features of SSH is port forwarding. This allows standard unencrypted TCP/IP communications to be tunneled within an encrypted SSH session. For example, say you run a POP/SMTP-based mail server. By running sshd on your server, and configuring users to connect using an SSH client like SecureCRT with port forwarding enabled of ports 25 and 110, everyone can send and receive mail securely between client and server.

Of course, I must make the standard disclaimers about using new software. Even some of the contributors to this new sshd distribution feel that it is "unfinished," and it hasn't been widely tested yet. I'd recommend deploying it in a non-production environment first just to be prudent. I did note (like one of the contributors) that each connection to the daemon caused two new sshd.exe processes to show up on the server, both consuming between one and two megs of memory. They disappeared when the connection was closed, leaving the original sshd process. That being said, I sure like what I've see so far. Let me know if you give this a try.

Crypto, crypto everywhere

It just seems that I never have time to talk about all of the good stuff I come across each month in Windows security. Stay tuned for next month as we continue our discussion of secure communications protocols in Windows and introduce some OS hardening prescriptions.

Joel Scambray is a Principal of Foundstone . He is co-author of Hacking Exposed: Network Security Secrets & Solutions, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox https://go.microsoft.com/?linkid=2544905. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.