On Sat, January 31, 2015 05:14, Johnny Hughes wrote:
On 01/30/2015 06:09 PM, Scott Robbins wrote:
On Fri, Jan 30, 2015 at 11:27:55PM +0000, Marko Vojinovic wrote:
On Fri, 30 Jan 2015 14:15:05 -0800 Akemi Yagi amyagi@gmail.com wrote:
On Fri, Jan 30, 2015 at 2:04 PM, Scott Robbins scottro@nyc.rr.com wrote:
Centos 7 does that as well.
Heh, I guess I've used good passwords in my installs then.
I have to tap it twice all the time. But don't tell this to anyone! ;-)
OP's point is that probably in RHEL8 you won't be able to do even that anymore.
Exactly. There is some complaining going on on the Fedora testing list, not sure where else one can protest.
Well, protesting here would be meaningless .. as is protesting systemd here. CentOS-8 will have whatever is in the RHEL-8 source code, exactly as it is in that source code minus branding. Just like CentOS-2.1, 3, 4, 5, and 6. Our goal is to rebuild the source code exactly, bugs and all. We want all the behaviors and the experience to be identical in every way.
If you want to effect change before it gets in RHEL, then Fedora is the place. If you want to get it changed in CentOS, then buy RHEL and providing feedback there is the way. We are, by design, exactly as Red Hat pushes the RHEL source code.
Reading between the lines of the Fedora list discussion leads me to the conclusions that:
1. The password strength decision is driven by RH corporate.
2. There is not going to be any back-off by the developers.
3. This is going to be in RH-8.
4. There is absolutely no rational argument that can be made to anyone alter any of this.
5. Protesting there is evidently meaningless as well.
The Fedora Server WG has already asked that this be optionally enforced if it cannot be removed. Answer: No.
This change was not discussed, it was announced. There has been zero support for it from the community and a large amount of criticism. All requests for information respecting the rational and evidential support driving he change are met with what can only be described as political doublethink amounting to:
See the unrelated discussion on this thread over here; and when you discover that it has nothing to do whatsoever with your request then see that tangential thread over there; and when you persistently return to your original request because there is no answer in either then be told that you are a conspiracy theory nut-case.
On Fri, Jan 30, 2015 at 2:49 PM, Chris Murphy <lists at colorremedies.com> wrote: On Fri, Jan 30, 2015 at 1:21 PM, Adam Williamson <adamwill at fedoraproject.org> wrote:
On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote:
What's the actual, real world, non-imaginary impetus behind the change?
It's exactly what all the list posts I pointed you to say it is.
Please go find quotes because I just went through them all and I found:
"Better security is always a plus."
"Instead I propose that we increase our minimum password..."
"In principle I don't disagree with it; But IMO it can not be a replacement to stronger defaults."
And that's it. No actual reasons, let alone any data to back it up. And all three of those statements have flaws which I've already addressed.
I don't know how to stop the conspiracy virus which causes people to leap to the conclusion that there's some shadowy secret motive behind every change they don't like, but there *isn't*.
( Odd, is it not, that Mr. Williamson professes that there is no secret motive but cannot actually provide one when asked. )
The most telling line in the entire thread, for me, is this one:
On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote:
When you stop trusting me. I stop trusting you. And that's a huge problem, and thus far the engineering types are looking at this with narrow vision, it's 2 more key presses. They aren't looking at this at all from the perspective of its connotation.
Personally, from the outside looking in, this all smells of a pointy haired boss directive that the devs are trying to cover their collective asses from. Of course, my corporate days are long behind me so perhaps things have changed. Equally it could be simple incompetence by highly strung people that do not like being criticised for an ill-considered hasty decision but who actually have no evidence to support it.
I have to go off now and find a nice bone bed to lie down in; and fossilize.
On Jan 31, 2015, at 8:04 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
- The password strength decision is driven by RH corporate.
So who do you believe is driving RH corporate? Why are they expending the effort to do this?
The answer is clear to me: general security principles. By the time EL8 comes out, we’ll have had ~3 years of warnings under EL7 that weak passwords would not be tolerated, and they’re finally disallowing them. Good!
(More like 6 years, actually, because EL6 gives a red warning bar for weak passwords.)
Let’s flip it around: what’s your justification *for* weak passwords?
We use them here temporarily during setup, but we lock the system down with a secure unique password before deployment. Switching to something more secure really is not that burdensome.
- There is not going to be any back-off by the developers.
Why would there be? The trend in security is clear: keep up or get run over.
The only question is how quickly forward we proceed, not which direction “forward” is.
RHEL has been moving forward pretty darn slowly. The current system in EL7 allows *appallingly* bad passwords. Passwords that can be cracked in reasonable time scales even with SSH’s existing rate-limiting.
- There is absolutely no rational argument that can be made to anyone
alter any of this.
That could be because there is no rational reason.
Got one? Lay it on me. Please include a description of the threat model where a password like byrnej123 should be allowed, which *is* allowed in EL7, as long as root is setting it and says “Yes, I really am sure I want such a dreadfully easy to crack password.”
- Protesting there is evidently meaningless as well.
While I’ve got the floor, I would like to encourage everyone to send mail to god@universe.org to protest tomorrow’s sunrise.
Rationale: Melanoma is bad.
This change was not discussed
Hmm, yes, let’s hold public committee hearings for every technical change. The resulting bureaucratic mire will surely usher in the Year of Linux!
( Odd, is it not, that Mr. Williamson professes that there is no secret motive but cannot actually provide one when asked. )
What secret motive *could* there be?? The current security policy is weak, and this change fixes that. End of story.
On Mon, February 2, 2015 4:17 pm, Warren Young wrote:
On Jan 31, 2015, at 8:04 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
- The password strength decision is driven by RH corporate.
So who do you believe is driving RH corporate? Why are they expending the effort to do this?
The answer is clear to me: general security principles. By the time EL8 comes out, weâll have had ~3 years of warnings under EL7 that weak passwords would not be tolerated, and theyâre finally disallowing them. Good!
(More like 6 years, actually, because EL6 gives a red warning bar for weak passwords.)
Letâs flip it around: whatâs your justification *for* weak passwords?
We use them here temporarily during setup, but we lock the system down with a secure unique password before deployment. Switching to something more secure really is not that burdensome.
- There is not going to be any back-off by the developers.
Why would there be? The trend in security is clear: keep up or get run over.
The only question is how quickly forward we proceed, not which direction âforwardâ is.
RHEL has been moving forward pretty darn slowly. The current system in EL7 allows *appallingly* bad passwords. Passwords that can be cracked in reasonable time scales even with SSHâs existing rate-limiting.
- There is absolutely no rational argument that can be made to anyone
alter any of this.
That could be because there is no rational reason.
Got one? Lay it on me. Please include a description of the threat model where a password like byrnej123 should be allowed, which *is* allowed in EL7, as long as root is setting it and says âYes, I really am sure I want such a dreadfully easy to crack password.â
- Protesting there is evidently meaningless as well.
While Iâve got the floor, I would like to encourage everyone to send mail to god@universe.org to protest tomorrowâs sunrise.
Rationale: Melanoma is bad.
This change was not discussed
Hmm, yes, letâs hold public committee hearings for every technical change. The resulting bureaucratic mire will surely usher in the Year of Linux!
( Odd, is it not, that Mr. Williamson professes that there is no secret motive but cannot actually provide one when asked. )
What secret motive *could* there be?? The current security policy is weak, and this change fixes that. End of story.
It's hard to not endorse everything you are saying. As far as motive is concerned, it is not that secret. Security. RedHat doesn't like poorly administered machined with RHEL linux get hacked, then many voices saying saying in the internet: RHEL Linux is not secure, RHEL Linux machines are getting hacked. Even though the reason is not what it sounds like.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, 2015-02-02 at 16:30 -0600, Valeri Galtsev wrote:
RedHat doesn't like poorly administered machined with RHEL linux get hacked, then many voices saying saying in the internet: RHEL Linux is not secure, RHEL Linux machines are getting hacked. Even though the reason is not what it sounds like.
What is the reason RHEL machines are being hacked ?
On Mon, February 2, 2015 5:34 pm, Always Learning wrote:
On Mon, 2015-02-02 at 16:30 -0600, Valeri Galtsev wrote:
RedHat doesn't like poorly administered machined with RHEL linux get hacked, then many voices saying saying in the internet: RHEL Linux is not secure, RHEL Linux machines are getting hacked. Even though the reason is not what it sounds like.
What is the reason RHEL machines are being hacked ?
I assume, you may have your own list but once you asked I'll mention off the top of my head what I've seen (no, these are not happened on machine I administer - knocking on wood ):
1. machine compromised elsewhere, user password (via keylogger or malicious ssh client) or secret key gets stolen; cyber criminal connects to my server with credentials on my user
2. after he is in: elevation of privileges through some local exploit. As I tend to have nothing to be exploited on multi-user machines (and run them under assumption bad guy is already in), this normally doesn't happen to me, but I help sometimes to sweep up mess and do forensics when that happened to someone
3. Independent on the above: just blunder when you are doing administration. I have seen admin helping a user (who was on the phone) change his password. And he accidentally in
passwd username
stuck enter between the above two words (!). Which ended up in changing root password on machine to very weak one he passed that person over the phone. When that didn't work (good hint that that was not that user's password that was changed!), he just changed it again. Then intruder just walked as root through open door (that weak password was one of the top four in cracker's dictionary).
4. Not updating the system, or having vulnerable services - I have seen these as well
5. Weak root password should be on the list, but practically only the ones on the top of password cracking dictionary are... Anyway, I do (or I like to think that I do) have strong root passwords. Nevertheless, I always have measures to thwart dictionary attacks from the network (as some of my users may have weak passwords, not the ones on the top of dictionary though I bet)
... This list goes on, someone can continue. Most of what I see (like the list above) I would classify as poor system administration. The last has nothing to do with how well RedHat puts together and patches their system. So I can understand them being less than willing to have RHEL hacked due to that. However, to think that you can force one to maintain his system well is utopia. So, even though I understand their reasons, I am sceptical they will find panacea.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
What secret motive *could* there be?? The current security policy is weak, and this change fixes that. End of story.
It's hard to not endorse everything you are saying. As far as motive is concerned, it is not that secret. Security. RedHat doesn't like poorly administered machined with RHEL linux get hacked, then many voices saying saying in the internet: RHEL Linux is not secure, RHEL Linux machines are getting hacked. Even though the reason is not what it sounds like.
While I admire RedHat, and use CentOS on my home servers, I would expect RH to give priority to those paying for their services, who I imagine are almost all sysadmins of systems with many users. My interests as a tiny user may not coincide with theirs.
This does not mean that I think there are evil spirits at RH trying to disrupt my life. But it does mean that the inconvenience of strong passwords may outweigh any additional security in my case.
On Mon, Feb 2, 2015 at 4:17 PM, Warren Young wyml@etr-usa.com wrote:
Let’s flip it around: what’s your justification *for* weak passwords?
You don't need to write them down. Or trust some 3rd party password keeper to keep them. Whereas when 'not weak' is determined by someone else in the middle of trying to complete something, you are very likely to have to write it down.
On Mon, February 2, 2015 5:26 pm, Les Mikesell wrote:
On Mon, Feb 2, 2015 at 4:17 PM, Warren Young wyml@etr-usa.com wrote:
Letâs flip it around: whatâs your justification *for* weak passwords?
You don't need to write them down. Or trust some 3rd party password keeper to keep them. Whereas when 'not weak' is determined by someone else in the middle of trying to complete something, you are very likely to have to write it down.
Whereas I agree with you... Well, I tell my users when they set password after I created account for them: the most important is that you can memorize and type your password. I myself, however use rather strong password (knocking on wood), and was never bugged by "weak password" warning. Being sysadmin, and "paranoia" is in sysadmin's job description, I tend to have all passwords different, neither of my regular user, or root passwords ideally should never repeat anywhere, even on different machines I administer. So I imminently am using encrypted password storage. These days it is keepassx.
Just my $0.02
Valeri
PS I don't like though policies invented by bureaucrats having no technical knowledge serving only to cover their backsides, like in National Laboratories they require one to change password every 6 Months, and password should never be anything you used in the past. This doesn't serve security, and is counter-productive. This policy for me indicates that they declare explicitly that they maintain security of their systems not too well, as a results of which your password likely can get compromised...
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, Feb 2, 2015 at 5:45 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Mon, February 2, 2015 5:26 pm, Les Mikesell wrote:
On Mon, Feb 2, 2015 at 4:17 PM, Warren Young wyml@etr-usa.com wrote:
Let’s flip it around: what’s your justification *for* weak passwords?
You don't need to write them down. Or trust some 3rd party password keeper to keep them. Whereas when 'not weak' is determined by someone else in the middle of trying to complete something, you are very likely to have to write it down.
Whereas I agree with you...
Or, you might similarly ask what is your justification for not getting up at 5 AM, going to the gym and swimming 20 or 30 laps every morning. The answer might just be that you are lazy, but should a software vendor make their code stop working for you because they think you aren't working hard enough?
On Feb 2, 2015, at 5:10 PM, Les Mikesell lesmikesell@gmail.com wrote:
should a software vendor make their code stop working for you because they think you aren't working hard enough?
When the consequence of widespread bad security is botnets and all the ills that derive therefrom — DDoS armies, spam, etc. — then yes, I think we do need to raise the industry’s overall level of security.
At risk of bringing out some *actual* Internet nutters, the question of minimum password security levels is directly analogous to that of vaccination. When a large population stops vaccinating, we start seeing previously-defeated diseases coming back, like the measles outbreaks in California and rural Australia:
http://goo.gl/7caiui http://goo.gl/8lT8Pd
Polio was almost completely eradicated, but it’s starting to come back in the middle east after the CIA used a fake vaccination campaign as a pretext to try to get into bin Laden’s Pakistan compound:
http://goo.gl/KbbMUC http://goo.gl/C2B5EE
I believe personal freedom should count quite highly in policy discussions. But, when your failure to protect yourself endangers me, it stops being a question of personal freedom.
Practice safe hex!
On Mon, 2015-02-02 at 17:49 -0700, Warren Young wrote:
Polio was almost completely eradicated, but it’s starting to come back in the middle east after the CIA used a fake vaccination campaign as a pretext to try to get into bin Laden’s Pakistan compound:
The Taliban were created and funded by the USA, using the Pakistani intelligence service, to give the Russian invaders of Afghanistan a bad time. Bin Laden was a frequent guest of honour at USA military bases in the US of A.
Inoculation against illnesses is important.
As for security, the cess pit is weak security not on Linux, BSDs and others etc. but on M$. It seems to be incredibly easy for one malicious person to launch attacks from machines they control all over the world - and those machines just happen to be running M$. Breaking into M$ machines seems to be t-o-o easy so I suspect it is not password weaknesses that are being exploited !
Encourage good security but don't force it down our throats !
On 3 February 2015 at 12:09, Always Learning centos@u64.u22.net wrote:
As for security, the cess pit is weak security not on Linux, BSDs and others etc. but on M$. It seems to be incredibly easy for one malicious person to launch attacks from machines they control all over the world - and those machines just happen to be running M$. Breaking into M$ machines seems to be t-o-o easy so I suspect it is not password weaknesses that are being exploited !
This is not correct and a dangerous assumption to make about real and current threats.
Your security practice, as you have described it, is poor. If you have been compromised, you may not be aware of it. A compromise of your systems weakens the whole community.
Kal
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On Tue, 2015-02-03 at 12:20 +1100, Kahlil Hodgson wrote:
On 3 February 2015 at 12:09, Always Learning centos@u64.u22.net wrote:
As for security, the cess pit is weak security not on Linux, BSDs and others etc. but on M$. It seems to be incredibly easy for one malicious person to launch attacks from machines they control all over the world - and those machines just happen to be running M$. Breaking into M$ machines seems to be t-o-o easy so I suspect it is not password weaknesses that are being exploited !
This is not correct and a dangerous assumption to make about real and current threats.
What is incorrect ? The fact that one person can control many computer systems - home and business - all around the world ?
That the same person can launch exactly the same attacks on my mail servers and the same attacks on my web servers from different machines all around the world ?
That the machines being used for the attacks just happened to be running M$ ?
That every day I witness the attacks on my systems ?
Your security practice, as you have described it, is poor.
Rubbish.
If you have been compromised, you may not be aware of it.
I really do think I would because of the systems I run. Please do not judge my standards by standards you may be familiar with.
A compromise of your systems weakens the whole community.
I'm am sure that is not true.
On 2/2/2015 6:17 PM, Always Learning wrote:
I really do think I would because of the systems I run. Please do not judge my standards by standards you may be familiar with.
I suspect list subscribers are inclined to view your standards (or lack thereof) in the light of your rubbish superiority-complex attitude.
On Mon, 2015-02-02 at 18:24 -0800, John R Pierce wrote:
I suspect list subscribers are inclined to view your standards (or lack thereof) in the light of your rubbish superiority-complex attitude.
What matters to me is my systems are secure. I have too much to loose if any part if compromised. That is why security remains top priority.
On 2/2/2015 5:09 PM, Always Learning wrote:
As for security, the cess pit is weak security not on Linux, BSDs and others etc. but on M$. It seems to be incredibly easy for one malicious person to launch attacks from machines they control all over the world - and those machines just happen to be running M$. Breaking into M$ machines seems to be t-o-o easy so I suspect it is not password weaknesses that are being exploited !
the majority of 'botnet' systems that probe at my servers appear to be poorly configured linux servers at colocs.
On Mon, 2015-02-02 at 17:20 -0800, John R Pierce wrote:
the majority of 'botnet' systems that probe at my servers appear to be poorly configured linux servers at colocs.
They appear to be an increasing source. Those and Vietnam are currently popular. So I block the data centres/coloc IP ranges.
Blocking of individual IPs is automatic and is for all ports. It usually lasts for about 4 to 6 weeks. Manual blocking is usually of IP ranges and usually permanent but restricted to ports 25 or 80.
I want is a quiet life :-)
OK, folks. You're doing a great job of describing the current milieu with a rough description of some best practices.
Now how about some specific sources you personally used to learn your craft that we can use likewise?
PatrickD
On Mon, 2015-02-02 at 18:34 -0800, PatrickD Garvey wrote:
OK, folks. You're doing a great job of describing the current milieu with a rough description of some best practices.
Now how about some specific sources you personally used to learn your craft that we can use likewise?
Taught myself (as usual). Used Google to find helpful advice from countless other people. Taught myself PHP to do the coding. Use BASH to perform repeated routines.
Will publish my Exim configuration and associated routines (including the anti-spammer checks etc.) on one of my web sites. And my EXIM changes to Logwatch.
Will add my Apache error routines, support files and reporting routines too.
How much do you currently know ?
On Mon, Feb 2, 2015 at 6:46 PM, Always Learning centos@u64.u22.net wrote:
On Mon, 2015-02-02 at 18:34 -0800, PatrickD Garvey wrote:
OK, folks. You're doing a great job of describing the current milieu with a rough description of some best practices.
Now how about some specific sources you personally used to learn your craft that we can use likewise?
Taught myself (as usual). Used Google to find helpful advice from countless other people. Taught myself PHP to do the coding. Use BASH to perform repeated routines.
OK, what were the key words you used as search terms?
Will publish my Exim configuration and associated routines (including the anti-spammer checks etc.) on one of my web sites. And my EXIM changes to Logwatch.
Will add my Apache error routines, support files and reporting routines too.
I'm sure that would be helpful, especially if others do likewise so we may compare and contrast what was done.
How much do you currently know ?
Enough to know I have a lot to learn.
PatrickD
On Mon, 2015-02-02 at 18:58 -0800, PatrickD Garvey wrote:
OK, what were the key words you used as search terms?
That always depends on what I am trying to do. I start with a problem/project then I research the subject. Its a bit like learning the law.
I'm sure that would be helpful, especially if others do likewise so we may compare and contrast what was done.
My reservation is could a spammer/hacker then use that information to circumvent those anti-spamming/anti-hacking routines ?
How much do you currently know ?
Enough to know I have a lot to learn.
I have lots to learn too. Linux is vast. My time is finite.
Your answer is a bit like the Irish man who said "If I was going to xxxxxx I would not be starting from here."
Goodnight.
On Mon, February 2, 2015 8:34 pm, PatrickD Garvey wrote:
OK, folks. You're doing a great job of describing the current milieu with a rough description of some best practices.
Now how about some specific sources you personally used to learn your craft that we can use likewise?
I've learned system administration way back (of course, I do flatter myself by thinking what I'm saying ;-) and still I keep learning new things all the time when I'm doing my job. Unix system administration book was a big thing (big step after computer science degree I got some time before); TrinityOS: a guide to configuring your Linux server for performance, security and manageability by David A. Ranch was a big step I can remember from way back. And after you got the basis, keep challenging yourself by doing new things. Of course, there are a bunch of other more specialized books... Not that I consider I mastered this craft, but I hopefully maintain my boxes so that they are secure...
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 3 February 2015 at 13:34, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
Now how about some specific sources you personally used to learn your craft that we can use likewise?
So many places it makes my brain hurt just thinking about it. Google and Wikipedia will keep you busy for a long while.
Off the top of my head:
There are some online "Security Handbooks" around (I think RedHat publish one) which lay some of the basic ground work.
SANS (http://www.sans.org/) and OWASP (https://www.owasp.org/) have some good resources. If you are cashed up, you can even do courses with SANS.
Reading about the security infrastructure that you are already using is a good idea, often accessible via mysterious things called "man pages". I learned a lot simply by reading about pam, iptables, and selinux.
Thinking about you systems from a penetration testing perspective can be helpful. For example, "Always Learning" has just told us that he uses single character root passwords on his testing machines, that he is testing 7 days a week and does not turn off his test machines. A pen tester or cracker could use that information to formulate a potentially successful attack strategy.
Google "free penetration testing tools". Only use the tools if you own the network or have written permission. Just reading about the tools can give you some insight into attack strategies that you should be defending against. Please don't try to attack "Always Learning".
Download and unpack a copy of rkhunter. Have a look inside. Its just a bunch of bash scripts. Good insight into some surprisingly simple historical attacks.
Google "linux security hardening". There are a lot of resources out there. The hard part is sifting out the gold from the crap. Sorry can help much there.
There are many other people on this list who have a much better grasp on this stuff than me. Hope they chime in.
Hope this helps,
Kal
On Mon, Feb 2, 2015 at 8:02 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 3 February 2015 at 13:34, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
Now how about some specific sources you personally used to learn your craft that we can use likewise?
So many places it makes my brain hurt just thinking about it. Google and Wikipedia will keep you busy for a long while.
Off the top of my head:
Thank you.
The CentOS wiki pages found by a title page search are: http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy http://wiki.centos.org/HowTos/Security http://wiki.centos.org/Security http://wiki.centos.org/Security/Heartbleed http://wiki.centos.org/Security/POODLE http://wiki.centos.org/Security/Shellshock
with translations for the zh and zh-tw languages.
On Mon, 2015-02-02 at 20:26 -0800, PatrickD Garvey wrote:
The CentOS wiki pages found by a title page search are: http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy http://wiki.centos.org/HowTos/Security http://wiki.centos.org/Security http://wiki.centos.org/Security/Heartbleed http://wiki.centos.org/Security/POODLE http://wiki.centos.org/Security/Shellshock
1. HelpOnConfiguration/SecurityPolicy = 2007-04-01
1(a). Link 'SecurityPolicy' = HTML status code 404 1(b). Link 'MoinMoin' = 2007-04-01
2. HowTos/Security = 2010-02-19 (RHEL 5)
3. Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE
*** NOTHING about Firewalls (IP Tables) ***
Perhaps it is a good time for those with harsh attitudes to abandon the practise of dissuading newcomers from contributing to the Centos Knowledge Pool for the ultimate benefit of everyone especially the newcomers, the shy, those whose English may not be ultra perfect and the curious.
If a newcomer makes a mistake or suggests something which is a good idea but never been done before by the Old Timers, do not destructively criticise their efforts. Constructive criticism is always good but sheer negativity because the newcomer has a different attitude to established methods is detrimental to the Centos ethos. After all computers always have been (certainly for me) an endless Learning process.
Inventions should have have occurred if everyone always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial.
Sympathetic interaction and informed debate is superior to hash words which usually dissuade the newcomers from ever again making suggestions or offering a potentially innovative idea.
Those who post on this list are probably less than 0.001% of the world-wide Centos users. Perhaps a Centos Newcomers List* environment would nurture a wider and better understanding of basic Centos whilst leaving the Data Centre things, the users of non-existent Clouds (actually just another Data Centre) and the technicalities of different RAIDs, motherboards, peripherals, disk speeds etc. to the main Centos List.
* alternative name suggestions: Centos Learning ? Centos Basic ?
The suggested list should have the possibility of linking to web pages to illustrate topics which means, perhaps, being able to forward diagrams etc. for publication on the Centos Learning web site.
Centos Leaning could and should encourage people to submit articles on various aspects of Centos. Thus providing a continuous educational environment beneficial to all. Centos Learning is not a competitor to the main Centos Users List, but - probably for the first time ever - a genuine online learning and exploring asset for those using or thinking of using Centos (could even team-up with Scientific since it is the same Linux).
Fedora has not got such a list, so my idea must be good !
Please excuse any inadvertent errors and misspellings.
On Tue, 2015-02-03 at 17:34 +0000, Always Learning wrote:
Inventions should have have occurred if everyone always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial.
Whoops !
Inventions *WOULD NEVER* have occurred if *PEOPLE* always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial.
On Tue, Feb 3, 2015 at 9:34 AM, Always Learning centos@u64.u22.net wrote:
On Mon, 2015-02-02 at 20:26 -0800, PatrickD Garvey wrote:
The CentOS wiki pages found by a title page search are: http://wiki.centos.org/HelpOnConfiguration/SecurityPolicy http://wiki.centos.org/HowTos/Security http://wiki.centos.org/Security http://wiki.centos.org/Security/Heartbleed http://wiki.centos.org/Security/POODLE http://wiki.centos.org/Security/Shellshock
- HelpOnConfiguration/SecurityPolicy = 2007-04-01
1(a). Link 'SecurityPolicy' = HTML status code 404 1(b). Link 'MoinMoin' = 2007-04-01
HowTos/Security = 2010-02-19 (RHEL 5)
Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE
*** NOTHING about Firewalls (IP Tables) ***
I agree, this is not good.
Come do as I have done.
I followed the instructions at http://wiki.centos.org/Contribute#head-42b3d8e26400a106851a61aebe5c2cca54dd7... After I had edited my home page, I copied three pages into subpages of my home page (Be careful to remove any security restrictions.) and edited them as I saw fit. All three of my pull requests have been accepted. I'm working on further improvements to the Download page, at the moment.
I would love to review the improvements you may make to any page of the wiki.
On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote:
*** NOTHING about Firewalls (IP Tables) ***
I agree, this is not good.
Come do as I have done.
I followed the instructions at http://wiki.centos.org/Contribute#head-42b3d8e26400a106851a61aebe5c2cca54dd7...
3. Contribute to the Wiki
Create a login with a username in the format: FirstnameLastname. For example, if your name is John Doe, the username to be created would be JohnDoe. Other variations, such as johndoe, John Doe, John_Doe, John, johnny123numbers, Mister Doe, JustSomeEditor etc. will not be accepted.
That is a bad beginning. They don't want talent just complete subservience. Since when has a user name been more important that the donation of learning, advice, guidance etc ?
'AlwaysLearning', 'alwayslearning' and 'MrLearning' makes me ineligible to post a Centos wiki page. Far better to post on one of my sites than within the restrictive Centos environment.
Seen 'Centos Pulse' ? http://wiki.centos.org/Newsletter
"The CentOS Pulse Newsletter is an important tool to communicate within the community. It is run by the community to collect interesting bits from the wiki, mailinglist, fora, SIGs and other sources, and put them into the spotlight."
First edition = 2009-06-02 Last edition = 2010-06-09
I would love to review the improvements you may make to any page of the wiki.
Post the URL of your page.
I like the idea of a 'Centos Learning' mailing list, as previously described.
On Tue, 2015-02-03 at 11:59 -0800, John R Pierce wrote:
On 2/3/2015 11:57 AM, Always Learning wrote:
'AlwaysLearning', 'alwayslearning' and 'MrLearning' makes me ...
... an anonymous troll.
That type of reaction dissuades people from contributing to the List.
Why don't you personally endorse the creation of a 'Centos Learning' mailing list to complement the other Centos Lists ?
On Tue, Feb 3, 2015 at 11:57 AM, Always Learning centos@u64.u22.net wrote:
On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote:
I would love to review the improvements you may make to any page of the wiki.
Post the URL of your page.
On Tue, 2015-02-03 at 12:06 -0800, PatrickD Garvey wrote:
On Tue, Feb 3, 2015 at 11:57 AM, Always Learning centos@u64.u22.net wrote:
On Tue, 2015-02-03 at 11:21 -0800, PatrickD Garvey wrote:
I would love to review the improvements you may make to any page of the wiki.
Post the URL of your page.
Impressive "Any time we aren't inclusive, we lose." but first it is necessary to have that sort of philosophy as a fundamental principle of Centos.
How about some support, on this list, for the creation of a Centos Learning mailing list ?
On Tue, 2015-02-03 at 15:02 +1100, Kahlil Hodgson wrote:
Thinking about you systems from a penetration testing perspective can be helpful. For example, "Always Learning" has just told us that he uses single character root passwords on his testing machines, that he is testing 7 days a week and does not turn off his test machines.
Yes single character. Writing and testing usually 7 days weekly. Turn off everything when not in use including test machines.
No connection to the Internet.
On 4 February 2015 at 14:36, Always Learning centos@u64.u22.net wrote:
Thinking about you systems from a penetration testing perspective can be helpful. For example, "Always Learning" has just told us that he uses single character root passwords on his testing machines, that he is testing 7 days a week and does not turn off his test machines.
Yes single character. Writing and testing usually 7 days weekly. Turn off everything when not in use including test machines.
No connection to the Internet.
Sorry. Must have misunderstood your earlier comments.
Sounds like a fairly specialized work-flow. You might want to consider using an updates.img that removes the password strength requirements (see http://fedoraproject.org/wiki/Anaconda/Updates). The anaconda installer is fairly straight forward Python code. I haven't got a copy on me at the moment, but at a guess, all you need to do is track down the relevant lines and comment them out.
Hope this helps.
Kal
On Feb 2, 2015, at 4:26 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Mon, Feb 2, 2015 at 4:17 PM, Warren Young wyml@etr-usa.com wrote:
Let’s flip it around: what’s your justification *for* weak passwords?
You don't need to write them down.
The new rules are:
1. At least 8 characters.
2. Nothing that violates the pwquality rules:
http://linux.die.net/man/8/pam_pwquality
Are you telling me you cannot memorize a series of 8 characters that do not violate those rules?
I’m the first to fight boneheaded “password security” schemes like a required change every N weeks, but this is not that. Spend a bit of time, cook up a really good password, and then use it for the next several years. That amortizes the cost of memorization to near-zero, greatly reducing the drive to write it down in an insecure place.
Or trust some 3rd party password keeper to keep them.
That doesn’t really apply here. Any password you have to type into a GUI is going to have to be something you can memorize. Password managers are for things you access *after* you are logged in.
(Another gripe of mine: this recent trend toward using some “cloud” login as your OS login. Apple, Microsoft, and Google are now all doing this! This perforce requires me to weaken a password with a cloud-sized attack surface (i.e. frackin’ huge) to the point that I can memorize it. Before this change, I was using huge random passwords and 2FA. That doesn’t work any more in a world where the OS now requires my cloud password every time it wants elevated privileges.)
Whereas when 'not weak' is determined by someone else in the middle of trying to complete something, you are very likely to have to write it down.
Presumably you have already worked out a good password, and memorized it.
This change is not going to enforce uniqueness per server.
(Though, if this server will be used via SSH, it might be a good idea to do that anyway. SSH keys — optionally with passphrases — are more secure than even quite a long human-memorizable password. Disable password auth and use keys.)
Warren Young wrote:
The new rules are:
At least 8 characters.
Nothing that violates the pwquality rules:
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
Of the remaing 6 rules one is optional ("repeated characters") and 3 of the remaining 5 concern similarity to previous passwords.
Of the remaining 2, one is to avoid short passwords (unspecified), and the other to avoid one's username.
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
(Looking stupid for the sake of everyone who wants to know, because I'm unselfish--and, having been married more than once, have a thick skin).
Palindrome : A word, phrase or sequence that reads the same backward as forward, e.g. ³madam" or "nurses run²
Valère Binet [C]
On 2/3/15, 9:16 AM, "Scott Robbins" scottro@nyc.rr.com wrote:
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
(Looking stupid for the sake of everyone who wants to know, because I'm unselfish--and, having been married more than once, have a thick skin).
-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 2015-02-03, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
I don't think anybody is missing anything. "Palindrome" in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., "password1drowssap".
--keith
On Tue, Feb 03, 2015 at 07:52:53AM -0800, Keith Keller wrote:
On 2015-02-03, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
I don't think anybody is missing anything. "Palindrome" in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., "password1drowssap".
Ah, that makes sense then, thanks.
On Tue, Feb 3, 2015 at 11:20 AM, Scott Robbins scottro@nyc.rr.com wrote:
I don't think anybody is missing anything. "Palindrome" in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., "password1drowssap".
Ah, that makes sense then, thanks.
I think the intent is: "Don't use a password likely to be included in the list that an attacker would try". Of course if services would rate-limit the failures by default or at least warn you about repeated failures and their source, brute-force attacks would rarely succeed. But fixing the problem doesn't seem to be the point here.
On Tue, February 3, 2015 11:37 am, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 11:20 AM, Scott Robbins scottro@nyc.rr.com wrote:
I don't think anybody is missing anything. "Palindrome" in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., "password1drowssap".
Ah, that makes sense then, thanks.
I think the intent is: "Don't use a password likely to be included in the list that an attacker would try". Of course if services would rate-limit the failures
Which sysadmins do for ages when they configure their machines. And I don't think any system will ever come from system vendor fully prepared to serve anything necessary, and tightened to best requirements (which depend on box designation anyway). So, system vendors can do better, but there always will be need for you to do your sysadmin's part. Sounds almost like job security. As one of my friends says: all systems suck, and thanks to that got our jobs ;-)
Valeri
by default or at least warn you about repeated failures and their source, brute-force attacks would rarely succeed. But fixing the problem doesn't seem to be the point here.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Feb 3, 2015 at 11:48 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I think the intent is: "Don't use a password likely to be included in the list that an attacker would try". Of course if services would rate-limit the failures
Which sysadmins do for ages when they configure their machines. And I don't think any system will ever come from system vendor fully prepared to serve anything necessary, and tightened to best requirements (which depend on box designation anyway).
Really? Are vendors not capable of shipping something with good default settings? It seems like getting a new car and having to install a different engine yourself because the factory couldn't figure out how to do it.
So, system vendors can do better, but there always will be need for you to do your sysadmin's part.
If that were really true, then you also wouldn't be able to follow anyone else's advice about how to do it. That is, if your system really needs to be so different that it couldn't have been shipped with the configuration you need, then a book couldn't tell you that either.
Sounds almost like job security. As one of my friends says: all systems suck, and thanks to that got our jobs ;-)
But wouldn't you rather be doing something new/different instead of just fixing things that should have been done right in the first place?
On Tue, February 3, 2015 12:08 pm, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 11:48 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I think the intent is: "Don't use a password likely to be included in the list that an attacker would try". Of course if services would rate-limit the failures
Which sysadmins do for ages when they configure their machines. And I don't think any system will ever come from system vendor fully prepared to serve anything necessary, and tightened to best requirements (which depend on box designation anyway).
Really? Are vendors not capable of shipping something with good default settings? It seems like getting a new car and having to install a different engine yourself because the factory couldn't figure out how to do it.
So, system vendors can do better, but there always will be need for you to do your sysadmin's part.
If that were really true, then you also wouldn't be able to follow anyone else's advice about how to do it. That is, if your system really needs to be so different that it couldn't have been shipped with the configuration you need, then a book couldn't tell you that either.
Sounds almost like job security. As one of my friends says: all systems suck, and thanks to that got our jobs ;-)
But wouldn't you rather be doing something new/different instead of just fixing things that should have been done right in the first place?
Sounds so I almost have to feel shame for securing my boxes no matter what job vendor did ;-)
Just a simple example: I have at least 3 classes of boxes configured ultimately different and having very different level of security/fortification. Do you seriously suggest that system vendor will ship all three level of security configurations? Do you seriously think that needing quite high level of security for some box I will not go over all settings influencing it myself? Will you not? We are not Windows admins, we rely on what we configure or check ourselves. And we do take security seriously, so, we do go over everything whether the system vendor does or does not claim they have done that part already (and and claim they did it better than I can do it). If you prefer to delegate what you are responsible for (security of your box) totally to someone else (even as good guys as system vendor is), then I don't know what to tell you. Yet, I'm sure, majority Unix sysadmins will still do what I do: go over everything themselves. No matter what someone says.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Sounds so I almost have to feel shame for securing my boxes no matter what job vendor did ;-)
Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn't that a waste?
Just a simple example: I have at least 3 classes of boxes configured ultimately different and having very different level of security/fortification. Do you seriously suggest that system vendor will ship all three level of security configurations?
Yes, 3 seems about right.
Do you seriously think that needing quite high level of security for some box I will not go over all settings influencing it myself? Will you not?
Of course, but only because the vendor does not do it. I think Red Hat's engineers are capable of it if they wanted to.
We are not Windows admins, we rely on what we configure or check ourselves.
Not sure what you mean by that. Windows is much worse since the configurations tend to be hidden and the ways to do things interactively and scripted are wildly different.
Yet, I'm sure, majority Unix sysadmins will still do what I do: go over everything themselves. No matter what someone says.
There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn't mean that things should not be shipped with usable defaults.
On Tue, February 3, 2015 12:39 pm, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Sounds so I almost have to feel shame for securing my boxes no matter what job vendor did ;-)
Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn't that a waste?
Do I have to take that people who are not sysadmins themselves just hate an existence of sysadmins?
Just a simple example: I have at least 3 classes of boxes configured ultimately different and having very different level of security/fortification. Do you seriously suggest that system vendor will ship all three level of security configurations?
Yes, 3 seems about right.
Do you seriously think that needing quite high level of security for some box I will not go over all settings influencing it myself? Will you not?
Of course, but only because the vendor does not do it. I think Red Hat's engineers are capable of it if they wanted to.
Here is the difference between us. I refuse to trust something ultimately important which I can check or tune without checking (and tuning if necessary). It will be my laziness. Note, that that I apply to myself. What you do is up to you (and you bear consequences of your decision, and I bare consequences oi mine).
We are not Windows admins, we rely on what we configure or check ourselves.
Not sure what you mean by that. Windows is much worse since the configurations tend to be hidden and the ways to do things interactively and scripted are wildly different.
Yet, I'm sure, majority Unix sysadmins will still do what I do: go over everything themselves. No matter what someone says.
There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn't mean that things should not be shipped with usable defaults.
No, I'm not the driver of my cars, I mean computers. I am a mechanic of racing car competition team, my cars go into competition, and the life of driver riding it depends on me having taken the whole mechanism apart, and making sure nothing breaks and kills driver and hundreds of spectators.
I really hate these car analogies. They are counter-productive. In your eyes my server is indeed a commodity, which I refuse to agree with pretty much like I refuse to join ipad generation. My ipad would be commodity, but I for one will never trust that ipad and will not originate connection to secure box from it.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn't that a waste?
Do I have to take that people who are not sysadmins themselves just hate an existence of sysadmins?
No, I think there are better things for sysadmins to do than fix settings that should have had better defaults.
There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn't mean that things should not be shipped with usable defaults.
No, I'm not the driver of my cars, I mean computers. I am a mechanic of racing car competition team, my cars go into competition, and the life of driver riding it depends on me having taken the whole mechanism apart, and making sure nothing breaks and kills driver and hundreds of spectators.
So don't you think it would be a good thing if the thing was built so it didn't break in the first place? That is, so nobody gets killed running it as shipped, even it they don't have your magical expertise?
I really hate these car analogies. They are counter-productive. In your eyes my server is indeed a commodity, which I refuse to agree with pretty much like I refuse to join ipad generation. My ipad would be commodity, but I for one will never trust that ipad and will not originate connection to secure box from it.
The point I'm trying to make is that whatever setting you might make on one computer regarding security would probably be suitable for a similar computer doing the same job in some other company. And might as well have been the default or one of a small range of choices. And in particular, rate limiting incorrect password attempts and/or providing notifications about them by default would not be a bad thing. Unless there's some reason you need brute-force attacks to work...
On Tue, 2015-02-03 at 13:15 -0600, Les Mikesell wrote:
No, I think there are better things for sysadmins to do than fix settings that should have had better defaults.
How can any SysAdmin (= System Administrator) administer something he or she is uncertain about ? The job of any system administrator is to poke their nose in and ensure everything is absolutely fine.
No looking or no checking can not provide the necessary reassurance everything is absolutely fine *AND SAFE*.
On Tue, Feb 3, 2015 at 11:15 AM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Perhaps the Simplified Linux Server Special Interest Group http://wiki.centos.org/SpecialInterestGroup/SLS could benefit from contributions from each of you?
On Tue, February 3, 2015 1:37 pm, PatrickD Garvey wrote:
On Tue, Feb 3, 2015 at 11:15 AM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Perhaps the Simplified Linux Server Special Interest Group http://wiki.centos.org/SpecialInterestGroup/SLS could benefit from contributions from each of you?
This sounds flattering, but no, I'm done with that, no noise from me here ;-) so... unless someone wants to pipe that. And improve the statements. And one can put his name under that. As at least what I was saying is so common knowledge IMHO.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, February 3, 2015 1:15 pm, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 1:01 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn't that a waste?
Do I have to take that people who are not sysadmins themselves just hate an existence of sysadmins?
No, I think there are better things for sysadmins to do than fix settings that should have had better defaults.
Disagree. Ensure of security of the box is sysadmin's duty. It is in job description. Job to be done.
There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn't mean that things should not be shipped with usable defaults.
No, I'm not the driver of my cars, I mean computers. I am a mechanic of racing car competition team, my cars go into competition, and the life of driver riding it depends on me having taken the whole mechanism apart, and making sure nothing breaks and kills driver and hundreds of spectators.
So don't you think it would be a good thing if the thing was built so it didn't break in the first place? That is, so nobody gets killed running it as shipped, even it they don't have your magical expertise?
I regret I let myself be dragged into car analogy. Once again, I'm not "driving" my machines.
I really hate these car analogies. They are counter-productive. In your eyes my server is indeed a commodity, which I refuse to agree with pretty much like I refuse to join ipad generation. My ipad would be commodity, but I for one will never trust that ipad and will not originate connection to secure box from it.
The point I'm trying to make is that whatever setting you might make on one computer regarding security would probably be suitable for a similar computer doing the same job in some other company. And might as well have been the default or one of a small range of choices. And in particular, rate limiting incorrect password attempts and/or providing notifications about them by default would not be a bad thing. Unless there's some reason you need brute-force attacks to work...
It is possible that system vendor does what you call better job. I do welcome, e.g., "--hitcount" iptables option used in firewall CentOS comes with. (But some may hate that, and I respect their demand for their boxes). This doesn't mean I will not take a look into configuration at least once, and add what I have "certified" in my kickstart file. This probably is where we do diverge. I do not configure all end every box, I do necessary job with one system class for each of OS releases... --> kickstart, but minor tweaks may still be necessary depending on particular tasks on the box.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, 2015-02-03 at 12:39 -0600, Les Mikesell wrote:
There are probably still people that take their cars apart to check that they were assembled correctly too.
Its about taking personal responsibility for the security of your system(s). Trusting someone else's settings of what THEY think YOUR security should be, is very unwise.
It is not car disassembly - it is checking the oil level, the benzin (petrol), the brake fluid, the window washer liquid, the tyre pressures including the 'spare wheel'. Pilots of aircraft do exactly the same. It is called a preflight check. Doing that on a new Centos installation is sensible and, if one cares about security, desirable.
On Tue, Feb 3, 2015 at 1:30 PM, Always Learning centos@u64.u22.net wrote:
There are probably still people that take their cars apart to check that they were assembled correctly too.
Its about taking personal responsibility for the security of your system(s). Trusting someone else's settings of what THEY think YOUR security should be, is very unwise.
Maybe.... It is at least equally unwise to think that you are the only expert and all the people who are supposed to know what they are doing are wrong. That's why we have measles again... I'd rather see some real experts set up usable defaults instead of every person doing an install having to second-guess it.
On Tue, 2015-02-03 at 13:37 -0600, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 1:30 PM, Always Learning centos@u64.u22.net wrote:
Its about taking personal responsibility for the security of your system(s). Trusting someone else's settings of what THEY think YOUR security should be, is very unwise.
Maybe.... It is at least equally unwise to think that you are the only expert and all the people who are supposed to know what they are doing are wrong. That's why we have measles again... I'd rather see some real experts set up usable defaults instead of every person doing an install having to second-guess it.
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.
On Tue, Feb 03, 2015 at 08:03:35PM +0000, Always Learning 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.
Wouldn't that be like having the OS installer require strict passwords, and then have the sysadmin install a less-secure password on test systems after the system is loaded?
On Tue, 2015-02-03 at 15:05 -0500, Jonathan Billings wrote:
On Tue, Feb 03, 2015 at 08:03:35PM +0000, Always Learning 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.
Wouldn't that be like having the OS installer require strict passwords, and then have the sysadmin install a less-secure password on test systems after the system is loaded?
Flexibility is not excluded.
On Tue, Feb 3, 2015 at 2:03 PM, Always Learning centos@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.
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.
On Tue, 2015-02-03 at 14:10 -0600, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 2:03 PM, Always Learning centos@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 ?
On Tue, Feb 3, 2015 at 2:44 PM, Always Learning centos@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.
On Tue, 2015-02-03 at 14:48 -0600, Les Mikesell wrote:
On Tue, Feb 3, 2015 at 2:44 PM, Always Learning centos@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.
If 'n' is low, perhaps '2', then brute forcing will become more protracted.
An addition to my proposal, is allocate all sensitive users to a special group and limit the membership of that group to a maximum of, for example, 3 wrong password attempts within a SysAdmin chosen time interval.
Simple.
On 02/03/2015 03:44 PM, 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.
As has been mentioned, fail2ban does this.
However, the reason you want a password that is not easily bruteforced has nothing to do with this, and all bruteforce attempts cannot be blocked by this method. Scenario: 1.) There's some sort of security vulnerability that allows an intruder to read an arbitrary file. This type of vulnerability (whether it be in php, glibc, bash, apache httpd, or whatever) is not rare. 2.) Attacker uses said vulnerability to exfiltrate /etc/shadow. 3.) Attacker uses a large graphics card's GPU power, harnessed with CUDA or similar, to run millions of bruteforce attempts per second on the exfiltrated /etc/shadow, on their computer (not yours). 4.) After a few hours, attacker has your password (or at least a password that hashes to the same value as your password), after connecting to your system only once.
Now, there are the slow bruteforcers running out there, but those are not the droids this change is looking for. By being 'encouraged' to have a difficult to bruteforce password from the very first, you have better security even when the attacker exfiltrates /etc/shadow or other password hash table (I say 'when' and not 'if' here). And the bar for what qualifies as a secure password (from the point of view that the attacker has your hashed password in hand and is bruteforcing on their equipment) is continually rising as compute power increases.
On 02/04/2015 02:08 PM, Lamar Owen wrote:
3.) Attacker uses a large graphics card's GPU power, harnessed with CUDA or similar, to run millions of bruteforce attempts per second on the exfiltrated /etc/shadow, on their computer (not yours). 4.) After a few hours, attacker has your password (or at least a password that hashes to the same value as your password), after connecting to your system only once.
Oh, and the program to do this can be found very easily. It's called 'John the Ripper' and has GPU support available: http://openwall.info/wiki/john/GPU https://en.wikipedia.org/wiki/John_the_ripper
Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability of the type that allows arbitrary remote code execution or arbitrary file access. Once the attacker has your /etc/shadow, there is absolutely nothing you can do to keep said attacker from cracking your passwords at full speed. Well, nothing except the password strength itself.
On Wed, 2015-02-04 at 14:16 -0500, Lamar Owen wrote:
Oh, and the program to do this can be found very easily. It's called 'John the Ripper' and has GPU support available: http://openwall.info/wiki/john/GPU https://en.wikipedia.org/wiki/John_the_ripper
Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability of the type that allows arbitrary remote code execution or arbitrary file access. Once the attacker has your /etc/shadow, there is absolutely nothing you can do to keep said attacker from cracking your passwords at full speed. Well, nothing except the password strength itself.
Thanks for the future details. My passwords usually contain letters from 2 or 3 different languages as well with non-letters inserted every 2 or 3 characters.
On Feb 4, 2015, at 12:16 PM, Lamar Owen lowen@pari.edu wrote:
Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.
On Wed, February 4, 2015 3:55 pm, Warren Young wrote:
On Feb 4, 2015, at 12:16 PM, Lamar Owen lowen@pari.edu wrote:
Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They donât need to crack your passwords now. Youâre already boned.
There can be scenario that someone has /etc/shadow due to admin's stupidity, yet doesn't have root access. Like: NFS exported / without root_squash option, then everybody having root on different box can mount and have your /etc/shadow.
But in general, I'm with you. And incident like above is really major incident after which full investigation of all what happened on the box, change of all password (and other thing that too should be considered compromised like keys, certs...) and rebuild of box are mandatory.
In any case, I agree that whoever let password hashes get exposed... is doomed.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 02/04/2015 04:55 PM, Warren Young wrote:
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.
Not exactly.
There have been remotely exploitable vulnerabilities where an arbitrary file could be read (not written), but otherwise root access wasn't given by the exploit; that is, no shellcode per se. If you can somehow (buffer overflow shellcode or something similar) get, say, httpd to return a copy of /etc/shadow in a GET request, well, you don't have root, but you do have the hashed passwords. It doesn't take an interactive root session, and may not even leave a trace of the activity depending upon the particular bug being exploited.
Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow, even with an interactive reverse shell and root access being had. So even when you recover your system from the compromise you have the risk of all those passwords being known, and unfortunately people have a habit of using the same password on more than one system.
Further, lists of usernames and passwords have market value.
On Feb 4, 2015, at 3:16 PM, Lamar Owen lowen@pari.edu wrote:
On 02/04/2015 04:55 PM, Warren Young wrote:
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.
Not exactly.
There have been remotely exploitable vulnerabilities where an arbitrary file could be read
CVEs, please?
I’m aware of vulnerabilities that allow a remote read of arbitrary files that are readable by the exploited process’s user, but for such an exploit to work on /etc/shadow, the process has to be running as root.
Most such vulns are against Apache, PHP, etc, which do not run as root.
One of the biggest reasons for the mass exodus from Sendmail to qmail/exim/postfix/etc was to get away from a monolithic program that had to run as root to do its work.
If you can somehow ...get, say, httpd to return a copy of /etc/shadow
httpd doesn’t have permission to read /etc/shadow, two ways. First, it’s not running as root, and second, you’re running SELinux, *RIGHT*? The default configuration of SELinux on CentOS won’t let httpd read *anything* outside its normal service directories.
But of course the same people fighting this move to more secure password minima are the same ones that turn off SELinux.
Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow...
Further, lists of usernames and passwords have market value.
Of course. But that’s a different thing than we were discussing.
On Wed, Feb 4, 2015 at 4:55 PM, Warren Young wyml@etr-usa.com wrote:
There have been remotely exploitable vulnerabilities where an arbitrary file could be read
CVEs, please?
I’m aware of vulnerabilities that allow a remote read of arbitrary files that are readable by the exploited process’s user, but for such an exploit to work on /etc/shadow, the process has to be running as root.
Most such vulns are against Apache, PHP, etc, which do not run as root.
Those are common. Combine them with anything called a 'local privilege escalation' vulnerability and you've got a remote root exploit. And people will know how to combine them.
One of the biggest reasons for the mass exodus from Sendmail to qmail/exim/postfix/etc was to get away from a monolithic program that had to run as root to do its work.
Except that sendmail was fixed. And when the milter interface was added it became even less monolithic.
Further, lists of usernames and passwords have market value.
Of course. But that’s a different thing than we were discussing.
Not exactly - it just becomes a question of whether the complexity requirements imposed by the installer are really worth much against the pre-hashed lists that would be used to match up the shadow contents.
On Feb 4, 2015, at 4:14 PM, Les Mikesell lesmikesell@gmail.com wrote:
Not exactly - it just becomes a question of whether the complexity requirements imposed by the installer are really worth much against the pre-hashed lists that would be used to match up the shadow contents.
Rainbow tables don’t help against salted hashes. Rainbow tables are for attacking *un*salted hashes, like NTLM used.
https://crackstation.net/hashing-security.htm
When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.
On 5 February 2015 at 10:36, Warren Young wyml@etr-usa.com wrote:
When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.
Kinda highlights that 'time' is important here. Booting into a fresh system and then running updates and hardening your system can take a few minutes. There may be an appreciable difference between having a password that can be cracked in 1 second and one that takes an hour. (Yes, infrastructure can help mitigate this risk).
I'm thinking of someone with limited infrastructure installing a system under time pressure. They might be tempted to use a very weak password initially with the expectation that they would get back to hardening the system later. If they are regularly under time pressure, that may never actually happen, or may be delayed for hours/days. An 8 character password might just nudge the probabilities in your favour and protect against a drive by attack.
Does that sound like a reasonable case to protect against?
On Feb 4, 2015, at 5:20 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 5 February 2015 at 10:36, Warren Young wyml@etr-usa.com wrote:
When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.
Kinda highlights that 'time' is important here.
Yes, which is why a properly-designed remote credential checking system throttles login attempts: to buy time.
Safes and vaults aren’t rated “secure” or “insecure,” they’re rated in terms of minutes. This one here is a 5 minute safe, and that one over there is a 15 minute safe. You buy the one that gives you the time you need to react appropriately to an attack.
An 8 character password might just nudge the probabilities in your favour and protect against a drive by attack.
Does that sound like a reasonable case to protect against?
That’s exactly what this change does.
This calculator will help you to explore the problem:
https://www.grc.com/haystack.htm
Put in something like “Abc123@#” to turn on all the green lights to see the effect of a password that will pass the new rules.
SSH as shipped on CentOS doesn’t allow 1,000 guesses per second, as this calculator assumes, so we actually have a few orders of magnitude more security. Not that it matters, given that it reports that my example password would take 2.13 thousand centuries to crack.
On Feb 4, 2015, at 5:43 PM, Warren Young wyml@etr-usa.com wrote:
SSH as shipped on CentOS doesn’t allow 1,000 guesses per second, as this calculator assumes
Hmm, just thought of a counterattack:
If CentOS’s SSH currently allows 10 guesses per minute *per IP*, all you need to do to get 1,000 guesses per second is to rent time on a 6,000 machine botnet.
On Wed, 2015-02-04 at 17:50 -0700, Warren Young wrote:
On Feb 4, 2015, at 5:43 PM, Warren Young wyml@etr-usa.com wrote:
SSH as shipped on CentOS doesn’t allow 1,000 guesses per second, as this calculator assumes
Hmm, just thought of a counterattack:
If CentOS’s SSH currently allows 10 guesses per minute *per IP*, all you need to do to get 1,000 guesses per second is to rent time on a 6,000 machine botnet.
Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.
Is this safe enough ?
wac4140SoeTer'#621strAAt0918;@@
Online Attack Scenario: (Assuming one thousand guesses per second) 7.26 hundred million trillion trillion trillion centuries
Offline Fast Attack Scenario: (Assuming one hundred billion guesses per second) 7.26 trillion trillion trillion centuries
Massive Cracking Array Scenario: (Assuming one hundred trillion guesses per second) 7.26 billion trillion trillion centuries
They've obviously got slow processors.
On Feb 4, 2015, at 5:55 PM, Always Learning centos@u64.u22.net wrote:
On Wed, 2015-02-04 at 17:50 -0700, Warren Young wrote:
rent time on a 6,000 machine botnet.
Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.
Acquiring your own botnet requires time and effort. Renting someone else’s botnet trades one resource for another.
Nothing is free. Just as with my analogy with safes, we’re not talking about absolute security. We just need to make an attack *costly enough* that it will never succeed, if we do our part. (Like not saying chmod 644 /etc/shadow !!)
On Wed, 2015-02-04 at 18:14 -0700, Warren Young wrote:
Nothing is free. Just as with my analogy with safes, we’re not talking about absolute security. We just need to make an attack *costly enough* that it will never succeed, if we do our part. (Like not saying chmod 644 /etc/shadow !!)
I looked on a DVD backup of the 2010 standard install of a VPS (without looking again I think it was C5.3).
Spreading good ideas and techniques (see my "Centos Learning" mailing list suggestion) could encourage newcomers to implement good security as soon as they arrive on Linux. I found switching to Linux without help was a steep learning curve but, as usual, I survived. I'm still Learning.
On 02/04/2015 07:55 PM, Always Learning wrote:
Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.
Those crackers who build these botnets are the ones who rent out botnet time to people who just was to get the work done. There is a large market in botnet time.
Is this safe enough ?
wac4140SoeTer'#621strAAt0918;@@
Yes, it is.
On Thu, 2015-02-05 at 09:51 -0500, Lamar Owen wrote:
On 02/04/2015 07:55 PM, Always Learning wrote:
Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.
Those crackers who build these botnets are the ones who rent out botnet time to people who just was to get the work done. There is a large market in botnet time.
Surely its time for the Feds to arrest and change them ?
Is this safe enough ?
wac4140SoeTer'#621strAAt0918;@@
Yes, it is.
Gee thanks. I'll use it for root on every server ;-)
On Thu, February 5, 2015 9:34 am, Always Learning wrote:
On Thu, 2015-02-05 at 09:51 -0500, Lamar Owen wrote:
On 02/04/2015 07:55 PM, Always Learning wrote:
Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.
Those crackers who build these botnets are the ones who rent out botnet time to people who just was to get the work done. There is a large market in botnet time.
Surely its time for the Feds to arrest and change them ?
Is this safe enough ?
wac4140SoeTer'#621strAAt0918;@@
Yes, it is.
Gee thanks. I'll use it for root on every server ;-)
I know this is joke. Yet (in a slim chance someone out there can follow it with seriousness) I would strongly suggest:
Don't do it. Don't use anything as any sort of password which was ever publicized in any shape. Putting it in a search line of any search engine, or it passing it over to any (but your own) password strength checker has (fair in my estimate!) chance of that to be logged, added into the database, etc. I almost which to yell: people use your brain ! ;-)
I know, I know, everybody is reasonable, it is just I didn't have my coffee yet...
Valeri
-- Regards,
Paul. England, EU. Je suis Charlie.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, 2015-02-05 at 09:41 -0600, Valeri Galtsev wrote:
wac4140SoeTer'#621strAAt0918;@@
Gee thanks. I'll use it for root on every server ;-)
I know this is joke. Yet (in a slim chance someone out there can follow it with seriousness) I would strongly suggest:
Don't do it. Don't use anything as any sort of password which was ever publicized in any shape. Putting it in a search line of any search engine, or it passing it over to any (but your own) password strength checker has (fair in my estimate!) chance of that to be logged, added into the database, etc. I almost which to yell: people use your brain ! ;-)
Yes never ever, not once, let any person or any search engine etc. know too much about your specific security arrangements. Generalise with principles but always withhold the precise specifics.
The nasty people out there are trying to steal your data and wreck your systems. They have no scruples. There is a real cyber war going-on and your systems are their targets.
I know, I know, everybody is reasonable, it is just I didn't have my coffee yet...
Your logic is amazingly good for a coffee drinker.
On Thu, February 5, 2015 10:08 am, Always Learning wrote:
On Thu, 2015-02-05 at 09:41 -0600, Valeri Galtsev wrote:
wac4140SoeTer'#621strAAt0918;@@
Gee thanks. I'll use it for root on every server ;-)
I know this is joke. Yet (in a slim chance someone out there can follow it with seriousness) I would strongly suggest:
Don't do it. Don't use anything as any sort of password which was ever publicized in any shape. Putting it in a search line of any search engine, or it passing it over to any (but your own) password strength checker has (fair in my estimate!) chance of that to be logged, added into the database, etc. I almost which to yell: people use your brain ! ;-)
Yes never ever, not once, let any person or any search engine etc. know too much about your specific security arrangements. Generalise with principles but always withhold the precise specifics.
The nasty people out there are trying to steal your data and wreck your systems. They have no scruples. There is a real cyber war going-on and your systems are their targets.
I know, I know, everybody is reasonable, it is just I didn't have my coffee yet...
Your logic is amazingly good for a coffee drinker.
No, I wasn't born here though I live here, so I don't take to my heart any jokes about people living in one of the colonies you lost ;-) Just stealing it from some movie I like. Still didn't have chance for my morning coffee yet (which I deserve: I was working hard all morning). Don't take me too seriously too, just get nice cup of tea (or wait till morning for it) ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, 2015-02-05 at 12:35 -0600, Valeri Galtsev wrote:
On Thu, February 5, 2015 10:08 am, Always Learning wrote:
On Thu, 2015-02-05 at 09:41 -0600, Valeri Galtsev wrote:
I know, I know, everybody is reasonable, it is just I didn't have my coffee yet...
Your logic is amazingly good for a coffee drinker.
No, I wasn't born here though I live here, so I don't take to my heart any jokes about people living in one of the colonies you lost ;-)
I thought you were Russian from the way you sometimes phrase your sentences. My mixed ancestry is European. I didn't loose anything, at least half of me didn't. Although I do like a cup of tasty tea, I have never tried the Boston Vintage.
I favour the European Union making open-source computer operating systems the preferred Public Sector choice. The massive state-funded M$ domination, and effective monopoly of new desktops and laptops, stifles innovation and competition. ('State' as in sovereign state)
Its time a free Centos DVD was given away by retailers selling consumer desktops and laptops (including netbooks, notebooks etc.). Forcing consumers to buy M$ at extra cost is wrong.
On 02/05/2015 10:34 AM, Always Learning wrote:
On Thu, 2015-02-05 at 09:51 -0500, Lamar Owen wrote:
Those crackers who build these botnets are the ones who rent out botnet time to people who just was to get the work done. There is a large market in botnet time.
Surely its time for the Feds to arrest and change them ?
The Feds in which country?
Gee thanks. I'll use it for root on every server ;-)
Do note that now that it has been posted to a public list, while it was safe while unpublished, it would not be safe in the future. I have in my possession a file of passwords from a compromised server here, from several years ago. This was part of one of the slow-bruteforcer networks out there, and is one reason we now whitelist only needed outbound connections on port 22 and block all others on our two internet connections.
Incidentally, this particular slow bruteforcer didn't need root to operate. The password list has about 65,000 passwords in it, some of which would have been considered strong passwords. Well, until they made the list. Your password is just about guaranteed to be on future lists.....
However, another password with similar characteristics would be fine. You just never want to use it on more than one server to be safe.....
On Thu, 2015-02-05 at 13:59 -0500, Lamar Owen wrote:
On 02/05/2015 10:34 AM, Always Learning wrote:
Surely its time for the Feds to arrest and change them ?
The Feds in which country?
The USA for a start. The USA's law enforcement is never slow at working with foreign countries law enforcement to secure the arrest of offenders upsetting the USA - sometimes having them extradited to the US of A for trial.
More effort must be made tracing the hackers. Hacking is routinely accepted too often. If a burglar attempts to break into a bank, does law enforcement forget about it ?
Gee thanks. I'll use it for root on every server ;-)
Do note that now that it has been posted to a public list, while it was safe while unpublished, it would not be safe in the future.
Have absolutely no intention of using it or anything resembling it. The security risk is too great !
..... is one reason we now whitelist only needed outbound connections on port 22 and block all others on our two internet connections.
Port 22 is always blocked, port 21 too, on all machines. Too risky. Having port 22 open will give me sleepless nights.
Your password is just about guaranteed to be on future lists.....
Then let them waste their time and energy attempting to crack a non-existent password.
You just never want to use it on more than one server to be safe.....
Agreed. Never ever repeat the same passwords on different machines.
On 2/5/2015 10:59 AM, Lamar Owen wrote:
However, another password with similar characteristics would be fine. You just never want to use it on more than one server to be safe.....
there's a very useful tool built into centos's 'expect' package...
$ mkpasswd -l 15 -d 3 -C 5 5ufkpX@SDxa2DF3
$ mkpasswd -l 24 -d 3 -C 5 xRyijvCo4fhph!QcY46xbprK
$ rpm -qf `which mkpasswd` expect-5.44.1.15-5.el6_4.x86_64
but, Dog save someone from having to type said passwords even once and get it correct.
Jonathan Billings billings at negate.org Tue Feb 3 20:35:44 UTC 2015
Honestly, of all the faults and foibles in the Red Hat/CentOS installer, I'm amazed that someone is complaining about that.
Someone is trying to keep the scope of such faults and foibles on topic, otherwise they'd easily be tempted to get carried away.
"Oh No! They released a
product that's *incrementally* more secure than before! Heavens Above! (faints)"
I agree it's incremental, in the realm of turning hours into days, or days into weeks. I think we're well past 8 character passwords taking centuries to crack by brute force. Therefore I think it's a distraction, pointlessly incremental for staving off remote login attacks. The common attack vectors on users gets them to reveal their password, no matter its length. Or tricks them into agreeing to escalating process privilege even without a password.
If you want something meaningful, disabling sshd by default has a more meaningful effect, and it's more typical (at least in terms of deployment volume) so everyone should be familiar with the idea.
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.
I can set "moon" as the password on OS X, as an admin. Do you think a company, and its users, with such a big target on their backs, haven't considered the benefit of requiring somewhat more secure passwords? So far they've spent quite a lot of development effort (their own and 3rd party developers) on sandboxing functionality and constant policy adjustments over the past few years. If it were worth it, it'd be a lot easier to just say, shift the burden to the user, and make them pick a 10 character password.
Chris Murphy
On Feb 4, 2015, at 4:14 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Feb 4, 2015 at 4:55 PM, Warren Young wyml@etr-usa.com wrote:
Most such vulns are against Apache, PHP, etc, which do not run as root.
Those are common. Combine them with anything called a 'local privilege escalation' vulnerability and you've got a remote root exploit.
Not quite. An LPE can only be used against your system by logged-in users.
To make a blended attack that can read /etc/shadow from an LPE, you need either SSH access or a remote shell vuln, not an arbitrary file read vuln. Holes that expose an unintended remote shell are quite a bit rarer than ones that allow a service like Apache to send you any file their non-root account has permission to read.
It’s a bit like calling lightning to find a system where both types of vulnerabilities are available at the same time.
While this discussion has been very interesting, I would like to encourage participants to be very careful about disclosing the specifics their own security efforts. While is good to discuss the pros and cons of strategies, disclosing the details of the exact strategies that you use, no matter how good they are, is a bad idea. This is typically hard information for an attacker to acquire and they would run the risk of generating too much noise if they were to try to acquire it. A somewhat subtle trap is to disclose information about time, e.g., when you last changed a password on a system.
On Wed, Feb 4, 2015 at 6:32 PM, Warren Young wyml@etr-usa.com wrote:
Most such vulns are against Apache, PHP, etc, which do not run as root.
Those are common. Combine them with anything called a 'local privilege escalation' vulnerability and you've got a remote root exploit.
Not quite. An LPE can only be used against your system by logged-in users.
Or any running program - like a web server.
To make a blended attack that can read /etc/shadow from an LPE, you need either SSH access or a remote shell vuln, not an arbitrary file read vuln. Holes that expose an unintended remote shell are quite a bit rarer than ones that allow a service like Apache to send you any file their non-root account has permission to read.
It’s a bit like calling lightning to find a system where both types of vulnerabilities are available at the same time.
No, you exploit the server application hole to tell you about the kernel vulnerability. The last one I saw in the wild involved the symlink race in the kernel around centos 5.2 or .3 and a struts java library bug. But there are people who know what combinations of vulnerabilities to try.
On Feb 4, 2015, at 7:23 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Feb 4, 2015 at 6:32 PM, Warren Young wyml@etr-usa.com wrote:
An LPE can only be used against your system by logged-in users.
Or any running program - like a web server.
That’s not what LPE means. “L” = “local”, meaning you are logged-in interactively to the server, or have the ability to execute arbitrary commands remotely, which comes to the same thing.
The only way Apache can be used in conjunction with an LPE to provide root access is via something like Shellshock.
I’m not saying LPEs, remote shell attacks, and arbitrary command execution vulnerabilities do not exist. I’m pointing out that each of these classes of vulnerabilities are rare on their own, and rare times rare equals scarce.
There’s no such thing as absolute security. There is only better and worse; somewhere along that continuum is a point labeled “sufficient.” Policies like the one we’re arguing over merely attempt to set a sane minimum level.
On Wed, Feb 4, 2015 at 8:43 PM, Warren Young wyml@etr-usa.com wrote:
On Feb 4, 2015, at 7:23 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Feb 4, 2015 at 6:32 PM, Warren Young wyml@etr-usa.com wrote:
An LPE can only be used against your system by logged-in users.
Or any running program - like a web server.
That’s not what LPE means. “L” = “local”, meaning you are logged-in interactively to the server, or have the ability to execute arbitrary commands remotely, which comes to the same thing.
The only way Apache can be used in conjunction with an LPE to provide root access is via something like Shellshock.
The instance I saw used a java web server, but server bugs that allow allow execution of arbitrary commands have been fairly numerous - shellshock might have worked too. And that's all you need to turn what you thought was a local vulnerability into a remote one.
On 02/04/2015 05:55 PM, Warren Young wrote:
On Feb 4, 2015, at 3:16 PM, Lamar Owen lowen@pari.edu wrote:
There have been remotely exploitable vulnerabilities where an arbitrary file could be read
CVEs, please?
CVE-2006-3392 for one. As this one was against Webmin, well, webmin by nature has to have root access. Yeah, webmin should not be configured to be accessible from the internet at large, but that's not the point. Yes, it is an old one, but there are I'm sure other vulnerabilities that have either not been found or not been published.
And then, a long time ago, in an OS far far away, there was CVE-2000-0915 (FreeBSD 4.1.1 Finger Arbitrary Remote File Access) where the advisory text description included the following wording: "The finger daemon running on the remote host will reveal the contents of arbitrary files when given a command similar to the following :
finger /etc/passwd@target
Which will return the contents of /etc/passwd."
I just had a peek at the anaconda source for Fedora 21. Apparently you can waive the password strength tests (and the non-ASCII tests) by simply clicking "Done" twice.
def _checkPasswordASCII(self, inputcheck): """Set an error message if the password contains non-ASCII characters.
Like the password strength check, this check can be bypassed by pressing Done twice. """
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 5 February 2015 at 09:16, Lamar Owen lowen@pari.edu wrote:
On 02/04/2015 04:55 PM, Warren Young wrote:
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.
Not exactly.
There have been remotely exploitable vulnerabilities where an arbitrary file could be read (not written), but otherwise root access wasn't given by the exploit; that is, no shellcode per se. If you can somehow (buffer overflow shellcode or something similar) get, say, httpd to return a copy of /etc/shadow in a GET request, well, you don't have root, but you do have the hashed passwords. It doesn't take an interactive root session, and may not even leave a trace of the activity depending upon the particular bug being exploited.
Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow, even with an interactive reverse shell and root access being had. So even when you recover your system from the compromise you have the risk of all those passwords being known, and unfortunately people have a habit of using the same password on more than one system.
Further, lists of usernames and passwords have market value.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Feb 4, 2015, at 3:56 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
I just had a peek at the anaconda source for Fedora 21.
This change isn’t in a released version of Fedora yet:
https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html
The change will probably be in Fedora 22, and it’s being discussed here because there’s every reason to think we’ll see the change in CentOS 8.
On Thu, Feb 05, 2015 at 09:56:30AM +1100, Kahlil Hodgson wrote:
I just had a peek at the anaconda source for Fedora 21. Apparently you can waive the password strength tests (and the non-ASCII tests) by simply clicking "Done" twice.
That's correct for Fedora 21. The inability to waive the requirement will show up in the new Anaconda.
On 5 February 2015 at 12:09, Scott Robbins scottro@nyc.rr.com wrote:
On Thu, Feb 05, 2015 at 09:56:30AM +1100, Kahlil Hodgson wrote:
I just had a peek at the anaconda source for Fedora 21. Apparently you can waive the password strength tests (and the non-ASCII tests) by simply clicking "Done" twice.
That's correct for Fedora 21. The inability to waive the requirement will show up in the new Anaconda.
Thanks for the heads up. At least we know it can be easily reinstate it via an updates.img -- for those testing installers in sandboxed environments.
On Wed, 2015-02-04 at 14:55 -0700, Warren Young wrote:
On Feb 4, 2015, at 12:16 PM, Lamar Owen lowen@pari.edu wrote:
Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability
Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow
On C6, the default is:-
---------- 1 root root 854 Mar 13 2014 shadow
On 5 February 2015 at 10:53, Always Learning centos@u64.u22.net wrote:
On C6, the default is:-
---------- 1 root root 854 Mar 13 2014 shadow
Even better if you have SElinux enabled
----------. root root system_u:object_r:shadow_t:s0 /etc/shadow
On Feb 4, 2015, at 4:53 PM, Always Learning centos@u64.u22.net wrote:
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow
Nope:
# rpm -q --dump setup|grep shadow /etc/gshadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X /etc/shadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X
This says it should be mode 400, as it is here on both of the local EL5 boxes I checked.
You have a serious security hole there, Always.
On 2/4/2015 4:04 PM, Warren Young wrote:
# rpm -q --dump setup|grep shadow /etc/gshadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X /etc/shadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X
This says it should be mode 400, as it is here on both of the local EL5 boxes I checked.
You have a serious security hole there, Always.
indeed.
$ cat /etc/redhat-release && ls -l /etc/shadow CentOS release 5.11 (Final) -r-------- 1 root root 4739 Sep 24 10:54 /etc/shadow
On 2015-02-04, Always Learning centos@u64.u22.net wrote:
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow
It is much more likely that someone has screwed up your system. I think even CentOS 4 had shadow as 400. And what on earth would the point be in having a world-readable shadow file?!? The whole point of having a shadow file is to keep password hashes out of /etc/passwd so that people can't read it. It would be nonsensical to then make the shadow file readable.
--keith
On Thu, Feb 5, 2015 at 4:19 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadowIt is much more likely that someone has screwed up your system. I think even CentOS 4 had shadow as 400. And what on earth would the point be in having a world-readable shadow file?!? The whole point of having a shadow file is to keep password hashes out of /etc/passwd so that people can't read it. It would be nonsensical to then make the shadow file readable.
Yes, /etc/shadow would have always been readable only by root by default. The interesting question here is whether an intruder did it, clumsily leaving evidence behind, or whether it is just a local change from following some bad advice about things that need to be changed - or running some script to make those changes. The latter seems more likely to me.
On Thu, February 5, 2015 4:29 pm, Les Mikesell wrote:
On Thu, Feb 5, 2015 at 4:19 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadowIt is much more likely that someone has screwed up your system. I think even CentOS 4 had shadow as 400. And what on earth would the point be in having a world-readable shadow file?!? The whole point of having a shadow file is to keep password hashes out of /etc/passwd so that people can't read it. It would be nonsensical to then make the shadow file readable.
Yes, /etc/shadow would have always been readable only by root by default. The interesting question here is whether an intruder did it, clumsily leaving evidence behind, or whether it is just a local change from following some bad advice about things that need to be changed - or running some script to make those changes. The latter seems more likely to me.
Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
But again, it's your money in your bank (and/or whatever else could get into jeopardy).
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, Feb 5, 2015 at 4:39 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Yes, /etc/shadow would have always been readable only by root by default. The interesting question here is whether an intruder did it, clumsily leaving evidence behind, or whether it is just a local change from following some bad advice about things that need to be changed - or running some script to make those changes. The latter seems more likely to me.
Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
You aren't being paranoid enough. If it happened as a result of following some instructions or running a script, it's not just the box that is compromised, it is everything you think you know. On the other hand it could have just been an accidental typo.
On Thu, February 5, 2015 5:07 pm, Les Mikesell wrote:
On Thu, Feb 5, 2015 at 4:39 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Yes, /etc/shadow would have always been readable only by root by default. The interesting question here is whether an intruder did it, clumsily leaving evidence behind, or whether it is just a local change from following some bad advice about things that need to be changed - or running some script to make those changes. The latter seems more likely to me.
Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
You aren't being paranoid enough.
Really? My take is to take it as seriously as it can potentially be. It _is_ paranoid, and is paranoid enough. Which would constitute pretty good compliment responsible sysadmin can get ;-)
If it happened as a result of following some instructions or running a script, it's not just the box that is compromised, it is everything you think you know. On the other hand it could have just been an accidental typo.
That's why I said "avoid wishful thinking".
Yes, but "could have been" is one story (then, still variety of important things may be left in jeopardy). Finding the proof that it is accidental typo or stupid script is another. The second one takes much more time and effort in my experience. I figure my teachers deserve their share of credit for teaching me the way I am. Your response to incident that just got discovered may be different. But what, after all it is your money (well, _his_ money in this case). As I figure, there are no other users on this box. But imagine there are...
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, Feb 5, 2015 at 5:29 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
You aren't being paranoid enough.
Really? My take is to take it as seriously as it can potentially be. It _is_ paranoid, and is paranoid enough. Which would constitute pretty good compliment responsible sysadmin can get ;-)
No, you are saying don't trust that box.
If it happened as a result of following some instructions or running a script, it's not just the box that is compromised, it is everything you think you know. On the other hand it could have just been an accidental typo.
That's why I said "avoid wishful thinking".
I'm saying don't trust the source of the advice you were following when this happened.
On Thu, 2015-02-05 at 16:39 -0600, Valeri Galtsev wrote:
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow
Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
Logically ?
1. to change the permissions on shadow from -rw-x------ or from ---------- to -rw-r--r-- requires root permissions ?
2. if so, then what is the advantage of changing those permissions when the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
On Thu, February 5, 2015 5:23 pm, Always Learning wrote:
On Thu, 2015-02-05 at 16:39 -0600, Valeri Galtsev wrote:
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadowBe it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
As I said, it's your money, mister.
Think of what your users will think about your response to bizarre you have discovered. Sysadmins have their users' trust a priori. But they have to keep deserving this trust all the time.
Just my $0.02
Valeri
PS I figure I really have to thank my teachers! Including great books I've read...
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 2015-02-05, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Thu, February 5, 2015 5:23 pm, Always Learning wrote:
On Thu, 2015-02-05 at 16:39 -0600, Valeri Galtsev wrote:
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadowBe it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one's wishful thinking!).
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
As I said, it's your money, mister.
It seems very likely that, even if the system's security is not compromised, the sysadmin's certainly is. Some things are beyond our ability to repair.
--keith
On Thu, 2015-02-05 at 17:36 -0600, Valeri Galtsev wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
As I said, it's your money, mister.
In the politest manner may I suggest the ability to read and the ability to retain information is important ?
Somewhere previously in this threat and within the last few days, I mentioned
1. the file permissions were found on a 2010 DVD back-up of a 5.3 ? Centos installation;
2. all my current systems C5 and C6 have ---------- permissions for the shadows (shadow, gshadow and their backups)
3. the disk drive originally used in 2010 was wiped in 2010 or 2011, repartitioned, reformatted and reused.
4. I don't know what happened and despite being concerned and curious I am unlikely ever to discover the cause
Why waste time on this, when Centos Learning, IP TABLES firewall for beginners will bring substantially greater benefits to everyone ? OK, not for the hackers !
On 6 February 2015 at 10:23, Always Learning centos@u64.u22.net wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
The concept in play here is privilege escalation.
An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission.
From there an attacker could use that and other exploits to escalate privileges.
K
On Fri, 2015-02-06 at 10:50 +1100, Kahlil Hodgson wrote:
On 6 February 2015 at 10:23, Always Learning centos@u64.u22.net wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
The concept in play here is privilege escalation.
An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission. From there an attacker could use that and other exploits to escalate privileges.
How could file permission modification of /etc/shadow be used to "escalate privileges" ?
Thanks.
On 2/5/2015 8:20 PM, Always Learning wrote:
On Fri, 2015-02-06 at 10:50 +1100, Kahlil Hodgson wrote:
On 6 February 2015 at 10:23, Always Learning centos@u64.u22.net wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
The concept in play here is privilege escalation.
An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission. From there an attacker could use that and other exploits to escalate privileges.
How could file permission modification of /etc/shadow be used to "escalate privileges" ?
If I can give myself read access to /etc/shadow, then I can grab a copy and try to crack the passwords (including the root password). If I can give myself r/w access, then I can directly change the password and give myself instant access to everything.
On Mon, February 9, 2015 10:55 am, Bowie Bailey wrote:
On 2/5/2015 8:20 PM, Always Learning wrote:
On Fri, 2015-02-06 at 10:50 +1100, Kahlil Hodgson wrote:
On 6 February 2015 at 10:23, Always Learning centos@u64.u22.net wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions
when the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
The concept in play here is privilege escalation.
An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission. From there an attacker could use that and other exploits to escalate privileges.
How could file permission modification of /etc/shadow be used to "escalate privileges" ?
If I can give myself read access to /etc/shadow, then I can grab a copy and try to crack the passwords (including the root password). If I can give myself r/w access, then I can directly change the password and give myself instant access to everything.
I guess, this discussion (about security of your system and what affects it) should be ended by the reference to fundamental book on Unix system [administration]. One thing I learned: you can not become proficient in any subject just by reading sparse blogs about it. One thing you definitely need: very good understanding of underlying fundamentals. For this reason the most productive would be to think if you have very good general understanding of how Unix (or Unix-like) system works. The easiest is to start reading good book about it, and if you see you are making discoveries, then this is definitely what you are missing, and what you need to study before diving into discussion what is good for security and how it affects that. That would be what I would recommend to myself (which I did way back...). If I were choosing the book to get good start today, I would choose:
UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder
- don't worry about "outdated...", remember, you first need fundamentals. It is not as "fundamental" as some of the books of the past I remember, but I'd rather mention it that those really old books.
I'm sure, someone may suggest better book, maybe even free online book. Note, your advise of book giving fundamental knowledge of Unix or Linux system may be really valuable.
Just my $0.02
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, 2015-02-09 at 11:31 -0600, Valeri Galtsev wrote:
I guess, this discussion (about security of your system and what affects it) should be ended by the reference to fundamental book on Unix system [administration]. One thing I learned: you can not become proficient in any subject just by reading sparse blogs about it. One thing you definitely need: very good understanding of underlying fundamentals. For this reason the most productive would be to think if you have very good general understanding of how Unix (or Unix-like) system works. The easiest is to start reading good book about it, and if you see you are making discoveries, then this is definitely what you are missing, and what you need to study before diving into discussion what is good for security and how it affects that. That would be what I would recommend to myself (which I did way back...). If I were choosing the book to get good start today, I would choose:
UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder
- don't worry about "outdated...", remember, you first need fundamentals.
Brilliant logic about ignoring the publication date.
I did a Google on
"UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder"
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
Although I have a natural preference for paper books (I became a computer person at a large international book publisher) and I like the ability to annotate text, the PDF is definitely a useful and informative read.
Thanks Valeri.
I.
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
On Mon, 2015-02-09 at 11:12 -0800, John R Pierce wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Probably not really a software pirate but an individual (and a keen cyclist) storing some old-ish PDFs on his own web site.
One I noticed was "Free BSD, 2009" all 857 pages present - in Russian. Another is a 2005 Linux PDF book in Russian.
No copyright on his photos including long empty roads, sunlight, countryside and an occasional motor vehicle. For example
http://sferon.dlinkddns.com/Pub/Brevet_400km_3.05.2014/P1010009.JPG
of in the countryside
http://sferon.dlinkddns.com/Pub/Images_krepostnaya/Krepostnaja.jpeg
I really liked and appreciated the filming perspective (position) in the Italian video
http://sferon.dlinkddns.com/Pub/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0% BD%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5/BdB%20-%20Ventimiglia%20-% 20Monviso.mpeg
So there is little to fear from the web site of a Russian cyclist who likes Linux. Although I would have preferred him to like Centos more than Debian.
On 2015-02-09, Always Learning centos@u64.u22.net wrote:
On Mon, 2015-02-09 at 11:12 -0800, John R Pierce wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Probably not really a software pirate but an individual (and a keen cyclist) storing some old-ish PDFs on his own web site.
The PDF *itself* is still pirated. It has nothing whatsoever to do with "software" piracy.
So there is little to fear from the web site of a Russian cyclist who likes Linux.
I don't even fully trust docs written by any third party until I can cross-check it against official documentation. So I definitely do not think it's okay to trust pirated documentation from a Russian site I will never be able to know anything about.
--keith
On Mon, February 9, 2015 3:28 pm, Keith Keller wrote:
On 2015-02-09, Always Learning centos@u64.u22.net wrote:
On Mon, 2015-02-09 at 11:12 -0800, John R Pierce wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the
shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Probably not really a software pirate but an individual (and a keen cyclist) storing some old-ish PDFs on his own web site.
The PDF *itself* is still pirated. It has nothing whatsoever to do with "software" piracy.
So there is little to fear from the web site of a Russian cyclist who likes Linux.
I don't even fully trust docs written by any third party until I can cross-check it against official documentation. So I definitely do not think it's okay to trust pirated documentation from a Russian site I will never be able to know anything about.
Which should not reflect on the book I recommended:
http://www.amazon.com/Linux-System-Administration-Handbook-Edition/dp/013148...
(Neither should the fact that the one who recommended it - myself - has Russian origin too. I for one hate the fact that copyright - and decency - are so much violated on the territory of Russia).
Still, as I stressed in my original suggestion: to get proficient in anything one has to learn fundamentals, so I would forget about blogs, web posts, and would begin with a really good book. Unless you are already an expert in a sense you know fundamentals (but this question is the one that one can only answer by himself).
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, 2015-02-09 at 15:54 -0600, Valeri Galtsev wrote:
Still, as I stressed in my original suggestion: to get proficient in anything one has to learn fundamentals, so I would forget about blogs, web posts, and would begin with a really good book. Unless you are already an expert in a sense you know fundamentals (but this question is the one that one can only answer by himself).
I agree with Valeri's assertion that fundamental knowledge is more important than web post or blog snippets.
When building a house, it is important the foundations are perfect and solid otherwise - if there are gaps in the structure supporting the building - that building is likely to be unstable. This analogy also applies to computer operating systems.
On Mon, 2015-02-09 at 13:28 -0800, Keith Keller wrote:
On Mon, 2015-02-09 at 11:12 -0800, John R Pierce wrote:
on a site hosted in Russia which appears to be FULL of copyright violations.
On 2015-02-09, Always Learning centos@u64.u22.net wrote:
Probably not really a software pirate but an individual (and a keen cyclist) storing some old-ish PDFs on his own web site.
The PDF *itself* is still pirated. It has nothing whatsoever to do with "software" piracy.
I don't even fully trust docs written by any third party until I can cross-check it against official documentation. So I definitely do not think it's okay to trust pirated documentation from a Russian site I will never be able to know anything about.
Keith neither of us know whether or not the Russian man obtained his PDF copy of the book lawfully. In my book-publishing opinion, the PDF appears to have originated from the book's publisher, so the original source must have been *the* official source. Hence the book, in the PDF version, must have been written by the official authors.
The existence of an alleged unpaid-for copy on a foreign web site can not, in any sense whatsoever, denigrate, diminish nor deprecate the official authors distinguished achievement.
There are poor people all around the world who enjoy computers including Linux and whom would benefit from learning more about Linux. Some who can read English sufficiently proficiently to benefit from the book's text, may be too poor to afford the, to them in their country, "exorbitant" Western price for an "official" copy. Some publishers recognise this reality and sell in third-world countries at a small fraction of the "Western" price. In those circumstances selling PDFs for an extremely low price may be the source of this particular PDF especially as hardbacks and paperbacks could never economically be sold as low as a very low cost "official" PDF copy.
Depriving people of learning (also known as education) keeps them in political and economic subjugation to the detriment of the Human race.
Would be nice to gain some support for the Centos Learning mailing list suggestion :-)
On Mon, Feb 09, 2015 at 10:10:35PM +0000, Always Learning wrote:
Keith neither of us know whether or not the Russian man obtained his PDF copy of the book lawfully. In my book-publishing opinion, the PDF appears to have originated from the book's publisher, so the original source must have been *the* official source. Hence the book, in the PDF version, must have been written by the official authors.
Unless the guy who is posting the pirated PDF downloaded it from a shady site that inserts PDF viruses and whatnot. The point is, it's neither ethical nor safe to use this pirated copy.
One of the authors, Evi Nemeth, was a really great and interesting person who I've heard speak at conferences. She also co-wrote the Linux Administration Handbook, which I read both editions years ago, so I can vouch for their quality. However, as computer books are most likely to do, they are quickly made out of date by the rapid pace of linux development (even Enterprise linuxes like CentOS).
I learned my trade mostly through doing, watching other people do things, reading lists, and attending conferences, Linux Users Groups and other meetings of Linux admins. I love books, and continue to buy reference books for languages and favorite software tools, but I don't have any recent Linux books.
On Mon, Feb 9, 2015 at 11:12 AM, John R Pierce pierce@hogranch.com wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
-- john r pierce 37N 122W somewhere on the middle of the left coast
Good observation.
Do you know of an ethically available reference on the System Administration topic?
On Mon, February 9, 2015 3:14 pm, PatrickD Garvey wrote:
On Mon, Feb 9, 2015 at 11:12 AM, John R Pierce pierce@hogranch.com
wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the
shows every page appears to be readable. 11 pages devoted to BASH.
Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright
violations.
-- john r pierce 37N 122W somewhere on the middle of the left coast
Good observation.
Do you know of an ethically available reference on the System Administration topic?
There is misunderstanding here. My original reference _IS_ ethically available. The paper born copy of the book can be bought, say, on amazon:
http://www.amazon.com/Linux-System-Administration-Handbook-Edition/dp/013148...
What was bashed in successive posts was pirate copy of the same book hosted somewhere in Russia. Whereas it is strongly advisable to stay away from pirate copy, this fact should not reflect of real book itself. Buying real book is by no means unethical.
Still, there are many knowledgeable people on the list, they may give different recommendation, which will create some pool of choices. I asked John and Jonathan, I'd like to ask also Les Mikesell and Mr. SilverTip257: what would you, gentlemen, recommend? Anybody? (I know there are many experts on the list - larger number than my poor brain can hold ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, Feb 9, 2015 at 3:42 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Still, there are many knowledgeable people on the list, they may give different recommendation, which will create some pool of choices. I asked John and Jonathan, I'd like to ask also Les Mikesell and Mr. SilverTip257: what would you, gentlemen, recommend? Anybody? (I know there are many experts on the list - larger number than my poor brain can hold ;-)
Are you looking for something simpler or more detailed than the obvious starting point? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... or https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
It may be good to read other guides to understand what is specific to RHEL/Centos and what works in general, but there is probably more than you want to know in the official docs.
On Mon, Feb 9, 2015 at 2:06 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Mon, Feb 9, 2015 at 3:42 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
Still, there are many knowledgeable people on the list, they may give different recommendation, which will create some pool of choices. I asked John and Jonathan, I'd like to ask also Les Mikesell and Mr. SilverTip257: what would you, gentlemen, recommend? Anybody? (I know there are many experts on the list - larger number than my poor brain can hold ;-)
Are you looking for something simpler or more detailed than the obvious starting point? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... or https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
It may be good to read other guides to understand what is specific to RHEL/Centos and what works in general, but there is probably more than you want to know in the official docs.
-- Les Mikesell lesmikesell@gmail.com
Thank you, Les, for, probably the most relevant starting point.
As one who is constantly driven to distraction by spelling and grammar errors when reading such an offering, I'd like to know how a member of the CentOS project submits improvements to something in the RedHat documentation. Can you provide guidance in that regard?
On 10 February 2015 at 09:53, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
I'd like to know how a member of the CentOS project submits improvements to something in the RedHat documentation. Can you provide guidance in that regard?
I think you can simply submit a bug report under fedora documentation.
Note, the Fedora Systems Administration Guide seems to have been written by the same RedHat engineers
https://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Gu...
Kal
On 10 February 2015 at 10:08, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
I think you can simply submit a bug report under fedora documentation.
Via bugzilla:
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Documentation
On Mon, Feb 9, 2015 at 3:11 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 10 February 2015 at 10:08, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
I think you can simply submit a bug report under fedora documentation.
Via bugzilla:
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Documentation _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Please allow me to make sure I am perceiving this correctly, reports of errors found in RedHat documentation are to be reported against the Fedora Documentation product type in the RedHat bugzilla? and reports of errors found in Fedora documentation are, also, to be reported against the Fedora Documentation product type in the RedHat bugzilla?
On 10 February 2015 at 10:15, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
Please allow me to make sure I am perceiving this correctly, reports of errors found in RedHat documentation are to be reported against the Fedora Documentation product type in the RedHat bugzilla? and reports of errors found in Fedora documentation are, also, to be reported against the Fedora Documentation product type in the RedHat bugzilla?
I don't know officially, but I'm making a guess that, since the two documents are clearly related and have the same authors, if you see the same error in the Fedora document and you report it, it will probably get fixed in both. The Fedora document explicitly solicits bug reports, but I don't see the same in the RedHat one. Worth a shot don't you think? Maybe submit a small bug report and see what the response is like?
On Mon, Feb 9, 2015 at 3:23 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 10 February 2015 at 10:15, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
Please allow me to make sure I am perceiving this correctly, reports of errors found in RedHat documentation are to be reported against the Fedora Documentation product type in the RedHat bugzilla? and reports of errors found in Fedora documentation are, also, to be reported against the Fedora Documentation product type in the RedHat bugzilla?
I don't know officially, but I'm making a guess that, since the two documents are clearly related and have the same authors, if you see the same error in the Fedora document and you report it, it will probably get fixed in both. The Fedora document explicitly solicits bug reports, but I don't see the same in the RedHat one. Worth a shot don't you think? Maybe submit a small bug report and see what the response is like?
That's a testable starting point. Thanks.
On 02/09/2015 04:25 PM, PatrickD Garvey wrote:
On Mon, Feb 9, 2015 at 3:23 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
On 10 February 2015 at 10:15, PatrickD Garvey
patrickdgarveyt@gmail.com wrote:
Please allow me to make sure I am perceiving this correctly, reports of errors found in RedHat documentation are to be reported against the Fedora Documentation product type in the RedHat bugzilla? and reports of errors found in Fedora documentation are, also, to be reported against the Fedora Documentation product type in the RedHat bugzilla?
I don't know officially, but I'm making a guess that, since the two documents are clearly related and have the same authors, if you see the same error in the Fedora document and you report it, it will probably get fixed in both. The Fedora document explicitly solicits bug reports, but I don't see the same in the RedHat one. Worth a shot don't you think? Maybe submit a small bug report and see what the response is like?
That's a testable starting point. Thanks. _______________________________________________
Officially, no, the "Fedora Documentation" bz product isn't there for Red Hat guides. If you want to file a bug against a RHEL guide, choose your version of RHEL then look for the guide's component - these days, they all start with "doc-", which should make the search easy.
Unofficially, there's a nonzero chance that your bug will find a writer that plays in both spaces, or that we'll be able reassign the bug to the correct component for you. But please, don't make work for Fedora volunteers when there are people standing by getting paid to handle your bugs :)
On 10 February 2015 at 16:39, Pete Travis lists@petetravis.com wrote:
Officially, no, the "Fedora Documentation" bz product isn't there for Red Hat guides. If you want to file a bug against a RHEL guide, choose your version of RHEL then look for the guide's component - these days, they all start with "doc-", which should make the search easy.
Thanks for the heads up. Was not aware of the 'doc-' prefix.
Unofficially, there's a nonzero chance that your bug will find a writer that plays in both spaces, or that we'll be able reassign the bug to the correct component for you. But please, don't make work for Fedora volunteers when there are people standing by getting paid to handle your bugs :)
As previously noted, the authors of both documents are the same, and appear to be RedHat employees.
On 02/09/2015 11:11 PM, Kahlil Hodgson wrote:
On 10 February 2015 at 16:39, Pete Travis lists@petetravis.com wrote:
Officially, no, the "Fedora Documentation" bz product isn't there for Red Hat guides. If you want to file a bug against a RHEL guide, choose your version of RHEL then look for the guide's component - these days, they all start with "doc-", which should make the search easy.
Thanks for the heads up. Was not aware of the 'doc-' prefix.
Unofficially, there's a nonzero chance that your bug will find a writer that plays in both spaces, or that we'll be able reassign the bug to the correct component for you. But please, don't make work for Fedora volunteers when there are people standing by getting paid to handle your bugs :)
As previously noted, the authors of both documents are the same, and appear to be RedHat employees. _______________________________________________
Right, that's the non-zero thing I mentioned. Some Red Hat writers also contribute to Fedora Docs, often on their own time.
On 02/09/2015 11:11 PM, Kahlil Hodgson wrote:
On 10 February 2015 at 16:39, Pete Travis lists@petetravis.com wrote:
Officially, no, the "Fedora Documentation" bz product isn't there for Red Hat guides. If you want to file a bug against a RHEL guide, choose your version of RHEL then look for the guide's component - these days, they all start with "doc-", which should make the search easy.
Thanks for the heads up. Was not aware of the 'doc-' prefix.
Unofficially, there's a nonzero chance that your bug will find a writer that plays in both spaces, or that we'll be able reassign the bug to the correct component for you. But please, don't make work for Fedora volunteers when there are people standing by getting paid to handle your bugs :)
As previously noted, the authors of both documents are the same, and appear to be RedHat employees. _______________________________________________
Right, that's the non-zero thing I mentioned. Some Red Hat writers also contribute to Fedora Docs, often on their own time.
On Feb 9, 2015, at 12:12 PM, John R Pierce pierce@hogranch.com wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Remember, Adobe Flash BAD, Adobe PDF GOOD.
Amazing how quickly security fundamentals — like declining to download a file which can contain scripts that run on the local machine from a clearly dodgy site — go out the window when put up against expediency.
On Tue, February 10, 2015 4:04 pm, Warren Young wrote:
On Feb 9, 2015, at 12:12 PM, John R Pierce pierce@hogranch.com wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Remember, Adobe Flash BAD, Adobe PDF GOOD.
Amazing how quickly security fundamentals â like declining to download a file which can contain scripts that run on the local machine from a clearly dodgy site â go out the window when put up against expediency.
Yes, expediency. And cost, quite likely (even though it is better than affordable). That really suggests the need to learn fundamentals (I would put in order: Unix or Linux system basics first; system security second).
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri and Warren,
My decisions are based on what I know. Those decisions can be called "informed decisions".
I am not abdicating anything to you two gentlemen.
On 2015-02-10, Always Learning centos@u64.u22.net wrote:
My decisions are based on what I know. Those decisions can be called "informed decisions".
Calling them "informed decisions" doesn't automatically make them informed decisions.
--keith
On Tue, 2015-02-10 at 16:24 -0800, Keith Keller wrote:
On 2015-02-10, Always Learning centos@u64.u22.net wrote:
My decisions are based on what I know. Those decisions can be called "informed decisions".
Calling them "informed decisions" doesn't automatically make them informed decisions.
This is puerile. Are you really so bored ?
On Tue, 2015-02-10 at 15:04 -0700, Warren Young wrote:
On Feb 9, 2015, at 12:12 PM, John R Pierce pierce@hogranch.com wrote:
On 2/9/2015 11:06 AM, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
on a site hosted in Russia which appears to be FULL of copyright violations.
Remember, Adobe Flash BAD, Adobe PDF GOOD.
Amazing how quickly security fundamentals — like declining to download a file which can contain scripts that run on the local machine from a clearly dodgy site — go out the window when put up against expediency.
1. Flash I don't have or use.
2. PDFs can be created by *NON-ADOBE* software. PDF's (well most of them) can be opened by non-Adobe PDF-type software.
3. The Russian's web site is that of a devote cyclist. Most of the films on his web site are of cycling or about cycling. Most of the oldish PDF files are about Linux and in Russian. I do not consider his site presents a malicious danger to me.
Warren, it is senseless you wasting your valuable time trying to make me do what you want. The system here just does not work like that - perhaps elsewhere but certainly not here.
On 2/10/2015 3:28 PM, Always Learning wrote:
- The Russian's web site is that of a devote cyclist.
oh, well, I'm glad that makes the copyright violation of stealing an authors work OK in your book.
On Tue, 2015-02-10 at 16:39 -0800, John R Pierce wrote:
On 2/10/2015 3:28 PM, Always Learning wrote:
- The Russian's web site is that of a devote cyclist.
oh, well, I'm glad that makes the copyright violation of stealing an authors work OK in your book.
Another bored expert desperate for a modicum of excitement ?
You have absolutely no prima facie evidence to support your assertion.
I refer you to my posting dated Mon, 09 Feb 2015 22:10:35 +0000 which includes, inter alia:-
"Keith neither of us know whether or not the Russian man obtained his PDF copy of the book lawfully. In my book-publishing opinion, the PDF appears to have originated from the book's publisher, so the original source must have been *the* official source. Hence the book, in the PDF version, must have been written by the official authors.
"The existence of an alleged unpaid-for copy on a foreign web site can not, in any sense whatsoever, denigrate, diminish nor deprecate the official authors distinguished achievement.
"There are poor people all around the world who enjoy computers including Linux and whom would benefit from learning more about Linux. Some who can read English sufficiently proficiently to benefit from the book's text, may be too poor to afford the, to them in their country, "exorbitant" Western price for an "official" copy. Some publishers recognise this reality and sell in third-world countries at a small fraction of the "Western" price. In those circumstances selling PDFs for an extremely low price may be the source of this particular PDF especially as hardbacks and paperbacks could never economically be sold as low as a very low cost "official" PDF copy."
FACT: Valeri's recommendation is, in my opinion, a useful source of basic knowledge benefiting Centos users regardless whether that book in printed on paper or is a virtual or an electronic "book" (i.e. PDF).
ANOTHER FACT: Linux Programmer's Reference, Petersen, Osborne McGraw-Hill 1998 - ISBN 0-07-882587-3, which I obtained on 27 October 2000, is also a good good source of useful information. I've started re-reading the 71 pages on BASH. I never knew the first character on the first line could be a space.
On 2/10/2015 4:58 PM, Always Learning wrote:
You have absolutely no prima facie evidence to support your assertion.
Seriously? from page 5 of said PDF.
Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise....
On Tue, 2015-02-10 at 17:14 -0800, John R Pierce wrote:
On 2/10/2015 4:58 PM, Always Learning wrote:
You have absolutely no prima facie evidence to support your assertion.
Seriously? from page 5 of said PDF.
Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise....
Oh dear.
Legal point 1: you do not know the source of the Russian's PDF.
Legal point 2: you can not determine with certainty that the said PDF is *not* a lawful copy.
Legal point 3: you can not establish the Russian's possession of the PDF is *not* lawful.
Legal point 4: Page iv (meaning preface page 4 but physical page 5) contains
"Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-13-148005-6 ISBN-10: 0-13-148005-7 Text printed in the United States on recycled paper at Edwards Brothers in Ann Arbor, Michigan. First printing, June 2010"
Legal point 5: You are seriously mistaken in asserting the said PDF did *not* originate from the publisher.
Legal point 6: You have no case to argue.
Legal point 7: You are unproductively using your own, and other's, time, interest and energy.
On 2/10/2015 5:29 PM, Always Learning wrote:
Legal point 1: you do not know the source of the Russian's PDF.
doesn't matter.
Legal point 2: you can not determine with certainty that the said PDF is *not* a lawful copy.
I know that *I* don't have the rights to read that PDF, and I suspect you don't either. Do you have written permission from the copyright holder, Pearson Publishing, to download that ? I see a statement embedded in the work that permission is required to reproduce, store, transmit, etc in any form. Your suggesting on a public forum such as this that a random copy on a random website is an acceptable source of a copyrighted work is immoral and wrong.
On 02/10/2015 05:29 PM, Always Learning wrote:
Legal point 1: you do not know the source of the Russian's PDF.
Legal point 2: you can not determine with certainty that the said PDF is *not* a lawful copy.
Legal point 3: you can not establish the Russian's possession of the PDF is *not* lawful.
I don't think anyone is arguing that point. But if anyone else downloads the PDF from his site, then they are violating the copyright. I can only assume you have violated the copyright, as you are quoting from the PDF.
Legal point 7: You are unproductively using your own, and other's, time, interest and energy.
And you are perpetuating the same. Please let it go, and do not encourage copyright infringement.
On Tue, Feb 10, 2015 at 6:29 PM, Always Learning centos@u64.u22.net wrote:
On Tue, 2015-02-10 at 17:14 -0800, John R Pierce wrote:
On 2/10/2015 4:58 PM, Always Learning wrote:
You have absolutely no prima facie evidence to support your assertion.
Seriously? from page 5 of said PDF.
Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise....Oh dear.
Legal point 1: you do not know the source of the Russian's PDF.
Well seeing as it's over 1200 pages and only ~16MB, it cannot possibly be scanned. It's too small a file. If I had to guess, it probably escaped somewhere between whoever did the layout and created the original PDF, and a foreign publisher (I'm assuming this book has been translated into other languages).
Legal point 2: you can not determine with certainty that the said PDF is *not* a lawful copy.
It's most definitely not a lawful copy. I'm completely certain of this.
Legal point 3: you can not establish the Russian's possession of the PDF is *not* lawful.
Russia is a UCC signatory, it's certain it's not a lawful copy under either international or Russian law.
Legal point 4: Page iv (meaning preface page 4 but physical page 5) contains
"Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax: (617) 671-3447 ISBN-13: 978-0-13-148005-6 ISBN-10: 0-13-148005-7 Text printed in the United States on recycled paper at Edwards Brothers in Ann Arbor, Michigan. First printing, June 2010"
Legal point 5: You are seriously mistaken in asserting the said PDF did *not* originate from the publisher.
It doesn't matter if the publisher lost containment and the PDF escaped into the wild. It's still copyright infringement to cause copyrighted material to be replicated without permission.
Legal point 6: You have no case to argue.
OK well if you're going to take the time to make bullshit legal points like this, then I get to say "you sir, may kindly kiss my ass."
Legal point 7: You are unproductively using your own, and other's, time, interest and energy.
So are you, and this is your informal invitation to stop.
On Tue, February 10, 2015 6:58 pm, Always Learning wrote:
On Tue, 2015-02-10 at 16:39 -0800, John R Pierce wrote:
On 2/10/2015 3:28 PM, Always Learning wrote:
- The Russian's web site is that of a devote cyclist.
oh, well, I'm glad that makes the copyright violation of stealing an authors work OK in your book.
Another bored expert desperate for a modicum of excitement ?
You have absolutely no prima facie evidence to support your assertion.
I refer you to my posting dated Mon, 09 Feb 2015 22:10:35 +0000 which includes, inter alia:-
"Keith neither of us know whether or not the Russian man obtained his PDF copy of the book lawfully. In my book-publishing opinion, the PDF appears to have originated from the book's publisher, so the original source must have been *the* official source. Hence the book, in the PDF version, must have been written by the official authors.
"The existence of an alleged unpaid-for copy on a foreign web site can not, in any sense whatsoever, denigrate, diminish nor deprecate the official authors distinguished achievement.
"There are poor people all around the world who enjoy computers including Linux and whom would benefit from learning more about Linux. Some who can read English sufficiently proficiently to benefit from the book's text, may be too poor to afford the, to them in their country, "exorbitant" Western price for an "official" copy. Some publishers recognise this reality and sell in third-world countries at a small fraction of the "Western" price. In those circumstances selling PDFs for an extremely low price may be the source of this particular PDF especially as hardbacks and paperbacks could never economically be sold as low as a very low cost "official" PDF copy."
FACT: Valeri's recommendation is, in my opinion, a useful source of basic knowledge benefiting Centos users regardless whether that book in printed on paper or is a virtual or an electronic "book" (i.e. PDF).
Just to make it clear: I recommended the book itself without pointing to any source of it, and when pirate copy was mentioned by somebody else, I had to say I do not recommend that source and would recommend to buy the book on amazon.
The guy who put document copyrighted to somebody else is either stupid or ignorant (and I don't care if he is Russian, Bulgarian, Chinese, or USA person, or...). Ignorance in this place is akin full disregard of another person's hard work and rights (Book brilliant authors' and copyright holders'). I doubt we can educate that Russian guy. Unless someone who feels good towards him can find way to contact him and explain everything... Not I definitely ;-)
Valeri
ANOTHER FACT: Linux Programmer's Reference, Petersen, Osborne McGraw-Hill 1998 - ISBN 0-07-882587-3, which I obtained on 27 October 2000, is also a good good source of useful information. I've started re-reading the 71 pages on BASH. I never knew the first character on the first line could be a space.
-- Regards,
Paul. England, EU. Je suis Charlie.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, 2015-02-10 at 19:19 -0600, Valeri Galtsev wrote:
Just to make it clear: I recommended the book itself without pointing to any source of it, and when pirate copy was mentioned by somebody else, I had to say I do not recommend that source and would recommend to buy the book on amazon.
The person asserting the copy was "pirated" (meaning stolen) has no proof it was stolen. Just because someone jumps up and down shouting various things, can not in law make any of those things a fact.
To prove something one needs FACTS which is also known as evidence. No evidence exists that the copy was stolen. Justice depends on factual information not people inventing "facts" without proof. If I claimed you were Bill Gates' brother, would that actually make you Bill Gates' brother ?
On Tue, February 10, 2015 7:36 pm, Always Learning wrote:
On Tue, 2015-02-10 at 19:19 -0600, Valeri Galtsev wrote:
Just to make it clear: I recommended the book itself without pointing to any source of it, and when pirate copy was mentioned by somebody else, I had to say I do not recommend that source and would recommend to buy the book on amazon.
Indeed I should have said "allegedly pirated" not just "pirated". As I don't care to go into details if it is or it isn't. I also would recommend to finish this discussion and those who feel so get themselves some fundamental book and go ahead with reading it. Which I'm going to do myself (there are things I need to read...)
Valeri
The person asserting the copy was "pirated" (meaning stolen) has no proof it was stolen. Just because someone jumps up and down shouting various things, can not in law make any of those things a fact.
To prove something one needs FACTS which is also known as evidence. No evidence exists that the copy was stolen. Justice depends on factual information not people inventing "facts" without proof. If I claimed you were Bill Gates' brother, would that actually make you Bill Gates' brother ?
-- Regards,
Paul. England, EU. Je suis Charlie.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, 2015-02-10 at 21:32 -0600, Valeri Galtsev wrote:
Indeed I should have said "allegedly pirated" not just "pirated". As I don't care to go into details if it is or it isn't. I also would recommend to finish this discussion and those who feel so get themselves some fundamental book and go ahead with reading it. Which I'm going to do myself (there are things I need to read...)
On my desk I have a copy of 'The Book'. I got it free of all costs. It is not mine. I did not buy it or otherwise make a payment to possess it. It has the same copyright notice inside. It does not state "Pirate Copy" anywhere on the covers or inside. Hopefully I am lawfully allow to read it ?
Before an unnecessary riot starts perhaps I should mention I've borrowed 'The Book' from a public library :-)
On Tue, Feb 10, 2015 at 8:55 PM, Always Learning centos@u64.u22.net wrote:
Before an unnecessary riot starts perhaps I should mention I've borrowed 'The Book' from a public library :-)
FYI my comments are restricted the PDF floating around of the recommended UNIX and Linux System Admin book. That's definitely not legit.
What libraries offer is not only legal, it's important to keep this intact. Publishers have variably been very unreasonable abrogating the first-sale doctrine when it comes to ebook versions. It's a case where I believe in no shade of gray. If I'm led to believe I've bought an ebook, not merely renting it, then I should have the right to give that ebook to a library, school, friend, leave it in an estate to children. And quite a number of publishers deny this doctrine applies to ebooks. Not good.
On Tue, 2015-02-10 at 21:04 -0700, Chris Murphy wrote:
What libraries offer is not only legal, it's important to keep this intact. Publishers have variably been very unreasonable abrogating the first-sale doctrine when it comes to ebook versions. It's a case where I believe in no shade of gray. If I'm led to believe I've bought an ebook, not merely renting it, then I should have the right to give that ebook to a library, school, friend, leave it in an estate to children. And quite a number of publishers deny this doctrine applies to ebooks. Not good.
My considered opinion is:-
PDF copies, as produced by the publisher, should be sold for no more than USD $ 10.00 per copy with 30% going directly to the author. At present publishers are far too greedy. Their lust for the public's cash is detrimental to learning generally and to the distribution of knowledge.
Many years ago, before I sold my soul to the computer world for GBP £2 per week extra pay, bookshops received between 45% and 55% discount. PDFs require no storage space in premises, no heating, no building insurance, no public liability insurance, no staffing costs etc. etc. Consequently it is unreasonable for the publisher and/or the distributor to retain most of the income from PDF and other e-book format sales. They are doing virtually no work but profiteering enormously from the author's hard work.
Admittedly it is possible for sellers to sell cloned copies of PDFs. However it must be possible to overprint every page in a PDF with a sellers receipt number or publisher's copy-serial-number which could be entered on a web site when seeking errata and extras associated with possession of the publication - or even registering possession of a copy for future updates and associated information.
On Tue, Feb 10, 2015 at 5:39 PM, John R Pierce pierce@hogranch.com wrote:
On 2/10/2015 3:28 PM, Always Learning wrote:
- The Russian's web site is that of a devote cyclist.
oh, well, I'm glad that makes the copyright violation of stealing an authors work OK in your book.
This thread has gone quite off topic. But as a published author, which should give me no more authority on the subject than anyone else, who happens to have had his copyright ripped off, I have to say that I don't really give a crap. Maybe I give a tiny crap.
For one, the freeloader problem is well understood economically, and isn't that big of a problem so long as the price and distribution mechanisms are appropriate in the first place. Second, not everyone on this planet is on the same page (or even book) when it comes to property rights; this can't be construed to mean "we're right and they're wrong". Someone who buys my book and now has these ideas, who then replicates them with his own physical property (ink and paper) really hasn't cost me anything. The idea I've lost sales royalties is sort of a b.s. argument, chances are these people wouldn't have ever bought the book to begin with. OK, so the argument goes, then these people shouldn't benefit from these ideas. Well, in my case, they're not really ideas, they're facts - it's a technical book. And you can't copyright facts. You can only copyright the prose by which those facts are presented.
An incomplete search suggests the average middle class Russian annual income is around $10k-$15k. This book is 0.2% of that salary. The average U.S. salary is nearly 4x that amount. Does anything think the price of this book is 1/4 the price in Russian? *shrug*
The whole valuation and pricing of this sort of stuff is bullcrap. It's a less than a $40 book on Amazon, chances are each author is making much less than $1 in royalties per book. So who's being ripped off the most by downloading a bootleg PDF? The publisher. The authors aren't being injured that much.
On Feb 10, 2015, at 4:28 PM, Always Learning centos@u64.u22.net wrote:
- PDFs can be created by *NON-ADOBE* software.
And SWFs can be generated by non-Adobe software, and JARs can be generated by non-Oracle software. What’s your point? Is it that only Evil Corporations can create software that can be used for evil purposes?
Are you back on the “F/OSS software is invulnerable” bandwagon already, after being knocked off it a week or two back?
PDF's (well most of them) can be opened by non-Adobe PDF-type software.
So what do you do when you get a PDF that *can’t* be opened by your non-Adobe PDF reader? Do you discard it and go find another way to get the content, or do you grumble and fire up acroread?
- The Russian's web site is that of a devote cyclist.
I’m a devout cyclist, too, yet you’ve apparently decided I’m an enemy.
What makes this other guy unimpeachable?
I could care less that he’s Russian, or a cyclist. What I care is that he’s purposely providing illicit goods. That’s enough for me to distrust what he’s providing.
This Russian cyclist doesn’t even have to be the source of the evil. Chances are that he didn’t buy this PDF from an official source and offer it directly. It’s far more likely that he’s just another step in the chain back to the original source. Why are you trusting all of them, too?
Warren, it is senseless you wasting your valuable time trying to make me do what you want.
Make you? How am I going to accomplish that? I have no power over you.
I just thought that, since you were Always Learning, you’d want someone to tell you when they saw you doing something that could compromise your security.
On Tue, 2015-02-10 at 17:59 -0700, Warren Young wrote:
On Feb 10, 2015, at 4:28 PM, Always Learning centos@u64.u22.net wrote:
- PDFs can be created by *NON-ADOBE* software.
And SWFs can be generated by non-Adobe software, and JARs can be generated by non-Oracle software. What’s your point? Is it that only Evil Corporations can create software that can be used for evil purposes?
Are you back on the “F/OSS software is invulnerable” bandwagon already, after being knocked off it a week or two back?
PDF's (well most of them) can be opened by non-Adobe PDF-type software.
So what do you do when you get a PDF that *can’t* be opened by your non-Adobe PDF reader? Do you discard it and go find another way to get the content, or do you grumble and fire up acroread?
- The Russian's web site is that of a devote cyclist.
I’m a devout cyclist, too, yet you’ve apparently decided I’m an enemy.
Warren, I have never declared you to be an "enemy". I am an all weather cyclist who used take his bike as luggage on aircraft.
What makes this other guy unimpeachable?
I could care less that he’s Russian, or a cyclist. What I care is that he’s purposely providing illicit goods.
Then go and complain to the USA's FBI on +1.202-324 3000. It is not a Centos issue !
That’s enough for me to distrust what he’s providing.
This Russian cyclist doesn’t even have to be the source of the evil. Chances are that he didn’t buy this PDF from an official source and offer it directly. It’s far more likely that he’s just another step in the chain back to the original source. Why are you trusting all of them, too?
Warren, it is senseless you wasting your valuable time trying to make me do what you want.
Please don't waste your time moaning about something which is not related to Centos.
Make you? How am I going to accomplish that? I have no power over you.
I just thought that, since you were Always Learning, you’d want someone to tell you when they saw you doing something that could compromise your security.
I never stated I was stupid. Being in the world's top 2% of brainy people neither deprives me of decisiveness nor of thoughtful consideration. Having encountered my first M$ boot virus circa 1987 ? and having seen others experiencing M$ viruses, I am aware of the dangers.
This thread is unproductive.
On Mon, Feb 09, 2015 at 07:06:11PM +0000, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
Although I have a natural preference for paper books (I became a computer person at a large international book publisher) and I like the ability to annotate text, the PDF is definitely a useful and informative read.
It looks like that's a pirated book, so it's probably not terribly ethical (nor safe) to use that PDF.
On Mon, February 9, 2015 1:13 pm, Jonathan Billings wrote:
On Mon, Feb 09, 2015 at 07:06:11PM +0000, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
Although I have a natural preference for paper books (I became a computer person at a large international book publisher) and I like the ability to annotate text, the PDF is definitely a useful and informative read.
It looks like that's a pirated book, so it's probably not terribly ethical (nor safe) to use that PDF.
-- Jonathan Billings billings@negate.org
Thanks Jonathan. John R Pierce also mentioned that it is hosted in Russia. I for one would definitely avoid this source. If I were to set myself a goal to get fundamental book I would wait a bit, as some clever people may recommend something else on this list, then choose what looks most fundamental to you. I would ask John Pierce and Jonathan Billings: what would you, gentlemen, recommend for the one who decided to become really very Unix (or Linux) person - understanding in-depth how the system works? Other experts (I know there are many on this list)?
Thanks. Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, Feb 9, 2015 at 11:13 AM, Jonathan Billings billings@negate.org wrote:
On Mon, Feb 09, 2015 at 07:06:11PM +0000, Always Learning wrote:
The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.
Although I have a natural preference for paper books (I became a computer person at a large international book publisher) and I like the ability to annotate text, the PDF is definitely a useful and informative read.
It looks like that's a pirated book, so it's probably not terribly ethical (nor safe) to use that PDF.
-- Jonathan Billings billings@negate.org
Good observation.
Do you know of an ethically available reference on the System Administration topic?
On 10/02/15 04:31, Valeri Galtsev wrote:
UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder
Yeah buy this book. Skimping is not acceptable.
I do hope the Niña is found in my lifetime http://nina7.org
On Mon, February 9, 2015 1:51 pm, Peter Lawler wrote:
On 10/02/15 04:31, Valeri Galtsev wrote:
UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder
Yeah buy this book. Skimping is not acceptable.
+1
Yes, good people have to feed their families, so their work has to be paid for (by us, customers, through buying good product).
I would also wait for other advises (maybe someone suggests better book).
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 02/06/2015 12:50 AM, Kahlil Hodgson wrote:
On 6 February 2015 at 10:23, Always Learning centos@u64.u22.net wrote:
Logically ?
- to change the permissions on shadow from -rw-x------ or from
---------- to -rw-r--r-- requires root permissions ?
- if so, then what is the advantage of changing those permissions when
the entity possessing root authority can already read shadow - that entity requires neither group nor user permissions to read shadow.
The concept in play here is privilege escalation.
An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission. From there an attacker could use that and other exploits to escalate privileges.
come on guys, If a cracker changed the perms to 644 he's probably sensible enough to change it back to 000 after grabbing a copy... this is most likely a BCAK error, let it rest please.
On Thu, 2015-02-05 at 14:19 -0800, Keith Keller wrote:
On 2015-02-04, Always Learning centos@u64.u22.net wrote:
On C5 the default appears to be:-
-rw-r--r-- 1 root root 1220 Jan 31 03:04 shadow
It is much more likely that someone has screwed up your system. I think even CentOS 4 had shadow as 400. And what on earth would the point be in having a world-readable shadow file?!? The whole point of having a shadow file is to keep password hashes out of /etc/passwd so that people can't read it. It would be nonsensical to then make the shadow file readable.
That is why I posted earlier today
"Yes that is what I would like to know. Can't tell. That disk was wiped, partitioned differently and reformatted. But it remains a puzzle I am unlikely to forget for a long time."
On Wed, 2015-02-04 at 14:08 -0500, Lamar Owen wrote:
However, the reason you want a password that is not easily bruteforced has nothing to do with this, and all bruteforce attempts cannot be blocked by this method.
Thanks for your well-explained concerns. You make good sense.
Just counted the characters in one of my root passwords. It uses uppercase, lowercase, symbols, numbers and is a mere 25 characters long. Another one is, I think, about 32 characters long.
Plain FTP is banned. SSH is shifted away to an obscure port and permitted only for 3 predetermined IP addresses. Web hackers are automatically banned after the first attempt. Similar defences are employed against spammers and mail hackers.
I restrict directory and file access to special users with no-logon ability. I upgrade immediately a replacement is announced. I read my chosen selection of logs and self-created reporting programmes from every server.
IP Tables restricts in and out traffic as much as possible. DROP appears everywhere.
I'm not paranoid about security but I do not intend to be a passive or a willing victim of hacking etc. I would jail hackers for a minimum of 6 months.
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??
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.
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.
On 2015-02-03 22:22, Always Learning wrote:
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.
I am maybe mislead, but I thought that is exactly what fail2ban[1] would do and this is already a few years out. Also it is ,if I remember correctly, in epel.
Regards,
Markus
On 2015-02-03, Markus markus.scharitzer@gmail.com wrote:
On 2015-02-03 22:22, Always Learning wrote:
(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.
I am maybe mislead, but I thought that is exactly what fail2ban[1] would do and this is already a few years out. Also it is ,if I remember correctly, in epel.
sshguard can also do this (not sure if it's in EPEL or another common repo).
More paranoid sysadmins simply disable all password logins and make users use ssh keys instead.
--keith
Scott Robbins wrote:
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
I don't follow your meaning. Do you think yraM is a palindrome?
Merriam-Webster (online) a word, verse, or sentence (as “Able was I ere I saw Elba”) or a number (as 1881) that reads the same backward or forward
I can't believe many people use palindromes as passwords.
On Wed, Feb 04, 2015 at 12:34:20AM +0000, Timothy Murphy wrote:
Scott Robbins wrote:
On Tue, Feb 03, 2015 at 01:53:45PM +0000, Timothy Murphy wrote:
The 7 rules listed in this URL seem utterly bizarre to me.
The first is "Don't use a palindrome" which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means "a known word backwards".
That's what I would call it (or phrase or sequence of numbers.) When I read your post, I thought I was missing something, but some cursory googling indicates that I'm right. What am I missing here?
I don't follow your meaning. Do you think yraM is a palindrome?
Ah, your original sentence was originally quite clear, but I managed to misunderstand it, thinking you meant a word that is the same backwards and forwards, as opposed to what you clearly defined. Sorry. I guess my mind filled in the spaces or something.
On 02/03/2015 04:56 AM, Les Mikesell wrote:
On Mon, Feb 2, 2015 at 4:17 PM, Warren Young wyml@etr-usa.com wrote:
Let’s flip it around: what’s your justification *for* weak passwords?
You don't need to write them down. Or trust some 3rd party password keeper to keep them. Whereas when 'not weak' is determined by someone else in the middle of trying to complete something, you are very likely to have to write it down.
Use pass phrases. They work both ways - stronger password, easier to remember.
On Mon, 2015-02-02 at 15:17 -0700, Warren Young wrote:
The answer is clear to me: general security principles. By the time EL8 comes out, we’ll have had ~3 years of warnings under EL7 that weak passwords would not be tolerated, and they’re finally disallowing them. Good!
(More like 6 years, actually, because EL6 gives a red warning bar for weak passwords.)
Let’s flip it around: what’s your justification *for* weak passwords?
Wrong point. Wrong focus. Ultimately it is for the deployer (and the user if Root) to determine. To suggest otherwise is pure arrogance.
M$ users do not own their machines. M$ does. M$ determines what they can do and what data M$ secretly collects on them, stores on the machine and prevents the user viewing. Seems like another move towards emulating M$.
If testing then a one character password is very acceptable to me. Why should some arrogant nutter impose an arduous ultra secure password when a simple one character password will suffice ? Who knows the machine, the deploying environment and the circumstances better ? The user or some anonymous and arrogant nutter perhaps many thousands of miles (or kilometers) away ?
Remember machines should be working for the convenience of Humanity - not for the convenience of anonymous nutters who know absolutely nothing about the user's work situation ! Generally having strong passwords is good however generalised circumstances should never be forced down the throats of loyal users. An English (as in England, Europe) saying is:-
Rules were made for the guidance of wise men, but for the obedience of fools !
If everyone is willing to donate USD 1, then perhaps we could lend him to M$ where security is so lax he could do some enormous good.
No need to waffle Warren. You've lost this one :-)
On 03/02/15 10:31, Always Learning wrote:
Remember machines should be working for the convenience of Humanity - not for the convenience of anonymous nutters who know absolutely nothing about the user's work situation !
'anonymous nutters'? I guess those people on the cited mail lists are using fake names. Given you're carrying on about being English, maybe you should contemplate the slander, libel and defamation laws in that country as well as in other countries where your post may be being read.
No need to waffle Warren. You've lost this one :-)
I don't think it's Warren who's waffling. I certainly don't think the people on the referenced mail lists are anonymous, or nutters.
And just to be 100% clear, you're certainly not speaking for me.
Pete.
On Tue, 2015-02-03 at 10:44 +1100, Peter Lawler wrote:
On 03/02/15 10:31, Always Learning wrote:
Remember machines should be working for the convenience of Humanity - not for the convenience of anonymous nutters who know absolutely nothing about the user's work situation !
'anonymous nutters'? I guess those people on the cited mail lists are using fake names. Given you're carrying on about being English, maybe you should contemplate the slander, libel and defamation laws in that country as well as in other countries where your post may be being read.
Didn't cite any mailing list. One can not defame an anonymous nutter/expert/genius/fool. Can't be slander because that is oral defamation.
When the changes (a.k.a. improvements) are introduce, just how many users will be aware of the identities of those who promoted and implement those changes ? Very few, if any. Hence 'anonymous' is definitely justified in that context.
Nutters seems justified because a wise decision maker will always permit informed users to make their own choice.
And just to be 100% clear, you're certainly not speaking for me.
Writing for myself is sufficient. This list does not yet circulate audio messages.
On Tue, Feb 03, 2015 at 10:44:31AM +1100, Peter Lawler wrote:
On 03/02/15 10:31, Always Learning wrote:
Remember machines should be working for the convenience of Humanity - not for the convenience of anonymous nutters who know absolutely nothing about the user's work situation !
'anonymous nutters'? I guess those people on the cited mail lists are using fake names.
Whether anonymous or not, they continually show that they have no idea of a work situation. Each time we work around it.
As I understand it, the rationale is because RH allows ssh root login by default. I'd rather they change that, but I also want to have millions of dollars and be admired by everyone.
On Mon, 2015-02-02 at 20:02 -0500, Scott Robbins wrote:
Whether anonymous or not, they continually show that they have no idea of a work situation. Each time we work around it.
They lack general knowledge of the 'real' computer world. To them it seems like a childish game.
As I understand it, the rationale is because RH allows ssh root login by default. I'd rather they change that, but I also want to have millions of dollars and be admired by everyone.
How can a remote user log-on for the first time, if not via SSH ? Perhaps the installation process should permit the installer to select a non-standard SSH port at installation time ?
...... and on first log-on the user is forced to change the password and also to change the originally SSH port ?
It would have been nice if the 'anonymous' to me people on another RH related list had popped into Centos and sought ideas, opinions and comments ..... that is what 'team work' is about :-)
On Mon, February 2, 2015 5:31 pm, Always Learning wrote:
On Mon, 2015-02-02 at 15:17 -0700, Warren Young wrote:
The answer is clear to me: general security principles. By the time EL8 comes out, weâll have had ~3 years of warnings under EL7 that weak passwords would not be tolerated, and theyâre finally disallowing them. Good!
(More like 6 years, actually, because EL6 gives a red warning bar for weak passwords.)
Letâs flip it around: whatâs your justification *for* weak passwords?
Wrong point. Wrong focus. Ultimately it is for the deployer (and the user if Root) to determine. To suggest otherwise is pure arrogance.
M$ users do not own their machines. M$ does. M$ determines what they can do and what data M$ secretly collects on them, stores on the machine and prevents the user viewing. Seems like another move towards emulating M$.
If testing then a one character password is very acceptable to me. Why should some arrogant nutter impose an arduous ultra secure password when a simple one character password will suffice ? Who knows the machine, the deploying environment and the circumstances better ? The user or some anonymous and arrogant nutter perhaps many thousands of miles (or kilometers) away ?
Remember machines should be working for the convenience of Humanity - not for the convenience of anonymous nutters who know absolutely nothing about the user's work situation ! Generally having strong passwords is good however generalised circumstances should never be forced down the throats of loyal users. An English (as in England, Europe) saying is:-
Rules were made for the guidance of wise men, but for the obedience of fools !
Yet, the "fools" are so inventive, they often find a way around rules.
Valeri
If everyone is willing to donate USD 1, then perhaps we could lend him to M$ where security is so lax he could do some enormous good.
No need to waffle Warren. You've lost this one :-)
-- Regards,
Paul. England, EU. Je suis Charlie.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 3 February 2015 at 10:31, Always Learning centos@u64.u22.net wrote:
If testing then a one character password is very acceptable to me. Why should some arrogant nutter impose an arduous ultra secure password when a simple one character password will suffice ? Who knows the machine, the deploying environment and the circumstances better ? The user or some anonymous and arrogant nutter perhaps many thousands of miles (or kilometers) away ?
I know its hard to believe, but you are not the only one using this OS. There are a broad range of users with a broad range of experience using the OS in a broad range scenarios. One important group is new users with limited experience and knowledge about security. This is an important group to protect. More experienced users understand this and put up with, or work around, the occasional inconvenience. This is not arrogance, this is about being a responsible member of a community. It is important for all of us to encourage (and discuss) good security practices, as well as discourage (and refute) poor practices. Ultimately, this make our community a safer place.
It is my, perhaps naive, hope that members of our community are Always Learning about good security practices and emerging threats to the OS.
The root password is close to, if not actually, our last line of defense (SELinux helps us here by the way). Using a one character password is problematic if you are connected to the internet, for example, if you are _testing_ the OS and want to run updates after the install. This is problematic since, by default, new installs typically allows SSH access and root logins over SSH. Yes, firewalls help, but they need to be configured correctly, and there are subtle tricks that sophisticated attackers can exploit to subvert poorly configured firewalls. If you really want to do this, I'd suggest running your test system in some kind of DMZ to prevent any exploit cascading into the rest of your network. It may just be easier to pick a "good" but easy to type root password that you use for all your test machines. Also, its a good idea to make sure you always turn off your test machines when not in use, and to disable them once you are finished testing (so they can't be accidentally turned on in the future).
Hope this helps.
Kal
On Tue, 2015-02-03 at 11:57 +1100, Kahlil Hodgson wrote:
One important group is new users with limited experience and knowledge about security. This is an important group to protect.
It is important for all of us to encourage (and discuss) good security practices, as well as discourage (and refute) poor practices. Ultimately, this make our community a safer place.
Perhaps a topic for the Centos Wiki entitled Basic Security on Your New Machine ?
The root password is close to, if not actually, our last line of defense (SELinux helps us here by the way).
Surely the whole idea is to prevent nasty things getting in.
Disable FTP. Change SSH ports. Restrict access to sensitive parts from known IPs. Run Logwatch or similar (and amend the reports using /etc/logwatch ...). Read the logs. Allocate file and directory permissions to users lacking any log-on ability.
There is a lot that can be done.
Using a one character password is problematic if you are connected to the internet, for example, if you are _testing_ the OS and want to run updates after the install.
But if one is doing things on a isolated machine unconnected to anything why the password aggro ? Best never to speculate when attempting to justify a hash and arrogant policy of DO WHAT RHEL DEMANDS. I prefer a clear warning and then let the user make an informed choice. After their first hacking they will not make a similar mistake again.
This is problematic since, by default, new installs typically allows SSH access and root logins over SSH.
Then block it as part of the installation process and let the user open what they think they need. Not use if you are correct about SSH. Root usually (if I remember correctly) needs to be permitted.
Yes, firewalls help, but they need to be configured correctly, and there are subtle tricks that sophisticated attackers can exploit to subvert poorly configured firewalls.
Again another opportunity for a good Centos Wiki article. A basic firewall setup. Then a series of examples: to achieve this, do that. Obviously good and clear explanations are needed to enable impeccable understanding of the firewall logic.
Yes help the new users. Perhaps even a Centos NewUsers list devoid of all the more technical things. It could cater for single machine users.
If you really want to do this, I'd suggest running your test system in some kind of DMZ to prevent any exploit cascading into the rest of your network.
Not really sure what a (USA military) DMZ looks like. Security has always been my highest priority. "When in doubt, lock 'em out" is my motto.
It may just be easier to pick a "good" but easy to type root password that you use for all your test machines. Also, its a good idea to make sure you always turn off your test machines when not in use, and to disable them once you are finished testing (so they can't be accidentally turned on in the future).
Unnecessary in my working environment. I write and test virtually even day, 7 days a week. No machine, test or production, has unrestricted access to/from the Internet. Unused ports are blocked. Unused applications are removed or disabled. SSH is allowed from only 3 IPs. Instant IP blocking for suspicious activity has been a basic component for the last 3 or 4 years, or longer. It was the first security enhancement I programmed.
To save electricity equipment is turned-off when not in use.
On 3 February 2015 at 12:58, Always Learning centos@u64.u22.net wrote:
If you really want to do this, I'd suggest running your test system in some kind of DMZ to prevent any exploit cascading into the rest of your network.
Not really sure what a (USA military) DMZ looks like. Security has always been my highest priority. "When in doubt, lock 'em out" is my motto.
A DMZ in this context is a network that has been isolated from the rest of your local network. You can access it from your local network, it can access the rest of the world, but it can't access your network. The idea is that, if a machine in the DMZ is compromised, it can only access other machines in the DMZ.
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 2/2/2015 6:16 PM, Kahlil Hodgson wrote:
A DMZ in this context is a network that has been isolated from the rest of your local network. You can access it from your local network, it can access the rest of the world, but it can't access your network. The idea is that, if a machine in the DMZ is compromised, it can only access other machines in the DMZ.
its *very* annoying that the soho internet gateway/router market uses the term "DMZ" for the target of default port forwarding rules, nearly the exact OPPOSITE of what a proper DMZ is.
On Tue, 2015-02-03 at 13:16 +1100, Kahlil Hodgson wrote:
A DMZ in this context is a network that has been isolated from the rest of your local network. You can access it from your local network, it can access the rest of the world, but it can't access your network. The idea is that, if a machine in the DMZ is compromised, it can only access other machines in the DMZ.
Thanks. Now I know. That sort of operation can be done via the router and by selecting a wifi option on the same router (Asus RT-AC68U). Wifi is off by default.
On 2/2/2015 6:29 PM, Always Learning wrote:
On Tue, 2015-02-03 at 13:16 +1100, Kahlil Hodgson wrote:
A DMZ in this context is a network that has been isolated from the rest of your local network. You can access it from your local network, it can access the rest of the world, but it can't access your network. The idea is that, if a machine in the DMZ is compromised, it can only access other machines in the DMZ.
Thanks. Now I know. That sort of operation can be done via the router and by selecting a wifi option on the same router (Asus RT-AC68U). Wifi is off by default.
An Asus RT-whatever is a home internet gateway, not a proper firewall router, and it has no provision for a proper DMZ as it doesn't have a port for it. This has *nothing* to do with wifi.
implementing a proper DMZ requires a firewall router with multiple zones, at a minimum WAN (internet), LAN (your regular network), and DMZ, used for your public facing internet servers. The DMZ uses its own network switch (or VLAN) separate from your LAN switch(es), so traffic from LAN<=>DMZ has to go through the firewall router. You define firewall rules such that DMZ servers are blocked from accessing anything on your WAN except specific services they need (if any), but you usually allow systems on the LAN side access to everything on the DMZ side. I've seen configurations where even LAN to DMZ was tightly controlled, so for example only administrator workstations could ssh into the DMZ servers.
On Mon, 2015-02-02 at 18:41 -0800, John R Pierce wrote:
An Asus RT-whatever is a home internet gateway, not a proper firewall router, and it has no provision for a proper DMZ as it doesn't have a port for it. This has *nothing* to do with wifi.
The Asus I use for development work is more than a mere 'home only' thing. It is used in small offices and caters for multiple external IP addresses. It has wifi that separates visitor traffic from the LAN it controls.
However I have no wish and no need to play about using DMZs because for the development work I do, I don't need a DMZ or anything resembling a DMZ.
On 2015-02-03, Always Learning centos@u64.u22.net wrote:
Perhaps a topic for the Centos Wiki entitled Basic Security on Your New Machine ?
As long as someone qualified is writing and reviewing this wiki page.
--keith
On Mon, 2015-02-02 at 19:03 -0800, Keith Keller wrote:
On 2015-02-03, Always Learning centos@u64.u22.net wrote:
Perhaps a topic for the Centos Wiki entitled Basic Security on Your New Machine ?
As long as someone qualified is writing and reviewing this wiki page.
Disagree. One does not have to posses some mythical qualifications, or any qualification at all, to write a sensible guide. What is required is knowledge, experience, clarity of thought and expression and a desire and ability to pass-on one's knowledge to others in a very understandable manner.
Peer review is obviously beneficial.
Placing obstacles in the way perhaps explains why this topic may not have been sufficient covered by the Centos wiki. Just look at what the "Qualified" have produced so far on this topic ! Why does one need to be "qualified" by a third party before one can write a good, concise and very informative guide ?
I think it better if the peer reviewer/reviewers is/are distinct from the author(s). Reviewing one's own work is often prone to inadvertently overlooking one's own mistakes.
It can be a collaborative effort.
On Mon, Feb 2, 2015 at 7:03 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2015-02-03, Always Learning centos@u64.u22.net wrote:
Perhaps a topic for the Centos Wiki entitled Basic Security on Your New Machine ?
As long as someone qualified is writing and reviewing this wiki page.
--keith
I thought the Open Source base belief on that was that a single specific expert is insufficient.
Everyone here knows iterative documenting on the CentOS wiki can be done via http://lists.centos.org/mailman/listinfo/centos-docs Right?
On 2015-02-03, PatrickD Garvey patrickdgarveyt@gmail.com wrote:
On Mon, Feb 2, 2015 at 7:03 PM, Keith Keller
As long as someone qualified is writing and reviewing this wiki page.
I thought the Open Source base belief on that was that a single specific expert is insufficient.
Fair enough. Allow me to rephrase: as long as someones qualified are writing and reviewing the page.
--keith
On Mon, Feb 02, 2015 at 11:31:35PM +0000, Always Learning wrote:
If testing then a one character password is very acceptable to me. Why should some arrogant nutter impose an arduous ultra secure password when a simple one character password will suffice ? Who knows the machine, the deploying environment and the circumstances better ? The user or some anonymous and arrogant nutter perhaps many thousands of miles (or kilometers) away ?
I'm curious, were you upset when Java (and various other software packages that use SSL) were updated to stop using SSLv3? Surely this would have caused problems with any testing infrastructure that wasn't open to the world that used pre-generated SSL certificates. The decision to disable it was made by the packagers of the software because of security implications. Sure, SSLv3 still works, it's just not secure. It's just some arrogant nutter who thinks that maybe we shouldn't be using it anymore.
On Tue, 2015-02-03 at 09:24 -0500, Jonathan Billings wrote:
I'm curious, were you upset when Java (and various other software packages that use SSL) were updated to stop using SSLv3?
No. I do not use Java. Updating to prevent security breeches is *always* a good idea.
-
Always Learning -
Beartooth -
Binet, Valere (NIH/NIA/IRP) [C] -
Bowie Bailey -
Chris Murphy -
Gordon Messmer -
James B. Byrne -
John R Pierce -
Jonathan Billings -
Kahlil Hodgson -
Keith Keller -
Lamar Owen -
Les Mikesell -
Markus -
Nicolas Thierry-Mieg -
PatrickD Garvey -
Pete Travis -
Peter Lawler -
Rejy M Cyriac -
Scott Robbins -
Timothy Murphy -
Valeri Galtsev -
Warren Young