Have you ever seen "Connections," or its sequel series, "Connections2"? It was produced by PBS, and although it didn't cover just recent innovations, it talked instead about science, invention and discovery over time, drawing amazing links between events, people, discoveries/creations, and the situations that played a role in all of the above. I remember watching it when I was much younger, and I can recall many of the episodes clearly today.
If the bandwidth spike is the result of an insecure network by the client, they need to eat the cost, as they have indirectly incurred it. But if they were the victim of a DoS that involved packets originating from another ISP with source addresses spoofed as though they originated from the client network, I'd say the ISP needs to eat that; they should be ingress/egress routing. And when slammer hit, if they didn't have SQL servers accessible to the outside but got hit with enough scans to boost their charges...well, at that point I think the ISP needed to start filtering that port for a short time at their borders anyways (remember that that specific port was for purposes that are not likely over the internet without a VPN).
I think it ultimately comes down to whose negligence led to making the bandwidth-intensive attack possible.
I saw Batz speak at the Black Hat Briefings in 1999 about this. He described a host of attacks (no pun intended) including what he aptly termed a "Denial of Existence" attack, whereby an entire Autonomous System gets blackholed from its peers.
Are willing to participate in a scam to deprive a third world nation of millions of dollars through contract fraud, embezzlement or something similar and who are also...
B) willing to put a lot of trust in co-conspirators for such a transaction...
...are getting rooked for almost 6 figures USD apiece? What's the problem?:)
I think you're confusing technology with service providers. Isn't that a bit like saying that the Cisco gear sucks because you have a crappy ISP? Mesh networking technology is, in my opinion, unsafe, and the short answer to your question will be (by any security-conscious business), "yes!" Let's face it, guys like us are not the driving power behind the wireless infrastructure market.
Wait...you rely on security by obscurity by ignoring "unknown equipment" there...and the key isn't whether the equipment is known or not, the key is whether the BEHAVIOR of the known equipment can be emulated. Ever set up a honeypot? Ever hack IIS to make it look like apache? Such things are possible. After all, how the hell do you set up a wireless network and still hide the underlying protocol behavior, eh? There's nothing flawed about the implemention...the very concept of it is flawed. Anyone can enter into such a network, and in the real world "anyone" includes "very bad people". Saying that a nuclear power plant is hard to get within wireless range of is a useless argument; I doubt that mesh networks are being designed strictly for use in nuclear power plants. Oh, and a quick note: wireless networking is prohibited in nuclear power plants, as well as any classified installation or similar high-security installation under federal control. Can you guess why? It ain't because wired nets are just as insecure as wireless ones, I can tell you that much:)
Yes, but it's a lot harder to patch into twisted pair. Ever hear of warwalking? Try it sometime, and then try patching into the actual wire...it'll be an enlightening experience for you:)
And then realize that being a participant in a mesh network is far more access, far more readily given, than being a participant of a Wi-Fi network.
Um, you're missing what a teergrube does. It doesn't stop people on its network from getting spam (remember, it's the server being treated as an open relay that acts as a teergrube), but rather anyone. When spammers ignore a teergrube, it has no positive impact on anyone; the spam just gets routed through a real open relay and still gets to its intended recipients. In short, a teergrube does not sit at the end point, it sits at the relay point.
Keep in mind that IDC sells the document that details this fact. They also sell other things that put it in their best interest for this report to say what it does. After all, do you think they'd be much use to anyone as an intelligence gathering organization if they only had to report "nope, not much going on here!" Remember, whenever someone talks about something that they are selling, consider that the statements should be verified before taken as fact:)
Ok then...as I can understand it (and maybe I'm missing the point here), for objects in the mesh to assist in carrying its traffic, you have to entrust them to be part of its infrastructure. This leads to the obvious question: would you allow just anyone to put their router (or device that acts like a router and does god knows what else) between you and your endpoint? For that matter, would you trust a network made entirely of network devices that everyone and their brother contributed, with those devices able to come and go like thieves in the night?
It seems to me that a mesh network would inherently place trust in all users, in a world where it's clear that all users should not be trusted, just some...and there's no way yet to sort out the good from the bad. Even if you restricted the use/deployment of the network to a single organization, it still poses an absolute nightmare that an insider could subvert the functions of a node.
I love the notion of minimal centralization (if any) and the fault tolerance that can come with it, but I think that the security risk is waaaaaay too great.
One day, when all connections between points (I doubt this day will come, btw) are encrypted, this could work, but only as long as the mesh itself could detect and isolate the source of DoS behavior against the rest of the net. Remember, encryption keeps information secret, but it doesn't keep anyone from just plain breaking stuff:)
First off, you are incredibly wrong. Almost all spam is bounced off of servers that relay...that is, they forward mail for users of any domain. That's why this concept exists; spammers search for "open relays" (that's why they're called that, btw) and use them. TarProxy would look like a normal open relay to the spammer, and therefore he would use it.
Unfortunately, there is a problem. Before TarProxy there was another thing, called a "teergrube" or "tarpit." What it did was slow down the connection (with things like ICMP source-quench and psychotically small TCP window sizes) so that it acted like a spam speed bump. In the meanwhile, it didn't actually forward any of the spam anyhow. Why didn't this technology become more widespread? I'm glad you asked! Because it was trivial for the guys who develop spammer software to recognize these systems, have their software detect such behavior, and cease using them within less than a minute. And that's what will happen with a TarProxy, alas.
Without looking into any existing algorithms for searching, ranking, or correlating, write Pagerank. Produce even pseudocode that can achieve what Google has achieved (and Altavista et. al. have NOT). Then I think you can tell us that what they have developed is no big deal. The truth is, what you described is the basis for ranking...big deal, ideas are a dollar a dozen. Patents don't protect ideas. At least, that's not how they're SUPPOSED to be used, but some GS-9 in an office can screw that up with a rubber stamp. Patents protect IMPLEMENTATIONS. Working models of implmentations of ideas are supposed to be part of a patent application, and for a reason. If you can't make it work, you can't patent it, because it's all about how you managed to do it...and by the way, if someone comes out with a better idea on how to achieve the same thing, tough beans, your patent does not protect you from their competition.
At least that's how it's supposed to be, how the laws were written. The problem isn't patents, but how the USPTO has been approving dumb-ass applications that are nothing more than wordings of concepts. "One-click buying" is not an implementation, neither is hyperlinking or any of the other egregious patents that are the bane of our existence these days.
But until you can whip me up Pagerank code from scratch, don't whine about how they don't deserve a patent for it:)
Yeah, we've gone from a long-time, brilliant, and completely ignored proponent of better security against terrorism, information warfare and other means of asymmetric warfare to an arguably incompetent defender of infrastructure who will be listened to. Great.
That's not the realm of the organizations mentioned here. It's not within their power or realm of responsibility to force deployment of standards, nor does it make sense for them to hold back on development of better standards until the older ones are heavily used. What if the older standard isn't as useful as predicted?
And finally, WHAT standard? What lesser standard exists for MAN (Metropolitan-Area-Networks, a far cry from anything you can do with 802.11x) over wireless signals? This isn't like something you'll use on your home network, this is the wireless equivalent of a SONET ring.
Great...the 21st is my birthday also. "Happy Birthday, Shoten! We have one more raving a$$hole on the net than we had on the 20th, only this one is getting press time!"
He's a little dork. I know, it's not terribly conducive to intellectual discussion to use words like "dork," but the word exists for a reason, and this is as good an example of that reason as I can possibly imagine. For one, "GOBBLES Security," which for a long time pretended to be a whole group of people, turned out to be one teenager. For those of us who were at DefCon X this past year and saw him talk, well...you know what I am talking about here. For those of us who remember when he first started posting on the vuln-dev list on SecurityFocus, well...you know what I'm talking about too. As for the rest of you, I implore you, do a little research, because this dork thrives upon people not knowing what a child he is. I wouldn't believe him if he said he had proof that Bill Gates was a capitalist.
Hey, in case you all didn't know this, the DMCA is NOT the only law in existence. TV shows are copyright protected, and that protection exists outside of DMCA.
Jeez.
What's next, "Is murdering Bill Gates' entire family legal??" based on how murder isn't covered by DMCA or of any real interest to the MPAA or RIAA?
What say we all get together and DoS DMA's infrastructure while this is in consideration? After all, if we were to keep calling them incessantly (and emailing, and whatever else we can do), it would certainly be an elegant form of vengeance, particularly if it impeded their ability to fight the FTC on this one. Don't forget to get the law firm that is "of counsel" to them in this matter:)
This is an excellent idea. For a long time the fight against computer viruses (as well as many other aspects of computer security) has been focused on winning or losing, period. Try to stop the virus, and that's it. But what about what happens when a virus gets through? Like almost all things in computer security, there hasn't been enough attention given to what happens if security fails. Bruce Schneier has been yelling from the mountain that security is as much about what happens when safeguards don't work as it is about making sure they do. The notion of being able to keep a virus in check to a certain degree is a good example of security that can fail gracefully when a new virus comes around.
He kind of sounds like a bit of an a$$hole, to be utterly honest. He repeatedly slams just about every computer professional on the planet (except himself, of course) for everything from writing bad code to not knowing ALL the details of EVERY service running on EVERY machine they have responsibility for. I can, off the top of my head, mention a hundred organizations who are so small they cannot possibly afford a person of this depth of knowledge.
He also ignores the facts of the world, choosing instead to think that everyone else needs to bend. Programming languages are being written insecurely by everyone alive? Don't whine about it, try to come up with a better way that won't make it so hard to write secure code with the available workforce out there. Let's face it; the infrastructure that exists needs supporting, and we can't wait until all the monkeys out there learn the One True Way(tm) of making everything secure. Telling everyone that they need to know everything is a stupid way to tackle the problem.
It's interesting how many concrete and hard statements are being made about things like cost and ease of construction, considering nobody's ever built one of these before. I almost feel like I was reading about an upcoming software product that's expected (by the vendor) to revolutionize the world!
Yeah, until you decide to turn it back on again, right? Windows machines have an "off" switch too...whether it's a matter of unloading from memory or powering down, it's no different.
Certifications are a leftover from the world where everything the military used was custom-made. Back in that world, things were so rigidly specified ("mil-spec") and known to the end user, it made some sense. From the top to the bottom, people in the military or intelligence communities were involved in the design and keeping a sharp eye on the security. The frame of thought of the designers was "zero-threat," whereby they thought of everything they possily could think of, and security was above nearly all other priorities. In this environment, it's easy to make a list of things to check for, and you can actually work that way.
Now, the emphasis is on COTS products, which have almost all been designed with the commercial (read as, "less security-conscious") market. Concern has not been for security as much as marketability, ease of use, and appeal to the public. The designers often do not keep security at a high priority, if at all until the later stages of development. And the people who really understand the nature of the threat in high-security environments had no input, insight, or awareness whatsoever of the internal workings of the products. The products are so varied and different from each other, a checklist of hard facts to verify (as certifications are) is no longer sufficient to catch all the possible risks.
That said, the other problem is that no other method has yet been developed. It's easy to say, "Just do a vulnerability assessment." How? How do you do that on a constant basis on something the size of a government network? How do you make sure that nothing slips through the cracks? And above all else...how do you keep most of the contractors from getting in the way of the few (or single) contractor who gets the job of checking everyone else's work? At least certifications are neutral, in that they have no capability to be used by any single contractor against all the others.
Ah, I'm with you...perhaps I should have been clearer. I love the theoretical stuff especially because now it's not so theoretical; I can consider the implications and potential applications many steps ahead. With the real-world background I now have, theoretical no longer means impractical or unapplicable.
Have you ever seen "Connections," or its sequel series, "Connections2"? It was produced by PBS, and although it didn't cover just recent innovations, it talked instead about science, invention and discovery over time, drawing amazing links between events, people, discoveries/creations, and the situations that played a role in all of the above. I remember watching it when I was much younger, and I can recall many of the episodes clearly today.
If the bandwidth spike is the result of an insecure network by the client, they need to eat the cost, as they have indirectly incurred it. But if they were the victim of a DoS that involved packets originating from another ISP with source addresses spoofed as though they originated from the client network, I'd say the ISP needs to eat that; they should be ingress/egress routing. And when slammer hit, if they didn't have SQL servers accessible to the outside but got hit with enough scans to boost their charges...well, at that point I think the ISP needed to start filtering that port for a short time at their borders anyways (remember that that specific port was for purposes that are not likely over the internet without a VPN).
I think it ultimately comes down to whose negligence led to making the bandwidth-intensive attack possible.
I saw Batz speak at the Black Hat Briefings in 1999 about this. He described a host of attacks (no pun intended) including what he aptly termed a "Denial of Existence" attack, whereby an entire Autonomous System gets blackholed from its peers.
Are willing to participate in a scam to deprive a third world nation of millions of dollars through contract fraud, embezzlement or something similar and who are also...
B) willing to put a lot of trust in co-conspirators for such a transaction...
:)
...are getting rooked for almost 6 figures USD apiece? What's the problem?
I think you're confusing technology with service providers. Isn't that a bit like saying that the Cisco gear sucks because you have a crappy ISP? Mesh networking technology is, in my opinion, unsafe, and the short answer to your question will be (by any security-conscious business), "yes!" Let's face it, guys like us are not the driving power behind the wireless infrastructure market.
Wait...you rely on security by obscurity by ignoring "unknown equipment" there...and the key isn't whether the equipment is known or not, the key is whether the BEHAVIOR of the known equipment can be emulated. Ever set up a honeypot? Ever hack IIS to make it look like apache? Such things are possible. After all, how the hell do you set up a wireless network and still hide the underlying protocol behavior, eh? There's nothing flawed about the implemention...the very concept of it is flawed. Anyone can enter into such a network, and in the real world "anyone" includes "very bad people". Saying that a nuclear power plant is hard to get within wireless range of is a useless argument; I doubt that mesh networks are being designed strictly for use in nuclear power plants. Oh, and a quick note: wireless networking is prohibited in nuclear power plants, as well as any classified installation or similar high-security installation under federal control. Can you guess why? It ain't because wired nets are just as insecure as wireless ones, I can tell you that much :)
Yes, but it's a lot harder to patch into twisted pair. Ever hear of warwalking? Try it sometime, and then try patching into the actual wire...it'll be an enlightening experience for you :)
And then realize that being a participant in a mesh network is far more access, far more readily given, than being a participant of a Wi-Fi network.
Um, you're missing what a teergrube does. It doesn't stop people on its network from getting spam (remember, it's the server being treated as an open relay that acts as a teergrube), but rather anyone. When spammers ignore a teergrube, it has no positive impact on anyone; the spam just gets routed through a real open relay and still gets to its intended recipients. In short, a teergrube does not sit at the end point, it sits at the relay point.
Keep in mind that IDC sells the document that details this fact. They also sell other things that put it in their best interest for this report to say what it does. After all, do you think they'd be much use to anyone as an intelligence gathering organization if they only had to report "nope, not much going on here!" Remember, whenever someone talks about something that they are selling, consider that the statements should be verified before taken as fact :)
Ok then...as I can understand it (and maybe I'm missing the point here), for objects in the mesh to assist in carrying its traffic, you have to entrust them to be part of its infrastructure. This leads to the obvious question: would you allow just anyone to put their router (or device that acts like a router and does god knows what else) between you and your endpoint? For that matter, would you trust a network made entirely of network devices that everyone and their brother contributed, with those devices able to come and go like thieves in the night?
:)
It seems to me that a mesh network would inherently place trust in all users, in a world where it's clear that all users should not be trusted, just some...and there's no way yet to sort out the good from the bad. Even if you restricted the use/deployment of the network to a single organization, it still poses an absolute nightmare that an insider could subvert the functions of a node.
I love the notion of minimal centralization (if any) and the fault tolerance that can come with it, but I think that the security risk is waaaaaay too great.
One day, when all connections between points (I doubt this day will come, btw) are encrypted, this could work, but only as long as the mesh itself could detect and isolate the source of DoS behavior against the rest of the net. Remember, encryption keeps information secret, but it doesn't keep anyone from just plain breaking stuff
First off, you are incredibly wrong. Almost all spam is bounced off of servers that relay...that is, they forward mail for users of any domain. That's why this concept exists; spammers search for "open relays" (that's why they're called that, btw) and use them. TarProxy would look like a normal open relay to the spammer, and therefore he would use it.
Unfortunately, there is a problem. Before TarProxy there was another thing, called a "teergrube" or "tarpit." What it did was slow down the connection (with things like ICMP source-quench and psychotically small TCP window sizes) so that it acted like a spam speed bump. In the meanwhile, it didn't actually forward any of the spam anyhow. Why didn't this technology become more widespread? I'm glad you asked! Because it was trivial for the guys who develop spammer software to recognize these systems, have their software detect such behavior, and cease using them within less than a minute. And that's what will happen with a TarProxy, alas.
Ok, so here's a challenge for you:
:)
Without looking into any existing algorithms for searching, ranking, or correlating, write Pagerank. Produce even pseudocode that can achieve what Google has achieved (and Altavista et. al. have NOT). Then I think you can tell us that what they have developed is no big deal. The truth is, what you described is the basis for ranking...big deal, ideas are a dollar a dozen. Patents don't protect ideas. At least, that's not how they're SUPPOSED to be used, but some GS-9 in an office can screw that up with a rubber stamp. Patents protect IMPLEMENTATIONS. Working models of implmentations of ideas are supposed to be part of a patent application, and for a reason. If you can't make it work, you can't patent it, because it's all about how you managed to do it...and by the way, if someone comes out with a better idea on how to achieve the same thing, tough beans, your patent does not protect you from their competition.
At least that's how it's supposed to be, how the laws were written. The problem isn't patents, but how the USPTO has been approving dumb-ass applications that are nothing more than wordings of concepts. "One-click buying" is not an implementation, neither is hyperlinking or any of the other egregious patents that are the bane of our existence these days.
But until you can whip me up Pagerank code from scratch, don't whine about how they don't deserve a patent for it
Yeah, we've gone from a long-time, brilliant, and completely ignored proponent of better security against terrorism, information warfare and other means of asymmetric warfare to an arguably incompetent defender of infrastructure who will be listened to. Great.
That's not the realm of the organizations mentioned here. It's not within their power or realm of responsibility to force deployment of standards, nor does it make sense for them to hold back on development of better standards until the older ones are heavily used. What if the older standard isn't as useful as predicted?
And finally, WHAT standard? What lesser standard exists for MAN (Metropolitan-Area-Networks, a far cry from anything you can do with 802.11x) over wireless signals? This isn't like something you'll use on your home network, this is the wireless equivalent of a SONET ring.
Now I can upgrade to something better than my wonderful Replay drive! Oh, wait...uh...hm.
Great...the 21st is my birthday also. "Happy Birthday, Shoten! We have one more raving a$$hole on the net than we had on the 20th, only this one is getting press time!"
He's a little dork. I know, it's not terribly conducive to intellectual discussion to use words like "dork," but the word exists for a reason, and this is as good an example of that reason as I can possibly imagine. For one, "GOBBLES Security," which for a long time pretended to be a whole group of people, turned out to be one teenager. For those of us who were at DefCon X this past year and saw him talk, well...you know what I am talking about here. For those of us who remember when he first started posting on the vuln-dev list on SecurityFocus, well...you know what I'm talking about too. As for the rest of you, I implore you, do a little research, because this dork thrives upon people not knowing what a child he is. I wouldn't believe him if he said he had proof that Bill Gates was a capitalist.
Hey, in case you all didn't know this, the DMCA is NOT the only law in existence. TV shows are copyright protected, and that protection exists outside of DMCA.
Jeez.
What's next, "Is murdering Bill Gates' entire family legal??" based on how murder isn't covered by DMCA or of any real interest to the MPAA or RIAA?
What say we all get together and DoS DMA's infrastructure while this is in consideration? After all, if we were to keep calling them incessantly (and emailing, and whatever else we can do), it would certainly be an elegant form of vengeance, particularly if it impeded their ability to fight the FTC on this one. Don't forget to get the law firm that is "of counsel" to them in this matter :)
This is an excellent idea. For a long time the fight against computer viruses (as well as many other aspects of computer security) has been focused on winning or losing, period. Try to stop the virus, and that's it. But what about what happens when a virus gets through? Like almost all things in computer security, there hasn't been enough attention given to what happens if security fails. Bruce Schneier has been yelling from the mountain that security is as much about what happens when safeguards don't work as it is about making sure they do. The notion of being able to keep a virus in check to a certain degree is a good example of security that can fail gracefully when a new virus comes around.
He kind of sounds like a bit of an a$$hole, to be utterly honest. He repeatedly slams just about every computer professional on the planet (except himself, of course) for everything from writing bad code to not knowing ALL the details of EVERY service running on EVERY machine they have responsibility for. I can, off the top of my head, mention a hundred organizations who are so small they cannot possibly afford a person of this depth of knowledge.
He also ignores the facts of the world, choosing instead to think that everyone else needs to bend. Programming languages are being written insecurely by everyone alive? Don't whine about it, try to come up with a better way that won't make it so hard to write secure code with the available workforce out there. Let's face it; the infrastructure that exists needs supporting, and we can't wait until all the monkeys out there learn the One True Way(tm) of making everything secure. Telling everyone that they need to know everything is a stupid way to tackle the problem.
It's interesting how many concrete and hard statements are being made about things like cost and ease of construction, considering nobody's ever built one of these before. I almost feel like I was reading about an upcoming software product that's expected (by the vendor) to revolutionize the world!
Yeah, until you decide to turn it back on again, right? Windows machines have an "off" switch too...whether it's a matter of unloading from memory or powering down, it's no different.
Certifications are a leftover from the world where everything the military used was custom-made. Back in that world, things were so rigidly specified ("mil-spec") and known to the end user, it made some sense. From the top to the bottom, people in the military or intelligence communities were involved in the design and keeping a sharp eye on the security. The frame of thought of the designers was "zero-threat," whereby they thought of everything they possily could think of, and security was above nearly all other priorities. In this environment, it's easy to make a list of things to check for, and you can actually work that way.
:)
Now, the emphasis is on COTS products, which have almost all been designed with the commercial (read as, "less security-conscious") market. Concern has not been for security as much as marketability, ease of use, and appeal to the public. The designers often do not keep security at a high priority, if at all until the later stages of development. And the people who really understand the nature of the threat in high-security environments had no input, insight, or awareness whatsoever of the internal workings of the products. The products are so varied and different from each other, a checklist of hard facts to verify (as certifications are) is no longer sufficient to catch all the possible risks.
That said, the other problem is that no other method has yet been developed. It's easy to say, "Just do a vulnerability assessment." How? How do you do that on a constant basis on something the size of a government network? How do you make sure that nothing slips through the cracks? And above all else...how do you keep most of the contractors from getting in the way of the few (or single) contractor who gets the job of checking everyone else's work? At least certifications are neutral, in that they have no capability to be used by any single contractor against all the others.
But that's just my frustration
Ah, I'm with you...perhaps I should have been clearer. I love the theoretical stuff especially because now it's not so theoretical; I can consider the implications and potential applications many steps ahead. With the real-world background I now have, theoretical no longer means impractical or unapplicable.