Posted on

Overview of IPv6 event with Cisco

Introduction

I was fortunate enough to have recently been invited to a  Cisco event in Glasgow. It ran over 1.5 days and was broken down in to several sessions ranging from 15 minutes to three hours. This was a free event for attendees but I’m assuming with venue costs, materials and staffing, it wasn’t cheap for Cisco to host. Not that I’ll feel sorry for them, but with a number of these type of events being lined up over the coming months, I guess it will add up.

Day 1

The morning contained no less than five sessions:

  • IPv4 exhaustion and implications
  • IPv6 notation and address types
  • Address planning
  • IPv6 routing
  • Transition mechanisms

So far, so good. Some of this was revision for me, however the address planning section was a key reason for my attendance as I wanted to make sure the plan we had back at the office wasn’t heading off down the wrong track. Lunch was provided but as we were over running a little, we risked indigestion by wolfing it down and getting back down to the good stuff.

The afternoon was supposed to be:

  • Presentation from a new start-up, PresenceOrb, on how they have embraced IPv6
  • Cisco IT giving us insight in to how they deployed IPv6
  • Three hours of hand-on labs

Or at least that was the plan. About 15 minutes before the end of Khalid Jawaid’s excellent discussion re. Cisco IT, the fire alarm went off and, due to it being genuine, we lost 90 minutes stood outside on the pavement. Well, perhaps 60 minutes and the remainder in a local coffee shop. Upon returning to the training room we got the tail end of Khalid’s presentation but then only had an hour of the hand’s on labs. Thankfully, we were given the lab instructions so I am able to continue the lab at home.

Day 2

This was just a half day and covered five sessions:

  • Presentation from a consultancy firm, Farrpoint
  • A more in depth look at the current state of the IPv6 landscape
  • Discussion of IPv6 security and comparison to IPv4
  • Application demo of IPv6 connectivity in mobile devices
  • Final Q&A session

The IPv6 landscape presentation was given by Steve Simlo, Product Manager for IPv6 in Cisco Systems. I found it to be of great value, especially the online resources that were shared. Steve is also a Manchester City fan so he really knows his stuff 😉

The security discussion was, as you would expect, a little dry, but covered a wide range of topics and had a good IPv4 comparison thrown in. The demonstration was finally left out, which didn’t really bother anybody as it left more time for the Q&A session.

Summary

Overall, I was really impressed with this event. It ticked several boxes for me:

  • Free. OK, I don’t usually stump up cash for these but being free meant my work were more obliging in letting me attend
  • Higher number of shorter sessions. I get easily bored on most five day training courses, unless the trainer is at the top of their game. 15-60 minute sessions can be much more productive
  • High quality presenters. The Cisco guys were excellent, presenting well and knew the material. Very impressive. The two guest speakers were also good and there was very little in the way of a sales pitch from them
  • High quality advice. Outside of the sessions themselves, I was able to grab the Cisco experts and get some nitty gritty details out of them. You can’t beat face to face interaction for getting that kind of useful information

I think Cisco hit the nail on the head with this event. The topic itself is getting more pertinent with each IPv4 address that gets used up and its good to see an industry giant getting a wide range of people (approximately 50 attendees) all thinking about moving forward with IPv6 adoption.

Till the next time.

Posted on

Logging options on the Cisco ASA

Introduction

Logging is a critical function of any device in your network, but perhaps even more so on a firewall. Whether you are troubleshooting an issue, following an audit trail or just wanting to know what is going on at any time, being able to view generated logs is highly valuable. This post looks at logging options on the Cisco ASA and discusses some of the things you need to consider.

Tick tock

It’s all very well looking through your logs as individual events but if you want to tie them together, particularly across multiple devices, then you need to ensure that all of your devices have the correct time configured. Nothing says ‘I love you’ more than a time stamp that you can trust. If you use a centralised logging solution, you can filter logs across multiple devices to help determine root cause of issues. You can configure time on the ASA manually by using the following commands:

The above lines configure the time, the timezone relative to UTC and the daylight savings time settings respectively. There is a battery on the motherboard of the ASA that will keep the time should the device lose power or be rebooted. However, locally configured time can drift over…time, so what we really want is to use a trusted external time source that all devices synchronise against and this is where NTP comes in.

Lines 1-2 above dictate that we should be using authentication with NTP for added security and gives a key to use. Line 3 is required to advise the ASA that this key is trusted. Line 4 tells us which server to use, which interface it can be found on and which authentication key to use. It also tells the ASA to prefer this time source over other NTP servers of the same judged accuracy based on what stratum they are in. You should configure at least two NTP servers for redundancy. In the event that all servers are unavailable for an extended period, the ASA can fall back to using the local clock. NTP is a Jekyll and Hyde protocol. It can be as simple to understand as the last section or you can dive deep in to it’s bowels and be lost forever.

Log destination

Logs can be sent to several destinations but before I list them, it should be noted that logs come from two key sources, system events and network events. System events include things like CPU errors, network events include packets being denied on a certain interface. Both types of messages are dealt with by the logging subsystem and are then potentially filtered prior to being sent to one of the following destinations:

  • Console – logs sent here can be viewed in real time when you are connected to the serial port. As this causes CPU interrupts for each message, you need to be careful when enabling this
  • ASDM – logs can be viewed in the ASDM GUI. From here, you can quickly build filters, colour code the logs by severity and save the log as a local text file to be dealt with later or simply archived
  • Monitor – logs to a Telnet or SSH session. But you don’t still use Telnet for management do you?!?
  • Buffered – this is the internal memory buffer
  • Host – a remote syslog server
  • SNMP – rather than sending logs remotely using the syslog syntax, you can use SNMP to send a trap
  • Mail – send generated logs via SMTP
  • Flow-export-syslogs – send event messages via NetFlow v9

Log severity levels

Before I show some examples of how to configure different logging, it’s worth looking at the different severity levels available to us. There are eight in total as per Cisco’s definitions below:

Numeric level Name Definition
0 Emergencies  Extremely critical “system unusable” messages
1 Alerts Messages that require immediate administrator action
2 Critical A critical condition
3 Errors An error message (also the level of many access list deny messages)
4 Warnings A warning message (also the level of many other access list deny messages)
5 Notifications A normal but significant condition (such as an interface coming online)
6 Informational An informational message (such as a session being created or torn down)
7 Debugging A debug message or detailed accounting message

By selecting a lower severity (with a higher number), you are also opting in to everything with a higher severity e.g. level 4 will not only log all warnings but all errors, critical, alert and emergency logs. Be wary of selecting too low a severity level, particularly on the console. You can quickly bring a device to it’s knees if it’s getting hammered.

Examples

Here are some examples to show how to get things up and running.

Line 1 enables logging globally. We then enable timestamps on the log messages, without which it’s difficult to tell when an event occurred. Line 3 configures the size of the local buffer memory. Once this fills up, it is overwritten in a circular fashion. Lines 4 and 5 configure the buffered and monitor destinations previously discussed for the same level, the first using the keyword ‘warnings’ and the second using the equivalent numerical value. Both are interchangeable but will show in various command outputs using the keyword regardless (except in the logs themselves, where the numerical form will display). Lines 6 and 7 are configured together for remote syslog logging. Line 6 enables the logging at the specified level (in this case informational) and line 7 configures the syslog server IP address and the interface it can be found on.

Line 8 allows various other attributes to be included in each log message. In this case, it will include the hostname but can also include the firewall IP address of a particular interface, the context name (where used) or a specific string. The latter could be useful for using regular expressions for refining logs at a more granular level.

Finally, the show logging command will firstly show the different settings for each logging destination and then the current contents of the local log buffer. Below is an example of its output with just the first log entry for brevity (please note the enabled settings below are not by any means ideal for a production environment, you need to consider what is best for yours):

One thing to note about logging to Telnet\SSH sessions using the monitor destination. Whilst you may have this enabled and will be able to see the messages logged count in the above output rising each time, you may find yourself confused as to why, whilst SSH’d on to your ASA, you aren’t seeing the logs on your screen. To view logs for the current session, assuming they are enabled, you need to type this command in whilst connected:

and the logs will start appearing according to the severity level you have set. In a move that I can only attribute to Cisco allowing a drunken intern to come up with the command to negate the above one, somebody settled on:

Thanks drunken intern guy. To finish off this post, I’ll bundle some other commands together with a brief description:

If you have a pair of firewalls configured in a failover configuration, you can enter the first command to enable logging on the standby unit also. Just be aware of the increase in traffic if logging externally to the ASA. The second line will additionally send debug messages to any configured syslog servers, which is disabled by default. Again, this can cause a severe increase in traffic, especially if you enable lots of debugs. The last command changes messages to a proprietary Cisco format and to be honest, I don’t think its used much at all.

Summary

Hopefully you will have learnt a couple of extra things you can do with logging from this post but you can dive even deeper and I suggest you do to get the most out of this critical function. For example, you can archive buffered logs to the local flash or to a remote FTP server, you can disable certain messages completely or just filter them from certain destinations. You can also change the default severity of individual messages to better suit your environment. It would require a certain amount of initial work but would be easily repeatable across your estate.

A great place to learn more is to use the ASDM console which, despite me being a CLI fiend on the ASA, comes in to its own when configuring and reviewing logs. Also pay special attention to what level of logging you have for each destination. I’ve only covered a couple of key points on how best to do this (e.g. disable console logging) as what works best depends on your environment. If possible though, try to use a centralised Syslog server and use the ASDM logging due to it’s immediate nature and filtering capabilities.

Till the next time.

Posted on

Top IT podcasts

Introduction

I thought it would be valuable to some readers if I collated a list of the top IT podcasts in one place and gave a brief description of each of them. Who am I kidding? This list will also be helpful to me as I get older and start forgetting more and more things. Some of these shows were new to me so I went on a marathon session before reviewing.

Breakdown

  • Packet Pushers – this was the first networking podcast I started listening to and its still my favourite. It is hosted by Greg Ferro and Ethan Banks, both who have been in the industry long enough to know a thing or two. Topics cover protocols, hardware, design, security, certification, a little bit of SDN, etc. There have been a few attempts at other podcast streams under the Packet Pushers banner. The Priority Queue is used to deep dive on niche topics and Healthy Paranoia is an excellent security focused podcast hosted by Michele Chubirka. There was a Wrath of the Data Center show that was based around the CCIE Data Center certification hosted by Tony Bourke but it withered away after only a couple of shows. There is a growing blogger community too and also a forum. PP has further presence on IRC, Twitter, Facebook and Google+. Apart from the mostly great content, the thing that really works for me is how Ethan and Greg compliment each other so well. Add in Michele’s insane approach to introducing her show and in depth knowledge and it adds up to a fun learning experience. Expect a new show about once a week
  • No Strings Attached – love wireless? Then look no further. Hosts include Sam Clements, Jennifer Huber, Blake Krone and George Stefanick. The show is relatively new, hitting the airwaves in January 2012. This is obviously a more specialised show than some of the others but, already at show 19, they are still producing great content at about a show every 2-3 weeks. Topics include hardware from different vendors, software and the ever evolving 802.11 standards
  • Class C Block – this is the newest of the shows listed here, only producing it’s first show in September 2012. Since then the hosts, CJ Infantino and Matthew Stone, have produced a show roughly every 2-3 weeks, although it has sadly ground to a halt. Topics cover IPv6, studying, design, and MPLS. Give them your support by getting over there and having a listen and if you like, drop them a comment. There is nothing like positive feedback and high consumption figures to motivate more content. I found this podcast quite refreshing for the most part. You can sense the guys wanting to learn themselves as much as feed back to the community. Just a shame it ran out of steam
  • Risky Business – another more specialised and award winning show, this time focusing on security. This is the longest running show featured here having been born in February 2007 and produces a show every 1-2 weeks. Don’t feel overawed by the 200+ shows, go back up to six months and start from there, dipping in to any older shows that take your fancy
  • Social Engineer.org – a resource rich website, it focuses on what is for me, the most intriguing aspect to Information Security. The show itself started in October 2009 and is produced about once a month. Topics have included pretexting, NLP, penetration testing and Kevin Mitnick. The main host, Chris Hadnagy is excellent and he has a number of  supporting panelists, such as Dave Kennedy, who all offer something different to make this one of my favourites. The quality of the guests always impresses
  • Arrested DevOps – This is one of my favourite more recent podcasts with a good line up of industry folk and content. The show notes are always top notch with full transcriptions too. Some of the topics include hiring in IT and dealing with failure

Summary

Have I missed your favourite? If so, add it in the comments below with a brief synopsis as I have above. Try at least a couple from each of those listed above and let the hosts know what you think.

Till the next time.

Posted on

(I always feel like) somebody’s watching me

Introduction

Rockwell was a true visionary of his time. His mega hit of the 80’s after which this post is titled always takes me back to my childhood and puts a smile on my face. OK, perhaps I’ve given him too much credit in my opening statement but I was recently reminded of this song at an InfoSec event I attended in January. There were some great presentations from vendors, professionals and amateur hackers alike. It was one of these sessions in particular that made me go ‘wow’ so I thought I’d write it up.

Snoopy

I would like, if I may, to take you on a strange journey. Imagine yourself walking through a busy city, perhaps on your daily commute or just sightseeing. How would you feel if at the end of the day, somebody who you had never met before approached you and showed you a picture of your house, told you where you worked and also which park you like to drop your kids off at each Saturday morning? Of course, things would be even more creepy if somebody had that information but decided to not tell you. It might sound like a bad movie plot. It might also sound like a scaremongering tale or at the very least, highly unlikely due to the assumed effort to collect such information.

Step in Snoopy, a distributed tracking and profiling framework. Using a geographical distribution of wireless access points (WAPs) called drones, they can track a person’s movements as they move around the catchment area. They do this using the MAC address of the mobile device you carry with you e.g. phone, iPad, etc. and take advantage of the chatty nature of WiFi enabled devices. Your device will broadcast on a regular basis trying to find every SSID it has connected to. To use some overly obvious examples, a phone could be trying to find the following wireless networks:

  • MyHomeHub3874
  • CompanyA-Guest
  • MoonBucksCoffee4242
  • CityYAirport

The drone devices themselves can be contained in a very small form factor. You could for example use a Raspberry Pi or even make a custom device. They can be battery powered but imagine one in a mains pluggable air freshener form factor. Blends in nicely and is continuously powered for free. They can be made for about £20-£30 so if anybody finds and removes one, the cost to replace is acceptable. By placing 50 or so of these around a city at key ‘people centric’ places such as train stations, shopping centres, sports stadiums etc., you can cover a large area very well.

The drones also have 3G or better to connect, via OpenVPN, to a server so that data collection can be centralised and also to provide Internet connectivity for clients when it wants to take things to the next level. Before I explore that though, you can see how the person mentioned at the start of this post could quickly glean the information he or she was after. As you walk past any of these droid APs, it detects the SSIDs that you have connected to and with a tip of the hat to Google with their massive war driving initiative as part of mapping the world, can determine the geographical locations of each of these. As long as the SSID is unique and has been mapped to a publicly accessible database, then it’s a breeze to link devices to locations. The next step, which is a bit more naughty is to use the AP as a classic rogue i.e. now allow the client to connect to it by spoofing the SSID. This only works on open networks i.e. those that haven’t been secured with WEP\WPA(2).

At this point, the mobile clients can start accessing the Internet via the rogue AP. This is bad enough yet to make matters worse the connection is proxied via the centralised server meaning that all traffic can be analysed further. That’s a lot of data being collated at the central server but the fun really begins when that data is processed for habits and patterns.

Maltego

Although Snoopy is lesser known, many of you may already have heard of or even used Maltego. It is touted as an intelligence and forensics application which can mine a source of data (in our case, the data collected from the drones on the central server) and present it in a visual form. It allows the creation of custom transforms which analyses relationships between people, networks, websites, social services etc.

Putting it all together

Now imagine how these two tools can be combined. As our unsuspecting victim, you walk in to MoonBucks located near a drone device which listens to your phone’s broadcasts. The AP easily becomes MoonBucksCoffee4242 and your phone connects. You buy yourself a mocha choca latte with an extra shot and decide to check a couple of things online whilst you fuel up. You first head over to Facebook, then check your Twitter feed. Perhaps you also log on to LinkedIn, Google+ and whatever else takes your fancy.

Between Snoopy and Maltego, there is all sorts of interesting pwnage that can be had. As stated in my initial paragraph covering Snoopy, it is easy to see which SSIDs you have connected to and where they are located but as soon as you connect and start browsing, it can soon be determined relatively easily who you are based on the sites and profiles you are viewing.

Taking it further and introducing time based data i.e.  going beyond a single session, it can now be determined who you are and where you are. Over a period of time, patterns may show up that suggest you take sick days after a big sports event on a Sunday, on Wednesdays you work in a different office, the first day after pay-day you tend to be running an hour later than usual, etc.

Let’s consider a scenario that doesn’t require as much data crunching. If somebody wanted to track a particular person, one way to determine the MAC address of his mobile device would be to set up a droid at an event that person was known to be attending. Do this a couple more times at other events and then use Maltego to extract the unique MAC addresses. You might get lucky and whittle this down to a single MAC after only two events (i.e. the tracked person is the only one to attend both events), perhaps three or four but if you can now get that device to connect to the Internet via your AP, you can link all activity to that one person. I’ll leave it up to your imagination as to what devastation could ensue.

Summary

This is all relatively cheap to get set up and working. As a hacking project, I find this fascinating but it should be obvious how, in the wrong hands, your privacy could easily be torn down. Once you mine the data to a deeper level and begin to correlate the movements of multiple people, both physically and online, then your habits basically become an open book.

We are all accustomed to a seamless mobile experience these days but how do you mitigate this kind of attack? Again, it’s the ongoing balancing act between security and usability. This post is highlighting the possibility of such an attack. There are certain steps you can take to make sure you are not connecting to a rogue AP but it’s difficult to block many mobile devices from advertising the networks they have already connected to. This is all posted as food for thought and I hope it was of as interest to you as it was to me.

Till the next time.

Posted on

Cisco Live London 2013 – preview

Introduction

It’s that time of year again, Cisco Live London 2013. Last year, I was a virgin to Cisco Live but my cherry was popped about 30 minutes in to the technical seminar on the Monday. By the end of the week, I had learnt an incredible amount of useful information, not just technically focused but also about how the event works. Things like when is best to visit the World of Solutions, how the waiting lists for sessions work and how to survive on four hours sleep a night (this latter point, to be truthful, was learnt during the 1st six months of my daughter’s life).

Up until very recently, I thought I would be joining the sessions via Cisco Live 365 online and then out of nowhere came an offer of a ticket. I got the chance to create my account only six days before the event but, after an initial fear that I would have nothing but the dregs to choose from, was happy to see that I could fill my schedule with things of interest to me.

Last year’s agenda

In short, I will be avoiding the following topics that I hit heavily last year:

  • WAN optimization. Working for an ISP, we have many customers coming in to our core network via WAN links for either Internet access, Inter-site traffic or to access hosted clouds
  • IPv6. I needed to get up to speed on this quickly for my CCNP studies. I don’t think there is going to be much movement towards adoption in the UK over the next 12 months. If I’m proved wrong and, as a company, we decide to make a move to deploy in that time, last year’s sessions will hold me in good stead regardless and I’ll be able to hit the ground running
  • WiFi. I had a WiFi deployment project coming up at this time last year so I squeezed a few related sessions in which were most useful

I also attended some routing based labs and sessions. I found that once I came back from last year’s event, my motivation to complete my CCNP (I still had the ROUTE and TSHOOT exams left) went through the roof.

This year’s agenda

With all of that in mind, I’ve broken this year’s sessions in to the following broad topics:

  • Security. Those who read my blog know that I am currently studying towards my CCNP Security. I’m booked in to a number of related sessions that cover ASAs, IPS and advanced remote access configuration. I’ve no doubt I’ll get the same motivation to get cracking with my studies upon my return
  • Data centre. I sat in on a few related sessions last year, including a monster technical seminar on the Monday that blew my mind. At that time, it was more out of interest that I attended these events. This year, we have UCS in our data centre with Nexus on it’s way so it is imperative that I turn up the heat. There are even a couple of SDN sessions in there. I’ve had so much SDN thrown at me over the last 12-18 months from various sources that I am hoping to let some of this finally crystallise in to understanding!
  • Keynotes. I found last year’s quite interesting. I’ll be keen to see how Cisco are viewing the world right now and what their vision of the future is
  • Socialising. An extremely important aspect of any event such as this. Last year, I met some great people and learnt things outside of the sessions. I ate curry and drank beer and a good time was had by all. I fully expect to top this at 2013’s event

Summary

Watch this space for some related blog posts. Last year, I was like a giddy teenager who had stolen the keys to his dad’s sports car and was blogging every night in to the wee hours. This year, rather than talk about the event in summary daily posts, I plan on putting together some more technically focused posts, which may take longer but will hopefully be of value to some readers.

If you are going, give me a shout and we’ll meet up.

Till the next time.

Posted on

Cisco ASA Identity Firewall

Introduction

When the CTO approached me asking how access to a subnet was restricted, I advised him that the people who needed access were given a DHCP reservation and an ACL on a Cisco ASA limited those IP addresses to certain destination hosts on certain ports. It wasn’t scalable and it wasn’t particularly secure. For example, if one of those users wanted to log on to a different machine, they would get a different IP address and access would break. If their computer NIC got sick and needed replacing, same thing. Worse still, anybody could log on to their machine and get access to the same resources or give themselves a static IP when the other user had their computer turned off and nobody would be the wiser.

I had been looking at a number of methods to address this, such as 802.1x authentication\application proxy and during our discussion, we both came to the conclusion that it would be pretty cool if we could restrict access via usernames, especially if this could remain transparent to those users. This would give us the flexibility and transparency we were looking for whilst maintaining the required level of security. Isn’t that the perfect balance that we strive for in IT security?

!!!DRUM ROLL!!!

Enter the Identity Firewall feature on the Cisco ASA platform. This is a new feature available from software version 8.4(2). The Identity Firewall integrates with Active Directory using an external (to the ASA) agent. The Cisco.com website has a host of documentation on the feature which you should follow to get it up and running but below is a summary of how it works, some things to be aware of and my thoughts on the feature.

How it works

First of all, this feature has three main components. The ASA itself, Active Directory and an agent which sits on one of your domain machines and feeds information back to the ASA. There are a number of prerequisites you need to make sure are in place and rules you must follow before rolling this out e.g. AD must be installed on certain OS versions, same for the server the agent is on, you can have multiple agents for redundancy but only one installed on a domain controller, you must configure the correct level of domain wide security auditing, ensure host firewalls are opened accordingly. The configuration guide does a pretty good job of listing all of these and I would heartily recommend you check it out if deploying the feature.

There is also the relatively small matter of creating an account in AD that the ASA will use to communicate with AD. You also need to create some config on the ASA itself made up of a mix of AAA and specific ‘user-identity’ commands. The agent is configured via the command prompt (or Powershell prompt as I tend to always use since I fell in love with it deploying Exchange 2007). You set up which AD servers it should be monitoring (you want to point it to all DCs that will be logging account logon\logoff events) and then which clients (ASAs) the agents will be reporting to. You can also configure Syslog servers for better accounting.

In a nutshell, the agent is checking the security logs of the DCs to see who is logging on and with what IP address. It adds this information to a local cache and sends it to the configured ASA clients. This is done using Radius. The ASA also talks directly to AD using LDAP to get AD group membership. The final piece of the puzzle is enabling the Identity Firewall so that all of these components start talking. At this stage, there are various commands you can run via the agent or on the ASA to confirm the communication is working as expected.

It is then a matter of creating ACLs that utilise users and\or groups and giving them access to resources. You can also combine this with source IP which means you can say Fred can access Server X when he is in Subnet Y but if he moves, he loses access. If Janet logs on to Fred’s original machine, she could have the same IP but won’t be given the same access due to her username not being in the ACL.

I found setting it all up very easy. However, circumstance led to it being some time before all interested parties were happy with the outcome e.g. the firewall being used had recently been upgraded from 8.0 code to 8.4, and a load of migrated NAT rules started playing up, muddying the waters. The positive side to this was that the firewall config has been streamlined considerably. There was also the morning spent troubleshooting a single user’s issue that ended up being down to him not being in the correct AD group as assumed. That said, I think it’s a pretty robust feature for what is effectively a first iteration.

Testing

I’ve tried to break it a number of ways e.g. pull an authorised user’s network cable out of their machine, give myself their static IP, but without being logged on as them, my username\IP pairing doesn’t match what the firewall thinks. There are a number of timers involved with this feature that might trip you up if you don’t understand them e.g. the firewall can only check group membership every hour at best, meaning if you remove a user from a group, they could still retain access. Worse still, if you disable their account in AD but keep them in the group, they will still have access until their Kerberos ticket expires. You can manually update group membership on the ASA if this would be an issue for you. I would guess that if it is, the person has been marched out of the building at that point anyway.

VPN logon vs AD logon

Another thing to be aware of is remote VPN access. When you remote VPN on, you get authenticated to the firewall. This could be via local ASA accounts, Radius, TACACS, ACS, LDAP etc. If you use AAA LDAP authentication (using Active Directory in this case), you are not logging on to the domain as you VPN in, you are simply saying ‘here are my AD credentials, please authenticate me on the firewall’. At that point, one of two things happens with the Identity Firewall. If you are using a domain computer to remote on, that machine will automatically try to make contact with a DC. When it finds one (over the VPN), it will log on to the domain, create a security log and the AD agent will let the ASA know. Any rules assigned to that user, that don’t filter on source IP, will now come in to effect. However, if the machine is not joined to the domain, there will be no logon event (the username\password given at connection was only for VPN authentication), and so any user-identity ACLs will not apply.

In the latter case, you may want to create a specific VPN connection profile with specific DHCP pool for example and go back to restricting by IP, only allowing users in a certain AD group for example to be able to connect to that profile. Not ideal, but it would work.

Summary

In summary, I really like this feature. It answers a number of questions specific to the environment I have implemented it in. Things I particularly like are its ease of setup including the troubleshooting commands to aid with this. Learning the syntax of the ACLs is a simple task, as they extend upon existing IP-based ACLs. I also like the fact that there are several ‘under the hood’ settings you can tweak to improve security further still e.g. remove users from the cache if their machine as been idle for a certain amount of time, force LDAP lookups over SSL.

Something that I wasn’t so keen on was the split communication i.e. the ASA getting group membership directly from AD, IP mapping from the agent. I would like to see the agent providing the group membership too. It should also not be too hard to tell the agent which groups to keep a closer eye on (the ones used in ACLs sounds like a good start). This would allow the ACL to be updated much quicker should a group be amended.

I would love to hear what others’ experience of this feature has been. Overall, I am very pleased with it and look forward to upcoming improvements.

Edit: additional points

A few other points I should highlight, if you move to a different subnet the new IP address will be picked up as long as your device authenticates with the domain. I tested this early on by disconnecting my laptop from the wired network with a persistent ping happening in the background. I then VPN’d back to the office via the WiFi network and within a couple of seconds of the connection be made, the ping reestablished.

The second point which will hopefully save somebody a head ache out there; a user testing this functionality was reporting it working as expected until they would open a spreadsheet that would make a data connection to a SQL database in a different subnet. The user had access to this SQL database as allowed by the Identity Firewall ACLs but as soon as the data was refreshed in the spreadsheet, he would get kicked. I could see it happening using the ASA and AD agent troubleshooting commands too. After a little bit of head scratching, we realised that the spreadsheet data connection was using a different set of domain credentials to connect to the database. This triggered a logon event for the user’s IP address but with the user account for the data connection. In turn, the AD Agent updated the cache with the new user and IP combination and denied the traffic based on the ACL. One answer to this would be to add the data connection account to the ACL but in the end, we just connected to the database in the spreadsheet using the user’s own credentials. This highlights the fact that, whilst a user can be affiliated with multiple IP addresses, only one user can be affiliated with any one IP address, which is the key to making this feature secure.

One last thing which is perhaps the most important, considering this is a discussion about a security feature. If your users connect via a shared IP address, you should be aware. For example, if your users log on to a Terminal Server, they will all be coming from the same IP address by default. That means that if a user with elevated permissions logs on to the TS, all other users will effectively gain the same access as permitted via the Identity Firewall. My advice would be to deny access via a shared IP address to any resources that need restricted access.

Till the next time.

Posted on

New Year’s resolutions 2012

Just before the end of January hits us, I thought it would be a good idea to put my 2012 study wish list down in writing in the form of New Year’s resolutions. This will not only be a valuable checklist for me, but will provide motivation as the year moves on and putting it on my website will drive me on further.

I want to do the numbered items in that order. I’m being sensible this year as I want to make sure my CCNP reflects a good knowledge and not just good exam skills, especially with me only moving over to networking officially last year.

2013 should be even more exciting, but I’ll not be setting those goals in stone until nearer the time. I already have a good idea of what I want to do next year but I’ll be more focused if I keep that open and get my head down for the list below.

  1. CCNP ROUTE – having already passed the SWITCH exam at the tail end of 2011, I’ve already started studying for the ROUTE exam and have just about got EIGRP and OSPF out of the way. I’m hoping an IPv6 class I’m taking at Cisco Live London next week will help me in that area and that leaves BGP and route redistribution for when I return. However, I’m not in any rush and have a date for the exam of May time pencilled in
  2. CCNP TSHOOT – I want to give myself three months from passing ROUTE to have a go at this exam. Again, that’s plenty of time but I really want to make sure my CCNP is solid. After all, it’s just another step on the journey…one that never ends
  3. CCDA – no set time for this one other than just wanting it by the end of the year. I think design skills are critical for any IT engineer, but in particular in the field of networking. As well as giving you an understanding of why the pieces of the puzzle do, or perhaps do not work together when troubleshooting existing networks, it is a skill required of network architects
  4. CCNA specialism – not sure which one. I like the idea of doing the Wireless and I love the whole topic of IT security. Either way, I intend on getting both of them, but only have my sights set on one for 2012. With a new wireless deployment coming up at one of our offices, I think I may let that sway my decision for now

Till the next time.