Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

Category: Cisco (page 3 of 6)

CCIE Security travel diaries are here

Bonjour à tous , as they say in Brussels (sorry – Bruxelles) .

I started a new blog about preparing/thinking/sweating/labbing for/about/for/in Cisco CCIE Security Lab exam. You are welcome to read it here : ccie-security-blog.com . The first post is titled “Tips on how to fail your CCIE Security Lab exam” and summarizes my first attempt I took in November in Brussels.

Also it inevitable means I will post less and less here , about Checkpoint, so bear with me until I attain this coveted badge, CCIE Security Expert.


Happy New Year everyone!

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

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
control-plane host
service-policy type port-filter input FILTER_CLOSED_PORTS

Before the configuration:

# telnet 444
telnet: connect to address Connection refused

After the configuration:

[root@darkstar ~]# telnet 444
telnet: connect to address 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 ?

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

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:
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

snmp-map in ASA is for passing through traffic only

I don’t know who to blame – me for not being attentive or Cisco documentation for being vague, but when I read about snmp-map inspection that allows you to block selectively by SNMP version I decided it was the way to protect ASA itself from such queries. And only with the help of Netpro forum at Cisco.com did I learn that this feature is designed to inspect the SNMP traffic that passes THROUGH the ASA and not destined to the ASA itself.
So if you want to limit what version of SNMP ASA will use to answer queries , use usual snmp-server host …
For those who do want to block passing through the ASA SNMP of say version 1 and 2c , here is how:

Louvre(config)#   snmp-map no-v1or2-here
deny version 1
deny version 2c

Now define with access-list what traffic to inspect, you may use specific IPs or just general SNMP ports – udp 161 and 162:

Louvre#  sh run access-list no-v3
access-list no-v1or2-here extended permit udp any any eq snmptrap
access-list no-v1or2-here extended permit udp any any eq snmp

Bind ACL to class-map:

Louvre(config)#  class-map snmp-block-v2or1
match access-list no-v1or2-here

Use the class-map in policy map with enabling snmp-map inspection :

Louvre(config)#  policy-map no-snmp-v2or1
class snmp-block-v2or1
inspect snmp no-v1or2-here

And finally apply the policy map on some interface

Louvre(config)#  service-policy no-snmp-v2or1interface outside

ASA 8.2 now speaks SNMP v3 decently

ASA 8.2 speaks SNMP v3 decently
This article is all about SNMP in ASA. ASA has much less configuration options than IOS does, and this is good. Starting version 8.2 ASA supports version 3 of the SNMP protocol which adds new security model to the whole SNMP stack. But first we will start with old fashioned SNMP v2c (c is for ‘community’) . It takes about 15 secs to do it:

snmp-server location “935 Pennsylvania Avenue, NW”
snmp-server contact “Don’t call us we’ll call you”
snmp-server community *****    // Note this community will be used if more specific one isn’t given per host
snmp-server enable traps snmp authentication linkup linkdown coldstart   //specific traps
snmp-server enable    // you enable server
snmp-server listen-port 161   // in case you want to change, who knows …
snmp-server host outside community ****** version 1 udp-port 162     // only now SNMP polling is enabled and to the given host , also version 1 and port 162 on SNMP management ( to send traps
no snmp-server enable traps ipsec start stop    // To disable specific traps

As you already know this setup will exchange community strings in clear text and also no packet is cryptographically authenticated/verified. What a shame for “Adaptive Security Appliance” . The fix is on the way. It is called SNMP v3 and has 3 security levels to choose from:
noAuthNoPriv – packets are neither authenticated nor encrypted . Basically the model used so far by SNMP v1 and v2c – everything clear text.
authNoPriv – packets are authenticated , that is user is sent in clear text but its password is not , (configurable) MD5 or SHA algorithm.
authPriv – the highest level, all SNMP packets are both authenticated using MD5 or SHA and their content is encrypted with DES/3DES/AES (128,196,256) algorithm.
Using the list above let’s configure our ASA for each level .
General steps:

  • Configure snmp-server group for every security level you want to use ;
  • Creatre user for each security level you wan to use and assign it to the snmp-server group of your choice
  • Create usual snmp-server host entry but adding version 3 and username to be used by this host. NOTE You can have only one such command per host but no matter which out of 3 security levels you specify in this command it will allow the other 2 to be used in querying as well


snmp-server group v3-noauth v3 noauth
snmp-server user Jambo v3-noauth v3
snmp-server host outside version 3 Jambo

Querying the ASA:

snmpwalk -v 3 -u Jambo -l noauthnopriv


snmp-server group V3-auth v3 auth
snmp-server user AUTH V3-auth v3 auth md5 12345678

Minimum pass length is 8 , and while ASA seems not to care it is a violation and snmpwalk will complain on pass < 8 and bail out .
snmp-server host outside version 3 AUTH

Querying the ASA:

snmpwalk -v 3 -u AUTH -a md5 -A 12345678 -l authnopriv

Here everything will be encrypted.

snmp-server group v3-priv v3 priv
snmp-server user very_secure v3-priv v3 auth md5 12345678 v3-priv v3 auth md5 12345678 priv aes 128 12345678
snmp-server host outside version 3 very_secure

N.B. To my surprise there is no such thing as debug snmp . Actually it does exist, but entering this command gives no error and produces no debug either.
Noticed by the way. In logs you can see all the passwords you entered while configuring SNMP, not very secure I would rather say .

(config)# sh log | grep snmp
%ASA-5-111008: User ‘enable_15’ executed the ‘snmp-server user AUTH V3-auth v3 auth md5 12345678’ command.

sla monitor in Cisco ASA land

SLA monitoring is finally here. What is it useful for ? To add/remove dynamically routes in ASA depending on results of the SLA status.
Below is configuration steps but while there are many words in the command itself there are not much options there , so the command is long but pretty uniform.

TokyoASA1(config)# sla monitor 33
TokyoASA1(config-sla-monitor)# type echo protocol ipIcmpEcho int outside type echo
TokyoASA1(config-sla-monitor-echo)# ?
default Set a command to its defaults
exit Exit probe configuration
frequency Frequency of an operation
no Negate a command or set its defaults
num-packets Number of Packets
request-data-size Request data size
threshold Operation threshold in milliseconds
timeout Timeout of an operation
tos Type Of Service
TokyoASA1(config-sla-monitor-echo)# frequency ?
sla-monitor-echo mode commands/options:
<1-604800> Frequency in seconds
TokyoASA1(config)# sla monitor schedule 33 ?
ageout How long to keep this Entry when inactive
life Length of time to execute in seconds
recurring Probe to be scheduled automatically every day
start-time When to start this entry
TokyoASA1(config)# sla monitor schedule 33 life forever start after 00:05:00

Now create tracking process to be later applied to the static route:

TokyoASA1(config)# track 1 rtr 33 reachability

And finally we create static route and attach to it the created track :

TokyoASA1(config)# route outside 0 0 track 1

Now let’s see some statistics on the track:

TokyoASA1# sh track
Track 1
Response Time Reporter 33 reachability
Reachability is Down
1 change, last change 00:04:03
Latest operation return code: Unknown
Tracked by:

The final configuration looks like

sla monitor 33
type echo protocol ipIcmpEcho interface outside
num-packets 3
request-data-size 1500
timeout 30
frequency 5
sla monitor schedule 33 life forever start-time after 00:05:00
TokyoASA1# sh sla monitor configuration
SA Agent, Infrastructure Engine-II
Entry number: 33
Type of operation to perform: echo
Target address:
Interface: outside
Number of packets: 3
Request size (ARR data portion): 1500
Operation timeout (milliseconds): 30
Type Of Service parameters: 0x0
Verify data: No
Operation frequency (seconds): 5
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Enhanced History:
TokyoASA1# sh sla monitor configuration operational-state
Entry number: 33
Modification time: 15:14:04.168 UTC Sun May 23 2010
Number of Octets Used by this Entry: 1480
Number of operations attempted: 48
Number of operations skipped: 0
Current seconds left in Life: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Connection loss occurred: FALSE
Timeout occurred: FALSE
Over thresholds occurred: FALSE
Latest RTT (milliseconds): 1
Latest operation start time: 15:22:59.169 UTC Sun May 23 2010
Latest operation return code: OK
RTT Values:
RTTAvg: 1RTTMin: 1RTTMax: 1
NumOfRTT: 3RTTSum: 3RTTSum2: 3
TokyoASA1# debug sla monitor ?
error Output IP SLA Monitor Error Messages
trace Output IP SLA Monitor Trace Messages
TokyoASA1# debug sla monitor trace
TokyoASA1# IP SLA Monitor(33) Scheduler: Starting an operation
IP SLA Monitor(33) echo operation: Sending an echo operation
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=1 OK
IP SLA Monitor(33) Scheduler: Updating result
IP SLA Monitor(33) Scheduler: Starting an operation
IP SLA Monitor(33) echo operation: Sending an echo operation
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=0 OK
IP SLA Monitor(33) echo operation: RTT=1 OK

And by the way it really works – when track is down the route to which it is attached magically disappeared
from the routing table as should.

Teach ASA to speak NTP

Time is precious, even more when you need accurate logging to know when someone breaks into your systems. Let’s configure NTP time synchronization on our ASA 5510.
Configs are pretty simple, but worth remembering a thing or two.

  • ASA can not be NTP server as opposed to IOS.
  • You can use prefer optional keyword with ntp server command but … it works if you have multiple servers having “the same accuracy” by Cisco.com words. In people’s language they mean the same stratum. If your ASA has 2 servers – one of stratum 2 and other of stratum 3 , even if you put stratum 3 server as preferred the one of stratum 2 will be selected.
  • Authentication is available but oprional. The only algorithm of choice is MD5.
  • You can have multiple trusted keys at the same time, I guess they will be tried in turn (needs verification).

Ok then, back to CLI – NTP server is, use authentication, MD5.

TokyoASA1(config)# ntp authentication-key 1 md5 CISCO
TokyoASA1(config)# ntp trusted-key 1
TokyoASA1(config)# ntp server ?
key Configure peer authentication key
prefer Prefer this peer when possible
source Interface for source address
TokyoASA1(config)# ntp server key 1
TokyoASA1(config)# ntp authenticate
TokyoASA1# debug ntp ?
adjust NTP clock adjustments
authentication NTP authentication
events NTP events
loopfilter NTP loop filter
packets NTP packets
params NTP clock parameters
select NTP clock selection
sync NTP clock synchronization
validity NTP peer clock validity
TokyoASA1# sh ntp stat
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
reference time is cfa3cae4.3dd6a89e (15:40:20.241 UTC Sun Aug 23 2010)
clock offset is -377969342.9594 msec, root delay is 2.04 msec
root dispersion is 15262547.68 msec, peer dispersion is 16000.00 msec
TokyoASA1# sh ntp ass
address ref clock st when poll reach delay offset disp
~ .LOCL. 1 26 64 0 2.0 -37796 16000.
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

Some debug comes next :

TokyoASA1# NTP: Authentication key 1
NTP: reachable
NTP: sync change
NTP: peer stratum change
TokyoASA1# sh ntp stat
Clock is synchronized, stratum 2, reference is
nominal freq is 99.9984 Hz, actual freq is 99.9984 Hz, precision is 2**6
reference time is cf9e06b2.e6239822 (06:41:54.898 UTC Wed May 19 2010)
clock offset is -2.9681 msec, root delay is 1.95 msec
root dispersion is 21.58 msec, peer dispersion is 18.57 msec
Older posts Newer posts

© 2016 yurisk.info

Theme by Anders NorenUp ↑