Saturday, February 18th, 2012
At my job I am very lucky to get to work with so many interesting people. I work on designs, breaches, and pushing products to their limits on a daily basis. This is very fun but there is a drawback. Being that I work primarily with security designs I often can’t share the details of my work. Even a bit of architectural knowledge about my customers could give an attacker the edge. While I can’t talk about the details and who it was for I often do get a chance to speak out on my work in a generic fashion. There are a few ways I get to do this. Most of my work stays hidden inside of my company but occasionally I get to do work outside and share my thoughts. One of my favorite ways to do this is via a webinar. Its a short one hour (or less) to review a particular topic of interest and takes some questions and answers.
Next Tuesday I will be giving another webinar. This one will is of particular interest to me as it will cover a hot industry topic, application security. Application security in the sense of how we came to focus on applications and where security will go to next. I love it because it talks a bit more toward some future ideas of security rather than just covering the products. While I love the products I think people can get a good marketing pitch anywhere. I rather talk about those deeply burning technical ideas that lead people to think. In a world where we are surrounded by advertisements its nice to get some substance.
As I said my next webinar will be on Tuesday February 21st at 9am PST. If you would like to join click on the link below to register. I will be doing a Twitter Q&A as well after the event. I will give everyone 24 hours to tweet me at @junipernetworks, @junipersecurity, or @robwcam with the hash tag #jnprq (Juniper Question) and I will write a blog giving all my answers by the end of the week. I look forward to hearing from you after the webinar. My good college and friend Bill Pfeifer (@webguppy) will also be joining me to talk security.
Wednesday, February 1st, 2012
I received a great question through the Twitterverse about IPS with IPSec. The question comes from @brian38401 “@robWcam Any thoughts on inspecting #IPSec traffic with an #IPS? Since inspection tends to mis order frames…performance problem?”. This is a great question Brian and we will be glad to help out. I asked my team about this and here is what we came up with.
Generally we do not see people utilizing IPS to protect IPSec terminating gateways. Generally IPSec does a pretty good job of securing itself. IPSec has built in protections to ensure that the remote gateway is who it says it is and it does its best at preventing injected packets. There always could be issues with the vendor’s IPSec implementation and this could lead to possible exploitation. For this reason you may want to consider implementing IPS, but in the ~90 years with of security experience on my team we don’t typically see this being done. If you did choose to use IPS with IPSec it would introduce additional latency (based upon the IPS device) but for most vendors this would be sub millisecond and really wouldn’t impact your service.
Now there are some good things you can do to mitigate risks with IPSec. The first is to lock down who can terminate IPSec connections to you. If possible use an upstream router to put hard access lists about which sources can terminate to you (assuming static sites). You would want to limit this to IKE, ESP, and AH (if your using it). This way only the gateways you want to negotiate with you can access your IPSec gateway. Secondly you want to rate limit IKE connections going toward your IPSec gateway. This can be done and should be done for all gateways. It could be possible to ramp up invalid IKE connections and this would exhaust resources on the IPSec gateway. This is an attack that you would want to prevent against. I won’t say that its common, but it is something we do see quite often.
Thanks again for the question Brian, we here at @JuniperNetworks are always happy to help!