Category: access control

Do We Need NAC and 802.1x?

Another question I got in my Inbox:

What is your opinion on NAC and 802.1x for wired networks? Is there a better way to solve user access control at layer 2? Or is this a poor man's way to avoid network segmentation and internal network firewalls.

Unless you can trust all users (fat chance) or run a network with no access control (unlikely, unless you’re a coffee shop), you need to authenticate the users anyway.

read more see 5 comments

The Difference between Access Lists and Prefix Lists

A while ago someone asked what the difference between access and prefix lists is on the Network Engineering Stack Exchange web site (a fantastic resource brought to life primarily by sheer persistence of Jeremy Stretch, who had to fight troves of naysayers with somewhat limited insight claiming everything one would want to discuss about networking falls under server administration web site).

The question triggered a lengthy wandering down the memory lane … and here's the history of how the two came into being (and why they are the way they are).

read more see 6 comments

DHCPv6 Prefix Delegation, RADIUS and Shared Usernames

Jernej Horvat sent me the following question:

I know DHCPv6-based prefix delegation should be as stable as possible, so I plan to include the delegated prefix in my RADIUS database. However, for legacy reasons each username can have up to four concurrent PPPoE sessions. How will that work with DHCPv6 IA_PD?

Short answer: worst case, DHCPv6 prefix delegation will be royally broken.

read more see 4 comments

IPv6 End User Authentication on Metro Ethernet

One of the areas where IPv6 sorely lacks feature parity with IPv4 is user authentication and source IP spoofing prevention in large-scale Carrier Ethernet networks. Metro Ethernet switches from numerous vendors offer all the IPv4 features a service provider needs to build a secure and reliable access network where the users can’t intercept other users’ traffic or spoof source IP addresses, and where it’s always possible to identify the end customer from an IPv4 address – a mandatory requirement in many countries. Unfortunately, you won’t find most of these features in those few Metro Ethernet switches that support IPv6.

read more see 14 comments

Last-resort password recovery

Pappyar has sent me an interesting password recovery technique, which can be used in those weird circumstances when you cannot force the router to go to ROMMON (for example, you’ve configured no service password-recovery and the break signal does not work as expected). Unfortunately, his trick works only if you can remove the flash memory from the router (it’s soldered in low-end models):

  1. Turn off the router.
  2. Take out the flash.
  3. Turn on the router.
  4. This time router will take you to ROMMON as it cannot find an IOS image.
  5. Set the configuration register with confreg 0x2142.
  6. Reset (this will change the stored value of the configuration register).
  7. Turn off the router.
  8. Reinsert the flash.
  9. Turn on the router and you are done.
see 10 comments

Using hostnames in IP access lists

When I was configuring the access list that should prevent spammers from misusing my workstations, I obviously had to figure out the IP address of the ISP’s SMTP server (access lists and object groups accept IP addresses). I almost started nslookup on my Linux workstation, but then decided to try entering a hostname in an IOS ACL … and it works. Unfortunately, IOS performs a DNS lookup when you enter the hostname (assuming you have configured the ip name-server) and stores the resulting IP address in the ACL definition:

rtr(config)#ip access-list extended InsideList
rtr(config-ext-nacl)#permit tcp any host smtp.example.com eq smtp
Translating "smtp.example.com"...domain server (192.168.0.1) [OK]
rtr(config-ext-nacl)#do show access-list InsideList
Extended IP access list InsideList
10 permit tcp any host 192.168.2.3 eq smtp

You can enter hostnames in ACLs or network object groups. In both cases, the name is immediately translated into an IP address.

see 6 comments

ACL object groups

I always thought that there was no need to restrict outbound sessions across a firewall in low-security environments. My last encounter with malware has taught me otherwise; sometimes we need to protect the rest of the Internet from our clumsiness. OK, so I decided to install an inbound access-list on the inside interface of my SOHO router that will block all SMTP traffic not sent to a well-known SMTP server (and let the ISP’s SMTP server deal with relay issues).

read more see 5 comments

AAA command authorization gotchas

Once upon a time, AAA command authorization in Cisco IOS queried the TACACS+ server for every single command a user entered. Rules have changed drastically in the meantime (at least for IOS release 12.4):

  • Non-privileged show commands are executed without TACACS+ authorization. Privileged show commands (show running or show archive log config) are still authorized.
  • Some commands that can be executed in non-privileged (aka disable) mode (enable, disable, help, logout) are authorized only if you configure aaa authorization commands 0 methods regardless of the current privilege level.
  • Other commands (for example, ping) are authorized based on the current privilege level.

For example, if you’ve configured AAA command authorization only for privilege level 15, the ping command will be authorized if you’re working in enable mode, but not otherwise.

  • Command authorization is not performed on console unless you’ve configured aaa authorization console.
read more see 6 comments

SSH works without AAA

I was always under impression that you have to configure AAA (even if you have local passwords) if you want to use SSH on a Cisco router. Based on the comment made by shef I tried various options and found out that SSH works without AAA (at least in IOS releases 12.4 and 12.2SRC). In both cases, you can configure AAA authentication (using AAA servers or local passwords) or local username/password authentication (you can also use enhanced password security).
read more see 13 comments

Identifying TACACS+ failure

I've got an interesting question from Colin a while ago:

I would like to generate a different prompt during the login to the router if the TACACS+ server has failed, indicating to the network operators that they have to log-in with the special (local) username, not with the TACACS+ authenticated username/password.

Fortunately he was running TACACS+ which supplies its own prompts during the authentication phase (the solution would not work with RADIUS). If you change the local authentication prompts, you'll get the prompts from TACACS+ server if it's reachable from the router (the AAA authentication is performed via TACACS+ server) and the local prompts if the TACACS+ server has failed (the AAA authentication is performed via any other mechanism). Here's a sample configuration:

aaa new-model
aaa authentication login REMOTE group tacacs+ local
!
aaa authentication fail-message #
Local authentication failed.
#
aaa authentication password-prompt "Enter local password:"
aaa authentication username-prompt "Enter local username:"
!
user a secret b
!
line vty 0 4
login authentication REMOTE




see 11 comments

Change the username/password prompt with AAA

TACACS+ protocol introduced with the IOS AAA architecture had great provisions for customizing the whole login process (user-defined banners, prompts ...). Unfortunately, it never really took off and most AAA solutions deployed today rely on RADIUS servers that cannot control the login process itself (the RADIUS server can only check the username/password pair for validity).

To change the login prompts when using RADIUS servers, use the aaa authentication [banner|fail-message|password-prompt|username-prompt] text configuration command.
read more add comment
Sidebar