| Steps: 1. Target gets DDoS attack, notifing Coordinator for secured DNS update 2. Coordinator talk to TargetDNS, update its DNS records with Proxy IP addresses as ALT type. 3. Coordinator talk to ClientDNS, ask it to fetch updated DNS records regarding Target from TargetDNS. 4. If the TargetDNS are not affected by DDoS attack, Client DNS can tak to TargetDNS through normal internet route and and fetch the updated DNS records. Otherwise ClientDNS needs to setup indirect route to TargetDNS through Proxy and Gateway to avoid the impact of DDoS attack. 5. If the Client access the Target by hostname, the name resolve library with query the ClientDNS and get updated DNS records. Later on, client will use the proxy IP and setup indirect route to Target. Notes:
|
The following is a short tutorial for using the nsreroute command,
an add-on to the popular BIND9 v.9.2.2 DNS software written and maintained
by the Internet Software Consortium.
The purpose of nsreroute is to help the victim of a DDOS (distributed denial
of service) attack keep network services available to legitimate clients during
the attack. At the onset of a DDOS flood, the victim host (or a computer on another
network that can act on behalf of the victim) executes nsreroute, which parses
the contents of a file that contains the following elements:
reroute [legitimate client's SOA hostname] [victim hostname] [victim IP address]
[proxy server IP address] [proxy server IP address] ...
nsreroute first sends a query to the Internet requesting the IP address of
the server of authority (SOA) for a legitimate client. After receiving the reply,
nsreroute constructs a DNS message that includes the following threetuple:
{victim hostname, victim IP address, (list of proxy server IP addresses)}.
(Currently the maximum number of proxy server IP adddresses that can be contained
in the message is 10.) The reroute message is sent to the SOA of the legitimate
client, which authenticates the identity of the sender. Upon successful authentication,
the server writes a new zone file to disk that contains the new mappings
for victim hostname, IP address, and proxy server IP address. The proxy server
IP addresses will be designated by the new type, "ALT", instead of the "A" type
for regular IP addresses. The server also appends a new zone statement to its named
configuration file for the new zone file. Finally the server rereads the named
configuration file and reloads all zone files into memory. It will then be ready
to retrieve all resource records (i.e. hostname/IP address mappings, including those
of type "ALT") to a querying client.
The nsreroute command enables friendly clients to get hostname/IP address records
of a DDOS victim from their own DNS servers instead of from the SOA of the victim.
The presence of the "ALT" type IP addresses in the query reply means that the victim
is being attacked and that the client should send the message intended for the
victim to the IP address of one of the listed proxy server addresses. The proxy
server will forward the message to the victim at a new, secret IP address. This
strategy allows previously known legitimate clients to maintain contact with the victim
while the victim is under attack.
EXAMPLE
dr_doug.familypetclinic.com is being flooded with hundreds of thousands of
packets, including echo replies, UDP datagrams, and TCP connection requests. Fortunately,
Dr. Doug was ready for such an attack, because Dr. Doug himself is a computer enthusiast
and enjoys hacking into unprotected networks in his spare time. But that is beside the
point. Immediately Dr. Doug's network intrusion detection system issues an alert, and
Dr. Doug's server sends a distress signal to a machine on another network. This friendly
machine automatically launches the following command:
nsreroute -v client_file
where client_file contains the line:
reroute spike.niceolddog.com dr_doug.familypetclinic.com 133.41.96.71 203.55.57.102
203.55.57.103 185.11.16.49 221.46.56.38
In this case, Dr. Doug had only one line in the client_file, because he had only one preferred
client name in his database. If his website had more customers, this file could contain
thousands, perhaps hundreds of thousands, of lines starting with "reroute", depending on
how many client hostnames had legitimately accessed his web server. Evidently Dr. Doug
doesn't do too much business online.
This command sends Dr. Doug's hostname, his IP address (first in the list), and list of
proxy server addresses to spike.niceolddog.com. After both client and server verify
each other's identity, the server processes the reroute message, writing a new zone file
to the directory where it stores zone files (usually /var/named). This zone file will
look like:
$TTL 86400
@ IN SOA spike.niceolddog.com. root.niceolddog.com. (
1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ; Negative caching TTL of 1 hour
)
IN NS spike.niceolddog.com.
dr_doug.familypetclinic.com. 86400 IN A 133.41.96.71
dr_doug.familypetclinic.com. 86400 IN ALT 203.55.57.102
86400 IN ALT 203.55.57.103
86400 IN ALT 185.11.16.49
86400 IN ALT 221.46.56.38
This zone file is called "db.familypetclinic.com". As is evident, the IP address of
dr_doug.familypetclinic.com is 133.41.96.71 and is designated as type A. The other
IP addresses are all proxy servers and are designated as type ALT.
Also, in the server's configuration file (located at /etc/named.conf), a new zone statement
has been appended:
zone "familypetclinic.com" IN {
type master;
File "db.familypetclinic.com";
};
The BIND9 named software immediately reloads all zone files into memory, so queries from clients
in the zone covered by spike.niceolddog.com for dr_doug.familypetclinic.com will get all IP
addresses from the zone file shown above, including both type A and type ALT.