The behavior of the Root login account on Juniper devices

Due to the number of hacks we've been seeing the past few years, I've decided to concentrate a lot of my future blog posts on Security.

It's imperative to secure any device that has an internet connection, whether it's a router, switch, tablet, smartphone, etc.

This was tested on Juniper routers and MXes and I have not tested this on the SRX.

When you first configure your brand new Juniper Device, you are logged into the unit as the user root with no password. Before you can commit your initial config on the device, it will tell you to set the root password for the system.

You do it like this:

[edit system]root@# set root-authentication plain-text-password New Password: type password hereRetype new password: retype password here
The thing you have to worry about is if you decide to enable ssh on the device, the root account is also allowed to ssh into the device.

services {
    ssh
}

$ ssh -l root 172.16.1.9
root@172.16.1.9's password:
--- JUNOS 11.4R7.5 built 2013-03-01 10:14:08 UTC


root@mx80:RE:0%
root@mx80:RE:0%
root@mx80:RE:0% cli
{master:0}
root@mx80> 

This is dangerous if this device is on the internet. Hackers will always try to brute-force ssh the root login account. I've asked some of my friends/coworkers who know juniper and they did not even know this behavior.

You have to explicitely disable ssh for the root account.

services {
    ssh {
        root-login deny;
    }
}

Juniper should have built this the opposite way and had root-login defaulted to deny.  So the admin knows that they're actually explicitly allowing users to ssh into the device using the root account.

BTW there is a parameter that says root-login allow.

You might wonder why Juniper did this? Well the reason is probably some engineer early in the software development phase did this for convenience.  Then as the code evolved over the years, you couldn't change the "default" behavior as some customer would complain about this change. So now you're stuck with it.

Small snippet of an attacker trying to gain access via ssh.


Jan 23 05:15:25 localhost sshd[8513]: Invalid user ftp from 82.222.9.122
Jan 23 05:15:26 localhost sshd[8517]: Invalid user guest from 82.222.9.122
Jan 23 05:25:17 localhost sshd[8522]: Invalid user root from 82.222.9.122
Jan 23 05:35:17 localhost sshd[8524]: Invalid user info from 82.222.9.122
Jan 23 05:45:14 localhost sshd[8526]: Invalid user jack from 82.222.9.122
Jan 23 05:55:18 localhost sshd[8528]: Invalid user karaf from 82.222.9.122
Jan 23 06:05:15 localhost sshd[8530]: Invalid user log from 82.222.9.122
Jan 23 06:25:03 localhost sshd[8786]: Invalid user nagios from 82.222.9.122
Jan 23 06:34:58 localhost sshd[9071]: Invalid user oracle from 82.222.9.122
Jan 23 06:44:52 localhost sshd[9307]: Invalid user pi from 82.222.9.122
Jan 23 06:54:43 localhost sshd[9483]: Invalid user postgres from 82.222.9.122


Best practice is to deny root-login and setup connection limits and rate limits.

ssh {
root-login deny;
protocol-version v2;
connection-limit 10;
rate-limit 2;
}

Any device on the internet should also have black-lists and white-lists for SSH to prevent malicious attackers from gaining access to your device.

Data Center and Lab best practices

I saw my buddies Mark Honer of VM Ware and Dan Luderville from Gigamon speak at a Mirapath Sponsored Data Center Event. Now while I'm not much of a Data Center Infrastructure technologist specializing on the physical Underlay (Layer 1),  I do like to sit in on events like these to see where the trend is going and what problems these guys are seeing.  Mark is a very funny guy and likes to add humor in his presentations. One of the topics of interest is the Data Center Best Practices. We do these in our lab, so while this may seem common sense, you'd be surprised at how many other labs and data centers I've seen that doesn't.


I'll illustrate a few of them.

1) Use copper and fiber cables with unique serial number and lengths at both ends for tracing connections. Now you don't need serial numbers for inventory purposes. Most cables don't come like this, but Mirapath can do this as part of your order. Saves a lot of time especially when the distance is more than 1 meter. The cool thing is that Mirapath keeps a record of your serial number so when you order more, you don't have to remember where you last left off.

2. Use blanks in spaces were equipment are not installed. First it keeps the airflow going and two it prevents people from using your equipment as a shelf.

3. Using colored cables.

You should standardize around a particular color for each kind of connection.

We use white for our management connections and red for our console connections. Whenever we see some other color connected to the switch, we know someone has thrown in a rouge device and can easily track down who did it.

One of these kids don't look like the other

4. Buy special colored power cables for critical devices. If all your power cables are the same, which usually come in black, someone might pull your critical device from the network because they might not know which cable goes to which device. Now if you have some that are red, then they know not to unplug that device.

We call these the 'your fired' cables. We've had no incidents of accidental pulling of cables when we had these installed.

5. Invest in a nice labeler. You don't know how much time you can save if you just label things correctly. I used to spend many hours having to physically go back and forth between my desk and the rack just to figure out which hardware device I'm trying to find in the lab. If I had a labeler at that time to mark the devices with names, ips and basic information, I wouldn't have wasted my time.

These techniques are good for the small and young companies who are growing. The right best practices can prevent your company into turning into one of these.