The Security Kitchen

It isn’t easy man…

You’ve been relying on that IPSec or L2TP VPN solution for a few years now. You’re either using a dedicated VPN solution (genre Cisco VPN Concentrator) or terminating VPN somewhere on your perimeter or in a DMZ (good thinking !!) and (hopefully) you got a set of policies and access control strategies to secure it even further.

You’re happy. Your users are happy. Why change ? Either you need to change to support the business needs or you have to change because the product you are using has been declared end of life. If the former is the case, you’re in a better position to evaluate because you (or your company) realized that the current setup just doesn’t cut it anymore. If the latter is the case, you might be reluctant to investigate your options. Your plate is already overfull and this is just another project that needed to be finished yesterday.

Wait … checking out all your options is worth it. And there aren’t that many … You can either remain with IPSec/L2TP or you can choose a SSL/TLS VPN Solution.  Both have pro’s and con’s though.

An IPSec solution needs a client installed on the workstation making the connection. That’s good because then you know only the people with the client (and the correct configuration) can connect. However, if you have external parties connecting (say service providers, consultants, …) how sure can you be that the client, the configuration and even the user certificate is not shared among multiple users ?

Most SSL/TLS VPN solutions do not require a client for limited functionality like web access to an internal website. Other functionality, like a VPN tunnel or RDP/Citrix access to a server, will require an ActiveX or Java control/applet to be installed on the endpoint. It isn’t clientless but the big advantage is that the user pulls the configuration and software from the box, you don’t need to distribute software and configurations.

Moving from one IPSec solution to the other requires thorough planning. If you change vendors, keep in mind that VPN client applications don’t tend to like eachother.  Most of the time you can not run 2 VPN Clients on the same box. This might have major implications on your road warriors who will come into the office only sporadically.  If something goes wrong, they lost their lifeline …. NOT GOOD.

Moving from IPSec to SSL/TLS however … while planning is still needed, it’s less of an headache because you only need to provide the new procedure to the end users. But the technology change might force you to rethink your architecture.

Some pointers :

- 2-Factor authentication : the main SSL/TLS VPN solutions support easy integration with 2-Factor authentication solutions. While it’ll cost you extra, I wouldn’t suggest SSL/TLS without it.  The least you wanna know is that the user connection to your network is who she says she is.

- Client verification : Since you are no longer in control of which endpoints your users use to connect to your network, you have to make sure that the endpoints meet a certain security standard.  To the very least, the solution should support OS detection, AV/AS detection. Most of the solutions go further and allow you to build granular policies to allow access to resources based on which endpoint connects.  John D connecting from a internet kiosk in Madagascar will have less functionality then the same user connecting with his company laptop.  Take your time to create the necessary profiles, for both users and endpoints.

- Single Sign-On : You can achieve this ! With SAML you can have your authentication and authorization information passed on to back-end website (your internal portal, a helpdesk application, a time registration application, …). This can bring huge benefits to the company.  (More info on SAML : http://en.wikipedia.org/wiki/SAML).

- Connection : if choosing an SSL/TLS solution, think about how you connect it.  The solutions usually allow single-legged or multi-legged configurations.  I would opt for at least a two-legged config.  The reason is simple.  All traffic from the endpoints reach the box encrypted, on an untrusted network. My gut tells me you can not send the unencrypted traffic over that same connection into your internal network.

Conclusion
Either implementation costs money. In my humble opinion, SSL/TLS solutions bring more additional benefits then IPSec/L2TP solutions because they allow you to support a broader base of user types and in general be more flexible in allowing or restricting access to internal resources.  If you choose SSL/TLS, think about the endpoints and how you can control them.

Yesterday, I was lucky enough to have a work gig in The Hague (The Netherlands), just when the SANS crew touched down for Secure Amsterdam and as they were organizing a community event, I took the chance to go see what they had to say.

As a sidenote: Larry Pesce, from Pauldotcom fame, was one of the teachers and since I felt sorry that while he was only 2 hours away from beer walhalla, he only had Heineken to choose from, I brought him some tasty Westmalle dubbel.

I arrived late because traffic was bad just before a holiday weekend and I dropped into the SANS introductory presentation.  All I remember from that was the lively discussion about the value of certification. Sorry, been there, done that, I’ve had 7 Microsoft t-shirts and lapel pins are great tools to learn kittens a lesson.  What I’m really trying to say is that every cert has it’s value. Whether it’s a vendor cert, a SANS cert or a CISSP doesn’t really matter.  The only guy that bugged me was someone who thought he had seen it all. You see that type of people and you immediately feel sorry for them because you just know they are on their way down. You’ve never seen it all dude, waving your business card with your unpronouncable title on it doesn’t make you ‘the man’. You’d like that, but it doesn’t.  ‘The man’ is the person who works his ass off every single day without claiming the limelight. The limelight you’re revelling in, might get your ass burned, badly. Anyway, I disgress …

After the break it was time for Larry’s preso on Metadata, the silent lesson.  You can find an up to date version of that preso on the pauldotcom website . Key points of this presentation were that metadata is really everywhere and there’s great fun to be had with.  Looking at document metadata can teach you a lot of information about the persons or companies you’re investigating. I’ve done some testing before and what you can achieve with documents and photos from the web is really amazing. In short : really great preso, cleanly delivered by a very knowledgeable and skilled presenter.  This is the kind of stuff you wanna see more often.

The last preso of the night was delivered by govcert.nl . While the presentation was build around a great concept, I think it ended up being a blow in the water.  They bundled some of the results of their research into some kind of gameshow concept (odd one out) but unluckily it wasn’t really entertaining.  Most of the challenges were geared towards a Dutch public while I felt the crowd at this event was more international and that’s the reason why they all fell in the water.  Belgians, French, German and/or English people can’t tell the difference between Geert Wilders and a chimpansee, let alone knowing who he is. What I also missed was context. Why was this one the odd one out and what could’ve been done to prevent the data breach you meant to touch upon. Wait, there was some stuff about popups and boners that was really fun.

And there we arrive at a very big soapbox of mine.  We, as Security Professionals, kinda love reading about new attack vectors, and we revel in the fame that becomes our part when we can come with something new. However, when you present something new, I expect you to do the following :

a) tell me what it is that is so special about what you found.
b) tell me how it works, what it does and obviously how I can do it.
c) and then it is your friggin responsibility to tell me how the f* I can protect myself from it.

It’s one thing to find a hole and I have lots of respect for researchers that do that each and every day.
The really great know how to educate.

That be all.

Stay Secure !

It’s old news and honestly, this shouldn’t happen on networks that are administered by capable network admins. Thruth is, it still happens and it’s damn difficult to track down. In this blogpost, I will try to illustrate the process of finding the rogue device and provide you with some information on how to prevent it from happening again.

DHCP is a broadcast protocol, a client on your network requesting an IP address will broadcast this request (over UDP port 68) and any DHCP server seeing this request will reply.  The client will accept the address from whichever server provides an address first. Whenever a client has received an address, he will start communicating on the network, not caring about which server he received the information from. He will however contact the DHCP server again after 50% of the lease time, to extend it’s lease. If the server doesn’t answer, the client will attempt again after 50% of the remaining time and will continue to do that until he receives a reply or when the lease expires, thus rendering himself unable to communicate.

Now, the rogue server might be on your network for quite a while before you notice problems and that depends mainly on your lease time. When things start to go south, you will notice.  Your helpdesk will be swamped in calls from people who wish to be attended to as soon as possible.

There is NO WAY you will be able to find the server in a timely manner by checking each and every box seperately. Then how can you find the culprit and remove the problem from your network ?

Step 1 : define which range the machine is distributing. In most cases this will not be the same range as the one that you use.  On one of the victim hosts, you can run ‘ipconfig /all’ to find the range and also the ip address of the malicious DHCP server.  From the same host ping that server, then execute the ‘arp -a’ command, jot down the ip address and the MAC address of the rogue server.  Now we can begin the real work.

In this case, arp is our best friend.  log on to your core switch (assuming you know the passwords …). Every switch in your network keeps an arp table, so it knows what MAC address is connected to which port.  The command to retrieve this information is different on all platforms.

‘show mac-address-table‘ is the command you want to use on Cisco
‘display arp‘ is it’s 3com counterpart
‘show mac-address‘ on HP Procurve equipment

in the list (which can be really long on your core infrastructure) find the MAC address you jotted down.  It might be the case, as it was in mine, that you will not find the exact MAC address. xx-xx-xx-xx-xx-ab might be the address you retrieved from the host, and you will only find xx-xx-xx-xx-xx-aa is in your switch.  In that case, take the address that is closest to the address you found.

From there, you execute the same command on the switch that is connected on the port that was indicated in the arp table of the core switch and you repeat the process until you find the port where the server is connected.  Either shut the port down or pay a visit to the person responsible for the mayhem.

To prevent this from every happening again, you can use build-in features on your switch !!

HP Procurve
dhcp-snooping [ip address] will configure ‘authorized’ DHCP servers.

Cisco
ip dhcp snooping enables dhcp snooping
ip dhcp snooping trust needs to be configured on interfaces where your DHCP server(s) are connected

These settings will actually allow you to never have to think about this issue ever again.  It sure beats cleaning up the mess !

A final note, most rogue DHCP servers are accidents.  People having a virtual machine running that has a dhcp daemon running without them knowing.  Don’t be too hard on the owners of the systems. Sure it’s stupid, but you were at least as stupid for not configuring your network to prevent it from even happening. Also, if you even remotely care about your network, please make sure that your documentation is up to date, including uplink port numbers. There’s only one thing worse than no documentation and that is incomplete documentation.

Cheers,

Stay Secure.