>
> 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@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@turtlehill:/opt$
> ===named.conf security in 2008
> [root@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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
