On Sun, Jan 1, 2012 at 6:04 PM, Ljubomir Ljubojevic <office@xxxxxxxx> wrote:
> On 01/02/2012 02:50 AM, Bennett Haselton wrote:
> > I'm not sure what you mean by "an exploit from a web board which is
> > apparently designed to pull outside traffic". Like Ljubomir said, it
> looks
> > like a script that is used from machine X to DOS attack machine Y, if
> > machine Y has the VBulletin bulletin board software installed on it. Is
> > that what you meant?:)
> >
> > But anyway, since the file was located at /home/file.pl (and since
> attacker
> > had console access), presumably it wasn't being invoked by the web
> server,
> > only from the command line. So how would it have made any difference if
> > httpd was running in its own context, if that script was not being
> invoked
> > by httpd?
>
> Nobody of us really knows how they got in. All you will get from this
> mailing list will be speculations, apart from useful instructions how to
> gather as much info as possible.
Speculation is fine, I'm interested in any method that the attacker *could*
have used to get in to the server if it's *logically possible* that the
attack could have had a non-trivial chance of working. (If they could have
gotten in by method A, and they could have gotten in by method B, then
regardless of which they DID use, I should still try to fix both A and B.)
But that still excludes things like "they got in because you used a
password instead of an ssh key", as I have said many times why a
12-character random alphanumeric password (with 10^24 possible values) is
secure enough even with the most pessimistic assumptions about botnets and
GPUs.
> So there are many possible ways they
> got in including brute force.
Knowing that it was a 12-character random alphanumeric password, do you
still think it could have been done by brute force?
>
As I understood you, you do not use
> neither fail2ban, denyhosts or/and logwatch, and you haven't checked
> those two servers very much in recent months.
>
> What Rilindo is saying is that SELinux might detect exploits while their
> trying to break processes from their routine (allowed by SELinux), and
> all of this (if it happened via exploits) might have been prevented by
> SELinux. You really do have lot of gaps in your security.
A couple of people have pointed out "gaps" in what I was doing for
*detection and analysis* after the fact (don't wipe a machine after it's
hacked, have logs going back further than 4 weeks, have the logs backed up
off-site, etc.), and that's useful. But as far as I can tell nobody has
really pointed out any "gap" in what I'm doing on the *prevention* side.
To focus on one exact question: What is a *preventive* measure that you
think I am not doing, that you think would reduce the chance of a break-in,
in some specific scenario?
Take fail2ban and denyhosts, which block connections from IPs that make too
many invalid ssh logins. In the scenario where the attacker is trying to
brute-force the login, then if your ssh login password is already
un-bruteforceable, then blocking connections from IPs that are making too
many invalid attempts, will not reduce the chance of an attacker
brute-force (which is already essentially zero).
Do you think I'm incorrect that fail2ban and/or denyhosts (and switching
from passwords to ssh keys) do not reduce the chance of a breakin, if your
ssh password is a truly random mixed-case-alphanumeric 12-character
string? If you think this is incorrect, why?
> If I were you,
> I would use all advice's given to you here and secure the rest of your
> servers (SELinux, fail2ban/denyhosts, logwatch, rsyslog, etc..)
>
I tried SELinux but it broke so much needed functionality on the server
that it was not an option. There are many, many issues where all the forum
discussions about how to solve the problem, just end with "Just turn off
selinux", and nobody apparently has any other idea how to solve it. But in
any case, what exactly does it do for httpd security, that isn't already
accomplished by having httpd run as the unprivileged "apache" user? You
said SELinux could prevent an exploit from "breaking a process from its
routine". But even without SELinux, an attacker who found an exploit that
could take control of httpd and make it try any action he wanted, still
wouldn't be able to actually do anything while running as "apache", would
they?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
