Tunnel snmp-check and other UDP traffic over SSH

Today I will be walking you through how to tunnel snmp-check and other UDP traffic over SSH.

In this example we are tunnelling UDP over SSH to circumvent firewall rules on the outside. Our firewall rules are only allowing access into the other side of the firewall to TCP port 22 on a Ubuntu server. We don’t have access to any other TCP or UDP ports. The only method of communication into the environment is via SSH to our Ubuntu server. We will use this server as jump/pivot point for other traffic. Imagine we have earlier identified through cdpsnarf using SSH dynamic port forwarding and proxychains another router, we want to enumerate this further. Our next goal in this case is to try and enumerate SNMP UDP port 161 on target router with a public community string. This example could also be applied to all sorts of UDP traffic such as DNS for example were we want to tunnel our local DNS requests to a server behind a firewall. Zone transfer maybe?tunnel snmp-check and other UDP over SSH

Attack machine: Kali Linux
Pivot Server: Ubuntu
Target: GNS3 Cisco Router

We are going to do this by sending our local UDP traffic through netcat (handling UDP) into a fifo process back into netcat (handling TCP), through the ssh tunnel then in reverse the other end. Yes I know bit of a brain teaser! You can read more about fifo files here, they are similar to pipe in linux. In essence we are sort of writing the output to a file (without actually writing anything) then sending it on its merry way through netcat via TCP then down the tunnel. Its best we see this in the flesh with an example.

We begin on the Attack machine by running up the ssh connection, here we are forwarding TCP port 6666 on localhost to TCP 6666 on the remote pivot server:

Then on the Pivot Server we create a fifo file for netcat to talk too:

On the Attack machine we do similar:

In second terminal on the attack machine:

Run up ‘netstat -au’ to verify snmp is listening on the local machine.

UDP netstat connections

We can then simple run snmp-check to localhost.

snmp-check over SSH


Looking further down the information we discover the following:
snmp-check over SSH another netowrk


Another network interface, is this possibly the internal network and route to DA..? Maybe in the next post…

Bingo UDP and snmp-check over an SSH tunnel, awesome!


VLAN tagging in Kali Linux 2.0

Connecting to Trunked Ports!

Just a quick post on how to configure VLAN tagging in Kali Linux 2.0. If we have a trunk port presented to us, how do we utilise it?

To setup vlan tagging in Kali Linux 2.0 is pretty straight forward, to set the scene and demonstrate this further we need a lab. The below lab is our ‘test.local’ environment set up in GNS3. There are 3 vlans, 10 20 and 30. 10 and 20 are routable, vlan 30 is isolated from 10 and 20. In the lab we have a ‘router on stick’ configured  at R4, fa0/1 is sub interfaced with vlans 10 and 20. utilising DHCP, vlan 10 for servers and vlan 20 for clients. All devices in vlan 30 are statically assigned IP addresses and not routable to the 10 and 20 vlan networks.  In all switches there are a variety of 802.1q trunked and access ports.

The idea of the lab is that vlan 30 can’t talk to vlan 10 or 20. However as a trunked port is presented to the Kali vm, it will be able to communicate to all vlans.

This is how it looks:

VLAN tagging in Kali Linux 2.0 - switch configuration

Lets look at how we would configure Kali to test all hosts in the different vlans, first via CLI and then via GUI in Network Manager:

As you can see with the current trunk connection we can’t access any of the networks, however a quick Wireshark does reveal we can see traffic and the different vlans…

First lets open up ‘/etc/network/interfaces’ in nano and add our interfaces. The idea is very similar to a cisco router we are essentially sub interfacing our network connection in the interfaces file:

Save our file and then simply bring up the sub-interfaces with ‘ifconfig XXX up’ where XXX is our subinterface:

We can now access all of our vlans in question.

Further to this, if we set off a ping to each network and Wireshark the trunk connection we can see our tagged packets. Hooray.

The Gui is even easier, lets configure it via the Network Manager. We will do this via opening up our network connections/Network Manager, simple click on the ‘+’ sign, select ‘VLAN’ fill in the details on the vlan tab as well as the ‘IPv4Settings’ tab:

And there you have it.

I hope this helps someone!


Active Directory Authentication for Cisco Devices – Routers and Switches

Cisco, AAA, Radius, Active Directory, Windows Server 2012 R2, NAP role, NPS its all going on!

Active Directory Authentication for Cisco DevicesJust a quick note to reference the following video on YouTube. This video demonstrates setting up Active Directory Authentication for Cisco Devices, such as Routers and Switches etc. This is using AAA on the router and RADIUS through the Network Access Policy (NAP) role in Windows Server 2012 R2, this in turn enables a Network Policy Server (NPS). The Windows server (the Radius Server) is registered in Active Directory which allows it to query the domain it is connected too for authenticating users in Active Directory to the Cisco IOS devices. You can control who has access to various network devices through rules created on the NPS. This can in turn be achieved in Active Directory via groups, binding those groups to privilege levels to pass through to deifferent devices.

For example you could have a group in AD called Network Admins which is tied to a prilivelge level 15 group rule in the NPS configuration. This rule would pass through the privilege level 15  setting through to the IOS configuration. Members of this AD group upon succesful authentication would then be granted privilege level 15 access on the router or switch.



PowerShell Port Scan

Check your Egress Filtering with a PowerShell port scan script

Firewall Egress Filtering Check with PowerShell

This is just a quick post so I can refer to myself more than anything regarding conducting a  Powershell Port Scan! However this is a useful couple of lines to to conduct a port scan from a windows device with PowerShell. This can be used in a number of situations however is especially ideal to check your egress filtering out to a server on the internet or to a segmented network. In the below few lines we are testing the first 1000 ports this can be bumped up to 65535 if wanted and the server that you are port scanning is listed as X.X.X.X.

This particular script has been pulled from Black Hills Information Security page here. An alternative from Microsoft’s ‘Hey, Scripting Guy! Blog’ can be found here.

The Common Problem

Often organisations lack adequate egress filtering, by this I mean outbound connects that can be established on a number of ports from within the heart of the network. Client machines and typical internal application servers don’t need to access a range of services out on the Internet. Once a nasty exploit has got an attacker onto a network they will look to get a foothold within the network lateral move and phone home to command and control server. Having a range of ports open to clients and servers allows attackers to make an outbound connects from whole host of tools, including PowerShell for that matter.

The Solution

Check you egress filtering and lock down any unwanted open ports out to the internet, your perimeter firewalls should not allow these outbound connections. Obviously certain services are going to need to make outbound connections such as web proxy and email gateways and these rules should be appropriately provisioned. To take this one step further enable your outbound firewall rules on your local hosts, ‘hang on a sec, you must be crazy’ I hear you say, however by doing this you will be help prevent the lateral movement of attackers through your network as well as being able to get off your network back out to the Internet.


Cisco Access Control List Guidelines to follow when creating rules.

Cisco Access Control List Guidelines

Just a quick post to remind myself and others ofCisco Access Control List Guidelines. the following Cisco Access Control List Guidelines that we should be aware of. I thought this would be good to post as a quick reference/lookup. This just gives a basic run down of how ACL’s should be implemented as per Cisco CCNA Security.

  • Ensure the last ACE that is processed has a ‘deny any’ or ‘deny any any’
  • ACLs are processed top down, as soon as as an ACE is matched the processing is stopped.
  • Make sure the most specific ACEs are at the top of the list.
  • One ACL per interface, per protocol, per direction.
  • Any new ACE’s that are added to an ACL are added to the bottom by default, unless specified.
  • Router generated traffic is not filtered by outbound ACLs
  • Standard ACLs should be placed as close to the destination as possible.
  • Extended ACLs should be placed as close to the source as possible.

Mitigating VLAN Hopping Attacks

Ways to mitigate VLAN Hopping Attacks on a Cisco Switch.

Cisco Switch mitigating VLAN Hopping Attacks

The ways in which we can prevent basic vlan hopping attacks on a Cisco Switch are more best practice security configurations. Vlan hopping attacks can occur in one of two ways. The first by an attacker spoofing DTP messages directly to a switch, if the switchport has Dynamic Trunking Protocol (DTP) enabled it can then negotiate a vlan and receive tagged packets for that vlan. The second is by introducing a rogue switch and again taking advantage of DTP and negotiating a trunk with the switch and then allowing it to receive all vlans. Not good!

We can do the following to prevent this:

  • Disable Dynamic Trunking Protocol (DTP) for non-trunked ports with switchport mode access – this should always be done for all ports straight out of the box!
  • Disable Dynamic Trunking Protocol (DTP) for all trunked ports with switchport non-negotiate.
  • Manually enable trunk ports with switchport mode trunk.
  • Set the native vlan to an unused vlan rather than just leaving it on vlan1 with switchport trunk native vlan (your vlan number)
  • Put all unused ports into an unused vlan and then disable all unused ports – again disabling all unused ports should be done straight out the box.

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.

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:

ipsec command breakdownBefore 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 to PC3 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).


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:

Cisco AAA Authentication with RADIUS against Active Directory GNS3 Topology

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:

radius lab

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:

Radius Clients, New

New Radius Client Settings

New Radius Client Advanced Screen


Now we need to configure the Network policy:

New Network Policy

New Network Policy name

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:

New Network Policy - Add

Grant Access for this group:

New Network Policy Access Granted

Configure the appropriate authentication methods:

New Network Policy - Configure Authentication Methods

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

New Network Policy - Standard Radius Attributes

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.

New Network Policy - Vendor Specific Radius Attributes

Then Finish:

New Network Policy - 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.

Enable AAA:

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:

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

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:

All together this looks like the below:

We can test simply by logging out and back in.


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:

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.


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:

RIP and IPV6 lab
RIP and IPV6 lab

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

IPV6 rip routing table
IPV6 rip routing table

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.


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.