Slashdot Mirror
Canadian ISP Hijacking DNS Lookup Errors
Freshly Exhumed tips us to news that Canadian ISP Rogers Cable appears to be redirecting invalid DNS requests to their own search and advertising page. Roadrunner got caught doing the same thing earlier this year. According to the article, "The hijacking appears to be an attempt by Rogers to use its Deep Packet Inspection (DPI) technology to cash in on the mistakes of its users." Freshly Exhumed also reminds us, "As IOActive security researcher Dan Kaminsky has warned in the past, this presents a very serious security problem."
This must be brand new. I did a test just now and a bad URL sends you here:
http://www20.search.rogers.com/search?
With appropriate variables substituted for what you were typing of course, like this:
Enter: http://www.rogersblowz.com and you get:
http://www20.search.rogers.com/search?qo=www.rogersblowz.com&rn=mEelOh0JrKFZejZ
Let the debate rage on!!!
Mark
http://www.opendns.com/
basically it is remove your ISP's dns#s and add these
208.67.222.222
208.67.220.220
Politics is Treachery, Religion is Brainwashing
If the ISP is messing with the DNS service, the best thing to do is to use a different service.
For Linux/Unix users, you can just run a caching-only server on the desktop system, and it will issue its own name requests from the root on down. I've been doing a slightly more complex version of this at home for VPN purposes. (Forward requests to my employer's net to the private internal DNS server (through the VPN), while querying the public internet for all other servers.)
I don't know it a similar option is available for Windows users w/o shelling out big bucks, but it is technically feasible
If you cannot run a caching-only server, another option is to use a third-party DNS server. The only problem here is that it would not be automagically configured by DHCP, and would have to be manually set up.
What the hell? Verizon is doing this now, too. Whenever I type in 'slashdot' in firefox, it just takes me to their useless search page, which is getting REALLY old now. I'm getting pretty disgusted now, and they should get it through their thick heads that if they're gonna charge us money for 'net access, they have NO right to make more money off of us by selling ads instead of allowing our browsers to function as expected.
Show this to your friends and family that don't know what a real hacker is
Verizon has been doing this for a while. I read the Terms of Service, Acceptable Use Policy, etc. every time they update it. It's clearly there, disguised as a 'feature' called DNS Assistance.
However, Verizon does have non-poisoned DNS servers which you can find in their Help pages, along with instructions for changing your machine's settings. http://netservices.verizon.net/portal/link/help/item&objId=23883
They tried to get me to use their poisoned servers, and as soon as I found out (btw, they DO report nxdomain, along with their error handling servers), I went back to the old ones.
The poisoned ones were 68.237.161.12 (nsnyny01.verizon.net) and 71.250.0.12 (nsnwrk01.verizon.net), and the unpoisoned ones are 151.202.0.85 and 151.203.0.85.
-uso.
What you hear in the ear, preach from the rooftop Matthew 10.27b
I've had to do this, and it works. No annoying Verizon snatching my failed DNS lookups!
Of course, if you try to get this out of their so-called "tech support", they will not know what you're asking for until you manage to get down to tier 2 or 3 or so. Amazing as it sounds, teir-one Verizon Fios tech support will glaze over at the mere mention of DNS, and will stupidly keep trying to get you to do inane things with your browser.
Ruby Neural Evolution of Augmenting Topologies
Verizon's non-poisoned dns servers are vulnerable to the newly discovered dns vulnerability. Shout at them!
151.202.0.85 is POOR: 26 queries in 2.1 seconds from 22 ports with std dev 19.03
151.203.0.85 is POOR: 26 queries in 2.4 seconds from 22 ports with std dev 15.08
Check for your self using `dig porttest.dns-oarc.net. in txt`
4.2.2.1
4.2.2.2
It is not recommended to set immutable bit, as it causes issues in various situations (like restoring /etc from a backup).
Failure to write to an immutable file is an API issue unique to Linux boxes that use ext2fs or ext3fs.. Systems that run ReiserFS, XFS, or jfs, don't have this bug.
Future versions of DHCPD/Ifplug, or the C library, may very well properly detect the 'immutable' bit and clear it, before writing, then re-set the bit after finishing.
Just like they do if you're root and try to write to a file that exists with mode 444.
Essentially, immutable bit was historically a half-baked feature intended to be used with 'securelevel'.
The concept is you are able to mark important system files immutable, and then raise the securelevel. Once the securelevel is raised, the filesystem will not allow important system to be changed without booting in single user mode.
The removal of securelevel from the kernel in 2.4.x likely means that the days of the 'immutable' bit are numbered as well. Some day you may upgrade your kernel, and be surprised to find out immutable doesn't do anything anymore.
The reliable way to turn off gathering of DNS settings from DHCP is to use distro-specific instructions.
For example, in Redhat-based distros you edit /etc/sysconfig/network and specify "PEERDNS=no"
Of course, now that you understand the risk that the immutable bit may stop working for you unexpectedly later, you can go ahead and try setting it anyways... because it's easy, and simpler than configuring your network software the right way.
http://www.opendns.com?
Evolution is a state-sponsored, state-protected religion.
opendns.com does the very mangling I want to avoid and calls it a feature. At least they tell you they are doing it, and use it for stuff that could benefit end users (filtering allowed site names) as well as their own advertising. But it doesn't solve the problem. It is just a more "open" and up front version of the problem.
AdBlock gets rid of the Verizon "search" page.
Clickity, clickity, never see again.
I think the most annoying aspect is how we get used to leaving off the 'www' at the beginning of domains with Firefox, and Firefox adds it in for you if the non-www address fails to resolve. With this DNS hijacking this feature is broken.