yurisk.info » IOS Cisco

Archive IOS running configuration automatically for possible rollback

Yuri — Fri, 23 Sep 2011 18:56:22 +0000

Here is a feature that will save you time and frustration in many possible scenarios – especially when managing Cisco routers in multi-user environment. Once enabled archiving saves periodically copy of the running configuration of IOS router to the flash or remote server. So
next time something stops working after changes and you don’t know which one caused this – just revert back to the working configuration that is readily available.

Encrypting preshared keys stored on the cisco IOS router

Yuri — Fri, 15 Jul 2011 08:37:19 +0000

You never know where your router may end up . It may be RMA’ed without proper wiping the configuration first, it may be plain simple stolen. In any of these or other unfortunate cases the last thing you would want is for the attacker get passwords or other security information stored on the router.
One piece of such information is preshared key(s) , that by default are stored in clear text.
To address this potential threat Cisco, starting IOS 12.3, provide AES encryption feature on IOS routers to encrypt the stored preshared keys. In video below I recorded you can see the walkthrough to enable and manage this security feature.
Enjoy. As always suggestions, critics, comments are welcome .
NB – Narration is in English.

Cisco – how to schedule an unattended reload with EEM

Yuri — Wed, 22 Jun 2011 18:34:06 +0000

Good evening everyone,
Today a colleague of mine asked if I had a ready-to-use template to schedule a reload of Cisco IOS router .
- “Of course, piece of cake, there should be millions of hits on it in Google” , was my thought. So, after 30 minutes of searching the mighty G and being surprised to have found nothing I dragged from my notes this recipe dated 2007 but still valid as ever.
Enjoy.
NB Word of warning to those trying to do it with built in KRON service of IOS – rebooting a router requires to answer “yes” at the CLI prompt and therefore will NOT work with KRON, only EEM can do it.
IOS used and tested – IOS 12.4T

conf t
Edge(config)#event manager applet ReloadMe
Edge(config-applet)#event timer cron name ReloadMe cron-entry “05 09 * * *”
Edge(config-applet)#action 33 reload
wr mem

This will reload router every day at 09:05, for other formats see man page for cron in Linux

sh run
….
event manager applet ReloadMe
event timer cron name ReloadMe cron-entry “05 09 * * *”
action 33 reload

Cisco Netflow performance data

Yuri — Sun, 13 Mar 2011 10:45:06 +0000

Not much of a post but link to the Cisco site stating how much Netflow loads the Cisco routers:
Netflow data sheet
I, personally, do a lot of Netflow monitoring and can say that on unloaded routers , passing 2-5 mbits/sec of traffic, the additional load will be some 1-2% of CPU cycles. For the most loaded pair of routers I do monitoring for , two Cisco 2800 passing about 70 Mbits/sec of traffic and creating about 900 Mbytes of Netflow data a day each, enabling Netflow added 8% of CPU load and they cope with it perfectly well.

My Amazon book list for CCIE Security Lab exam

Yuri — Fri, 18 Feb 2011 11:24:40 +0000

Not limited to CCIE Security Lab only, of course, here is the list of books I find really useful in preparing for the Lab .
Amazon Listmania list

The easiest way to disclose Cisco routers on the network and how to fix it

Yuri — Fri, 29 Oct 2010 15:43:10 +0000

Cisco gear has a well-known behaviour pattern that when you telnet to some weird and positively closed port on Cisco you get the uniform response of “Connection refused” . To add more precision it happens when a terminal line management access is enabled on the Cisco but your IP is not in the access-list allowing access to the device. The funny thing about that is that only Cisco seem to do it , and given so, it makes exposing a Cisco device a no-brainer. I tested it on few dozens of Cisco routers (I don’t talk about other equipment from the Golden Gate folks) and it only confirmed this observation. Also I tested telnetting to the other vendors’ equipment and always got back time out. So far I’ve tried Juniper, Brocade, IBM, Huawei. To somehow fix this situation Cisco actually have a feature in their Control Plane Protection toolbox just for that. Below I bring the configuration from IOS router that causes the router to time out connection attempts to the closed ports.

class-map type port-filter match-any CLOSED_PORTS
match closed-ports
policy-map type port-filter FILTER_CLOSED_PORTS
class CLOSED_PORTS
drop
control-plane host
service-policy type port-filter input FILTER_CLOSED_PORTS

Testing.
Before the configuration:

# telnet 19.6.24.51 444
Trying 19.6.24.51…
telnet: connect to address 19.6.24.51: Connection refused

After the configuration:

[root@darkstar ~]# telnet 19.6.24.51 444
Trying 19.6.24.51…
telnet: connect to address 19.6.24.51: Connection timed out
telnet: Unable to connect to remote host: Connection timed out

NB Unfortunately it is a half-solution cause if telnet access is enabled on the Cisco then connection attempts to the port 23 will elicit the same “Connection refused” . To close even this disclosure hole , disable telnet as the management protocol and switch to SSH.
NB2 The good news for the pentesters out there is that rare ISP implement such protections

How come assigning VPN user to specific group takes just one command but no one does it ?

Yuri — Mon, 04 Oct 2010 10:36:29 +0000

Group locking, as Cisco call it, has been available since ancient IOS 12.2(13)T (circa 2003) and still – most of the set ups I see of clients’ VPN servers at most use different VPN groups for different privilege access requirements and blissfully ignore the fact that all it takes to get more enabled access is to know the pre-shared key of the other VPN group. And believe me – it is not that hard when group pre-share key (PSK) is known to half of the company. So if you happen to stumble on this post bear with me and let’s fast forward from accepted practices of 90’s to 2010.
Below are possible ways to lock users connecting to Cisco device (IOS router and ASA to be precise) to predefined VPN groups and do it forcefully so that even if the end user knows the PSK of other VPN group(s) she won’t be able to connect with it.

Case 1. Cisco IOS router acting as Ezvpn server , users are authenticated locally by the router. Let’s name it – group is JUNIPER , and the local user is John.Chambers and we want to confine this user to this group for ever.
Enable group locking for specific group (don’t forget to do the same for all VPN groups)

R1(config)#crypto isakmp client configuration group JUNIPER
R1(config-isakmp-group)#group-lock

Now restrict user to be able to use this group only. For that you have to reconfigure user to look like username followed by delimeter (that can be any of @, %, /, \) and then group name , to be concrete

R1(config)#username John.Chambers@JUNIPER secret Idontworkforsalaryanymore

from now on user John.Chambers will be able to authenticate with Cisco only using John.Chambers@JUNIPER . It overrides any user for VPN connection that already exists, that is if there is already user John.Chambers it will not be able to connect with the group JUNIPER . On the other hand anyone getting PSK of the VPN group JUNIPER will fail authentication if the user is not explicitly reconfigured in the new format.
Case 2 . Cisco IOS router users are authenticated using external Radius server. Unlike local authentication, with Radius you create the user as usual – John.Chambers but then assign it in the Settings cisco-av-pair attribute called user-vpn-group, like this:
ipsec:user-vpn-group=JUNIPER
Case 3.ASA Local username authentication.
No fancy username/group configuration here, you just lock username to a group under general attributes of the user.

ASA1(config)# username John.Chambers password Idontworkforsalaryanymore
ASA1(config)# username John.Chambers attributes
ASA1(config-username)# group-lock value JUNIPER

Case 4. ASA Radius authentication .
Here also the VPn group is forced for the user settings using the following attribute:
[3076\085] Tunnel-Group-Lock JUNIPER

Difference between ebgp-multihop and ttl-security.

Yuri — Fri, 26 Feb 2010 18:39:12 +0000

Once upon a time reading some CCIE paper at work I asked myself a question : “Why would someone bother to invent ttl-security and even write RFC http://tools.ietf.org/html/rfc5082 on it when multi-hop EBGP feature provides the same end result ?” .
The results of my busy/doing-nothing activity I present here.
First some background. For some (unknown to me) reasons BGP peering was envisioned as TCP connection between directly connected routers, by default. To proceed with this design (worth checking BGP RFCs if it was actually an obligation) vendors (Cisco,Juniper and even Fortinet) implemented all BGP protocol communication using TTL=1 in TCP packets being exchanged. As the logical consequence of this if a router was placed more than 1 hop away from its peer BGP session could not be established. To provide for such set ups when peers are many hops away the ebgp-multihop term was coined – on configuration level you can specify that BGP peer is that hops far away .
What happens in fact is that when you specify such multi-hop BGP peer the router starts sending BGP packets with TTL being equal to the number of hops you set . That means if I set peer to be 3 hops away and some attacker tries to spoof legit peer’s IP but is 4 hops away – such attack won’t succeed cause my router will receive spoofed BGP packets ok but will send replies with TTL of 3 which will expire just 1 hop away from the attacker.
Questionable , but security . So why ttl security?
This feature indeed enforces that BGP peer is no more than given hops away . And here comes the difference – it enforces it inbound . It works this way – after you enable ttl security on the BGP peer session and specify how many hops away this peer is allowed to be, your router
checks incoming TCP packets from this peer and does this simple calculation ; configured value <= 255 – hops-away-to-peer , if it holds true your router goes on with establishing BGP session , if not – session is shut down. Regarding outgoing TTL values – may be it is Cisco-only thing, may be not , but the moment you enable ttl security for some BGP peer on Cisco the router itself starts sending BGP-related packets to this peer with initial ttl being equal to 255. I guess it is logical that if you enforce on your side ttl security the peering side will want to do the same.

When ttl rule is broken we see in the debug session:
Dec 27 19:08:04.103: %BGP-4-INCORRECT_TTL: Discarded message with TTL 1 from 124.2.11.15
And neighbor status is:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
124.2.11.15 4 13462 33 63 0 0 0 00:04:31 Idle

#sh ip bgp neighbors 124.2.11.15
BGP neighbor is 124.2.11.15, remote AS 13462, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Closing

Capture packets at IOS Cisco router or finally we have a sniffer

Yuri — Mon, 01 Feb 2010 07:33:06 +0000

Finally it is here – built-in sniffer on the Cisco IOS platform ! Starting IOS 12.4(20) release Cisco introduces brand new feature
called Embedded Packet Capture (EPC) that allows us to capture raw packets on the Cisco router and then later analyze it offline.
It can capture any traffic passing through the router, destined to it, or originated from it . The captured packets are stored in DRAM
of the router from where you can upload the capture file using HTTP/SCP/HTTPS/TFTP/FTP anywhere and then dissect it. The capture
is stored using PCAP format , so any protocol dissector will understand this file, including the favorite one WIreshark/Ethereal.
Now some limitations:
– CEF has to be enabled on the router;
– The capture is stored in the DRAM , so you’d better have enough of it;
– While no maximum capture buffer or packet size is stated I guess it depends on the platform (see tests below);
– IOS has to be 12.4(20) or higher.
Let’s now look at steps to configure the capture on the router and then look at the results.
Configuration involves 5 steps:

Create named capture buffer in router memory (including filters what to capture and what not to). Multiple buffers simultaneously are supported;
Create named capture point , again, multiple capture points active at the same time are possible. Using multiple capture buffers and capture points gives us full flexibility in the process – I can say capture packets at the same time inbound on incoming interface and
store it to the memory buffer A while the same traffic going outbound on outgoing interface capture to another buffer B and have this
way capture of the same traffic at 2 distinct points on the router. Your imagination is the limit here.
Associate capture buffers with capture points;
Start/stop capture;
Export captured packets as PCAP file elsewhere or see it in raw format on the router itself (in case binary is your first language).

Now I will walk through configuring,all this is being done on Cisco 2821 (250 Mb of DRAM). IOS is being Cisco IOS Software, 2800 Software (C2800NM-IPBASEK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)
1) Create named capture buffer in memory. Packets are stored there, as this is DRAM storage if router does restart all capture data will be lost. You also specify filter for which packets are to be captured , if none given it will capture ALL packets at the
capture point. Not surprisingly for filtering you use access-lists, standard or extended, named or numbered.

In my testing I am trying to capture all SMTP traffic passing through the interface Giga0/1. Accordingly the ACL for it will be:

Eldorado(config)#ip access-list extended MAIL_TEST
Eldorado (config-ext-nacl)# permit tcp any any eq smtp

Now I create capture buffer in the memory:

Eldorado #monitor capture buffer MAIL filter access-list MAIL_TEST

NOTE: Fo the particular platform (cisco 2821) the limits and defaults for the buffer are these:

Eldorado#monitor capture buffer MAIL size ?
<1-5127gt; Buffer size in Kbytes : 512K or less (default is 256K)

NOTE 2: In Cisco.com documentation this and other commands related to capture have options that trying to use them gave error.
For example Command reference gives option to configure length of the packet to be captured (instead of default 68 bytes) :

Eldorado #monitor capture buffer MAIL length
^
% Invalid input detected at ‘^’ marker.

2) Creating capture point (i.e. where to capture packets on the router):

Eldorado# monitor capture point ip cef GIGA GigabitEthernet0/1 both

Here I specify interface GigabitEthernet0/1 as point of capture and also set that traffic is to be captured in both directions (or you can use in/out instead)

3) Associate capture buffer with capture point (it does not start capture yet):

Eldorado#monitor capture point associate GIGA MAIL

4) Start capturing packets:

Eldorado#monitor capture point start GIGA

4.1)Stop capture (optional) , you can export capture in the next step without stopping it:

Eldorado# monitor capture point stop GIGA

5) Export captured packets as file to external server , here I use SCP as protocol:

Eldorado#monitor capture buffer MAIL export scp://rumba@216.163.142.1:/capture.cap
Writing capture.cap
Password:
Sink: C0644 309346 capture.cap
!!
Eldorado#

- Now you can see the capture file with Wireshark .
There is it to it.

Verifying.
– To see parameters of the capture:

Eldorado#show monitor capture buffer all parameters

 Capture buffer size (linear buffer)
Buffer Size : 262144 bytes, Max Element Size : 68 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Configuration:
monitor capture buffer siz
Capture buffer MAIL (circular buffer)
Buffer Size : 512000 bytes, Max Element Size : 1024 bytes, Packets : 363
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : GIGA, Status : Inactive
Configuration:
monitor capture buffer MAIL size 500 max-size 1024 circular
monitor capture point associate GIGA MAIL
monitor capture buffer MAIL filter access-list MAIL_TEST
Eldorado#

- Seeing contents of the captured packets on the router :

# show monitor capture buffer MAIL dump

08:18:59.995 UTC Jan 25 2010 : IPv4 LES CEF    : Gi0/1 None

45514C50:                            002414F7              .$.w
45514C60: 2723001F 9E4cd37F 03e4cda dd379aaa  'A...F&...E..0W.
45514C70: dd379aaa dd379aaa  dd379aaa dd379aaa @.-.Eב#X.3,,.M%
45514C80: 03e4cda 03e4cda 03e4cda  03e4cda  ../..&....s@yh
45514C90: 00000204 23ee3444 000000             .....d.....

08:19:00.699 UTC Jan 25 2010 : IPv4 LES CEF    : Gi0/1 None

45514C50:                            002414F7              .$.w
45514C60: 03e4cda 03e4cda 03e4cda 03e4cda 'A...F&...E..KYj
45514C70: 03e4cda 03e4cda 03e4cda 03e4cda @.-.#4$f.%%
45514C80: 03e4cda 03e4cda 03e4cda 03e4cda../..'|S^^^0])
45514C90: 03e4cda 03e4cda 03e4cda 03e4cda..EHLO smtp02.bi
45514CA0: 03e4cda 03e4cda 03e4cda 03e4cda s.eu.blackberry.
45514CB0: 636F6D0D 0A00                        com...

Cisco log: Missing cef table for tableid 65535 during CEF samecable event

Chen — Thu, 21 Jan 2010 10:39:19 +0000

Today I’ve noticed some strange error on my Cisco 1841 router :

%FIB-4-FIBCBLK: Missing cef table for tableid 65535 during CEF samecable event

After searching the net, i’ve found some Cisco bug that describes this.
“FIB-4-FIBCBLK errors with dns view
Symptoms

Message “%FIB-4-FIBCBLK: Missing cef table for tableid 65535 during CEF samecable event” displayed on the console logs.

Conditions

The message seems to be generated anytime a dns request is made to the router where the router then has to use the dns forwarder

Workaround
No workaround”
(Source)

This happens when you have DNS server on the device and it needs to grab the answer from the device configured DNS server (A.K.A DNS Forwarder), and each request will cause this error log.

According to Cisco, the affected device list does not include my MD release – 12.4(25b), however i do see it . (List)

List of IOS with the Fix :
12.2(33)XNE
12.4(24.6)T1
12.4(15)T9
12.2(32.8.11)SR183
12.2(32.8.1)REC186
12.4(20)T3
12.2(33.1.3)MCP5
15.0(1)M
12.4(24)T1
12.2(32.8.1)REE186
12.4(22)T2
12.4(22)MDA1
12.4(24)YG
12.4(24)GC1
12.4(22)XR
12.4(24)MD
12.4(22)YE2