Nine DNS security protection techniques in a Linux application environment

& Nbsp; (1) restrict name server recursive query function & nbsp; disable recursive query to enable name server passive mode, when it sends a query request to the external DNS, it will only answer the query request of its authorized domain, without caching any external data, so it is impossible to suffer from cache poisoning

(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 "exa

Mple.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 program and script interpretation language;

(4) any unused text editors;

(5) unwanted customer programs;

(6) other network services that are not needed.

(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:

The 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 recursive mode query responses with a certain latency.