> > Joe, Randy and James are my mentors of 15, 5 and 5 years, > respectively, and all said the same thing, namely "nuke and repave, be > sure to be current on BIND" since it is a purpose-built box (ns1). > Perhaps is it a difference in language and what you mean by mentor and where I would mean old colleague/peer who I have discussed this with. They have stated their opinions and you can follow that - but then you would be diverging from the point of RHEL somewhat with a custom built BIND. Remember that the version number you see on BIND is not always the equivalent of upstream due to backports. You should check the relevant RHEL errata, the package %changelog and CVE to get a better understanding of what exploits are known and what has been patched. > With 20/20 hindsight, it is clear that I shouldn't have posted the > original post asking the list for help and hopefully informing other > potential targets of the risk (read: there were no responses to the > original post, therefore it was posted to the wrong audience). > Err... this isn't the whole story/truth. I just searched your emails on this list. the first reference to bind was the 16th feb with the thread "Blasphemous" with complaints (and no substance) to Redhat not having current Bind - despite the fact 9.7 is in the then released 5.6... you suggested an alt repo "for critical internet functions." No where did you indicate you had a name server hacked/altered/poisoned... although you pointed out your credit card prcessing system was running Redhat linux 7.3 (Valhalla) and was nearing 10 years old.... this from someone complaining about teh 'age'' of BIND in RHEL/CentOS. > There was no time for forensics at the time of the discovery; just > time to get advice and react. Then you have no way of telling what happened. For future reference a better reaction is to isolate the server (whether physical or virtual) and put a new system in place to serve the need for it whilst you analyze what happened to the previous. Without that knowledge you cannot mitigate any issues or discover where the failure was, if any. > What follows is from a few moments ago. > > ===details=== > ===box was last nuked and repaved Jul 28 2008 > ===much unnecessary software removed Jul 28 2008, 57 tasks active per > 'ps auxw | wc -l' This is irrelevant to the point at hand. > ===current nmap (same nmap results as on problem day) > Starting Nmap 5.21 ( http://nmap.org ) at 2011-02-18 18:38 CST > Note: Host seems down. If it is really up, but blocking our ping probes, try -PN > Nmap done: 1 IP address (0 hosts up) scanned in 0.19 seconds > vaden at turtlehill:/opt$ nmap -A -PN ns1.texoma.net > Starting Nmap 5.21 ( http://nmap.org ) at 2011-02-18 18:38 CST > Nmap scan report for ns1.texoma.net (209.151.96.2) > Host is up (0.0012s latency). > Not shown: 998 filtered ports > PORT STATE SERVICE VERSION > 53/tcp open domain > 987/tcp open ssh OpenSSH 3.9p1 (protocol 2.0) > | ssh-hostkey: 1024 36:dc:c8:29:b1:d3:8a:b1:e6:cf:2b:4c:70:ed:c8:9a (DSA) > |_1024 10:f9:a6:d2:32:68:15:3a:9f:04:3a:89:05:1e:b8:52 (RSA) > Service detection performed. Please report any incorrect results at > http://nmap.org/submit/ . > Nmap done: 1 IP address (1 host up) scanned in 26.44 seconds So you have SSH exposed and Domain requests exposed. Not surprising but irrelevant in and of itself. > vaden at turtlehill:/opt$ > ===named.conf security in 2008 > [root at ns1 data]# cat /var/named/chroot/etc/named.conf | more > ### > # > # attribution: By Rob Thomas, noc at cymru.com > # <http://www.cymru.com/Documents/secure-bind-template.html> > # -and- > # > <http://www.knowplace.org/pages/howtos/split_view_with_bind_9_howto.php> > # > # at the behest of > # Dr. Joe Redacted (redacted1.edu) > # Dr. Randall Redacted (redacted2.edu) > === Without adequate details such as whether IP requests were limited to your allotted IP addresses and other config details this doesn't help. > ssh port not on 22 > === This is fundamentally irrelevant. This is a very visible server given it is a primary nameserver for you. A simple nmap as you showed above presents any potential hacker with the correct port for SSH given a targeted attack. > distro's standard iptables save ssh port Perhaps here you made a security mistake and should have configured it differently - for example limiting connection attempts, set up fail2ban, limit inbound SSH from known IPs for management purposes from your corporate network, not had SSH publically visable, etc. Without more detail it is impossible to say what went wrong and how the system could be potentially secured. If you have a specific point of vulnerability you have encountered - whether a known CVE or not - I would urge you to open a bugzilla ticket with reproducible steps. If you got hacked through poor configuration and monitoring then it's your own fault quite frankly and perhaps for something you see as such a key service you should hire a proper admin and pay for a Redhat license so you have an SLA to full back on for bugs. That is what it is there for. Regardless of the above I urge you to stop posting irrelevant nonsense and pushing the signal to noise ratio of the list to such intolerable levels. James