The Security Kitchen

(and shameless self promotion)

Most of y’all know I was a speaker at Excaliburcon in Wuxi, China a few weeks ago.  I have loads of pictures, but not a lot of the feature me   Today our awesome host (Dr. Xu Rong Sheng) forwarded me some pictures.  Here they are.

Yours truly in action

I learn most from interacting with an people

The awesome people that ARE Excaliburcon 1

Visiting the research center they’re building in Wuxi

So, my brother bought this new fancy HP laptop with Windows 7 and he asked me to prep it for him. You know the drill, basic settings, install software, configure network adapters, install anti-crapware (preferably free), …

While uninstalling some of the packaged software (Norton, MS Works, some trial versions of other craptastic software), My eye fell on the (nowadays) ubiquitous Adobe software packages that were installed.  Adobe AIR 1.5.0 (the latest version available from Adobe is 1.5.2) and Adobe Acrobat Reader 9.1.0 (latest = 9.2.0) . A quick look at http://www.securityfocus.com showed that several exploits exist.

And then to know that the first 15 minutes starting a new HP laptop are spent looking at an update screen where HP happily tells you that it’s installing the *latest* updates.

Things will never change …

I hereby release the slides of the presentation I did at Excaliburcon in Wuxi, China.  Be on the lookout for the next edition, cuz this con is really promising.

Go figure out for yourself …

As I’m sitting here in the lobby of the Kempinski hotel I’m still figuring out what happened here in Wuxi.  Jayson Street and Ming Zhou took on the challenge to organize the first real hacker/infosec conference in China and did they succeed? Yes, they did.

With a good presence of international security people like Ian Amit, Chris Nickerson, Adam Laurie, Nathan Hamiel, FX and plenty plenty more good content was assured and the outturn was pretty awesome too for a first edition in a place where this kind of conferences is not commonplace (yet).

On a personal level, I’ve made a ton of new friends and engaged in some pretty good debate about information security …

I’ll probably write more later as I’m still a little dazed and confused from what happened but that’s a good thing !

Wuxi and Excaliburcon rocked, watch out for the coming editions of this awesome conference !!

As most of you already know, I’ll be speaking at Excaliburcon in Wuxi, China this week. I’m not sure whether I’ll be able to post from there but you can follow all the action on their website : http://www.newcamelotcouncil.com/INDEXEN.html .

I’m looking forward to meeting up with some pals I made at Brucon and meeting some new people … and for me, after exactly 10 years, it’s a blast to finally be able to visit one of the countries I love the most on this planet (don’t try to get me into political discussions, that’s a whole different story).

Anyway … I’m off, will keep you updated whenever possible OR post a recap when it’s over.

再见

A few days ago someone asked me advice because he was planning to put a web server up in the DMZ, and he wasn’t entirely sure how to go about that. Our conversation ended with him saying that I was probably gonna blog about this in the style of  “Someone was asking stupid questions regarding DMZs …”, so here’s that blog … in a different style.

First up, there are no stupid questions.  Where would I earn the right to feel high and mighty because I know more about networks than you? There’s another million things I don’t know shit about. To go even farther, I probably learned more from this conversation than you

Here’s my view of the (old school) DMZ.

What is a DMZ ?

The name DMZ comes from the military term, Demilitarized Zone, we only wanted to have it’s proper TLA (Three Letter Acronym) so it would sound cooler.  In the military, the DMZ is a pretty dangerous place to be.  Best case you have guns pointing at you from both sides, worst case they’re shooting you to smithereens.

On a network, we create a DMZ to locate components that will interact with users or machines that are in an untrusted zone. Why ? Because the risk that these components are compromised is much bigger and if they would be in our trusted (internal) network, the havoc when it happened would be immense. The DMZ gives us control over the traffic that is allowed to and from the boxes, from both sides.

Option 1 : the multihomed firewall

In my humble opinion, a good SMB or branch office solution.  Assuming you don’t have to much internet-facing services. We set up one interface of the firewall for internet access, one interface connects to our DMZ and the third one connects to our LAN.  The rule of thumb here is to tightly control access from the internet to our (blue) box in the DMZ, make sure no access from the DMZ box to the internal network is allowed and strictly control access from the LAN to the box in the DMZ.

Option 2 : back to back firewalls

You have extensive needs for internet facing services and you have a budget too?  Good ! Back to back firewalls give you a lot more flexibility.  In the drawing I’ve created an internal and an external DMZ.  Your webserver (the blue box) is in the external DMZ and you control access from the internet tightly.  Access to this server from the LAN is extremly limited (ssh only, maybe even from a management LAN?).  You might have noticed the orange server in the internal DMZ.  Imagine that your webserver needs to present data from an internal database?  Your worst decision might be to have the webserver connect directly to your internal database.  So we set up a database server in a seperate subnet and replicate a (read-only) subset of our database, containing only the data we actually need, to this server.  Again, the proof of the pudding is in the tasting.  You are going to limit access between any of the subnets to only that what is strictly needed to get the job done ! And even then you are reviewing this on a periodic basis.

Option 3 : Don’t try this at home

I hope you noticed what is wrong here.  You have put your server in the DMZ but also added a secondary interface that is connected directly to your LAN.  This is a recipe for disaster.  Sure, it’s easy to work with but by doing this you are connecting an untrusted zone with a trusted zone and bypassing your firewall in one go.  Any pwnage of the server will result in pwnage of your entire internal network.  It even hurt my eyes to draw this option.  Let’s move on !

Option 4 : A special case

This is a scenario that is well-suited for a web application firewall (but not the best solution !).  Assume that incoming traffic is encrypted (HTTPS over TCP/443) and traffic to the server behind the WAF is not encrypted.  SSL termination is on the WAF.  If we would implement scenario one, we would have unencrypted traffic travelling over an untrusted network, the same DMZ link.  If someone would breach our DMZ, it would be trivial to snoop in on that traffic.  To avoid this, we create a secondary DMZ. Thus we have an external DMZ where our encrypted traffic flows and another DMZ where the unencrypted traffic flows.

Again, the key is to control access to any machine on any network controlled by you.  And check on it !

Note :

This is a very rudimentary overview of DMZ setups. I’m sure you can find more elaborate versions somewhere on the internet, but I didn’t want to disappoint you The rest of the discussion, we will continue over a few good beers.