Featured

Selasa, 12 Agustus 2008

Tips & Tricks for securing BIND on linux

It's about time I wrote this article. In this topic we'll going to think worst case scenario. What if somebody found a very bad bug in your version of BIND? What if this bug allowed a hacker to execute commands on your system? Do we really have to place the security of our system and domains in the hands of the BIND programmers? NO! Place your security in the hands of linus torvalds (the mastermind behind linux) by using linux chroot, user/group, and file permissions to your advantage.

The magic that is setuid (Set User ID)

Let's pretend the worst case scenario happened. A hacker has exploited BIND and is running commands on your server through port 53 - the port BIND uses for DNS service. What is he able to do with this power? Well, lucky for you, you're probably already involved in linux security 101: don't EVER run services as root! Yes, sure, you have to run bind as root in order for BIND to use the restricted port 53. But if you're smart, you ran bind with the "-u" option to tell it to setuid() to a non-privilaged user. Typically, the user "named" is created for this purpose. The "named" user is granted permission to read and write to only files and directories bind has business with and any commands that a normal user is allowed to run. So don't worry, a hacker won't be able to tell BIND to run "rm -rf /" on your entire file system. BIND couldn't do it even if it wanted to after it setuid's to "named" and starts the dns service.

Linux file permissions

But BIND can't be denied all access rights. It needs to be able to read its configuration file named.conf. It needs to be able to read all the zone files. It also needs to be able to write its process id to a file (see BIND configuration docs for "pid-file"), and to write slave transfers to zone files, and if you use dynamic update, it needs to write to zone files and create journal files as well. You need to make sure it has these access rights. After all, you're not letting it run as root right? right???

Remember that anything BIND can do, your hacker can do as well. If BIND can write to your zone files, so can a hacker. A hacker might think it's funny to point your domain at a porn site. We need to limit this kind of destructive behavior. So let's start at the beginning of the typical BIND zone file directory tree:

/var/named/

BIND is the only user who has any right to be in this directory, so give it full access rights for the named user and group (assuming you've got a named group). The first command below says that only the user "named", and the any users in the group "named" has access to this directory. The second command says that the "user" has execute, read, and write permissions to the directory (the first 7). So does the group (the second 7). But everybody else isn't allowed to look or touch (the 0).

chown named:named /var/named
chmod 770 /var/named

Now for the interesting and fun part: customizing your system. By no means is this the only solution, but it's a solution that I figure sounds fun at the time. Create 2 more directories with appropriate permissions. The first directory will be for secured zones that BIND is only allowed to read from. The second directory is for unsecured zones that BIND is also allowed to write to. Remember that for chmod, the first digit is user permissions, the second digit is for group permissions, and the third is for everybody else. The number 7 is full permissions (4=read + 2=write + 1=execute). The number 5 is write access denied (4=read + 1=execute). Remember that directories must have execute permission to show their contents.

mkdir /var/named/secured
mkdir /var/named/unsecured
chown named:named /var/named/*
chmod 550 /var/named/secured
chmod 770 /var/named/unsecured

Ok sweet, now what do we do with this bit of architecture we've built? Place all your master zones in the secured directory. That way BIND isn't allowed to change them, but still being able to load them. Place all your slave and dynamic zones in the unsecured directory where BIND simply has to have write access. Then tell BIND where these zones are in your named.conf. At any time you can mass set the permissions for all your zone files with the following commands. The first command grants read access ONLY to all files in the secured directory. The second command grants read and write access for all files in the unsecured directory.

chmod 440 /var/named/secured/*
chmod 660 /var/named/unsecured/*

eh, you can probably take this concept and change the permissions for your named.conf and pidfile. But these are unimportant matters, so I'll leave that fun up to you. We're finished with the important part, and hopefully you now have a good handle on linux file permissions.

If you're still afraid BIND might hurt you, throw it in jail!

Even if BIND is doing the best it can by running as a non-privilaged user, you're not completely safe. What if a hacker working through BIND can exploit your system? This is part of the art of hacking. It's the use of imagination and creativity and pulling in all kinds of experience and knowledge toward a single goal - gaining root on your system. Through a series of commands and tricks and exploits the hacker might be able to reach this ultimate goal. Suddenly, nothing is safe anymore.

But this giant in security that is linux has yet another line of defense: chroot. By running it in chroot, the program is restricted to a tight little box where their burly brutish jail keeper is the linux kernel itself. In this situation the kernel is not impressed by root permissions, and will quarantine BIND from the system no matter what it has to say about it. But enough glamour, how do we get it working? First of all, you execute BIND like so:

named -u named -t /jail/named

The path can be anything you want. I just chose "/jail/named" cause you might want to jail other services besides named, and the named directory is its own little special box. But yeah, it's the -t option that tells BIND to tell the kernel to throw it in jail. Once in jail, BIND has a totally new directory heirarchy:

/jail/named/var/named/secured/
/jail/named/var/named/unsecured/

See what's happening here? Anytime BIND is looking for a file called "/var/named/secured/bob.zone" it is really accessing the file "/jail/named/var/named/secured/bob.zone". That's where the name comes from. Chroot = Change Root. You are creating a virtual root directory from BIND's perspective. There's some work involved in making sure the jail is habitable by BIND, cause stuff like "/dev/null" and "/dev/random" will no longer be accessible unless you setup an equivilent in "/jail/named/dev/null" and "/jail/named/dev/random". Writing a tutorial for chroot'ing BIND is beyond the scope of this document (to be honest, I've never bothered with it). But here's what looks like a good tutorial on how to prepare the jail and place BIND in it:

www.faqs.org: Chroot-BIND-HOWTO


source : http://forums.devshed.com/dns-36/bet-you-want-to-setup-a-dns-server-huh-141940.html

Setting up BIND under linux

ah, most excellent. Either you're a veteran linux user who wants to configure BIND, or you're a linux newb who has to configure a linux/unix dedicated server. Or some combination. In the previous post I emphasized BIND configuration. In this post I'm going to emphasize on how to get around linux so that you can manage BIND. BIND should already be installed, so let's start orientation shall we?

Most likely location for the BIND files:

/usr/sbin/named - BIND server process
/usr/sbin/rndc - BIND management tool
/var/named/ - Location of zone files
/etc/named.conf - BIND configuration file

Even if those aren't the right locations, you can find a file by entering the following commands:
updatedb - update the locate database
locate rndc - example to look for a file

Ok first let's grab the DollarDNS example configs. Enter the following commands (NOTE: if you are not already logged in as root, do so by entering the "su" command then typing your root password):

cd /etc
wget http://www.dollardns.net/bind/named.conf
cd /var/named
mkdir /var/named/old
mv * /var/named/old/
wget http://www.dollardns.net/bind/basiczone.com.zone
wget http://www.dollardns.net/bind/127.0.0.rev
wget http://www.dollardns.net/bind/named.ca

There, the above commands replaced your current config, moved all existing files to a subdirectory, and downloaded the example zones. Now open the config file:

vi /etc/named.conf

-- open named.conf --

You are now using the vi editor which can be found on pretty much any linux or unix system. Let's go into edit mode. Press the 'a' key. Now you can start editing the file. Please look at the above post and follow the directions to make the file host your domain. The only difference is that you can ignore the "directory" line. It's already properly configured. Also if you run a firewall (like iptables) then you should uncomment the "query-source" line by removing the '#' in front of it.

When you are done editing press the 'esc' key to go back into command mode. Then type the following and press enter to save and close the file.

:wq

-- close named.conf --

now we need to do some file manipulation. I'm going to pretend that your domain is "example.com" and your public IP (www.whatismyip.com) or dedicated server ip is 12.345.67.8. So enter the following commands except enter the right domain and first 3 digits of your ip.

mv basiczone.com.zone example.com.zone
mv 127.0.0.rev 12.345.67.rev

There, using those move commands we've renamed the files to match with what you specified in named.conf. Remember how to edit files using vi? Let's edit those files with the correct dns information.

-- open example.com.zone --
** see windows post for editing details **
-- close example.com.zone --

-- open 12.345.67.rev --
** see windows post for editing details **
-- close 12.345.67.rev --

There, hopefully you've got all the editing all tucked away.

Now, I don't know if BIND is actually running. So we're going to do a rude shut down of named if it is running.

killall -KILL named

That'll terminate the named process no matter how screwed up it is. I don't recommend using that command in normal operational circumstances. You should do the following command instead:

rndc stop

It should work without the path since /usr/bin should be in your PATH environment variable. If your server was already running normally, then you can do the following command to have BIND reload all configuration changes:

rndc reload

To start named you enter the following command:

named -u named

The "-u named" part makes sure it is running as the "named" user cause if you started it as root, you'd be in serious trouble if a exploit was discovered for your version of bind. Oh btw, don't know what version you're running? Do the following command:

dig @127.0.0.1 version.bind txt ch

Yep, the whole world can ask your server what version of BIND it is. You can change that, but changing the displayed version is not covered by this basic tutorial. You can always ask me how though. To test to see if named is successfully running you can also do the above command. It'll say there was a timout or something. If BIND didn't successfully start, you can always do the following command to see what's up:

named -u named -g

Basically you're starting BIND in the console. It will either shut down due to errors, or you have to press CTRL+C to terminate it. Fix any errors you see or tell me about them in a post.

Want BIND to start with your system? Well, it's probably already doing so, but you can check to make sure in the following file. This is accurate on redhat 9.0. It may be different on your system:

vi /etc/rc.d/init.d/named
vi /etc/sysconfig/named

In that file you can see how named is started on system boot. Sometimes default configurations do something funny with "chroot" (covered in my next tutorial) which wouldn't work too well with how you configured things above. Any chroot configuration is probably in the sysconfig file. Also there's a chance it uses the "-c" argument which tells named that "named.conf" is located someplace other than /etc/named.conf. If you don't know how to manipulate this file, then it's probably best not to, and just start BIND manually.

Let's see, what else. We've edited all the files, I've told you how to stop, start, and reload BIND. Told ya how to debug, and where the startup script might be. aha, here's a linux command cheet sheet useful for managing BIND:

mv oldpath newpath - move files and directories
cp oldpath newpath - copy file from one place to another
ls -la - list the current directory's contents
ps -Af - list currently running processes
killall process - kill all processes by that name
cd path - change directory
pwd - display current directory path
rm file - delete a file
rmdir dir - delete a folder
rm -rf dir - delete a directory and all its contents
mkdir path - create a folder

You might want to delete the following file. It's useless, we should use default parameters:

rm /etc/rndc.conf

You might want to delete the following file. It's useless, comes with some OS's:

locate named.custom
rm /path/to/named.custom

Well that's it. Check out the end of the windows post to learn how to test your domain to make sure it's working right.

source : http://forums.devshed.com/dns-36

Setting up BIND under windows

Download the BIND executeable linked from the previous post and install it to the default directory. Make sure that in BIND's installation window that you specify a password for the named user.

Under Windows XP, %WINDIR% is 'C:\WINDOWS'
Under Windows NT/2K/2K3, %WINDIR% is 'C:\WINNT'

%WINDIR%\SYSTEM32\dns\bin

In this directory you have all of the BIND executeables. Here's a description of the executeables I'm going to bother mentioning:

named.exe - This is the BIND server program
rndc.exe - This program can be used to manage the server
named-checkzone.exe - This program can be used to check the syntax for zone files
named-checkconf.exe - This program can be used to check the syntax for config files

%WINDIR%\SYSTEM32\dns\etc

In this directory you have all the configuration files and zone files. Delete all the files you see in here. Then download my template BIND Config files to this directory. Ignore the sub directories at the link. Here's a description of the files:

named.conf - Tell bind what domains you are hosting - plus some extra config stuff.
rndc.key - This is the authentication key for rndc.exe to manage named.exe.
named.ca - These are the DNS root servers.
basiczone.com.zone - This is an example zone file.
127.0.0.rev - This is an example of a reverse IP zone file.

If you are the intuitive sort, reading the comments in these files should teach you all you need to know to get everything setup to your satisfaction. However, I'm going to assume you're still confused, so let's move on. The first thing we need to do is configure BIND to be the host of your domain. So crack open named.conf in notepad.

-- open named.conf --

First we need to tell BIND where our zone files are going to be stored. Currently it is set to this:

directory "/var/named";

That may be fine under linux, but we need to change it to this. Don't forget to replace %WINDIR% with the path to your windows directory.

directory "%WINDIR%\SYSTEM32\dns\etc";

Now let's pretend the domain you want to host on your server is called "example.com". Let's edit the file so that it is using our domain. Scroll all the way down to the end of the file. You will find this zone block:

zone "basiczone.com" IN {
type master;
file "basiczone.com.zone";
};

Seems pretty straight-forward. We are going to be the master of the domain, so the type is "master". It also provides the name of the file that stores information about the "basiczone.com" domain. Let's change that to this:

zone "example.com" IN {
type master;
file "example.com.zone";
};

Excellent, we are now the host of our very own example.com! The file "example.com.zone" that will be in our etc directory will take care of domain->IP resolutions, but we also need IP->domain resolution as well. So take a look at this other zone block:

zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.rev";
};

Now we see why it's called a "reverse" zone. The IP address is reversed for resolution purposes to make it act like a domain. Now go to www.whatismyip.com and copy that IP address. I'm going to pretend that the IP is 12.345.67.8. Let's edit the zone block to say this:

zone "67.345.12.in-addr.arpa" {
type master;
file "12.345.67.rev";
};

Wondering why we aren't including the last number 8? It's because this demonstration is creating a reverse zone file for all the IP addresses that start with 12.345.67. In the zone file we'll configure which ending IPs are pointing to what.

-- close named.conf --

So now we're done configuring named.conf. We need to setup the domain and reverse ip zone files now. In your etc directory, make the following changes:

rename basiczone.com.zone to example.com.zone
rename 127.0.0.rev to 12.345.67.rev

Once again we're at a point where the dns server will run perfectly fine. However, our DNS info will be all wrong wrong wrong. So on to editing your example.com domain. We're assuming the following:

You registered ns1.example.com at your registrar with 12.345.67.8
You registered ns2.example.com at your registrar with 12.345.67.8
You specified the following servers as hosts for your domain at your registrar:
ns1.example.com
ns2.example.com

-- open example.com.zone --

There's a few confusing points about this file that you may be wondering about. A zone file is filled with "records". Each record takes a domain, and assign it to some piece of information. The file is also organized into columns. Here's a description of them:

Column1: The domain to assign the information

In the first column we have these values: @, ns1, ns2, www, mail. The '@' is a symbol for the name of our zone. That would be 'example.com' in this case. The other words are simply a shortcut for "ns1.example.com", "ns2.example.com", "Www.example.com", and "mail.example.com" respectively. BIND will add on the zone name when it reads the file.

Column2: The type of information we're assigning

In the second column we have these values: SOA, NS, MX, A. Just ignore the SOA record, it's required. The NS records are where we specify the names of the dns servers that host our domain. The MX record is where we assign the name of our email server for @example.com. And finally, the 'A' records is where we assign IP addresses to the domains.

Column3: The information data

This is what we're going to have to edit. The NS records are fine if you added "ns1.example.com" and "ns2.example.com" as hosts for your domain at your registrar. If not, you need to change the data values to the names of the dns servers you DID assign at your registrar. The MX record is also fine if you want "mail.example.com" to be your mail server. The 'A' records have got to change though. If you're hosting your own mail server and web server, change all the IPs to 12.345.67.8 (replace that with your real IP of course).

-- close example.com.zone --

All done with that. Let's move on to the reverse zone:

-- open 12.345.67.rev --

Things are a little bit different in this file. Notice that we've got some full domains. You are allowed to specify full domains in your zone files IF you have a period stuck on to the end of it. Always put that period on there if you DON'T want BIND to automatically append the zone name to the end of the domain. We also got a new record type called PTR. The PTR record is what you use to assign a domain to an IP. PTR records should only be located in reverse IP zones. In this zone we are assigning domains to 4 IP addresses. All 4 IPs begin with 12.345.67 since that is the name of our zone, and the last digit can be found in the first column. Delete all these records:

1 PTR ns1.basiczone.com.
2 PTR ns2.basiczone.com.
3 PTR mail.basiczone.com.
4 PTR www.basiczone.com.

In our demonstration we only have 1 IP, so let's make only 1 PTR record for the IP ending with 8.

8 PTR mail.example.com. ;12.345.67.8 points to mail.example.com

We actually have a lot of domains pointing to that IP, but we should only specify one of them. Since many mail servers require RDNS for you to send mail to them, I had the mail domain assigned to the IP. We also need to change the NS records from:

@ NS ns1.basiczone.com.
@ NS ns2.basiczone.com.

To the name servers that host a reverse zone for this IP:

@ NS ns1.example.com.
@ NS ns2.example.com.

-- close 12.345.67.rev --

Now let's talk about how to manage the server.

start the server

Windows: Control Panel->Administrative Tools->Services->ISC BIND->Start

stop the server

Windows: Control Panel->Administrative Tools->Services->ISC BIND->Stop
DOS: %WINDIR%\SYSTEM32\dns\bin>rndc.exe stop

reload config

Windows: Control Panel->Administrative Tools->Services->ISC BIND->Restart
DOS: %WINDIR%\SYSTEM32\dns\bin>rndc.exe reload

If you try to start the server and it says the application terminated unexpectedly or something, check the error logs like this:

Windows: Control Panel->Administrative Tools->Event Viewer->Application Log
DOS: %WINDIR%\SYSTEM32\dns\bin>named.exe -g

If you did fail to start the server, it means named.conf has a syntax error someplace. Either try to figure it out yourself, or show me the logs using the DOS method.

Got the server start? excellent! Now let's test your configuration. I wrote a tool called "DNS Crawler" and it is a great way to test your dns server config remotely.

http://www.dollardns.net/cgi-bin/dnscrawler/index.pl

In the above URL, enter your IP in the "server" field. The domain you registered in the "name" field. And "AXFR" for the type. Press "submit query" and you'll see your entire zone if you didn't mess up someplace. If you got a "server failure" then you need to check out the logs to see why. "server failures" most commonly happen when you have a syntax error in your zone file.

The above test uses TCP port 53. We should also make sure that normal UDP queries also work. Make the same query except change the type to "ANY". That will display all records assigned to the root domain. (the ones that start with @ in your zone file).

Another great resource for checking the syntax of your domains is in the below link. Create a master or reverse zone, and change it up. It will tell you if you try to save a zone with syntax errors. There's also a DNS Crawler link to check the format of your zone.

DollarDNS DNS Manager

And by golly, I think I'm done with this tutorial.

source :
http://forums.devshed.com/dns-36/bet-you-want-to-setup-a-dns-server-huh-141940.html

Setting up Private Nameservers in Cpanel

This guide will show you the ropes in how to setup cpanel nameservers and configure them properly so you can run ns1 and ns2.yoursite.com. Once your nameservers are setup clients can then use your own private nameservers for their domains.


1. Regiser your domain
Register the domain name you would like to use, you can register a domain here if you need one.This domain will be used as your nameservers - eg ns1.yourdomain.com and ns2.yourdomain.com


2. Additional IPs
Have 2 available IP addresses for your server that aren't in use.You will need to contact you provider to obtain these IP addreses.


3. Registering the Nameservers
Now login to your domain management page for the domain you registered and register ns1.newdomain.com and ns2.newdomain.com as nameservers (registries normally have a special facility for doing that). The registry may also have a facility to propogate these nameservers around the foreign registries - if so, you should use this facility.

These registrations may take a few days to propagate (often as many as 3 days).

Article provided by WebHostGear.com


4. Reverse DNS
You may also need to get your data centre to enter a reverse DNS pointer for your nameservers. You'll need to let them know each nameserver and its IP address. Sometimes you can suffer non-delivery of mail if you don't so this. Reverse DNS pointers can take a while to propagate.
Setup a reverse on the IP address for your domain

Article provided by WebHostGear.com


5. Broken NDC/BIND
My version of WHM/CPanel came with a broken NDC. To fix this:

SSH into your box as root.

(a) Type: cd /scripts
(b) Type: ./updatenow
(c) Type: ./fixndc

Go back into WHM, go to the Restart Services section in the left menu and click DNS/Nameserver (BIND).

You will need to do this if you start getting 'ndc' errors when you are doing anything DNS related in WHM.


6. Setup Nameservers In WHM
Go into WHM (Web Host Manager) and select Edit Setup from the Server Setup menu on the left. Enter ns1.newdomain.com in the Primary Nameserver field. Hit 'Assign IP Address', then hit 'Add an A Entry for this nameserver'.
Repeat this process for the Secondary Nameserver field.


7. Tidy Up Junk Nameservers
Go into WHM (Web Host Manager) and select Manage Nameserver IPs from the Server Setup menu on the left. Remove any nameservers you don't recognise. This is just a tidy up exercise in case anyone's set anything up on the box before you.


8. Initial Nameserver Setup
Go into WHM (Web Host Manager) and select Initial NameServer Setup from the Server Setup menu on the left. Run this.


9. Restart BIND
Restart BIND (step 7 restarts BIND, but we've known it to need a proper stop and start for it to work) from SSH with:

service named stop
service named start


10. Manual Checks
I don't know what it is about this process, but it doesn't always work, so there are some things you can check manually via SSH.

/etc/wwwacct.conf
Check that the nameservers are correctly specified on NS, NS2 etc.
EG: scroll to the name servers section.....
NS ns1.yournameserver.com
NS2 ns2.yournameserver.com

/etc/resolv.conf
Check that there are nameserver entries for each IP. There may also be one for 127.0.0.1 - this is okay. I'm led to believe (by the 'man' entry for resolv.conf) that this isn't a particularly important file, but I changed mine to read:

domain mybox.com
search mybox.com
nameserver 127.0.0.1
nameserver 111.111.111.111
nameserver 222.222.222.222

Where 'mybox.com' is the main domain of my server, and '111.111.111.111' and '222.222.222.222' are the IP addresses of my primary and secondary nameservers.

resolv.conf is used to lookup names that are not in FQDN format.

/etc/nameserverips
Check that there are entries for each IP acting as a nameserver.
EG:
IPHERE=ns1.yournameserver.com
IPHERE=ns2.yournameserver.com



source : http://www.webhostgear.com/11.html
Copyright © 2015 Flash Info On Blog