Cashback Offer from 4th to 8th August 2021. Get Flat 10% Cashback credited to your account for a minimum transaction of $80. Post Your Question Today!

Question Details Normal
$ 5.00

Unit 3 Discussion: Regular DNS vs Chroot (jail)

Question posted by
Online Tutor Profile
request

Unit 3 Discussion: Regular DNS vs Chroot (jail)

NOTE: PLEASE USE THE ADDITIONAL LINKS BELOW TO ANSWER THIS DISCUSSION QUESTION. PLEASE FEEL FREE TO ADD SOMETHING NEW.

We live in an environment where there are hackers always attempting to get access to our server’s data and configuration. One of the ways to prevent that is by using the DNS jail or chroot. It is a pseudo root that users cannot get any higher in the directory structure.

The tasks of the administrator is to make sure these services that are installed and configured properly so they are not compromised.

In your discussion post:

  • Describe each of the three advantages and provide a screenshot or description of each. You may need to search the public web using a search engine like Google or Bing to find screenshots of systems with different services. Cite any sources you use in APA format; this includes sources for any screenshots that are not your own.
  • When responding to your peers’ posts, describe your initial thoughts on the best advantage over the other system’s services they posted. Note any major similarities or differences your notice between the different services.

Additional Resources

How To Use Chroot with DNS (Links to an external site.)

Install and Configure DNS/BIND With Chroot Feature (Links to an external site.)

Linux Security (Links to an external site.)

Available Answers
$ 5.00

[Solved] Unit 3 Discussion: Regular DNS vs Chroot (jail)

  • This Solution has been Purchased 1 time
  • Submitted On 09 Sep, 2016 09:49:59
Answer posted by
Online Tutor Profile
solution
What's a "Jail"? Though the utility of a nameserver is probably clear to most people reading this tech tip, the concept of "jail" may not be: we've been asked to elaborate. A "jail" is a software mechanism for limiting the ability of a process to access resources outside a very limited area, and it's done with security in mind. A nameserver often talks to the outside world, and time has shown that "the public internet" is a very hostile environment. Should a flaw in BIND be discovered, it could be exploited by one located anywhere on the planet: by isolating the process inside a jail, this restricts the harm that can be done to a compromised system. A jail is created using the chroot() system call (named for "change root"), and it's given a directory name as a parameter. Once this call is made, the root - the top of the directory tree - for this process is changed from / to the directory given, and there is no way for the process to get outside this area. We typically use /chroot/named to jail our nameservers, but we'll note that the "chroot" in the directory name is just a convention: this is not required (e.g., "/usr/local/named" would make a fine jail location too). By itself, this won't prevent some flaw in BIND from being exploited, but the worst that happens is that the nameserver is compromised: it can't be leveraged to taking over the whole system. In this way it's more of a general safety precaution providing defense in depth. Much more information on chroot jails can be found in our Linux Magazine article: Go Directly to Jail - Secure Untrusted Applications with Chroot Pick up the source Get the source at the Internet Software Consortium, and the home page for BIND is http://www.isc.org/products/BIND/. These instructions were written for 9.1.2 on a Red Hat Linux 6.2 system, and we'll try to keep them updated as we upgrade our and customer systems. We generally try to keep running the latest stable versions - we're not generally too adventurous with beta. Our practice is to keep our own build stuff under a /source tree, and to unpack individual sources under it. # cd /source # gtar -xzvf bind-9.1.2.tar.gz This unbundles everything into a subdirectory with the full name of the package, and the next step is to to configure and build it. Configure and build The BIND instructions say to simply run ./configure, but under Linux a couple of additions are required. For many years, we have recommended disabling thread support, because in 2.2 kernels, chroot jailing did not work properly. We have never been brave enough to attempt it with more recent kernels, but we've been getting reports that threading works fine in 2.6. In addition, BIND can support IPv6, the next generation IP addresses (current version is IPv4). BIND typically probes for IPv6 support at runtime, but since we are quite sure that we really don't need this on our networks, we disable it entirely as a safety measure. NOTE: we prefer to remove any existing nameserver installations (especially those provided by the operating system) before installing the new one. This avoids problems with older versions of key binaries lying around and sometimes being at the wrong point in the command-search $PATH. Under Red Hat Linux (for instance), this means removing three packages before doing installations. # rpm -e bind bind-utils caching-nameserver Finally, we want everything installed into the /usr/local hierarchy, so we provide the installation prefix. This said, configuration and installation is quite simple: # cd /source/bind-9.1.2 # ./configure --prefix=/usr/local --disable-ipv6 # make # make install This takes about 15 minutes on a dual-CPU 200 MHz Pentium Pro machine and about three minutes on a 1 GHz Pentium III, and it installs around 200 files under /usr/local. Most of them are #include files for C language programming, and only about a dozen are really needed for a BIND installation. See the complete file list at the end of this document. Build and configure the jail Creating the actual jail itself is much easier than for BIND 8 because so much trash is not required - it's just tremendous. In particular, none of the shared libraries or named binary files are required to live in the jail, and this makes it easier and more secure for us. For more details on our thoughts on chroot operations, see our more detailed tech tip Best Practices for UNIX chroot() Operations The initial steps to configure the jail are: create initial named user and group # groupadd named # useradd -g named -d /chroot/named -s /bin/true named # passwd -l named "lock" the account Remove all the login-related trash under the newly-created home directory # rm -rf /chroot/named Re-create the top level jail directory # mkdir -p /chroot/named # cd /chroot/named create the hierarchy # mkdir dev # mkdir etc # mkdir logs # mkdir -p var/run # mkdir -p conf/secondaries create the devices, but confirm the major/minor device numbers with "ls -lL /dev/zero /dev/null /dev/random" # mknod dev/null c 1 3 # mknod dev/zero c 1 5 # mknod dev/random c 1 8 copy the timezone file # cp /etc/localtime etc Noticeably absent are any ownership/permissions issues: this is deliberate. We'll get to it shortly. Note that the ls command used to verify the major/minor device numbers includes the -L parameter - this follows symbolic links and is required on some platforms such as Solaris. Construct the configuration files The named.conf configuration is central to named operation, and we'll go through creating it step by step. Though these files can get very complex, our first efforts will be for a minimal caching-only nameserver just to get the whole end-to-end process working correctly. Then we'll retrofit to add in needed features such as local domains and access controls. The named.conf file lives in the jail's etc directory, which makes the full path /chroot/named/etc/named.conf. We usually create a symbolic link to make this visible to the rest of the system at /etc/named.conf. # ln -s /chroot/named/etc/named.conf /etc/named.conf Note - we're creating a symbolic link to a file that does not yet exist - this is confusing. But when we edit the file (the next step), it is created properly. Now, using your favorite editor, create the first version of the etc/named.conf file. We suspect that some of these parameters are not strictly necessary, as the defaults will do, but we feel that being explicit will make the daemon easier to debug for the new administrator (less searching for key files). options { directory "/conf"; pid-file "/var/run/named.pid"; statistics-file "/var/run/named.stats"; dump-file "/var/run/named.db"; # hide our "real" version number version "[secured]"; }; # The root nameservers zone "." { type hint; file "db.rootcache"; }; # localhost - forward zone zone "localhost" { type master; file "db.localhost"; notify no; }; # localhost - inverse zone zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; notify no; }; Notice that the directory keyword says /conf, not /chroot/named/conf - this is intended. When running the nameserver inside the chroot jail, all the paths are relative to the top of the jail at /chroot/named. This configuration refers to three additional files -- db.rootcache, db.localhost and db.127.0.0 -- and they are all created in the /chroot/named/conf directory. db.rootcache is a...
Buy now to view the complete solution

The benefits of buying study notes from CourseMerit

Assurance Of Timely Delivery
We value your patience, and to ensure you always receive your homework help within the promised time, our dedicated team of tutors begins their work as soon as the request arrives.
Best Price In The Market
All the services that are available on our page cost only a nominal amount of money. In fact, the prices are lower than the industry standards. You can always expect value for money from us.
Uninterrupted 24/7 Support
Our customer support wing remains online 24x7 to provide you seamless assistance. Also, when you post a query or a request here, you can expect an immediate response from our side.
closebutton
Only 45 characters allowed.
closebutton

$ 629.35