Tightening Telnet Step by Step

Controlling access with IPSec can help keep your vulnerable habitat safe from visitors of all species.

• By Roberta Bragg
• April 01, 2001

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:

1. 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.)
2. Right-click on the IPSec Policy node and select, “Create a new IPSec Policy.” This starts the IPSec Policy Wizard.
3. Click Next.
4. 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.

5. Type in a description like, “This blocking policy will prevent a telnet connection or conversation to this system.”
6. Click Next.
7. Clear the “Activate the Default Response Rule” check box.
8. Make sure the “Edit properties” check box is checked (Figure 2) and click Finish.

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

9. 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.

10. On the “New Rule Properties” page click the Add button to add a filter list.
11. 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.

12. 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.

13. 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.

14. On the Filter Properties | Description page, enter a description.
15. Click OK to return to the filter list page, then click Close.
16. On the Rule Properties | Filter Action page select Add.
17. Select the “Block” radio button (Figure 7) and click OK.
18. 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.

19. On the New Rule Properties | Connection Type page note that “All Network Connections” is the default. This is what we want.
20. 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.
21. 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.
22. 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. 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:

1. Right-click on the Screen Telnet Policy and select “Unassign.”
2. Double-click on the Screen Telnet Policy to open the Policy Property page and add a new rule.
3. From the Properties page | IP Filter List click the Add button.
4. On the IP Filter List page, enter a name and description and click the Add button to add a filter.
5. 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).
6. On the Protocol page select the TCP protocol and add the port 23.
7. 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.

8. Click OK.
9. In the Local Security Policy console, right-click on the Policy and select “Assign” to activate the rule.
10. 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.

1. First, we’ll modify a rule on the RED computer. Unassign the telnet policy. Double-click on the policy to expose the Property pages.
2. Double-click the “permit” rule.
3. Double-click the “telnet” filter.
4. 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.)
5. Close all windows and assign the policy.
6. 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.”
7. 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.
8. Now we’ll create the IPSec policy on the BLUE computer. Open the Local Security Policy console.
9. Expand the IPSec Policy node.
10. 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.

13. To change authentication method to shared-key, on each computer, double-click the assigned policy in the Local Security Policy interface.
14. Double-click the rule to open the Rule Properties page.
15. 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.

16. Test the rule. From the RED computer, attempt a telnet session.
17. 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.