VIEWS: 28 PAGES: 8 POSTED ON: 10/24/2011
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.
Pages to are hidden for
"Telnet"Please download to view full document