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!

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

14th June 20165th November 2016

Running MBSA on a remote machine.

Running MBSA on remote machine that is in a workgroup or different domain.

I thought I would share my findings on using MBSA (Microsoft Baseline Security Analyser) for targeting remote machines that are not part of the same domain or in a workgroup. This really is a great tool for enumerating OS patch levels.

We have two scenarios to run through; the first, running MBSA on remote machine that is in a different domain from the machine that it is installed on. The second, running MBSA on a machine that is in a workgroup. Ok no problem. Here is what we do.

First Scenario

In the first scenario our target machine is a Windows Server 2012 R2 machine that is in a different domain to our MBSA host (Windows 7 Pro 64bit). Fire up a cmd prompt with admin privileges from the machine that you are running MBSA from, and run the following syntax:

runas /netonly /user:test\administrator "mbsacli.exe /target 192.168.56.104 /nvc /nd /wi"

A second command prompt will pop up and run, running the syntax as above:

MBSA remote1

If you wait a short while the MBSA command prompt will disappear when finished, from here you can open up MBSA and view the report:

mbsa remote2

In this example the target machine was in my virtualbox lab, in a domain called ‘Test’. The machine I ran MBSA from was a Windows 7 Pro machine in a workgroup (no relationship) other than IP connectivity. The cli syntax I used here was used to speed up the check, clearly only use this if you have the latest scan catalogue:

/wi – Show all updates even if not approved by wsus.
/nvc – Do not check for a new version of MBSA.
/nd – Do not download any files from MS update site when scanning.

Additional options:

/target <Target-IP>

/listfile C:\tmp\targets.txt

/catalog C:\tmp\wsusscn2.cab

Add: ‘>C:\tmp\MBSADC1.txt’ to the end of the syntax for a handy output to a text file.

As an example you might use:

runas /netonly /user:test\administrator "mbsacli /catalog C:\tmp\wsusscn2.cab /target 192.168.56.104 /nvc /nd /wi"

The Second Scenario

The second scenarios is a Windows Server 2003 machine that is in workgroup. The syntax is actually the same however your specifying the local machine name rather than the domain name. I have mixed this one up a little here by not using the cli, by just specifying MBSA the command simple fires up MBSA GUI as the account specified. The only thing to remember here is to add the IP address into the GUI.

runas /netonly /user:test\administrator mbsa

mbsa remote3

And again after the scan has finished the results can be view in the GUI.

mbsa remote4

I haven’t successfully managed to do this from a Windows 10 client yet, various forums would suggest it isn’t supposed to work with 10 however if you know please feel free to drop me an email or comment.

9th June 20165th November 2016

Windows Client/Server Hardening Part 2: Securing Remote Desktop with Certificates.

Securing Remote Desktop with Certificates from your Internal CA.

Implementing Remote Desktop with Certificates

In this post I’m going to be following on from Part 1 located here, talking about further hardening the Windows Remote Desktop Protocol (RDP) with a certificate based system. The certificate is generated and signed by an internal Active Directory Certificate Authority (CA). The issue here being that you have no way of verifying the server or PC that you are trying to connect to via RDP. The machine that you are supposedly connecting to usually presents you with a certificate that is signed by itself, funnily enough known as a ‘self signed certificate’.

The Attack…

The play by an attacker here being that should they have exploited a vulnerability and been able to access your internal network (not for this discussion, however..), they could essentially respond to ARP request by modifying responses sent by an attackers machine. This is done by flooding the network with bad ARP responses, known as ARP poising, the whole attack is known as a Man In The Middle (MITM). There are many ways of carrying out a MITM attack, this just one of them. Once a MITM attack is in play and your arp cache is then poisoned you would essentially be connecting to an attackers machine. The attacker can then sniff the network traffic and all sorts of other rather bad things can happen, like stealing credentials.

A typical self signed certificate presented through RDP looks like the picture above, and clearly states the certificate is not from a trusted certificate authority. If your PC can trust the certificate that is presented by the machine you are connecting too, through the use of a bonafide signed certificate from your internal CA you would know whether or not the machine you are connecting to is genuine. More importantly, through the use of Group Policy you can specify that you are not able to connect to it unless you trust it. Thus preventing any bad MITM rdp sessions.

How do we fix it…

Carlos Perez has written up an excellent ‘how to’ guide from start to finish on how to setup this up. He walks through the certificate templates required for the RDP service. Also setting up group policy to deploy the certificate. This is a great guide so I’m not going to re-regurgitate his excellent work going through all the various screen shots, you can view it here at http://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo .

31st May 20162nd January 2017

Ubuntu 14.04 Syslog Server

A quick and simple Ubuntu 14.04 Syslog Server with rsyslog for Network Devices.

In this post I going to run through creating a quick a simple Ubuntu 14.04 Syslog Server. Logging events is an important part of secure network configuration. The messages provided by devices such as switches, routers, firewalls and number of other devices provide a huge amount of information to systems administrators when a specific event has occurred and steps need to be traced. This could be for diagnosing a problem or looking at the activity of a potential attacker. When syslogging is setup it allows system administrators to respond better to incidents due to having the information readily available. Shipping the logs off to a remote server allows them to be safely stored without fear of them being deleted due to an attacker compromising the device but also the device being restricted due to small amount of storage space usually allocated.

In this post we are going to setup a syslog server on Ubuntu 14.04. Ubuntu uses rsyslog for its logging you can read all about this here, I’m just going to cover some of the basics to get you up and running, the idea here being that you have something to work on and take to the next level.

The below network diagram whilst may seem overly complicated, serves us well for this scenario and gives us our network and devices that we want to collect data from. In this scenario we want to collect logs from the routers. The platform we are going to test this out in is GNS3, truth be told it was a lab I had machines active for so though, meh… why not drop a syslog server in.

Ubuntu Syslog Server Network

There are essentially three steps I’m going to walk you through:

1. Configure the /etc/rsyslog.conf to accept remote incoming UDP syslog messages
2. Create and configure a conf file in /etc/rsyslog.d/30-cisco.conf. This is a new file we are going to create which specifies some rules on what we want to do with our messages if they come from different devices. You can add the rules to the rsyslog.conf file however creating a seperate conf file is the neater option in my opinion.
3. Change permissions of the /var/log/ directory so syslog user can make changes, create files etc.
4. Restart rsyslog with : sudo service rsyslog restart.
5. Test with our Cisco devices.

So taking our completely standard Ubuntu 14.04 install find our rsyslog.conf file in /etc/ and uncomment the following lines with our favourite text editor in my case ‘nano’:

$ModLoad imudp
$UDPServerRun 514

If you scroll down towards the bottom of the file we can see that it references to use all ‘conf’ files under /etc/rsyslog.d/ including where the default rules are kept in 50-default.conf.

Create/touch a new file calling it ’30-cisco.conf’, since we are only collecting syslog info for cisco devices on this occasion we shall chose this name. Append the file with the following lines of code:

# This rule runs in FRONT of the local/regular rules
# The below line sets a variable for the hostname and Cisco directory.

$template HostBasedLog,"/var/log/cisco/%HOSTNAME%.log"

# This creates a separate log file for each device

if $fromhost-ip == ‘192.168.0.1’ then -?HostBasedLog
& ~
if $fromhost-ip == ‘10.0.0.2’ then -?HostBasedLog
& ~

The above code sets up a template which creates the ‘cisco’ directory and also a log file using the hostname of the device the messages have come from.

From here we set the permsisions of the log directory for syslog service with ‘cd /var && sudo chown syslog:syslog log’

Restart the rsyslog service: ‘service rsyslog restart’

All that is left to do is configure our cisco devices to ship logs off to our syslog server. For a typical cisco router or switch we can simple do this from a conf t prompt with ‘logging x.x.x.x’ also setting desired trap levels with: ‘logging trap debugging’ for example.

There it is, a simple syslog server, as said previously this is just something to get you started with. The next level to think about is rotation of log files, backups secure transfer of the log files through TLS which rsyslog supports.

31st May 201630th April 2017

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.

1..1000 | % {$test= new-object system.Net.Sockets.TcpClient; 
$wait = $test.beginConnect("X.X.X.X",$_,$null,$null); 
($wait.asyncwaithandle.waitone(50,$false)); if($test.Connected)
{echo "$_ open"}else{echo "$_ closed"}} | select-string " "

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.

21st May 201630th April 2017

Microsoft LAPS – Unique passwords for your local Administrator accounts.

Managing local administrator passwords in the enterprise with ‘Microsoft LAPS Local Administrator Password Solution’.

When it was announed that CPasswords could be easily found and encrypted from the Groups.xml file created by Group Policy Preferences in May 2014 the enterprise needed a better solution to manage the local administrator accounts and more importantly the password being used. Commonly Group Policy Preferences were used to change the administrator account name and password across the enterprise workstations however the issue was two fold; the administrators password was written to a groups.xml file located in the sysvol directory (as well as locally) being written to the field ‘CPassword’ and also the same password would be used for all PC’s/laptops across the network. Should the password become compromised on one host an attacker could move laterally from one PC to another dumping creds. A better solution was required, enter LAPS! LAPS enables you to have a unique complex password for each domain joined machine (vista and above), the password being stored centrally in AD and restricted access to specific users (the helpdesk) via access control list. LAPS requires only .Net 4.0 and Powershell 2.0, however does require an AD schema update. LAPS is controlled from its own user interface and does require a small amount of GPO to be configured and client installed on the machine.

I’ll walk through setting up LAPS in a test lab and client setup in my next post.

21st May 201630th April 2017

Monitoring Domain Admins with PowerShell! Free and Easy

Free Active Directory Monitoring with PowerShell, keep an eye on those high privilege level groups!

Keeping an eye on privileged Active Directory groups is Important. We can do this by Monitoring Domain Admins with PowerShell. Groups such as ‘Domain Admins’ (DA) and ‘Enterprise Admins’ (EA) in Active Directory (AD) is vitally important within your IT shop. You need to be aware of any changes happening to high privilege level groups. Especially ones that have the level of access that DA and EA groups have. This of course also extends further than just administering AD privilege groups. In addition to these you may also want to monitor your high privilege level application groups. Such as Lync and SCCM. The worst case scenario is you find a username you not aware of has been dropped in your DA group. As soon as this happens you want to know and investigate immediately. You don’t need any fancy tools to monitor active directory groups. You just need a few lines of PowerShell coupled with the Send-MailMessage feature. Very quickly you have some powerful alerting.

Solution:

I’ve just pulled the below script together in a few minutes which very simple pulls the DA group and emails the contents to the desired location in the script.

$EmailBody = "The Domain Admin group has the following members verify these are correct:
              $currentmembers "

$currentmembers = (Get-ADGroupMember -Identity "Domain Admins").name | out-file -filepath C:\temp\currentmembers.txt

$Email = @{ 
            'From' = 'Active Directory Administrator <admin@test.lab>' 
            'To' = 'adam@test.lab'
            'Subject' = 'Current Domain Admin Members' 
            'SmtpServer' = 'my.smtpserver' 
            'Body' = $EmailBody 
        } 
        Send-MailMessage @Email

This is just a simple script to query the contents of a group and mail it. What you would ideally want is a comparison of a before and after state. In addition some intelligence within the script. This would be to either; email you if any changes have been made including the additions. O alternatively do nothing if no changes have been made. Then schedule the script to run every 5 minutes with Task Scheduler. This allows you to have pretty good overview of your high privilege accounts. Such a script thankfully already exists over at TechNet https://gallery.technet.microsoft.com/scriptcenter/Detect-Changes-to-AD-Group-012c3ffa

Alternative tools do exist such as SolarWinds LEM and ChangeAuditor. However using PowerShell is free after all and requires very little effort to implement! As a bonus you’ll boost your PowerShell skills.

5th May 201630th April 2017

Over the wire – bandit online terminal based war games delivered through SSH! Brilliant!

Over the wire – bandit – SSH War games!

I just thought I would share with you all Over the wire – bandit this is fun hacking practice game that you can play on online through SSH. It very addictive and once you start you will want to progress through the levels. Not stopping till you have finished. I started this and had to finish it. You can find it over at http://overthewire.org/wargames/ I found this through ‘The hackers playbook 2’ book of pentesting tips and tricks found here http://thehackerplaybook.com/dashboard/

Over The Wire - Bandit

Over the wire is a set of text based games, brought to you in a ‘capture the flag’ type style game where you ssh into there servers and crack the puzzle or code. The first series called ‘bandit’ is relatively straight forward with 26 levels. You start the game with a username and password to login to their servers via SSH. You can move up a level each time cracking the puzzle and obtaining the password to the next level. The bandit series is a great intro in its own right to bash as you have to use and combine tools and functions like grep, sort, base64 etc in order to crack the code. Each level finds you figuring out how to view/capture a text string which is the password to the next level. Head over to http://overthewire.org/wargames/ and check it out.

24th April 201630th April 2017

Metasploit database cache not built

Fixing Metasploit database cache

Just a quick reminder to myself and others of how to fix the Metasploit database cache not built issue. When we use Metasploit the search is super slow and returns the ‘slow search warning’ This where you find either the database isn’t connected or when you try to search for a vulnerability the return is ‘[!] Module database cache not built yet, using slow search’ due to the database not being connected like below: This doesn’t seem to be a huge issue and the search still works however its a fairly easy fix and makes the searching significantly quicker. I’ve posted this as I’m usually finding myself having forgotten the syntax to fix it after rebuilding a kali vm, and searching around various other posts on the internet for it, so here it is:

If we check the database in Metasploit with db_status we find the below error:

So to fix the issue:

Start the postgresql service and ensure it starts at startup:

Initialize the msf database with:

Load msfconsole and recheck the database you should find this is now connected:

Finally rebuild the db cache, give it a few minutes and you should find the search instantaneous :

et voila!

17th April 201630th April 2017

Cisco Access Control List Guidelines to follow when creating rules.

Cisco Access Control List Guidelines

Just a quick post to remind myself and others of 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.