http://thehackernews.com/2012/02/fbi-will-shutdown-internet-on-march-8.html
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 Solve said problem easily by destination NATing those IPs on 53/UDP/TCP to your own recursive servers, or dump them on Google at 8.8.8.8 if you're so inclined. Extra bonus result: NAT logs will show who needs a pleasant email from customer service. Or you could just let 'em[1] suffer, BoFH-style. jms [1] "'em" in this case is "your customer service reps" who will see a 'higher than normal call volume' should the FBI's warning mean anything. -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms@Opus1.COM http://www.opus1.com/jms
Joel M Snyder <Joel.Snyder@Opus1.COM> wrote;
http://thehackernews.com/2012/02/fbi-will-shutdown-internet-on-march-8.html
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
Solve said problem easily by destination NATing those IPs on 53/UDP/TCP to your own recursive servers, or dump them on Google at 8.8.8.8 if you're so inclined. Extra bonus result: NAT logs will show who needs a pleasant email from customer service.
Even better, nat to a 'bogon' DNS server -- one that -- regardless of the query -- returns the address of a dedicated machine on your network set up especially for this purpose. This special-purpose machine returns a customized 'error message' for any/all 'standard' protocols -- one that states that they are infected with the particular malware, that none of their attempts at intnernet access will work until they get that malware removed, that they need to contact a 'computer repair' business ("See the Yellow pages") to get the problem dealt with, -and- that assistance with such malware removal is -not- part your 'support' services. Lastly, add a statement that any calls to -your- support staff will cause the customer's account a fee of $xx -- just for repeating the above. Th special-purpose machine logs all inbound connection attempts -- timestamp, source IP, and protocol -- for matching against customer accounts, providing a provable audit trail to support the 'penalty' charge, when users -do- call 'support'. Optionally, you refer them to a 'paid consulting' division of your operation, which provides additional services on a time-and-materials basis. This approach is -not- particularly 'customer-friendly' in the short term, but it -will- have long-term benefits for the customer -- they _will_ have learned something about the risks of not 'practicing safe hex', and their machine(s) will (well, _probably_) be safer/more secure in the future. Thus reducing future problems for both the customer and the provider support desk.
Or you could just let 'em[1] suffer, BoFH-style.
[1] "'em" in this case is "your customer service reps" who will see a 'higher than normal call volume' should the FBI's warning mean anything.
On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
Even better, nat to a 'bogon' DNS server -- one that -- regardless of the query -- returns the address of a dedicated machine on your network set up especially for this purpose.
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
On Feb 19, 2012, at 10:59, Ken Gilmour <ken.gilmour@gmail.com> wrote:
On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
Even better, nat to a 'bogon' DNS server -- one that -- regardless of the query -- returns the address of a dedicated machine on your network set up especially for this purpose.
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
It is possible to configure the web server not to log POSTed info. -- TTFN, patrick
On 2012-02-19 12:59 , Patrick W. Gilmore wrote:
On Feb 19, 2012, at 10:59, Ken Gilmour <ken.gilmour@gmail.com> wrote:
On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
Even better, nat to a 'bogon' DNS server -- one that -- regardless of the query -- returns the address of a dedicated machine on your network set up especially for this purpose.
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
It is possible to configure the web server not to log POSTed info.
Per default most webservers (Apache, nginx, etc) won't log POST variables, GET variables will be logged (as they are part of the query) but those should not contain any PII. Greets, Jeroen
On Sun, 19 Feb 2012 13:02:01 +0100, Jeroen Massar said:
Per default most webservers (Apache, nginx, etc) won't log POST variables, GET variables will be logged (as they are part of the query) but those should not contain any PII.
Right. They shouldn't. But the security mailing lists have lots of counter-examples from clue-challenged web developers.. Plan your logging strategy accordingly (is there any safe answer here other than "disable logging" or "log only timestamp and source IP"?)
From ken.gilmour@gmail.com Sun Feb 19 05:04:39 2012 Date: Sun, 19 Feb 2012 11:59:37 +0100 Subject: Re: DNS Attacks From: Ken Gilmour <ken.gilmour@gmail.com> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: nanog@nanog.org
On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
Even better, nat to a 'bogon' DNS server -- one that -- regardless of the query -- returns the address of a dedicated machine on your network set up especially for this purpose.
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
*WHAT* 'confidential data' in which logs? <grin> The aforementioned dedicated machine isn't a real web-server, or a real 'any other' server -- it is solely a special-purpose application machine, When you connect to it on say, port 80, it doesn't log anything from the port -- it just logs (1) the timestamp, and (2) the connecting IP address (and _nothing_ else); then it copies out a previously prepared static file, and disconnects. You build a separae app that reads that logfile, matches IP ddress/timestamp to a customer account, and feeds a message into the 'customer records' system that this customer -has- been notified of this problem, and when, in case they call for support. If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe' between the processes, so that the data never hits disk in the first place. ;) I've got proof-of-concept code for a single program that handles HTTP (port 80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143), IMAP3 (port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far. I'm planing to add IRC, and various SSL-based protocols as well.
-- Sent from my smart phone. Please excuse my brevity On Feb 19, 2012 4:10 p.m., "Robert Bonomi" <bonomi@mail.r-bonomi.com> wrote:
From ken.gilmour@gmail.com Sun Feb 19 05:04:39 2012 Date: Sun, 19 Feb 2012 11:59:37 +0100 Subject: Re: DNS Attacks From: Ken Gilmour <ken.gilmour@gmail.com> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: nanog@nanog.org
On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi@mail.r-bonomi.com>
Even better, nat to a 'bogon' DNS server -- one that -- regardless of
query -- returns the address of a dedicated machine on your network set up especially for this purpose.
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
*WHAT* 'confidential data' in which logs? <grin>
The aforementioned dedicated machine isn't a real web-server, or a real 'any other' server -- it is solely a special-purpose application machine, When you connect to it on say, port 80, it doesn't log anything from the port -- it just logs (1) the timestamp, and (2) the connecting IP address (and _nothing_ else); then it copies out a previously prepared static file, and disconnects.
You build a separae app that reads that logfile, matches IP
to a customer account, and feeds a message into the 'customer records' system that this customer -has- been notified of this problem, and when, in case they call for support.
If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe' between the processes, so that the data never hits disk in the first
wrote: the ddress/timestamp place. ;)
I've got proof-of-concept code for a single program that handles HTTP
(port
80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143), IMAP3 (port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far. I'm planing to add IRC, and various SSL-based protocols as well.
So you're suggesting that the client sends a DNS request to one of the sink holes, which is intercepted by an appliance via some sort of NAT and then dropped? That's also illegal in Europe. You are denying users the right to information. Using a redirect to some sort of Web server (a weird sort of DNS poisoning) will at least inform a user that they're infected. But then that opens another can of worms. I am imagining some sort of Facebook style "free notification system" free to what extent? It also trains users to accept foreign security advice aka fake AV warnings.
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. This or do nothing. http://www.guardian.co.uk/world/2012/jan/18/iran-death-sentence-porn-program... Interpol helps Iran capture a programmer for creating porn sites. Now, if the Interpol want you to block a DNS server, or worse, to spy on users conecting to a DNS server. Will you help? doing nothing is also a good option, methinks. Start medling, redirecting dns trafic, spyiing on the user... all these things are dirty and can't end well. (note, of course, I am a user, so I have a user opinion. ) -- -- ℱin del ℳensaje.
On Mon, 20 Feb 2012 16:38:00 +0100, Tei said:
The right solution is to capture the request to these DNS servers, and send to a custom server with a static message "warning.html".
Not all DNS lookups are for websites. The lookup could be for NTP, or SMTP, or ssh, or a World of Warcraft server, or....
On Mon, Feb 20, 2012 at 12:00 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 20 Feb 2012 16:38:00 +0100, Tei said:
The right solution is to capture the request to these DNS servers, and send to a custom server with a static message "warning.html".
Not all DNS lookups are for websites. The lookup could be for NTP, or SMTP, or ssh, or a World of Warcraft server, or....
thank you.
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... 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
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
On Mon, Feb 20, 2012 at 4:00 PM, Joel jaeggli <joelja@bogus.com> wrote:
be assigned again, so a static filter policy will return to bite us again like it always does.
sure, so you are saying there's a timelimit on how long the supposed ISP can run this infrastructure... and that they have until then to lower their loss rate(s) when customers are cutoff and call their support center because: "The Intertubes are down!". sounds accurate to me... of course, they've already been getting notifications of infected folks, so hopefully they have a jump on the problem already? :) it's wishful thinking monday! -chris
On Sun, Feb 19, 2012 at 4:59 AM, Ken Gilmour <ken.gilmour@gmail.com> wrote:
What happens when the client sends a POST from a cached page on the end user's machine? E.g. if they post login credentials. Of course, they'll get the error page, but then you have confidential data in your logs and now you have to protect highly confidential info, at least if you're in europe.
Either you don't log the data on the webserver, or you notify the user that the POST form data has now been posted, and display the link to the public web page where their posted data now appears, on the error page. Once your user has shared "confidential" information unsolicited with an unknown third party, and the general public, the information's confidentiality was spoiled by the act of posting, regardless of the content of the information -- -JH
On Tue, 21 Feb 2012 16:29:04 CST, Jimmy Hess said:
Once your user has shared "confidential" information unsolicited with an unknown third party, and the general public, the information's confidentiality was spoiled by the act of posting, regardless of the content of the information
I see lawyers booking their vacations in Tahiti now.....
Here is a repeat http://www.theregister.co.uk/2012/02/16/ghost_domains_dns_vuln/ -henry ________________________________ From: "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> To: Jimmy Hess <mysidia@gmail.com> Cc: nanog@nanog.org Sent: Tuesday, February 21, 2012 3:15 PM Subject: Re: DNS Attacks On Tue, 21 Feb 2012 16:29:04 CST, Jimmy Hess said:
Once your user has shared "confidential" information unsolicited with an unknown third party, and the general public, the information's confidentiality was spoiled by the act of posting, regardless of the content of the information
I see lawyers booking their vacations in Tahiti now.....
participants (11)
-
Christopher Morrow -
Henry Linneweh -
Jeroen Massar -
Jimmy Hess -
Joel jaeggli -
Joel M Snyder -
Ken Gilmour -
Patrick W. Gilmore -
Robert Bonomi -
Tei -
Valdis.Kletnieks＠vt.edu