Re: CRC32 - thoughts on Gutmann response

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 
most scenarios.

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 this 
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 
	  be exploitable
	- 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,

Steve McKown
Titanium Mirror, Inc.


--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>