Unbound DNS: Additional Settings

In the previous article, we introduced Unbound and covered some of the most common settings. In this article, we will cover some additional settings.

Under Services -> Unbound DNS, the “Unbound DNS Settings” tab has a subheading called “Statistics“. Unbound provides various statistics relating to the number of queries that Unbound handles. These statistics are printed to the Unbound log file, which can be found at /var/log/unbound.log. This log file is viewable via Status: Package logs or via the command line using the command “clog“.

There are a few configurable options. The “Enable Statistics” check box allows you to enable the use of statistics. Checking this will cause Unbound to generate statistics which can be used to generate other information. The “Statistics Interval” dropdown box allows you to select the time as to when statistics will be written to the Unbound log file (anywhere from 5 minutes to 2 hours). If “Yes” is selected in the “Enter Cumulative Statistics” dropdown box, the statistics collected will be cumulative and will not be cleared after each report has been logged. The “Extended Statistics” check box will cause Unbound to log the type of queries that have been handled by the resolver. Otherwise, Unbound only logs the total number of queries collected.


Advanced Settings and ACL Lists

The “Unbound DNS Advanced Settings” tab has a number of additional settings that may be useful. The “Hide Identity” check box will cause Unbound (if checked) to refuse id.server and hostname.bin queries. The “Hide Version” checkbox will cause Unbound (if checked) to refuse version.server and version.bind queries. As a result, any attempt to hack Unbound will potentially be thwarted by depriving the hacker of this vital information. The “Log level verbosity” check box allows you to select the logging verbosity. “Level 0” specifies no verbosity (only errors are logged), while each higher level of logging verbosity (up to Level 5) provides additional information. The “Message Cache Size” dropdown box allows you to alter the size of the message cache. The message cache stores DNS rcodes and validation statuses. The RRSet cache will automatically be set to twice this amount (the RRSet cache contains the RR data).

The “Outgoing TCP Buffers” dropdown box allows you to select the number of outgoing TCP buffers to allocate per thread. If the value is set to 0, no TCP queries to authoritative servers are done. The “Incoming TCP Buffers” dropdown box allows you to select the number of incoming TCP buffers to allocate per thread. Once again, if the value is set to 0, then no TCP queries from clients are accepted.

The next tab is “Unbound DNS ACLs“. Here you can define access control lists for Unbound. Click on the “plus” sign on the right side of the page to add a new ACL. The “ACL name” edit box allows you to provide an ACL name. The “Action” dropdown box allows you to choose what to do with DNS requests that match the specified criteria. “Deny” causes Unbound to stop queries from hosts within the specified netblock. “Refuse” will also stop queries from hosts within the specified netblock, but will send a DNS rcode REFUSED error message back to the client. “Allow” will allow queries from hosts within the specified netblock. “Allow Snoop” will allow recursive and nonrecursive access from hosts within the specified netblock.

At “Networks“, you can press the “plus” button and specify a netblock or series of netblocks (along with descriptions) to which the action will be applied. Finally, you can add a description in the “Description” edit box. When you are done setting up the ACL, press the “Save” button to save the changes (or “Cancel” to cancel).

Unbound also provides various command line utilities to manage your DNS cache server. To remove a name from the cache, type:

unbound-control flush [name]

where [name] is a record of any type (including A, AAAA, NS<SOA, CNAME, DNAME, MX, PTR, SRV and NAPTR). If you want to remove a name of a specific type, then type:

unbound-control flush_type [name] [type]

If you want to flush an entire zone, type:

unbound-control flush_zone [name]

This will remove all information at or below the name from the cache. For example, if you specify .com, all entries below .com will be removed.

To determine the name servers that will be queried to lookup a zone, type:

unbound-control lookup [name]


External Links:

Unbound package at doc.pfsense.org

sudo Logging

sudo logging

Enabling sudo logging in CentOS.

As mentioned in the introduction to sudo, the sudo command logs which users run what commands. Logging does not occur automatically. You need to set up sudo and syslogd to log commands. This involves two steps. First, you must create a sudo logfile in /var/log. Second, you must configure syslog.conf to log sudo commands. To configure sudo logging, follow these steps:


  1. Log on as root. Create a sudo log file in /var/log. Enter:
    touch /var/log/sudo
  2. Next, you need to add a line in the syslog.conf file to direct logging to your sudo logging file. Open syslog.conf by entering the following:
    vi /etc/syslog.conf
  3. Enter the following line at the end of the syslog.conf file (press i to insert text). The whitespace must be created using TAB, not the SPACE BAR.
    local2.debug /var/log/sudo
  4. This syslog.conf entry logs all successful and unsuccessful sudo commands to the /var/log/sudo file. You can also log to a network host by indicating the network host instead of a local directory.
  5. Press ESC to write and quit the file, and enter wq at the colon.
  6. Since you have modified the syslog.conf file, you need to restart syslogd. To send a HUP signal to syslogd, you must first know this sylogd process identifier (PID). To find the syslogd PID, type:
    ps aux | grep syslogd
  7. The second column lists the PID number. The last column lists the process using that PID. This is the information you need to enter the appropriate kill command and restart syslogd. Type:
    kill -HUP (PID NUMBER)
  8. First, you will generate log entries for user chris. Log on as user chris.
  9. Enter the following ifconfig commands while logged on as user chris:
    sudo -lsudo /sbin/ifconfig eth0 down
    sudo /sbin/ifconfig etho up
  10. Restart one of the httpd proceesses 9or another process of your choice) using the kill command by entering:
    ps aux | grep httpd
  11. Choose an Apache (httpd) PID from the list that appears. Enter:
    sudo kill -HUP (PID NUMBER)
  12. Now list the root user directory as user chris. Enter:
    sudo ls /root
  13. Log on as root and view the sudo log file. All the sudo commands that chris entered should be listed.
  14. You can log any root commands by simply typing sudo before each command. For example, make sure that you afre logged on as root and enter the following commands:
    sudo useradd bessie
    sudo passwd bessie
    sudo vi /hosts
  15. Access and view the sudo log by entering:
    sudo cat /var/log/sudo
    All root user entries are logged, including the cat command you just entered.

Obviously, sudo is very helpful for controlling an auditing root access. It allows a system administrator to distribute root access without giving out the root password. An administrator can control what root access is needed for each user, and can customize system access based on those needs.


External Links:

Introduction to sudo at linux.com

Network Hardening with Bastille

network hardeningBastille is an open source program that facilitates the network hardening of a system running Linux. It performs many of the tasks discussed in previous articles on this blog such as disabling services and ports. It eases the process of hardening a Linux system, giving you the choice of what to lock down and what not to, depending on your security requirements, and bundles many of the routine tasks done to secure a Linux system into a single package.

Bastille is powerful and can save administrators time from configuring each individual file and program throughout the operating system. Bastille is a set of Perl scripts that run as an interactive program, and instead of configuring files and programs individually, in Bastille the administrator answers a series of “Yes” and “No” questions through an interactive GUI. The program automatically implements the administrator’s preferences based on their answer to the questions, thus streamlining the network hardening process.


Bastille is written specifically for Red Hat Linux and Mandrake Linux, but it can easily be modified to run on most Unixoid systems. The specific Red Hat/Mandrake content has been generalized, and now the formerly hard-coded filenames are represented as variables. These variables are set automatically at runtime. Before you install Bastille on your system, you will want to ensure your Linux version is supported by Bastille. It is known to work with Red Hat, Fedora, SUSE, Debian, Ubuntu, Gentoo, and Mandriva, as well as HP-UX.


Network Hardening with Bastille: Features

More information about each of Bastille’s features is available when the program is run, but here is an overview of the main network hardening features of the program:

  • Apply restrictive permissions on administrator utilities: This allows only the root to read and execute common admin utilities such as ifconfig, linux-conf, ping, traceroute, and runlevel. It also disables the SUID root status for these programs.
  • Disable r-protocols: The r-protocols allow users to log on to remote systems using IP-based authentication. This authentication is based on the IP address, so a hacker could easily create spoofed packets that appear to be from the authorized system.
  • Disable CTRL-ALT-DELETE rebooting: This disallows rebooting the machine by this method.
  • Optimize TCP Wrappers: This choice modifies the inetd.conf and /etc/hosts.allow file so that whenever inetd gets a request, it has to contact TCP Wrappers, which will determine if the requesting IP address is allowed to run the service.
  • Limit system resource usage: If you limit system resource usage, you improve network hardening can reduce the chances of a denial-of-service (DoS) attack. If you limit system resource usage, the following changes will occur:
    • Individual file size is limited to 40 MB.
    • Each individual user is limited to 150 processes.
    • The allowable core files number is configured to zero. Core files are used for system troubleshooting, and can be exploited by hackers if the gain control of them.
  • Restrict console access: Bastille can specify which user accounts are allowed to log on via the console.
  • Additional and remote logging: Enables the admin to add two additional logs to /var/log: /var/log/kernel (for kernel messages) and /var/log/syslog (for error and warning severity messages)
  • Process accounting setup: Allows you to log the commands of all users.
  • Deactivate NFS and Samba: NFS (Network File System) and Samba are services for accessing files from Linux systems on remote systems. Unless the firewall is configured to block the packets or the admin secures these services, Bastille recommends deactivating these services.
  • Harden Apache web server: httpd should be disabled if the service is not required. If Apache is being run, there are also ways of enabling Apache in a manner that ensures maximal network hardening.




Implementing this policy goes a long way towards achieving network hardening. In the next article, we will take a look at the process of implementing Bastille.

External Links:

The official Bastille web site

How to Harden Your Linux Server’s Security with Bastille on www.unixmen.com

Hardening your systems with Bastille Linux at linux.com

Snort Installation in pfSense: Part Two

snort installationIn part one of this series, we began our look at snort installation. In this article, we continue the process.

Next, add a directory to /usr/local/lib:

cd /usr/local/lib
mkdir snort_dynamicrules

Add the following line to file /etc/passwd (or use the “useradd” or “adduser” command):

snort:*:40000:snort

Issue the commands below in order to take ownership of all files in /etc/snort:

cd /etc/snort
chown -R snort:snort *


Locate and modify the following variables in your snort.conf file (in directory /etc/snort) as follows (found between lines 40 and 120 in snort.conf):

This assumes the network you are going to monitor is 192.168.1.0/24:

var RULE_PATH /etc/snort/rules
ipvar HOME_NET 192.168.1.0/24
ipvar EXTERNAL_NET !$HOME_NET
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
var WHITE_LIST_PATH /etc/snort/rules
var BLACK_LIST_PATH /etc/snort/rules

You will also need an initialization script. You can find one for FreeBSD 8.x at the official snort website. Place this script into the /etc/rc.d directory on your pfSense box.

You also want to make a symbolic link (symlink) in /usr/sbin to point to where the actual snort binary was compiled. You could also copy the snort binary to /usr/sbin as well. To make the symlink, issue these commands:

cd /usr/sbin
ln -s /usr/local/bin/snort snort
chmod 700 snort

If the directory “/var/log/snort” does not exist on your system, issue the following commands as “root”:

cd /var/log
mkdir snort
chmod 700 snort
chown -R snort:snort snort

The commands below will also change the ownership of the directories and files to user “snort” and group “snort:

cd /usr/local/lib
chown -R snort:snort snort*
chown -R snort:snort snort_dynamic*
chown -R snort:snort pkgconfig
chown -R 700 snort*
chown -R 700 pkgconfig
cd /etc
chown -r snort:snort snort
chmod -R 700 snort


Testing Your Snort Installation

At this point, you should be ready to do some testing of snort to see if it actually starts up and reads in the rules. You can check /var/log/messages to catch any fatal errors or crashes.

If you want to test snort startup, issue the following commands:

cd /usr/local/bin
./snort -T -i em0 -u snort -g snort -c /etc/snort/snort.conf

The above command will cause snort to start up in self-test mode, checking all the supplied command line switches and rules files that are passed to it and indicating that everything is ready to proceed. If all the tests are passed, you should see the following:

Snort successfully validated the configuration!
Snort exiting

If no errors are returned, you can proceed. To manually start snort, issue the following commands:

cd /usr/local/bin
 ./snort -i em0 -D -u snort -g snort -c /etc/snort/snort.conf

Make sure that snort initializes properly before proceeding below, you can check /var/log/messages for more information in the event of an error in initialization.

To see if snort is actually running on the system, you can check which processes are running, like so:

ps aux | grep -i “snort”

If snort is working, it should return output that indicates snort is a running process, like so:

19633 ?? Ss 0:00:04 /usr/local/bin/snort -D -i em0 -u snort -g snort -c /etc/snort/snort/conf -l /var/log/snort/




External Links:

The official snort website

 

© 2013 David Zientara. All rights reserved. Privacy Policy