Re: Maformed SNMP Packet log/trace
"sd" == Sean Donelan <sean@donelan.com> writes:
sd> On Tue, 26 Feb 2002, Richard A Steenbergen wrote:
A lot of those protocols have people looking at them on a regular basis, and they still manage to come up with obscure exploits noone else noticed (ex: 23mb of buffer overflows to exploit telnetd).
sd> So what is the solution for a public network operator. I attended sd> a presentation last week where a Checkpoint reseller suggested the sd> client needed to buy eight Checkpoint firewalls to protect a sd> single web server. I was impressed, what about the undercoating sd> and scotchguard fabric protector. That's actually a possibility, soon as they support OC-192 interfaces ;) Stay away from the undercoating, but the ScotchGuard(tm) is definitely worth it! sd> Is it time to fall back in punt? How would you architect a backbone if sd> you could do it over? Security is not about making things foolproof. They'll always be able to break you, no matter what you do. Security is about assuming acceptable risk, and mitigating unacceptable risk. This whole recent mess has actually gone over fairly cleanly. The vast majority of public infrastructure seems to have been patched with a fair amount of speed, and nobody's noticed any serious outages due to it. Apparently, the risk we assumed was acceptable, and when it became unacceptable, it was mitigated quickly enough. If I could do it over? I'd get in my Tardis, and go back to 1969. I'd teach everyone at DARPA how to spell security. Loose source route, IP options in general, ICMP address mask requests, all these things should go away. sd> Is the complexity of SSH code worth the protection? Or is it better sd> never to access your routers through VTY ports, and always use an sd> reverse-terminal server to the console from an out-of-band management sd> LAN? Console is slow, logs can easily DoS a 9600 baud line. It only allows one connection. Good fallback point, operationally does not scale. SSH is worth the protection, as reference implementations are available, and it requires very little in the way of system support. As long as in-band access to routers is required, SSH (or HTTPS or IPSec) will be with us. As time passes, the quality of the tools that we have to work with improves, and our trust in them can grow. The official answer is control plane separation. This worked for the PSTN, and it's the way the Internet will go, eventually. ericb -- Eric Brandwine | Things should be as simple as possible, but not simpler. UUNetwork Security | ericb@uu.net | +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E
On 27 Feb 2002, Eric Brandwine wrote:
Security is not about making things foolproof. They'll always be able to break you, no matter what you do. Security is about assuming acceptable risk, and mitigating unacceptable risk.
10 years ago I suspect we would have been discussing software quality control. The security label isn't always the best approach a problem. Yes, car thieves will always be able to steal your car. That isn't the same problem as having the wheels fall off the car because the factory didn't tighten the lugnuts. Are buffer overflows an intrinsic risk, or a symptom of bad software engineering? I don't believe in unbreakable systems. But quality engineering can make systems more stable and robust under all conditions, even the unexpected. Yes, Murphy, Mother Nature and Malicious people will still get you. But its easier to fix a well-designed system than one held together with lots of duct tape.
If I could do it over? I'd get in my Tardis, and go back to 1969. I'd teach everyone at DARPA how to spell security. Loose source route, IP options in general, ICMP address mask requests, all these things should go away.
You wouldn't need to go all the way back to 1969. I debated loose source routing with one of the authors of TCP/IP in the early 1980's :-) I made an ass of myself in that debate. But its not really fair to say they didn't understand security. Security is one of those words, which means a lot of different things to different people. The Internet is better at security than the NSA for some types of security, and worse at other types of security. What will be interesting is if the Internet can add confidentiality on top of a network easier than other networks can add availability on top of their networks. The Internet blew through Y2K without a hiccup, ask the NRO how their super-secure network did.
SSH is worth the protection, as reference implementations are available, and it requires very little in the way of system support. As long as in-band access to routers is required, SSH (or HTTPS or IPSec) will be with us. As time passes, the quality of the tools that we have to work with improves, and our trust in them can grow.
SNMPv1 had reference implementations too. Out trust seems to have been misplaced.
The official answer is control plane separation. This worked for the PSTN, and it's the way the Internet will go, eventually.
Just because Bell Labs never released a paper on "Security Problems in the SS7 Protocol Suite" doesn't make the telephone network secure. PSTN security relies primarly on trust between telephone companies. Not very scalable. The Internet has been the biggest improvement in telephone security in the last 100 years. The Internet was a nice bright shiny object which attracted most of the phreakers away from the PSTN. Control plan seperation isn't a complete answer for the Internet because its a network of networks. Just like control plane seperation has problem scaling in the PSTN, you'll find a lot of "untrustworthy" parties will end up with access to the control planes which extend between networks.
... Are buffer overflows an intrinsic risk, or a symptom of bad software engineering?
as long as stack memory is immutably executable, and software is written in the C language, buffer overflows are an intrinsic (though manageable) risk. one expects that they don't program interplanetary missions in C.
... But its easier to fix a well-designed system than one held together with lots of duct tape.
and yet it's a lot harder to break 500 duct-taped systems of mixed and varied heritage than to break one well designed system. monoculture is intrinsically brittle no matter how strong the genes themselves may be.
SSH is worth the protection, as reference implementations are available, and it requires very little in the way of system support.
and it's been broken a couple of times now, from buffer overflows to integer overflows. and now i hear that mr. bernstein has a paper out about how RSA isn't nearly as secure as we thought it was, and there's a rumour of another ssh integer overflow attack in the offing. there's no silver bullet or silver buzzword. programs written in languages other than C are susceptible to buffer overflows, bitswizzlers other than just RSA will turn out to be trivial in hindsight, IPsec and DNSsec and XYZZYsec will each turn out to be crocks of dung at some point in the future. but for some values of "now", each might have its place. the best security-related records will be set and held by people and companies who are unceasingly vigilant and who practice professional risk management, and not by people or companies who depend on silver buzzwords. (note that i hold the single-author record for total CERT advisories, proving that in my copious youth i knew how to sling code but not how to manage risk.)
On Wed, Feb 27, 2002 at 02:00:41AM -0500, Sean Donelan wrote:
SNMPv1 had reference implementations too. Out trust seems to have been misplaced.
Beware of any protocol named "Simple". In my experience things that are designed with unneeded complexity tend to be the most broken or breakable. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
participants (4)
-
Eric Brandwine -
Paul Vixie -
Richard A Steenbergen -
Sean Donelan