Setup DNS Server step by step in CentOS / RHEL

DNS (Domain Name System) is the core component of network infrastructure. The DNS service resolves hostname into ip address and vice versa.

DNS Server Installation in CentOS 6.5

This how-to tutorial will show you how to install and configure Primary and Secondary DNS server. The steps provided here were tested in CentOS 6.5 32 bit edition, but it should work in RHEL 6.x(x stands for version) and Scientific Linux 6.x too.

Scenario

Here are my test setup scenario

[A] Primary(Master) DNS Server Details:

Operating System     : CentOS 6.5 32 bit (Minimal Server)
Hostname             : masterdns.example.com
IP Address           : 192.168.1.200/24

[B] Secondary(Slave) DNS Server Details:

Operating System     : CentOS 6.5 32 bit (Minimal Server)
Hostname             : slavedns.example.com
IP Address           : 192.168.1.201/24  

Setup Primary(Master) DNS Server

[root@masterdns ~]# yum install bind* -y

1. Configure DNS Server

The main configuration of the DNS will look like below. Edit and add the entries below which were marked as bold in this configuration files.

[root@masterdns ~]# vi /etc/named.conf 
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 127.0.0.1; 192.168.1.200;};                      ## Master DNS IP ##
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { localhost; 192.168.1.0/24; };                      ## IP Range ##
allow-transfer{ localhost; 192.168.1.201; };                        ## Slave DNS IP ##  
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
zone "." IN {
type hint;
file "named.ca";
};
zone"example.com" IN {
type master;
file "fwd.example.com";
allow-update { none; };
};
zone"1.168.192.in-addr.arpa" IN {
type master;
file "rev.example.com";
allow-update { none; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

2. Create Zone files

Now we should create forward and reverse zone files which we mentioned in the‘/etc/named.conf’ file.

[A] Create Forward Zone

Create ‘fwd.example.com’ file in the ‘/var/named’ directory and add the entries for forward zone as shown below.

[root@masterdns ~]# vi /var/named/fwd.ostechnix.com 
$TTL 86400
@   IN  SOA     masterdns.example.com. root.example.com. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@IN  NS      masterdns.example.com.
@IN  NS     slavedns.example.com.masterdns     IN  A    192.168.1.200
slavedns     IN  A   192.168.1.201

[B] Create Reverse Zone

Create ‘rev.example.com’ file in the ‘/var/named’ directory and add the entries for reverse zone as shown below.

[root@masterdns ~]# vi /var/named/rev.example.com $TTL 86400
@   IN  SOA     masterdns.example.com. root.example.com. (        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
@IN  NS      masterdns.example.com.@IN  NS      slavedns.example.com.masterdnsIN  A   192.168.1.200
slavedns IN  A   192.168.1.201
200       IN  PTR     masterdns.example.com.201      IN  PTR    slavedns.example.com.

3. Start the bind service

[root@masterdns ~]# service named start
Generating /etc/rndc.key:                                  [  OK  ]
Starting named:                                            [  OK  ]
[root@masterdns ~]# chkconfig named on

6. Test syntax errors of DNS configuration and zone files

[A] Check DNS Config file

[root@masterdns ~]# named-checkconf /etc/named.conf 
[root@masterdns ~]# named-checkconf /etc/named.rfc1912.zones

[B] Check zone files

[root@masterdns ~]# named-checkzone ostechnix.com /var/named/fwd.ostechnix.com 
zone ostechnix.com/IN: loaded serial 2011071001
OK
[root@masterdns ~]# named-checkzone ostechnix.com /var/named/rev.ostechnix.com 
zone ostechnix.com/IN: loaded serial 2011071001
OK
[root@masterdns ~]#

7. Test DNS Server

Method A:

[root@masterdns ~]# dig masterdns.example.com; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> masterdns.example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11496
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;masterdns.example.com.INA;; ANSWER SECTION:
masterdns.example.com. 86400INA192.168.1.200;; AUTHORITY SECTION:
ostechnix.com.86400INNSmasterdns.example.com.ostechnix.com.86400INNSslavedns.example.com.;; ADDITIONAL SECTION:
slavedns.ostechnix.com.86400INA192.168.1.201
;; Query time: 5 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Sun Mar  3 12:48:35 2013
;; MSG SIZE  rcvd: 110

Method B:

[root@masterdns ~]# dig -x 192.168.1.200
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> -x 192.168.1.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40891
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;200.1.168.192.in-addr.arpa.INPTR
;; ANSWER SECTION:
200.1.168.192.in-addr.arpa. 86400 INPTRmasterdns.example.com.;; AUTHORITY SECTION:
1.168.192.in-addr.arpa.86400INNSmasterdns.example.com.1.168.192.in-addr.arpa.86400INNSslavedns.example.com.;; ADDITIONAL SECTION:
masterdns.example.com. 86400INA192.168.1.200slavedns.example.com.86400INA192.168.1.201;; Query time: 6 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Sun Mar  3 12:49:53 2013
;; MSG SIZE  rcvd: 150

Method C:

[root@masterdns ~]# nslookup masterdns
Server:192.168.1.200
Address:192.168.1.200#53
Name:masterdns.example.comAddress: 192.168.1.200

Thats it. Now the Primary DNS server is ready

Setup Secondary(Slave) DNS Server

[root@slavedns ~]# yum install bind* -y

1. Configure Slave DNS Server

Open the main configuration file ‘/etc/named.conf’ and add the lines as shown in bold letters.

[root@slavedns ~]# vi /etc/named.conf 
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 127.0.0.1; 192.168.1.201; };                    ## Slve DNS IP ##      
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { localhost; 192.168.1.0/24; };                     ## IP Range ##   
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
zone "." IN {
type hint;
file "named.ca";
};
zone"example.com" IN {
type slave;
file "slaves/ostechnix.fwd";
masters { 192.168.1.200; };
};
zone"1.168.192.in-addr.arpa" IN {
type slave;
file "slaves/example.rev";
masters { 192.168.1.200; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

2. Start the DNS Service

[root@slavedns ~]# service named start
Generating /etc/rndc.key:                                  [  OK  ]
Starting named:                                            [  OK  ]
[root@slavedns ~]# chkconfig named on

Now the forward and reverse zones are automatically replicated from Master DNS server to Slave DNS server.

To verify, goto DNS database location(i.e ‘/var/named/slaves’) and use command ‘ls’.

[root@slavedns ~]# cd /var/named/slaves/
[root@slavedns slaves]# ls
ostechnix.fwd  ostechnix.rev

The forward and reverse zones are automatically replicated from Master DNS. Now check the zone files whether the correct zone files are replicated or not.

[A] Check Forward zone:

[root@slavedns slaves]# cat example.fwd 
$ORIGIN .
$TTL 86400; 1 day
ostechnix.comIN SOAmasterdns.example.com. root.example.com. (2011071001 ; serial
3600       ; refresh (1 hour)
1800       ; retry (30 minutes)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NSmasterdns.example.com.NSslavedns.example.com.$ORIGIN example.com.
masterdnsA192.168.1.200
slavedns A192.168.1.201

[B] Check Reverse zone:

[root@slavedns slaves]# cat example.rev 
$ORIGIN .
$TTL 86400; 1 day
1.168.192.in-addr.arpaIN SOAmasterdns.example.com. root.example.com. (2011071001 ; serial
3600       ; refresh (1 hour)
1800       ; retry (30 minutes)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NSmasterdns.example.com.NSslavedns.example.com.$ORIGIN 1.168.192.in-addr.arpa.
200PTRmasterdns.example.com.
201PTRslavedns.example.com.
masterdnsA192.168.1.200
slavedns A192.168.1.201

3. Add the DNS Server details to all systems

[root@slavedns ~]# vi /etc/resolv.conf 
# Generated by NetworkManager
search example.com
nameserver 192.168.1.200
nameserver 192.168.1.201
nameserver 8.8.8.8

4. Test DNS Server

Method A:

[root@slavedns ~]# dig slavedns.example.com; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> slavedns.example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39096
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;slavedns.example.com.INA;; ANSWER SECTION:
slavedns.example.com.86400INA192.168.1.201;; AUTHORITY SECTION:
example.com.86400INNSmasterdns.example.com.example.com.86400INNSslavedns.example.com.;; ADDITIONAL SECTION:
masterdns.example.com. 86400INA192.168.1.200;; Query time: 7 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Sun Mar  3 13:00:17 2013
;; MSG SIZE  rcvd: 110

Method B:

[root@slavedns ~]# dig masterdns.example.com; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> masterdns.example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12825
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;masterdns.example.com.INA;; ANSWER SECTION:
masterdns.example.com. 86400INA192.168.1.200;; AUTHORITY SECTION:
ostechnix.com.86400INNSmasterdns.example.com.ostechnix.com.86400INNSslavedns.example.com.;; ADDITIONAL SECTION:
slavedns.example.com.86400INA192.168.1.201;; Query time: 13 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Sun Mar  3 13:01:02 2013
;; MSG SIZE  rcvd: 110

Method C:

[root@slavedns ~]# nslookup slavedns
Server:192.168.1.200
Address:192.168.1.200#53
Name:slavedns.example.comAddress: 192.168.1.201

Method D:

[root@slavedns ~]# nslookup masterdns
Server:192.168.1.200
Address:192.168.1.200#53
Name:masterdns.example.comAddress: 192.168.1.200

Method E:

[root@slavedns ~]# dig -x 192.168.1.201
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> -x 192.168.1.201
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56991
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;201.1.168.192.in-addr.arpa.INPTR
;; ANSWER SECTION:
201.1.168.192.in-addr.arpa. 86400 INPTRslavedns.example.com.;; AUTHORITY SECTION:
1.168.192.in-addr.arpa.86400INNSmasterdns.example.com.1.168.192.in-addr.arpa.86400INNSslavedns.example.com.;; ADDITIONAL SECTION:
masterdns.example.com. 86400INA192.168.1.200slavedns.example.com.86400INA192.168.1.201;; Query time: 6 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Sun Mar  3 13:03:39 2013
;; MSG SIZE  rcvd: 150

Asigra : Agentless Backup in Cloud Environment

Implementing an Asigra backup/recovery solution produces immediate and dramatic benefits. Compared to legacy agent-based alternatives, Asigra software offers:

 

1.Significant savings.

 

Even if agents from traditional vendors were free, an Asigra solution would still enable huge

reductions in operating expenses. As per an estimate, first-year operating expenses alone approach $150,000 for an enterprise environment with 1,000 server agents. Annual

server maintenance and operating expenses for this same configuration add up to nearly $60,000. Eliminating agents eliminates those costs that are in addition to the purchase

price of agents.

 

2.Simple licensing.

 

DS-Client licenses actually ARE free. The DS-System offers businesses a unique pay-as-you-grow pricing model based on the aggregate amount of compressed data stored across the network. Simply purchase software the same as disk capacity—no license fees, no

tracking, no overspending on site licenses—customers pay only for compressed capacity consumed.One piece of soft ware to install, manage, and diagnose.

The Asigra software even self-upgrades, so there is no time-consuming and administrative-resource-draining pushing of agents or updates out to hundreds or thousands

of remote-site systems.

 

3. WAN/LAN/CPU resource conservation.

 

Asigra software runs with negligible impact on servers, workstations,and laptops, eliminating the CPU-cycle hits associated with agent-based solutions. Delta blocking, common fi le elimination and compression technologies also minimize impact on bandwidth and storage resources. While traditional agent-based backup/recovery solutions require implementation of high-speed pipes between the central data center and remote offi ces, Asigra enables the effective use of existing links such as DSL.

 

4. Robust, hardcoded security.

 

Asigra software provides both ‘in-fl ight’ and ‘at-rest’ data protection, utilizing up to 256 bits for AES encryption keys to guarantee extremely safe data transfer and storage. And, it works within the organization’s security framework—there are no agents to open hacker-tempting ports in the fi rewall. With secure data transmission across an IP WAN, the Asigra solution

helps businesses achieve compliance, minimize information-loss liabilities, and protect customer confi dence.

 

5. Elegant’ scaling.

The DS-System is capable of elegantly scaling both in the dimensions of capacity and performance.

This type of scalability is critical for environments with large numbers of remote sites, high-capacity data sets, and rapid high data growth. While agent-based solutions compound

complexity in rapid growth environments, the Asigra agentless backup/recovery solution easily accommodates new capacity, new applications, and new sites. Features such as

integrated loadbalancing ensure effi ciency across multiple DS-System IP addresses.

 

6. Backup consistency, improved recoverability.

 

The simplicity, effi ciency, and security of the Asigra system promote implementation of consistent data backup programs across remote sites. Able to implement more frequent,

successful backup processes, companies can significantly boost data recoverability in environments where success rates below 50% were once the norm.

 

 

Snort : IPS

What Is IPS (Intrusion Prevention System)?

Intrusion Detection System (IDS) is a device which monitors packets on your network. IDS reports attack behaviors based on security rules and signatures applied on the device. However IDS has certain disadvantages, such as high false positive rate, unable to stop Denial of Service (DoS) attack and intrusion from UDP protocols.
Intrusion Prevention System (IPS), on the other hand, not only has the ability of IDS, but also can drop malicious packets and close connection sessions in order to stop further attacks. IPS could achieve Real-time Interdiction by leveraging in-line deployment in the network topology. It analyzes all network traffic passing through system and takes actions to suspicious packets immediately.

Network deployment method of IDS and IPS

Due to the differences between IDS and IPS, the deployment of these two systems is designed according to their characteristics.
IDS usually plays the role of monitoring. IDS must be able to sniff the traffic which interests IDS while not compromise the overall network throughput. Following figure illustrates the typical way of deploying an IDS device on a network.

On the other hand, IPS must take immediate action to suspicious packets. The deployment need to enable IPS to look at each packet and deal with suspicious packet real-time. Typically making all traffic pass through IPS could achieve the deployment requirement. This is so-called in-line deployment.

 

SNORT on Linux to Act as an IPS – The Idea behind It

Generally SNORT is sophisticated IDS software, which monitors network traffic to detect and analyze attacking behaviors according to predefined rules. SNORT sends alerts to network administrator while attacks or abnormal network activities are detected. However, the function of the system is limited to passively monitoring party. The protective action must rely on the administrator’s response.
Though SNORT is commonly used as an IDS, it has some enhanced capabilities could make it into an IPS. This article mainly illustrates how SNORT can act as an IPS device.
By using the following settings, SNORT becomes an IPS to take immediate action to suspicious traffics.

• Network Deployment Method
  • In-line deployment: The inline deployment enable SNORT to look at each packet and deal with suspicious packet directly
• Advanced Network Configuration
  • - iptables
• SNORT Mode Configuration
  • - in-line mode
• SNORT’s rule Actions
  • drop/reject/sdrop

The Actual Implementation – Lab Exercise

We are going to implement a basic IPS box step by step in this lab. This box has 2 interfaces acting as one inline segment and is connected between host A and host B. The following figure shows the topology. Moreover, we will play some packets from host A to host B to see if part of them will be dropped as we expect.

 

Configure and run SNORT in inline mode

Please refer to the following article to see how to install SNORT: http://www.ibm.com/developerworks/web/library/wa-snort1/
Add following rule set to /etc/snort/rules/snort.rules, which allows any packet except tcp packet whose destination is port 23.

drop tcp any any -> any 23 (msg: "Drop telnet packets"; sid: 1000001)
pass ip any any -> any any

Edit /etc/snort/my-snort.conf as follows:

config daq_dir: /usr/lib64/daq
config daq: nfq
config daq_mode: inline
config policy_mode: inline 
output alert_full: stdout
include /etc/snort/rules/snort.rules

Run SNORT with the following command line options

$ snort -c /etc/snort/my-snort.conf -Q --alert-before-pass

Now, we can send an ICMP Ping packet from host A to host B. The ICMP Ping packets should be forwarded successfully because the ICMP packets are allowed in our SNORT rule set.

winson@VM-UBUNTU:~$ ping 1.0.67.2 -c 1
PING 1.0.67.2 (1.0.67.2) 56(84) bytes of data.
64 bytes from 1.0.67.2: icmp_req=1 ttl=64 time=0.838 ms
--- 1.0.67.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.838/0.838/0.838/0.000 ms

Then we can use telnet to send TCP packets destinating to port 23 and we should get a connection timed out message.

winson@VM-UBUNTU:~$ telnet 1.0.67.2
Trying 1.0.67.2...
telnet: Unable to connect to remote host: Connection timed out

We can also go to SNORT console to see these telnet packets are dropped by SNORT

[**] [1:1000001:0] <> Drop telnet packets [**]
[Priority: 0] 
05/03-17:34:41.995762 1.0.67.1:40145 -> 1.0.67.2:23
TCP TTL:64 TOS:0x10 ID:3913 IpLen:20 DgmLen:60 DF
******S* Seq: 0x310D692D Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 156788324 0 NOP WS: 5 

[**] [1:1000001:0] <> Drop telnet packets [**]
[Priority: 0] 
05/03-17:34:44.985455 1.0.67.1:40145 -> 1.0.67.2:23
TCP TTL:64 TOS:0x10 ID:3914 IpLen:20 DgmLen:60 DF
******S* Seq: 0x310D692D Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 156788625 0 NOP WS: 5 

 [**] [1:1000001:0] <> Drop telnet packets [**]
[Priority: 0] 
05/03-17:34:50.995668 1.0.67.1:40145 -> 1.0.67.2:23
TCP TTL:64 TOS:0x10 ID:3915 IpLen:20 DgmLen:60 DF
******S* Seq: 0x310D692D Ack: 0x0 Win: 0x16D0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 156789226 0 NOP WS: 5 

Now it is a Linux box with basic IPS capabilities. You can try to write more complicated SNORT rules to make it more powerful.