Re: We hit half-million: The Cidr Report
Security is a layered approach though. I can't recall any server or service that runs in listening state (and reachable from public address space) that hasn't had some type of remotely exploitable vulnerability. It's hard to lean on operating systems and software companies to default services to off. When you run netstat -a on a lot of operating systems there are too many things in listening state without a convincing enough reason. NAT is stateful only out of necessity but after IPv6 a small layer of security will go away but there is potentially another alternative. Scanning blocks of IPv6 addresses for valid hosts is mostly a waste of time but you could do things like looking at server logs or getting IP addresses of clients you are connected with on P2P networks. A good way to prevent that is to assign multiple IPv6 addresses to operating systems as security zones so a source address a browser or P2P client would use is not the same one with potentially remotely exploitable services running in listening state. As a bonus they should probably take it one step further and just place web browsers and email clients in a dedicated VM sandbox that can be blown out and recreated in case of infection or persistent browser toolbars and stuff. So far malware seems to be winning the war so it might be best to just acknowledge that people are likely to be attacked successfully and attempt to quarantine it when it happens. It would probably be less intrusive than trying to force people into restricted user accounts so I never understood why nobody ever really pushed for this. Technical users have been running suspect code and links in VM's for a while now. On Wed, Apr 30, 2014 at 1:13 AM, Owen DeLong o...@delong.com wrote: On Apr 29, 2014, at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”. Owen
Re: We hit half-million: The Cidr Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 29/04/2014 04:39, valdis.kletni...@vt.edu a écrit : Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? Deaggs can legitimatelly occur for a different purpose : hijack prevention (Pilosov Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. - -- Jérôme Nicolle -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNg94YACgkQbt+nwQamihvv6wCdFS6gqfUJwD0m/OelYdWjCZui S9cAnAkxlWyM4/JJmTPKxPWKYRXbz/c0 =vuYo -END PGP SIGNATURE-
Re: We hit half-million: The Cidr Report
Just out of curiosity, how does removing port address translation from the equation magically and suddenly make everything exposed, and un-invent the firewall? -Blake On Tue, Apr 29, 2014 at 11:00 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 11:37 PM, TheIpv6guy . wrote: On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell jeff-k...@utc.edu wrote: On 4/29/2014 2:06 PM, Owen DeLong wrote: If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of can't get there from here... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?). The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago. Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks. These are ports that were originally open by default... and if you don't have a perimeter policy, you're wrong (policy, compliance, regulation, etc). Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... Jeff
North NJ LATA 224
Anyone selling IP over ATM / Frame Relay in North NJ Verizon LATA 224 that could carve a PVC real fast?
Re: We hit half-million: The Cidr Report
On 4/30/14, 12:00 AM, Jeff Kell jeff-k...@utc.edu wrote: Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... This is emphatically not true. All PCI compliance requires is that your private IP addresses are not disclosed to the public, which could be RFC1918, NAT, firewalling, proxies, creative routing, etc. --Josh hates this misconception.
Re: We hit half-million: The Cidr Report
On Apr 30, 2014, at 09:15 , Jérôme Nicolle jer...@ceriz.fr wrote: Le 29/04/2014 04:39, valdis.kletni...@vt.edu a écrit : Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? Deaggs can legitimatelly occur for a different purpose : hijack prevention (Pilosov Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. The idea I have a 'reason' for hurting everyone else, so it is OK has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
RE: We hit half-million: The Cidr Report
Behalf Of Jeff Kell Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. Jamie
Re: We hit half-million: The Cidr Report
On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) pgpIfdP2icDUY.pgp Description: PGP signature
Re: We hit half-million: The Cidr Report
On 4/30/14, 9:30 AM, valdis.kletni...@vt.edu wrote: On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) So, I've been (fomerly) involved in the design/build/operation/refresh of pci environments as part of application services for enterprise with ~ order of .8 billion annually in online sales. The process starts at the beginning e.g. before you build it. If you parachute in a consultant or auditor totally cold, you are going to have to educate them to the nuances of your particular operation, it's is very similar with SOX controls. In any event your documentation should be order. and actual operation should be as documented. Ultimately as was my experience with FIPA/HERPA compliance in the educational environment these should not taken as mysterious externalities foisted on operations by hostile regulators, or industrial cartels, but as part of normal business operations, and internalized as such. signature.asc Description: OpenPGP digital signature
Re: We hit half-million: The Cidr Report
Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) In my previous jobs when I was doing FIPS/NIST/whatever compliance, it ended up being the case that having a highlighted copy of the spec document worked wonders most of the time. Barring that, the one place where I had a problem with this also had a COO who was formerly a shark-in-an-$8000-suit type of lawyer, and he was often able to explain to a clue-free auditor's boss exactly what would happen if they failed us despite the fact we met the spec as written (starting with reporting them to the PCI guys in charge of maintaining the list of qualified auditors). It's been my general experience that one must vet auditors in the same way one vets other vendors of intangible products--carefully and thoroughly, lest they screw you. Spend the same amount of energy you'd spend choosing the appropriate corporate lawyers or outsourced HR. -- Josh
Re: We hit half-million: The Cidr Report
Patrick, Le 30/04/2014 16:54, Patrick W. Gilmore a écrit : It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea. I totally agree with you. It's a shame to have to consider bad practices from a network perspective as necessities from a security standpoint. That beeing said, let's try to consider adverse interests on that matter. Large routing tables are an issue for smaller networks generating less value than major players usually providing transits to others. The constant growth of the routing table gives a technical and economical advantages to established carriers (roughly the same arguing OTTs _must_ pay premium PNIs because of an arbitrary ratio-driven peering policy). The necessity for higher-end routers to provide transit services could also slow down the steep fall of transit prices. It would establish a sensible barrier to newcomers on local transit services. It's also reducing the value of older equipments and killing the grey-market and brokers. Well, the power-draw of 6500's and other oldies could be enough, but their unability to scale to today's standards helps newer hardware sales. Now there would be a smart way to handle the issue with SDN. A smart network controler could manage a larger RIB with ease and provide routing-ASICs with a virtualy agregated FIB much smaller than the previous 256k routes limit, thus creating more interest for older routing-switches. Would a manufacturer develop such a smart conroller ? Nah, let's sell bigger overpriced TCAMs instead. Oh, and of course, the argument about hijack-prevention would disapear if everyone was doing there part and deploy RPKI in a matter of weeks. As did everyone feel the responsability to deploy IPv6, for that matter. See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. I'm not sure we're on the same page here. De-agregating with a no-export tag will have no effect at all but on TE between the orinating AS and its transit provider. If the more specific prefix isn't propagated, a hijack may occur locally anywhere else on the Internet. Let's consider someone willing to intercept mails from major hosted services (gmail, outlook...) to a company connected through bad transits. The hijacker would simply announce the more specific prefix on a few IXPs and win the reachability. The backchannel route could then be established over any other T1 (who won't pick up the more-specific anyway). Simply put, you have to be no more than one hop away from most IXPs to get a decent hijack-proof reachability. De-agg with no-export is a nonsense. The idea I have a 'reason' for hurting everyone else, so it is OK has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. Alright, let's implement new policies at a RIR, IXPs and T1s levels to forbid anyone from de-agregation without no-exports. Culprits would fall under a three-strike policy before definitive de-peering and public humiliation. Who's with me ? :) -- Jérôme Nicolle
Dealing with auditors (was Re: We hit half-million: The Cidr Report)
On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: On Wed, 30 Apr 2014 15:40:43 -, Jamie Bowden said: You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says Thou shalt NAT, you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. Later years I was in a small 1100-many HP9000 shop--same thing only different. (That was also the environment with a medical school and hospital with Internet-accessible heart monitors on Windows 95.) I think there has been some drift away from IBMishness as The Gold Standard, but it still looks like there is no allowance for the real world in computing and networking. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The Cidr Report
On Apr 26, 2014, at 12:19 PM, Deepak Jain dee...@ai.net wrote: Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack). A /64 deaggregte only makes it through because folks let it; there’s something to be said for filters. That said, one might generally expect every AS (there are about 60K or them, I gather) to have one prefix, and if it deaggregates, it might be reasonable to expect it to multiply by four. RIR online records suggest that someone that asks for additional addresses beyond their /32 is told to shorten the existing prefix, not allocated a new one - the same prefix becomes a /31 or whatever. The reason we have 500K+ IPv4 prefixes is because we hand them out in dribbles, and there is no correlation between the one you received last week and the one you receive today. Geoff’s slides are interesting in part because of their observations regarding deaggregates. If 1% of of all AS’s advertise over half of the deaggregates, that seems like a problem their neighbors can help with, and if not them, the neighbors' neighbors. It’s hard to imagine that a single Ethernet (a single /64) is so critical that the entire world needs a distinct route to it. In any event, I would not approach this as a statistical issue, and say “well, IPv4 grew in a certain way, and IPv6 will do the same”. It can. But we have had the opportunity to think ahead and plan for the growth, and the RIR communities have been planning. It seems likely that, with a little care, IPv6 should do quite a bit better. signature.asc Description: Message signed with OpenPGP using GPGMail
Rancid with Maipu devices
Hello everyone! I was wondering if anyone is using Rancid with Maipu devices? I am slightly stuck because default clogin gives error on terminal length 0 and widith command in Maipu cli. Also, I tried adding no more which is being executed but still overall script is failing. Did anyone got around this? If so, it would be helpful if you can share your customized script for Maipu. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2
Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
The auditors VMware sent to us were just as bad. To ensure we weren't running rogue ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. Oh look, this MAC isn't listed as one of your virtual machines. It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC On Wed, Apr 30, 2014 at 2:31 PM, William Herrin b...@herrin.us wrote: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html
RE: Dealing with auditors (was Re: We hit half-million: The Cidr Report)
We just dealt with a vmware audit too; it was a joke. In any case, the thing I found curious with their auditor as well as a PCI QSA (fancy auditor), is that neither entity seemed to know IPv6 exists. The whole time I'm thinking okay, now why aren't you investigating these same attack vectors in IPv6? Just another reason PCI is not necessarily about security David -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ulf Zimmermann Sent: Wednesday, April 30, 2014 8:36 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: Dealing with auditors (was Re: We hit half-million: The Cidr Report) The auditors VMware sent to us were just as bad. To ensure we weren't running rogue ESX(i) servers or WorkStation, they made us provide full arp/cam tables. Then a list of the virtual machines. Oh look, this MAC isn't listed as one of your virtual machines. It isn't because it was running on virtual box or something like that. Auditor didn't know you could export a virtual machine from VMware and load it into another visualization software and it would keep the VMware MAC On Wed, Apr 30, 2014 at 2:31 PM, William Herrin b...@herrin.us wrote: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon larryshel...@cox.net wrote: On 4/30/2014 11:30 AM, valdis.kletni...@vt.edu wrote: And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-396-1764 You can find my resume at: http://www.Alameda.net/~ulf/resume.html
