Blueteam-Crash-Course

Blue Team Crash Course

View on GitHub

Assumptions

DNS

DNS is the service that turns names (like google.com) into IP addresses. It’s kinda like a phone book, which is used to map people’s names to their phone number. A system will use a variety of resources to “resolve” or convert name into an IP. A more detailed look at DNS info can be read about here in an article from CloudFlare. I recommend you read it.

DNS Host Configuration

Hosts File

The simplest way a system converts names to IPs is through the hosts file. Both Linux and Windows have this, and its a simple and easy way to add name mappings. For Windows, the file is at C:\Windows\System32\Drivers\etc\hosts, while on Linux, it is just /etc/hosts.

The format is simple:

<IP> <NAME>

A system always checks this hosts file first, so it’s a good way to short-circuit the resolution process. This is used to redirect ad sites to block adds, or override your resolution to critical sites, so you can’t get there or go a fake one! RedTeam!

Setting a Nameserver

After the hosts file, the system will attempt to to turn a name into an IP, also known as resolving the name, through a configured nameserver. Essentially, the system is asking that DNS server to do the mapping of name to IP. (We’ll make our own DNS server we can point our systems to later) This can be configured in a few different ways.

/etc/resolv.conf

The main file that contains what options the system will use for DNS resolution is /etc/resolv.conf. The format of the file is as follows:

domain <DOMAIN>
nameserver <SOME_IP>

The domain option is not required, and is used to append to names. This would allow you to use only a part of the name instead of the full name (or Full Qualified Domain Name, FQDN for short).

The more important setting is nameserver, which sets the server the system will send DNS requests to resolve the name.

In many modern systems though, /etc/resolv.conf is generated by the network management service, so if you edit it, your changes may not stick around for long. Do it as a last resort. Use the following methods to configure the DNS name.

CentOS 7

In the same file you used to set the static IP on your CentOS 7 system, add the following if you haven’t already. You only require 1 DNS server to resolve, but having a second is a good backup in case the first DNS server fails (for example, if you set the first to be your DNS server and the second to something else, if your DNS server goes down, you might have a backup).

DNS1=<NAMESERVER_IP_1>
DNS2=<NAMESERVER_IP_2>

Ubuntu 16.04

In /etc/network/interfaces, under the interface you set the static IP on, add the following:

dns-nameservers <NAMESERVER_IP_1> <NAMESERVER_IP_2>

Note the space between the addresses.

Ubuntu 18.04

In the /etc/netplan/01-netcfg.yaml file you edited to set the static IP, add the following at the same indentation after the addresses and gateway:

nameservers:
    addresses: [<NAMESERVER_IP_1>, <NAMESERVER_IP_2>]

Note the commas after the first IP.

Building a DNS Server

To practice managing and configuring a service, we’ll dive into making a DNS server. Thankfully, default configurations will give us a basis to work upon and overall the process is pretty straight forward.

You can configure your DNS server in different “modes”:

We’ll be doing a Authoritative and Forwarding server on Ubuntu 16.04.

Install the Service Packages

On a command line (connected through SSH is recommended), run the following command to install the necessary service package for BIND, a popular DNS server, (bind9) and some tools (bind9utils and dnsutils):

sudo apt-get install bind9 bind9utils dnsutils

When prompted, type y and Enter to continue the installation.

Locating the Configuration Files

A majority of service configuration files are stored in /etc/. The config files for BIND on this version of Ubuntu are in the /etc/bind/ directory.

Note that other Linux distributions may have these files at different locations, so research the location if you can’t find where the files are.

The main config file is /etc/bind/named.conf. Note the name of the file is not related to BIND, but a combination of name, for being a domain name server, and d for daemon, which is another name for a service process that runs in the background. Services may do this sometimes.

Editing the Configuration Files

Almost all configuration files for services can only be edited by root, so be sure to be root or use sudo.

Hopefully you know vi…

Let’s open the /etc/bind/named.conf file. Note though that there’s not much here:

sudo vi /etc/bind/named.conf

The contents:

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

The lines with // in front are comments, similar to the C language. The lines with include mean that we are including other config files into the main config file. Many services have ways of including configurations from other files, so you don’t have one massive config file that’s hard to manage and script.

Note that the configuration format that BIND uses is not universal, different services have different formats, so be sure to research how to edit their formats correctly.

Setting up Forwarding

To setup forwarding to forward our DNS requests, we need to edit the /etc/bind/named.conf.options included into the main config file.

sudo vi /etc/bind/named.conf.options

In the file, uncomment the following portion of the file by removing the // in front (With vi, use the arrow keys to navigate and use the delete key to remove them):

        // forwarders {
        //      0.0.0.0;
        // };

It should look like this:

        forwarders {
                0.0.0.0;
        };

However, 0.0.0.0 is invalid to send DNS requests to, so we need to set this to another IP. If you are in a shared lab, set this to a local DNS server (ask your systems administrator). If you are at home, set this to something like 8.8.8.8, which is Google’s public DNS resolver.

Be sure to add that ; at the end! It gets me every time…

For example:

        forwarders {
                172.16.10.10;
        };

Save and exit out of vi, and then restart the service to enable the changes.

Note: Most services won’t reflect the changes until they are restarted!

But, uh, we don’t know the service name… Using the sudo service --status-all command can list out the services and we can see if we can identify it. Your output will probably be different.

jacob@testdns:~$ sudo service --status-all
 [ - ]  bind9
 [ - ]  bootmisc.sh
 [ - ]  checkfs.sh
 [ - ]  checkroot-bootclean.sh
 [ - ]  checkroot.sh
 [ - ]  console-setup
 [ + ]  cron
 [ - ]  hostname.sh
 [ - ]  hwclock.sh
 [ - ]  keyboard-setup
 [ - ]  killprocs
 [ + ]  kmod
 [ - ]  mountall-bootclean.sh
 [ - ]  mountall.sh
 [ - ]  mountdevsubfs.sh
 [ - ]  mountkernfs.sh
 [ - ]  mountnfs-bootclean.sh
 [ - ]  mountnfs.sh
 [ + ]  networking
 [ + ]  ondemand
 [ + ]  procps
 [ + ]  rc.local
 [ + ]  resolvconf
 [ + ]  rsyslog
 [ - ]  sendsigs
 [ + ]  ssh
 [ + ]  udev
 [ - ]  umountfs
 [ - ]  umountnfs.sh
 [ - ]  umountroot
 [ + ]  urandom

There’s a service called bind9 near or at the top, same as the package we installed! We can guess this is the service name we want to use to restart.

sudo service bind9 restart

To check the status of our service, change the restart to status to get the service’s status (Your output will be different):

jacob@testdns:~$ sudo service bind9 status
* bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
   Active: active (running) since Thu 2019-10-24 03:24:46 UTC; 4s ago
     Docs: man:named(8)
 Main PID: 1627 (named)
   CGroup: /system.slice/bind9.service
           └─1627 /usr/sbin/named -f -u bind

Oct 24 03:24:46 testdns named[1627]: command channel listening on 127.0.0.1#953
Oct 24 03:24:46 testdns named[1627]: configuring command channel from '/etc/bind/rndc.key'
Oct 24 03:24:46 testdns named[1627]: command channel listening on ::1#953
Oct 24 03:24:46 testdns named[1627]: managed-keys-zone: loaded serial 0
Oct 24 03:24:46 testdns named[1627]: zone 0.in-addr.arpa/IN: loaded serial 1
Oct 24 03:24:46 testdns named[1627]: zone 127.in-addr.arpa/IN: loaded serial 1
Oct 24 03:24:46 testdns named[1627]: zone 255.in-addr.arpa/IN: loaded serial 1
Oct 24 03:24:46 testdns named[1627]: zone localhost/IN: loaded serial 2
Oct 24 03:24:46 testdns named[1627]: all zones loaded
Oct 24 03:24:46 testdns named[1627]: running

It should say loaded and Active: active (running). If not, the text on the bottom is log output for the service, which is helpful to see what went wrong.

Testing out Forwarding

It’s always good to test your own services to make sure they are running as you expected. They may start, but they may not give the results you want.

To test BIND, we’ll use the dig command, a common tool for testing DNS. It has many more options than we’ll explore to day, so be sure to look it up sometime.

We’ll test to see if can resolve google.com. The @127.0.0.1 forces dig to use a certain DNS server, in this case our local one. Otherwise, dig will use the DNS server address is /etc/resolv.conf.

dig google.com @127.0.0.1

dig returns a status in its output, look at the status field in the result. If things aren’t going well, things may hang as dig or the DNS server waits for a result.

For example, this is when a request times out:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49581
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 24 03:32:50 UTC 2019
;; MSG SIZE  rcvd: 39

A successful result may look similar to this:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50143
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		299	IN	A	172.217.12.142

;; AUTHORITY SECTION:
.			261290	IN	NS	b.root-servers.net.
.			261290	IN	NS	m.root-servers.net.
.			261290	IN	NS	f.root-servers.net.
.			261290	IN	NS	h.root-servers.net.
.			261290	IN	NS	e.root-servers.net.
.			261290	IN	NS	j.root-servers.net.
.			261290	IN	NS	a.root-servers.net.
.			261290	IN	NS	g.root-servers.net.
.			261290	IN	NS	d.root-servers.net.
.			261290	IN	NS	i.root-servers.net.
.			261290	IN	NS	c.root-servers.net.
.			261290	IN	NS	l.root-servers.net.
.			261290	IN	NS	k.root-servers.net.

;; Query time: 50 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 24 03:38:02 UTC 2019
;; MSG SIZE  rcvd: 266

If you get a successful response, you’re all set for this section. If not, use the logs the status to diagnose the problem. More log output is available in /var/log/syslog (only readable as root). Use cat and tail to view portions of the log and watch for output when the service is restarted.

Setting up a Domain

Now let’s set up our own domain. If your at home, you can use something like YOURNAME.local. If your in a shared lab, the system administrator or instructor might have on for you.

First, edit the /etc/bind/named.conf.local file as root:

sudo vi /etc/bind/named.conf.local

Add the following lines to the file: with DNS.NAME being the domain name you selected:

zone "DNS.NAME" {
    type master;
    file "/etc/bind/DNS.NAME.fwd";
    allow-transfer {none;};
};

Once we save and exit, we need to create the zone file and add entries called “records.”

sudo vi /etc/bind/DNS.NAME.fwd

Headers and SOA record

To start, add the following lines as a header and first record (note, keep the . on the end when you edit the domain):

$TTL 86400
@   IN  SOA     DNS.NAME. root.DNS.NAME. (
        0000  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)

These values are required in a zone file, giving administrator contact info, time-to-live (TTL) which indicates how long results from this domain should be stored, and other data. Research dns SOA records for more info. The main field we are interested here is the serial. This is used to indicate the “version” of the zone file, and should be changed with each edit. In a larger setup, this would tell slave DNS servers that there is an update to the zone, and they need to update their own zone information. If you don’t change the serial, other servers won’t know they need to update.

A common pattern is <4-DIGIT-YEAR><2-DIGIT-MONTH><2-DIGIT-DAY><2-DIGIT-INCREMENTAL-VALUE>, such as 2019102401, which is the first serial for Oct 21, 2019.

NS records

The next record we need to have is setting the nameserver, NS records. This tells what server is authoritative for the domain, and would list other nameservers if they existed for this domain. Note the trailing ., it needs to be there! (@ stands for the base domain or domain root, which is DNS.NAME)

@       IN  NS          ns1.DNS.NAME.

ns1 is a common name for the nameserver, we’ll set who will get this name next.

A records

The A records are the ones that map a name to an IP. They are formatted like this:

<NAME>      IN  A   <IP>

First we add one for the nameserver NS record, which is the server we are configuring.:

ns1         IN  A   <YOUR_SYSTEMS_IP>

Then we can add whatever names we want in new records! For example:

coolstuff   IN  A   192.168.1.2

Sets coolstuff.DNS.NAME to map to 192.168.1.2.

When you’ve added the names you wanted, save and exit, then restart the service.

Testing our Domain

Use dig again to test our domain.

dig ns1.DNS.NAME @127.0.0.1

If everything is set up right, you should get a result and congrats, you have a DNS server! All you need to do is point your other systems to your DNS server so they can resolve the domain you’ve configured. Be sure if you have a firewall, you’ve opened the necessary ports, UDP and TCP ports 53.

Conclusion

There’s much, much more on DNS. This was a quick look to get you familiar with the protocol and managing a service. More research will lead to things such as reverse zones, DNS cache poisoning, open DNS resolvers, MX records for mail, DNSSEC, and more. DNS is a critical service for the Internet, so you should learn more about it.

  Navigation  
< Ch 5 Home