On 2/20/12 09:57 , Christopher Morrow wrote:
On Mon, Feb 20, 2012 at 10:38 AM, Tei <oscar.vives@gmail.com> wrote:
I am a mere user, so I all this stuff sounds to me like giberish.
The right solution is to capture the request to these DNS servers, and send to a custom server with a static message "warning.html". Nothing fancy. With a phone number to "get out of jail", so people can call to "op-out" of this thing, so can browse the internet to search for a solution.
in this case, the fbi/dns-changer case, the information is pretty straightforward for theisp folk... 'client machine makes dns queries not to the isp dns server (or one of several free dns services), but to a known bad set of netblocks'
the easy fix is to just stand up (forever, ha!) dns servers on the ip blocks inside the ISP's network, done and done...
given the size and distribution of the ip blocks in question I doubt very much that they will go unused forever... from a previous message in this thread. Quoting the FBI: 85.255.112.0 through 85.255.127.255 67.210.0.0 through 67.210.15.255 93.188.160.0 through 93.188.167.255 77.67.83.0 through 77.67.83.255 213.109.64.0 through 213.109.79.255 64.28.176.0 through 64.28.191.255 which map quite nice to various rir prefix assigments. it's almost like someone cribbed the whois inetnum field when they loaded their scattergun... inetnum: 85.255.112.0 - 85.255.127.255 while I have no doubt that some of those prefixes my be run by rather than simply host to bad actors, if they're returned to rirs, they will be assigned again, so a static filter policy will return to bite us again like it always does.
they can then start notifying the customers via mail/email/carrier-pidgeon that they are infected, along with instructions about how to get un-infected.
-chris