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.
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.
