305 Unit 3 Disscussion

advantages of using the a DNS pseudo root in a Linux server. Introduction DNS, or the Domain Name System, is an integral part of how systems connect with each other to communicate on the internet. Without DNS, computers, and the people who use them, would be required to connect using only numerical addresses known as IP addresses. Besides the obvious problem of having to remember a large number of complex numbers for simple tasks, communicating through IP addresses also causes some additional problems. Moving your website to a different hosting provider, or moving your servers to different locations would require you to inform every client of the new location. DNS servers, the computers that together form the system that allow us to use names instead of addresses, can server many different functions, each of which can contribute to your ability to accessing servers by name. In a previous guide we discussed some of the basic terminology and concepts of the domain name system. We will assume some familiarity with the concepts covered in that article. In this guide, we will talk about some of the different types of DNS server setups and what the advantages, use cases, and properties are of each. The Path of a DNS Query When a client program wants to access a server by its domain name, it must find out how to translate the domain name into an actual routable address that it can use to communicate. It needs to know this information in order to get or send information to the server. Some applications, including most web browsers, maintain an internal cache of recent queries. This is the first place the application will check, if it has this capability, in order to find the IP address of the domain in question. If it does not find the answer to its question here, it then asks the system resolver to find out what the address of the domain name is. A resolver in general is any component that acts as a client-side participant in a DNS query. The system resolver is the resolving library that your operating system uses to seek out the answer for DNS queries. In general, system resolvers are usually what we consider stub resolvers because they are not capable of much complexity beyond searching a few static files on the system (like the /etc/hosts file) and forwarding requests to another resolver. So generally, a query goes from the client application to the system resolver, where it is then passed to a DNS server that it has the address for. This DNS server is called a recursive DNS server. A recursive server is a DNS server that is configured to query other DNS servers until it finds the answer to the question. It will either return the answer or an error message to the client (the system resolver in this case, which will, in turn, pass it to the client application). Recursive servers generally maintain a cache as well. It will check this cache first to see if it already has the answer to the query. If it does not, it will see if it has the address to any of the servers that control the upper level domain components. So if the request is for www.example.com and it cannot find that host address in its cache, it will see if it has the address of the name servers for example.com and if necessary, com. It will then send a query to the name server of most specific domain component it can find in order to query for more information. If it does not find the address to any of these domain components, it has to start from the very top of the hierarchy by querying the root name servers. The root servers know the addresses of all of the TLD (top level domain) name servers which control zones for .com, .net, .org, etc. It will ask the root servers if it knows the address of to www.example.com. The root server will refer the recursive server to the name servers for...

Buy now to view the complete solution

The main benefit of a chroot jail is that the jail will limit the portion of the file system the DNS daemon program can see to the root directory of the jail. Additionally, since the jail only needs to support DNS, the programs related to ISC BIND/DNS available in the jail can be extremely limited. Most importantly, there is no need for setuid-root programs, which can be used to gain root access and break out of the jail. Securing ISC BIND/DNS This part focuses on preventing ISC BIND/DNS from being used as a point of break-in to the system hosting it. Since ISC BIND/DNS performs a relatively large and complex function, the potential for bugs that affect security is rather high with this software. In fact, there have been exploitable bugs in the past that allowed a remote attacker to obtain root access to hosts running ISC BIND/DNS. To minimize this risk, ISC BIND/DNS can be run as a non-root user, which will limit any damage to what can be done as a normal user with a local shell. Of course, this is not enough for the security requirements of most DNS servers, so an additional step can be taken - that is, running ISC BIND in a chroot jail. DNS in chroot Important: The named binary program must be in a directory listed within your PATH environment variable for this to work. For the rest of the documentation, I'll assume ...

Buy now to view the complete solution

First, how does it work? When one types /sbin/chroot directory_name on the UNIX system command line one sees that the new root is now 'directory_name' (the /bin/ls / command produces the listing of files from 'directory_name' presuming that you have an 'ls' command located within your new root). Chroot shell command changes the root directory for a process, goes into this directory and then starts a shell or a user-specified command. Chroot command uses a chroot() system call. The command and the system call have an important difference between them: unlike the shell command, chroot() call does not change your working directory to the one inside chrooted jail. The source of chroot.c (shell command, in Linux part of sh-utils) shows the following sequence of system calls: chroot (argv[1]); chdir ("/"); As will be seen further, it will allow for easy chroot jail breaking. Chroot is often used as a security measure. If one has ever used an anonymous ftp server, one has used chroot. Ftp server chroots itself into a special directory upon the anonymous ftp login. DNS (Domain Name System) daemon bind is often chrooted as well. People also suggested chrooting telnet/ssh remote shell users into their corresponding home directories, so they can only update their web pages. Web servers can be run chrooted too. Smap secure email wrapper from FWTK firewall tool kit runs chrooted to the mail spool directory. When chroot is implemented, programs running inside cannot access any system resources on the outside. Thus all system libraries, configuration files and even devices files should be recreated within the chroot jail. What daemons can be chrooted? If a daemon has to access files that are not easily collectible in one place, chrooting it will be hard. For example, sendmail needs mail spool (/var/spool/mail), other files in spool (such as mqueue), user's home directories (to check for .forward files) and system configuration files ...

Buy now to view the complete solution