RES: RES: Exploits start against flaw that could hamstring huge swaths of
Guys, Red Hat have a release with the patch on CR repository. Should we update using the rpm on CR or using the source provide by ISC ? The release on CR is: 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 -Mensagem original- De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Randy Bush Enviada em: terça-feira, 4 de agosto de 2015 19:53 Para: Christopher Morrow Cc: NANOG; Joe Greco Assunto: Re: RES: Exploits start against flaw that could hamstring huge swaths of Automation just means your mistake goes many more places more quickly. and letting people keep poking at things that computers should be doing is... much worse. people do not have reliability and repeat-ability over time. i love the devops movement; operators discover that those computers can be programmed. wowzers! maybe in a decade or two, we will discover mathematics. nah. randy
RES: Exploits start against flaw that could hamstring huge swaths of
So, you guys recommend replace Bind for another option ? -Mensagem original- De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Joe Greco Enviada em: terça-feira, 4 de agosto de 2015 12:01 Para: Stephane Bortzmeyer Cc: nanog@nanog.org Assunto: Re: Exploits start against flaw that could hamstring huge swaths of On Tue, Aug 04, 2015 at 10:03:33AM -0400, Jay Ashworth j...@baylink.com wrote a message of 6 lines which said: Everyone got BIND updated? For instance by replacing it with NSD or Unbound? Or doing something better like not just replacing one evil with another, and instead moving to a heterogeneous environment where possible. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote: So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, 04 Aug 2015 15:06:36 -, Leonardo Oliveira Ortiz said: So, you guys recommend replace Bind for another option ? The *good* recommendation is to get some onboard security clue, and learn procedures to mitigate the inevitable exploits against flaws in infrastructure software. pgproCq1JbkNP.pgp Description: PGP signature
Re: RES: Exploits start against flaw that could hamstring huge swaths of
Automation just means your mistake goes many more places more quickly. On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote: So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
With the (large) caveat that heterogenous networks are more subject to human error in many cases. On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote: So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths
Den 04/08/2015 19.18 skrev Christopher Morrow morrowc.li...@gmail.com: On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: On 4 August 2015 at 18:48, Joe Greco jgr...@ns.sol.net wrote: However, the original point was that switching from BIND to Unbound or other options is silly, because you're just trading one codebase for another, and they all have bugs. It is equally silly to assume that all codebase are the same quality and have equally many bugs. Maybe we should be looking at the track record of those two products and maybe we should let someone do a code review. And then choose based on that. because: 1) historical results matter here? (who looked at which products over what period of time, with what attention to detail(s) and which sets of goals?) 2) the single person doing a code review is likely to see all of the problems in each of the products selected? Maybe not but a code review can tell what methods are used to safe guard against security bugs, the general quality of the code, the level of automated testing etc. History can give hints to the same. If it had a lot of bugs discovered it is likely it is not good quality in a security perspective and more bugs can be expected. It is called due diligence. The aim is not to find the bugs but to evaluate the product. Regards Baldur
Re: RES: Exploits start against flaw that could hamstring huge swaths of
Automation just means your mistake goes many more places more quickly. and letting people keep poking at things that computers should be doing is... much worse. people do not have reliability and repeat-ability over time. i love the devops movement; operators discover that those computers can be programmed. wowzers! maybe in a decade or two, we will discover mathematics. nah. randy
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 4:53 PM, Randy Bush ra...@psg.com wrote: i love the devops movement; operators discover that those computers can be programmed. wowzers! Maybe we can give them a new title. I'm thinking, System Programmer.
Re: RES: Exploits start against flaw that could hamstring huge swaths
With the (large) caveat that heterogenous networks are more subject to human error in many cases. Indeed. Everything comes with tradeoffs. More intimate familiarity with the product and a uniformity of deployment strategy has made it more practical here to stick with BIND; an update is a simple matter of a tarball and running a script that manages the dirty work. However, the original point was that switching from BIND to Unbound or other options is silly, because you're just trading one codebase for another, and they all have bugs. However, collectively, two different products cooperatively providing a service are likely to have a higher uptime in a well-designed environment. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
I don't disagree, but automation usually protects against typing errors, it doesn't protect against incorrect configurations. Using multiple vendors or server software means that your people have to know all of the systems. There are many cases where, for example, a Cisco like CLI will make a network engineer think that a command works exactly the same way on another vendors system when in fact the under the hood implementation is very different. It's not always feasible to have the people with the needed skill levels and automation does not help that at all. On Aug 4, 2015 10:21 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms khe...@zcorum.com wrote: Automation just means your mistake goes many more places more quickly. and letting people keep poking at things that computers should be doing is... much worse. people do not have reliability and repeat-ability over time. If you fear 'many more places' problems, improve your testing. On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote: So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
- Original Message - From: Scott Helms khe...@zcorum.com On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough Automation just means your mistake goes many more places more quickly. Not necessarily. The sort of failure you're talking about, Scott, is user did the wrong thing, and sure, automation makes it easier for that to spread. Chris was, though, I think, suggesting automating around user tries to do the right thing on disjoint devices, and fails *because they're disjoint*; that is, clearly, a problem automation can help with. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: RES: Exploits start against flaw that could hamstring huge swaths
On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: On 4 August 2015 at 18:48, Joe Greco jgr...@ns.sol.net wrote: However, the original point was that switching from BIND to Unbound or other options is silly, because you're just trading one codebase for another, and they all have bugs. It is equally silly to assume that all codebase are the same quality and have equally many bugs. Maybe we should be looking at the track record of those two products and maybe we should let someone do a code review. And then choose based on that. because: 1) historical results matter here? (who looked at which products over what period of time, with what attention to detail(s) and which sets of goals?) 2) the single person doing a code review is likely to see all of the problems in each of the products selected? nothing against any of the software in question here, but really this is all quite a crapshoot and past transgression research doesn't make for a great tool to plan for the future. Joe's right: all software has bugs, find the software and strategy that makes sense for your organization that MIGHT mean 2 platforms (seems sensible to me!) and it might mean automation for management of configs (from an abstraction so you can generate the right data to each target implementation) or it might mean more monkeys on keyboards if you don't believe in automation. -chris
Re: RES: Exploits start against flaw that could hamstring huge swaths
On 4 August 2015 at 18:48, Joe Greco jgr...@ns.sol.net wrote: However, the original point was that switching from BIND to Unbound or other options is silly, because you're just trading one codebase for another, and they all have bugs. It is equally silly to assume that all codebase are the same quality and have equally many bugs. Maybe we should be looking at the track record of those two products and maybe we should let someone do a code review. And then choose based on that. Regards, Baldur
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms khe...@zcorum.com wrote: Automation just means your mistake goes many more places more quickly. and letting people keep poking at things that computers should be doing is... much worse. people do not have reliability and repeat-ability over time. If you fear 'many more places' problems, improve your testing. On Aug 4, 2015 9:38 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough On Aug 4, 2015 9:25 AM, Joe Greco jgr...@ns.sol.net wrote: So, you guys recommend replace Bind for another option ? No. Replacing one occasionally faulty product with another occasionally faulty product is foolish. There's no particular reason to think that another product will be impervious to code bugs. What I was suggesting was to use several different devices, much as some networks prefer to buy some Cisco gear and some Juniper gear and make them redundant, or as a well-built ZFS storage array consists of drives from different manufacturers. Heterogeneous environments tend to be more resilient because they are less likely to all suffer the same defect at once. Problems still result in some pain and trouble, but it usually doesn't result in a service outage. This doesn't seem like a horribly catastrophic bug in any case. Anyone who is reliant on a critical bit like a DNS server probably has it set up to automatically restart if it doesn't exit cleanly. If you don't, you should! So if it matters to you, I suggest that you instead use a combination of different products, and you'll be more resilient. If you have two recursers for your customers, one can be BIND and one can be Unbound. And when some critical vuln comes along and knocks out Unbound, you'll still be resolving names. Ditto BIND. You're not likely to see both happen at the same time. However, at least here, we actually *use* TSIG updates, and other functionality that'd be hard to replace (BIND9 is pretty much THE only option for some functionality). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
hi ya On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms khe...@zcorum.com wrote: With the (large) caveat that heterogenous networks are more subject to human error in many cases. coughautomate!/cough ... On 08/04/15 at 12:21pm, Christopher Morrow wrote: On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms khe...@zcorum.com wrote: Automation just means your mistake goes many more places more quickly. and letting people keep poking at things that computers should be doing is... much worse. people do not have reliability and repeat-ability over time. ditto ... computers are experts at listening and repeatatively doing what it's told to do .. If you fear 'many more places' problems, improve your testing. i prefer automation .. even if it's wrong, you can look at the script and see what bad things it did and you should know what to do to fix the problem and fix the script to prevent it from spreading that mistake again person's standard excuse if you ask a person(s), what did you do to create this mess, duh... i donno btw, it's my kids birthday, i needed to be home an hr ago with the cake :-) hummm... :-) /standard - fwiw for automation to work: - folks updating the scripts should be required to know all platforms being used and how its different from each other - folks testing the scripts/updates process/proceedures should be paid bonuses, even free pizza/beer for finding bugs before release to the your internal world of automated-machines - always have 3 co-developments boxes for the script develpment and to backup each other - always have 2 or more test bed boxes for initial releases of new scripts where those boxes can also be downgraded back to the previous release before the new patches was applied - if nothing went wrong, there should be minimal issue with release a patch where it doesn't propagate problems automatically to everywhere the trick is how good are the eyes/brains that is looking for potential problems of the new releases/patches/updates/etc - i also say always let clients pull down patches vs pushing it to systems that seems un-responsive to avoid having to wait for dead boxes - all appps, not just bind, has occasional problems .. changing to something else doesn't necessarily solve the original bug problem pixie dust alvin # ddos-mitigator.net
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, 04 Aug 2015 15:54:53 -0400, Barry Shein said: Wow this thread went off-track in nanoseconds. So which bind versions are ok? This week's. pgpakL0r72_lt.pgp Description: PGP signature
Re: RES: Exploits start against flaw that could hamstring huge swaths of
Wow this thread went off-track in nanoseconds. So which bind versions are ok? -b
