[LAC-TF] Entrevista a Bob Hinden sobre Seguridad IPv6

[Alejandro Acosta]

Hola Fernando,
 Primero, mil gracias por los articulos, recomiendo a todos que se los
lean (independientemente que esten o no de acuerdo a lo que mencionan
los autores).
 Mis comentarios entre lineas:


On 2/25/12, Fernando Gont <fgont at si6networks.com> wrote:
> FYI:
> <http://searchsecurity.techtarget.com/news/2240118217/-RSA-2012-talk-to-offer-help-understanding-IPv6-security-issues>
>
> En lo personal, tengo una visión algo distinta sobre la última
> pregunta (*parte* de mi argumento estando descripto en
> <http://searchsecurity.techtarget.com/tip/IPv6-myths-Debunking-misconceptions-regarding-IPv6-security-features>...)

Casualmente tu vision distinta de la ultima pregunta, es tu ultimo
mito de ese articulo.
Aprovecho para preguntar: Entiendo que en IPv4 el network scan es con
fuerza bruta, en tu articulo indicas que ya no sera asi para IPv6.

Cito:

" that attackers are not performing IPv6 address scans with a
brute-force approach, but rather they are trying to improve their
scans by taking advantage of these known patterns of IPv6 address
assignments."

A que patrones te refieres?

Gracias, saludos,

>
> Saludos,
> Fernando
>
>
>
>
> RSA 2012 talk to offer help understanding IPv6 security issues
>
> Security professionals should begin learning about the emerging IPv6
> protocol now or they may end up scrambling at the last minute to update
> their security systems and networking equipment when it becomes
> unequivocally necessary to support the protocol, according to an expert
> speaking about IPv6 security issues at RSA Conference 2012.
>
> In an interview with SearchSecurity.com, Hinden explains why IPv6
> security issues can no longer be ignored, how IPv6 is most likely to be
> exploited by attackers, and what security pros must do to secure their
> networks in preparation for the IPv6 transition.
>
> For security pros who may not be as familiar with the evolution of IPv6,
> where are we today regarding deployment within the Internet
> infrastructure? Are mandatory enterprise IPv6 deployments on the horizon?
>
> Robert Hinden: Things have been moving a lot faster in the last couple
> of years, since people figured out the IPv4 addresses were going to be
> exhausted soon. That's what’s driving deployment now.
>
> The purpose of my talk is to give a heads up to enterprises who haven't
> been paying much attention. Enterprises, especially in North America,
> have a lot of IPv4 addresses, and the point I wanted them to understand
> is that IPv6 is built into a lot of the products they're running today.
> They need to think about that even if they're not running it inside
> their networks because there's the potential for unmonitored IPv6
> network tunnels to be created that go outside their firewall, and
> malware could use IPv6 for elicit communication. It's something security
> pros in enterprises need to start paying attention to. Security pros
> need to lead on IPv6.
>
> As of now, what's the most likely timeline in which enterprises will be
> forced to implement IPv6 to ensure connectivity with the rest of the
> Internet?
>
> Hinden: I've been doing this for a long time and I've learned not to try
> to make date predictions; it's hard to tell. But, I'm confident
> enterprises need to be paying attention to IPv6 security, figuring out
> what they're going to do, and not make this a fire drill. You don't want
> to be in a situation where you aren't prepared to implement IPv6
> securely if the [IPv4 address] exhaustion accelerates, and it's much
> easier if it's done gradually.
>
> As a whole, how capable are today's network security products at
> handling IPv6 traffic?
>
> Hinden: My impression is it's gotten much better in the last couple
> years. One issue I see is customers of security companies aren't running
> the more recent software for their products. If you're running something
> that's several years old, it's not going to have these IPv6
> capabilities. Some companies are reluctant to update for a variety of
> reasons, but it's time to do this.
>
> How mature are the IPv6 security features in the security products
> offered by vendors today?
>
> Hinden: It's hard for me to speak for all vendors, but certainly all the
> major vendors have tools that are ready for production. They're not beta
> anymore. This is newer code than the IPv4 code that's been around for 15
> years, so there are going to be bumps and there will probably be
> patches, but it's ready for production.
>
> How much education is required for network security pros who haven't
> dealt with securing IPv6 before?
>
> Hinden: That's one of the big things that's missing today.  The
> protocols are here, the vendors have products they can run, but
> enterprise staff needs to learn about IPv6, in general, and then about
> the specific security differences and how to handle them. That's the
> point of my talk at RSA, to raise awareness of this and encourage people
> to start doing that.
>
> For enterprise network security professionals going to RSA to learn
> about IPv6 capabilities in security products, what should be the key
> questions enterprises ask the vendors?
>
> Hinden: As they go around the show floor, I think they should ask the
> vendors not only what products they have, but also how they manage it.
> Do you use the same management interface? How have you tested your
> products? A good way to determine how mature a vendor's product is by
> asking if they can run their products with IPv4 turned off. Though I
> don't think most enterprises are going to do that for a long time.
>
> What concerns you most about IPv6 security?
>
> Hinden: It's twofold: One is that with the [IPv4 to IPv6] transition
> solutions, it's possible to create unauthorized tunnels into the
> enterprise. There are tunneling technologies included in Windows Vista
> and Windows 7 that allow tunneling through a NAT; it's basically IPv6
> under UDP under IPv4, making it possible to create a tunnel outside an
> enterprise that may go unnoticed. A user may do this purposely or he or
> she might turn on an application that creates an IPv6 tunnel – the "get
> me back to my PC"-type products like to do this – and all of the sudden
> you have this tunnel going through your NAT device. If that's your
> firewall then you may have a tunnel going through it that you would
> normally block. If you're not looking for it and you don't have any IPv6
> rules set up on your firewall, you may not see things leaving your network.
>
> The other is IPv6 as a covert channel for malware; malware that may use
> IPv6 as a way of communicating inside the enterprise. If you're not
> looking for this traffic, it could go host to host outside of the normal
> protections an enterprise deploys. You can't stop what you can't see and
> that's the message here. It's time for enterprises to start looking at
> the security of IPv6, and make sure their security tools have IPv6
> support in them now. You may have vendors that support it and you may
> not have turned it on. It's time to [turn it on]. This is an issue you
> don't want to have.
>
> There are a number of transition mechanisms being employed to ensure
> interoperability between IPv4 and IPv6 – dual-stack nodes, transition
> and tunneling paradigms – but those mechanisms appear to be a key
> security concern among experts. What's your take?
>
> Hinden: Say you're trying to decide whether to let a particular protocol
> through your firewall. You can't look at the same fixed place for the
> relevant info as you would for IPv4. There's more surface area, if you
> will, that needs to be examined. You need to have software security
> tools that understand the different security mechanisms of IPv6 and know
> how to parse them so you can look at the packet, find the relevant info
> and apply your relevant rules to it. Conceptually it's easy – it's all
> defined in the IPv6 RFCs – but you need to have special tools that can
> do this. When you work with your vendors, make sure they know how to do
> this.
>
> Some say widespread IP address scanning by attackers is not feasible
> with IPv6, but others have said attackers will likely have success
> exploiting known IPv6 distribution patterns or known ranges of assigned
> addresses. What's your reaction?
>
> Hinden: With standard addresses, the prefix will come from your ISP, and
> then the rest is related to each device's MAC address. It's hard to
> predict what MAC addresses are going to be used inside an enterprise. So
> that's still really hard. With addresses that are manually assigned,
> such as to routers on a subnet, if you assign those addresses
> sequentially, it is easier for someone to guess what those addresses
> would be. So as long as you think about the way you assign addresses and
> don't assign them sequentially, then it's a lot harder to guess what the
> addresses are.
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf
>