View source

==Zone File Processing Defaults in CoCCA ==
In CoCCA software, The default directory to save the processed zone files in /var/www/chroot/etc/namedb/TLD/db.TLD, this mean CoCCA assume that the Bind will be installed with jail environment.

== install Bind in chroot  ==
BIND normally runs as the named process, with named user. we can alsoinstall BIND in chroot jail to limit the files which can named user see.
first we will install the bind in chroot then we will explain how we can configure Bind9 to work with CoCCA in same server, to be able see the zone files which generated by CoCCA, and how CoCCA can send the command : <code> rndc reload </code>, to take the new changes of TLD RR.
to install the Bind in chroot environment we need to do the following:
----
<code>
 yum -y install bind-chroot
</code>
----
Then the script <code> /usr/libexec/setup-named-chroot.sh </code>, will create and fix the chroot directory permission, using the following command:
----
<code> /usr/libexec/setup-named-chroot.sh /var/named/chroot on </code>  
----
Then we need to stop old named process, using the following command : <code> systemctl stop named </code> Or <code>/etc/init.d/named stop in Centos 6</code>
----
The next step is to disable the named service to ba able to start at startup, using the following command <code> systemctl disable named </code> Or <code> chkconfig named off for Centos 6</code>
----
Then we need to start named in chroot, by using the command : <code> systemctl start named-chroot </code>, or in Centos 6 using <code> /etc/init.d/named-chroot start </code>
----
The next step is to enable run the service on boot time, by using this command: <code> systemctl enable named-chroot </code>, Or in Centos 6 <code> chkconfig named-chroot on </code>
----
Now the Bind installed in chroot, we can see the configuration file for named in the following path : 
----
<code> ll /var/named/chroot/etc </code>
----
we can see the following files and directory: <code> named.conf, namedb, localtime, rndc.key, .... </code>, we will use the named.conf to configure Bind9 as a Hidden Master DNS Server and we will configure it to allow XAFR for the other TLD secondary DNS servers, 
----
The Final step is to create symbolic link on /etc as the following : <code> ln -s /var/named/chroot/etc/named.conf /etc/named.conf </code>
----

== Configure Bind9 as a Hidden Master DNS Server ==
----
in this step we will configure the Bind9 which installed in chroot jail, at the same server which CoCCA has been also installed, the CoCCA Software will generate the zone file and store it after processing in the follwoing path: <code> /var/named/chroot/etc/namedb/TLD/db.TLD </code>, this mean the Bind9 should configure to use the db zones file in this path.
----
The Hidden Master DNS Server, is aspecial DNS configuration that protects the master DNS server from attack, and it should be has the following features wich we will convert it to configuration file:
----
-  Only one or more of the slaves know of its existence, which mean A hidden master is a DNS server placed behind a firewall and access restricted to response to query originated by those slaves only.
----
- This server is the primary authoritative server, which means it contains a complete zone file for a given TLD, the authoritative DNS servers should only answer with delegated data for hosted zones, this mean we should disable recursion completely.
----
- Allow zone transfer to slaves using AXFR query using plain transfer or using TSIG keys.
----
The named.conf file divided to many part the first part is the Options part, the main changes should be to this part :
- IP address which will named-chroot listen (IPv4,IPv6), for example:
----
<code>
 listen-on port 53 { Your_DNS_IPv4; };
 listen-on-v6 port 53 { You_DNS_IPv6; };
</code>
- ACL which contain the IP address for allowed slaves to transfer zones, and ACL for denied IP, for example:
----
<code>
acl black-hats {
        10.0.2.0/24;     192.168.0.0/24; };

</code>
----
Allowed slaves to Transfer:
----
<code> acl TLD_IP_ALLOEWD_TRANSFER { </code>
<code>              IPv4; IPv6;      </code>
<code>                             };</code>
----
- define the "view" "production_zones" which will contain the zones and which client allowed to query transfer, and which TSIG keys will be used, for example we can define the view as the following:
----
<code>
view "production_zones" {
        match-clients           { any; };
        match-destinations      { Your_DNS_IPv4; };
        recursion no;
        notify yes;
        allow-query { any; };</code>
        key TLD_IP_ALLOEWD_TRANSFER_TSIG_KEY_TLD { algorithm hmac-sha256; secret "sldjslkdjsljdlskdaaASdSCaxscsdcmxlcmVydowpUH0wAQ="; };
        server Slave_IP { keys { TLD_IP_ALLOEWD_TRANSFER_TSIG_KEY_TLD; };};// this mean the slave should use key to transfer zone
----
<code>
zone "TLD" IN {
        type master;
        file "/etc/namedb/TLD/db.TLD"; //based on chroot directory
        allow-transfer { TLD_IP_ALLOEWD_TRANSFER; };
        also-notify { TLD_IP_ALLOEWD_TRANSFER; };
};
</code>
----
- disable recursion, this can be done at "view" level or at Options level with this statement: <code> recursion no; </code> 
----
- hide the bind version to not allow the attacker to know which bind version you run, this can be done at options level : <code>        version "Not Available"; </code>
----
- customize the log messages and divide it to security log, query log, bind log, example: the security log can be redirected to security.log file, then we can configure the fail2ban to monitor this log file to bolck IP which try to DDoS DNS service over TCP/UDP.
----
<code>
logging {
        channel security_file {
                file "/var/log/named/security.log" versions 3 size 30m;
                severity dynamic;
                print-time yes;
                                 };
        category security {
                security_file;
                            };
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
</code>
----
== Block DDoS Attack Using fail2ban ==
fail2ban will use the <code>/var/log/named/security.log</code> file which has been created at previous section, to monitor the security errors, then will block the attacker by block it using iptables, we need to Edit the<code> /etc/fail2ban/jail.conf </code> file and change from:
----
<code>
[named-refused-udp]
 enabled  = false
----
to:
----
[named-refused-udp]
 enabled  = true
----
and from:
----
[named-refused-tcp]
 enabled  = false
----
to:
----
[named-refused-tcp]
 enabled  = true
</code>
----
Then restart fail2ban in centos 6 <code>/etc/init.d/fail2ban restart </code> Or in centos 7 <code>systemctl restart fail2ban </code>.