OpenBSD Journal

Bad Service provider, BAD ...no cookie

Contributed by jose on from the mispelling dept.

oh hell just pick one.. writes: "Verisign bad behavior, Pure Evil - routing table fix on 64.94.110.11 - see Jeremy >>> http://jeremy.zawodny.com/blog/archives/000970.html "

I first saw about this on the NANOG list and since then I have null routed 64.94.110.11 (route add 64.94.110.11 127.0.0.1) for my home network. ISC's BIND 9 now appears to have support to filter this behavior out .

Anyhow, worth doing as a possible protection of your network's privacy.

(Comments are closed)


Comments
  1. By jose () on http://monkey.org/~jose/

    if you run a BGP network, it looks like you can filter this as well:

    http://www.merit.edu/mail.archives/nanog/msg13715.html

  2. By Jeff Flowers () jeff@goo.cc on http://goo.cc/

    I wonder if NetSol understands or cares how pissed off this makes people? I think that they must be run by a bunch of idiots.

  3. By Anonymous Coward () on

    From:
    "Richard M. Smith"


    To:



    Date:
    Today 18:07:52


    Hi,

    Here's another interesting angle on the Verisign Site Finder Web site.
    VeriSign has hired a company called Omniture to snoop on people who make
    domain name typos. I found this Omniture Web bug on a VeriSign Site
    Finder Web page:

    http://verisignwildcard.112.2o7.net/b/ss/verisignwildcard/1/G.2-Verisign
    -S/s03509671784255?[AQB]&ndh=1&t=17/8/2003%2010%3A39%3A28%203%20240&page
    Name=Landing%20Page&ch=landing&server=US%20East&c1=www.elinkprocess.com/
    html/minibank_1000.html&c2=www.elinkprocess.com/html/minibank_1000.html%
    20%2803/00%29&c12=Yes&c13=03&c14=No&c15=00&c16=Yes&c17=15&c22=NOT%20SET&
    g=http%3A//sitefinder.verisign.com/lpc%3Furl%3Dwww.elinkprocess.com/html
    /minibank_1000.html%26host%3Dwww.elinkprocess.com&r=http%3A//www.google.
    com/search%3Fas_q%3Dmini-bank%2B1000%26num%3D100%26hl%3Den%26ie%3DUTF-8%
    26oe%3DUTF-8%26btnG%3DGoogle%2BSearch%26as_epq%3D%26as_oq%3D%26as_eq%3D%
    26lr%3D%26as_ft%3Di%26as_filetype%3D%26as_qdr%3Dall%26as_occt%3Dany%26as
    _dt%3Di%26as_sitesearch%3D%26safe%3Dimages&s=1024x768&c=32&j=1.3&v=Y&k=Y
    &bw=1024&bh=538&ct=lan&hp=N&[AQE]

    The query string of the URL contains the usual things such as the Web
    page URL, the referring URL, browser type, screen size, etc. This query
    string is built on the fly by about 50 lines of JavaScript embedded in
    the Verisign Web page.

    The Omniture server sets a cookie so that people can be watched over
    time to see what typos they are making.

    Here's a bit more about the Omniture snooping service:

    http://www.omniture.com/announcement.html

    Note to Omniture: Yes, I was using Google to research security issues
    with the Mini-Bank 1000 ATM, but my interests are purely academic. ;-)

    Richard M. Smith
    http://www.ComputerBytesMan.com

  4. By ben () on

    The matter with null routing/firewalling this verisign block is that your sendmail queue will expand outrageously.
    Since your sendmail couldn't detect unexistent domains anymore, he will absurdely fail and retry to deliver buggy mails.
    Verisign had set up a simple smtpd that always reply 550 on this address to avoid this problem.
    But this 550-only smtpd if isn't reachable (null-routing policy) the trick won't work indeed.

    Comments
    1. By Pete () on

      k, so work round it. Use policy routing with an ACL that only forwards 'ip = veri_bad && dest port != 25' to /dev/null...

    2. By jose () on http://monkey.org/~jose/

      what on earth are you talking about? have you seen a dramatic reduction in your queue size since verisgn started doing this? seriously, think about it for a second. they weren't doing this prior to this weekend, and no one's queues exploded beyond what they could handle. and now ... now you get 5 carriage returns into it, revealing your from address, your fat fingered to address, and maybe a subject line. not good at all ... it reveals information i'd rather not just hand over to verisgn ...

      anyhow, i don't see a big problem here, and i'm basing this on the fact that we didn't see a big problem before. now, thanks to the verisgn behavior, i do see a possible privacy problem ...

      Comments
      1. By vincent () on

        i think the problem is that before the Dumb Change, bad hostnames were detected...

  5. By Olivier () om_deadlydotorg-post-039a@olden.ch on mailto:om_deadlydotorg-post-039a@olden.ch

    (oops, away for a few minutes, I guess my cat got the Enter key, sorry...)

    I think VeriSign's behavior utterly sucks, and I trust most sane persons agree on this.
    What now?
    I mean, beyond some basic technical "damage control" measures (null-routing/"block return-rst"...)?

    I reviewed the TOS/privacy policy they post on their sitefinder service and I definitely don't agree with it. Can I opt out? Can my ISP? How am I supposed to do this?
    It seems VeriSign also logs DNS queries, so simply blocking whatever address non-existant domains now resolve to doesn't help much (btw, any more info on this, anyone?)

    Beside not resolving any .com or .net domain name, what choice are we given?
    All this is done without most users knowledge, let alone consent. Is this even legal?..

    Register.com was recently sued for not having told its customers it would publish a temporary 'coming soon' page on newly registered domains.
    Isn't VeriSign's move infinitely worse?

  6. By Anonymous Hero () on

    NANOG link (Merit.edu) doesn't work anymmore. I've blocked it this way:

    block out quick on $ext_if from any to 64.94.110.11

    Works fine so far. And i'm not running BIND, so... Qmail-LDAP has a patch. DJBDNS has a patch

    www.nrg4u.com
    www.tinydns.org

    PowerDNS patch is in the make, see the mailinglist for details.

  7. By Olivier () on http://www.whois.sc/verisign-dns/

    (In case people are still reading this thread...)

    A petition against Verisign's abuse of the system is at:
    http://www.whois.sc/verisign-dns/

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]