Login Enhancements

phoeneous

Just some review for myself but thought I'd share. Link to my blog

---

To prevent service disruption from attacks such as Denial of Service or Dictionary Attacks, login enhancements should be used. When DoS detection and login enhancements are used, the router can be customised to act upon attacks and respond by preventing logins after so many failed attempts within a certain amount of time. These failed attempts can also be logged for auditing. More information about login enhancements here.

To enable login enhancements, the first command that must be issued is login block-for attempts <#> within <seconds>

Router(config)#login block-for 180 attempts 3 within 60

With this command, we are telling the router that if there are 3 invalid login attempts within 60 seconds, then block vty logins for 180 seconds. Since we have not configured a quiet-mode acl yet, the only way to access the router is via the console port.

Here we can see an attacker attempted to login to a router but was unsuccesful in 3 attempts within 60 seconds. To prevent any further DoS or Dictionary attacks, the router then blocks vty logins for 180 seconds by going into quiet-mode.

After issuing the login on-failure log command, we can see detailed information about the failed login such as: timestamp, source IP, port, and username used.

From the timestamp we can see that after 180 seconds (00:35:06.75 mark) the router disabled quiet-mode and allowed logins to the vty lines.

But what happens if the router is in quiet-mode for more than 180 seconds? What if the router logins are inaccessible for 60 minutes and your only access is the console port but you are not physically in front of that router? In the topology below, the attacker has logged in unsuccessfully 3 times and the router is in quiet mode for several minutes. Any vty line login attempt made from the Remote Office location would be unsuccessful unless the source IP of that subnet is permitted by the quiet-mode acl. In this topology the source IP would be in the loopback0 interface of 192.168.1.1/24 on the Remote_Office router.

By default, the sl_def_acl is created but as you can see, any source IP to any destination IP will be denied.

Headquarters#sh access-lists

Extended IP access list sl_def_acl
10 deny tcp any any eq telnet log
20 deny tcp any any eq www log
30 deny tcp any any eq 22 log

To circumvent this issue, a new access-list can be created. In this case we will permit any traffic from the Remote_Office router to the vty lines on the Headquarters router when it is in quiet-mode.

Headquarters(config)#ip access-list extended PERMIT_REMOTE_OFFICE

Headquarters(config-ext-nacl)#permit ip 10.100.0.0 0.0.0.3 any
Headquarters(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any

After the quiet-mode acl has been created it will need to be applied with:

Headquarters(config)#login quiet-mode access-class PERMIT_REMOTE_OFFICE

As you can see that even while the router is in quiet-mode due to login enhancement parameters, any traffic permitted by the quiet-mode acl will be permitted on the vty lines. Note the timestamp of when quiet-mode was enabled and shortly after that there was a successful login from the Remote_Office router from user root on source IP 10.100.0.2.

Finally, two other commands useful for troubleshooting are sh login and show login failures.

SteveO86

Excellent post, Great explanations and the screen shots are perfect!

phoeneous

SteveO86 wrote: »

Excellent post, Great explanations and the screen shots are perfect!

Thanks! I'm going to be more active on my blog now especially with our mpls and voice roll out soon. Looks like you and I have similar blogs .

SteveO86

Looks like it, once I get around to customizing my blog a bit more I'll get a link going to your blog in my blog roll.

I look forward to seeing more good information from you! Blogging just makes managing study notes so much easier, along with Evernote.