All things DevOps

Tag: authorative zones

If you run a DNS server on the Internet with a default configuration many people/robots will take advantage of you. The same is true for Mail, but that is another article. Needless to say if you are running a service on the Internet, the naughty goblins will find you. To thwart these dirty criminals all that’s necessary is to configure your named.conf properly. However, since these robotos are being naughty there is a high degree of certainty they are infected endpoints, and as such I really don’t want them coming anywhere near me or my machines. After all for humanity sake we don’t want to be infected by the deadly plague ! This article is short and sweet, here is how to protect your DNS server & your server in one article using named.conf & ufw (iptables).

Named.conf.options

Now a days named.conf is really just a file that inherits 3 other files, named.conf.local, named.conf.options, and named.conf.default-zones. The one we are going to fix is named.conf.options. The configuration below should only be applied in a scenario where you want to run an authorative nameserver, and a caching name server, but the key is you only want to allow people to query the cache that ‘you know personally or are you’ vs. allowing the entire internet, because then bad things happen. If this is not the setup you are going for, don’t do this 🙂 But if it is follow along.

Add the following section with the proper IP’s to the top fo the file

1

2

3

4

5

acl"trusted"{

192.241.206.98;

localhost;

localnets;

};

Note you can also add a CIDR for a subnet like 192.168.0.0/16

After that’s done under the options {} section… make it look like this

1

2

3

4

allow-query{any;};

allow-recursion{trusted;};

allow-query-cache{trusted;};

allow-transfer{202.157.182.142;};

Note, allow transfer is necessary if you have a secondary nameserver that needs to receive updates. Now restart bind9

1

tuxninja@tlprod1:/etc/bind$sudo service bind9 restart

Ok now all querying including behavior from non-trusted people will not be allowed. If it is working check your /var/log/syslog and you will see some denies like this

Now the above is from my actual log file. I was quite annoyed that clients are basically abusing the hell out of hehehey.ru… so I decided I don’t want to talk to those people at all. To those people I should be a blackhole. To do this I used UFW which is short for uncomplicated firewall, which essentially makes dealing with Iptables much much nicer. It’s only my 2nd time using UFW, but I’ve been using Iptables for well over a decade. Anyway, here is my simple setup with UFW that I came up with.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

tuxninja@tlprod1:/etc/bind$sudo ufw defaultdeny incoming

Defaultincoming policy changed to'deny'

(be sure toupdate your rules accordingly)

tuxninja@tlprod1:/etc/bind$sudo ufw defaultallow outgoing

Defaultoutgoing policy changed to'allow'

(be sure toupdate your rules accordingly)

tuxninja@tlprod1:/etc/bind$sudo ufw allow ssh

Rules updated

Rules updated(v6)

tuxninja@tlprod1:/etc/bind$sudo ufw allow80

Rules updated

Rules updated(v6)

So we are configuring the default policy to deny all incoming traffic, allow outgoing, and then allow SSH & Apache/Web traffic basically. Next I created a script called block.sh to add ufw deny rules for bad actors I parsed out of my log, here’s what block.sh looks like

1

2

3

4

5

6

# cat block.sh

#!/bin/bash

whileread line;do

ufw deny from$line

done

Don’t forget to chmod +x your shell script. Then I did this… blocking all bad actors…

Note, use sudo if you don’t run this as root. This will go through my log and find all these bad requests, and block the requestor. It’s quite aggresive, so be careful, make sure you thoroughly limit your parsing with grep to only block things you really don’t want talking to your server, because this blocks ALL traffic from this requestor to your service, not just DNS.

Once that is complete you need to finally permit good DNS requests by running

1

ufw allow53

And then finally enable your firewall

1

ufw enable

If you are successful you should see entries in your log that look like this