In a typical corporate environment, your machines _are_ going to get moved this year or next year. Either your department gets more people, and moves to a different floor, or you lose people and the Real Estate Mavens consolidate your desks, or Alice leaves and Bob gets her machine, or Carol gets a newer faster machine and Dave gets her old one, or your startup gets bought and you move into your New Corporate Overlords' building.
Forcing you to rename machines when that happens is annoyingly disruptive; not renaming the machines when you move will rapidly start to annoy your IT people.
And of course, if any of your people have laptops (like _all_ of your sales people and field engineers) forget naming them by room number.
Naming machines after the users has some of the same drawbacks, but depending on your environment it's less likely to get you in trouble. If Carol gets the newer faster machine, she'll probably move her files to it, and you can rename the machine when you give it to Dave. But of course you might end up with "carolpc" and "carolpc2" for a while...
Dude, in case the wrongness of putting SSN in the machine name didn't tell you it was a joke, the poster has the Day of Week in there and hits you over the head with a 2x4 about having to rename the machine every day...
Sorry, didn't see your reply - Yes, OpenDNS offers the NXDOMAIN->search page stuff, which is bad. But their malware stuff, while certainly violating protocols, only does it at times that you wouldn't have wanted the protocol to succeed if you'd realized what you were asking for.
I used to work with an ex-Navy guy - our lab became much neater once he joined us, and more secure as well. But different organizations have much different concepts of what it means to "secure a computer" -
The Army sends out computer technicians to look at log files.
The Navy ties the computer down with ropes and netting to keep it from bouncing around in rough seas, and does whatever it takes to keep the computer room water tight.
The Marines send a squad of guys with automatic weapons to make sure nobody gets near it.
The Air Force? They cut a purchase order to secure another computer.
Bruce Schneier says that give a choice between security and dancing pigs on your computer, people will take the dancing pigs every time.
When Windows came out, it was perfectly secure - there's only one user in the universe, and she's allowed to do whatever she wants. ("Format C: "? Sure!).
Unfortunately, while Unix was designed from the beginning for security, it didn't always _stay_ designed for security, and some of the things that were done for security had serious tradeoffs. Networking was usually the worst, certainly from TCP/IP's beginnings in 4.2BSD, but also other protocols and other applications had problems, and you're not secure unless everything's secured in some way.
Low-numbered well-known tcp/udp ports can only be opened as root. While that avoided having ordinary lusers running fake servers, a generally worthwhile goal, it meant that every network service had to be implemented securely, and if any service had a bug, exploiting it made you root! (Of course, you don't need to be root to cause trouble - the Morris Worm didn't bother - but if you're a malicious attacker you want to be root because you can trash everybody, not just hog resources or trash individual users.)
If you're careful, you can open any special ports you need and then setuid to a non-root user, but not every programmer bothered, and some programs were already toast before they did that.
Sendmail used to run as root. There's no need for a mail system to run as root just to deliver mail - the System V and V8 mailers typically used group privileges to deliver mail into mailboxes - but not only did sendmail need Port 25, it also had a dancing-pigs feature, which was the ability to run received mail for a user through a mail-handling program with that user's privileges, and the easiest way to do that was to run as root.
Sendmail's pretty solid stuff these days, but it's been a favorite target for decades, not only because of its complexity, but because it's important enough that for years, almost any Unix machine was running it.
For the non-sendmail crowd, UUCP had its security holes as well, though the Honey DanBer version helped fix a lot of them. Remotely executing programs is a really useful and powerful concept - and doing it in environments where you have to safety-check every input that could possibly get handed to a shell means that somebody's going to slip a backquote through _some_ program or other and you'll be toast again.
Unix security means that the operating system is mostly protected from users and whatever malicious programs the users can be conned into running, but the users can still trash their own environments. And root used to be a user, and still sort of is, though we've gotten better about that. And email makes it easy to hand files to any user in hopes they'll run it; the big change over the decades is that you can send them more than just ASCII or EBCDIC.
Even if Unix was secure, it was originally accessed from terminals that might not be dumb enough to be secure. Back in 1979, one of the San Francisco area papers ran an article that "hackers in Berkeley" had found a security hole in "the Unix, a computer made by DEC" (ahem...) It was the then-already-old trick of sending escape sequences to a VT100 or HP2621 that would get echoed back to the computer as if the user had typed them. So what cool things is your computer running to talk to your iPhone or Bluetooth?
Password security has always been a problem. The original Unix password system was pretty strong for its day, but if you picked a wimpy password, you were vulnerable to password-guessing. (And some of the early password-length-enforcers only applied to regular users, not root, so that's the obvious password to try cracking.)
Unix file permissions were very flexible, but you had to be sure to tighten all of the ones that needed to be tight.
(Back when I was a newbie learning security, RTM's father used at least the last three of those methods to crack into my accounts:-)
I'd guess the percentage of legitimate demand is far less than 10% of domain registrations, probably far less than 1% (seeing as how the current legitimate+illegitimate percentage is 0.3%) But it doesn't matter much - 10% was low enough to kill off the vast majority of the remaining domain tasters, while high enough that people weren't going to argue and whine about how unreasonably strict it was. It means that the registrars who were friendly to the domain-tasting business can't afford to push that stuff any more, and it's not clear that setting a tighter limit is the most effective way to kill of the remaining abusers. After all, there are still people who speculate on name space just for the advertising revenue even if they have to pay the full $6/year. So a lot of this namespace pollution is going away.
If I were spending that kind of money on television, I'd get a more basic high-resolution TV and if I want to add general-purpose-computer-type features, I'd use a computer to get them, because the computer's going to be much more flexible and extensible in the future than a locked-in TV feature set. That still probably means you're going to spend a couple of hundred dollars upgrading your video card, so you can get 1920x1080 or more at high speed, and then you'll probably find yourself adding a TV tuner card to run MythTV, and then probably adding another terabyte or two of disk because mythTV filled up your current disk, etc., so it's not clear you'll actually save any money, but you'll get a lot more flexibility for things you want to do in the future.
I assume you can run paint.net on a Virtual Machine Windows environment - does it also run in Wine, which would be a bit lighter weight interface with the rest of your Linux environment?
The reason for an encrypted disk is that somebody may walk off with your computer and want to access your data. Sure, it's more likely that somebody will walk off with a laptop you carry around than a server that's wired in to things, but you never know. Maybe they've got a warrant or a subpoena, maybe they're just thieves, maybe they're competitors trying to scoop your new project. I've had equipment stolen out of big corporate offices before. If it's unnecessary paranoia, fine, it's unnecessary paranoia.
Also, CPU cycles are only expensive if you don't have enough of them. Depending on whether your server is just a file and print server or also a mail server with spam prevention software, you may have cycles to burn or you may not.
Their cookie-based fix is offensively lame - not only does the typical implementation of DNS hijacking only "help" queries to http port 80 and maybe https port 443, while breaking other protocols, their opt-out "fix" only fixes connections to those ports from cookie-supporting browsers, not from the applications for other protocols. Comcast's opt-out uses MAC addresses, so at least you can opt out for everything, not just only opt out from the least broken services.
Yup. I've had the document on my desk for a couple of weeks, planning to write a ranting response in my copious spare time. And J. Livingood posted a response somewhere else in this Slashdot comment chain as well.
Using cookies indicates that they Really Don't Get It - if you're using a browser, hijacking your query is evil but not particularly stupid, while if you're using some other protocol, such as email or ssh or even http/https on some port other than 80, the browser cookie isn't going to tell their broken DNS server or web server anything.
I've had a printout of your draft on my desk for a while, planning to write a good rant in response:-)
The "only redirect www.domain.tld" logic certainly helps reduce the number of applications that'll be broken, though I do still https: to www.domain.tld addresses and sometimes do ssh (usually not, and I almost never email them either.)
But even then it's breaking the behaviour my browser is configured for - I've got Firefox using Google as its search engine, and try to have IE do that as well.
As the parent article had said, you've got no way to predict whether they'll be consistent about the IP addresses they use for their redirect page, and you can't just give your application to everybody with the DNS-hijackers' addresses wired in, because they may have ISPs who use different hijack pages or your ISP could change yours at any time. And then there's the problem of load-balanced redirect servers - the service could round-robin between N different redirect servers (instead of anycasting or hiding the load-balancing behind NAT) so you wouldn't even get a consistent redirect page.
And even if your app _is_ the web, the most popular web servers let you pick what search engine to use in case of a NX response, so it's broken even then. Comcast's a little less broken than some hijacking services, since they're only redirecting www.whatever.tld, but who knows how long that'll last as a policy.
Usually it's opt-in - if you didn't set your computer to use their service, your queries won't go there and they won't lie to you. And if you'd rather have the occasional failure (and aren't running your own email server) in return for getting blocked from known malware sites, go ahead and opt in.
The only time it's opt-out is when your ISP decided to use OpenDNS or one of their competitors to do name resolution instead of doing it correctly - I'd be really annoyed if one of my ISPs did that without asking me.
Normally I'd agree with you - I've ranted elsewhere in this story about how DNS hijacking breaks all kinds of things, even including the browsers that it's supposed to be "helping". However, there's one case where it can be useful - hijacking queries for known evil sites (malware-infected, phishing targets, etc.) Unlike hijacking queries that should return Not Found sorts of messages, this returns the address of a "you don't want to go there" warning page instead of the address of the usually-actually-existing evil server. So while it's still incorrect behaviour, it's at least not breaking DNS as badly, and it's only breaking it for cases where a non-broken response would have gotten you somewhere bad anyway (unless of course you're a security researcher who _wants_ to talk to evil servers.)
There's one case where some of the DNS hijacker services aren't purely evil - it's the ones that take queries for known malware sites and redirect them to "you don't really want to go there" pages. That doesn't always do what you want either, but unless you're a security researcher, you probably didn't want any protocols from your machine connecting to malware-infected.example.com, so even a lame protocol-not-equipped failure from DNS-Hijackers.your-ISP.net is better either than a successful or unsuccessful connection to the evil site.
But that doesn't break the protocols as badly, because for the most part it's redirecting queries for sites that _do_ have actual servers on them.
Breaking DNS is bad for non-broken apps - it's only going to be worse for broken ones:-) Your PC's DNS resolver should be set up to use your internal DNS servers in preference to your ISP's DNS servers if possible, so if the VPN is routing 10.x.x.x addresses through the tunnel and non-RFC1918 addresses to the public internet, there won't be a problem with it going the wrong way.
The misappropriation is technically bad because it's done at the wrong protocol layer, and even when it works it's bad because it'll cause your browser to do something you didn't want.
Here's how DNS is supposed to work when it works, and how it's supposed to work when the lookup fails.
You have some application that wants to set up a connection to example.com using some protocol.
The application sends a query to the DNS servers to find out where example.com lives, gets told "192.9.200.1".
The application sets up a TCP session or UDP query/response to 192.9.200.1, yay!
But if the query fails, because you typed exampel.com instead, or because the site no longer exists, DNS tells your application "Not Found".
The application does something application-appropriate in response -
If your application was sending email, your mail server can tell your mail client that it couldn't deliver the mail.
If your application was receiving email, it might have been doing the lookup to see if the alleged sender existed; failure says it's a spammer.
If you were doing ssh, it tells you it couldn't set up a connection.
If your application was an Instant Messaging client, it's unlikely that they'll do anything good for you.
If it was a modern browser looking up Port 80, it tries tricks like adding a www or a.com, and if those also fail it may feed your query into your favorite search engine.
If it was a browser looking up Port 443 https:, it tells you that your connection failed but doesn't try feeding your possibly sensitive information to a random search engine.
Now look at what happens if your DNS server lies to your application by giving it some other IP address instead of the correct failure message, like 68.87.60.144.
If you're doing ssh, your ssh client will try to set up a connection to a server you have no ability to log in to. If you're lucky, the server won't be running an ssh server application; if you're unlucky, it'll maliciously try to steal your login information.
If you're sending email, and that system has an email server on it, it might reject your email with a confusing error message (unknown user fred@exampel.com), or it might pretend to accept your message but discard it silently with the rest of the spam, so you don't know it got lost.
If you're validating received email, it tells you that example.com was an existing mail server, so you're more likely to accept that spamgram.
If you're trying to make a secure connection to https://example.com/ and Comcast is listening on port 443, you might pass it sensitive information, and at best there's nothing good that can happen from attempting the connection vs. many bad things.
... don't profit...
Finally, when we get to the one case Comcast and its ilk _were_ thinking of, instead of your browser sending your incorrect URL to the search engine you like or generating a failure message if that's what you prefer, Comcast sends your URL to _its_ search engine in hopes of making a PROFIT on advertising to you.
I just got a new laptop at work, and it has Office 2007, replacing the 2003 that was on the old one. The only thing that makes it at all tolerable is that my new screen is 900 pixels high instead of 768, so most of the space that the ribbon's burning up is new pixels, but it takes me longer to get to many of the features I use often, and I haven't yet dug around to find all the features I'd like to have, plus it'll take me a while to memorize where it's hiding everything that I considered to be reasonably obvious in 2003.
Slashdot Mirror
In a typical corporate environment, your machines _are_ going to get moved this year or next year. Either your department gets more people, and moves to a different floor, or you lose people and the Real Estate Mavens consolidate your desks, or Alice leaves and Bob gets her machine, or Carol gets a newer faster machine and Dave gets her old one, or your startup gets bought and you move into your New Corporate Overlords' building.
Forcing you to rename machines when that happens is annoyingly disruptive; not renaming the machines when you move will rapidly start to annoy your IT people.
And of course, if any of your people have laptops (like _all_ of your sales people and field engineers) forget naming them by room number.
Naming machines after the users has some of the same drawbacks, but depending on your environment it's less likely to get you in trouble. If Carol gets the newer faster machine, she'll probably move her files to it, and you can rename the machine when you give it to Dave. But of course you might end up with "carolpc" and "carolpc2" for a while...
Dude, in case the wrongness of putting SSN in the machine name didn't tell you it was a joke, the poster has the Day of Week in there and hits you over the head with a 2x4 about having to rename the machine every day...
Sure, you can name you machines like that, but what if the person reading them doesn't have a futhark font loaded :-)
Sorry, didn't see your reply - Yes, OpenDNS offers the NXDOMAIN->search page stuff, which is bad. But their malware stuff, while certainly violating protocols, only does it at times that you wouldn't have wanted the protocol to succeed if you'd realized what you were asking for.
I used to work with an ex-Navy guy - our lab became much neater once he joined us, and more secure as well. But different organizations have much different concepts of what it means to "secure a computer" -
Bruce Schneier says that give a choice between security and dancing pigs on your computer, people will take the dancing pigs every time.
When Windows came out, it was perfectly secure - there's only one user in the universe, and she's allowed to do whatever she wants. ("Format C: "? Sure!).
Unfortunately, while Unix was designed from the beginning for security, it didn't always _stay_ designed for security, and some of the things that were done for security had serious tradeoffs. Networking was usually the worst, certainly from TCP/IP's beginnings in 4.2BSD, but also other protocols and other applications had problems, and you're not secure unless everything's secured in some way.
(Back when I was a newbie learning security, RTM's father used at least the last three of those methods to crack into my accounts :-)
I guess they're pricing it for their target market? Surely nobody would ship a copy from the UK over to North America!
On the other hand it does something useful....
I'd guess the percentage of legitimate demand is far less than 10% of domain registrations, probably far less than 1% (seeing as how the current legitimate+illegitimate percentage is 0.3%) But it doesn't matter much - 10% was low enough to kill off the vast majority of the remaining domain tasters, while high enough that people weren't going to argue and whine about how unreasonably strict it was. It means that the registrars who were friendly to the domain-tasting business can't afford to push that stuff any more, and it's not clear that setting a tighter limit is the most effective way to kill of the remaining abusers. After all, there are still people who speculate on name space just for the advertising revenue even if they have to pay the full $6/year. So a lot of this namespace pollution is going away.
If I were spending that kind of money on television, I'd get a more basic high-resolution TV and if I want to add general-purpose-computer-type features, I'd use a computer to get them, because the computer's going to be much more flexible and extensible in the future than a locked-in TV feature set. That still probably means you're going to spend a couple of hundred dollars upgrading your video card, so you can get 1920x1080 or more at high speed, and then you'll probably find yourself adding a TV tuner card to run MythTV, and then probably adding another terabyte or two of disk because mythTV filled up your current disk, etc., so it's not clear you'll actually save any money, but you'll get a lot more flexibility for things you want to do in the future.
I spend a large fraction of my work day with a couple of putty ssh sessions open to various boxes. It's pretty much indispensable.
I assume you can run paint.net on a Virtual Machine Windows environment - does it also run in Wine, which would be a bit lighter weight interface with the rest of your Linux environment?
The reason for an encrypted disk is that somebody may walk off with your computer and want to access your data. Sure, it's more likely that somebody will walk off with a laptop you carry around than a server that's wired in to things, but you never know. Maybe they've got a warrant or a subpoena, maybe they're just thieves, maybe they're competitors trying to scoop your new project. I've had equipment stolen out of big corporate offices before. If it's unnecessary paranoia, fine, it's unnecessary paranoia.
Also, CPU cycles are only expensive if you don't have enough of them. Depending on whether your server is just a file and print server or also a mail server with spam prevention software, you may have cycles to burn or you may not.
Their cookie-based fix is offensively lame - not only does the typical implementation of DNS hijacking only "help" queries to http port 80 and maybe https port 443, while breaking other protocols, their opt-out "fix" only fixes connections to those ports from cookie-supporting browsers, not from the applications for other protocols. Comcast's opt-out uses MAC addresses, so at least you can opt out for everything, not just only opt out from the least broken services.
Yup. I've had the document on my desk for a couple of weeks, planning to write a ranting response in my copious spare time. And J. Livingood posted a response somewhere else in this Slashdot comment chain as well.
Using cookies indicates that they Really Don't Get It - if you're using a browser, hijacking your query is evil but not particularly stupid, while if you're using some other protocol, such as email or ssh or even http/https on some port other than 80, the browser cookie isn't going to tell their broken DNS server or web server anything.
I've had a printout of your draft on my desk for a while, planning to write a good rant in response :-)
The "only redirect www.domain.tld" logic certainly helps reduce the number of applications that'll be broken, though I do still https: to www.domain.tld addresses and sometimes do ssh (usually not, and I almost never email them either.)
But even then it's breaking the behaviour my browser is configured for - I've got Firefox using Google as its search engine, and try to have IE do that as well.
As the parent article had said, you've got no way to predict whether they'll be consistent about the IP addresses they use for their redirect page, and you can't just give your application to everybody with the DNS-hijackers' addresses wired in, because they may have ISPs who use different hijack pages or your ISP could change yours at any time. And then there's the problem of load-balanced redirect servers - the service could round-robin between N different redirect servers (instead of anycasting or hiding the load-balancing behind NAT) so you wouldn't even get a consistent redirect page.
And even if your app _is_ the web, the most popular web servers let you pick what search engine to use in case of a NX response, so it's broken even then. Comcast's a little less broken than some hijacking services, since they're only redirecting www.whatever.tld, but who knows how long that'll last as a policy.
Usually it's opt-in - if you didn't set your computer to use their service, your queries won't go there and they won't lie to you. And if you'd rather have the occasional failure (and aren't running your own email server) in return for getting blocked from known malware sites, go ahead and opt in.
The only time it's opt-out is when your ISP decided to use OpenDNS or one of their competitors to do name resolution instead of doing it correctly - I'd be really annoyed if one of my ISPs did that without asking me.
Normally I'd agree with you - I've ranted elsewhere in this story about how DNS hijacking breaks all kinds of things, even including the browsers that it's supposed to be "helping". However, there's one case where it can be useful - hijacking queries for known evil sites (malware-infected, phishing targets, etc.) Unlike hijacking queries that should return Not Found sorts of messages, this returns the address of a "you don't want to go there" warning page instead of the address of the usually-actually-existing evil server. So while it's still incorrect behaviour, it's at least not breaking DNS as badly, and it's only breaking it for cases where a non-broken response would have gotten you somewhere bad anyway (unless of course you're a security researcher who _wants_ to talk to evil servers.)
There's one case where some of the DNS hijacker services aren't purely evil - it's the ones that take queries for known malware sites and redirect them to "you don't really want to go there" pages. That doesn't always do what you want either, but unless you're a security researcher, you probably didn't want any protocols from your machine connecting to malware-infected.example.com, so even a lame protocol-not-equipped failure from DNS-Hijackers.your-ISP.net is better either than a successful or unsuccessful connection to the evil site.
But that doesn't break the protocols as badly, because for the most part it's redirecting queries for sites that _do_ have actual servers on them.
Breaking DNS is bad for non-broken apps - it's only going to be worse for broken ones :-) Your PC's DNS resolver should be set up to use your internal DNS servers in preference to your ISP's DNS servers if possible, so if the VPN is routing 10.x.x.x addresses through the tunnel and non-RFC1918 addresses to the public internet, there won't be a problem with it going the wrong way.
The misappropriation is technically bad because it's done at the wrong protocol layer, and even when it works it's bad because it'll cause your browser to do something you didn't want.
Here's how DNS is supposed to work when it works, and how it's supposed to work when the lookup fails.
Now look at what happens if your DNS server lies to your application by giving it some other IP address instead of the correct failure message, like 68.87.60.144.
I just got a new laptop at work, and it has Office 2007, replacing the 2003 that was on the old one. The only thing that makes it at all tolerable is that my new screen is 900 pixels high instead of 768, so most of the space that the ribbon's burning up is new pixels, but it takes me longer to get to many of the features I use often, and I haven't yet dug around to find all the features I'd like to have, plus it'll take me a while to memorize where it's hiding everything that I considered to be reasonably obvious in 2003.