Tightening Telnet Step by Step

“The work is done, but how no one can see; ’Tis this that makes
the power not cease to be.” —Lao Tzu, Tao Te Ching

When I travel, I have to leave my friend Jane, the 13-year-old Boxer,
behind. So when an opportunity to baby-sit two of my friend’s dogs came
my way, I was reluctant to say no.

If you’ve followed this column, you learned about default IPSec policies
and, last month, worked your way through my introduction into the theory
and architecture of IPSec on Windows 2000. This month, it’s time to build
a useful policy courtesy of Roscoe and Oscar (the visiting pups) and use
it to lock down some portion of the network.

Now, because I have a huge house, I’m currently playing hostess to three
dogs, two cats, two visiting sleepover guests of the human (Klingon? Troglodyte?)
variety, and a variable number of daytime interlopers. You can see my
problem here. I need to block or restrict access to some resources and
generally control the comings and goings of all creatures without offending
them or having the equivalent of World War III within the confines of
my very vulnerable habitat. It’s like your opportunities to control access
and access paths to resources and services on your network. It’s a bit
of a hassle to figure out the right policies to put in place and quite
problematic if your actions keep your constituents from the resources
they need. (Roscoe, Oscar and Jane never did get their calls of nature
coordinated, and woe the party that blocked their access to the great
outdoors.) After figuring out protocols for my own alien nation this week,
configuring IPSec policies, rules and filters is a snap. While you don’t
have similar animal instructors in the Tao of IPSec, I’ll try to make
your job just as easy with my step-by-step instructions.

One warning though: I want you to think about IPSec like you would
a nasty little yippy dog (Roscoe’s contribution). Don’t get complacent,
careless or too demanding. If you learn the pooch’s habits and give it
what it expects, it’ll roll over and perform other feats of athleticism
for you. Try to “command” or provide sloppy instructions or lose your
temper, and you’ll find it has nasty little teeth.

I’m not a big fan of instructions that come with lots of screenshots,
but I’ll make an exception here. I’ve suffered through attempts at IPSec
implementations on “not-to-be-named-for-fear-of-retribution” third-party
firewalls and instructed many in the way of lap-dog training. Pictures
seem to serve us well here. (Bloodletting works well, too; but if you’re
like me, your tetanus shots aren’t up to date—so I’ll provide the screen
shots.)

Rule 1. Block Telnet Sessions
Some of you cried for telnet capabilities on Windows boxes. You want to
administer them remotely like you do your Unix hosts, and I can’t blame
you. However, there are a number of problems with this, such as the fact
that telnet is notably insecure because it passes passwords in the clear.
While Win2K can use NTLM for password authentication, that isn’t a solution
for a heterogeneous environment and can be a security danger. (Hackers
can trick Win2K into exposing its NTLM-authentication string, which can
then be hacked using common tools.) In some environments, you may want
to provide a secure beltway for those telnet sessions: We’ll do that in
“Rule 3. Up the Ante: Require Negotiation.”

For now, I want to nip telnet in the bud: The conversation just can’t
occur. Rule 1 is a blocking rule. Any attempt to telnet to hosts to whom
the policy applies will result in the packets being dropped. Remember
the essence of a blocking policy. There’s no negotiation; the filtered
protocol simply can’t be used.

In this scenario I’ll use two stand-alone Win2K computers: RED computer,
a Win2K server, and BLUE computer, running Win2K Professional. I’ve intentionally
kept things simple here; there’s no domain to worry about — the Local
Security Policy console will suffice. (In a Win2K domain, domain, site
or OU policies can override any policy set on the local machine. This
is desirable and simplifies setting policies across the enterprise, but
makes it harder to practice and set up test policies.)

Here are the steps to follow:

Open the Local Security Policy console and traverse it to the IPSec
Policies node. Make sure that no policies are currently “assigned.”
(Those are policies actively in place and being used. For this test
we want to keep things simple.)

Right-click on the IPSec Policy node and select, “Create a new IPSec
Policy.” This starts the IPSec Policy Wizard.

Click Next.

Type in a name. “Screen Telnet” will do (Figure 1).

Figure 1. Once you ensure that there are no policies
assigned, right-click on the IPSec Policy node and select “Create
a new IPSec Policy.” Here, you’ll give the new policy a name and type
in a description.

Type in a description like, “This blocking policy will prevent a
telnet connection or conversation to this system.”

Figure 2. After specifying the properties for
the new IPSec policy, be sure to check the “Edit properties” box before
clicking Finish.

On the “Screen Telnet Properties” page make sure the “Use Add Wizard”
checkbox is unchecked and click the Add button to add a rule (Figure
3). A rule is composed of an IP Filter List, Filter Action, Authentication
Method, Tunnel Setting and Connection Type. The wizard helps you to
configure these. However, in a simple blocking rule, most of these settings
aren’t needed, nor are they relevant. The wizard’s settings, like the
instructions of the pet owner whose pets you’re to supervise, only serve
to confuse you. What’s important here is creating filters for the policy
agent to interpret. (If the packet protocol and port or IP address match
the filter, then the filter action will apply.) We’ll do that next.

Figure 3. Click the Add button to add a rule,
which will create a filter for the policy agent to interpret.

On the “New Rule Properties” page click the Add button to add a filter
list.

Enter a name for the filter list and a description (Figure 4). Whatever
you use here will show up in the first column of the “Screen Telnet”
Policy Property pages. It’ll identify the rule, so choose a descriptive
name. I’ve used the name “block telnet.”

Figure 4. The IP Filter comprises multiple filters,
allowing multiple subnets, IP addresses and protocols to be combined
into one filter. Whatever name and description you use here will show
up in the first column of the “Screen Telnet” Policy Property pages.

On the Filter Properties | Addressing page (Figure 5) change the
Source address selection box to indicate “Any IP address” and the Destination
selection box to indicate “My IP Address.” You want to block telnet
access to the RED server from any other system.

Figure 5. By changing the Source Address selection
box to indicate “Any address” and the Destination selection box to
indicate “My IP Address” on the Filter Properties | Addressing page,
you can block telnet access to the RED server from any other system.

On the Filter Properties | Protocol page (Figure 6), select the protocol
type of TCP and set the IP protocol port “to this port” to 23.

Figure 6. On the Filter Properties | Protocol
page, select the protocol type of TCP and set the IP protocol port
to 23.

On the Filter Properties | Description page, enter a description.

Click OK to return to the filter list page, then click Close.

On the Rule Properties | Filter Action page select Add.

Select the “Block” radio button (Figure 7) and click OK.

Back on the Filter Action page (Figure 8), make sure your new “Block”
filter action is selected.

Figure 7. Selecting the “Block” radio button
ensures that communication won’t be allowed.

Figure 8. Check the Filter Action page to make
certain that your new “Block” action is activated. Then, click over
to the Connection Type page to ensure that “All Network Connections”
is the default.

On the New Rule Properties | Connection Type page note that “All
Network Connections” is the default. This is what we want.

Make sure your new filter list (rule) is chosen, then click OK. Be
sure to select your new rule on the Policy Properties | Screen Telnet
page, then click Close.

Before you activate your new policy, test telnet communications to
the RED computer. From the BLUE computer go to a command prompt and
enter “telnet ipaddress of the RED computer.” Make sure that you can
start and use a telnet session, then exit the session.

In the RED computer, the Local Security Policy console expands IPSec
Policies. Right-click on your new policy and select “Assign.” This activates
the policy.

23. From the command prompt of the BLUE computer, attempt a telnet
connection. You should get the error, “Could not open a connection to
host ipaddressentered; connection failed.” This, incidentally, is the
error you’d get if connectivity failed for other reasons, such as that
the service wasn’t running.

Congratulations. Your blocking policy works!

Some of you might question, what’s the point? Why block all telnet connections
using an IPSec policy when the simpler answer would be to disable or remove
the telnet service on the system?

You have a valid point there, but what if you want to allow telnet for
yourself, yet deny it for others? By adding a second rule to your policy,
you can do that. The second rule should include a filter that identifies
telnet from your computer to the server. In our test scenario, we’ll write
a filter that identifies the BLUE computer by IP address and adds a filter
action of “Permit” for packets destined for port 23.

Rule 2. Permit Telnet from a Specific System
By adding rules to your policy, you’re defining additional actions. The
order in which you add the rule doesn’t determine whether it’s implemented.
Indeed, all rules selected in a policy are evaluated starting with the
most specific and ending with the least specific. Thus, if the policy
has a block telnet rule and a permit telnet rule, they can coexist and
still give us the response we want. This is why you must carefully define
your rule sets to account for all possible actions. If you were to define
a rule to permit telnet from your computer and no rule to block it from
others, the net effect of the rule would be to permit telnet connections
from everyone with valid accounts and passwords. By defining an all-encompassing
blocking rule and testing it first, you insure that your policy has the
desired effect.

Rule 2 in our policy has the effect of permitting a telnet session with
the RED computer from the designated IP address on the local network (the
BLUE computer), while blocking telnet sessions from anyone else.

Follow this step-by-step approach:

Right-click on the Screen Telnet Policy and select “Unassign.”

Double-click on the Screen Telnet Policy to open the Policy Property
page and add a new rule.

From the Properties page | IP Filter List click the Add button.

On the IP Filter List page, enter a name and description and click
the Add button to add a filter.

On the Addressing page, add — as a source address — the IP address
of the BLUE computer and, as a destination address, “My IP Address”
(Figure 9).

On the Protocol page select the TCP protocol and add the port 23.

Return to the Rules property pages and make sure both the “Block
telnet” and the new “Permit telnet rule” are selected (Figure 10).

Figure 9. By adding the IP address of the BLUE
computer as a source address and making “My IP Address” the destination,
telnet communication between the BLUE and RED computers is permitted.

Figure 10. To achieve the desired affect, make
sure that both the “Block telnet” and the new “Permit telnet” rules
are selected.

Click OK.

In the Local Security Policy console, right-click on the Policy and
select “Assign” to activate the rule.

Test the rule by using the telnet command from the BLUE computer
to connect to the RED computer. You should obtain a connection. Try
the telnet command from another computer — it shouldn’t work.

Congratulations. You’ve written a multiple-rule policy that works!

All’s well that ends well. However, what if an insider (someone on your
local network) wants to telnet to the RED computer and can spoof your
IP address? What about your conversation via telnet — it’s not encrypted,
is it? Couldn’t someone use a packet sniffer on your network and figure
out what you’re doing? Couldn’t someone intercept your connection creating
a “man-in-the-middle” or a “replay” attack?

All this and more are possible — so shouldn’t we protect this session
further?

Rule 3. Up the Ante: Require Negotiation
Protecting the session more tightly requires a fourfold answer:

Protect the conversation: Require encryption.

Protect the connection: Require an IPSec Policy on the BLUE computer.

Protect authentication: Require certificates.

Monitor IPSec communications and act on the results.

The sum of these actions is to create a rule that requires negotiation.
So far we’ve been blocking or permitting the telnet connection. Any computer
on the network that met the criteria was either blocked or permitted access
to a telnet connection. IPSec simply acted like a personal firewall and
only for the telnet connection. Remember, if packets from any other protocol
than telnet arrived at our RED computer, they weren’t affected by the
rule. (We could have created a rule that blocked all other protocols as
well, but that’s another story. Don’t add this rule unless you know which
protocols your Win2K system needs to participate in its network configuration
— you’ll have to create rules to allow them.)

While simply blocking and permitting communications is valuable, it leaves
too many holes for the determined attacker to jump in. To lock our system
down further, we have to create a rule that requires negotiation. Furthermore,
to allow our BLUE computer to participate in a telnet session with the
RED computer, the BLUE computer must participate in an IPSec-negotiated
connection with the RED computer. An IPSec policy must be created and
assigned to the BLUE computer. To monitor IPSec communications, we can
use the IPSec Monitor; by monitoring events, we can even log IKE negotiation
steps to a log file. (See “Who’s Talking IPSec
Today?”)

To put the negotiate rule successfully into place requires two operations.
First, the rule must be added to the telnet policy (or, as in our case,
we’ll change the “permit” rule to “negotiate”). Second, the rule must
be created on the RED computer. Here’s where all that knowledge from last
month about matching policy information really comes into play. The encryption,
integrity and authentication pieces must match from computer to computer.

First, we’ll modify a rule on the RED computer. Unassign the telnet
policy. Double-click on the policy to expose the Property pages.

Double-click the “permit” rule.

Double-click the “telnet” filter.

On the Filter Action page, change the rule to “require negotiation.”
Note that this action defaults to allow a negotiation of various algorithms
for integrity and encryption. Remember that the rule on the BLUE computer
must have a match for these algorithms or the policy negotiation will
fail. (If it doesn’t match, it’s going to crash.)

Close all windows and assign the policy.

Now we’ll test the new RED computer policy. On the RED computer,
open the IPSec monitor (ipsecmon) tool. At a command prompt, enter “ipsecmon.”

From the BLUE computer, attempt to initialize a telnet session and
note that the connection failed. The IPSec Monitor will show nothing
because no negotiations occurred and no SAs were initialized.

Now we’ll create the IPSec policy on the BLUE computer. Open the
Local Security Policy console.

Expand the IPSec Policy node.

In the detail pane, right-click on the default policy, “Client (respond
only),” and select “Assign policy.”

This default policy communicates normally with all systems, including
the RED server, but can respond to a request to negotiate security. Only
the required protocols will be used to communicate with the RED server.

Wait. You’re not done yet. It’s true that the default policy does have
all of the default settings correctly identified to negotiate encryption
and integrity algorithms. However, there’s one small problem. In our desire
to create a simple environment in which to explain and test custom IPSec
policy development, we have no domain present. The authentication method
of every policy defaults to Kerberos, and we have no Key Distribution
Center (KDC).

When IPSec policy rules and filters were blocking or permitting, IPSec
authentication didn’t play a role. IPSec merely checked its rules and
filters to see if a protocol should be blocked or permitted. Authentication
was carried out and telnet between Win2K computers allowed NTLM authentication.

If the account by which I logged onto the BLUE computer didn’t also exist
on the RED computer, neither rule would have allowed the telnet connection.
(Nor would it have been possible without rules.) However, when you change
your filter action to “negotiate,” the IPSec authentication method becomes
important. You must select an authentication method that’s the same on
both sides and that’s relevant. In a Win2K-domainless environment, Kerberos
isn’t relevant. For stand-alone systems, only shared-key or certificate
authentication can be used. Since a certificate server isn’t part of our
test environment either, for testing purposes, we changed the authentication
method to shared-key. (This isn’t an appropriate action in the real world
in most cases as the shared key is entered and viewed in clear text within
the IPSec interface. If access to these policies is restricted, the shared
key can be held in some respect. Allowing multiple users access to the
policy or knowledge of the key will weaken its effectiveness. If domain
membership isn’t an option, certificates can be used to strengthen security.

To change authentication method to shared-key, on each computer,
double-click the assigned policy in the Local Security Policy interface.

Double-click the rule to open the Rule Properties page.

On the “authentication methods” page, select “shared key” as the
method and type a shared-key phrase (Figure 11). Make sure to repeat
the phrase on each computer. Do not configure authentication methods
on the filter. While it’s possible to do so, phase 1 negotiation (which
must be completed before the SAs for phase 2 are created — see last
month’s column for a description of IPSec phases 1 and 2) will use the
rule configured on the Rule Properties page. Configuring conflicting
authentication on the filters may halt the negotiation.

Figure 11. When choosing a shared-key phrase
for authentication, be sure to repeat the phrase on each computer.

Test the rule. From the RED computer, attempt a telnet session.

On the BLUE computer, view the IPSec Security Monitor. If the negotiation
is successful, the monitor will show SA information. First the IP addresses
will appear, then—if name resolution is possible—the computer names
will replace them (Figure 12).

Figure 12. If negotiation is successful, first
the IP address will appear and, if name resolution is possible, the
computer names will replace them.

Problems?
If you’re having problems with the process, check the following:

That one authentication method exists between a pair of hosts.

Make sure to mirror your filter: One-way protection via IPSec isn’t
allowed. To create a mirror, make sure the “mirror” checkbox is selected
on the Filter Rule Properties | Addressing page or create two rules.
(You can create one-way rules for blocking or permit filters.)

The IPSec Policy Service agent server must be running.

The telnet service must be running on the RED server.

The network connections are working.

That encryption, authentication and integrity methods match.

That the source IP address is correct in the negotiate filter.

That the telnet port is correct.

That the policy is assigned.

That rules are selected.

Desiderata
While you’ll find IPSec complicated, you can accomplish amazing things
with it—its possibilities are endless. Maybe you don’t want to block telnet,
but there must be some communication you’d like to encrypt, some conversation
you’d like to prevent. How about using IPSec to develop the poor-person’s
personal firewall? Or encrypting all communications between servers in
the DMZ? Wouldn’t you like to assure that uploaded Web pages are coming
from approved sources and not being hijacked in order to load malicious
content? Should replicated data between Exchange Servers or databases
be protected?

With a little practice — well, with a lot — you can create the perfect
IPSec policies for every occasion. It’s not like babysitting yippy dogs
— you don’t have to get bitten.

Who's
Talking IPSec Today?

To monitor IPSec communications, set up auditing and use the IPSec
Monitor, netdiag and IKE logging.

Enable log on, object access and policy change auditing on the
IPSec computer. If authentication fails, helpful messages will be
recorded in the security log. You’ll also know who successfully
used that policy and changed it and what was accessed (if auditing
of objects is configured in the file system, AD and/or printer).

The IPSec Monitor shows the details of SAs. It doesn’t show failed
IPSec negotiations. It can also be used to show that the IPSec Policy
Agent is working on the system. A statement in the interface declares
it to be so.

Netdiag.exe is a tool from the Support Tools folder on the Windows
2000 installation CD-ROM. If the support tools have been installed,
the netdiag | test:IPSec will detail the current policy assigned
on the local system.

IKE logging can be enabled via a registry entry. Once enabled,
IPSec phase 1 and phase 2 negotiation is logged to the Oakley.log
file in \debug. The log is quite detailed, and
most information will only be helpful to advanced users. However,
knowledge of the negotiation phases allows you to find useful information
in the log. In our test example, you might have found that the Kerberos
authentication method was invalid; been able to trace the phase
1 and 2 negotiation; and identified the algorithms used for integrity,
authentication, and encryption and the IP addresses of the host
computers (keys and passwords aren’t exposed). Should something
have gone wrong, you might have been able to identify where the
process stopped and perhaps found a pointer to the part of the policy
and the computer it lay on to direct your review. For details of
its implementation look at the white paper, “A Step-by-Step Guide
to Internet Protocol Security (IPSEC)” at www.microsoft.com/
TechNet/win2000/
win2ksrv/technote/ispstep.asp.