Blocking SiteFinder Service

← Back to Stories (view on slashdot.org)

Posted by timothy on Wednesday September 24, 2003 @05:54AM from the masking-tape-on-monitor dept.

apankrat writes "Given VeriSign's position on wildcard redirection service, it looks like it's time for a simplier and more efficient ways of bringing things back to where they were. For those running BIND there is a patch; for those on the client side - there is a dnsfix for Windows and the usual iptables hackery under Linux. Aware of any other clean and easy ways to block wildcarding ? Post below."

6 of 38 comments (clear)

Min score:

Reason:

Sort:

dnsmasq has a fix by hummassa · 2003-09-24 06:14 · Score: 4, Informative

here.
version 1.16 is ok.
others have fixes, too, you can find them in this place.

hope I have helped,

--
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
This is working for me in my Firewall by southern · 2003-09-24 06:18 · Score: 3, Informative

I added this to my FORWARD rule on the Firewall:

iptables -A blocked_sites -p TCP -d 64.94.110.11 -j REJECT --reject-with icmp-host-unreachable

Will be doing the DNS patch soon. But this works for now.

--
Chris Southern
or just add a line to etc hosts by coyote4til7 · 2003-09-24 06:33 · Score: 4, Informative

The way I've dealt with it under both XP & OS X is to modify etc/hosts.

Under OS X, Solaris, Linux, etc., it's "/etc/hosts". Under Windows XP, it's "C:\Windows\system32\drivers\etc\hosts"

In either case, add this to the end of the file:
0.0.0.0 sitefinder.verisign.com

Wah-lah!

--

the clock on the wall says 4 til 7
do NOT blackhole/block 64.94.110.11! by graf0z · 2003-09-24 07:00 · Score: 5, Informative
... because then mails to mistyped domains will end up waiting in MTA-queues instead of being bounced immediately (some other protocols may have weird behaviour, too). Instead:
- Read this and this before you panic
- ask your ISP for patching bind (or whatever ns-software they use)
- install a patched bind (djbdns, ...) locally as a caching dns
- if you have no chance of using a patched nameserver (why that?), you may reject (not: drop) 64.94.110.11:80/tcp only and install one of those patches to your MTA (postfix, sendmail, ...)
- if you are customer of verisign, ask them for suspending their new "service"
/graf0z.
Re:Evil, evil, evil by graf0z · 2003-09-24 07:45 · Score: 4, Insightful

The only concern I have with ISC's fix to BIND is that they just filter for that one IP address (64.94.110.11)... all Verisign has to do is change the IP in their wildcard A-record and we'll be back to square one.
wrong
You are talking about one of those on-the-fly patches released by some pissed-of admin on the same day. The ISC-patch allows you to say "the following zone are only allowed to have delegations" (like NS-records), all other data (like A-records) are ignored. That's exactly the behaviour You expect from a TLD.
Of course verisign could get around that (by putting a windcard NS-record into their TLDs), but that would be really offensive. Let's see if they will go that far ...
/graf0z.
djbdns (dnscache) patch by asackett · 2003-09-24 09:28 · Score: 3, Informative

Here is a site linking to a patch for dnscache users. I'd prefer a hack along the lines of what [groan] ISC has implemented, but if verislime were to delegate and then spoof, ISC's hack would stop working, while the dnscache patch would simply require a bit of administwiddling and then keep right on working.
Patch 'em up and move 'em out...

--
Warning: This signature may offend some viewers.