Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Programming \ Glibc support encryption by modifying the DNS     - GitLab issued Merge Request return error 500 when the two solutions log (Linux)

- Is Linux the most secure operating system (Linux)

- Easily solve the MySQL database connection error too many (Database)

- lack of SWAP space during installation of Oracle (Database)

- Ubuntu apt-mirror established local private sources (Linux)

- Oracle Character Set Summary (Database)

- Linux command execution order control and pipeline (Linux)

- RPM package management tools under Linux (Linux)

- Java implementation of stacks and queues (Programming)

- Linux regex awk Comments (Linux)

- Why I do not like the Go language style interface (ie Structural Typing) (Programming)

- CentOS Nginx achieve 3 virtual machine load balancing (Server)

- Linux using RAID how to use Mdadm Tool Management Software RAID (Linux)

- installation and configuration of the PHP environment (Apache2) under Linux (Server)

- Ubuntu update bug fixes Daquan (Linux)

- Ubuntu study notes and related problem solving (Linux)

- CentOS6 installed Tomcat (Server)

- The difference between free command displays the buffers and cache (Linux)

- GCC library link order problems (Programming)

- Source code compiled by the installation program under Linux (Linux)

 
         
  Glibc support encryption by modifying the DNS
     
  Add Date : 2018-11-21      
         
         
         
  Domain Name System (DNS) is one of the many weaknesses in Internet security; host applications accessed corresponding IP addresses can be misled to other places. In other words, it will connect to the wrong position, causing the middleman (man-in-the-middle) attacks and so forth. The DNSSEC protocol extension to DNS information through the establishment of a credible encrypted channels to resolve this vulnerability. After correctly configured DNSSEC, the application will be able to get reliable host information queries. About DNSSEC by trying to integrate better into the discussion GNU C library, we know that, to ensure information security DNS queries it is not so simple.



In a sense, this problem is solved years ago, we can configure a local domain name service for complete DNSSEC validation (verification) and allows the application by glibc function to use the service. DNSSEC can even be used to improve security in other areas, for example, it can carry SSH or TLS key fingerprint, so that the application can confirm that the dialogue with the correct server. However, when we hope to confirm the results of this self-proclaimed DNS with DNSSEC validation is not really been certified by the time - that is, when we want to rely on the security of DNSSEC promised, things get a bit complicated.

 

/etc/resolv.conf problem

From the point of view of glibc, the problem is in part because glibc itself does not do DNSSEC validation, instead of referring to the /etc/resolv.conf file server read from the file parsing and validation done, then the results returned to the application. If your application uses the underlying res_query () interfaces, the result will include a "Certified Data (authenticated data)" (AD) identification (if the domain name server is set up, then) to indicate DNSSEC validation has been successful. But they did not know glibc credit these results provide domain name server, so it really does not tell whether the application result is really reliable.

Recommendations by the glibc maintainer Carlos O'Donell proposed increase is an option (dns-strip-dnssec-ad-bit) in the resolv.conf file tells glibc unconditionally remove AD logo. This option can be set by the release, expressed DNSSEC level DNS query results are not reliable. And once established a good right environment can obtain reliable results, and then remove this option. Thus, although the problem has not been fully resolved, at least on the basis of the application has to evaluate the reliability obtained from glibc DNS query results.

A secure environment configuration should look like? This situation should be standard and not too bad: there is a local name server, through the loop (loopback) access interface, as the only access /etc/resolv.conf file entries. This domain name server should be configured to do the check, but the check fails after simply does not return any results. In most cases, the application will no longer need to be concerned about AD logo, if the results are not reliable, the application can not see. Some releases have tended to this model, but the situation is still not as some people imagine that simple.

One of the problems is that in this way the /etc/resolv.conf file into the center of the trustworthiness of the entire system. However, in a typical Linux system, there are numerous DHCP client, the network script and many more programs can modify this file. Like Paul Wouters pointed out, in a short time it is impossible to lock the file. Sometimes this change is necessary: ​​in a diskless system startup, before starting its own domain name server is a domain name service; a whole DNS system environment will be different according to the connected network and change; Runtime in the container is also preferably configured to use the host's domain name server; and so on.

So now generally believed that the existing system in the /etc/resolv.conf file and can not be trusted. So it was suggested to add another profile (/etc/secure-resolv.conf or whatever), but this did not solve the problem fundamentally. In addition, some participants feel that even if there is a run on the loop interface name servers are not really reliable, such as Zack Weinberg even suggested that the system administrator can intentionally disable DNSSEC confirmation (validation).

Since the current system configuration is insufficient trust, it can be inferred that, in the case of improvement can obtain reliable results after, glibc needs to have a way to notify the application. AD logo can be shielded manner discussed above (or "domain name server can trust this" option In contrast, adding a display); of course, this requires a locking system to a certain extent so as not to be subject to any non /etc/resolv.conf expected changes. Petr Spacek as recommended, there is a way the idea is to provide a way to allow applications to query glibc current communication is not a local domain name server.

 

In glibc, which handles?

Another way is regardless of the domain name server, but to do DNSSEC glibc itself confirmed. However, such a large lump of the encryption-related code into glibc also has great resistance. This will increase the size of the library itself, so that the feeling will increase the likelihood of attack using its application. Another extended look in this direction, by the recommendations made by Zack, can confirm the relevant code into the domain name service cache daemon (nscd) inside. Because the nscd is part of glibc, glibc maintained by the developer, so to some extent, can believe that we can confirm that the correct implementation of DNSSEC. And where the communication socket nscd is open, so it can not be considered /etc/resolv.conf problem. However, Carlos fear in this way can not let those who do not want to use nscd cache function accepted by users; in his opinion, can be ruled out nscd way.

So, at least in the near future, glibc unlikely fully implemented DNSSEC confirmed the entire inquiry process. This means that if there is a security application to be used to query the domain name glibc library, the library will need to provide an identity to evaluate the results from an independent domain name server returns to what extent reliability. This almost certainly need to release or system administrator to make some definite changes. Like Simo Sorce say:

If glibc does not use explicit configuration option to notify the application domain analysis with it is credible, there would be no use ...... not change it there is a great drawbacks, because application developers will immediately recognize that they can not be trusted any information obtained from glibc, so when dealing with DNSSEC related information is simply not it.

To configure a system to normal use DNSSEC requires changes to many components of the system - this is a release of a range of problems, take time to fully resolve. In this process of change glibc's role is likely to be relatively small, but very important part: if the application does not implement its own set of domain name parsing code, glibc DNS results are likely to be the only way to ensure credible. Running multiple DNSSEC implementation in a system does not look like a safe way, so it's better to do things right.

glibc project currently no way to determine what to do with this thing, although some tags /etc/resolv.conf file looks almost ready. Such changes should require a new release; take into account the development of glibc conservative nature, it may be too late to join in February is expected to release the 2.23 version. So there will not be glibc temporarily higher security DNSSEC, but in this direction, there are some of the progress.
     
         
         
         
  More:      
 
- Lua4.0 interpreter documents (Programming)
- CentOS / RedHat system partition essential requirements and partition scheme (Linux)
- Why learn and use C language (Programming)
- Linux server remote user to obtain root privileges prevention (Linux)
- Ubuntu system process is bound CPU core (Linux)
- The user of fedora is not in the sudoers file method to solve (Linux)
- Ubuntu install ruby (Linux)
- Installation JDK 1.8 under CentOS7 (Linux)
- Ubuntu 10.04 to Ubuntu 10.10 Upgrade (Linux)
- How to use awk command in Linux (Linux)
- Let Git variety of colors and custom log format output (Linux)
- Stunning exclamation point at the Linux command line (Linux)
- gzip, bzip2, xz, tar, zip compression, archive Detailed (Linux)
- OpenSSH server configuration file for each Common Definition (Server)
- Windows 7 hard disk to install Ubuntu 14.10 (Linux)
- Linux-- sub-volume compression and decompression (Linux)
- Spring Boot + Nginx + Tomcat + SSL configuration notes (Server)
- Mybatis + binding Struts2: achieving user to insert and find (Programming)
- HAProxy Windows version of the compiler and its application in the CORS (Server)
- Nginx version information hidden or modified (Server)
     
           
     
  CopyRight 2002-2020 newfreesoft.com, All Rights Reserved.