On Friday, February 18, 2011 04:15:28 pm Always Learning wrote: > > From: Larry Vaden <vaden at texoma.net> > > Our site running Centos 4.8 and 5.5 name servers was hacked with > > the result that www.yahoo.com is now within our /19 and causing > > some grief. > > Don't understand what you mean by 'within our /19'. I think I do; he's an ISP, and apparently someone inside his address block (the CIDR notation /19; his actual block is publicly found by doing a quick nslookup of his domain name, noting the IP address of the DNS server(s) listed, and then a whois of the IP address of the DNS server(s). His /19 shows up) has hacked in some way the zone file(s) or the cache for his nameserver so that his customers, who would ordinarily use his DNS server as their recursive resolver, now see www.yahoo.com (among who knows what others) as pointing to a different address, the one inside his /19 (which I hope he has tracked and duly removed in grand Texas style), for the purpose of phishing. Now whether this was done by actually hacking into his DNS server or by a cache poisoning attack or what, I don't know since those details Larry hasn't made public. And that's ok. A fully up-to-date C4 or C5 should be covered when it comes to those sorts of things, but to prevent such things I would recommend to Larry that he use the great iptables tools that CentOS provides, or use some other iptables configurator, or simple hosts.allow and hosts.deny, to restrict the addresses that can actually ssh into his server, and only allow port 53 UDP and TCP traffic into and out of his DNS servers to his cutsomers. If he has routers/switches with access lists I would apply those as a second layer of traffic filtering, going both ingress and egress relative to his DNS server. A DNS/BIND vulnerability alone won't kill you, other than the previously mentioned cache poisoning attacks (and those are mitigated with other well-known techniques); it's the TCP connection from the vulnerability shellcode back to the attacker's box that is the killer, and that's what the aggressive iptables/acls will do for you. Hmmm, the Bastille hardening script might help you, but I don't know that for sure. DNS servers should only serve DNS, and the only other connections in or out should be tightly controlled. Easier said than done, especially with limited staff and funds, I know, but still the best practice. I say that having had a DNS server hit, on May 1, 1998, with a BIND 4 vulnerability. Got a quick education on BIND best practices, even though it is sometimes is tempting to 'do it later....'