Now I seriously doubt that any serious CCIE Security candidate is going to go into the Lab with the intent on using 'Auto Secure" for a configuration. However, like 'vpnetup' on the ASA, it can be used to quickly jog the memory about something that you might need, or even to create a checklist. So how can this help. Auto secure can be ran without applying it to the configuration. Just start out in privilege exec mode by typing "auto secure". Answer a few questions and when it gets to the end, enter no for "Do you want to apply this to your running configuration". Alternatively, if you want an expensive ($1400) joke in which you won't be present for the punch line (proctor grading an auto-secured router), I suppose you could enter yes. So exactly what does this produce?
c1841#auto secure
--- AutoSecure Configuration ---
*** AutoSecure configuration enhances the security of
the router, but it will not make it absolutely resistant
to all security attacks ***
AutoSecure will modify the configuration of your device.
All configuration changes will be shown. For a detailed
explanation of how the configuration changes enhance security
and any possible side effects, please refer to Cisco.com for
Autosecure documentation.
At any prompt you may enter '?' for help.
Use ctrl-c to abort this session at any prompt.
Gathering information about the router for AutoSecure
Is this router connected to internet? [no]: <<change this to yes to see CBAC
Securing Management plane services...
//Many are disabled anyway, but you don't know //exactly what may have been re-enabled in your lab. Disabling service finger
Disabling service pad
Disabling udp & tcp small servers
Enabling service password encryption
Enabling service tcp-keepalives-in
Enabling service tcp-keepalives-out
Disabling the cdp protocol
Disabling the bootp server
Disabling the http server
Disabling the finger service
Disabling source routing
Disabling gratuitous arp
Is SNMP used to manage the router? [yes/no]: yes <<It would be nice if it would produce an SNMPv3 config
SNMPv1 & SNMPv2c are unsecure, try to use SNMPv3
Enable secret is either not configured or
is the same as enable password
Enter the new enable secret:
Confirm the enable secret :
passwords do not match
Enter the new enable secret:
Confirm the enable secret :
Enter the new enable password:
Confirm the enable password:
Configuring AAA local authentication
Configuring Console, Aux and VTY lines for
local authentication, exec-timeout, and transport
Securing device against Login Attacks
Configure the following parameters
Blocking Period when Login Attack detected: 10
Maximum Login failures with the device: 5
Maximum time period for crossing the failed login attempts: 3
Configure SSH server? [yes]:
Configuring interface specific AutoSecure services
Disabling the following ip services on all interfaces:
//actual syntax of some items we
//might wish to disable on our interfaces
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
Disabling mop on Ethernet interfaces
Securing Forwarding plane services...
Enabling CEF (This might impact the memory requirements for your platform)
Enabling unicast rpf on all interfaces connected
to internet
Configure CBAC Firewall feature? [yes/no]: no
This is the configuration generated:
//actual configuration no service finger
no service pad
no service udp-small-servers
no service tcp-small-servers
service password-encryption
service tcp-keepalives-in
service tcp-keepalives-out
no cdp run
no ip bootp server
no ip http server
no ip finger
no ip source-route
no ip gratuitous-arps
no ip identd
security passwords min-length 6 <<minimum password length security authentication failure rate 10 log <<local auth failure
enable secret 5 $1$2iN.$UDWy8OzU2D2axQ.6igkc10
enable password 7 02050D4808095D
aaa new-model
aaa authentication login local_auth local
line con 0
login authentication local_auth
exec-timeout 5 0
transport output telnet
line aux 0
login authentication local_auth
exec-timeout 10 0
transport output telnet
line vty 0 15
login authentication local_auth
transport input telnet
line tty 1
login authentication local_auth
exec-timeout 15 0
login block-for 10 attempts 5 within 3 <<login block after a failure crypto key generate rsa general-keys modulus 1024
ip ssh time-out 60
ip ssh authentication-retries 2
line vty 0 15
transport input ssh telnet
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
logging facility local2
logging trap debugging
service sequence-numbers << service sequence numbers
logging console critical
logging buffered
interface FastEthernet0/0
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
no mop enabled
interface FastEthernet0/1
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
no mop enabled
interface FastEthernet0/1.1
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
interface Virtual-Access2
no ip redirects
no ip proxy-arp
no ip unreachables
no ip directed-broadcast
no ip mask-reply
ip cef
access-list 100 permit udp any any eq bootpc
!
end
Apply this configuration to running-config? [yes]: no c1841# Now I'm not advocating using auto sec at all. All of the above items we should already be comfortable with. However, if it comes down to the wire and some of the above items are giving you grief after your brain was fried dealing with IPSec, this might be a possibility. These are some "best practice" sort of items. Since the DocCD is focused on configuration, you have to dig around for a few minutes to find many of the above items. If you found this document useful, please share it with your friends. If you have anything to add, please comment below.
|
