ASA/PIX: Cut-thru authentication/authorization with RADIUS

Cut-thru authentication provides an added layer of security and a central point to manage access-lists, the ACS in this case.

First, create a "downloadable IP ACL" within the ACS framework.
Shared Profile Components -> Downloadable IP ACLs -> Add (ACL and ACE's)

Next, associate this ACL with an ACS user or group. Note that you might have to modify "Interface Configuration" and "Advanced Options" to make "downloadable ACLs" appear in the user definition pages.

Now, on the ASA:

First create an access-list to define interesting traffic:
access-list redzone permit tcp any any eq telnet

Next permit access to either the appliance's virtual telnet addresses or at least one inside target host via telnet in the access-list applied on the outside interface:
access-list outside_in permit tcp any host 10.35.0.252 eq telnet

Next, configure AAA authentication:
aaa authentication match redzone outside myRadiusServer

Note that you should configure your RADIUS server:
aaa-server myRaidiusServer protocol radius
aaa-server myRadiusServer (outside) host H.O.S.T key secret

You can also configure local authentication with the appliance:
virtual telnet h.0.s.t

Remember to allow telnet access to the this virtual telnet IP address via the outside_in access-list.

Once the user is authenticated, you can verify by:
show uauth
show access-lists

You will see the temporary ACL in the output of the show command. Note that no "authorization" configuration was necessary when using RADIUS (contrast with the post that describes TACACS+ authentication and authorizaton).

Smart filtering with SNMP v3

SNMP version 3 provides the wonderful benefits of strong authentication, privacy and tight control of what information you allow the device to reveal. With Cisco IOS 12.4T, the configuration tasks are quite simple:

First, define a "view" thusly:
snmp-server view NOC interfaces included

You can exclude specific interfaces. For example, "26" represents "Gi0/0.500" interface and you want to exclude it entirely:
snnp-server view NOC ifEntry.*.26 excluded

Note the "*" which is a wildcard to exclude all elements for ifIndex 26. This of course can be more specific to limit exactly the elements you choose to hide. Or you can very specific and only allow access to certain interfaces only.

Next, configure a SNMP group:
snmp-server group NOC v3 auth read NOC

Finally configure the user:
snmp-server user noc NOC v3 auth md5 soeasytosee

Or you can take a step further and enable privacy with DES as follows:
snmp-server user noc NOC v3 auth md4 soeasytosee priv des hidemeplease

You can test with "snmpwalk"
snmpwalk -v3 -aMD5 -Asoeasytosee -unoc -lauthNopriv host.ip.address

When privacy is enabled:
snmpwalk -v3 -unoc -aMD5 -Asoeasytosee -xDES -Xhidemeplease -lauthpriv host.ip.address

ASA: AAA authorization with TACACS+

I have to admit, this was a tricky one! I have scoured the web for sometime now in an effort to accomplish AAA authorization, but using TACACS. While "downloadables ACLs" with RADIUS accomplish this and more relatively easily, getting TACACS to authorize is a bit more obscure.

access-list redzone permit tcp any host 10.35.0.0 255.255.255.0 eq telnet
access-list redzone permit tcp any host 10.35.0.0.0 255.255.255.0 eq http

aaa-server taca1 protocol tacacs
aaa-server taca1 (outside) host 172.30.3.100
key xxxx

aaa authentication match redzone outside taca1
aaa authorization match redzone outside taca1

Now for the interesting part:

On the ACS server, create a user and assign a "shell command authorization set" which specifes, for example here:

command: telnet
arg: permit 10.35.0.100

command: http
arg: permit 10.35.0.100

Please make sure you use the regular "shell command authorization and not the PIX/IOS set.

ASA's address in traceroute

Have you wondered how you'd go about making the firewall show up in a traceroute command?
R1#trace 172.30.3.53
Type escape sequence to abort.Tracing the route to 172.30.3.53
1 fa-0-1-r5 (10.4.1.1) 4 msec * 0 msec 2 * fa-0-0-r5 (10.7.1.2) 4 msec * 3 10.25.4.1 0 msec * 0 msec 4 * 150.10.1.254 0 msec * 5 172.30.3.53 0 msec * 0 msec
On the ASA or PIx:
policy-map global_policy
class class-default set connection decrement-ttl
After modifying "global_policy" on the ASA or PIX:
R1#trace 172.30.3.53
Type escape sequence to abort.Tracing the route to 172.30.3.53
1 fa-0-1-r5 (10.4.1.1) 0 msec * 0 msec 2 * fa-0-0-r5 (10.7.1.2) 0 msec * 3 10.25.4.1 0 msec * 0 msec 4 * * 150.10.1.1 0 msec 5 * 150.10.1.254 0 msec * 6 172.30.3.53 0 msec * 0 msec

Private VLAN - de-mystified

Ah! I can relate to your frustration with this topic.

Consider the ethernet frame format. The 802.1q tag is a 4 bytes long and is inserted by the network switch between the SA and type/len fields of the ethernet frame.
[DA][SA][4byte-tag][type/len][data][FCS]

Private VLANs are characterized by a single primary VLAN and secondary VLANs ("community" and "isolated").

When a switchport is configured as a pvlan host port, say of the "community" type, all frames that ingress the network are tagged with the community vlan-id. Note that during egress to the host, the switch removes the tag.

The key concept is the upstream filtering capability provided by private vlans. Frames from "community" ports are tagged with their secondary vlan-id upon ingress, and they are only forwarded to other ports in the same community OR promiscuous ports. It gets stricter with "isolated" ports where frames are only forwarded upstream to promiscuous ports. Note that promiscuous ports tag with primary vlan-id.

Lastly, note that promiscuous ports specify a mapping that encompasses the primary VLAN and a list of secondary VLANs. This aspect controls which secondary VLANs are allowed to talk to the host connected to the promiscous port.

For example, you may have a network where users need access to web-servers and email, but guests are only allowed access to web-servers. Here, you can achieve your objectives by configuring a community VLAN each for employees and guests, web-server promiscuous host ports that map the primary to both secondary VLANs, and finally email promiscuous host ports that map the primary to only the employee community.

Private VLANs work in VTP transparent mode only. As long as they are created consistently, and trunked across switches, they can be effective over a multi-switch network. Each switch will enforce the same ingress vlan-id tagging and forwarding logic for upstream traffic.

Role based authorization for IOS using TACACS+

Role base authorization simplifies the enforcement of security controls when used with IOS devices.

The first step involves the configuration of the IOS device.

parser view ccie
secret 5 $1$pcY4$eqZ1i/dKMOS8cPigSQZbm0
commands configure include all router
commands configure include all interface
commands configure include shutdown
commands configure include all no router
commands configure include all no interface
commands configure include no shutdown
commands configure include no
commands exec include all configure terminal
commands exec include all configure
commands exec exclude show ip route
commands exec include show ip interface
commands exec include show ip
commands exec include show privilege
commands exec include show parser view
commands exec include show parser
commands exec include show
commands exec include logout
!

Then we proceed to configure AAA:

aaa new-model
aaa authentication login default local
aaa authentication login iosvpn local
aaa authentication login RAD group radius
aaa authentication login TACA group tacacs+
aaa authentication login EZvpn local
aaa authorization exec RAD group radius
aaa authorization exec TACA group tacacs+
aaa authorization network iosvpn local
aaa authorization network ezVPN local
aaa session-id common
aaa authentication login TACA group tacacs+
aaa authorization exec TACA group tacacs+

ip tacacs source-interface FastEthernet0/0

tacacs-server host 172.30.3.53 tacacs-server key 7 1511080501
line vty 0 3
session-timeout 30
exec-timeout 30 0
authorization exec TACA
login authentication TACA

Finally we configure the ACS server:

Enable "Display window for each service..." under advanced TACACS+ interface configuration.


Next, for the desired user(s) or group(s) check "Shell (exec)" and under "Custom Attributes" type:
shell:cli-view-name=ccie

When you login as a user (or member of a group) with this feature enabled, you will be placed in the appropriate CLI view.

DMVPN - hub to spoke issue

DMVPN brings with it tremendous simplicity whilst providing a scalable and secure connectivity solutions. The configuration of the hub is compact and elegant, while the spokes feature mostly uniform and even more concise commands. An IGP such as OSPF of EIGRP, with the latter being more popular, can be easily configured to overlay a network on top of the NBMA mGRE fabric that DMVPN is built on.

While configuring and experimenting with various versions of DMVPN, I ran into a very interesting issue that is really the crux of this blog entry. Spoke-to-spoke connectivity was no problem but I was not able to ping the networks behind the hub, or ping spoke networks from the hub.

The issue was rooted in the control-plane policing policy applied at the hub. The ICMP rate was limited to 1 packet per second (pps). This apparently is not enough when tunnel interfaces come into the picture as is the case here with DMVPN. Increasing the ICMP threshold to 10 or more packets per second and specifying "burst" value fixed this issue.

vPC configuration on Nexus 7000

vPC or Virtual Port Channels allow multiple links between particpating switches to partcipate in traffic forwarding but they are no longer confined to the same switch like in a traditional port channel.

Ensure you are in the correct VDC

Step 1.

feature vpc

Step 2.

vpc domain 1

Step 3.
Configure vPCpKL - peer keep-alive link.
Note: this is done while under "vpc domain "

peer-keepalive destination

Note that it highly recommended that the keep-alive link be configured using a separate VRF such as the mgmt 0 mechanism.

Step 4:
Create the vPCpL - peer-link
Note: this is done under the interfaces on each switch that are going to participate in the domain.

interface port-channel 20
vpc peer-link

Step 5:

Enable vPC on the unlink/downlink interfaces on particpating switches

vpc

GET - Group Encrypted Transport
Secure Connectivity Simplifed.

Cisco's GDOI interpretation for IOS provides a simple and effective way to protect traffic between networks without the overhead of tedious, repetive manual configuration headaches.

The following example illustrates how a central key server can specify traffic to be encrypted.

Key server configuration:

crypto gdoi group myGDOI
identity number 99
server local
rekey algorithm aes 128
rekey retransmit 10 number 2
rekey authentication mypubkey rsa GET-gdoi-key
rekey transport unicast
authorization address ipv4 GET_list
sa ipsec 1
profile gdoi-profile
match address ipv4 GET_traffic
replay counter window-size 64
address ipv4 10.4.1.2

crypto ipsec profile gdoi-profile
set security-association lifetime seconds 900
set transform-set ccie

Extended IP access list getvpn_traffic
10 permit ip 10.9.1.0 0.0.0.255 192.168.200.0 0.0.0.255
20 permit ip 192.168.200.0 0.0.0.255 10.9.1.0 0.0.0.255