Les Mikesell wrote:
Craig White wrote:
We will work also with the Red Hat Security team and see if we can
isolate any issues that might be FIXABLE.
----
doesn't this almost beg for upstream to make denyhosts a base install
and automatically on, just as sshd is automatically on?
I've always wondered why a program like sshd didn't rate-limit
connection attempts from day one. It's not exactly a new concept,
especially for a security-oriented program.
I actually think RedHat has moved backwards in this area. I'm seeing
dictionary attacks on ssh, vsftp, dovecot, samba, virtually every
service which might be available out to the web. Gaining access in any
of these areas is the first step to a compromised system.
ssh and vsftp seem to be the most often attacked... I have had ssh set
to deny all and allow only known IP addresses of known users who need
the service... still not perfect by any means, as somewhere along the
line someone is going to need access while their connection is
dynamic... just hadn't hit that one yet.
I have to wonder about vsftp... Yes it's fast, but I wonder if some of
this speed comes from not doing checks that really need to be done, like
keeping up with multiple failed logins. Seems like wu and pro both had
settings for this within their config files? But, even if we take the
UNIX ideal for doing things, the modular approach... I am very surprised
that RHEL doesn't appear to have any system within the provided packages
which can be set to deal with the various servers in some straight
forward manner. Yes, there are programs out there. I'm running one of
them. But why are we left with this one shortcoming by upstream?
Sorry, this just seems to be really odd to me. Dealing with each
external system, is dealing with yet one more system to follow. Each
time, there may be a new issue introduced with regards to a conflict on
a server... the whole reason for following upstream as much as possible.
Each one also introduces the need to follow another mailing list. It's
just not very efficient nor as safe, when compared to yum or up2date
updates.
As for changes to passwords. Sure, changing the root password is a great
idea. But then, what about all the users? It's absurd to consider making
all the users on a hosting server change their passwords once a month,
once a year or even once every ten years. They can barely keep up with
the one they have and many don't. Most don't know how to configure their
email client. Entry into a system from any service opens up a lot of
potentials. I really don't get why there is not a system in place to
deal with this just as we have selinux, suexec, etc.
John Hinton
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
