NTP troubleshooting can involve checking configuration settings in ntp.conf, basic network connectivity and firewalls. Sometimes the problem is immediately apparent, but not always. While attempting to set up one XenServer 5 system as the NTP server for others (rather than having all of them contacting NTP servers on the Internet, and writing broader firewall rules to support that), I bumped into the following problem.

  1. The client system can ping the NTP server.
  2. No network switch is imposing an ACL, nor is there a firewall between the two systems.
  3. A diagnostic check with ntpq -p reveals the following:

ntpq: read: No route to host



Host-based firewalls are an important component in the security practitioners tool chain. Layering security mechanisms for a defense-in-depth stance provides redundancy to protect valuable assets. As I was reminded the other day, threat vectors connect threats to vulnerabilities, but ultimately exploiting a vulnerability is about access to, or destruction of an asset. Patching for known vulnerabilities is part of the constant vigilance required, but unknown vulnerabilities still remain. When one up-stream security mechanism fails, or is bypassed by some means, another should still remain behind it so that reaching the asset is more difficult than defeating a single security mechanism.

Of course, no network-based security measure protects assets behind application software — but this is another topic, for another day.  Firewalls limit the attack surface to specific services and applications and may also help prevent some kinds of abuses.

The Linux host-based firewall, iptables, has a wealth of modules for various purposes. One particularly useful one is the limits module. Let’s explore how this can be used to protect against some basic attacks. (more…)