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.

Using CURL to access Openstack

So I'm exploring the API for Openstack to see how I can extract information from an Openstack platform.

I found the examples can be found here.  While the API is located here.

This could be useful as in the future I could script a networking device (Switch, Router, Firewall, etc) to automate and provision services whenever a new tenant is built.

The idea is to self provision itself. For example when a new tenant is created, a switch can access Openstack, find out what network name was configured, which vlan id assigned and a what ip subnet configured.

So the first step is to authenticate to the Openstack Server and retrieve a temporary token.

host1#curl -d '{"auth":{"passwordCredentials":{"username": "admin","password": "mypassword"},"tenantName": "admin"}}' -H "Content-Type: application/js
on" http://x.x.x.x:5000/v2.0/tokens | python -mjson.tool

What comes back is a json response that needs to be parsed.  I piped the python module "python -mjson.tool"  to parse the contents.

What I get in return looks similar to this:

{
    "access": {
        "metadata": {
            "is_admin": 0,
            "roles": [
                "3e2b3771096e4a95b39f3832c19679df"
            ]
        },
        "serviceCatalog": [
            {
                "endpoints": [
                    {

             ....
            }
        ],
 "token": {
            "expires": "2014-07-10T19:31:10Z",
            "id": "14213fjgiod2341vcrt46b9674f",
            "issued_at": "2014-07-09T19:31:10.700433",
            "tenant": {
                "description": "admin tenant",
                "enabled": true,
                "id": "3a10de8a82444118865a6398b336ee68",
                "name": "admin"
            }
        },
        "user": {
            "id": "be246bdf3e01493d8d75bf3938e1bffc",
            "name": "admin",
            "roles": [
                {
                    "name": "admin"
                }
            ],
            "roles_links": [],
            "username": "admin"
        }
    }
}

Now you can see that the token "expires" and this will mean that you will need to request tokens every so often for security purposes.

After this you'll need the token id so you can make further requests.

Next assign your token to a variable.

host1# MyToken=14213fjgiod2341vcrt46b9674f

host1# echo $MyToken
14213fjgiod2341vcrt46b9674f

Then you can use the token to request further information:
host1#curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/networks | python -mjson.tool
{
    "networks": [
        {
            "admin_state_up": true,
            "id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
            "name": "Network1",
            "provider:network_type": "local",
            "provider:physical_network": null,
            "provider:segmentation_id": null,
            "router:external": false,
            "shared": false,
            "status": "ACTIVE",
            "subnets": [
                "d4bf516f-135c-4c7f-ba7e-363cb6c7d307"
            ],
            "tenant_id": "3a10de8a82444118865a6398b336ee68"
        }
}

With this information I can do a get on the subnet:

/v2.0/subnets/​{subnet_id}

 # curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/subnets/d4bf516f-135c-4c7f-ba7e-363cb6c7d307 | python -mjson.tool
{
    "subnet": {
        "allocation_pools": [
            {
                "end": "20.20.0.20",
                "start": "20.20.0.10"
            }
        ],
        "cidr": "20.20.0.0/24",
        "dns_nameservers": [
            "198.6.1.1"
        ],
        "enable_dhcp": true,
        "gateway_ip": "20.20.0.1",
        "host_routes": [],
        "id": "d4bf516f-135c-4c7f-ba7e-363cb6c7d307",
        "ip_version": 4,
        "name": "Network1",
        "network_id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
        "tenant_id": "3a10de8a82444118865a6398b336ee68"
    }
}

So with this information I can basically extract the cidr and  gateway_ip to populate a gateway router.

SDN - Unbundling platforms via Cumulus Networks

I went to a Meetup the other night and saw a presentation by JR Rivers (Co-founder) of Cumulus Networks.

He had an interesting point that most Enterprise networks have hardware that run a single OS. For instance a customer Data Center will run Cisco hardware running Cisco IOS. As it is, the Network Admin is stuck using that vendor and cannot move to another vendor without a forklift upgrade.

Who wants to reconnect links?

JR's proposition is to basically take what's currently going on in the server market and redefine the networking industry.

If you don't like your current vendor's OS, then you can re-image the gear and run the Network OS flavor of your choice.

I can see why Cumulus has taken this approach. In order to disrupt an incumbent, you need a way to remove them from the environment without disrupting the environment.

I can see this working on whitebox gear, but not really much on incumbent gear. A question from the audience was raised, who does the support? JR said that they would support software related issues. But what happens if Cumulus OS is running on top of a Cisco box? Good luck trying to call Cisco. They would automatically void the warranty in a situation like this. The one good thing about having a single vendor environment is that there is support. You know that the vendor will fix their bugs. In this new environment, you're not sure who's going to take responsibility to fix the bug. Also Cumulus is currently only targeting TOR boxes, so this unbundling of platforms will currently only happen in the Data Center.

The value that Cumulus adds is that their OS is Linux. With Linux, DevOps is very familiar with this OS and can program both the APP and the network, hence the SDN part. If Cisco doesn't have a feature in IOS that you need, as a customer you have to ask for a feature request, give your SE a dollar value tied to this feature and then wait x months for the new version to come out. Of course that software upgrade costs money.

As a Demo, JR showed us a BASH script that solved a problem. His point, he created the feature himself. It didn't cost him any money or require him to upgrade his OS.

Now for some vendors like Cisco you could do scripting off box using screen scrapes. But other vendors already have this capability. For instance, Arista has Python built into their OS, so JR's value add doesn't really hold a lot of weight. Juniper has a scripting language called SLAX which is based on XML/XLST.

A problem I see is that the OS is Linux and Security is a big problem. The reason why some vendors don't want to open up a scripting language on their box is because of this very reason. If a hacker is able to take control of your OS, they could create malicious code to do all sorts of things. I wouldn't want to be the Network Admin who has to figure out why their network is all of a sudden DDOSing their own servers and other networks. Which is why Juniper removed Perl from their early implementation of Junos and also why they support SLAX which basically prevents users from messing around with the kernel.

An audience member asked about JR's take on OpenFlow.  He was mostly against this. His response was that there would be lots of problems getting all the vendors to support this. This is an incorrect assumption. Networking vendors always update their OSes to support new protocols. As a vendor, you have to adapt to new things or you die.

I believe JR's reluctance is the threat OpenFlow can create. A SDN controller using OpenFlow can basically take the brains out of a switch. If you have 100 switches, you basically have 100 OSes,  a separate OS running on each switch. With Openflow, you can theoretically control all 100 switches with a single SDN controller and not rely on the underlying OS to do the decision making. Program the whole network, not just each individual switch.

While Cumulus does make an interesting point in unbundling platforms, SDN using a controller that is able to program your whole network is way more interesting.