So we've got to secure our Juniper router from un-authorised access attempts. There are a couple of ways we can access the device for configuration; console, telnet, SSH, HTTP(s) and NMS to name the main ones. Each of these however *needs* a username and password to permit access before we get in, we need it for authentication.


So lets go ahead and configure a username and password for our router. We've decided to be totally cliche and use the name 'admin' for our administrator account. First we need to get into configuration edit mode by entering the configure keyword from 'exec' mode.

root@R1> configure

Now lets enter the 'system' command tree (which contains the login 'features') by entering:

root@R1# edit system

Now we can add the user:

Screen+shot+2011-05-23+at+21.23.57

Whoa! What went wrong here? Well it's simple really, JunOS saved my arse. The password I chose to input here was 'junos'. Sure it wasn't a very secure password but I figured it was for a demo so who cares? Well JunOS cares. It is very kindly reminding you that the password you put in was poor and didn't pass the restriction guidelines of minimum password length of 6 characters (junos is 5 of course) AND that it didn't contain a mixture of either case, numbers or punctuation. So lets do that again and choose the password JunOS1!

Screen+shot+2011-05-23+at+21.24.42

All good. Now you know what - our company guidelines are more strict than that. We need to have a minimum of 8 characters and we need to also make sure that the new passwords being set have at least 3 characters of difference from the last. That is to say if my current password if PassW0rd! then my new password cannot be PaSSW0rd! because I only changed two of the letters to uppercase.

So lets put in the configuration to get the company policy met:

Screen+shot+2011-05-23+at+21.32.43

OK, so user set, password right, now lets put our user into the right security group. Admin is clearly an administrator and so we'll put that user into the highest security group with the most rights. Note that this command has been entered from the 'top' of the configuration tree rather than from inside the 'system' branch:

Screen+shot+2011-05-23+at+21.40.21

Right now we need to enable the services themselves. Out of the box a fresh JunOS configuration has no services enabled. Lets turn on Telnet and SSH.


Screen+shot+2011-05-23+at+21.22.59

Now we look back at our company security policy and notice that we are told to exclude 'root' user access from SSH enabled devices. We can do this in JunOS...well done eh...

Screen+shot+2011-05-23+at+21.33.59

So now the only user configured outside of 'root' is 'admin' so we'll be using admin to access the device. All good so far. But hey, we've got a router here on the network...anyone can access it. What we really need to do now is restrict access to it. Now on a Cisco IOS device we'd be talking about an access-list. We'd write the list and then apply it to an interface (vty for telnet/ssh). Well JunOS is just the same except, like always, JunOS does things a little differently.

Lets start be creating a firewall filter (comparable to Cisco access-list). First enter the 'firewall' edit mode, notice we first skip back to the top of the configuration tree:

Screen+shot+2011-05-23+at+21.35.04

Lets setup our filter to allow access from hosts in the 192.168.1.0/24 network. Forgive the screenshot the syntax goes thus (remember we are already at [edit firewall] level:


Screen+shot+2011-05-23+at+21.36.30

root@R1# set filter ssh-and-telnet-only term source-hosts from source-address 192.168.1.0/24

So thats the network access limited, and now we'll make sure this filter is matching traffic destined for telnet and ssh ports only. Remember SSH runs on port TCP/22 and Telnet on TCP/23 but we can match those using the application name. Again, the screen host has truncated and the beginning is 'set filter ssh-and-telnet-only term sour.....'

Screen+shot+2011-05-23+at+21.36.42

Finally we need to 'accept' this traffic. This is like the IOS 'permit' keyword.

Screen+shot+2011-05-23+at+21.37.04

So what do we do with the access which is denied? Well those sessions are dropped but wouldn't it be nice to see how many we're dropping? Lets add to our filter now with the 'count' keyword followed by a 'reject'. Both of these statements are called last in the filter. In IOS the reject would be implicit as a 'deny' at the end but like IOS if we want to log access attempts we need to add the 'deny log' statement at the end too...so not too dissimilar eh?

Screen+shot+2011-05-23+at+21.39.03
Screen+shot+2011-05-23+at+21.39.41

Right, access-list done now but we need to bind it to an interface. Just like in IOS where you would use an access-group or access-class for VTY ports in JunOS we simply add the 'filter' to the interface. Again, the screenshot it truncated:

root@R1# set interfaces em0.0 family inet filter...

Screen+shot+2011-05-23+at+22.40.17

OK, lets try a telnet now. 

Screen+shot+2011-05-23+at+21.41.10

Now lets try an SSH. First attempt causes my unix based host to prompt to add the SSH key signature to my known_hosts file...the second attempt has no such issue...we login...done.

Screen+shot+2011-05-23+at+21.41.38

Screen+shot+2011-05-23+at+21.41.54

Thanks for reading
View Comments
Cisco IOS access-lists are well understood, well documented and well, just plain necessary. We use access-lists to secure devices and services as well as to manage routing protocols and much more in routers and switches.

Access-lists come in a number of flavours so lets mentioned some of them here:

Standard access-lists
Extended access-lists
VLAN access-lists
Context-Based access-lists
NBAR enhanced access-lists (not really an access-list but can be used within ACL's to augment the matching process)
Zone Based access-lists

In this techguide we're just concentrating on the standard ACL.

So how do we say it? Ay'see'el? or ACKLE? It doesn't matter how you pronounce the name but the majority of the discussions I attend use the phonetic Ay'See'El (like you were reciting the letters individually A, C, L) way. Hey, what do I know, I'm a Brit and we pronounce route like Route as in Route66 (see Chuck Berry) So lets move onto something more interesting.

In this first encounter we'll go through standard ACL's. Access-lists are lists of lines which are read by the parser one by one from top to bottom. The lines are 'sorted' using line numbers which are incremented by default in 10's (e.g. the first permit/deny access-list statement will be prefaced with a line number of 10, the next line by 20, the next by 30 and so on) although this can be overridden. By function a standard ACL can only describe the source and it has no idea about protocol.

This is the format as written out:

access-list {1-99 | 1300-1999} {permit | deny} source-address [wildcard mask]

Here is a screenshot using the Cisco IOS context sensitive help to show the format of the access-list. We see here that the keyword to begin defining the access-list is simply 'access-list' in configuration mode. The '?' after 'access-list' simply engages the help output to be displayed.

Screen shot 2011-05-15 at 20.46.42

So we see looking down the list that standard ACL's can be defined using values between 1-99 and 1300-1999. We'll choose 1, it doesn't matter so long as it fits within those ranges described earlier. Using the help again we see the next choice is the action to take. Here we see we can 'deny', 'permit' or actually simply remark or comment on the access-list. Lets remark on the access-list as a first step to describe it's function "Test ACL for demo" It should perhaps be stated that the default action for any traffic which is NOT matched int eh access-list receives a 'deny' by default. You will not see this default action in any of your configuration but it is there.

Screen shot 2011-05-15 at 20.48.53

Screen shot 2011-05-15 at 20.50.52

Now we'll add to this ACL by permitting access from remote hosts on network 1.2.3.0/24.

Firstly lets see the options available to us to do this. OK so we use the permit keyword, thats required since we want to permit access. The ? reveals a few options now, hostname, any and host. What are we saying here? The easiest one to take on first is 'any'. By stating any we're saying basically permit (allow) any source.

Screen shot 2011-05-15 at 20.49.02

Using the keyword 'host' is very powerful and allows us to permit or deny access from a single IP address. The IOS parser simply reads the 'host' keyword and replaces it with a /32 mask in runtime. Remember an all 1's subnet mask (255.255.255.255) denotes a host.

So what if we want to permit all hosts on network 1.2.3.0/24? Well of course a /24 netmask is written as 255.255.255.0 (first 24 bits are 1's). IOS however expects the netmask to be written as a wildcard mask. A wildcard mask is the inverse of a network mask where a '1' is written as a '0'. The 255.255.255.0 therefore becomes 0.0.0.255. So lets add this new line in:

Screen shot 2011-05-15 at 21.00.42

Again we see we can add to this statement by using the 'log' keyword. Using 'log' allows us to see the number of matches this access-list receives.

So we now have an access-list in the configuration, we can see this here:

Screen shot 2011-05-15 at 21.03.28

The access-list is useless however without applying it to something. The access-list is powerful because it can be added it interfaces, protocols, services and probably more. We'll test out access list by applying it to our VTY service which is used to access the router across the network using protocols like telnet and SSH.

Using this topology we have created a loopback interface Lo2 on R2 with IP address 1.2.3.4/24.

1234

Lets assign the access-list 1 to the running configuration for the VTY interfaces on R1.

Screen shot 2011-05-15 at 21.09.48

Note that the access-list command changes to the 'access-group' command when it is being applied to the interface. Notice also that we are now adding a 'direction' of 'in' for the access-list. This means we are asking the router to look at packet arriving 'into' the router. The other option would be 'out' or 'outbound'. OK so we'll drop out of configuration mode back into privileged EXEC mode and run a show command to describe the status of the access-list. Notice it is given the default line of '10'. When access-lists are created each new line is incremented by a value of '10'. If we were to add a new permit or deny statement to out access-list it would start with a '20'. Remember once more that there is a default 'deny' at the end of any access-list which will be matched if no other lines within the access-list are matched.

Screen shot 2011-05-15 at 21.11.51

So lets telnet to the VTY interface running on IP address 10.1.12.1 (refer to diagram) and see what happens.

First we'll try to connect from the directly connected interface on R2 (from 10.1.12.2)

Screen shot 2011-05-15 at 21.19.15

Ah, we're denied access. If you recall we permitted access from nodes in network 1.2.3.0/24 and remember too that anything not specifically matched in the ACL will hit the implicit 'deny' statement at the end...well we're denied because our source IP address is 10.1.12.2. So lets override the default IP address used for the telnet on R2 and make it use the loopback Lo2 interface...

Screen shot 2011-05-15 at 21.22.36

OK, well that worked! So we should now see a hit in our access-list...

Screen shot 2011-05-15 at 21.23.17

We can see the matches at the end of the access-list there - 2 ;-)

Thanks for reading, see you next time with Extended Access-lists
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.