Showing posts with label Basics. Show all posts
Showing posts with label Basics. Show all posts

Friday, August 5, 2022

Lesson 2 - Navigating in Cisco IOS


 LESSON 2 - LAB

Cisco IOS Navigation Part 1


Cisco Navigation Part 2
 

Once, you have connected to your terminal to Cisco switch or router console port power it up and observe startup messages on your screen.

In case your network device does not have startup-configuration saved in NVRAM/Flash memory, you will be greeted with 'Would you like to enter the initial configuration dialog [yes/no]:' message as depicted below:

Pic. 1 - System Configuration Dialog


You can safely cancel this request as its capability to configure the device is not very impressive. Just enter: no and hit enter twice. Wait, as it takes few seconds for the device to give you prompt back.

What follows is bunch of messages sent to the screen and after hitting the Enter key few times you get something like this (here is the router, but a switch would introduce itself as ... Switch> ):

Router>

What you are looking at right now is prompt of IOS operating system. Terminal and commands you type are the primary means of 'talking' (configuring/monitoring) your network node (switch/router).

IOS Modes (contexts)

From the very beginning try to be attentive to details you see on the screen.

The prompt of the device tells you which 'context' you are in.

The prompt that presents '>' character is called 'user exec mode' or 'privilege level 1 mode'. You can't configure much in this mode of operation. It is designed as a 'monitoring' mode not a 'configuration' one. You should also know that even monitoring capability in user exec mode is limited. For instance, you can't see the running configuration of the device. However, it is useful for less experienced users who want to perform basic diagnostics of the device without risking of accidental re-configuring the device and causing a problem.

Make sure that if you are learning networking you DO NOT USE PRODUCTION equipment. You should have some lab gear to experiment on.

Assuming you are using lab equipment let's roll up our sleeves and begin to learn about different IOS contexts.

Type in the following command:

Router>enable
Router#

The prompt changes to '#' which is called 'privileged exec mode', 'enabled mode' or sometimes 'privilege level 15 mode'. I would like to draw your attention to two things here. Both modes of operation (or contexts, if you like) have two things in common:
  1. They are used primarily to monitor the device (you will be using 'show' and 'debug' commands in those modes).
  2. Using any IOS command and pressing enter will execute the command as long as its syntax is correct. In case you make a typo or command is not available in the context you are in, an error shows up on the screen and the command will not be executed.
NOTICE!
IOS takes a single command per line that must be accepted with Enter.
Now, coming back to those two modes (contexts) here's a somewhat concise explanation of what they are used for and how to use them:
  1. User Exec Mode - is limited in terms of what information will be available.
  2. Enabled Exec Mode - gives the operator ALL information (like root or Administrator account on a computer).
Question Mark

IOS commands (one per line) can be a single keyword or a keyword followed by one or more arguments. You should learn how to ask IOS for help as there will be a lot of commands to remember and a lot of arguments those commands can take.

Question mark '?' is your best friend in learning commands. It is a built-in help that is a 'context-sensitive help'. This means that depending on which context you use, typing a question mark (?) will display only keywords (commands) available in this particular context.

Configurations

In order to configure things in Cisco IOS (except for some minor changes), you must enter the 'global configuration mode' first which is characterized by the following prompt:

Router(config)#

This context can be accessed by typing the following command in the 'privileged exec mode':

Router#configure terminal

Whatever you configure device in 'global configuration mode' or 'config mode' it is going to be applied to the device as a whole unit (e.g. hostname, default gateway on a switch etc.). Don't worry about details right now. I will explain them in due time.

If you want to enter the context of the interface to add some parameters to it such as ip address, speed, duplex, description etc. , you must enter that interface from the global configuration mode like the one below:

Router(config)#interface fastethernet0/1


REMEMBER!
Watch your prompt to know in which context  your cursor is. If a particular command does not work it is either a typo, or perhaps you are in the wrong mode of operation (wrong context).

If you do not know what interfaces your device has, type the following command in the enabled mode:

Router#show ip interface brief

Here's first 'gotcha'. All 'show' commands can only by typed in either user-exec mode or privileged-exec mode. If you are in the 'config' mode you must precede show command with the 'do' keyword as shown below:

Router(config)#do show ip interface brief


Now look at the whole navigation I just showed here:


Router>enable
Router#configure terminal
Router(config)#interface fastethernet0/1
Router(config-if)#do show ip interface brief
  1. Entered the interface type (here: Fast Ethernet).
  2. Referenced the module number (here: 0)
  3. Referenced the port number in the module 0 (here: 1)
Please, note that routers count ports starting from 0, switches start counting ports from 1.

You'll learn other contexts as we go through numerous labs.

Abbreviations

You don't have to type in the full words of the commands and certain attributes that follow the commands. For instance, instead of typing:

Router#configure terminal
Router(config)#

You can type:

Router#conf t
Router(config)#

As long as the abbreviation uniquely describes which command you want to use, the system has no problem accepting it.

Shortcuts And Keystrokes

When you type enough of the characters that uniquely identify the command in a given context you can use 'tab' key and the system is going to complete the command on the screen (just like it happens in Linux terminal).

I often use the following keystrokes while editing the commands:
  • CTRL-z - takes the cursor back to the 'enabled exec' mode from any other context (Router#)
  • CTRL-a - takes the cursor to the beginning of the line
  • CTRL-e - takes the cursor to the end of the line
  • CTRL-k - erases everything to the right of the cursor
  • CTRL-u - erases everything to the left of the cursor
  • Up Arrow or CTRL-P - displays previous command from the history buffer
  • Down Arrow or CTRL-N - displays next command from the history buffer
System keeps the record of up to ten or twenty (default) commands you typed in. That depends on the system you use. You can increase/decrease the history buffer up to 256 commands.

If you want to check the history buffer size, type in:

Router#show terminal | include history

I will describe this pipe character '|' and 'include' keyword in our practice lab later.

Changing the buffer size can be accomplished with the following command in the 'enabled mode'

Router#terminal history size 256

There is another way of doing it, that you will practice in our lab section.

The above command will increase the size of the history buffer to 256 commands.

If you want to see the buffer (which commands were typed) use this command:

Router#show history
    If you understand the content of this lesson, let's practice all you have read (and a bit more) in our first lab.






    Friday, March 18, 2016

    Lab 3-3: Using ACLs to filter IP based traffic

    Previous Lab | Exercises | Next Lab



    Lab pre-requisites:

    Lab 2-1 Packet Tracer Topology Download.

    Topology Diagram


    This is continuation of the previous lab related to basic security.
      
    Task 1: Configuring an ACL (Access Control List).


    In this exercise assumptions have been made:

    PC1 (IP Address: 10.1.1.100/24) is allowed to to access Server (172.16.1.100) using any protocol.

    PC2 (IP Address: 10.1.1.101/24) CANNOT use telnet Server. All other traffic is allowed.

    There are few ways of constructing ACL. Here's one of them:

    Step 1
    Configure ACL statements:



    Branch#conf t

    Enter configuration commands, one per line. End with CNTL/Z.

    Branch(config)#access-list 100 deny tcp host 10.1.1.101 host 172.16.1.100 eq telnet

    Branch(config)#access-list 100 permit ip any any

    Branch(config)#

    Step 2
    Apply the ACL on Fas0/0 interface blocking incoming packets.

    Branch(config)#int f0/0

    Branch(config-if)#ip access-group 100 in

    Branch(config-if)#

    Branch#show access-list 100
    Extended IP access list 100
    deny tcp host 10.1.1.101 host 172.16.1.100 eq telnet
    permit ip any any
    Branch#

    Notice
    Packet Tracer does not provide us with index number next the ACL statements (on real equipment they are present and can be used to remove statements using 'named' acl syntax. 

    Notice
    Packet Tracer does not have 'show ip int f0/0' command implemented properly. This command normally displays whether incoming and/or outgoing ACL is applied on the interface.
      
    Notice
    Packet Tracer is somewhat limited here. We cannot enable http server (ip http server) on HQ router in order to properly test the ACL.


    Also 'named' ACLs are not working in the version of Packet Tracer I am using. This does not allow me to show you how to re-sequence statements, remove statements, and squeeze statements between other ones.

    Verification:

    Notice
    I have tested ACL using PC2 and telnet is NOT being blocked as expected. This proves that version of Packet Tracer I use is NOT working properly.

     


    Previous Lab | Exercises | Next Lab

    Wednesday, March 16, 2016

    Lab 3-2 Device Hardening




    Lab pre-requisites:

    Lab 2-1 Packet Tracer Topology Download.

    Topology Diagram


    This is continuation of the previous lab related to basic security.
      
    Task 1: Managing unused ports on a Switch.
    Task 2: Using Switchport port-security.
    Task 3: Disable unused services.

    Since all the switch ports are 'up' by default, this means that creating any connection to a port (connecting a device to a port), will cause the port to go up. This can create a problem for an administrator, as the users have access to the access switch ports through sockets in a wall or a floor. It is in the best interest of administrator to control who can plug new devices into the network. 

    Task 1: Managing unused ports on a Switch.

    As an example let's disable the following ports on SW1:
    Fas0/2, Fas0/4-12, Fas0/14-24.

    In order to do it in 'one shot' we are going to use the range command. It allows us to access the range of ports. If ports are contiguous, the range command uses a hyphen as separator, if not a comma is used as shown below:

    SW1(config)#interface range fas0/2,fas0/4-12,fas0/14-24

    SW1(config-if-range)#description UNUSED

    SW1(config-if-range)#shutdown

    I have thrown in the 'description', just to make sure that the ports are disabled for a reason.

    Verification in Packet Tracer would be to type in:

    SW1#show run

    Notice
    If you are using a real equipment I suggest that you used the following command:

    SW1#show interface status | include disabled

    This will display all the ports you have disabled filtering the ones that have not been disabled.

    Task 2: Using Switchport port-security.

    Now, let's fool around with port security. Suppose we want to ensure that port fas0/13 currently servicing our Branch router (fas0/0), will only allow its mac address as the source mac address. Port security can be applied.

    Try to remember the few things realated to port security:
    • In order to enable port security, 'switchport mode access' is required on the port as by default all ports are running 'dynamic' mode (Dynamic Trunking Protocol). Only ports in truly 'access mode' can be enabled for port security by default.
    • If you apply port-security the following security template will be applied: (only 1 mac address can be serviced on the port, the first mac address learned becomes the secure one, this mac address is NOT copied to the port configuration, the violation action is shutdown.
     More information on the options in another post.

    Let's configure the following on the port fas0/13 (connection to Branch):
    • Only 1 mac address allowed (Branch fas0/0)
    • Upon violation: shutdown the port (err-disable)
    SW1(config)#int f0/13
    SW1(config-if)#switchport mode access

    SW1(config-if)#switchport port-security

    SW1(config-if)#


    Verification:

           
    Based on the test we can say the following:

    Port fas0/13 is currently in secure mode (Secure Port).

    Only 1 mac address is allowed (MaxSecureAddr Count).

    The first learned mac address has become secure (CurrentAddr Count).

    There was no violation reported (SecurityViolation Count).

    If there is transmission hitting the port fas0/13 with the illegitimate mac address, the port is going to be 'shutdown' (put in error-disable state).

    Another way of checking this:



    Notice
    If the port is err-disabled, there are only two ways to bring it up:
    1. Disable the port (shutdown), and re-enable manually (no shutdown).
    2. Use errordisable recovery (not taught in CCNA courses).
    Display the current secure mac address:



    Notice
    Packet Tracer does not have this feature fully implemented (it does not behave like it would on a real switch).

    In case you have a real equipment, you can do the following:

    Configure Branch fas0/0 with a new mac:

    Branch(config)#int f0/0

    Branch(config-if)#mac-address 0008.eeee.eeee

    Branch(config-if)#


    In a few seconds, the router Branch will send 'gratuitous arp' message. Its source mac-address changed and will cause the violation.


    The port of the SW1 (fas0/13) will go 'down' and be placed in error-disabled mode. 


    You could then check this by issuing one of the two commands:


    SW1#show interface status | i err

    or

    SW1#show int fas0/13

    Also, SW1 shows the message that causes the violation etc.

    Task 3: Disable unused services.

    The last task relates to disabling certain services that might create security problem for us.

    If you want to disable CDP protocol, you can do this on all interfaces of a switch/router at the same time:

    SW1#conf t
    SW1(config)#no cdp run

    or on per interface basis:

    SW1#conf t
    SW1(config)#interface fas0/1
    SW1(config-if)#no cdp enable

    Verification:

    SW1#show cdp interface

    You will see that Fas0/1 is no listed anymore.

    Notice
    The below commands are NOT supported in Packet Tracer
    On some routers (especially older ones), check the following command for open ports:
    show control-plane host open-ports

    You might see that HTTP port is open (port 80). Then best practice is to disable it:

    Branch#conf t
    Branch(config)#no ip http server

    Also, a good practice would be to disable the following services (enabled by default on older routers):

    Branch(config)#no service tcp-small-servers
    Branch(config)#no service udp-small-servers
    Branch(config)#no service finger
    Branch(config)#no ip bootp server

    If you want to learn more on those all sevices check Cisco documentation.



    Tuesday, March 15, 2016

    Lab 3-1 Improving Device Security




    Lab pre-requisites:

    Lab 2-1 Packet Tracer Topology Download.

    Topology Diagram


    In this lab there are four tasks that allow apply a basic security on IOS based switches and routers.
     
    Task 1: Device password protection.
    Task 2: Remote access using Telnet and SSH.
    Task 3: Limiting remote access based on source IP Addresses.
    Task 4: Creating a login banner page.

    Let's rock and roll!

    Task 1: Device password protection.

    As an example let's protect access to SW1 starting at protecting the console which by default allows access without any password.

    Notice
    Switches and routers allow access to the console without prompting for the password. There is 'no login' keyword applied on the by default which means that a user is not prompted for the password even if one is configured. In order to protect the console, you must apply both password and 'login' keyword in order to prompt the user for the password.

    SW1 Console Password (use cisco as password):


    SW1>enable

    SW1#conf t

    Enter configuration commands, one per line. End with CNTL/Z.

    SW1(config)#line con 0

    SW1(config-line)#password cisco

    SW1(config-line)#login

    SW1(config-line)#

    In order to verify this configuration exit session by first typing end and then exit. You will be prompted for the password while creating new console session.

    As of now, we only protected console access. We must also protect the privileged exec mode (enabled mode). Let's use password sanfran for a change. The command should be applied in the global configuration mode (if you are still in the console prompt, type in exit to go back to global config mode).

    SW1(config)#enable password sanfran

    SW1(config)#

    Now, if you try to login to enabled mode the system will ask you for password sanfran to grant you access.

    The problem is that all the passwords are now showing in clear text format. Check this out:


    In order to protect all the existing passwords and the ones you will add in the future, we can encrypt them using Type-7 algorithm known as 'over-shoulder' encryption.

    Let's turn on the service now, using global configuraition command as shown below:


    SW1(config)#service password-encryption

    SW1(config)#

    All the passwords are not showing as clear text any more. However, you must still be careful not to disclose those encrypted strings as they can be easily broken on the net. As an example, copy the string below that my system used for sanfran:

    08324D400F0B0419

    Open the web page below and paste the string into Type-7 box and click 'Crack Password'. See for yourself.


    However, this protection is making difficult for a person to guess our password while looking at our screen when we display running-config.

    It is much smarter to protect our enabled mode, using a properly encrypted password (either MD5 or SHA-256 will be used dependent of the platform). Let's also use password cisco to do it.

    SW1(config)#enable secret cisco

    SW1(config)#

    Now, let's see what encryption Packet Tracer applied:

    Since we have both: enable password (sanfran) and enable secret applied, the question is which password is the system going to use upon our attempt to enter 'enabled mode'? The answer is, the password that is more secure (secret). The only problem is that using secret method we can only protect enabled mode but not console or vty lines (used for remote access). We will handle this as our last thing in this lab.

    Lastly, in this task let's allow remote access using Telnet. Here's the basic configuration (password cisco again, although on the production equipment each mode such as console, vty, enabled, should have different passwords).

    Let's see if we try to access switch (vty lines) using telnet, what happens when login keyword is applied but there is no password used as shown below:
    !

    line vty 0 4

     login

    line vty 5 15

     login

    !

    Notice
    At the moment, my PC1 has IP Address: 10.1.1.100/24.
    SW1 has VLAN1 interface configured with IP Address: 10.1.1.11/24

    My Telnet session from PC1 results in the following:




    Notice
    On a real equipment we receive the message:

    password required but none set

    Task 2: Remote access using Telnet and SSH. 

    If we want basic connectivity, assigning password to the first set of vty lines (0-4) can allow up to 5 simultaneous Telnet connections (if more is required apply password on vty lines 5 15 etc.)

    SW1(config)#line vty 0 4

    SW1(config-line)#password cisco

    SW1(config-line)#

    Now, Telnet works!



    Notice
    When you choose password for the production equipment, make sure that they are long (at least 8 characters) and not dictionary keywords. Use upper and lower case with special characters (such as %, ^, & etc.).

    However, from security perspective, Telnet connections are not recommended as everything we type (that includes the password) are sent in clear text format. If intercepted, we're in trouble. 

    SSH connections are highly recommended. Let's allow SSH support for our remote connections to SW1. These are necessary steps:

    Notice
    In real network it is recommended to have a centralized login access solution (using AAA server). Here, only local protection is used.

    Step 1
    Create username and password on the local device (user: ccna, password: cisco)


    SW1(config)#username ccna secret cisco

    SW1(config)#

    Notice
    If you want the user account (here ccna) to have access to privileged mode automatically upon connection to vty lines (skipping 'user exec mode'), you can use this instead:

    SW1(config)#username ccna privilege 15 secret cisco
    SW1(config)#

    Step 2
    Configure domain name (here cisco.com)
    Without domain name RSA public/private keys cannot be generated (command is rejected)

    SW1(config)#ip domain name cisco.com

    SW1(config)#

     
    Step 3
    Generate Public/Private key pair used for encryption/decryption of our transmissions while remotely accessed using SSH. Apply key 1024 bit when asked for modulus.

    SW1(config)#crypto key generate rsa

    The name for the keys will be: SW1.cisco.com

    Choose the size of the key modulus in the range of 360 to 2048 for your

    General Purpose Keys. Choosing a key modulus greater than 512 may take

    a few minutes.



    How many bits in the modulus [512]: 1024

    % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]



    SW1(config)#

    Step 4
    Change SSH session version to allow only SSHv2 connection (default 1.99 allows both SSHv1 and SSv2).

    Default:


    SW1(config)#ip ssh version 2

    SW1(config)#

    After the change:



    Step 5

    Allow SSH acces.

    SW1(config)#line vty 0 4

    SW1(config-line)#transport input ssh

    SW1(config-line)#login local

    SW1(config-line)#

    Notice
    The command: transport input ssh, only allows ssh. You can add telnet as well but in my opinion that defeats the purpose of this lab.

    Also, the command: login local, allows system to use locally defined user (ccna) to log on.

    You can verify this configuration by ssh-ing to itself (notice: -l for login not number 1 below):

    SW1#

    SW1#ssh -l ccna 10.1.1.11


    Exit upon verification



    Task 3: Limiting remote access based on source IP Addresses.


    As an example let us allow PC1 (IP Address 10.1.1.100) to access SW1 using SSH but no other source IP address.

    SW1(config)#access-list 5 permit 10.1.1.100

    SW1(config)#line vty 0 4

    SW1(config-line)#access-class 5 in

    SW1(config-line)#

    Notice
    The last 'implicit' rule says deny any. That means that no other source IP address can get access to vty lines (ssh/telnet).

    On real equipment you could add the following ACL statement

    SW1(config)#access-list 5 deny any log

    Unfortunately, this 'log' option does not work in Packet Tracer.

    Task 4: Creating a login banner page.

    Notice
    Banner in Packet tracer only supports motd option (banner login does not work)

    SW1(config)#banner motd &

    Enter TEXT message. End with the character '&'.

    *************************************************

    * Unauthorized Access Strictly Prohibited! *

    * ***********************************************

    &



    SW1(config)#

    Notice
    Make sure that you start banner with a delimiting character that is not used in the banner itself (I could not use '*' as a delimiting character). You must end with the same character to mark the ending of the message to be displayed upon connection.



    Verification
    Since only PC1 can access SW1 remotely I added telnet support (no ssh client on PC1) to see the banner upon connection.

    SW1(config)#line vty 0 4

    SW1(config-line)#transport input all

    SW1(config-line)#


     
    The last "security" touch is to use username and password for console 0 access. Since we have username and password locally defined (ccna/cisco), let's use it:

    SW1(config)#line con 0

    SW1(config-line)#login local

    SW1(config-line)#


    Cisco Is Easy - Main

      Cisco Basics (CCNA level)  Lessons: Watch Video Tutorials on Youtube 01 - Connecting to Cisco Console Port with MINICOM 02 - Navigatin...