Had a vulnerable version of BIND been running the criticality would have been

Had a vulnerable version of bind been running the

This preview shows page 19 - 22 out of 107 pages.

Had a vulnerable version of BIND been running, the criticality would have been much higher. Criticality = 3. Lethality – This attack did not do any damage to the network, but could have resulted in a root compromise if a vulnerable version of BIND was running on the firewall. Lethality = 5. System Countermeasures – System countermeasures existed on the firewall. The version of DNS was obfuscated in the /etc/named.conf file, and a version of BIND, 8.2.3-REL, was being used that is not vulnerable to the Infoleak and TSIG exploits. The firewall was also fully patched. The firewall did respond to the attackers inverse query and TSIG record packets, but it was nothing that could be considered "crown jewel" quality. However, the firewall did respond to the attacker inverse query. System Countermeasures = 3. 19
Image of page 19
Network Countermeasures – The firewall was running the ISC ( ) recommended version of BIND at the time of the attack. A more secure architecture would have been a separate DNS server that is hardened and has BIND running in a chroot'd environment. Network Countermeasures = 3. (Criticality + Lethality) – (System Countermeasures + Network Countermeasures) = Severity (3 + 5) – (3 + 3) = 2 Defensive Recommendation: A better method of defense than obfuscating the DNS version number would be to add the following substatement to the “options” block of the named.conf file for BIND 8.2.3 (or 8.2.4) to restrict all queries to only authorized servers: allow-query {external.dns.server.ip.1; external.dns.server.ip.2; internal.network.1.address/subnetmask; internal.network.2.address/subnetmask; internal.network.x.address/subnetmask; }; Next, update BIND to version 8.2.4, per the recommendation of . The newest version of BIND is always available here: . Finally, run BIND in a chroot'd environment on a dedicated DNS server that has been hardened using YASSP ( ) for a Solaris box, or Bastille-Linux ( ) for a Linux box. Multiple Choice Test Question: The maximum allowable size of a UDP DNS response payload, not including the IP or UDP header, is: a) 532 bytes b) 1460 bytes c) 512 bytes d) 20 bytes Answer - The correct answer is (c). DNS query responses are limited to 512 bytes of packet payload. If the payload exceeds 512 bytes, the data should be truncated and the TC flag should be set to "1" in the TC field of the fixed length DNS header flags field. 20
Image of page 20
Detect #3 - School Bus Trojan Scan Gauntlet Firewall Logs: May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 216.61.164.172: 54321 to a.b.c.6 on unserved port 54321 May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 216.61.164.172: 54321 to a.b.c.13 on unserved port 54321 May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 216.61.164.172: 54321 to a.b.c.14 on unserved port 54321 May 28 01:35:04 firewall.mycompany.com unix: securityalert: tcp if=hme0 from 216.61.164.172: 54321 to a.b.c.34 on unserved port 54321 May 28 01:35:04 firewall.mycompany.com unix: securityalert: no match found in local screen: TCP if=hme0 srcaddr=216.61.164.172 srcport=
Image of page 21
Image of page 22

You've reached the end of your free preview.

Want to read all 107 pages?

  • Spring '16

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture