Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

Fun with CUPP and Medusa in Kali Linux (Part 3 of 3) - fixedByVonnie

Fun with CUPP and Medusa in Kali Linux (Part 3 of 3)

If you’ve been following my CUPP and Medusa series then you know how to use the Common User Passwords Profiler (CUPP) to create a carefully tuned password list that matches your victim’s personal data.  Furthermore, you know how to use Medusa to crack against that list and then SSH into the compromised resource.

Well today I’ve got to show you two ways to stop this sort of thing from happening.

The easiest tip is to make sure your users are using strong passwords.  The enable account on a Cisco router is analogus to a root user on a Linux box or the Administrator on a PC.  Therefore it’s imperative that the account is fortified with carefully considered controls.

Passwords should never include hobbies, preferences, common names or anything like that.  Even obfuscating words with numbers won’t suffice.  The best approach is to generate a completely random password and to use a password vault to store it.

The first way to harden a router is increase the amount of time it takes to break in.

Blocking Brute Force

Making a brute force attack inconvenient is remarkably easy on a Cisco router.  It only takes three lines of code.

First we need to enter global configuration mode:

config t

Next we need to tell the router three things:

  • How many failed login attempts will we give the attacker?
  • How long should we block access when that failed login threshold is achieved?
  • How quickly should we respond?

This obviously takes some thought because you don’t want to unwittingly preclude your staff from logging into your equipment.

Let’s say we want to give our users three login attempts after which we’ll block access for 10 seconds within a 50 second time interval.

We could type this:

login block-for 10 attempts 3 within 50

This says:

Yo, Mr router, start blocking logins after 3 unsuccessful attempts.  You can block for 10 seconds but this assumes the user entered 3 failed attempts within a 50 second time frame.

You can also turn on logging so you can see what’s happening on the router:

login on-failure log every 10

Let’s configure our router and then try to break in:

Blocking Brute Force

Back on the Kali box, I’ll throw three failed attempts within 50 seconds.

Kali logging in via SSH

Alright so I’m locked out now with a permission denied.

Check out the router log!

Brute Force Logging

You can not only see each failed login attempt and exactly when it happened but we also have the source IP,, which is my Kali box.


As a bonus, you can add a delay, in seconds, between login attempts to slow down the process.

login delay 3

Limit the source IP address

An even better approach is restrict access to a specific source IP address. (or range of approved source IP’s)

Check this out:

Let’s say you want to limit sign in access to a single computer.  The only PC that can SSH into your router is the one with IP address:

We can create an access control list and then apply it to the SSH VTY lines.

ip access-list standard anti-brute

This says we should create a standard access control list and name it anti-brute.  We’ll allow but everything else will be blocked.

Cisco Restrict Source IP

Now we can apply the access-list to the SSH remote lines.

line vty 0 4
access-class anti-brute in

VTY lines are logical connection points to a Cisco device.  So line vty 0 4 is saying we want to enter the configuration mode for the first 5 VTY lines.

But why those four?

Because those are the lines I configured for SSH.

The access-class keyword applies the anti-brute rule we created.

Now look at what happens when I try to sign in from my Kali Box at

SSH blocked


Nice try Mr. hacker.

The Bottom Line

Hackers will inexorably look for new and creative ways to break into networks.  Some are motivated by fame.  Others are galvanized by greed but the bottom line is that malicious hackers can ruin your organization if you’re not prepared.

The sad thing is that most people aren’t prepared.  But you aren’t most people!

Now you know about CUPP.  Now you know about Medusa.  And now you know not only how a hacker can use these tools to break into your systems but also how you can fight them.

If this series helped you, please share in the comments below.  I’m curious who is benefiting from my content!



Connect with Vonnie on Twitter

Posted in Linux Tagged with: , , ,