security Archives - Page 2 of 2

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.

7th September 201523rd November 2016

Linux Firewall

Check out the Linux Firewall mini setup guide which demonstrates the use of iptables in Linux. Here I demonstrate a few basic commands and rules and explained how we can allow and deny specific traffic on your Linux server. The scenario is for typical web server allowing only HTTP, HTTPS and SSH. Host based firewalls are often overlooked relying solely on perimeter defenses however are an important aspect of protecting your endpoint whether that is on a server or workstation. Iptables in built into Linux is a pretty capable command line based stateful firewall. Once you have the hang on the syntax it is fairly straightforward to implement and customize to your own requirements.

Click to check out the full Linux Firewall iptables mini guide here.

29th August 201523rd November 2016

Greetings!

Greetings! Welcome to my InfoSec Site!

Here I will be mostly be talking to myself about Information Security Topics, News, and mini guides. Feel free to join in and comment!

I am also going to be sharing some of the latest Labs and Projects that I am currently working on, short tutorials that I have been through and had to learn along the way. This will be both Windows and Linux based. I will also be sharing some Security techniques, not only in an effort to raise awareness for Information Security, but also to use as my own quick lookup when I need to remember something!

I was inspired to create this site after listening to Defensive Security Podcast and subsequently reading an article titled How to build a successful information security career on their site.