Telnet by nuhman10

VIEWS: 28 PAGES: 8

									                             ACL Lab 1: Telnet Access

Introduction
In this introductory lab to Cisco control lists, we will experience the creation of some
simple standard and extended ACL's. We will apply these to a variety of interfaces,
including the virtual terminal interface (telnet). As we work with these introductory
examples, we will develop an effective technique for editing, saving, and
downloading our ACL's.

References
        Basics of Cisco Access Lists
        Router Initialization Procedure

ACL Editing Procedure
A good way to deal with ACL's that are being developed (editing and trying) is to
work on them in a text editor, then go to the 'config terminal' mode and transfer the
text file. Keeping in mind that an access-list command will add the newly specified
line at the end of the existing access list. This makes it impossible to create ACL's 'on
the fly' accurately. To avoid this problem, we will always 'erase' the previously
created ACL before we apply a new one. In some cases, this will involve working
from the command line to clear entries we have created. In other cases, we will build
this function into our new ACL's and/or write 'ACL Clearing Scripts' as we write the
originals. If this is confusing at this point, don't worry, we will straighten it up shortly
with examples. Just bear in mind - you must clear previous ACL entries before
starting new ones or you will experience unexpected results.

As with any programming situation, it is extremely important that you comment your
ACL's. When working with the editor, any line that starts with an exclamation point
will be a comment.

What is the "Current" ACL Situation
As we work through these labs, one thing that is a little painful is seeing what
access-list conditions exist, so that you can „clean up‟. Use

Show access-list to list all of the lists.

A good way to get the information about which ACL's are applied to which
interfaces:

show ip int fa 0/1 | include access
show line vty 0 4 | include access
etc.

Setup
Before starting this lab, be sure your router is in a „default‟ setup situation. Read
through the Router Initialization document linked to in the references section of this
document.

For all of the exercises in this lab, the IP's used are assuming group #5. Be sure to
replace any IP's in any of the exercises with those for your group.
     INSIDE1: Trusted Inside1 machine: 192.168.X.1, where X is your Island #.
        Boot this machine into Windows 2k
      E0: Router, trusted side interface (E0): 192.168.X.254, where X is your Island
       #
      E1: Router, Internet side interface (E1): 172.19.10.Y, where Y is the Lowest
       IP in your Island range
      OUTSIDE: Untrusted, Outside machine: 172.19.10.Z, where Z is the highest
       IP in your Island range. Boot this machine into Win2k also. Be sure your
       OUTSIDE machine is a patched OS.

Setting up for Telnet Access
1. In order to access the router via telnet a couple of settings must be enabled. First,
set up a telnet password for virtual terminal lines 0-4. Let‟s all set our telnet
passwords to „telnet‟:

(config)# line vty 0 4
(config-line)# password telnet

2. Secondly, whenever telnet is used, we must also specify a password to enter the
privileged exec mode. Let‟s set this password to „enable‟

(config)# enable password 0 enable

Once this is done, we will have to use the enable password to enter the priv exec
mode even when using the console connection.

Exercise 1.1: Router Telnet Relay

Review of Cisco Telnet Privileges
Cisco routers have different levels of login access, each with different security
privileges. You can configure the router to have user accounts with different levels of
privilege. The default configuration provides a general restricted login, known as user
EXEC level access, with a specific login password used for initial entry. Once logged
in, a user can look at router statistics, such as routing tables and interface traffic
counts, and telnet to other hosts, but he or she can't configure the router or
examine its configuration. Router configuration commands do not exist at that initial
login level of privilege. If someone who has gained login access to the router wants
to configure the router, he must request to do so. At that point, another password is
required (the „enable‟ password) to gain the necessary privilege level, known as
privileged EXEC.
        While it may seem that the initial login mode is not particularly useful, this is
not true. Having multiple levels of privilege can be very useful. From basic login
access, a network technician or administrator can still debug problems and monitor
key router information, such as interface statistics, without risking critical services or
the security of the router and the organization and business needs it serves.
        Network administrators from one management domain may give network
administrators from another management domain login access, but not privileged
access, to routers. One real-world example of this is with Internet service providers
(ISPs) and their high-speed leased-line customers. Some ISPs offer an Internet
connectivity service with a router that they manage on the customer's premise.
Customers are given the user EXEC mode password, but they cannot change the
router's configuration because they are not given the privileged EXEC password.
        Most routers can be used as a platform to telnet to another machine. The
Cisco is no exception to this. Though this can be a useful function, it can also provide
a tool for the potential hacker. Many routers (notably Cisco) allow the TELNET
command to be performed at the lowest security level (EXEC level). This means that
if someone can telnet to a Cisco router, then they will be able to telnet from there to
anywhere else. The implications of this are significant: a hacker can use your router
to disguise his attacks, or even to bypass the router's defenses and enter your own
'protected' network.

A word on the telnet operation
The telnet operation is normally associated with port 23 (telnet). However, a telnet
connection is nothing more than a terminal interface, and can be used to connect to
any open port. Once connected to a port one must know the available commands for
that particular application. In the few exercises that use telnet, we are really only
interested in whether or not we can make a telnet connection. For this reason, it is
not necessary to have a telnet service running on a machine we are attempting to
connect to, only that there is an open TCP port on that machine. But, if you would
like to play, it is very easy to start a telnet server on any of the machines – the
win2kpro and the linux machines both come with telnet servers. To see how to do
this, see the information at the end of this document “Setting up Telnet Service”. The
telnet service may already be running on the Win2k machine.
        If you would rather wait until another time to experiment with setting up
telnet services, simply telnet to port 445 on the Win2k machine, and port 111 on the
Linux box. Neither of these ports will respond, nor will you be able to enter any
commands, but you will be able to tell if you have made a connection – thereby
indicating that the telnet process has been successful. You can also use the Qod
(Quote of the day - port 17) or ToD (Time of day, port 13). These will provide
positive feedback that you have made the connection (ie: you will get a response).
However, these ports close as soon as they respond, so netstat will not show you an
„Established‟ connection.

Procedure
In this first exercise we are merely becoming familiar with using the router as a
telnet 'relay agent'. With the router set up without any restrictions (which it should
be at this initial time), any machine on either side (trusted side, or Internet side) will
be able to telnet to the router.

a) From your trusted machine, telnet to the router:

       INSIDE1> telnet E0

      Could we telnet to E1 instead?

b) You should now have the prompt for the router. Now, via the router telnet to the
OUTSIDE machine, port 445.

       Router>telnet OUTSIDE 445

c) You will know that the connection has been established (it will say “open”).
However you will not be able to do anything on this port. The connection will
automatically close in about a minute. Before it does though, quickly perform netstat
on the OUTSIDE machine.
        What does it show as the connection? (IP and port)

d) Also before the connection times out, from the router terminal interface:

       Router> show user
          What does it show as the connections?

e) Now let‟s try it from the outside in. First close your telnet session from your inside
machine. (Use the 'exit' command.) From your Outside box, telnet to router:

       OUTSIDE> telnet E1

      Could we have telnet to E0 instead?

f) From there, relay to the INSIDE1 machine. You can telnet to port 445.

       Router> telnet INSIDE1 445

In this case, you will not be able to run netstat on the INSIDE1 machine (well, you
can, but you will not see the connection, since it opens and closes so quickly). If you
telnet to port 445 however, it will and show a connection.

g) Perform the 'show user' command again.

          What are the connections shown?

h) Close the telnet session from the outside box.

i) This telnet 'relaying' may seem silly at this point. After all, you can simply telnet
directly to the destination machine. Try this – from the INSIDE1 machine, telnet
directly to the OUTSIDE machine:

       INSIDE1>telnet OUTSIDE <port number>

          Was it successful?

So, why bother to relay a telnet session? Well, there are a few possible scenarios
where this would be beneficial. As mentioned earlier, a hacker would do it in order
to…
    1. conceal his own IP while he performs intrusion
    2. use it to get „around‟ a firewall.
An administrator might use it to access machines that were on the other side of the
firewall, yet could not be contacted directly (same as #2 for the hacker). Next we will
take a deeper look at these situations.

Exercise 1.2: Router Telnet Access Permission
In this exercise we will set up an access list to allow only certain machines to have
access to the router‟s telnet capabilities.

a) Create the following text file using notepad. Save it as ACLex1_2.txt. (Be SURE to
change the labels to the appropriate IP addresses.)

!first erase old access list
no access-list 1
!allow access from inside box
access-list 1 permit INSIDE
!allow access from outside box – turned off for now
!access-list 1 permit OUTSIDE
!
!apply access list to the terminal lines
line vty 0 4
access-class 1 in

b) Create the following text file for the removal of the ACL. Save it as
ACLex1_2NO.txt.

no access-list 1
line vty 0 4
 No access-class 1 in

The access-class command does not consider what interface is used to telnet into the
router, so the exact interface that the packet came from does not matter. If host
INSIDE has a route to the router through interface Ethernet 0, they can continue to
use that interface to gain access to the router. On the other hand, any other host
cannot telnet to the router no matter which interface it uses.

c) Download your ACL file to the router. To do this, first move to the configuration
mode, and then perform a 'Send File' operation. As the file goes to the router, you
can see each of the instructions being executed. Keep an eye out for any instruction
that gets an error message reply. This will more than likely indicate that you did not
enter the file correctly. Check your syntax, correct any problems, re-save the file,
and re-download the file.

d) Do a „show running‟ to insure your changes have taken place as expected.

e) Once we are correctly configured, it is time to test the configuration. According to
this configuration, only the Inside machine should be able to telnet to the router.
From the Inside machine, attempt to telnet to the router:
INSIDE1 > telnet E1
        Was it successful?

f) Close the Inside telnet session. Now try to telnet to the router from the Outside
machine:
     What was the result?
     Why?

Questions:
1. Explain exactly what the access list entry does:
   access-list 1 permit INSIDE1
2. Why do we apply it to the vty IN rather than the OUT?
3. What would be the result if we applied it to the OUT? Would it still work? Would it
   do anything? Explain your answer.
4. With this setup can the inside machine RELAY telnet to the outside machine?
   Explain why/why not.

g) Before moving on to the next exercise, remove the ACL setup from this exercise.
To do so, download the second file we created to the router - ACLex1_2NO.txt. Then
run your show commands to insure that the ACL stuff has been cleared.

Exercise 1.3: Addresses Reachable from the Router Telnet Sessions
In this exercise we will see how to restrict the outgoing telnet connections to only our
own local network and the two machines that we are allowing incoming connections
from.
a) Enter the following. Save as ACLex1_3.txt:
!first erase old access list
no access-list 2
!define our INSIDE network
access-list 2 permit 192.168.X.0 0.0.0.255 (where X is your Island #)
!
!apply access list to the outbound connections from the vty
line vty 0 4
access-class 2 out

b) Download the ACLex1_3.txt configuration file to the router, and verify its success
as we did in the previous exercise. Correct and repeat as necessary.

c) Telnet to the router from the Inside box

       INSIDE1>telnet E1

d) From there, telnet to the outside machine

       Router>telnet OUTSIDE 13

      Was it successful?
      Why? Explain what the access list rules have done.
      Can the outside machine telnet out via the router?

e) Let‟s try the last question. From the outside machine, telnet to the router:

       OUTSIDE>telnet E0

f) From the telnet session, try to relay to the Inside machine:

       Router> telnet INSIDE1 13

          What is the result?

g) Of course, we have not done much to defend our internal machine yet. After all,
any outside machines could telnet directly to our inside machine. So, let‟s remove
that capability. To keep it simple, we will deny any type of outside connection to our
inside machine by adding another access list. Enter the following lines at the console:

access-list 1 deny any
int fa0/0
 ip access-group 1 out

      What does this new list do?
      What affect does it have when applied to the fa0/0 outgoing interface?
      What affect would it have if applied to the fa0/1 incoming interface?

h) Try to telnet directly from the outside box to the inside machine now:

       OUTSIDE> telnet INSIDE1 13

          What is the result?

i) Now try it via the router:
         OUTSIDE> telnet E0
Then..
         Router> telnet INSIDE1 13

            What was the result?

j) While we have this setup, let‟s try something else. From the outside box, close the
telnet session with the router, and then PING the inside machine:
        OUTSIDE> ping INSIDE1

        What is the exact result?
        What is unique about this response, and what does it indicate?

Its unique in that the response is coming back from the router. It indicates that no
packets can go from outside to inside, yet the telnet via router can get through.

k) Now try PINGing out from inside.

         INSIDE1> ping OUTSIDE

        What happens?
        Can you explain why?

Notes:
The method we have used to protect our internal networks to disallow any traffic to
go OUT the interface feeding the internal network. This approach is satisfactory when
you have multiple interfaces. In our case, if a packet comes in from the fa0/1
interface, there is only one place it can go – to the fa0/0 interface. Therefore, it
doesn‟t make any sense to even let the packet in, if we don‟t have any place to route
it.

            What is a better way to apply the access list that denies any so that we
             don‟t accept packets that cannot be delivered?

Our access list denies access FROM any host TO any host on the fa0/0 interface. This
basically isolates the machines on that interface. The only way they can
communicate with the rest of the world is VIA the router (i.e.: telnet relay). This is a
little like a „proxy‟ would work.

o) Before we leave this exercise, let's remove all of the installed ACL stuff. Create the
following text file and save it as ACLex1_3NO.txt:
no access-list 2
line vty 0 4
 no access-class 2 out
no access-list 1
int fa0/0
 no ip access-group 1 out
 no ip access-group 101 in

p) Now, send this file to your router. (Note that this file is a bit of a 'failsafe' in that it
removes everything we created during this exercise, even though it might not still be
active.)

Some Final Notes
There are other reasons to restrict the addresses reachable from a router. If a router
login password is compromised, restricting access can trap the intruder and make it
impossible for him to get any further (of course, if the enable password is
compromised, the intruder can simply reconfigure the router to let him through).
Also, network administrators may wish to prevent their user communities and net-
work technicians from using a router as a Telnet proxy to get around firewalls, and
an unscrupulous person could use the router as a way to perform activities that
cannot later be traced by firewall logs.

Problems
1. Write an ACL that will allow NO telnet hopping via the router whatsoever.
2. Write an ACL that will allow ONLY outgoing (from the trusted side) telnet hopping
   via the router.
3. Write an ACL that will allow only the single Outside box to telnet hop to the
   SINGLE inside machine. Ie: only OUTSIDE can telnet hop, and it can ONLY hop to
   INSIDE1.
4. In class we discussed how important it is to NOT use Telnet for your remote
   router connection - but use SSH instead. Determine how to set up your 2621 to
   provide SSH connection only. Provide all the details and how you tested your
   setup.


Appendix: Setting up a Telnet Service
On the Win2kPro
   1) Go to Control Panel > Administrative Tools > select Telnet Server
      Administration
   2) You will get a command-line type menu.
   3) Select #3 – Display/Change Registry settings
   4) Select #7 – NTLM. It will tell you the current value (probably 2), change this
      to 0.
   5) Return to the original menu and select #4 – Start the Service.
   6) Run netstat –aN. You should see the machine listening on port 23.

On the Linux Box
   1) First check to make sure it isn‟t already running:
          a. Netstat –pant.
          b. If you see port 23 open, then you are ok. Skip to the check the
              iptables.
   2) Check to see if the telnet daemon is installed:
          a. Whereis telnetd
          b. If you don‟t get a response telling you where it is, you will need to
              install it. If you did, you can skip the install part.
   3) Install xinetd and telnet
          a. Fire up the Linux CDRom and open the RPM‟s. Install xinetd. After that
              install telnetd (be sure to install the SERVER, the client is already
              installed).
          b. Set up telnet to start
          c. Go to the /etc/xinetd.d directory. Open the telnet file with a text
              editor. Change the „disable‟ from „= yes‟ to „= no‟. Save file.
   4) Start telnet
          a. From the command line, type
          b. /etc/rc.d/init.d/xinetd start (or „restart‟ if it is already running)
          c. Return to step 1.
   5) Don‟t forget iptables.

								
To top