A Tip A Day [:: ATAD ::]

DNS exploits broadly fall in the category of cache poisoning (DNS spoofing where incorrect information is introduced in the DNS cache), client flooding (attacker floods false responses pretending to be a nameserver), dynamic update vulnerability (exploits weak authentication during zone updates between distributed nameservers), information leakage (attacker can extract internal information during zone transfers), and compromise of the DNS server’s authoritative database (attacker obtains administrative previlidges).

The most recent of the DNS expliots whose code can be found here, implements an intelligent cache poisoning algorithm.

The following topics could be of interest while considering DNS security

1. Carefully written named.conf
   - have DNS keys in a separate file and use the include statement to reference it.
   - backup your named.conf
   - use view and the match-clients statements to restrict information to limited clients.
2. Better designed zone updates
   - Use of TSIG (Transaction SIGnatures) or TKEY which allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers.
   - Use of Access Control Lists (ACLs) provided by BIND which allow simple IP address protection.
3. Cryptographically Signed Zones
   - Use of DNSSEC which allows for zones to be cryptographically signed with a zone key.This way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver’s public key. This indeed would add considerable overhead but would prevent cache poisoning exploits.

If there is way to secure a system, some smart guy will invariably come up with a way to exploit an undiscovered vulnerability. These exploits, if not prevented, can atleast be curtailed by good system administration practices, regular system monitoring and updates.

Furthur Reading: DNS Security Extensions, DNS and BIND

__tipped__

The Domain Name System that dates back from the era of the ARPAnet can be understood as a distributed database (like a “phone book”) for any network that translates hostnames to IP addresses, and also vice versa translation called reverse lookup.

The DNS namespace/data stored in a nameserver is divided into manageable sets of data called zones. Zones contain name and IP address information about one or more parts of a DNS domain. A server that contains all of the information for a zone is the authoritative server for the domain. The namespace information is stored in zone files that may contain directives and resource records. Directives (optional) tell the nameserver to perform tasks or apply special settings to the zone. Resource records (mandatory) define the parameters of the zone and assign identities to individual hosts.

A nameserver can take one or more of the following roles:

master

Stores original and authoritative zone records for a namespace, and answers queries about the namespace from other nameservers.

slave

Answers queries from other nameservers concerning namespaces for which it is considered an authority. However, slave nameservers get their namespace information from master nameservers.

caching-only

Offers name-to-IP resolution services, but is not authoritative for any zones. Answers for all resolutions are cached in memory for a fixed period of time, which is specified by the retrieved zone record as the TTL value.

forwarding

Forwards requests to a specific list of nameservers for name resolution. If none of the specified nameservers can perform the resolution, the resolution fails.

Furthur Reading: BIND,  named.conf, rndc

__tipped__

Managing access to networking services on the system would be an important step in managing the system’s security. If you do not need to provide a network service, its best to turn it off. These services are usually managed by xinetd which offers a more secure extension to inetd

xinetd the eXtended InterNET Daemon is an open source daemon that is started on system bootup, and listens on ports designated in /etc/xinetd.conf for incoming network connections. When a new connection is made, xinetd starts up the corresponding network service.

Both the services managed by xinetd and the services in the /etc/rc.d/ directories (also known as SysV services) can be configured to start or stop using the following tools.

On Fedora

1. chkconfig

This is a command line utility that allows you to turn services on and off for the different runlevels. Non-xinetd services can not be started, stopped, or restarted using this utility (use service program instead).

2. Services Configuration Tool

This is a graphical application that displays a description of each service, displays whether each service is started at boot time (for runlevels 3, 4, and 5), and allows services to be started, stopped, and restarted.

3. ntsysv

This is a text-based application that allows you to configure which services are started at boot time for each runlevel. Non-xinetd services can not be started, stopped, or restarted using this program (use service program instead). ntsysv can also be used to configure runlevels.

On Debian

4. update-rc.d

update-rc.d automatically updates the System V style init script links under /etc/rcrunlevel.d/

5. rcconf

Text based GUI Runlevel configuration tool to add or remove services
Note: It would be prudent to modify firewall settings and policies while enabling/disabling services.

Furthur Reading: hosts_access, runlevels

Sources: [RedHat deployment guide, Wikipedia]

__tipped__

If my previous post gave you an opinion that configuring networking on Linux is a head spinning task, im sorry; the Network Administraton Tool that is bundled with most of the newer linux distro is there just to make this task easy for you. You should be able to launch the GUI based tool from the ‘System’ drop down menu and in RedHat the system-config-network command can be used.

The following types of interfaces can be configured using the network administraton tool.
- Ethernet
- ISDN
- modem
- xDSL
- token ring
- CIPE
- wireless devices
- device aliases and profiles

Points worth a note:
- ‘Export’ your original networking configuration before editing them, so you can recover from a mistake by importing back the settings. Most of the network administrator tools provide this option.
- ‘Save‘ your settings after editing and ‘Activate‘ the interface after they are created.
- When interface aliases are configured, DHCP will not work with the interface and its aliases

__tipped__

The /etc/sysconfig/network-scripts/ contains configuration scripts for each network interface, and its important not to confuse this with the /etc/sysconfig/networking/ directory that is used by the Network Administration Tool (system-config-network) whose contents should _not_ be edited manually. Each NIC has its corresponding configuration file /etc/sysconfig/network-scripts/ifcfg-eth(x) which allows the administrator to control the functioning of each interface individually.

Two or more network interfaces can be coupled to act as one to increase bandwidth and provide redundancy by creating a bonding interface using the bonding kernel module . Bonding options can be specified in the kernel module’s configuration file /etc/modprobe.conf, but however IMHO it seems better organized to use the bonding device’s own configuration file /etc/sysconfig/network-scripts/ifcfg-bond(n) instead.

A nice thing to know while changing the speed or duplex settings is that it requires disabling autonegotiation. This needs to be stated first, as the option entries are order-dependent in the ETHTOOL_OPTS= configuration parameter.

ETHTOOL_OPTS=”autoneg off speed 1000 duplex full”

Furthur reading: ethtool, modprobe.conf

__tipped__