Top 10 Network Security Mistakes #8: Insecure Admin Access

By Andrew Carlson ·

Putting It Out There

I heard her from clear across the bank lobby, “What was the account number again, Pa? The one with all the money in it?” I assumed Pa would walk over and quietly share the information, but you know what they say about assuming … that’s right, it’s the act of making an assumption.

“I said… 48293209, but make sure you only take out $10,000 this time! Sheesh, must be time to change the batteries in your hearing aids, Ma!” 

I was floored. Not because they were wearing frayed Jethro ropes for belts or smelled vaguely of maple syrup and antifreeze, but because they still had $10,000 left in their account with that clear lack of regard for protecting their critical information.

But you know, I’ve seen many cases where network administrators handle their critical infrastructure in much the same way. Shouting account numbers isn’t much different than failing to lock down administrative channels to your most important resources. 

Let’s make sure your proverbial administrative fly isn’t down, shall we?

Taking It Back

There are several ways admins should protect their critical assets to avoid giving Internet Hooligans a toehold.  Luckily, most of these are relatively easy to implement. There are several different classes of mitigation:

  • Secure the Channel
  • Limit Access
  • Monitor and React

Thankfully, many vendors are finally forcing the issue by removing insecure access channels, but there is plenty of dated equipment with plaintext channels still out there. Some modern vendors have it too. For shame, modern vendors!

Let’s cover each class of mitigation separately:

Secure the Channel

One way or another, you’re going to have to interact with your infrastructure, right?  You might have a thick client, a web GUI or a command line interface. You may even be able to use some amazing form of management telekinesis, but since you’re probably not Uri Geller, let’s stick to the basics for now. 

Plaintext = Bad

I sometimes think this is a foregone conclusion, yet I still see it out there. If your management channels are not encrypted, your credentials and infrastructure details are being sent in the clear.

Think of unencrypted channels like postcards in the mail. Anyone snoopy enough, given the right time and place, can read them. Ensure you are not using telnet or HTTP for management channels. This is exponentially more important if you are managing devices over the Internet. If your device doesn’t support SSH or HTTPS, replace it or start saving up for your early retirement. I hear Enron is selling low. 

SNMP is a common oversight as well. If you don’t need it, disable it. If you do need it, remember that neither SNMP v1 or v2 are encrypted, but v3 is. So, use V3 if possible. If you can’t, remove or at least change your default community strings to a randomly generated, 24-character password. Ensure you limit approved SNMP stations as well. Finally, consider disabling the RW community to avoid granting someone with a sniffer and the ability to spoof an IP the ability to make unapproved changes to your host. 

Letting someone SNMPwalk your host is bad, but giving them full control is…let’s just say, suboptimal. 

Weak Credentials

We covered poor password hygiene in a previous post, so I won’t go into detail here, except to say that the passwords to your network and security infrastructure are among the most valuable in your little universe, so they need to be handled like gold-laying hens. Or a 4-pack of Surly

The best option to secure admin access is to use centralized multi-factor authentication such as OTP. If you can’t use multi-factor, but you have RADIUS or TACACS available, that’s an improvement in some regards, but you must be diligent about turning down old or unused accounts (hint, hint: HR’s job!). 

If you must use static passwords, fertheloveofdog: change your default passwords, ensure that chosen passwords are sufficiently strong, make sure they are securely documented and make sure you update the passwords occasionally, especially after personnel changes. 

Simple math: disgruntled former employee + working passwords = more former employees (who are probably also not gruntled).

Limit Access

This one is so simple, yet so painfully underutilized, all I can do is wonder if there is an affiliate program for leaving doors unlocked that I’m missing out on.

Just because you can ping your host does not mean that you are done configuring it. I know: you sometimes have to make changes while you’re using the laptop of that guy from Shipping, and if you enable the admin ACL, you won’t be able to get in from the dock. 

Tough Love Alert: Burn off four of those french fries you had at lunch by walking back down to your own (hopefully secured) workstation. Or, even better, implement a dedicated management network with a secondary authentication gateway. Whatever you do, just don’t leave 0.0.0.0/0 open to manage your firewalls. Lock it or lose it, Bub (or Bubbette, as the case may be…).

Monitor and React

Do you log unsuccessful login attempts? Most people do. What most people don’t do: watch the logs and respond to them.

If you saw 65,000 unsuccessful attempts to log in from a single IP, would you believe one of your staff forgot their passwords 65,000 times?

Even MC Hammer knows that noise ain’t Legit. 

Block it before they find a zero-day or notice something you didn’t. Miscreants are often encouraged when they detect a lack of attention to detail. But let’s be honest, someone clumsy enough to kick up that many logs is probably not skillful enough to warrant too much concern (unless it is a diversion), so it’s really the Low & Slow attacks you need to be aware of. 

This is where good correlation engines can greatly assist you. If you don’t know where to start, check out Splunk. We also know of a few other good solutions, but none of them start with a price of free like Splunk. Plus, you get to say “Splunk” a lot, which is awesome. 

This next one is just so Mayberry simple, I don’t know why anyone wouldn’t use it. Lack of opportunity is the only good excuse. Bruteforce protection automatically locks admin accounts for a predetermined period of time after a certain number of unsuccessful login attempts. Having to wait 20 minutes to try five more passwords is often enough to discourage any script kiddie, and frankly, if you forget your password five times, I’m pretty sure you won’t cry if you have to get a topper on your coffee (or update your Password Manager) while you wait for the ACL to unlock. No IPS needed, just a good old fashioned dynamically-provisioned ACL based on access log greps. What could be simpler?

Summary

Following some simple rules can help you avoid having an epic V8 moment down the road. Even though securing your administrative access is a thankless job, you can still celebrate a little bit once you’ve locked things down. 

If you do decide to commemorate the moment with a tasty beverage, I might suggest avoiding anything that smells like maple syrup in a 32 oz. big gulp.


Additional Posts