(1) restrict name server recursive query
Disabling recursive queries can enable the name server to enter the passive mode. When it sends a query request to an external DNS, it will only answer the query request for its authorized domain, instead of caching any external data, therefore, it is impossible to suffer from cache poisoning attacks, but such actions also have negative effects, reducing the speed and efficiency of DNS domain name resolution.
The following statement only allows recursive queries on hosts in the 172.1610 network segment:
Allow-recusion {172.1610.3/24 ;}
(2) zone transfer)
If there is no restricted area transfer, the DNS server allows regional transmission for anyone. Therefore, the host name, Host IP list, router name, and Route IP list in the network architecture are supported, even the locations and hardware configurations of each host are easily controlled by intruders by setting in the DNS configuration file to restrict the hosts that can be transferred in the permitted regions, to some extent, information leakage can be mitigated. However, it should be noted that the problem cannot be fundamentally solved even if the whole zone is blocked, because attackers can use DNS tools to automatically query every IP address in the domain name space, so as to know which IP addresses have not been allocated, using these idle IP addresses, attackers can use IP spoofing to pretend to be a host in the system's trusted network for Request Zone Transfer.
The following statement only allows the hosts with IP addresses 172.1610.1 and 172.1610.2 to perform regional transmission with the DNS server:
Acl list {221.3.131.5; 221.3.131.6;
Zone "test.com" {type master; file "test.com ";
Allow-transfer {list ;};
};
};
(3) query Restriction)
If anyone can send a request to the DNS server, this is unacceptable. It is very important to limit the scope of services of DNS servers, so that many intruders can be taken out of the door. Modify the BIND configuration file:/etc/named. add the following content to the conf file to limit that only the 210.10.0.0/8 and 211.10.0.0/8 CIDR blocks of the local server can be queried. You can use the following allow-query clause in the options statement:
Options {
Allow-query {210.10.0.0/8; 211.10.0.0/8 ;};
};
(4) separated DNS (split DNS)
The split DNS technology is used to divide the DNS system into two parts: Internal and External. The external DNS system is located in the public service area and is responsible for normal external resolution; the internal DNS system is responsible for parsing hosts on the internal network. When you want to query domain names on the Internet, the query task is forwarded to the external DNS server, then, the external DNS server completes the query task. The advantage of dividing the DNS system into internal and external parts is that other users on the Internet can only see servers in the external DNS system, but not internal servers, and only exchange DNS query information between internal and external DNS servers, this ensures the security of the system. In addition, this technology can effectively prevent information leakage.
In BIND 9, you can use the view statement to separate DNS configurations. The view statement syntax is:
View view_name {
Match-clients {address_match_list };
[View_option;...]
Zone_statement ;...
};
Where:
◆ Match-clients: This clause is very important. It is used to specify who can see this view. You can use some options in the view statement;
◆ Zone_statement: This clause specifies the partition declaration visible in the current view. If the view statement is used in the configuration file, all the zone statements must appear in the view. For the same zone, the view configured for the Intranet should be placed before the view on the Internet.
The following is an example of using the view statement. It comes from the standard instruction document of BIND9:
View "internal" {match-clients {our-nets ;};
// Match the access of an Intranet Client
Recursion yes;
// Allow Intranet customers to perform recursive query zone "example.com "{
// Define the Zone Declaration visible to the Intranet Client
Type master; file "example.com. hosts. internal ";
};
};
View "external" {match-clients {any ;};
// Match the Internet client's access
Recursion no;
// Internet customers are not allowed to perform recursive query zone "example.com "{
// Define the Zone Declaration type master visible to Internet customers;
File "example.com. hosts. external ";};
};
Next, create a zone file visible to the Intranet client in example.com. hosts. internal, and create a zone file visible to the Internet client in example.com. hosts. external. You can refer to the content described above based on your actual situation.
(5) Hide BIND version information
Generally, software vulnerabilities and risks are related to specific versions. Therefore, the version number is one of the most valuable information that hackers need to collect for attacks. The hacker can use the dig command to query the BIND version number. Then, the hacker can query the version number to identify the vulnerabilities in the software and seek corresponding tools to attack the vulnerability. Therefore, it is unwise and risky to publish the BIND version at will. In fact, hiding the BIND version is relatively simple. You only need to modify the configuration file/etc/named. conf and add the version declaration in the option section to overwrite the BIND version information. Use the following configuration declaration to overwrite the BIND version number. When someone requests the version information, it will not be able to obtain useful version information:
Options {
Version "Unkown"
};
(6) Run BIND with non-root permissions
In Versions later than Linux kernel 2.3.99, BIND can be run with the-u option as non-root permission. This command runs BIND as a nobody user. running as a nobody can reduce the risk of a buffer overflow attack. The command is as follows:
#/Usr/local/sbin/named-u nobody
(7) Delete unnecessary DNS services
Delete unnecessary services on the DNS machine. Network services are an important cause of system security. Common DoS attacks, weak script attacks, and buffer overflow attacks are caused by the existence of network services in the system. Before installing the operating system on which DNS runs, determine the minimum set of services running in the system, creating a DNS server system should not install services such as Web, POP, gopher, and NNTP News. We recommend that you do not install the following software packages: (1) X-Windows and related software packages; (2) multimedia application software packages; (3) any unnecessary compilation and script interpretation languages; (4) any unused text editors; (5) undesired customer programs; (6) unwanted other network services.
(8) reasonably configure the DNS query method
There are two DNS query methods: recursive query and iterative query. Reasonable configuration of these two query methods can achieve better results in practice.
Recursive query is the most common query method. The Domain Name Server queries the domain name instead of the client (lower-level DNS server) that initiates the request. If the Domain Name Server cannot directly answer the question, then, the Domain Name Server performs recursive queries on the branches in each tree of the domain, and finally returns the query results to the client. During the Domain Name Server query, the client is completely in the waiting state.
Iterative query and weighing guide query. The method is as follows: when the server uses iterative query, other servers can return an optimal query point prompt or host address. If the optimal query point contains the host address to be queried, the host address information is returned. If the server cannot directly query the host address at this time, the host address is queried in sequence according to the prompts, until the server prompts that contain the host address to be queried, generally, each guide will be closer to the root server (up). After finding the root domain name server, then, the system looks down as prompted.
Based on the above two points, we can see that recursive queries are the queries that customers wait for the final results, while iterative queries are not necessarily the final results that the client waits, it may be a query prompt. Therefore, there are two problems:
◆ Secondary DNS initiates recursive queries to the primary DNS, which puts performance pressure on the primary DNS. All cross-domain queries must go through the primary DNS to respond to the secondary DNS;
◆ The second-level DNS initiates recursive queries to the first-level DNS, and then the first-level DNS initiates a recursive query response with a certain delay;
Therefore, DNS servers with a lot of traffic prohibit clients from using recursive queries to reduce server traffic.
(9) Use dnstop to monitor DNS traffic
When maintaining the DNS server, users often want to know which users are using the DNS server, and want to make statistics on the DNS status query, and know the DNS working conditions and status in a timely manner. Traditionally, users usually use open-source tools such as tcpdump to capture packets and view DNS data packets by viewing the traffic of port 53. Tcpdump is not customized for DNS traffic, so it may not be very convenient to use. Therefore, you can use the DNS-specific dnstop tool to query the DNS server status.
Dnstop is a very good open source software, users can go to the website http://dns.measurement-idea.
Because the software relies on tcpdump and pcap packet capture Library (libpcap) to intercept and filter packets transmitted over the network, you need to ensure that the system can install the corresponding software before normal installation and use of dnstop. Generally, these two required libraries have been pre-installed in the system. Run the following command to install dnstop:
(1) decompress the source code installation package
# Tar vxfz ddnstop-20090128.tar.gz
(2) switch to the decompressed directory and use the configure command to generate the Makefile file.
# Cd dnstop-20040309
#./Configure
(3) Use the make command for Installation
# Make
After the installation is successful, you can view the DNS Network Traffic monitoring through the corresponding network interface, as shown below:
#./Dnstop-s eth0
0 new queries, 6 total queries Tue Mar 26 19:35:23 2008
Sources count %
-------------------------------
172.96.0.13 4 66.7
172.96.0.14 1 16.7
172.96.0.15 1 16.7