nanog mailing list archives
Re: DNS Attacks
From: Ken Gilmour <ken.gilmour () gmail com>
Date: Mon, 20 Feb 2012 08:45:42 +0100
-- 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>
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.
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.
Current thread:
- Re: DNS Attacks Henry Linneweh (Feb 18)
- <Possible follow-ups>
- Re: DNS Attacks Joel M Snyder (Feb 18)
- Re: DNS Attacks Robert Bonomi (Feb 18)
- Re: DNS Attacks Ken Gilmour (Feb 19)
- Re: DNS Attacks Patrick W. Gilmore (Feb 19)
- Re: DNS Attacks Jeroen Massar (Feb 19)
- Re: DNS Attacks Valdis . Kletnieks (Feb 19)
- Re: DNS Attacks Robert Bonomi (Feb 18)
- Re: DNS Attacks Robert Bonomi (Feb 19)
- Re: DNS Attacks Ken Gilmour (Feb 19)
- Re: DNS Attacks Tei (Feb 20)
- Re: DNS Attacks Valdis . Kletnieks (Feb 20)
- Re: DNS Attacks Christopher Morrow (Feb 20)
- Re: DNS Attacks Christopher Morrow (Feb 20)
- Re: DNS Attacks Joel jaeggli (Feb 20)
- Re: DNS Attacks Christopher Morrow (Feb 21)
- Re: DNS Attacks Jimmy Hess (Feb 21)
- Re: DNS Attacks Valdis . Kletnieks (Feb 21)
- Re: DNS Attacks Henry Linneweh (Feb 21)