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