Renato Salles <rsalles,AT,rsnetservices,DOT,com,DOT,br>|
Re: CRC32 - thoughts on Gutmann response|
"R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>|
Fri, 26 Sep 2003 10:50:13 -0600|
On Friday 26 September 2003 08:02 am, Renato Salles wrote:
> [snip] ... as a small Linux firm as we are, our custommers
> trust us: they beleive we know what we're doing when deploing a VPN
> solution to them. A security break could have deep legal and financial
> concerns to us
My small company is in the same position as yours, and I share your concerns.
> [the customer asks] ... why do you keep using it after
> knowing that, even if in very speciall circunstances the privacy and
> the content's integrity could be compromised?
Even if your plan is to move everyone off CIPE, the more customers you have
and the more they rely on those tunnels, the more time it will take to plan
and execute a move that is not disruptive to their businesses. I know I'm
preaching to the choir, but it's much more likely we cause our customers pain
by a botched transition than their being compromised. So, no matter what
one's position on CIPE is, being clear and concise in our understanding of
the CIPE issue is critical, since the problem can't go away immediately in
In this light, perhaps we can come up with "best practices" to secure CIPE as
much as possible during the transition period, whether it be to a new product
or to a fixed version of CIPE. Here's what we've done, either before or as a
result of this issue.
1. Audit the subnet to which CIPE interfaces connect. Rooted machines in
subnet would pose a significant threat to network security and availability,
not just as a launch point for a CIPE attack.
2. Audit the machine on which CIPE itself runs. Hopefully that machine has
intrusion detection facilities already in place. Update to latest security
patches, etc. I don't recommend updating software that does not specifically
address a security issue right now, unless you need it for another reason.
3. Verify configuration and latest patches for routers on subnets containing
CIPE tunnel endpoints. Verify especially that the router is dropping spoofed
packets, source routed packets, etc.
4. firewall rules: lock CIPE traffic to endpoint IP addresses and ports (if
static IPs), preferably on the CIPE box itself.
5. Apply iptables rules to the traffic passing through the CIPE tunnels
- deny all as default (if you can)
- allow only the traffic one needs
- use 'limit' to limit connections where you can (ICMP, etc.)
- look carefully at non-TCP traffic; this is the stuff most likely to
- If you're bridging, there appears other issues not easily protected
I believe there are still situations were CIPE provides effective protection
(I reserve the right to change my mind as the key management stuff is
investigated). We must also find the right balance between cost, exposure,
risk, and availability. If a revised CIPE addressing the CRC-32 issue could
become available in 2 weeks (just a random, soon date), the solution is
likely different than if it takes 4 months (a random, late date). Just be
sure to consider this balance as you plan your course of action.
> I'll continue to follow the developement list closely, giving a hand to
> the newbees when it's possible, but my intention is to stop imediately to
> deploy CIPE to new clients until all this concers become more clearly
> adressed and the main developpers of CIPE decide themselves where are we
> going to.
Prudent. The real issue is current installations. I'm hopeful the guys with
the big brains might come up with an interim security solution for CIPE in
short order that gives us more options in our decision process.
All the best,
Titanium Mirror, Inc.