> From [email protected] Sun Feb 19 05:04:39 2012 > Date: Sun, 19 Feb 2012 11:59:37 +0100 > Subject: Re: DNS Attacks > From: Ken Gilmour <[email protected]> > To: Robert Bonomi <[email protected]> > Cc: [email protected] > > On Feb 18, 2012 10:24 PM, "Robert Bonomi" <[email protected]> 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.
