Configuring IPSec Site-to-Site VPN Tunnels

Configuring a IPSec Site-to-Site VPN Tunnels on a Cisco Router

I thought I would run through configuring IPSec Site-to-Site VPN Tunnels on a cisco router. I’m going to be covering at high level the basic principles needed to configure a IPSec Site-to-Site VPN. The fundemental principals can be used for the Cisco ASA Firewall or Cisco VPN concentrator. The VPN gateways in our example (the routers) are responsible for encapsulating and encrypting the outbound traffic which in a real world example this would from be from a site to a peer gateway at another site. This could be either through an MPLS network from an ISP or more commonly directly over the Internet. When the receiving gateway receives the traffic it strips away the headers, decrypt’s the content with the pre-shared key and forwards on the traffic to a host network on the inside.

In our example we are going to be using 3 networks with an IPSec VPN tunnel being established between two of the routers. I have added the extra network without the tunnel to demonstrate in wireshark the encrypted vs the non encrypted traffic. All three networks are connected to a switch which we are going to image as our either our Internet or MPLS connection.

IPSec VPN Diagram

An IPSec tunnel consists of 5 stages to establish and terminate its connection these are:

An ISAKMP tunnel is initiated when the VPN gateway detects ‘interesting traffic’ which is defined by an ACL.
IKE Phase 1 is established through negotiating the ISAKMP SA policy that is defined in the config.
IKE Phase 2 is established through negotiating the IPSec SA policy.
The IPSec tunnel is created and data can begin to be transferred Encrypted.
The IPSec tunnel is teared down when either the lifetime of the session expires or the IPSec SA is removed.

Below is the extra config that is used for each router other than the initial config of a standard GNS3 router, this can simple be copied into global configuration mode. The config is split into three main sections the interface configuration, EIGRP configuration and the IPSEC configuration.

hostname RouterA
interface fa 0/0
 ip address 4.5.6.1 255.255.255.0
 no shutdown
interface fa 0/1
 ip address 10.0.0.1 255.255.255.0
 no shutdown
 exit
router eigrp 111
 network 10.0.0.0
 network 4.5.6.0
 no auto-summary
 exit
# Identify interesting traffic on RouterA to RouterB with the below ACL
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 
# Configure the IKE Phase 1 ISAKMP SA policy on RouterA 
crypto isakmp policy 10
 encryption aes 256
 authentication pre-share
 hash sha
 group 5
 exit
crypto isakmp key cisco12345 address 4.5.6.2
# Configure the IKE Phase 2 IPsec SA Policy on RouterA
crypto ipsec transform-set VPN-SET esp-aes esp-sha-hmac
crypto map VPN-MAP 10 ipsec-isakmp
 description VPN Connection from RouterA to RouterB
 set peer 4.5.6.2
 set transform-set VPN-SET
 match address 101
 exit
interface fa0/0
 crypto map VPN-MAP
 exit

hostname RouterB
interface fa 0/0
 ip address 4.5.6.2 255.255.255.0
 no shutdown
interface fa 0/1
 ip address 10.0.1.1 255.255.255.0
 no shutdown
 exit
router eigrp 111
 network 10.0.1.0
 network 4.5.6.0
 no auto-summary
 exit
# Identify interesting traffic on RouterB to RouterA with the below ACL
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 
# Configure the IKE Phase 1 ISAKMP SA policy on RouterB
crypto isakmp policy 10
 encryption aes 256
 authentication pre-share
 hash sha
 group 5
 exit
crypto isakmp key cisco12345 address 4.5.6.1
# Configure the IKE Phase 2 IPsec SA Policy on RouterB
crypto ipsec transform-set VPN-SET esp-aes esp-sha-hmac
crypto map VPN-MAP 10 ipsec-isakmp
 description VPN Connection from RouterB to RouterA
 set peer 4.5.6.1
 set transform-set VPN-SET
 match address 101
 exit
interface fa0/0
 crypto map VPN-MAP
 exit

hostname RouterC
interface fa 0/0
 ip address 4.5.6.3 255.255.255.0
 no shutdown
interface fa 0/1
 ip address 10.0.2.1 255.255.255.0
 no shutdown
 exit
router eigrp 111
 network 10.0.2.0
 network 4.5.6.0
 no auto-summary
 exit
# Note there is no IPSec configuration on this router

I’ve broken down just one of the IPSec configuration below to explain what the various elements are, these need to match at both sites:

Before generating any interesting traffic if we execute ‘show crypto ipsec sa’ from RouterA we can clearly see there has been no traffic captured by the ACL.

before ipsec traffic

If we now generate some ‘interesting traffic’ such as a ping from PC1 10.0.0.2 to PC3 10.0.1.2 which will match our ACL that is specified in our crypto map, then re-issue ‘show crypto ipsec sa’ we will see from the stats that packets have been encrypted. Further to this we will see the inbound and outbound session will be ‘ACTIVE’.

After ipsec traffic

To take this one stage further we will demonstrate the difference in the Encrypted IPSec traffic and ordinary traffic using wireshark. The capture will be taken from the link between RouterA and the core network. We will ping out from PC1 to PC3 (the encrypted traffic caught by our ACL) and PC2 to PC5 (the non-encrypted traffic that doesn’t match our ACL) simultaneously. This is what we see:

IPSec traffic in wireshark.

As we can see from the wireshark capture our encrypted traffic is shown in the Encapsulated Security Payload and our non encrypted traffic in the clear (the ping request and reply).

22nd February 201623rd November 2016

Risky Business Podcast – Good Listen!

I thought I would share with you all a new podcast I have been listening to (well new to me). Risky Business, as taken from the website ‘Risky Business was established in February, 2007. It takes a lighthearted look at information security news and features!’ – I’ve found this weeks episode #399 particularly interesting, it contained news stories that are current at the moment, with just the right amount of technical detail to keep me listening. Notably the stories of the week that were discussed were around the iPhone FBI saga that started last week, GLibc vulnerability and interestingly the new NIST Cyber Security framework which was discussed by Cris Thomas, a.k.a. Space Rogue.

I invite you to also listen to Risky Business and maybe let me know what you think:

http://risky.biz/netcasts/risky-business

20th February 201623rd November 2016

Lets Encrypt!

Lets Encrypt! Free Certificate!

Lets Encrypt

I thought I would run through the process of obtaining a certificate for a web server from Lets Encrypt the open certificate authority by the Internet Security Research Group (ISRG) , for free!

The Lets Encrypt initiative has been setup to simplify the process of obtaining a certificate and make it more accessible for people to use encryption on their websites you can read more about it here: https://letsencrypt.org/. Certificates are free and valid for 90 days and need to be renewed for continuation of the service. (which can be automated). Those who have been through the process of provisioning certificates will understand the involved process to get it working, this is a breath of fresh air in comparison.

Sounds great so what do we need to do? Well the below example runs through the process for an already created standard HTTP apache debian based system.

OK So Lets Encrypt!

First we need to obtain the Lets Encrypt files. We will pull the files across from the Official GitHub repository. We’ll do this through git. This ensures that we have the latest version of the Lets Encrypt files. We will drop it under the /opt folder.

If you don’t have git installed… install it with:

apt-get install git

Then pull across the Lets Encrypt folder with:

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

(If you want to update in the future run ‘git pull’ in the same folder.)

Move into the lets encrypt folder:

cd /opt/letsencrypt

We then need to install the Lets Encrypt client through the ‘letsencrypt-auto’ command, when this is run it will essentially pull down all the related dependencies from your OS repositories and update the client through either apt-get or yum for example. From there on you can run either ‘letsencrypt’ or ‘letsencrypt-auto’ command for new certs of renewals.

Next we will obtain our certificate and bundle for our test domain testdomain.co.uk and subdomain www.testdomain.co.uk with the letsencrypt-auto command. This is the recommended method from the Lets Encrypt website.

There are a number of plugins that can be used with letsencrypt run command, and a number of command line parameters you can pass, these are all designed to help ease the process along. We are going to be running the Apache plugin and so will pass it the ‘–apache’ command. This plugin is designed to be used with Apache (funnily enough!) which automates the process of obtaining and installing the certificate with Apache2.4 on Debian based systems. This effectively sorts all the certificate configuration within Apache and then restarts the service.

./letsencrypt-auto --apache -d testdomain.co.uk -d www.testdomain.co.uk

After this is executed you should see the updates scroll through pulling content from your repositories, after a while you will presented with the following screen asking you to confirm your email. This is used as a reminder for renewal:

You can automate this process passing the –email parameter at the command line if you wish. So ‘–email admin@testdomain.co.uk’

You will next be asked to agree to the terms of service:

Again you can automate this by passing the –agree-tos in the command line.

Next you will be asked where you want to access your site through http and https or just through https.

You will then be presented with the ‘Congratulations!’ screen saying you have successfully configured your certificate and enabled https:

Renewal

To renew your certificate run:

letsencrypt-auto renew

This will renew all your certificates with all previously used parameters for certificates that are due to expire within 30 days. passing the -d parameter will renew per domain.

--force-renewal

Allows you to renew before 30 days.

You can also run:

letsencrypt-auto renew --rsa-key-size 4096

This will renew your certificate with a key size of 4096 bit.

You can also rerun the existing command you ran earlier in which case you will be prompted that you have already run the command and to either re-run the install or renew your certificates.

All that is left to do is to automate the renewal with a cron job, one for another post.

Amazing that’s it! This makes obtaining a certificate for a website very accessible to people due to the way the scripts/plugins automate the apache configuration.

**Thumbs up Lets Encrypt this is great project!**

7th February 20162nd January 2017

Server Hardening: HTTP TRACE TRACK Methods Allowed – Part1 Apache

Many vulnerability scanners will often bring back HTTP TRACE TRACK Methods Allowed against Apache and Microsoft web servers of the older generation. TRACE is usually associated with Apache and TRACK for Microsoft. This has a CVSS score of 4.3 and is a relatively easy fix. Clearly the older generation operating systems should be migrated to a supported platform, both the later distributions of Ubuntu and Microsoft 2012 R2 do not allow these methods to be used. However a simple way to validate this finding is to use telnet to connect to the web server on port 80, once connected you can type something similar to the following for each method. The ‘Host’, ‘TestA’ and ‘TestB’ aren’t needed however if you use some custom text you will be sure to see it echoed back by the web server if trace is enabled.

TRACE / HTTP/1.1
Host: 192.168.0.29
TestA: Is this correct?
TestB: Are we sure?

Tap return twice to send.

Which would look something like the below as you can see the user input was returned, the web server accepting the method:

Remediation:

As I said the HTTP TRACK / TRACE issue is this is relatively straight forward to fix, simple add ‘TraceEnable off’ somewhere in your main Apache config file outside of the vhost configuration.

Once implemented retesting should reveal that the method is not allowed:

after adding 'TraceEnable off' HTTP Trace disabled on Apache — After adding ‘TraceEnable off’

1st February 201623rd November 2016

mailtrap.io

Email Relaying with mailtrap.io

I have been recently testing out some SIEM (Secuirty Incident & Event Management) software by SolarWinds there LEM product, (a review for another post perhaps). During the testing I can across the requirement to relay mail notification emails out to a set of test users (this typically being IT, 3rd Line in my scenario) based on certain events, I wanted to ensure the rules were being fired correctly. I haven’t really come across this requirement before in testing so had to give this some thought. I didn’t really want to stand up a whole mail environment with clients etc in my lab simply due to complexity and configuration hassle that I should imagine it would entail, it also takes the focus off what I’m actually trying to achieve. Whilst googling some idea’s for ‘quick and dirty mail deployments’ I came across ‘mailtrap.io’.

Mailtrap.io essentially allows you to relay mail out across the Internet to there mail servers without it actually being forwarded onto the end recipient, a little bit like a fake smtp server. It is specifically designed for test, dev and QA environments for testing mail notifications without actually sending emails to customers or users. You can view the email messages online.

You can sign up for free account which gives you a single mailbox and allows you to receive upto 50 email messages. You receive a username and password and all the other details required for relaying mail, such as smtp address etc. These can be reset at the flick of a button enabling you to reset the creds at the end of your lab session.

Thumbs up for mailtrap.io I will be using this again in the future no doubt check it out at http://www.mailtrap.io

30th January 20163rd March 2018

Server Hardening: Securing SSH part 2

Secure up your SSH service

This is Part two of Securing SSH in the Server Hardening Series. In this post we will continue to walk through the remaining hardening options for SSH.

In Part 1 of Securing SSH located here we discussed:

Disabling SSH Protocol 1 and using 2.
Limiting the users who can login.
Disable root login and unsing only a standard user account.
Run SSH on a different port.

In Part 2 of Securing SSH we will now cover the remaining techniques:

Use Public Private keys for Authentication
Filtering SSH with iptables
Setting strong Cryptographic Algorithms

Use Public Private keys for Authentication

As we know passwords can be subject to brute force attacks and given enough time simple passwords can be broken. Using SSH public private key pairs for authentication is a more secure method. Its a more secure method of logging in than using a password due to the computational power and time needed to decipher the public private key pair through brute force. The private key is used on the machine from which you are logging in from and the public key is used on the server or machine which you are establishing an SSH session with. In addition to using the key pair you can use a passphrase to secure the key pair. Should the key pair become compromised you have a an additional fallback and time in which to remove the public key from server it is being used on.

First we need to create the key pair, you can create either an RSA (Rivest-Shamir-Adleman) or DSA (Digital Signature Algorithm) key pair. The default key size in Ubuntu is currently 2048 however you can specify the -b parameter for a high keysize for example ‘-b 4096’. In this example we are creating a keypair for the root login, you should ideally do this for a standard user however this is just to demonstrate the procedure.

In this example we are creating the key pair on the same test ubtunu 14.04 server as the one which we are going to be using the keys to actually access. In reality there are a number of ways and platforms from which to create the key pair, whether that’s on the server or client OS.

ssh-keygen -t rsa -b 4096

After the above command you will be prompted with some further questions, what and where the keys will be stored. Press enter and move on to accept the default files name, you can specify your own file name, the files will be created in the current working directory.

You will next be prompted to enter a passphrase, you have the option to enter one here. Doing so adds a layer of complexity for anyone that has already obtained the key pair and thus further hardens your configuration. If you enter a passphrase you will need to enter it in every time you ssh to the server.

The whole process will look like this:

If we now look in the ssh folder in the home user directory for root (or where ever you chose to save the files) we will see our key pair. The private key is called id_rsa and the public key is id_rsa.pub:

At this point it would be wise to backup both sets of keys. You will need to copy off the private key for you to use from your local machine that you will be ssh’ing in from, we could do this in many ways either using winscp from a windows operating system alternatively we can view the private key and use copy and paste the contents from an existing session. Remember the folder is hidden, with the period in front of the folder name (.ssh) if your looking for it in winscp ;-).

We will need to move the public key into the ‘authorized_keys’ file on the server you are going to be using the keys for (the same server in our case), and restart SSH. The .pub file should be copied over to the correct profile you will be ssh’ing into.

cd .ssh
cat id_rsa.pub >> authorized_keys
service ssh restart

If I had created the key pair on my client machine I could use the ssh-copy-id command in order to get the public key onto the server like below:

ssh-copy-id -i .ssh/id_rsa.pub root@165.227.237.152

At this point you are ready to test the rsa key authentication method. I would strongly recommend you test this at this stage whilst you still have regular username and password ssh authentication enabled, in case you have made a mistake and can’t get back in. If you going to be testing from putty or winscp you will need to use puttygen to convert your private key file into a format that putty can read which is a ppk file. This is a straight forward task.

Once tested and you are ready to start using your key pair you will want to remove the ability for ‘root’ (and other user in this example) to login with a username and password. Only do this after you have successfully used your key pair and are comfortable with the process. In the ‘sshd_config’ amend the ‘PermitRootLogin’ to read ‘PermitRootLogin without-password’ and add a line that reads ‘PasswordAuthentication no’ like below.

Restart ssh service one final time. This will deny access via username and password.

Filtering SSH with iptables

I demonstrated the use of iptables in one of my previous posts here, so won’t be going into this again.

Setting strong cryptographic algorithms

In this particular section of the post we are going to look at how we can customize the cryptographic algorithms that SSH can use and further optimize these so we are only using the most secure ones available. To dig a little bit deeper here there are two specific issues we are going address. The first being the type of encryption mode that is being used, and the second being the use of weak MAC algorithms.

At the time of writing (as this will change) your average vulnerability scanner will detect ssh on port 22 and will try to negotiate a session with the service. In doing so it will detect the cryptographic properties that the server would like to use, in your typical out of the box setup CBC (Cipher Block Chaining) encryption mode and MD5 or 96-bit MAC (Message Authentication Code) algorithms will be configured, both of which are considered weak. The use of CBC encryption mode for SSH is currently scored as CVSS Base Score 2.6 equating generally speaking as a Low risk. We can correct this by disabling CBC encryption mode, and enabling a different type of mode such as CTR or GCM. The use of weak MAC is also scored with a CVSS Base Score of 2.6 equating again generally speaking as a Low risk. This can be correct by removing the use of MD5 and 96 bit MACs.

Amend or appending the following lines to the /etc/ssh/sshd_conf file will resolve this issue, there are other variations that you could use however this will rectify the issue:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128
MACs hmac-sha1,umac-64@openssh.com,hmac-ripemd160

I hope this has been informative.

17th January 20165th January 2017

Cisco AAA Authentication with RADIUS against Active Directory 2012 NPS

AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2

I thought I would cover a quick post to demonstrate setting up Active Directory authentication for a Cisco router or switch IOS login. This will be using AAA and RADIUS through the Network Policy Server (NPS) role in Windows Server 2012 R2 to authenticate users in Active Directory on Cisco IOS devices.

As with all my labs a picture paints a thousand words so here is the GNS3 Network topology we will be using, this is also being used for 802.1x which will be covered in later post:

So here is quick run down on the gear we will be using just for this lab:

R1: Cisco IOS (C7200-ADVENTERPRISEk9-M), Version 15.2(4)S4

Server 2012 DC: Windows Server 2012 R2 ( Active Directory Domain Services and Network Policy Server role.

Just to demonstrate a lab as simple as the below could also be used to test this:

Active Directory Configuration:

I will be assuming that AD and the NPS role have already been installed. Prior to jumping into the NPS configuration you will need to create an AD group for the users that will be logging into the Cisco equipment, add a couple of test users to this group. In my case I have simply created a group called ‘Radius’ and have added the user ‘Adam’.

Open the NPS console.

Right click on the NPS(Local) tree node and select ‘Register server in Active Directory’:

Now create the Radius clients, in our this case this is R1:

Now we need to configure the Network policy:

Add our ‘Radius’ AD group. You can tighten the control here by specifying further conditions such as the ‘friendly name’ (R1) or the local IPV4 address of the radius client, in a production environment you would want to lock this down further for now we are just going to add the the user group to authenticate:

Grant Access for this group:

Configure the appropriate authentication methods:

Change the Standard Radius Attributes by removing ‘Framed-Protocol – PPP’. Edit the ‘Service-Type’ value to ‘Login’:

Add a Vendor specific attribute, this allows the radius server to pass the privilege level though the cisco router which we shall see later in the debugging. The value needs to read ‘shell:priv-lvl=15′.

You can create several policies for the different privilege levels. For example you could create a group in AD called ‘Cisco Users Priv 1’, associate this group to a policy and in the below option use the value ‘shell:priv-lvl=1′. When that user logs in the policy will match that user and the NPS use the matched policy passing privilege level 1 through to the router or switch.

Then Finish:

Cisco IOS configuration

Create a a user with privilege level 15, we wil use this as our fall back should the router not be able to contact the radius server it will use the local AAA database.

R1(config)#username Admin privilege 15 secret cisco12345

Enable AAA:

R1(config)#aaa new-model

Now we will setup the main parts to the radius configuration, tell the switch we would like to use radius and the group RAD_SERVERS:

R1(config)#aaa group server radius RAD_SERVERS

Specify the radius server that we would like to use in our case 10.0.0.2 is our NPS, the auth and acc ports and also the secure key we used:

R1(config-sg-radius)#server-private 10.0.0.2 auth-port 1812 acct-port 1813 key cisco
R1(config-sg-radius)#exit

Specify that for the default login for authentication an authorization that we want to use the group called RAD_SERVERS that we have just created and if that fails we use the local database. This is particularly important so we do not lock ourselves out on the router:

R1(config)#aaa authentication login default group RAD_SERVERS local
R1(config)#aaa authorization exec default group RAD_SERVERS local if-authenticated

All together this looks like the below:

R1(config)#aaa group server radius RAD_SERVERS
R1(config-sg-radius)#server-private 10.0.0.2 auth-port 1812 acct-port 1813 key cisco
R1(config-sg-radius)#exit
R1(config)#aaa authentication login default group RAD_SERVERS local
R1(config)#aaa authorization exec default group RAD_SERVERS local if-authenticated
R1(config)#aaa authorization console

We can test simply by logging out and back in.

Troubleshooting

It obviously goes without saying you need to test the authentication to the Radius server, exit right out of the console and log back in using your AD credentials.

If all has been configured correctly you should be able to login. its also worth testing the fall back option configured for local AAA authentication. We can do this just simply stopping the NPS service then try the local credentials, again all being configured correctly you should be able to login.

There are a few useful debugging commands we can use to monitor and troubleshoot the authentication these being:

R1#debug aaa authentication
AAA Authentication debugging is on
R1#debug aaa authorization
AAA Authorization debugging is on
R1#debug radius
Radius protocol debugging is on
Radius protocol brief debugging is off
Radius protocol verbose debugging is off
Radius packet hex dump debugging is off
Radius packet protocol debugging is on
Radius elog debugging debugging is off
Radius packet retransmission debugging is off
Radius server fail-over debugging is off
Radius elog debugging debugging is off
R1#

This time when we login we can see the debug information for an attempted login, it should look similar to this, note the highlighted area’s:

I hope this has been informative.

9th January 201623rd November 2016

IPV6 and RIP GNS3 Lab

I decided to to look into configuring a quick simple IPV6 lab in GNS3 using RIP. I put together the following lab using the RIP routing protocol for ease of use. The lab consists of 3 routers multiple interfaces, 3 subnets, 3 PC’s and switches for endpoint connectivity, I find its easier to use the virtual switches if I want to expand the lab later. The routers are the using the c7200-adventerprisek9-mz.152-4.S4 image and the PC’s are simply the virtual PCs (VPCS) from GNS3 again for ease of use. I do normally prefer to connect an actual operating system as PC’s as I find it more realistic however as we are just testing connectivity and routing the VPCS option is a good fit here and light on system resources.

Below is the simple topology:

Some of the basic configuration for RIP and IPV6 is show below for R1. This can then be replicated across the other routers and interfaces changing the IPV6 subnet ID and Interface ID as you go along. Using Global IPV6 addresses with a made up subnet ID.

Straight in the configuration starting in global configuration mode on R1:

R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 address 2001:db8:6783:120::1/64
R1(config-if)#no shutdown

Verify the interface:

verify the ipv6 interface configuration.

Note the new IPV6 Link Local address that has been automatically assigned to the interface when it was brought up, the closest thing to explaining for now is the 169.254.x.x/16 address asinged by APIPA. The Link Local address is made of the first 10 bits (identifiable as the Link Local FE80) the other 54 bits being Zeros (::) and the remaining 64 bits being made up of the MAC address and FFFE slotted in the middle. 🙂

Onto the routing:

R1(config)#ipv6 router rip RIP1
R1(config)#int fa0/0
R1(config-if)#ipv6 rip RIP1 enable

The router will then advertise its routes through the enabled interface for RIP1 using rip and likewise for R2 and R3. Once R3 has been configured 30 seconds later a quick check of the routing table from R1 should display:

We can see the advertised routes for rip, also notice that the advertised route is via its IPV6 Link Local address starting with FE80.

A quick check from PC3 to R1 and PC4 further verifies connectivity through IPV6 and rip configuration:

Checking IPv6 endpoint connectivity from PC3 to PC1. — Checking endpoint connectivity from PC3 to PC1.

Interesting, more to come from IPV6 in the future for sure.

8th January 20165th January 2017

CCNA Security – Implementing Cisco Network Security Lab

I thought I would share with you the Lab I have been mostly working with for CCNA Security (CCNAS) – Implementing Cisco Network Security (210-260) exam that I have recently took and passed. I have also used several smaller lab setups for specific testing however this is the main lab to piece everything together.

CCNAS - Implementing Cisco Network Security Lab — CCNAS – Implementing Cisco Network Security Lab

The lab has been built to accommodate the many elements on the exam and covers off most of the practical procedures that you need to be comfortable with. Using GNS3 and VirtualBox we are able to lab most of the practical exercises bar the L2 switching portions which I achieved through physical equipment (Catalyst 3750, 3550 x2 and 2950 switches). The exam does cover many topics in theory that you must know, these aren’t covered here, however can be found on the Cisco website.

The lab contains several client machines for managing the routers and ASA firewalls from putty, cisco configuration professional and ASDM as well as testing PAT through the ASA with a breakout to the internet. There is an Active Directory Domain Controller with the Network Access Protection role installed for use with AAA/radius and NTP. A separate syslog server. A DMZ with web server for testing NAT and outside firewall rules. There is also an ASA 5520 at each of the three sites for testing VPN site-to-site Ipsec connections, clients at all sites for testing end to end connectivity. There is also an outside remote client for testing the Anyconnect and client-less vpn options which takes advantage of the AAA radius service.

Using this lab we are able to address the following practical elements for the CCNAS exam:

2.0 Secure Access

2.1 Secure management

2.1.b Configure secure network management
2.1.c Configure and verify secure access through SNMP v3 using an ACL
2.1.d Configure and verify security for NTP
2.1.e Use SCP for file transfer

2.2 AAA concepts

2.2.b Configure administrative access on a Cisco router and ASA using RADIUS
2.2.c Verify connectivity on a Cisco router and ASA to a RADIUS server

3.0 VPN

3.2 Remote access VPN

3.2.a Implement basic clientless SSL VPN using ASDM
3.2.b Verify clientless connection
3.2.c Implement basic AnyConnect SSL VPN using ASDM
3.2.d Verify AnyConnect connection
3.2.e Identify endpoint posture assessment

3.3 Site-to-site VPN

3.3.a Implement an IPsec site-to-site VPN with pre-shared key authentication on Cisco routers and ASA firewalls
3.3.b Verify an IPsec site-to-site VPN

4.0 Secure Routing and Switching

4.1 Security on Cisco routers

4.1.a Configure multiple privilege levels
4.1.b Configure Cisco IOS role-based CLI access
4.1.c Implement Cisco IOS resilient configuration

4.2 Securing routing protocols

4.2.a Implement routing update authentication on OSPF

5.0 Cisco Firewall Technologies

5.3 Implement NAT on Cisco ASA 9.x

5.3.a Static
5.3.b Dynamic
5.3.c PAT
5.3.d Policy NAT
5.3 e Verify NAT operations

5.4 Implement zone-based firewall

5.4.a Zone to zone
5.4.b Self zone

5.5 Firewall features on the Cisco Adaptive Security Appliance (ASA) 9.x

5.5.a Configure ASA access management
5.5.b Configure security access policies
5.5.c Configure Cisco ASA interface security levels
5.5.d Configure default Cisco Modular Policy Framework (MPF)

Well what next, CCNP Security of course.

16th October 201523rd November 2016

Server Hardening: Securing SSH Part 1

This will be the first of two posts in the server hardening Series where we will discuss the Secure Shell (SSH) service. I will cover the options available to us for hardening SSH. SSH is a cryptographic network protocol used for remote management over an insecure (or less secure) communication channel. Whether this is a web server, an appliance or a firewall, out on the internet or in your local subnet. For example most remote Linux based servers have SSH enabled in order for administrators to remotely manage them rather than being directly in front of the server/appliance with a monitor at the console. According to arstechnica (2015) Microsoft is also to introduce native support for SSH in 2015 – so watch this space.

There are a number of hardening techniques that we can undertake to further secure the SSH service from an out of the box typical install. These include:

Disabling SSH Protocol 1 and using Protocol 2. (Part 1)
Limit the the users who can login. (Part 1)
Disable root login and use a standard user account. (Part 1)
Run SSH on a different port to 22. (Part 1)
Use Public Private keys for Authentication. (Part 2)
Filter SSH with iptables (demonstrated in one of my previous posts here) (Part 2)
Setting strong cryptographic algorithms (Part 2)

I will be demonstrating these tasks on Ubtuntu 14.04. however the options and configurations will be very similar across the different Linux distributions.

Disabling SSH Protocol 1 and using Protocol 2

Disabling SSH Protocol 1 is done in the following file ‘/etc/ssh/sshd_config’, so using your favorite text editor nano, vi, leafpad etc (mines nano) open up the ‘sshd_config’ file and find the protocol line and ensure it has a the ‘2’ parameter next to it like the below:

# Protocol 1
Protocol 2

Limit the the users who can login

Locate the authentication section again in the file ‘/etc/ssh/sshd_config’, and add in the line ‘AllowUsers Adam Mark’ and any other usernames as needed. This should be used in conjunction with disabling the root login. This will only let ‘Adam’ and ‘Mark’ login for example.

AllowUsers Adam Mark

Disable root login and use a standard user account

Locate the authentication section and specifically the ‘PermitRootLogin yes’ and either comment the line out with a # and add a new line in or change the parameter to ‘no’.

# Authentication:
LoginGraceTime 120
# PermitRootLogin yes
PermintRootLogin no

Run SSH on a different port to 22

This can clearly be achieved in a number of different ways depending on how your infrastructure is configured. For example you could change the port on your SSH Service in the sshd_config file or adjust port forwarding/translation rules on your firewall or router. The main goal of this exercise is to obfuscate the SSH service to a potential attacker, we must be clear here this doesn’t protect the port in any way however does distract from the fact port 22 is not open for business. I say again this will not protect you against an attacker with enough intent, an attacker with enough experience will have scanned all 65k ports and verified all services on all open ports. Never the less if somebody has only scanned the top 1k ports its still an option, but should not be relied upon. I’m not going to get into the debate of ‘security by obscurity’ in this post. From the following file ‘/etc/ssh/sshd_config’, locate the ‘port 22’ line and change the number parameter to the unused port of your choice

# I have changed the default SSH port from 22 to 3333
Port 3333

I have added a comment in the line above as a reminder here to allow the next person to see what I have done for any troubleshooting purpose. You never know when you will move on and the next person needs to administer the box, this is useful to them. 😉

In most cases the SSH service will need to be restarted in order for the changes to take effect. From a terminal: (I always add a ‘-v’, optional for verbose)

Service ssh restart -v

As always I would suggest you try these out first in a test environment making one change at a time before changing your corporate machines.