On Tue, Feb 3, 2015 at 2:03 PM, Always Learning <centos at u64.u22.net> wrote:> > Nothing wrong with letting "an expert" preconfigure the system and then, > after installation, the SysAdmin checking to ensure all the settings > satisfy the SysAdmin's requirements. >I'd just rather see them applying their expertise to actually making the code resist brute-force password attacks instead of stopping the install until I pick a password that I'll have to write down because they think it will take longer for the brute-force attack to succeed against their weak code. -- Les Mikesell lesmikesell at gmail.com
On Tue, Feb 03, 2015 at 02:10:31PM -0600, Les Mikesell wrote:> I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code.... The installer has MANY MANY defaults that are decided to produce a good starting point. Setting a root password that meets an extremely low bar in terms of security was one of those decisions. Honestly, of all the faults and foibles in the Red Hat/CentOS installer, I'm amazed that someone is complaining about that. "Oh No! They released a product that's *incrementally* more secure than before! Heavens Above! (faints)" If you honestly are so unable to remember a password for longer than 20 minutes, then I suggest using a kickstart to set the root password with a crypted hash. Or have a %post script replace whatever you typed in the password prompt with your insecure password. This is one of those decisions many software products have to make: Weighing the general security gained by requiring somewhat more secure passwords against the inconvenience of having to remember a somewhat more secure password. Since it's possible to get around the requirement in multiple ways, it makes sense to lean toward the more secure option. Make it inconvenient to be less secure. -- Jonathan Billings <billings at negate.org>
On Tue, 2015-02-03 at 14:10 -0600, Les Mikesell wrote:> On Tue, Feb 3, 2015 at 2:03 PM, Always Learning <centos at u64.u22.net> wrote: > > > > Nothing wrong with letting "an expert" preconfigure the system and then, > > after installation, the SysAdmin checking to ensure all the settings > > satisfy the SysAdmin's requirements.> I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code.Very sensible comment. I absolutely agree. Why do the Fedora Bunch think poncing-around with password lengths and composition is more important than extremely strong external security ? There should be a basic defence that when the password is wrong 'n' occasions the IP address is blocked automatically and permanently unless it is specifically allowed in IP Tables. If specifically allowed in IP Tables, there should be a predetermined wait time before another attempt can be made. Simple ! So why does Fedora prefer allowing the hackers unlimited opportunities to brute-force passwords ? -- Regards, Paul. England, EU. Je suis Charlie.
On Tue, Feb 3, 2015 at 2:44 PM, Always Learning <centos at u64.u22.net> wrote:> > There should be a basic defence that when the password is wrong 'n' > occasions the IP address is blocked automatically and permanently unless > it is specifically allowed in IP Tables.The people who are good at this will make the attempts from many different IPs - and sometimes cycle through a dictionary of different login names too. -- Les Mikesell lesmikesell at gmail.com
On Tue, Feb 03, 2015 at 02:10:31PM -0600, Les Mikesell wrote:> I'd just rather see them applying their expertise to actually making > the code resist brute-force password attacks instead of stopping the > install until I pick a password that I'll have to write down because > they think it will take longer for the brute-force attack to succeed > against their weak code.Also, it isn't up to the *installer* to set up a system that resists brute-force password attacks. That's a job for the default configuration files in OpenSSH, GDM, KDM, and any other software product that reads the password database. All the installer can do is read in the plain-text password, check to make sure it passes a minimum policy, then crypt it and put it in the shadow file. There are certainly things that could change, like having the pam configuration have pam_faillock on by default. But I tend to think that having brute-force resistance *AND* slightly better password security should be the goal, not one to the exclusion of the other. -- Jonathan Billings <billings at negate.org>
On Tue, 2015-02-03 at 15:51 -0500, Jonathan Billings wrote:> Also, it isn't up to the *installer* to set up a system that resists > brute-force password attacks.Give us the tools to do the job ! My amalgamated idea is:- (1) When external access gets a password wrong 'n' occasions, as determined by the SysAdmin, the external IP address is automatically permanently blocked unless that IP is included in a IP Tables 'allow' table. (2) If specifically allowed in IP Tables, that IP be blocked for 'm' minutes, as determined by the SysAdmin, before another attempt can be made. (3) All sensitive users be added to a special group. Limit the membership of that group to a collective maximum of 'n' SysAdmin chosen wrong password attempts within a time interval of 't' chosen by the SysAdmin. Baffled why it has never been done but then I'm Always Learning. -- Regards, Paul. England, EU. Je suis Charlie.
On Tue, 03 Feb 2015 20:44:33 +0000, Always Learning wrote: [....]> There should be a basic defence that when the password is wrong 'n' > occasions the IP address is blocked automatically and permanently unless > it is specifically allowed in IP Tables. If specifically allowed in IP > Tables, there should be a predetermined wait time before another attempt > can be made. > > Simple ! So why does Fedora prefer allowing the hackers unlimited > opportunities to brute-force passwords ?Both denyhosts and fail2ban can be installed from yum or dnf; is the same then not true for CentOS?? It worked on my wife's machine. (I'm presently fighting a strike by the box on which I normally run CentOS on my desk in order to be familiar with her OS.) Maybe I have some repo set for it that you don't?? -- Beartooth Staffwright, Not Quite Clueless Power User Remember I know little (precious little!) of where up is.