Home page logo
/

nanog logo nanog mailing list archives

Re: DNS Attacks
From: Robert Bonomi <bonomi () mail r-bonomi com>
Date: Sat, 18 Feb 2012 16:29:17 -0600 (CST)


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.




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault