Darknets Coming Soon? 288
Anonymous Stalwart writes "CIO.com is running a story on darknets and their implications for security. With the ruling against Grokster, darknets seem poised to become a reality. How this will impact the future of the workplace, from top-level IT/IS managers all the way to non-IT jobs will depend on how the tech community that is developing this technology treats it."
Dark Ambition (Score:5, Informative)
What is a darknet?... (Score:1, Informative)
I thought it was rather obvious from the article.- The Wolfkin
Re:I know the question we're all asking ourselves: (Score:1, Informative)
Source: http://en.wikipedia.org/wiki/Darknet [wikipedia.org]
Re:I know the question we're all asking ourselves: (Score:4, Informative)
I found this article [darknet.com] about "darknets" that I found informative, even though it's a book ad.
Article Text && Coral Cache URI (Score:5, Informative)
---
FILE SHARING
Spies in the Server Closet
BY MICHAEL JACKMAN
The Supreme Court might have stirred up a bigger problem than it settled when it ruled last June that file-sharing networks such as Grokster could be sued if their members pirated copyrighted digital music and video.
Since then, some programmers have announced they would pursue so-called darknets. These private, invitation-only networks can be invisible to even state-of-the-art sleuthing. And although they're attractive as a way to get around the entertainment industry's zeal in prosecuting digital piracy, they could also create a new channel for corporate espionage, says Eric Cole, chief scientist for Lockheed Martin Information Technology.
Cole defines a darknet as a group of individuals who have a covert, dispersed communication channel. While file-sharing networks such as Grokster and even VPNs use public networks to exchange information, with a darknet, he says, "you don't know it's there in the first place."
All an employee has to do to set one up is install file-sharing software written for darknets and invite someone on the outside to join, thus creating a private connection that's unlikely to be detected. "The Internet is so vast, porous and complex, it's easy to set up underground networks that are almost impossible to find and take down," says Cole.
He advises that the best--and perhaps only--defense against darknets is a combination of network security best practices (such as firewalls, intrusion detection systems and intrusion prevention systems) and keeping intellectual property under lock and key. In addition, he says, companies should enact a security policy called "least privilege," which means users are given the least amount of access they need to do their jobs. "Usually if a darknet is set up it's because an individual has too much access," Cole says.
---
Re:Ok, real response (Score:5, Informative)
Re:Ok, real response (Score:1, Informative)
We found a way around that issue. Feel free to drop in and see for yourself: http://anonetnfo.brinkster.net/ [brinkster.net]
Two definitions (Score:3, Informative)
One definition is an encrypted protocol over the Internet. The other definition is using wireless technologies off the Internet. Oddly, the person quoted in the CIO article was trying to claim that encrypted, closed file sharing over the Internet was nothing like a VPN. That makes no sense to me, especially given the other definition of a darknet (the wireless one off the Internet) really is nothing like a VPN.
A wireless-off-the-Internet darknet could serve Thomas Paine purposes if the U.S. government ever shuts down the Internet in response to a terrorist attack. An encrypted, closed information sharing network on the Internet could not.
Already there (Score:4, Informative)
Not Really (Score:5, Informative)
Think of an IRC style web. Basically, a properly designed network would allow one party to inform another that it wanted to make a connection. Then it would make that connection. By pre-passing the keys and proof of identity, you would be able to make arbitrary connections within a "closed surface" of the net.
===
What I have been waiting to see make a comeback is the good old fashioned POTS modem. With all the internet wire-tap laws being generally weaker than the phone tapping laws, it would _really_ make sense to transfer authentications (etc) through a old-fashioned BBS style "drop sites" that were not really on the net.
So you downloaded some particular binary splash. To turn it into the song or whatever you would have to go get the key/completion-tidbit. Heck, the actual directores could be encoded so you _couldn't_ know what you were passing unless you were also in on the sideband/drop-site.
old news (Score:2, Informative)
Monitoring traffic by source, destination and type (Score:3, Informative)
Effective monitoring is actually quite achievable with freely avalible software.
On a properly managed network you should be able to tell exactly who is using how much traffic and what type of traffic (and where it's coming in and out from) and to spot suspicious changes in usuage patterns, with historical data avalible in a format appropriate for a quick visual comparison. All of this should be fed in to your monitoring platform with alerts raised once set thresholds are reached.
In practice though, it's usually not cost effective to actually clamp down on misuse of bandwith and it's more prudent to let it slide (and/or go for the low hanging fruit if spot anyone taking the mickey) and just pickup the tab afterwords.
(Disclaimer: The next part of this post drifts away from this specific thread
I'm not sure why so many people imagine monitoring traffic by source and type is difficult and that they can't be spotted and rate limited on a per user basis, in an entirely automated fashion.
Using tools like jflow and cflowd (and various other commerical purpose built tools) to do detailed traffic profiling, and to a limited extent shaping, is something a few carriers and large providers do already. Even if your provider doesn't do this, there is a really good chance their transit providers do it.
At the moment, the majority of providers mark P2P traffic as the lowest priority for QoS purposes as it is, because (a) it's so all consuming and disproportionately resource intensive (compared to far more common tasks like legitimate HTTP traffic and FTP data transfer) and (b) it's hard to complain about slow transfer speeds of what is almost certainly Warez between you and an anonymous DSL/Cable subscriber in another state/country. This is partly why P2P transfer rates can be very crummy (the other major reason being of course the limited upstreams of most users).
Once you have profiling data for a given port or IP on your network, all you need to do is send a trigger to the switch/router/DSLAM/etc. to either trottle the traffic for that port on the TCP/UDP ports required (as the hardware permits - ideally on a per-TCP/UPD-port basis), or - if your feeling adventurous (or your hardware is crummy) - dynamically re-route traffic for that destination seperately, though a series of systems that are capeable of enforcing very fine grained QoS controls (on appropriate hardware, the 2.6 kernel with iptables and some appropriate modules is actually capeable of impressive work in this area).
If users start tunneling large amounts of traffic down other ports (and disguising it as as regular HTTP, SSH, HTTPS, etc. traffic) then it's going to be really obvious to spot using automated software, and those those users will find that providers will just impliment systems to nobble that specific type of traffic on their connection while they persist in doing that, and if they want unnobbled connection, they'll have to pay a real premium to compensate. It's also entirely possible providers will start enforcing QoS based on destination too, so that transfers to systems that are common P2P traffic destinations are effectively crippled (and traffic to network ranges used by Cable/DSL/College dorms/etc. could even be rated by default).
If any users imagine they can 'sneak around' by tunneling P2P traffic and making it look like encrypted VoIP traffic (and warzing to their hearts content at the expense of the rest of legitimate users) they are in for a big shock. They are going to find that suddently their VoIP traffic starts having specific (weekly/monthly) transfer limi
Re:And the MPAA/RIAA's response will be... (Score:3, Informative)
Re:Not Really (Score:3, Informative)
Otherwise, and for maximum snoop-proofing against external forces, one has to be willing to make the phone call to transfer mail (both by users and BBS-to-BBS), which may involve a long distance call, and as with FIDO, often a considerable delay as packets hop from one BBS to the next. (As the old tagline goes -- "Internet: modem and phone lines. FidoNet: tin cans and string."
There's no reason you can't encrypt your posts on the BBS, making them secure even from the sysop; in fact this used to be the norm on some BBSs, and I've seen one where it was *required*. You could either UUEncode the encrypted message and post it as ASCII, or attach an encrypted ZIP to an empty message, depending on the capabilities of the BBS software. To the BBS, it's just another message or attachment, it doesn't care that it's not in plain language. So the problem of snoop-proofing against the sysop is already solved (provided he allows encrypted messages. If he doesn't, he's probably not trustworthy anyway!)
The concept of a "dumb router" may have merit, tho, to prevent any human from seeing where a given packet comes from or goes to. Of course, you can still get caught when you log in, but there again -- in the old days, some BBSs *required* that you use a unique alias and never post your real name. If you're really paranoid, use a pay phone (thus not a number traceable to you) and one of those gadgets that leech to the mouthpiece. (I've got one that does 28.8 -- they're still made, for laptop use in hotels that don't have phone jacks. Hopelessly slow for files, but adequate for QWK/REP packets.)
There indeed was a problem with sysops losing interest or going off in a huff, but three that I've used had track records of 17 yrs, 10 yrs, and 11 yrs (and counting). So it's not a universal issue. Small ISPs go tits-up about as often as BBSs did.
BTW I still use two BBSs daily -- one via telnet, the other as QWK/REP by email. And should both die... well, I already own Wildcat.
W.A.S.T.E. is an example (Score:2, Informative)