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.

9th March 20165th November 2016

Block and Stream Ciphers

Symmetric Encryption Techniques – Block and Stream Ciphers.

Two types of symmetric encryption techniques that are used are Block and Stream Ciphers, in this post I will cover them both in a high level comparison.

Block Ciphers

Block ciphers take a section of plaintext (a block) and turns them into block of ciphertext of 64 or 128 bits. The block size is how much data is encrypted in one go.

The output from a block cipher is usually larger than the input data, due to the ciphertext being a multiple of the orginal block size.

Common modes of operation block ciphers are Cipher Block Chaining (CBC) and Electronic Codebook (ECB). Block ciphers include DES with a 64-bit block size and AES with a 128-bit block size.

Stream Ciphers

Stream ciphers encrypt plaintext one byte or one bit at a time, as opposed to a block of data at a time as with a block cipher. With a stream cipher, the conversion of these smaller plaintext sections of data can vary, depending on when they are viewed during the encryption process. Stream ciphers can be much faster than block ciphers, and usually do not increase the message size, because they can encrypt an any specific number of bits.

Stream ciphers include RC4 (and the RC series) ciphers. DES can also be used in stream cipher mode.

6th March 20165th January 2017

Mitigating VLAN Hopping Attacks

Ways to mitigate VLAN Hopping Attacks on a Cisco Switch.

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.

4th March 20165th November 2016

Drown

‘Drown’ Vulnerability in SSLv2 and TLS.

Drown SSL TLS This week sees a new vulnerability in SSLv2 and TLS. The ‘Drown’ vulnerability standing for “Decrypting RSA using Obsolete and Weakened eNcryption”, this is already sounds pretty harrowing to anyway in the security field, anything with RSA decryption and weakened encryption you know is not going to be good. Matthew Green does a great job in explaining all about this so I won’t attempt to regurgitate his excellent explanation, other than to highlight the issue and to say this doesn’t look good at all and I encourage you to read his blog and take note of this vulnerability:

http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html

This just highlights that fact that when a penetration tester tells you you still have SSL issues present on your sever you should definitely look into doing something about it as described by myself here: https://www.adamcouch.co.uk/2015/09/10/changing-ssl-tls-cipher-suites-in-windows-and-linux/