Device hardening is usually delivered as a checklist, and a checklist applied wholesale is one of the more reliable ways to cause an outage during a maintenance window. Most items on it are harmless and a few of them change who can reach the device, in ways that are not obvious until the moment somebody needs to.
The items worth the effort fall into three groups. Turning off services the device does not need, which is mostly safe and occasionally removes something a monitoring system depended on. Controlling who may run which command, which is the strongest control available and the one that can lock out every engineer simultaneously. And making the records trustworthy, which is worth nothing on its own and is the only reason any of the rest can be demonstrated afterwards.
This article covers what is actually being hardened and why the planes are separated, which services to disable and which ones bite back, how per-command authorization works and precisely how it locks you out, what makes a device's logs worth presenting to anybody, and how to verify hardening rather than assert it. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
Hardening is almost entirely a management plane exercise, and the control with the greatest effect is also the one with the most dangerous default when the policy server cannot be reached.What Is Actually Being Hardened?
Which part of the device?
The management plane, almost entirely. Hardening reduces who can reach the device, by which protocols, with which credentials, and what they may do once connected. The control plane is protected by rate limiting rather than by hardening, and the data plane — what crosses the device — is a filtering problem belonging somewhere else. Treating all three as one exercise produces a checklist where two thirds of the items are in the wrong document.
A Deeper Dive into the Planes
Why the separation matters operationally
Each plane fails differently and is restored differently. A management plane mistake locks people out and is fixed from the console or not at all. A control plane mistake degrades the device under load and is fixed remotely. A data plane mistake affects users and not the device.
Knowing which plane a change touches tells you what the worst case is before you make it. Every genuinely dangerous item in this article touches the management plane, and the reason is structural: it is the only plane whose failure removes the ability to undo the failure.
The three groups of management plane work
Reduce the surface, by turning off services and restricting who may connect. Control the actions, by deciding what an authenticated user may do. And make the records trustworthy, so that what happened can be established afterwards.
Their value is not equal. Surface reduction is the cheapest and the least effective, because the services being disabled were mostly not reachable anyway. Action control is the most effective and the most dangerous. Records are worth nothing preventively and are the only thing that matters after an incident.
Restricting who may connect
Two mechanisms, and both should be used. An access list on the terminal lines rejects connections from outside the management networks before authentication is attempted. And a management interface declaration, where the platform supports it, restricts which protocols may reach the device at all and on which interface.
The second is stronger because it applies to every service rather than to terminal sessions, and because it operates before the traffic reaches the processes being protected. Where it is available, it is the single highest-value item on any hardening list.
! Only the management networks may attempt a session
R1(config)# ip access-list standard MGMT-HOSTS
R1(config-std-nacl)# permit 10.200.0.0 0.0.0.255
R1(config-std-nacl)# permit 10.201.0.0 0.0.0.255
!
R1(config)# line vty 0 15
R1(config-line)# access-class MGMT-HOSTS in vrf-also
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 10 0
!
! Stronger: restrict which protocols reach the device at all
R1(config)# control-plane host
R1(config-cp-host)# management-interface GigabitEthernet0/0 allow ssh snmp
The transport itself
Version 2 of the secure shell protocol only, a key of adequate length, a modest session timeout and a small retry limit. Connection attempts blocked temporarily after repeated failures, with both failures and successes logged. None of this is controversial and all of it is frequently half-applied.
The item most often missed is restricting the inbound transport on the lines. A device that accepts the unencrypted terminal protocol because nobody removed it is accepting passwords in clear, regardless of how carefully the secure protocol was configured alongside it.
! Generate a key, then restrict the protocol to the secure one
R1(config)# crypto key generate rsa modulus 4096 label SSH-KEY
R1(config)# ip ssh version 2
R1(config)# ip ssh rsa keypair-name SSH-KEY
R1(config)# ip ssh dh min size 2048
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 2
!
! Slow down repeated attempts, and log both outcomes
R1(config)# login block-for 120 attempts 5 within 60
R1(config)# login on-failure log
R1(config)# login on-success log
Credentials stored on the device
Local accounts exist for the fallback path and their passwords are stored in the configuration. The storage format matters: the older reversible encoding is decoration rather than protection, and the modern hash types are genuine. Every local account should use a modern hash, and the enable secret alongside them.
The reversible encoding still appears wherever a value must be recoverable by the device — shared secrets for authentication servers, for example. Those cannot be hashed, which is why the configuration backup repository is part of the security boundary rather than an operational convenience.
! Modern hashes for anything that can be hashed
R1(config)# username breakglass privilege 15 algorithm-type scrypt secret <password>
R1(config)# enable algorithm-type scrypt secret <password>
!
! Check what is actually stored - the number after $ is the type
R1# show running-config | include ^username|^enable
username breakglass privilege 15 secret 9 $9$abc...
enable secret 9 $9$def...
| Plane | Hardened by | Failure looks like | Recovered from |
|---|---|---|---|
| Management | Everything in this article | Nobody can log in | The console, or a site visit |
| Control | Rate limiting | Processor saturated, adjacencies drop | Remotely |
| Data | Filtering, elsewhere | Users affected, device fine | Remotely |
Which Services Should Be Turned Off?
What is on the list?
Services the device does not need and that nothing legitimate uses: source routing, the small diagnostic services, remote configuration loading, name resolution on the command line. Those are safe. Three items are not safe to apply without thought: the on-device web server, which controllers and automation may need; the discovery protocol, which telephony and wireless onboarding depend on; and password recovery, whose removal changes what happens when somebody forgets a password from an inconvenience into an erased configuration.
A Deeper Dive into the Surface
The genuinely safe items
Source routing lets a sender dictate the path, which has no legitimate modern use and is a classic evasion technique. The small diagnostic services answer queries no operational tool uses. Remote configuration loading at boot is a mechanism from a different era. Name resolution on the command line means a typo becomes a hang while the device tries to resolve it as a hostname.
All four can be turned off on every device without checking anything, and their combined security value is small but real. The command-line name resolution item is worth doing for the usability improvement alone.
! Safe on every device, no checking required
R1(config)# no ip source-route
R1(config)# no service pad
R1(config)# no service finger
R1(config)# no ip bootp server
R1(config)# no service config
R1(config)# no ip domain-lookup
!
! Keep sessions from hanging around
R1(config)# service tcp-keepalives-in
R1(config)# service tcp-keepalives-out
The web server, which something may be using
Turning it off is correct where nothing uses it and is a mistake where a controller, an automation platform or a monitoring system talks to the device through it. The safe approach is to restrict rather than disable: keep the secure form, bind it to the management context, and apply an access list so that only the systems that need it can reach it.
Disabling it outright in a network with a controller will break provisioning in ways that take a while to attribute, because the device continues to forward traffic perfectly and only its management relationship is affected.
! Restrict rather than disable, where something uses it
R1(config)# no ip http server
R1(config)# ip http secure-server
R1(config)# ip http access-class ipv4 MGMT-HOSTS
R1(config)# ip http authentication aaa
R1(config)# ip http secure-ciphersuite aes-128-cbc-sha aes-256-cbc-sha
!
! Confirm what is listening
R1# show ip http server status | include status|port|access
The discovery protocol, which is not one decision
Running it across an entire network is an information disclosure at the edge and an operational necessity in the core. It should be disabled per interface on ports facing users and left enabled between infrastructure devices.
The exception is telephony and wireless, where the protocol carries the information that makes onboarding automatic. Disabling it globally on an access switch that serves phones produces devices that power up, get nothing, and appear faulty. Per-interface control is the answer and a global disable is not.
Password recovery, which deserves a decision rather than a tick
Disabling it prevents someone with physical access from bypassing the configuration to gain control. It also means the documented recovery procedure for a forgotten password becomes erasing the configuration entirely, which is a very different conversation with the business.
The decision depends on physical security. In a locked data centre with controlled access, the protection it adds is small and the operational risk it creates is real. In an unstaffed closet in a shared building it is the opposite. Applying it uniformly across both environments means one of them got the wrong answer.
The monitoring protocol
The older versions offer a community string in clear and no integrity protection at all. The current version offers authentication and encryption and should be the only one enabled. Read-only where a read-write capability is not genuinely needed, restricted by access list, and scoped to the views the monitoring system actually reads.
Leaving a read-write community configured because a tool needed it once is common and is a serious finding. Where write access is required, it should be scoped to the specific objects that tool writes.
! Current version only, authenticated and encrypted
R1(config)# snmp-server view MGMT-VIEW iso included
R1(config)# snmp-server group MON-GROUP v3 priv read MGMT-VIEW access MGMT-HOSTS
R1(config)# snmp-server user monitor MON-GROUP v3 auth sha <auth> priv aes 256 <priv>
!
! And confirm nothing from the older versions survived
R1# show running-config | include snmp-server community
R1# show snmp user
How Does Per-Command Authorization Work?
What does it do?
Every command an administrator types is sent to the policy server before it executes, and the server permits or denies it. That is genuinely per-user and per-command, which privilege levels cannot deliver because a privilege level is a property of the device rather than of the person. It is the strongest administrative control available, and its failure mode is that when the server cannot be reached, every command from every session is denied unless a fallback method is configured.
A Deeper Dive into Command Authorization
Why this protocol and not the other
Command authorization requires authorization to be a separate exchange from authentication, occurring repeatedly during a session rather than once at login. The protocol designed for device administration separates the three functions for exactly this reason; the protocol designed for network access combines authentication and authorization into a single exchange and therefore cannot do it.
It also obfuscates the whole packet body rather than the password alone, which matters because the packets now contain every command being run. The obfuscation is not modern encryption and should not be relied on as though it were — the servers still belong on a protected management network — but it is substantially better than sending the commands in clear.
! Servers, group and pinned source
R1(config)# aaa new-model
!
R1(config)# tacacs server TAC-1
R1(config-server-tacacs)# address ipv4 10.200.0.20
R1(config-server-tacacs)# key 7 <per-device-secret>
R1(config-server-tacacs)# timeout 3
!
R1(config)# aaa group server tacacs+ TAC-GROUP
R1(config-sg-tacacs+)# server name TAC-1
R1(config-sg-tacacs+)# server name TAC-2
R1(config-sg-tacacs+)# ip tacacs source-interface Loopback0
The four method lists
Authentication for login. Authorization for the shell, which decides whether a session may start. Authorization for commands at a chosen privilege level, which is the control this section is about. And accounting for those commands, which produces the record. Each is separate and each needs its own fallback.
The command authorization list is the one that matters here and the one whose fallback is most often omitted, because the other three have visible symptoms during testing and this one does not — it works perfectly right up until the server is unreachable.
! Four lists. Note the fallback on every single one.
R1(config)# aaa authentication login VTY-AUTH group TAC-GROUP local
R1(config)# aaa authorization exec VTY-AUTHZ group TAC-GROUP local if-authenticated
R1(config)# aaa authorization commands 15 VTY-CMD group TAC-GROUP if-authenticated
R1(config)# aaa authorization commands 1 VTY-CMD1 group TAC-GROUP if-authenticated
R1(config)# aaa accounting commands 15 default start-stop group TAC-GROUP
!
! Applied to the lines
R1(config)# line vty 0 15
R1(config-line)# login authentication VTY-AUTH
R1(config-line)# authorization exec VTY-AUTHZ
R1(config-line)# authorization commands 15 VTY-CMD
R1(config-line)# authorization commands 1 VTY-CMD1
!
! Console: local only, and no command authorization at all
R1(config)# line con 0
R1(config-line)# login authentication CONSOLE-AUTH
R1(config-line)# authorization exec CONSOLE-AUTHZ
Exactly how it locks you out
Without a fallback method, an unreachable server means no method answers, and a command with no authorization decision is denied. That applies to every command, including the ones that would remove the authorization configuration, and including the ones typed by a session that authenticated successfully moments earlier.
If the same configuration was applied to the console, the device is now unrecoverable by any means short of the password recovery procedure — which, if that was also disabled by an earlier item on the hardening list, means erasing the configuration. Those two items interact and the combination is worth naming explicitly, because each one alone is survivable.
Which levels to authorize
Authorizing at the highest level covers configuration and the commands that change the device. Authorizing at the lowest level as well covers everything else, which produces a complete record and a complete control at the cost of a server exchange per command and a substantial log volume.
Most deployments authorize the highest level only. That is a reasonable position: it controls everything that changes state and leaves diagnostic commands unrestricted. Where a regulatory requirement covers read access as well, both levels are needed and the server capacity planning changes accordingly.
Configuration mode, which is a separate switch
Commands typed in configuration mode are authorized only if a separate setting enables it. A deployment that authorizes commands and omits this one is checking the command that enters configuration mode and nothing typed after it, which is close to no control at all while appearing complete.
This is the most common incomplete implementation of the feature and it is invisible unless somebody specifically tests it by entering configuration mode and running something that policy should deny.
! Without this, nothing typed inside config mode is authorized
R1(config)# aaa authorization config-commands
!
! Test it properly: enter config mode and run something policy denies
R1# configure terminal
R1(config)# ! a command your policy should refuse
R1(config)# hostname SHOULD-BE-DENIED
Command authorization failed.
Designing the policy itself
Permit lists age badly and deny lists leak. The workable middle is a permit list per role built from command prefixes, with an explicit denial at the end, reviewed when the platform's software is upgraded because new commands appear and existing ones are sometimes restructured.
Whatever the shape, it belongs in version control on the server side and it needs an owner. A policy nobody maintains gradually becomes either too permissive to be a control or too restrictive to work, and both outcomes arrive quietly. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
| Control | Granularity | Fallback needed | Console |
|---|---|---|---|
| Login authentication | Per user | Local database | Local only |
| Shell authorization | Per user | If already authenticated | Local only |
| Command authorization | Per user, per command | If already authenticated | Never apply it |
| Config-mode commands | Per user, per command | Same list | Never apply it |
| Command accounting | Per command | Best effort | Safe to apply |
What Makes the Records Worth Anything?
What is required?
Four things together. Timestamps that include the date, sub-second precision and the time zone. A time source the device authenticates, so the timestamps cannot be moved by whoever is being investigated. A record of commands and of configuration changes, generated as they happen. And storage somewhere other than the device, because a record held only on the device under investigation is that device's account of itself. Any one of the four missing substantially reduces the value of the other three.
A Deeper Dive into Trustworthy Records
Timestamps, which are one line and constantly wrong
The default format on many platforms is relative uptime, which is useless for correlating anything with anything. Absolute time with milliseconds and a time zone makes a device's log lines comparable with another device's, with the authentication server's, and with an application's.
Setting the time zone explicitly matters as much as the timestamp format. A network whose devices log in local time without saying which local time produces an incident timeline that is off by hours in a way nobody notices until it matters.
! Absolute, precise, and explicit about the zone
R1(config)# service timestamps log datetime msec localtime show-timezone
R1(config)# service timestamps debug datetime msec localtime show-timezone
R1(config)# clock timezone CST 8 0
!
! What a line looks like afterwards
R1# show logging | include %SYS-5-CONFIG_I
Sep 15 09:41:22.184 CST: %SYS-5-CONFIG_I: Configured from console by alice on vty0
The time source, which must be authenticated
An unauthenticated time source can be impersonated, and moving a device's clock moves every timestamp it produces. That undermines the entire logging effort and it is not a theoretical concern — adjusting the clock is a recognised step in covering tracks.
Authentication is a shared key configured on the device and on the server, with the key marked trusted. It is more work to deploy than most items here because the key has to reach every device, and it is what makes the timestamps evidence rather than assertions.
! An authenticated time source, not just a reachable one
R1(config)# ntp authenticate
R1(config)# ntp authentication-key 1 sha1 <key>
R1(config)# ntp trusted-key 1
R1(config)# ntp server 10.200.0.30 key 1
R1(config)# ntp source Loopback0
!
! Confirm it is synchronised AND authenticated
R1# show ntp associations detail | include configured|authenticated|sane
R1# show ntp status | include synchronized|stratum
The configuration archive
A copy of the configuration taken on every change, with the change logged and attributed. This answers the question every incident review asks — what was different before — and it enables rolling back to a known state without reconstructing it by hand.
Two settings make it useful rather than merely present. Logging the individual commands as they are entered, including who entered them, and sending that log to the central collector as well as keeping it locally. And hiding key material in that log, so that the audit record does not itself become a credential disclosure.
! Archive on every change, log the commands, hide the secrets
R1(config)# archive
R1(config-archive)# path flash:archive/config
R1(config-archive)# maximum 14
R1(config-archive)# write-memory
R1(config-archive)# log config
R1(config-archive-log-cfg)# logging enable
R1(config-archive-log-cfg)# hidekeys
R1(config-archive-log-cfg)# notify syslog contenttype plaintext
!
! What changed, and by whom
R1# show archive log config all
R1# show archive
Off-device storage
Logs held on the device are lost when it reloads, limited by buffer size, and editable by anyone who compromises it. A central collector removes all three problems and is the difference between a record and a recollection.
The destination should be reached over the management network, from a pinned source address so that the collector can attribute the messages reliably, and at a severity that captures configuration and authentication events without drowning the collector in routine noise.
! Off the device, from a stable source, at a useful severity
R1(config)# logging host 10.200.0.40
R1(config)# logging trap informational
R1(config)# logging source-interface Loopback0
R1(config)# logging buffered 65536 informational
R1(config)# no logging console
!
! Is anything actually being sent?
R1# show logging | include Trap logging|Logging to
Rollback, which the archive makes possible
With an archive in place, a bad change can be undone by replacing the running configuration with an earlier version rather than by working out and reversing each line. This is faster and less error-prone than manual reversal, and it is available only if the archive was configured beforehand.
It is worth rehearsing once in a lab, because the mechanism computes and applies a difference and there are changes it cannot cleanly reverse. Knowing which ones before an incident is better than discovering them during one.
show archive log config all shows the key material rather than a placeholder. Fix: enable the option that hides key material in the change log, and treat the already-collected logs as compromised material requiring the affected secrets to be rotated.How Do You Verify Hardening Rather Than Assert It?
What does verification mean here?
Not reading the configuration. Verification means observing the behaviour: attempting a connection from outside the permitted networks and being refused, running a command policy should deny and seeing it denied, making the server unreachable and confirming an engineer can still work, and checking that a log line for each of those attempts arrived at the central collector. A configuration review confirms intent; only the behaviour confirms effect.
A Deeper Dive into Verification
The five behavioural tests
Connect from an address outside the management networks and confirm refusal before any password prompt. Connect from inside and authenticate against the central system. Run a command that policy denies and confirm the denial, in configuration mode as well as at the prompt. Make the servers unreachable and confirm a local login still works and that commands still run. And confirm each of those produced a record at the collector.
These take under an hour per platform and per software version, and they establish facts. Reading the configuration establishes that somebody typed the right lines, which is a different and weaker claim.
! Test 1-2: reachability of the management path
R1# show running-config | section line vty
R1# show ip access-lists MGMT-HOSTS
!
! Test 3: command authorization, including config mode
R1# show running-config | include aaa authorization
!
! Test 4: the fallback, by breaking the path deliberately
R1# show aaa servers | include host|State
!
! Test 5: did the collector receive it?
R1# show logging | include Trap logging
The interaction worth checking specifically
Command authorization without a fallback, plus password recovery disabled, plus command authorization applied to the console. Each of the three is defensible alone. Together they produce a device that cannot be recovered by any means that preserves its configuration.
Checking for the combination is a two-line search across every configuration and it should be part of the estate-wide audit rather than a per-device review. The devices most likely to have it are the ones hardened earliest, by the most thorough engineer, before the interaction was understood.
Drift, and why the first audit finds so much
A hardening standard applied at build time degrades. Devices are added from old templates, settings are changed during incidents and not restored, and software upgrades reset or rename things. The first estate-wide comparison after a hardening project always finds a meaningful proportion of devices that do not match, and the proportion grows every year without one.
A scripted comparison against the standard, run on a schedule, is the only thing that holds it. The output is a per-device difference list, and the value is that it is boring — a finding appears as one line rather than as an incident.
What to check on every device
The terminal line access list is applied and correct. The inbound transport is the secure protocol only. Every method list ends in a fallback. The console is on the local database with no command authorization. Logging has a remote destination and a pinned source. The time source is authenticated and synchronised. The archive is enabled with key material hidden. And no read-write community string from the older monitoring protocol exists.
Eight checks, all scriptable, all returning a clear yes or no. That list is more valuable than a hundred-item checklist because it can actually be run against four hundred devices every week.
! The eight checks, scriptable across the estate
show running-config | include ^ access-class|transport input
show running-config | include aaa authentication|aaa authorization
show running-config | section line con 0
show running-config | include logging host|logging source-interface
show ntp status | include synchronized
show running-config | section ^archive
show running-config | include snmp-server community
show running-config | include ^username|^enable
The devices the project never touched
Every estate contains devices that were not in scope: a switch in a cupboard, a lab router that became production, something commissioned during the project from the previous template. Each still has whatever it was built with, which is usually a shared local password and no central authentication at all.
Finding them is a reconciliation between three lists that will all disagree: the authentication server's device list, the asset inventory, and what actually answers on the management network. The differences are the finding, and this single exercise typically produces more real risk reduction than the entire configuration standard.
What to keep written down
Where the break-glass credentials are and when they were last rotated and tested. Which items on the standard were deliberately not applied, per site, and why — particularly password recovery and the discovery protocol, where the right answer differs by physical environment. And the date each behavioural test was last performed, per platform and software version.
That last one decays fastest. A fallback verified three years and two upgrades ago is not evidence of anything, and recording the date is what makes its staleness visible without anybody having to remember.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers device access control, management plane protection and AAA within its infrastructure security and services domain. What is asked is generally the method list semantics and the difference between privilege levels and per-command authorization, rather than a full hardening build.
| Claim | Configuration review proves | Behavioural test proves |
|---|---|---|
| Only management hosts can connect | A list was applied | A connection is actually refused |
| Commands are authorized | A line exists | A denied command is denied, in config mode too |
| A server outage is survivable | A keyword is present | An engineer can still work |
| Changes are recorded | Archive is configured | The record reached the collector |
| Timestamps are trustworthy | A server is configured | Synchronised and authenticated |
Conclusion
Hardening is a management plane exercise and that is the only plane whose failure removes the ability to undo the failure. Most of the surface reduction list is safe and low value — the services being disabled were largely unreachable already. Three items are not safe to apply from a template: the on-device web server, which a controller may need; the discovery protocol, which telephony and wireless onboarding depend on; and password recovery, whose removal turns a forgotten password into an erased configuration.
Per-command authorization is the strongest administrative control available and the only one that can take every command away from every logged-in engineer simultaneously. It does so by default: with no fallback method, an unreachable server means no command receives a decision and an undecided command is denied. Applied to the console as well, on a device where password recovery was disabled by an earlier item on the same checklist, the result is unrecoverable. Each of those three decisions is defensible alone and the combination is not, which is why the audit should search for the combination rather than review the items.
The records are worth nothing preventively and are the only thing that matters afterwards, and they need four things together: absolute timestamps with a time zone, a time source the device authenticates, a record of commands and configuration changes with key material masked, and storage somewhere other than the device being investigated. And none of it is verified by reading the configuration. Connect from a forbidden address and be refused, run a denied command in configuration mode and see it denied, break the path to the server and confirm an engineer can still work — those establish facts, and a configuration review establishes only that somebody typed the right lines. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 8907 — The TACACS+ Protocol
- RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol
- RFC 5905 — Network Time Protocol Version 4
- RFC 5424 — The Syslog Protocol
- RFC 3414 — User-based Security Model for SNMPv3
- RFC 7454 — BGP Operations and Security
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 8907 documents TACACS+, which runs over TCP port 49 and separates authentication, authorization and accounting into distinct exchanges.
- RFC 8907 describes the authorization exchange occurring per command, which is what allows individual commands to be permitted or denied per user.
- RFC 8907 notes that the obfuscation applied to the packet body is not a modern cryptographic mechanism and recommends that the protocol be carried over a protected network.
- RFC 4253 specifies the SSH transport layer, including the key exchange whose group size determines the strength of the resulting session keys.
- RFC 5905 specifies NTP version 4, including the symmetric key authentication that allows a client to verify the identity of its time source.
- RFC 5424 specifies the syslog protocol, including the timestamp format and the severity levels used to select which messages are forwarded.
- RFC 3414 specifies the user-based security model for SNMPv3, providing authentication and privacy that earlier versions of the protocol do not.
- RFC 1812 requires that routers be capable of disabling the processing of IP source route options, which have no legitimate use in modern networks.
- Cisco documentation describes AAA method lists, in which a method that returns a response ends the evaluation while an unresponsive method causes the next to be tried, and states that a command with no authorization decision is denied.
- Cisco documentation describes the configuration command authorization setting, without which commands entered in configuration mode are not individually authorized.
- Cisco documentation describes the configuration archive and configuration change logging, including the option that masks key material in the recorded commands.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include device access control, management plane protection and AAA within the infrastructure security and services domain.