Category: access control
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.
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).
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.
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.
Some of you might be old enough to know that Cisco IOS supports (or used to support) around 10 different layer-3 protocols (IP being the most popular these days) and each one of them (if it was added to IOS early enough when the parser was still somewhat immature) required its own range of numbered ACL. I’ve summarized all of them in the “IOS Access List numbering scheme” article in the CT3 wiki.
Shahid wrote me an e-mail asking about local command authorization. He would like to perform it within the AAA model, but while AAA local authorization works, it only allows you to specify user privilege level (and autocommand), not individual commands (like you can do on a TACACS+ server).
I had an interesting debate with an engineer who wanted to use TFTP between a router and a server reachable through an outside interface. He realized that he needed to configure (application-level) TFTP packet inspection for router-generated traffic, but unfortunately Cisco IOS does not support this particular combination.
His query prompted me to read the TFTP RFC, which clearly documents that the data packets sent by the server are coming from a different UDP port number (thus the need for application-level inspection). The results of my tests are available in the TFTP server protection with Context-Based Access Control (CBAC) article.
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):
- Turn off the router.
- Take out the flash.
- Turn on the router.
- This time router will take you to ROMMON as it cannot find an IOS image.
- Set the configuration register with confreg 0x2142.
- Reset (this will change the stored value of the configuration register).
- Turn off the router.
- Reinsert the flash.
- Turn on the router and you are done.
A reader sent me an interesting question:
Do you have any advice for resetting/logging into a router (2821) where the one time user of cisco:cisco has already been used?
I couldn't offer any better advice than performing the regular password recovery procedure. Is there another solution?
When I chose the word “unfortunately” in my post describing how Cisco IOS performs DNS lookup when you enter a host name in an access list, I’ve triggered several responses that disagreed with my choice of words. Here’s why I still think IOS ACL could be improved with dynamic DNS lookup:
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.
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).
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.