Showing posts with label authentication. Show all posts
Showing posts with label authentication. Show all posts

Thursday, 14 November 2019

Cisco SYSLOG Configuration Complete Tutorial

Cisco SYSLOG Configuration Complete Tutorial

This tutorial is a complete guide on Cisco SYSLOG Configuration, what is syslog and how syslog works . In addition, how to configure syslog to collect messages on a small to medium-sized network management device.
Monitoring a functioning network can provide information to a network administrator to proactively manage the network and report network usage statistics to others. Link activity, error rates and link status are some of the factors that help a network administrator determine the status and use of a network. Collecting and reviewing this information over time allows a network administrator to view and project the growth, and can help detect and replace a defective part before it fails completely.
This chapter covers three protocols that a network administrator can use to control the network. Syslog, SNMP and NetFlow are popular protocols with different strengths and weaknesses. Together they provide a good set of tools to understand what happens in a network.
The NTP protocol is used to synchronize the time across the devices, which is especially important when trying to compare the log files of different devices.

What is SYSLOG ?

When certain events occur on a network, network devices have trusted mechanisms to notify detailed system messages to the administrator. These messages may be important or not.
Network administrators have a variety of options for storing, interpreting and displaying these messages, as well as for receiving those messages that could have the greatest impact on the network infrastructure.
The most common method of accessing system messages provided by network devices is to use a protocol called " syslog ".

Syslog uses UDP port 514 to send event notification messages over IP networks to event message collectors.
The term "syslog" is used to describe a standard. It is also used to describe the protocol developed for that standard. The syslog protocol was developed for UNIX systems in the 1980s, but IETF first registered it as RFC 3164 in 2001 .
Many network devices support syslog, including routers, switches, application servers, firewalls and other network devices. The syslog protocol allows network devices to send system messages to syslog servers across the network. It is possible to set up a special out-of-band network (OOB) for this purpose.
There are several different software packages of syslog servers for Windows and UNIX. Many of them are freeware.
The syslog logging service provides three main functions:

  • The ability to collect registration information for problem control and resolution
  • Ability to select the type of registration information that is captured
  • The ability to specify the destinations of captured syslog messages

How SYSLOG Works

On Cisco network devices, the syslog protocol begins by sending system messages and the debug command result to an internal local device registration process. The way in which the registration process manages these messages and results is based on the device settings.
For example, syslog messages can be sent over the network to an external syslog server. These messages can be retrieved without having to access the device itself. The results and log messages stored on the external server can be included in several reports for easy reading.
On the other hand, syslog messages can be sent to an internal buffer. Messages sent to the internal buffer can only be viewed through the device CLI.

Finally, the network administrator can specify that only certain types of system messages be sent to several destinations. For example, you can configure the device to forward all system messages to an external syslog server. However, debug level messages are forwarded to the internal buffer, and only the administrator can access them from the CLI.
As shown in the illustration, common destinations for syslog messages include the following:

  • Logging buffer (RAM inside a router or switch)
  • Console line
  • Terminal line
  • Syslog server

It is possible to control system messages remotely by viewing the logs on a syslog server or accessing the device through Telnet, SSH or through the console port.

 FORMAT OF SYSLOG MESSAGES

Cisco devices generate syslog messages as a result of network events. Each syslog message contains a severity level and an installation .

SYSLOG SEVERITY LEVEL

The lower the level numbers, the more fundamental the syslog alarms. The severity level of the messages can be set to control where each type of message is displayed (that is, on the console or other destinations). In Image 3, the complete list of syslog levels is shown.

Each level of syslog has its own meaning:

  • Warning level, emergency level : these are error messages about software or hardware that is malfunctioning; These types of messages mean that the functionality of the device is affected. The severity of the problem determines the actual level of syslog that is applied.
  • Debug level: This level indicates that the messages are results that are generated from the issuance of several debug commands .
  • Notification level: the notification level only provides information, the functionality of the device is not affected. Interface messages active or inactive, or system restart are displayed at the notification level.

INSTALLATION INFORMATION

In addition to specifying severity, syslog messages also contain information about the installation. Syslog installations are service identifiers that identify and categorize system status data to report error and event messages.
The available registry installation options are specific to the network device. For example, Cisco 2960 series switches and Cisco 1941 routers support 24 installation options that are categorized into 12 types of installation.
Some common syslog message installations that are reported on Cisco IOS routers include the following:


By default, the format of syslog messages in Cisco IOS software is as follows:
seq no: timestamp:% facility-severity-MNEMONIC: description
For example, the example result of a Cisco switch for an EtherChannel link that changes to the active state is as follows:
00:00:46:% LINK-3-UPDOWN: Interface 
Port-channel1, changed state to up
Here the installation is LINK, and the severity level is 3, with the UPDOWN MNEMOTECHNICAL.
The most common messages are the active link and the inactive link, and the messages that a device produces when it exits configuration mode. If the ACL log is configured, the device generates syslog messages when the packets match a parameter condition.

SERVICE TIME STAMP

Log messages can be marked with the time, and the source address of syslog messages can be set. This improves debugging and administration in real time.
When the global service timestamps log uptime configuration mode command is entered , the amount of time that has elapsed since the last time the switch was started in the logged events is displayed. A more useful version of this command applies the datetime keyword instead of the uptime keyword ; This causes each registered event to show the date and time associated with the event.
When the datetime keyword is used , the clock must be set on the network device. This can be achieved in two ways:

  • Manual configuration using the clock set command
  • Automatic configuration using the NTP protocol

To allow an NTP time server to synchronize the software clock, use the global configuration mode command:
ntp server  ip-address
In the illustration, an example configuration is shown. R1 is configured as an NTP client, while router R2 functions as an authoritative NTP server. A network device can be configured as an NTP server, so that the other devices synchronize outside their time, or as an NTP client.

R2 (config) # ntp master 1
R1 (config) # ntp server 10.1.1.1
For the rest of the chapter, it is assumed that the clock was set and the service timestamps log datetime command was configured on all devices.

SYSLOG SERVER

To view syslog messages, a syslog server must be installed on a network workstation. There are several versions of freeware and shareware of syslog, as well as business versions to buy.
The syslog server provides a relatively user-friendly interface to see the result of syslog. The server analyzes the result and places the messages in predefined columns to interpret them easily.

Network administrators can easily navigate through a large amount of data that is collected on a syslog server. An advantage of viewing syslog messages on a syslog server is the ability to perform granular searches through the data. In addition, a network administrator can quickly remove syslog messages that are not important from the database.

DEFAULT REGISTRATION

By default, Cisco routers and switches send log messages to the console for all severity levels. In some versions of IOS, the device also buffers log messages by default. To enable these two settings, use the global logging console and logging buffered configuration commands , respectively.
The show logging command shows the default configuration of the registration service on a Cisco router, as shown in the illustration. In the first lines of the result, information about the registration process is provided, and at the end of the result the registration messages are indicated.

  • In the highlighted first line, it is indicated that this router is registered in the console and debug messages are included. This actually means that all debug level messages, as well as any lower level messages (such as notification level messages), are logged in the console. The result also indicates that 32 of these messages were recorded.
  • In the second highlighted line, it is indicated that this router is registered in an internal buffer. Since registration on an internal buffer was enabled on this router, the show logging command also indicates the messages in that buffer.

ROUTER AND SWITCH COMMANDS FOR SYSLOG CLIENTS

There are three steps to configure the router to send system messages to a syslog server where they can be stored, filtered and analyzed:

  • Step 1 . Configure the name of the destination host or the IP address of the syslog server in global configuration mode:

R1 (config) # logging 192.168.1.3

  • Step 2 . Control the messages that are sent to the syslog server with the global configuration mode logging trap level command . For example, to limit messages to levels 4 and below (0 to 4), use one of two equivalent commands:

R1 (config) # logging trap 4
R1 (config) # logging trap warning

  • Step 3 . Optionally, configure the source interface with the global configuration mode command:

logging source-interface  interface-type interface number
This specifies that syslog packets include the IPv4 or IPv6 address of a specific interface, regardless of the interface the packet uses to exit the router. For example, to set the source interface to g0 / 0, use the following command:

R1 (config) # logging source-interface g0 / 0

SYSLOG CONFIGURATION EXAMPLE

In Image 8, R1 was configured to send log messages of levels 4 and below to the syslog server at 192.168.1.3. The source interface was established in the G0 / 0 interface. A loopback interface is created, deactivated and reactivated. The result of the console reflects these actions.

The only messages that appear on the syslog server are those with a severity level of 4 or less (more serious). Messages with a severity level of 5 or more (less severe) appear in the result of the router console, but do not appear in the result of the syslog server, because the logging trap command limits the syslog messages that are sent to the syslog server according to severity level.

VERIFICATION OF SYSLOG

You can use the show logging command to view any message that is logged. When the registration buffer is large, it is convenient to use the vertical bar option (|) with the show logging command. The vertical bar option allows the administrator to specifically indicate which messages should be displayed.
For example, by issuing the show logging | include changed state to up , it is ensured that only interface notifications showing " changed state to up " are displayed .
In Image , it is also shown that by issuing the show logging | begin June 12 22:35 shows the contents of the registration buffer that occurred on June 12 or after this date.

Saturday, 9 November 2019

EIGRP MD5 Authentication Configuration

EIGRP MD5 Authentication Configuration

This chapter is about EIGRP MD5 Authentication Configuration on Cisco Router. EIGRP supports authentication of routing protocols using MD5. For better understanding we will share MD5 Authentication examples and Cisco configuration commands for you.

ROUTING PROTOCOL AUTHENTICATION

Network administrators should keep in mind that routers are at the same risk of attacks as devices for end users. Anyone with a packet detector program, such as Wireshark , can read the information that is propagated between the routers. In general, routing systems can be attacked by interrupting peer devices or falsifying routing information.
Peer interruption is the less critical attack of the two, because the routing protocols repair themselves, which makes the interruption only last a little longer than the attack itself. Forgery of routing information is a more subtle attack class that aims at the information that is transported within the routing protocol. The consequences of falsifying routing information are the following:

  • Traffic redirection to create routing loops
  • Traffic redirection for control on an unsecured line
  • Redirect traffic to discard it

One method to protect the routing information of the network is to authenticate the packets of the routing protocol using the message 5 (MD5) synthesis algorithm . MD5 allows routers to compare signatures that should be the same, in order to confirm that they come from a credible origin. The three components of this system are the following:

  • Encryption algorithm, generally public knowledge
  • Key used in the encryption algorithm, a secret shared by routers that authenticate packets
  • Package content

Routing protocols such as RIPv2, EIGRP, OSPF, IS-IS and BGP support various forms of MD5 authentication.

EIGRP CONFIGURATION WITH MD5 AUTHENTICATION

EIGRP message authentication ensures that routers only accept routing messages from other routers that know the same previously shared key. Without configured authentication, if an unauthorized person enters another router with different or conflicting route information, it can damage the routing tables of legitimate routers, which may be accompanied by a DoS attack.
So, when authentication is added to the EIGRP messages that are sent between routers, it prevents someone from adding another router to the network - by the way or by accident - and causing a problem. EIGRP supports authentication of routing protocols using MD5. The configuration of the EIGRP message authentication consists of two steps: the creation of a keychain and a key, and the configuration of the EIGRP authentication to use the keychain and the key.

 STEP 1. CREATE A KEYCHAIN AND A KEY

To function, routing authentication requires a key in a keychain. In order for authentication to be enabled, create a keychain and at least one key.

  • to. In global configuration mode, create the keychain. Although several keys can be configured, this section focuses on the use of a single key.

Router (config) # key chain  name-of-chain

  • b. Specify the key ID. The key ID is the number used to identify an authentication key within a keychain. The key range is from 0 to 2 147 483 647. It is recommended that the key number be the same on all routers in the configuration.

Router (config-keychain) # key  key-id

  • C. Specify the key chain for the key. The key chain is similar to a password. Routers that exchange authentication keys must be configured with the same key chain.

Router (config-keychain-key) # key-string  key-string-text

STEP 2. CONFIGURE EIGRP AUTHENTICATION WITH THE KEYCHAIN AND KEY

Configure EIGRP to perform message authentication with the key defined above. Complete this configuration on all interfaces enabled for EIGRP.

  • to. In global configuration mode, specify the interface on which you will configure EIGRP message authentication.

Router (config) # interface  type number

  • b. Enable EIGRP message authentication. The md5 keyword indicates that the MD5 hash will be used for authentication.

Router (config-if) # ip authentication mode eigrp  as-number md5

  • C. Specify the keychain to be used for authentication. The name-of-chain argument specifies the keychain that was created in step 1.

Router (config-if) # ip authentication key-chain eigrp  as-number name-of-chain
Each key has its own key ID , which is stored locally. The combination of the key ID and the interface associated with the message uniquely identifies the authentication algorithm and the MD5 authentication key in use. The keychain and routing update are processed with the MD5 algorithm to produce a unique signature.

EIGRP AUTHENTICATION EXAMPLE

To authenticate routing updates, all interfaces with EIGRP enabled must be configured to support authentication. In Image, the IPv4 topology and interfaces that have authentication configured are shown.

In 2nd Image, the configuration for router R1 with the EIGRP_KEY keychain and the cisco123 key chain is shown .

Once R1 is configured, the other routers receive authenticated routing updates. Adjacencies are lost until routing protocol authentication is configured in neighbors.

IPV6 EIGRP AUTHENTICATION CONFIGURATION 

The algorithms and the configuration to authenticate EIGRP messages for IPv6 are the same as those corresponding to EIGRP for IPv4. The only difference is that in the commands of the interface configuration mode, ipv6 is used instead of ip .
Router (config-if) # ipv6 authentication mode eigrp  as-number  md5
Router (config-if) # ipv6 authentication key-chain eigrp  as-number name-of-chain
In following Image, the commands for configuring EIGRP authentication for IPv6 on router R1 are shown using the EIGRP_IPV6_KEY keychain and the cisco123 key chain .

Similar configurations are introduced in R2 and R3.

VERIFICATION OF EIGRP AUTHENTICATION

Once EIGRP message authentication is configured on a router, any adjacent neighbor that has not been configured for authentication is no longer an EIGRP neighbor.
For example, when the Serial 0/0/0 interface of R1 was configured with MD5 authentication, but R2 was not yet configured, the following IOS message appeared on R1:
% DUAL-5-NBRCHANGE: EIGRP-IPv4 1: 
Neighbor 172.16.3.2 (Serial0 / 0/0) is 
down: authentication mode changed
When the adjacent Serial 0/0/0 interface is configured on R2, the adjacency is re-established and the following IOS message appears on R1.
% DUAL-5-NBRCHANGE: EIGRP-IPv4 1: 
Neighbor 172.16.3.2 (Serial0 / 0/0) is 
up: new adjacency
Similar messages also appear on R2.
Adjacencies are only formed when both connection devices have authentication configured, as shown in Image.

To verify that the correct EIGRP adjacencies have formed after configuring them for authentication, use the show ip eigrp neighbors command on each router.
In Image, it is shown that the three routers re-established neighbor adjacencies after EIGRP authentication was configured.

Finally, to verify the neighbors of EIGRP neighbors for IPv6, use the show ipv6 eigrp neighbors command .

Sunday, 27 October 2019

OSPF Authentication Types, Configuration & Verification

OSPF Authentication Types, Configuration & Verification

This article is relate to OSPF Authentication Types, Configuration & Verification. OSPF supports three types of authentication: null, simple password authentication and MD5 authentication. OSPF MD5 authentication can be configured globally or by interface. OSPF authentication is for security purpose. There are different types of OSPF authentication.

OSPF Authentication Types 

When neighbor authentication is configured on a router, the router authenticates the origin of each routing update package it receives. This is achieved by exchanging an authentication key (sometimes called " password ") known to both the router that sends the packet and the one that receives it.
To exchange routing update information securely, OSPF authentication must be enabled. OSPF authentication can be none (null), simple or synthesis of message 5 (MD5).
OSPF supports three types of authentication:

  • Null : This is the default method and means that no authentication is used for OSPF.
  • Simple password authentication : it is also known as "authentication with unencrypted text", because the password in the update is sent as unencrypted text over the network.
  • MD5 authentication (MD5 authentication) : This is the most secure and recommended authentication method. MD5 authentication provides greater security, since the password is never exchanged between peers. Instead, it is calculated using the MD5 algorithm. The coincidence of the results authenticates the issuer.


OSPF MD5 Authentication

The following example shows how MD5 authentication is used to authenticate two neighboring OSPF routers.
In Image 1, R1 combines the routing message with the previously shared secret key and calculates the signature with the MD5 algorithm. The signature is also known as " hash value ".

In Image 2, R1 adds the signature to the routing message and sends it to R2.

MD5 does not encrypt the message; Therefore, the content can be read easily.
In Image 3, R2 opens the package, combines the routing message with the previously shared secret key and calculates the signature with the MD5 algorithm.


  • If the signatures match, R2 accepts the routing update.
  • If the signatures do not match, R2 discards the update.

OSPFv3 (OSPF for IPv6) does not include any authentication capabilities of its own . Instead, it relies entirely on IPSec to protect communications between neighbors with the ipv6 ospf authentication ipsec spi command from the interface configuration mode. This is beneficial, as it simplifies the OSPFv3 protocol and standardizes its authentication mechanism.

OSPF MD5 Authentication Configuration

OSPF supports authentication of routing protocols using MD5. MD5 authentication can be enabled globally for all interfaces or for each desired interface.

To enable OSPF MD5 authentication globally, configure the following:
Interface configuration mode command:
ip ospf message-digest-key key md5 password
Router configuration mode command:
area area-id authentication message-digest
This method imposes authentication on all interfaces with OSPF enabled. If an interface is not configured with the ip ospf message-digest-key command , you cannot establish adjacencies with other OSPF neighbors.
To provide more flexibility, interface authentication is now supported. To enable MD5 authentication per interface, configure the following:
Interface configuration mode command:
ip ospf message-digest-key key md5 password
Interface configuration mode command:
ip ospf authentication message-digest
The global OSPF MD5 authentication methods and per interface can be used on the same router. However, the configuration per interface replaces the global configuration. MD5 authentication passwords do not have to be the same in an entire area; however, they have to be the same among neighbors .
For example, suppose that all routers in the illustration converged using OSPF and that routing works correctly. OSPF authentication will be implemented on all routers.

OSPF MD5 Authentication example

In the example in Image 4, we show how to configure R1 to enable OSPF MD5 authentication on all interfaces.

Note that informational messages indicate that the adjacency of OSPF neighbors with R2 and R3 changed to the Down state (inactive), because R2 and R3 have not yet been configured to support MD5 authentication.
As an alternative to the global enable of MD5 authentication, the example in Image 5 shows how to configure R1 to enable OSPF MD5 authentication per interface. Note that, also in this case, the adjacencies of OSPF neighbors changed to the Down state.

Next, OSPF MD5 authentication is enabled globally on R2 and per interface on R3.
R2 (config) # router ospf 10
R2 (config-router) # area 0 authentication message-digest
R2 (config-router) # interface GigabitEthernet 0/0
R2 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R2 (config-if) # interface Serial 0/0/0
R2 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R2 (config-if) # interface Serial 0/0/1
R2 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R2 (config-if) # end
R2 (config) # 
* Apr 8 10: 26: 46.783:% OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0 / 0/0 from LOADING to FULL, Loading Done 
R2 (config) # 
* Apr 8 10: 27: 16,435:% OSPF-5-ADJCHG: Process 10, Nbr 3.3.3.3 on Serial0 / 0/1 from FULL to DOWN, Neighbor Down: Dead timer expired 
R2 #
Informational messages also appear here. The first message is because the neighbor adjacency with R1 was re-established. However, the adjacency with R3 changed to the Down state, because R3 has not yet been configured.
R3 (config) # interface GigabitEthernet 0/0
R3 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R3 (config-if) # ip ospf authentication message-digest
R3 (config-if) # interface Serial 0/0/0
R3 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R3 (config-if) # ip ospf authentication message-digest
R3 (config-if) # interface Serial 0/0/1
R3 (config-if) # ip ospf message-digest-key 1 md5 CISCO-123
R3 (config-if) # ip ospf authentication message-digest
R3 (config-if) # end
R3 # 
* Apr 8 10: 29: 21.859:% OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Serial0 / 0/1 from LOADING to FULL, Loading Done 
R3 (config) # 
* Apr 8 10: 29: 27.315:% OSPF-5-ADJCHG: Process 10, Nbr 1.1.1.1 on Serial0 / 0/0 from LOADING to FULL, Loading Done 
R3 #
After configuring R3, all neighborhood adjacencies were re-established.

Verification of the OSPF MD5 Authentication

To verify that OSPF MD5 authentication is enabled, use the show ip ospf interface command in privileged EXEC mode. By verifying that the routing table is complete, it can be confirmed that the authentication was successful.
In Image, the verification of OSPF MD5 authentication is shown on serial interface 0/0/0 on R1.

In following Image, it is confirmed that the authentication was successful.