Re: DNS Attacks

[Robert Bonomi <bonomi () mail r-bonomi com>]

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.