Re: IPv6, IPSEC and DoS
Re: IPv6, IPSEC and DoS On Mon, 3 Jan 2005, Mohacsi Janos wrote: To prevent ARP or ND spoofing attack you should have L2 switch support to it! Or you can use static ARP or ND entries, which is rather difficult to maintain. Regards, Janos Mohacsi Funny you should mention this I thought about this but figure the following, regardless of VLAN/PVLAN/ settings, switches still need to build an ARP table so I would think that one can still inject bogus ARP information but it would likely but delegated to that particular segment where the MAC's are being spoofed from. There was an instance last year where I saw a student using some form of LAN generator for him to be able to spoof a network in order to play some XBOX game. Packeteers saw multiple MAC addresses coming from the ports in his room. When we investigated the situation he told us what it was the program was doing and we advised him to limit it via pseudo threat of disconnecting his port. So what happens when an ARP generating programs collides with the address of your L2 switch or a database. VLAN/PVLAN even static ARP entries won't help much. At least I don't think there is much that can be done when someone is determined. I could be wrong I am almost 99.999% of the times. Even an exhaustion attack could do some major damage. http://www.infiltrated.net/cisco/vlan-insecurities.html http://www.infiltrated.net/cisco/vlan-tagging-101.html http://www.infiltrated.net/cisco/layer2-security.pdf Aside from this, I've noticed there are quite a few OS' that still have issues regarding IPv6 // http://seclists.org/lists/fulldisclosure/2004/Mar/1412.html III. Impact It may be possible for a local attacker to read portions of kernel memory, resulting in disclosure of sensitive information. A local attacker can cause a system panic. // Not to single out this one instance, there was also an issue with OpenBSD, I'm sure I could find others for Windows, NetBSD as well. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D sil @ politrix . orghttp://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net How a man plays the game shows something of his character - how he loses shows all - Mr. Luckey
Re: IPv6, IPSEC and DoS
On 3-jan-05, at 16:29, J. Oquendo wrote: To prevent ARP or ND spoofing attack you should have L2 switch support to it! Or you can use static ARP or ND entries, which is rather difficult to maintain. Funny you should mention this I thought about this but figure the following, regardless of VLAN/PVLAN/ settings, switches still need to build an ARP table Yes, and that's why you need static MAC forwarding tables too. If you can then enforce the port-MAC-IP mappings you're pretty much bullet proof. I know there are switches that can handle the port-MAC part. An alternative for the MAC-IP part would be the TCP MD5 option or IPsec.
Re: IPv6, IPSEC and DoS
--- Iljitsch van Beijnum [EMAIL PROTECTED] wrote:
If you can then enforce the port-MAC-IP mappings
you're pretty much
bullet proof. I know there are switches that can
handle the port-MAC
part. An alternative for the MAC-IP part would be
the TCP MD5 option
or IPsec.
I guess it's true that everything old is new again:
isn't this effectively circuit-switching? If you're
dedicating network elements to particular hosts in a
non-dynamic manner, doesn't that make your
infrastructure effectively a PBX, where moving
{device} from one room to the next requires a a
technician's assistance?
-David Barak
=
David BarakNeed Geek Rock? Try The Franchise.
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: IPv6, IPSEC and DoS
On 3 Jan 2005, at 11:11, David Barak wrote: I guess it's true that everything old is new again: isn't this effectively circuit-switching? No, it's packet-switching with a provisioning process reminiscent of the Book of Telco. Static provisioning does not a circuit make. Joe
Re: IPv6, IPSEC and DoS
--- Joe Abley [EMAIL PROTECTED] wrote: No, it's packet-switching with a provisioning process reminiscent of the Book of Telco. Static provisioning does not a circuit make. Point made - what I was trying to say was that it has most of the disadvantages of a circuit-switched architecture... = David Barak Need Geek Rock? Try The Franchise. __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com
Re: IPv6, IPSEC and DoS
On Mon, 3 Jan 2005, Joe Abley wrote: On 3 Jan 2005, at 11:11, David Barak wrote: I guess it's true that everything old is new again: isn't this effectively circuit-switching? No, it's packet-switching with a provisioning process reminiscent of the Book of Telco. Static provisioning does not a circuit make. you could go one step further to make it circuit switching and static route all traffic in both directions to the individual /128's... talk about FUN!
Re: IPv6, IPSEC and DoS
On Mon, 3 Jan 2005, David Barak wrote:
I guess it's true that everything old is new again:
isn't this effectively circuit-switching? If you're
dedicating network elements to particular hosts in a
non-dynamic manner, doesn't that make your
infrastructure effectively a PBX, where moving
{device} from one room to the next requires a a
technician's assistance?
Not necessarily. Some public networks are moving away from the ask
everyone the question, anyone can answer model. It cuts down on the
chatter, and the spoofing. That doesn't mean you have to go to a static
provisioning model, but it does mean you have to think harder about what
you trust, what asks the questions and what answers the questions. You
can still have a dynamic network, as long as it doesn't learn the wrong
things.
Re: IPv6, IPSEC and DoS
On Mon, 3 Jan 2005, Sean Donelan wrote: Not necessarily. Some public networks are moving away from the ask everyone the question, anyone can answer model. It cuts down on the chatter, and the spoofing. That doesn't mean you have to go to a static provisioning model, but it does mean you have to think harder about what you trust, what asks the questions and what answers the questions. One example is the typical cable modem provider. A DOCSIS modem is provisioned with a MAC address known to the telco, and effectively creates a virtual port on a huge switch^Whub with the modem's MAC as the port identifier. The MAC of the device behind the virtual port is then provisioned using some sort of interface that detects and stores that MAC address as associated with the modem. At that point it's easy to automate the process and allow packets from known MAC addresses through only their associated virtual ports. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: IPv6, IPSEC and DoS
On 1-jan-05, at 22:20, Rob Thomas wrote: ] But as long as people get to snif your packets, you're dead in the ] water unless you use IPsec. The same is often said about SSL for web transactions. This is why keystroke loggers are so popular in bots and other malware. The point is that folks shouldn't assume that encrypted packets keep them safe. Encryption != security. Well, then use IPsec between your keyboard and the host. :-) And IPsec != encryption. Obviously there are many ways to be insecure even if you use IPsec, but my point is that if someone can snif your packets, they always get to break your sessions unless you use IPsec (or TCP MD5). Even SSL doesn't do you any good since it sits on top of TCP which leaves TCP vulnerable. SSL however will make sure that IF your session stays up whatever data makes it through hasn't been modified and even if sniffed, the clear text isn't available to others.
Re: IPv6, IPSEC and DoS
On 2-jan-05, at 4:07, [EMAIL PROTECTED] wrote: No, that list is just a starting point for the discussion. A lot of stuff in the list doesn't amount to anything. (For instance, there is no ARP in IPv6.) Yeah, ARP is basically one machine yelling Who has this IP? and another one answering ME!! ME!!. In IPv6, there's something called Neighbor Discovery where one machine yells Who has this address? and another one yells back ME!! ME!!. Totally different things :) The base functionality is obviously the same. It's implemented quite differently, though. (Note that they both do the exact same thing to make sure the correct machine is yelling ME!! ME!!) Really? So ARP uses SEND? ( http://www.ietf.org/html.charters/OLD/send-charter.html ) (Although living in a hostile subnet isn't something I would recommend in the first place. Being on the same link opens way too many additional attack vectors.)
Re: IPv6, IPSEC and DoS
On Sun, 02 Jan 2005 11:26:09 +0100, Iljitsch van Beijnum said: Really? So ARP uses SEND? ( http://www.ietf.org/html.charters/OLD/send-charter.html ) Neighbor Discovery doesn't *USE* SEND yet, either I seem to be unable to find the RFC numbers for SEND (except 3756 for the threat model). Lacking those, and lacking widespread support for said RFCs across both router vendors and end-user boxes, I have to call the *current deployable* Neighbor Discovery as doing the same thing as ARP - essentially nothing. What release of IOS did SEND become stable in? What release of other router software did it become stable? What release(s) of Windows, Linux, and Solaris did the support become stable? Yes, a year or two down the road, there will hopefully be deployable code. But not now. pgpfc4oM9nu2f.pgp Description: PGP signature
Re: IPv6, IPSEC and DoS
On 1-jan-05, at 2:22, J. Oquendo wrote: Supposedly the vulns associated with IPv6 are: reconnaissance, unauth'd access, layers 3-4 spoofing, ARP and DHCP attacks, smurfs, routing attacks, viruses andworms, translations, transistions, and tunneling mechanisms. According to Sean Covery's IPv6 Security Threats (http://www.seanconvery.com/SEC-2003.pdf) No, that list is just a starting point for the discussion. A lot of stuff in the list doesn't amount to anything. (For instance, there is no ARP in IPv6.) I don't understand your example, BTW. But as long as people get to snif your packets, you're dead in the water unless you use IPsec.
Re: IPv6, IPSEC and DoS
Hi, NANOGers. ] But as long as people get to snif your packets, you're dead in the ] water unless you use IPsec. The same is often said about SSL for web transactions. This is why keystroke loggers are so popular in bots and other malware. The point is that folks shouldn't assume that encrypted packets keep them safe. Encryption != security. Thanks, Rob. -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
Re: IPv6, IPSEC and DoS
On Sat, 01 Jan 2005 12:16:02 +0100, Iljitsch van Beijnum said: No, that list is just a starting point for the discussion. A lot of stuff in the list doesn't amount to anything. (For instance, there is no ARP in IPv6.) Yeah, ARP is basically one machine yelling Who has this IP? and another one answering ME!! ME!!. In IPv6, there's something called Neighbor Discovery where one machine yells Who has this address? and another one yells back ME!! ME!!. Totally different things :) (Note that they both do the exact same thing to make sure the correct machine is yelling ME!! ME!!) pgpGgkZrQtpNu.pgp Description: PGP signature
Re: IPv6, IPSEC and DoS
On Fri, 31 Dec 2004, J. Oquendo wrote: On Sat, 1 Jan 2005, Christopher L. Morrow wrote: Some of this 'not follow it now' is partly due to equipment problems. These problems should be disappearring from many larger networks as new gear is cycled in over the next couple of years. The option will then be available to the engineers that operate the networks, they will likely still prefer the 'closest to the end system router' make the filtering decision though. I think I've mentioned this before... Why isn't it standard by default. To which most replied about the ever changing BOGON addresses. It would be nice to see a Trusted repository that all equipment could pass to and from information. sure, this is part of 'to urpf or not to urpf by default on lan interfaces'. I think the vendor folks, and some operators, thought that 'changing defaults might be a bad thing'. There are lots of unintended consequences to urpf or not :( Personally, I'd love to see all LAN interfaces properly 'urpf' (or some version of that). Even moving upstream from the LAN to the WAN, CPE properly anti-spoof filtering (reverse 2627 filtering) would be a good start. I am not convinced that doing this sort of thing from a 'central trusted repository' (even a distributed central repository) is a good plan for 'everyone' though. take the cases of large 'internet' sized networks that are not 'the internet', getting them a copy or even them USING this methodology isn't necessarily possible, or required. This, btw, is part of the 'one secure' or 'secure default' or whatever-its-called-secure cisco template/config-option thingy... which is already out-of-date? your company likely has this capability, or could have it today... They also likely don't want you wasting company time buying things on ebay or amazon... your company, in the US, likely has this in their HR/Employee handbook in the form of some 'corporate assets are for corporate use only' statement. Indeed no one wants their resources wasted, but what about those in the financial industries where monetary information is being sent. Surely no They have their vpns and 'secure networks' and other methods... many of their transactions probably pass in the clear from DB to DB to DB, on local LANs or on private WANs. (speculation of course, perhaps their 3des is 3des'd and all is perfect and nice, who knows) one wants that information being passed. On that note of network waste, for those who do have those types of policies, that's what content management is for in my opinion. If it hasn't been fully implemented, than why call the kettle black. actually, those policies are there to fire people with, nothing more... no one polices them to any reasnable level. We once had a large and well known consulting firm for which we could see firewall logs, while watching the logs scroll by their laison mentioned how well their people knew their policies about sexual harassment and such... I think I asked: Hmm, so what is www.indialove.com do you think?? Oh, porn yea, one of your well informed employees is spending HOURS looking through that site, right now... Anyway, go policies! :) Once again... Happy New Year everyone... Going going gone... not quite gone yet, 2.75 hours remain! :)
