Home PC Games Linux Windows Database Network Programming Server Mobile  
           
  Home \ Programming \ Glibc support encryption by modifying the DNS     - Depth study and understanding for individual users suicide DDoS attacks (Linux)

- Chrome plug-in management, online-offline installation, part of the plug presentations (Linux)

- Share Practical Tutorial GitHub (Linux)

- The YUM package management under Linux (Linux)

- MySQL optimization of the relevant Group By (Database)

- 10 practical Java programming technology (Programming)

- impdp error ORA-39001, ORA-39000, ORA-31619 (Database)

- Availability Hadoop platform - Oozie Workflow (Server)

- Enterprise Hadoop cluster architecture - Hadoop installation (Server)

- To_explore Linux system boot process (Linux)

- NAT (network address translation) Realization (Linux)

- Why do I prefer Git (Linux)

- Linux disk quota-related instruction (Linux)

- ORA-28000 the account is locked fault simulation (Database)

- Example of use WebSocket (Programming)

- Configuring the PXE server in Ubuntu 14.04 (Server)

- Apache Spark1.1.0 deployment and development environment to build (Server)

- ApacheDS configuration of users and user groups to achieve SSO (Server)

- The difference between IPython and Python (Linux)

- The official release method to upgrade to Ubuntu 15.04 (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:      
 
- Linux package management (Linux)
- Let CentOS perform PPPoE dial-up, ADSL can be used in a network environment! (Linux)
- Memcached installation, configuration and monitoring (Server)
- AngularJS - Getting Started with Routing (Programming)
- Use backup-manager system backup on Linux (Linux)
- Linux user directory (Linux)
- Oracle Linux 7.1 install Oracle 12C RAC (Database)
- CentOS 7 Configure logging (VirtualBox) (Linux)
- Ubuntu install OpenMPI (Linux)
- OpenStack image production in the CentOS 6.2 (Linux)
- Java Generics Introduction --HashMap summary (Programming)
- APF firewall installation and configuration under Linux (Linux)
- MongoDB 3.2 to upgrade from 3.0.7 (Database)
- Open SSH remote access service that allows Android phone Ubuntu 14.04 (Linux)
- MongoDB query statistics grouping remove duplicate records (Database)
- Windows 8.1 hard drive to install Ubuntu 14.04 dual system reference tutorials and multi-drive Precautions (Linux)
- Install the latest Pinta graphics editing software on Ubuntu 14.04 (Linux)
- RHEL7.0 configuration CD-ROM to the local YUM (Linux)
- Intruder tools Knark Analysis and Prevention Linux environment (Linux)
- CentOS7 method to upgrade the kernel to 3.18 (Linux)
     
           
     
  CopyRight 2002-2020 newfreesoft.com, All Rights Reserved.