Re: [CentOS] trouble installing Math::BigInt module
On 4/1/2014 4:10 PM, Tom Robinson wrote: > Tom Robinson > IT Manager/System Administrator > > MoTeC Pty Ltd > > 121 Merrindale Drive > Croydon South > 3136 Victoria > Australia > > T: +61 3 9761 5050 > F: +61 3 9761 5051 > E: tom.robin...@motec.com.au > > On 01/04/14 19:04, Bennett Haselton wrote: >> On 3/31/2014 10:42 PM, Tom Robinson wrote: >>> On 01/04/14 16:19, Bennett Haselton wrote: >>>> On 3/31/2014 7:56 PM, Tom Robinson wrote: >>>>> Can you verify to which packages thefiles belong? >>>>> >>>>> Try using RPM: >>>>> >>>>> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm >>>> On the old machine: >>>> perl-Net-IP-1.25-2.fc6 >>>>> and >>>>> >>>>> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm >>>> On the new machine: >>>> perl-Crypt-DSA-1.16-1.el5.rf >>> That should be a good starting point. Your check on installed packages as >>> preposed by John shows two >>> very different packaged environments. Did you ever use CPAN on the old or >>> new machine? >> Yes, on both. I needed it because I needed to install Crypt::Twofish >> and it didn't seem to be available from the default repositories used by >> yum but it was available from CPAN. > So I stand alone on this, but CPAN can work. I use it. Well it sounds like it can work if you know have enough Linux knowledge that if CPAN throws you a curveball (or since you're Australian, bowls you a googly?), like package updates clobbering your libraries, and the written documentation about what to do is missing or wrong, you can fill in the gaps. I don't know enough about Linux to recognize when the documentation is wrong (or to fill in the missing parts), so I try to stay on the standard supported path as much as possible. >> Because there were dozens of sources that I read, plus probably >> thousands of others that I didn't read, saying that installing from CPAN >> was a way to install Perl modules, I figured it was reasonably safe to >> follow those directions, so I went ahead and did it. > Part of the issue is, as others have stated, you have a mish/mash of so many > different sources that > they don't play together nicely any more. > Best if you pare back to the basics. > > Try just core and EPEL packages to start with. If you can't find a package > for your needs you have a > few options. Compile a package yourself or use CPAN. > > CPAN on CentOS 5 is more difficult because when package updates arrive they > can clobber you nicely > installed CPAN libraries. CentOS 6 handles this better. CPAN does allow you > to configure the install > path for libraries, however, so you can defeat the package update clobberring > issue. > > In your case, probably best to stick with the package approach and compile a > new package based on > the installed core and EPEL packages to resolve the rest of your requirements. I understand (I think), but is it easy to tell me, or is there a *reliable*, *vetted* source, describing for intermediate users how to actually do this? i.e.: 1) When you say "Try just core and EPEL packages to start with", are you talking about which .repo files I should keep in my /etc/yum.repos.d directory? OK, then which ones should be in there? Only the CentOS-* ones that were in there by default? And *not* the rpmforge.repo one? Does one of the default .repo files also include the EPEL packages? 2) And then if I want to install a module like Crypt::Twofish which isn't included in the default packages, by "compiling a new package based on the installed core and EPEL packages", then I do -- what? I understand that if you already know the answers to these questions, it seems like the answers are "obvious" or "easy to find on Google". The problem is that's what got me here in the first place, because I did look for answers from reliable sources on Google, and didn't know enough to realize which parts of the directions were wrong. If I try to do the next step based on directions from Google, I'm not doing to know when the directions are misleading me there either. So I'm hoping someone could tell me how to do it or could point me to directions that have actually been vetted (meaning that someone showed the directions to at least one intermediate-level user and said "Here, we want these directions to be helpful to people, so try these out, let me know if you get stuck, and we'll keep revising the directions until there are no places where people get stuck any more."). >> Now, later I found out that you can get
Re: [CentOS] trouble installing Math::BigInt module
On 3/31/2014 10:42 PM, Tom Robinson wrote: > On 01/04/14 16:19, Bennett Haselton wrote: >> On 3/31/2014 7:56 PM, Tom Robinson wrote: >>> Can you verify to which packages thefiles belong? >>> >>> Try using RPM: >>> >>> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm >> On the old machine: >> perl-Net-IP-1.25-2.fc6 >>> and >>> >>> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm >> On the new machine: >> perl-Crypt-DSA-1.16-1.el5.rf > That should be a good starting point. Your check on installed packages as > preposed by John shows two > very different packaged environments. Did you ever use CPAN on the old or new > machine? Yes, on both. I needed it because I needed to install Crypt::Twofish and it didn't seem to be available from the default repositories used by yum but it was available from CPAN. Because there were dozens of sources that I read, plus probably thousands of others that I didn't read, saying that installing from CPAN was a way to install Perl modules, I figured it was reasonably safe to follow those directions, so I went ahead and did it. Now, later I found out that you can get your machine into an inconsistent state by installing things from both CPAN and yum repositories, and moreover apparently you can't even properly uninstall things that are installed by CPAN: http://stackoverflow.com/questions/2626449/how-can-i-de-install-a-perl-module-installed-via-cpan so by following directions to the letter which are repeated in thousands of sources, I apparently put my machine in a state that will cause frequent unpredictable conflicts with all the things installed by the system package manager, and the damage is irreversible. Is that about right? :) At about the same time I learned not to use CPAN, the person helping me solve the current problem said that I could make the run-time errors go away by going into CPAN and install Math::BigInt -- which led to a new error, getting "Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::Calc at /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DH.pm line 6", so then I installed Math::BigInt::Pari through CPAN and it fixed the problem. I had to use CPAN because it was the only solution he knew and it was an emergency to get that error fixed. So, going forward, to mitigate the damage, should I just take all the packages that are currently only listed as installed on the old machine, truncate the version number (so e.g. truncate "perl-Compress-Raw-Zlib-2.052-1.el5.rf" to just "perl-Compress-Raw-Zlib2") and install that with yum on the command line? (Thanks for that list, by the way.) And more generally, what is the best practice if I want to install a module like Crypt::Twofish that was not in the default yum repositories, if John and C.L. are saying to avoid CPAN, and both John and Tom are saying to avoid adding extra yum repositories? I'd like to use yum just for consistency since it automatically handles dependencies and such, and at least if I always use yum, then yum will always be "aware" of what's installed already (as opposed to things installed from CPAN). Bennett > I would work > to bring the new machine's perl environment as close to that of the old > machine's. > > Indeed, perl-Net-SFTP package is only installed on the new machine! > > Your package output is reformatted here. Work through this to bring your > environments as close as > possible and check if you have used CPAN to install packages in the past. > > $ diff -yW80 /tmp/oldlist /tmp/newlist > perl-5.8.8-41.el5 perl-5.8.8-41.el5 > perl-Compress-Raw-Bzip2-2.052-1.el5.r | perl-Class-Loader-2.03-1.2.el5.rf > perl-Compress-Raw-Zlib-2.052-1.el5.rf | perl-Compress-Zlib-1.42-1.fc6 > perl-Convert-ASN1-0.22-1.el5.rf | perl-Convert-ASCII-Armour-1.4-1.2.el5 > perl-Crypt-SSLeay-0.57-3.el5.rf | perl-Convert-ASN1-0.20-1.1 > perl-DBD-mysql-4.014-1.el5.rf | perl-Convert-PEM-0.07-1.2.el5.rf > perl-DBI-1.615-1.el5.rf | perl-Crypt-CBC-2.30-1.el5.rf >> perl-Crypt-DES-2.05-3.2.el5.rf >> perl-Crypt-DH-0.06-1.2.el5.rf >> perl-Crypt-DSA-1.16-1.el5.rf >> perl-Crypt-IDEA-1.08-1.el5.rf >> perl-Crypt-Primes-0.50-1.2.el5.rf >> perl-Crypt-RSA-1.99-1.el5.rf >> perl-Crypt-Random-1.25-1.2.el5.rf >> perl-Crypt-Twofish-2.13-1.el5.rf >> per
Re: [CentOS] trouble installing Math::BigInt module
On 3/31/2014 8:10 PM, John R Pierce wrote: > On 3/31/2014 7:56 PM, Tom Robinson wrote: >> Can you verify to which packages thefiles belong? >> >> Try using RPM: >> >> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm >> >> and >> >> rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm > for that matter, on both machines... > > rpm -qa |grep ^perl Old machine: perl-Test-Mock-LWP-0.05-1.el5.rf perl-HTML-Tagset-3.20-1.el5.rf perl-Net-Daemon-0.43-1.el5.rf perl-XML-LibXML-1.70-2.el5.rf perl-Net-SSLeay-1.36-1.el5.rf perl-DBD-mysql-4.014-1.el5.rf perl-Crypt-SSLeay-0.57-3.el5.rf perl-Sub-Uplevel-0.2002-1.el5.rf perl-IO-Tty-1.08-2.el5.rf perl-Digest-HMAC-1.01-15 perl-5.8.8-41.el5 perl-libwww-perl-5.805-1.1.1 perl-Test-MockObject-1.09-1.el5.rf perl-LWP-UserAgent-Determined-1.04-1.el5.rf perl-Convert-ASN1-0.22-1.el5.rf perl-UNIVERSAL-can-1.16-1.el5.rf perl-XML-NamespaceSupport-1.11-1.el5.rf perl-IO-Compress-2.030-2.el5.rf perl-Email-Date-Format-1.002-1.el5.rf perl-Expect-1.21-1.el5.rf perl-Test-Warn-0.22-1.el5.rf perl-Net-IP-1.25-2.fc6 perl-WWW-Mechanize-1.72-1.el5.rf perl-suidperl-5.8.8-41.el5 perl-Net-Telnet-3.03-5 perl-UNIVERSAL-isa-1.03-1.el5.rf perl-XML-SAX-0.96-1.el5.rf perl-HTML-Parser-3.68-1.el5.rf perl-Tree-DAG_Node-1.06-1.el5.rf perl-Compress-Raw-Bzip2-2.052-1.el5.rf perl-Compress-Raw-Zlib-2.052-1.el5.rf perl-Net-DNS-0.59-3.el5 perl-URI-1.35-3 perl-PlRPC-0.2020-1.el5.rf perl-DBI-1.615-1.el5.rf perl-HTTP-Server-Simple-0.43-1.el5.rf perl-Digest-SHA1-2.11-1.2.1 perl-IO-Socket-SSL-1.01-2.el5 perl-MIME-Lite-3.029-1.el5.rf New machine: perl-DBD-MySQL-3.0007-2.el5 perl-URI-1.35-3 perl-Compress-Zlib-1.42-1.fc6 perl-String-CRC32-1.4-2.fc6 perl-Tie-EncryptedHash-1.24-1.el5.rf perl-Sort-Versions-1.5-1.2.el5.rf perl-File-Which-1.09-1.el5.rf perl-Class-Loader-2.03-1.2.el5.rf perl-Net-SSH-Perl-1.34-1.el5.rf perl-5.8.8-41.el5 perl-Math-Pari-2.01080603-1.el5.rf perl-Crypt-IDEA-1.08-1.el5.rf perl-Math-GMP-2.05-1.el5.rf perl-Crypt-DES-2.05-3.2.el5.rf perl-Data-Buffer-0.04-1.2.el5.rf perl-Convert-ASCII-Armour-1.4-1.2.el5.rf perl-Probe-Perl-0.01-1.el5.rf perl-Crypt-DH-0.06-1.2.el5.rf perl-Test-Script-1.05-1.el5.rf perl-Crypt-DSA-1.16-1.el5.rf perl-Convert-PEM-0.07-1.2.el5.rf perl-Crypt-Random-1.25-1.2.el5.rf perl-Crypt-RSA-1.99-1.el5.rf perl-Net-SFTP-0.10-1.el5.rf perl-Crypt-Twofish-2.13-1.el5.rf perl-DBI-1.52-2.el5 perl-Digest-SHA1-2.11-1.2.1 perl-Digest-MD2-2.03-1.2.el5.rf perl-Crypt-CBC-2.30-1.el5.rf perl-Digest-HMAC-1.01-15 perl-IPC-Run3-0.043-1.el5.rf perl-Convert-ASN1-0.20-1.1 perl-Crypt-Primes-0.50-1.2.el5.rf perl-suidperl-5.8.8-41.el5 Thanks! Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] trouble installing Math::BigInt module
On 3/31/2014 7:56 PM, Tom Robinson wrote: > Can you verify to which packages thefiles belong? > > Try using RPM: > > rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm On the old machine: perl-Net-IP-1.25-2.fc6 > and > > rpm -qf /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm On the new machine: perl-Crypt-DSA-1.16-1.el5.rf > > Tom Robinson > IT Manager/System Administrator > > MoTeC Pty Ltd > > 121 Merrindale Drive > Croydon South > 3136 Victoria > Australia > > T: +61 3 9761 5050 > F: +61 3 9761 5051 > E: tom.robin...@motec.com.au > > On 01/04/14 13:34, Bennett Haselton wrote: >> I had to move a perl script from an old server to a new one. Both the >> old and new servers are running "CentOS release 5.10 (Final)" and perl >> v5.8.8. (But the problem I'm running into appears to be a package >> management problem and not a Perl problem which is why I'm posting it to >> a CentOS list.) >> >> The line of code in the script that attempts to open a Net::SFTP >> connection, which was working fine on the old machine, no longer works >> on the new machine. I've tracked it down to the module >> Net::SSH::Perl::Key::DSA not loading correctly on the new machine. On >> the old one, the line: >> perl -e "use Net::SSH::Perl::Key::DSA;" >> gives no error and no output (as expected), but on the new machine, the >> same line gives: >> >> www:/var/www/html/circumventor# perl -e "use Net::SSH::Perl::Key::DSA;" >> Math::BigInt version 1.78 required--this is only version 1.77 at >> /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4. >> BEGIN failed--compilation aborted at >> /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4. >> Compilation failed in require at >> /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7. >> BEGIN failed--compilation aborted at >> /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7. >> Compilation failed in require at >> /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14. >> BEGIN failed--compilation aborted at >> /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14. >> Compilation failed in require at -e line 1. >> BEGIN failed--compilation aborted at -e line 1. >> >> I tried to install Math::BigInt on my new machine, by adding a file at >> /etc/yum.repos.d/custom.repo containing the lines: >> >> [local] >> name=Perl_module >> baseurl=http://apt.sw.be/redhat/el5/en/i386/rpmforge/ >> enabled=1 >> gpgcheck=0 >> >> and then running "yum install Math::BigInt", but it just goes through a >> lot of spew and then ends with this error: >> >> >>> >> Transaction Check Error: >> file /usr/share/man/man3/Math::BigFloat.3pm.gz from install of >> perl-Math-BigIn >> t-1.89-1.el5.rf.noarch conflicts with file from package >> perl-5.8.8-41.el5.i386 >> file /usr/share/man/man3/Math::BigInt.3pm.gz from install of >> perl-Math-BigInt- >> 1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i386 >> file /usr/share/man/man3/Math::BigInt::Calc.3pm.gz from install of >> perl-Math-B >> igInt-1.89-1.el5.rf.noarch conflicts with file from package >> perl-5.8.8-41.el5.i3 >> 86 >> file /usr/share/man/man3/Math::BigInt::CalcEmu.3pm.gz from install of >> perl-Mat >> h-BigInt-1.89-1.el5.rf.noarch conflicts with file from package >> perl-5.8.8-41.el5 >> .i386 >> >> Error Summary >> >>> >> >> Both servers have Math::BigInt 1.77 installed. As far as I can tell, the >> reason the error occurs on the new server but not on the old server, is >> because on the old server the place that Math::BigInt is loaded is in >> the file /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm which contains the line: >> use Math::BigInt; >> whereas on the new server, Math::BigInt is loaded in the file >> /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm which contains >> the line: >> use Math::BigInt 1.78 try => 'GMP, Pari'; >> >> However, that's where my "expertise", such as it is, runs out. I have no >> idea why the two machines even attempt to load Math::BigInt in two >> different ways since I don't remember installing things differently on >> them. I would like to fix the problem on the new machine in the cleanest >> possible way (i.e., not just commenting out the "1.78" in the line "use >> Math::BigInt 1.78" -- I don't think that would be the "clean" solution!). >> >> Any idea what to do? >> >> Bennett >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] trouble installing Math::BigInt module
I had to move a perl script from an old server to a new one. Both the old and new servers are running "CentOS release 5.10 (Final)" and perl v5.8.8. (But the problem I'm running into appears to be a package management problem and not a Perl problem which is why I'm posting it to a CentOS list.) The line of code in the script that attempts to open a Net::SFTP connection, which was working fine on the old machine, no longer works on the new machine. I've tracked it down to the module Net::SSH::Perl::Key::DSA not loading correctly on the new machine. On the old one, the line: perl -e "use Net::SSH::Perl::Key::DSA;" gives no error and no output (as expected), but on the new machine, the same line gives: www:/var/www/html/circumventor# perl -e "use Net::SSH::Perl::Key::DSA;" Math::BigInt version 1.78 required--this is only version 1.77 at /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm line 4. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA.pm line 7. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/Net/SSH/Perl/Key/DSA.pm line 14. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I tried to install Math::BigInt on my new machine, by adding a file at /etc/yum.repos.d/custom.repo containing the lines: [local] name=Perl_module baseurl=http://apt.sw.be/redhat/el5/en/i386/rpmforge/ enabled=1 gpgcheck=0 and then running "yum install Math::BigInt", but it just goes through a lot of spew and then ends with this error: >>> Transaction Check Error: file /usr/share/man/man3/Math::BigFloat.3pm.gz from install of perl-Math-BigIn t-1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i386 file /usr/share/man/man3/Math::BigInt.3pm.gz from install of perl-Math-BigInt- 1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i386 file /usr/share/man/man3/Math::BigInt::Calc.3pm.gz from install of perl-Math-B igInt-1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5.i3 86 file /usr/share/man/man3/Math::BigInt::CalcEmu.3pm.gz from install of perl-Mat h-BigInt-1.89-1.el5.rf.noarch conflicts with file from package perl-5.8.8-41.el5 .i386 Error Summary >>> Both servers have Math::BigInt 1.77 installed. As far as I can tell, the reason the error occurs on the new server but not on the old server, is because on the old server the place that Math::BigInt is loaded is in the file /usr/lib/perl5/vendor_perl/5.8.8/Net/IP.pm which contains the line: use Math::BigInt; whereas on the new server, Math::BigInt is loaded in the file /usr/lib/perl5/vendor_perl/5.8.8/Crypt/DSA/KeyChain.pm which contains the line: use Math::BigInt 1.78 try => 'GMP, Pari'; However, that's where my "expertise", such as it is, runs out. I have no idea why the two machines even attempt to load Math::BigInt in two different ways since I don't remember installing things differently on them. I would like to fix the problem on the new machine in the cleanest possible way (i.e., not just commenting out the "1.78" in the line "use Math::BigInt 1.78" -- I don't think that would be the "clean" solution!). Any idea what to do? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] anyone doing automatic yum updates via yum-updatesd on production servers?
On 1/17/2012 3:41 PM, Les Mikesell wrote: > On Tue, Jan 17, 2012 at 2:14 PM, P J wrote: >> Thanks for the feedback guys, I agree about best practices but it's nice to >> get direct feedback from your peers. > In general it is very, very rare for an update to break anything - > after all that is the whole point of the 'enterprise' distribution and > it is well tested upstream. However, it is still possible, especially > if you have local apps and modifications, and it is very difficult to > back out any changes the updates make so it is always best to test on > a similar system before making changes on a production box where > downtime would be a problem. For boxes that are internet exposed, > I'd consider it more dangerous to go for long intervals with no > updates than to auto-update, though. That's what I meant hen I said I thought it would be better for CentOS to have auto-updates enabled by default out of the box. Power users can always change the defaults. But for all the servers where the admin neglects the server or doesn't know enough to change it -- YES people can pontificate all they want about how those people shouldn't be server admins -- but the fact being that those servers are out there, it would seem less risky to have auto-updates turned on than to have no updates at all. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bounties for exploits against CentOS?
On 1/17/2012 9:25 AM, Les Mikesell wrote: > On Tue, Jan 17, 2012 at 11:12 AM, Bennett Haselton > wrote: >> Pretty much all software testing is predicated on this notion -- that as >> you find and fix more bugs (of any kind, not just security bugs), >> eventually the mean time to find the next bug should get larger. >> Otherwise, what's the point, if at the end of all your testing and >> fixing, users keep running into bugs at the same frequency as before? > Look though the changelogs of any major application or the kernel > itself. See if it looks like the world is running out of bugs. > Well if the software itself is constantly being modified in other ways (addition of new features) then of course you'll never run out of new bugs either :) But even for software where the features are frozen, bugs in a given category should eventually get harder to find, and/or should be less severe than at the beginning of the cycle (which seemed to be the case whenever I worked in testing). If this were not the case, then what would even be the point of doing any testing and bug-fixing at all? Unless you expect that eventually the remaining bugs become rarer or less severe. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bounties for exploits against CentOS?
On 1/17/2012 8:11 AM, Les Mikesell wrote: > On Tue, Jan 17, 2012 at 9:04 AM, Bennett Haselton > wrote: >> But there seems to be some consensus, at least, that exploits do get >> found which allow apache to run arbitrary code (even under its >> unprivileged account), > Web servers are particularly prone to this because webapps are > typically designed to map user input to some action in a fairly > flexible way (i.e.by mapping the URL to a program and its inputs) and > people can easily manipulate the URLs they send. That leaves a lot of > levels where buffer overflows or mis-parsing can let unintended code > execute. > >> and exploits do get found that elevate an >> unprivileged user to root privileges. > And it is best to assume that there are more that haven't been found... > >> So you could offer, for example, >> a bounty for anyone who finds a way to elevate the privilege of an >> unprivileged account. That's a lot less powerful than a complete >> exploit that can be used against any server on the Internet, but it's >> the kind of thing an attacker might use as part of a larger exploit. So >> would you feel safer using CentOS/Red Hat if Red Hat, for example, >> offered a prize to anyone who could find a privilege-escalation exploit >> like that? Knowing that it would reduce the chance of a black hat >> finding the exploit and using it as part of an attack? > You'll never know when the last bug is found. Well I'm assuming there is no "last bug"; rather, that as more and more bugs are found and fixed, the mean time to find the next one will get measurably larger. Pretty much all software testing is predicated on this notion -- that as you find and fix more bugs (of any kind, not just security bugs), eventually the mean time to find the next bug should get larger. Otherwise, what's the point, if at the end of all your testing and fixing, users keep running into bugs at the same frequency as before? The idea is that if you find and fix enough of them, eventually the mean time to find the next one, and hence the cost of finding the next one, will exceed the black-market value of the exploit, so it's no longer profitable for black hats to go looking for them. On the other hand, it is conceivable that above a certain effort-threshold, the number of exploits to be found is essentially unlimited. Maybe at the $25,000 level, the number of bugs to be found is so large, that no matter how many are found and fixed, the mean time to find the next one will always average about $25,000. Meanwhile, if the black-market value of an exploit is more than that (say, $50,000), then the black hats will *never* run out of exploits. This would have the unfortunate implication that not only is there no point in paying out bounties at that level (since it wouldn't make it any harder for a black hat to find a new exploit), but there would be no point in finding and fixing exploits at that level at all (unless you know a particular exploit is being used in the wild) -- since it will never get any harder for a black hat to find one! > And if you don't know > that, what have you gained by painting a target on your head? > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bounties for exploits against CentOS?
On 1/16/2012 3:13 PM, Eero Volotinen wrote: >> Well I wasn't necessarily advocating it here, just asking whether people >> would feel more or less secure using CentOS if such a prize program >> existed (whether run by CentOS or RHEL), and why or why not. > Well, no. > > Usually attacks to system are caused by misconfiguration of server or > firewall or bugs in web applications *) > > *) https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Well one of the lessons of the recent threads seems to be that there is a lot of disagreement over what constitutes a "misconfigured server". Some people consider a server misconfigured if it doesn't use a firewall to limit access to sshd, some people consider it misconfigured if sshd uses passwords instead of keys, some people consider the server misconfigured if it doesn't use SELinux, etc. Because there are mutually contradictory definitions of "misconfigured", if you find out that a server was broken into you can always come up with a reason, after the fact, why the server should be considered "misconfigured", depending on whose definition you use. But there seems to be some consensus, at least, that exploits do get found which allow apache to run arbitrary code (even under its unprivileged account), and exploits do get found that elevate an unprivileged user to root privileges. So you could offer, for example, a bounty for anyone who finds a way to elevate the privilege of an unprivileged account. That's a lot less powerful than a complete exploit that can be used against any server on the Internet, but it's the kind of thing an attacker might use as part of a larger exploit. So would you feel safer using CentOS/Red Hat if Red Hat, for example, offered a prize to anyone who could find a privilege-escalation exploit like that? Knowing that it would reduce the chance of a black hat finding the exploit and using it as part of an attack? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bounties for exploits against CentOS?
On 1/16/2012 12:12 PM, John R Pierce wrote: > On 01/16/12 10:34 AM, Bennett Haselton wrote: >> With companies like Facebook and Google offering cash prizes for people >> who can find security holes in their products, has there ever been any >> consideration given to offering cash rewards to people finding security >> exploits in CentOS or in commonly bundled services like Apache? > companies like facebook and google have significant(!!) cash flow. > centos is a volunteer project. from where would this prize money come? > > you'd do better addressing this question to Redhat Enterprise Linux, > anyways, since CentOS's goal is to be a near exact copy, bugs and warts > included. Well I wasn't necessarily advocating it here, just asking whether people would feel more or less secure using CentOS if such a prize program existed (whether run by CentOS or RHEL), and why or why not. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] bounties for exploits against CentOS?
With companies like Facebook and Google offering cash prizes for people who can find security holes in their products, has there ever been any consideration given to offering cash rewards to people finding security exploits in CentOS or in commonly bundled services like Apache? (Provided of course they follow "responsible disclosure" and report the exploit to the software authors and get it fixed.) Obviously the benefit would be that it would increase the chance of a white hat finding and fixing an exploit, before a black hat discovered the same one and used it to attack people's servers. Would there be any other downsides, other than the cost of paying out the prize? I've heard some objections from companies over the years who didn't want to institute a "prize program", but I thought some of those objections didn't make much sense (and indeed some of those companies ended up instituting a prize program after all, a few years later). For example, some people said, "This just encourages people to find exploits and then they might use those exploits to do harm." (The problem with this is if someone has sufficient black-hat incentives for finding an exploit -- either to do malice, or more likely to sell it on the black market -- those incentives *already* exist, so the prize program wouldn't create any additional incentive to use an exploit illegally.) Would you feel safer using CentOS if a bounty program encouraged people to report exploits to the project? Why or why not? I think I would, for the stated reason -- newly discovered exploits are more likely to get reported and fixed, than to be used in the wild. But I'd be curious why anyone might feel less safe if such a program existed. On a related question, suppose that instead of paying for generic exploits against the operating system, you as a webmaster had the option of adding your website to a directory of "bounty" sites, where you would have to put up a bond of $100 to join. Then anyone who could prove that they broke into your server (let's say the "proof" is that they read a world-readable file in the root directory) would collect the $100 prize, if they can describe exactly how they did it and what you need to fix to prevent the attack in the future. That way, if there's ever a weakness in your server, it's more likely to be found by a white hat and reported to you directly so you can fix it, before a black hat finds the same weakness. Would you sign up your webserver? I think I would, and I believe I'd be reducing the risk of a black-hat breakin as a result, but there may be counter-arguments that I'm not thinking of. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] defense-in-depth possible for sshd?
On 1/12/2012 5:25 PM, Johnny Hughes wrote: > On 01/12/2012 10:31 AM, Tilman Schmidt wrote: >> Am 10.01.2012 19:05, schrieb Johnny Hughes: >>> Limit access to the sshd port from only authorized places ... and >>> the authorized places can be an openvpn type connection if you >>> always need access from difference IPs. If you have a laptop, put >>> an openvpn client on it and take it with you if you need access >>> from dynamic places. Connect the openvpn to the endpoint someplace >>> and then use that to connect to the sshd on the server via the >>> vpn. >> I'm not convinced that would actually improve security. >> What that does is replace the risk of intrusion via an sshd >> exploit by the risk of intrusion via an OpenVPN exploit. >> But it also adds a layer of complexity, and complexity is >> the enemy of security. So the risk of an exploitable hole >> in OpenVPN would have to be provably so much lower than in >> SSH that the difference outweighs the increase of risk >> through added complexity. I don't know of any data to >> support that claim. > Not at all ... you first have to crack the OpenVPN system to gain access > to the ssh port at all (that did not get you into the machine, it got > you an IP address that then allows you to TRY to access the machine) ... I think Tilman is saying that rather than "cracking" OpenVPN in the sense of tricking into allowing you access, you could find an exploit in OpenVPN where simply sending the right packets to the OpenVPN server would allow you to execute arbitrary code as root on the server, the same way as an attacker might try to do to the sshd server. Or is there a reason that an exploit against OpenVPN would be less powerful than an exploit against sshd? This came up earlier, and you said that OpenVPN has had far fewer such exploits logged against it than sshd. In that case it really would be more secure, but not because it provides an extra "layer", but rather simply because exploits against it are more rare. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] SELinux blocking cgi script from "writing to socket (httpd_t)"
Is this really supposed to get easier over time? :) Now my audit.log
file shows that SELinux is blocking my cgi script, index.cgi (which is
what's actually served when the user visits the front page of one of our
proxy sites like sugarsurfer.com) from having '"read write" to socket
(httpd_t)'. I have no idea what that means, except that I thought that
cgi scripts were supposed to be able to write to stdout so that the web
server could send the data via a socket connection to the end user's
browser, so I don't know why a CGI script would be blocked from writing
to a socket with security context httpd_t.
The only clue that might narrow it down is the line "Target
Objectssocket [ udp_socket ]". The sockets that the cgi
scripts usually send output to are of course tcp sockets, so why would
it say udp? The only time one of my cgi scripts might use udp would be
if it were doing a hostname lookup via dns, but the index.cgi script
doesn't do that at any point.
What would the pros do at this point?
***
Summary:
SELinux is preventing index.cgi (httpd_sys_script_t) "read write" to socket
(httpd_t).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]
SELinux denied access requested by index.cgi. It is not expected that this
access is required by index.cgi and this access may signal an intrusion
attempt.
It is also possible that the specific version or configuration of the
application is causing it to require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Contextsystem_u:system_r:httpd_sys_script_t
Target Contextsystem_u:system_r:httpd_t
Target Objectssocket [ udp_socket ]
Sourceindex.cgi
Source Path
Port
Host
Source RPM Packages
Target RPM Packages
Policy RPMselinux-policy-2.4.6-316.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing ModePermissive
Plugin Name catchall
Host Name g6950-21025.securedservers.com
Platform Linux g6950-21025.securedservers.com
2.6.18-274.12.1.el5 #1 SMP Tue Nov 29
13:37:46 EST
2011 x86_64 x86_64
Alert Count 1
First SeenWed Jan 11 09:34:13 2012
Last Seen Wed Jan 11 09:34:13 2012
Local ID 2adcd43d-7b8b-4e17-bb93-ad11a35f378a
Line Numbers 1
Raw Audit Messages
type=AVC msg=audit(1326303253.473:3626): avc: denied { read write }
for pid=6668 comm="index.cgi" path="socket:[415055]" dev=sockfs
ino=415055 scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=udp_socket
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/11/2012 5:32 AM, 夜神 岩男 wrote: > On 01/11/2012 07:19 PM, Bennett Haselton wrote: > >> Well there is already a beginner-friendly introduction: >> http://wiki.centos.org/HowTos/SELinux >> The problem I had with it is that there are several statements that are >> unclear, missing, or just wrong. That's not necessarily the fault of the >> author; if I had to write an intro to something that I knew a lot about, >> I'd probably also make a few statements that were unclear or wrong. > Tell me about it. I constantly find myself really great at writing docs > for systems that the audience is already expert in, but somewhat lacking > on writing it for complete beginners. Really, the principal problem is > one of prereqs. Teaching people on this list about SELinux is a lot > easier than teaching professional diesel mechanics about it, and a bit > harder than teaching a certain breed of security researchers about it. > So at what level is appropriate to begin the explanation? This is tricky. I agree that's always a tricky question, but I think the problem here was that even if you knew a lot about Linux but just happened to be unfamiliar with SELinux, the documentation was still incorrect in ways that the reader wouldn't be able to figure out on their own. When the doc says "Access is only allowed between similar types", you can't make head or tail of that unless you already know what it means. >> The cure for that is to show it to 10 people whose intelligence you are >> reasonably confident about, but who *don't already know* what the >> document is trying to teach, and ask them to suggest edits: anything >> that tells the user to "do something" without saying how, or is unclear, >> or doesn't work when they try it. Then when the documentation has been >> tweaked enough that it no longer has too many of those problem areas, >> then it's "ready". > This is sounds very much the way open source development works. And its > the process you're engaging in, actually. See below... Yes, for software. But I've never heard of it being done for documentation. I suspect this is for two reasons: (1) if software fails, the dev does has to bite the bullet and make it work, but if documentation "fails", it's easy to blame the user (reader); (2) to get help testing your software, you can stay within the community of people who helped right it or those closely connected to them, but to get help testing documentation, you have to reach out to people far removed from your inner circle. (Plus, in theory you can only test the document on a single person one time. You can't use them to test future iterations of the same document, because then they might incorrectly report that the document is getting "clearer" when really their understanding is just becoming clearer from multiple readings and back-and-forth with the authors.) >> (If I were a volunteer, some of my suggested edits to that page would be: >> - Near the beginning the doc says "the machine should be rebooted and >> the filesystem relabeled", without telling the user how to actually do >> that. Have a forward-reference telling the user where to read how to >> relabel the filesystem. >> - The sentence about "Access is only allowed between similar types" is >> apparently wrong (and meaningless anyway if it doesn't explain what >> "similar types" means). I would just go ahead and say that there's no >> way to know for sure what process types will be allowed to access what >> file types, and all you can do is make educated guesses based on the >> similarity of the names, and then look at error logs afterwards to see >> if you were right. >> - Explain that files in /tmp/ aren't relabeled after rebooting. (If >> indeed that is the case. We never did figure out why my /tmp/ files >> weren't being relabeled.) >> - The "genhomedircon" command gives an error if SELinux is enforcing; >> switch to permissive before running that command. >> - The doc says httpd runs in the httpd_t security context. This is only >> true if it's started silently; if the user starts it from the command >> line, it runs in a different context.) > And you should *really* cc this bit to the author. Anyway, you said it > is a wiki -- so why don't you get to wikifying instead of writing on a > mailinglist? That's the heart of the process! This is a system under > development, and as such needs your help. How great would it be for you > to document your trouble spots in learning and contribute that back? I wasn't going to get into this, but... I did find the wiki con
Re: [CentOS] SELinux and access across 'similar types'
On 1/10/2012 12:52 PM, 夜神 岩男 wrote: > On 01/11/2012 05:04 AM, Les Mikesell wrote: >> On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walsh wrote: > On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh >>wrote: >>> Now if only more people used RHEL we could further enhance >>> the products. :^) >>> >> Why isn't it accepted as more of a standard? >> > I don't understand the question. Why is it vendor-specific to RHEL? >>> I was talking Money not vendor specific. The question meant as a jab >>> was if more people used RHEL instead of Centos, we could pay more >>> developers. I thought the @redhat.com would signify why I would want >>> that. :^) >> OK, I can understand why you would want that. I don't understand why >> you think anyone else would want even more nonstandard variations in >> linux distributions. And if this isn't intended to be >> vendor-specific, why isn't it an independent upstream project or >> included in the kernel? > The logical code to SELinux isn't specific to RH, not by a long shot. > (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific > things in the near future, but that has nothing to do with SELinux) > http://userspace.selinuxproject.org/trac > http://www.gentoo.org/proj/en/hardened/selinux/ > https://wiki.ubuntu.com/SELinux > ... > > But the difficult thing about SELinux isn't how it works, its the detail > required for each policy to wrap each program up correctly without > denying useful functionality in the process, not to mention deploying > them with packages, and dealing with the whole new universe of > inaccurate bug reports SELinux has spawned... > > *That* is very hard -- and that is what Red Hat has been so good about > over the last while. In the process Fedora has spawned a slew of new > tools to make SELinux policy easier to deal with -- and in the process > of doing that Fedora acquired/affirmed its reputation for eating babies. > > SElinux exists all over the place, and there are binaries for it in > nearly every distro -- but nearly everyone has decided that "its too > hard" so its just a set of accessory packages almost nobody installs, > and if installed not activated, and if activated quickly de-activated > (the #1 web server "fix your frustrations on the web" advice for noobs > is still "disable SELinux, it sux"). > > Honestly, though, at this point the tools really are there. A packager > that wants to publish an SELinux policy with his package finds it easy > if the tools are understood -- what is really lacking now is just a very > public, beginner-friendly introduction to the core concepts of SELinux > which includes a nice intro to the somewhat arbitrary jargon that > surrounds access policy concepts. Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong. The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to "do something" without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's "ready". (If I were a volunteer, some of my suggested edits to that page would be: - Near the beginning the doc says "the machine should be rebooted and the filesystem relabeled", without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem. - The sentence about "Access is only allowed between similar types" is apparently wrong (and meaningless anyway if it doesn't explain what "similar types" means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right. - Explain that files in /tmp/ aren't relabeled after rebooting. (If indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.) - The "genhomedircon" command gives an error if SELinux is enforcing; switch to permissive before running that command. - The doc says httpd runs in the httpd_t security context. This is only true if it's started silently; if the user starts it from the command line, it runs in a different context.) It doesn't take that much work to turn so-so documentation into really useful documentation, but you have to start with the assumption that there is room for improvement. The mai
Re: [CentOS] SELinux and access across 'similar types'
On 1/9/2012 8:05 PM, Marko Vojinovic wrote: > On Monday 09 January 2012 15:29:59 Daniel J Walsh wrote: >> file_t means the file has no label, so the only way to create this >> type of file would be to remove the security attributes on the file. >> On an SELinux system, file_t should never be created, they are only >> created on a disabled SELinux system. I guess you could try to use >> chcon -t file_t on a file, but I believe the kernel will block that. >> Or you could attempt to delete the SELinux label, but that might also >> be denied. > Ok, now I think I understand. The OP has stale files in /tmp which are not > labelled, due to not purging /tmp on reboot. SELinux doesn't know how these > files should be labelled, so it doesn't even try, and gives them the type > file_t, which is a synonym for "this file doesn't have a type". > > So the answer for the OP is to use chcon on this file to label it somehow. If > that doesn't work, he should delete the file and recreate it (while SELinux is > active), so that it gets properly labelled. OK, I did delete the files in the /tmp/ directory, and as the running apache process re-created them, it created them with the correct type: [root@g6950-21025 tmp]# ls -lZ * -rw-r--r-- apache apache system_u:object_r:httpd_sys_script_rw_t hostname_ICECOOK.INFO -rw-r--r-- apache apache system_u:object_r:httpd_sys_script_rw_t hostname_LAZYFROG.INFO etc. So the documentation is missing something about clearing files out of /tmp/ (or they won't get relabeled properly and processes won't be able to access them under SELinux), but at least it's working now. Bennett > I learned something new today. :-) Thanks for the explanation! > > Best, :-) > Marko > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] defense-in-depth possible for sshd?
On 1/10/2012 5:16 AM, John Doe wrote: > From: Bennett Haselton > >> On 1/10/2012 2:02 AM, Adrian Sevcenco wrote: >>> UsePrivilegeSeparation >>> Specifies whether sshd(8) separates privileges by creating an >>> unprivileged child process to deal with incoming network traffic. >>> After successful authentication, another process will be created that >>> has the privilege of the authenticated user. The goal of privilege >>> separation is to prevent privilege escalation by containing any >>> corruption within the unprivileged processes. The default is >> ``yes''. >> OK. So it sounds like if you found a particular exploit in sshd that >> could *only* do certain things -- like write a file to an arbitrary >> location on disk -- then this privilege separation would prevent that >> exploit from being used to make the child process write somewhere that >> it didn't have privileges to write to. > Do a ps and look at the sshd tree. Example: > root 6014 0.0 0.1 97816 3760 ?S11:01 0:00 \_ sshd: > bob [priv] > bob 6029 0.0 0.0 97816 1796 ?S11:01 0:00 \_ > sshd: bob@pts/2 > bob 6030 0.0 0.0 108392 1760 pts/2Ss 11:01 0:00 \_ > -bash > > The sshd child is running as bob; so it has bob (and not root) rights... > > JD Yes, I understand that. What I said was that if you could take complete control of the sshd process you were connecting to, even if that process was completely unprivileged, you could still make it say "Accept a login from 'root' with password 'foo'" and then log in as root. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] defense-in-depth possible for sshd?
On 1/10/2012 2:02 AM, Adrian Sevcenco wrote: > On 01/10/12 11:12, Bennett Haselton wrote: >> What about sshd -- assuming that the attacker can connect to sshd at all >> (i.e. not prevented by a firewall), if they find an exploit to let them >> take control of sshd, would that imply immediate total control of the > UsePrivilegeSeparation > Specifies whether sshd(8) separates privileges by creating an > unprivileged child process to deal with incoming network traffic. > After successful authentication, another process will be created that > has the privilege of the authenticated user. The goal of privilege > separation is to prevent privilege escalation by containing any > corruption within the unprivileged processes. The default is ``yes''. > If UsePrivilegeSeparation is set to ``sandbox'' then the > pre-authentication unprivileged process is subject to additional > restrictions. > > http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 OK. So it sounds like if you found a particular exploit in sshd that could *only* do certain things -- like write a file to an arbitrary location on disk -- then this privilege separation would prevent that exploit from being used to make the child process write somewhere that it didn't have privileges to write to. On the other hand if you found an exploit that let you take complete control of sshd, you could just tell it "allow logins from root, accept 'foo' as the password, and then do whatever you were going to do before", and that would presumably work, wouldn't it? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] defense-in-depth possible for sshd?
If an attacker finds an exploit to take control of httpd, they're still blocked in part by the fact that httpd runs as the unprivileged apache user and hence can't write any root-owned files on the system, unless the attacker also knows of a second attack that lets apache escalate its privilege. Basically correct? What about sshd -- assuming that the attacker can connect to sshd at all (i.e. not prevented by a firewall), if they find an exploit to let them take control of sshd, would that imply immediate total control of the machine? Because if they can control sshd they can tell sshd, "Allow root login (even if prohibited in sshd.conf) and accept 'foo' as the password", then the attacker can log in as root. Is it possible, even in theory, to provide a second layer of defense behind sshd to prevent the attacker from controlling the machine, if the attacker controls sshd? The "log me in as root" attack would appear to imply that an extra layer is not possible. (Note I'm not talking about extra layers of security *in front* of sshd, like a firewall that only permits logins from known locations. I'm also not talking about detection after the fact -- obviously you can detect unexpected root logins from the /var/log/secure* files if the attacker doesn't erase them -- only whether you could use extra layers to *prevent* the attacker from owning the machine if they take control of sshd.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] missing email
On 1/9/2012 10:31 AM, m.r...@5-cent.us wrote: > I *loathe* dnsorbs Maybe this one will get through its crap. Maybe if > I add a few more words > > John R. Dennison wrote: >> On Mon, Jan 09, 2012 at 12:49:31PM -0500, m.r...@5-cent.us wrote: >>> I haven't gotten anything from the list since my email of 09:34 EST. Do > I have a problem, or is the list quiet? >>> Please cc me offlist, if this goes through. >> I hope you get 20,000 replies :) > Nope, jes' one, so far. > >> You _could_ just have checked the archive. > Actually, I went to the archives, and at least saw something from *sigh* > Bennett that was dated 12:34 or so today; that was why I asked. Dunno if > someone (NOT my hosting co - I don't have any filtering turned on) is > delaying, or filtering, or if I'd been dropped for some reason, or > In response to this message from *sigh* Mark, I dug up a bounce message that I got when trying to send email to this list yesterday. The bounce indicated that at the time, all mail from Gmail (or at least one particular Gmail SMTP server) was being blocked. I followed the link in the bounce message and got the IP of that SMTP server removed from the blacklist. Maybe the blacklist server had temporarly gotten into a state where it was reporting all IP addresses as spam sources (not just gmail). Or more generally, if a spam filter is so aggressive that it starts blocking all mail from Gmail, it's probably aggressive enough that it erratically blocks mail from lots of other sources as well. (If that had been the case though, you presumably would have gotten a bounce message like I did.) Here is the bounce message: Delivery to the following recipient failed permanently: centos-d...@centos.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 Service unavailable; Client host [209.85.210.179] blocked using ix.dnsbl.manitu.net; Your e-mail service was detected by mx.selfip.biz (NiX Spam) as spamming at Sun, 08 Jan 2012 22:02:35 +0100. Your admin should visit http://www.dnsbl.manitu.net/lookup.php?value=209.85.210.179 (state 14). - Original message - Received: by 10.50.153.234 with SMTP id vj10mr16576276igb.16.1326063636220; Sun, 08 Jan 2012 15:00:36 -0800 (PST) Return-Path: Received: from [192.168.1.33] (50-54-225-130.evrt.wa.frontiernet.net. [50.54.225.130]) by mx.google.com with ESMTPS id l35sm243526964ibj.0.2012.01.08.15.00.34 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 15:00:35 -0800 (PST) Sender: Bennett Haselton Message-ID: <4f0a2011.1020...@peacefire.org> Date: Sun, 08 Jan 2012 15:00:33 -0800 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/9/2012 3:41 AM, Tony Molloy wrote: > On Sunday 08 January 2012 23:19:39 Bennett Haselton wrote: >> On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote: >>> On 01/08/2012 03:15 PM, Bennett Haselton wrote: >>>> It's a file created by one of my CGI scripts. (The web server >>>> is accessed by several hostnames which are dynamically assigned >>>> to it, and I need a quick way of determining all hostnames that >>>> were recently used to access the server. So when someone >>>> accesses the server using HOSTNAME, the file >>>> /tmp/hostname_is created. Then another script >>>> just pulls the names of all of those files in order to find all >>>> recently used hostnames.) >>>> >>>>> My suggestion: >>>>> >>>>> stop apache >>>>> run relabeling again (if file continues to exists) >>>>> start apache >>>>> check >>>> Well when I was doing the relabeling I was doing: >>>> # touch /.autorelabel >>>> # reboot >>>> >>>> So when I'm rebooting apache stops and starts anyway, doesn't >>>> it? Doesn't the auto-relabel occur before other services are >>>> started up? So I'm not sure what I would actually do >>>> differently to follow this suggestion... >>> Ah, you are write, sorry. Well you might need to apply proper >>> (httpd_) SELinux label for that file. At the time of creation? \ >>> Maybe move it to another location where it will get automatic >>> label for what you want? >> Well the warning messages say that file_t files should *never* get >> created if the filesystem is labeled properly. So I didn't think >> it was just a matter of creating files where the default filetype >> would be different, because the default filetype should not be >> file_t anywhere. >> >> I could create a world-writeable directory somewhere else and have >> all the scripts write to that but it would be a pain to re-write >> and re-test everything as a workaround for this one bug... >> >> Well, one other theory: /tmp is a different partition, right? So >> maybe when I do >> # touch /.autorelabel >> # reboot >> >> it's only re-labeling the / partition and not the /tmp one? >> Unfortunately in that case I don't know how to make it re-label the >> /tmp filesystem as well. I tried creating /tmp/.autorelabel and >> rebooting, but that didn't work; /tmp/hostname_SKYSLICE.INFO and >> other files still had type file_t. >> >> Bennett >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > First I'm no SELinux expert ;-( but I've ben following this thread > with interest. It apears to be going around in circles. > > The only time I've come across a file_t type is when I have something > on a machine that SELinux doesn't know about. That is SELinux has no > policy for it. An example would be if I create a new top level > directory when I install a machine. SELinux knows nothing about that > directory name and has no preset type for it so it gets a label of > file_t or default_t. Doing a relabel in that case will have no affect on > the file label as SELinux still doesn't have a policy for it. > > So the question is how did your file get the file_t type in the first > place. You say it is generated from a cgi script run from apache. > > So is this the default apache which comes with CentOS > > What is the context of the apache executable. It should be > -rwxr-xr-x root root system_u:object_r:httpd_exec_t /usr/sbin/httpd Yes that's what I've got. > Where in the filesystem is the cgi script located. How did it get > there. > > What is the context of the cgi script > > What is the context of the directory the cgi script is in. [root@g6950-21025 ~]# ls -lZ /var/www/cgi-bin/capture.cgi -rwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/capture.cgi [root@g6950-21025 ~]# ls -ldZ /var/www/cgi-bin/ drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/ The script got there because I uploaded it there. > What is the context of /tmp. It should be > drwxrwxrwt root root system_u:object_r:tmp_t /tmp Yep. [root@g6950-21025 ~]# ls -ldZ /tmp drwxrwxrwt root root system_u:object_r:tmp_t /tmp > Regards > > Tony > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/8/2012 7:28 AM, Ljubomir Ljubojevic wrote: > On 01/08/2012 03:15 PM, Bennett Haselton wrote: >> It's a file created by one of my CGI scripts. (The web server is >> accessed by several hostnames which are dynamically assigned to it, and >> I need a quick way of determining all hostnames that were recently used >> to access the server. So when someone accesses the server using >> HOSTNAME, the file /tmp/hostname_ is created. Then another >> script just pulls the names of all of those files in order to find all >> recently used hostnames.) >>> My suggestion: >>> >>> stop apache >>> run relabeling again (if file continues to exists) >>> start apache >>> check >> Well when I was doing the relabeling I was doing: >> # touch /.autorelabel >> # reboot >> >> So when I'm rebooting apache stops and starts anyway, doesn't it? >> Doesn't the auto-relabel occur before other services are started up? So >> I'm not sure what I would actually do differently to follow this >> suggestion... > Ah, you are write, sorry. Well you might need to apply proper (httpd_) > SELinux label for that file. At the time of creation? \ > Maybe move it to another location where it will get automatic label for > what you want? Well the warning messages say that file_t files should *never* get created if the filesystem is labeled properly. So I didn't think it was just a matter of creating files where the default filetype would be different, because the default filetype should not be file_t anywhere. I could create a world-writeable directory somewhere else and have all the scripts write to that but it would be a pain to re-write and re-test everything as a workaround for this one bug... Well, one other theory: /tmp is a different partition, right? So maybe when I do # touch /.autorelabel # reboot it's only re-labeling the / partition and not the /tmp one? Unfortunately in that case I don't know how to make it re-label the /tmp filesystem as well. I tried creating /tmp/.autorelabel and rebooting, but that didn't work; /tmp/hostname_SKYSLICE.INFO and other files still had type file_t. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/8/2012 5:36 AM, Ljubomir Ljubojevic wrote: > On 01/08/2012 02:10 PM, Marko Vojinovic wrote: >>> [root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# >> Well... >> >> With this output I would say that your policy has been customized to have >> file_t as the default label for that file. Have you used audit2allow on that >> machine before the filesystem was properly relabeled? > That file is in the /tpm folder, used by apache. I guess that apache was > not stopped since/during relabeling so it stayed. It's a file created by one of my CGI scripts. (The web server is accessed by several hostnames which are dynamically assigned to it, and I need a quick way of determining all hostnames that were recently used to access the server. So when someone accesses the server using HOSTNAME, the file /tmp/hostname_ is created. Then another script just pulls the names of all of those files in order to find all recently used hostnames.) > My suggestion: > > stop apache > run relabeling again (if file continues to exists) > start apache > check Well when I was doing the relabeling I was doing: # touch /.autorelabel # reboot So when I'm rebooting apache stops and starts anyway, doesn't it? Doesn't the auto-relabel occur before other services are started up? So I'm not sure what I would actually do differently to follow this suggestion... ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 6:25 PM, Gordon Messmer wrote: > On 01/06/2012 01:36 AM, Bennett Haselton wrote: >> So I still don't know: after creating /.autorelabel (and verifying that >> it's there), and rebooting the system (and then verifying that the >> /.autorelabel file has been deleted, which is supposed to mean the >> auto-relabel actually happened), why am I still seeing the file type >> listed as file_t? > Either SELinux is disabled or your filesystem doesn't support extended > attributes. [root@g6950-21025 ~]# sestatus SELinux status: enabled SELinuxfs mount:/selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file:targeted (same thing happens if I switch to "enforcing", although then things start breaking instead of logging warnings) > Check /proc/cmdline to see if the kernel was instructed to disable > SELinux [root@g6950-21025 ~]# cat /proc/cmdline ro root=/dev/sys-0n1f/root Not sure what that means but I assume it doesn't force SELinux to be disabled. > and check /etc/sysconfig/selinux. [root@g6950-21025 ~]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted [root@g6950-21025 ~]# Note: SELinux is logging warnings (while in permissive mode) to /var/log/audit/audit.log whenever httpd interacts with one of the files like /tmp/hostname_SKYSLICE.INFO . Presumably that means it's not disabled; SELinux is on, but the file still hasn't been relabeled. > Check /proc/mounts to see what filesystem type your system is using. [root@g6950-21025 ~]# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 /dev /dev tmpfs rw 0 0 /proc /proc proc rw 0 0 /sys /sys sysfs rw 0 0 none /selinux selinuxfs rw 0 0 /proc/bus/usb /proc/bus/usb usbfs rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sys-0n1f/vartmp /var/tmp ext3 rw,nosuid,noexec,data=ordered 0 0 /dev/sys-0n1f/tmp /tmp ext3 rw,nosuid,noexec,data=ordered 0 0 /dev/sda1 /boot ext3 rw,data=ordered 0 0 tmpfs /dev/shm tmpfs rw,nosuid,noexec 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 /etc/auto.misc /misc autofs rw,fd=7,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0 -hosts /net autofs rw,fd=13,pgrp=2217,timeout=300,minproto=5,maxproto=5,indirect 0 0 > Use "tune2fs -l" to see if an ext3/4 filesystem has the "user_xattr" option. > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos In the output above, /dev/root /dev/sys-0n1f/vartmp /dev/sys-0n1f/tmp /dev/sda1 were all listed as ext3, and when I ran "tune2fs -l" on each of them, the output included the line Default mount options:user_xattr acl Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 7:49 PM, Marko Vojinovic wrote: > On Saturday 07 January 2012 17:23:57 Bennett Haselton wrote: >> [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO >> -rw-r--r-- apache apache system_u:object_r:file_t >> /tmp/hostname_SKYSLICE.INFO >> >> Any ideas? > What does > > # restorecon -v /tmp/hostname_SKYSLICE.INFO > > return? No output, and then the file type is the same as before: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# restorecon -v /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO [root@g6950-21025 ~]# ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 9:41 AM, Marko Vojinovic wrote: > On Saturday 07 January 2012 08:15:35 Bennett Haselton wrote: >> On 1/7/2012 6:50 AM, Marko Vojinovic wrote: >>> On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote: >>>> Apparently the marketplace favors hosting companies turning SELinux >>>> off >>>> because the failures it causes are too obscure and it causes too many >>>> support headaches. >>> Ignorance is bliss... ;-) >>> >>> A hosting company should certainly have SELinux turned on by default. A >>> customer who doesn't know how to handle it should be told to RTFM. >> See what I wrote to John about "should-statements"... you can't change >> human nature, but you can make better defaults. > What do you mean by "better" defaults? Better for the user, or better for the > hosting company? Better in terms of quality/security, or better in terms of > ease of use? > > There is no obvious "better" default, IMHO. This is about trading security for > convenience, and if a hosting company puts convenience before security, they > are doing a lousy job. Turning off SELinux is a choice that should be done by > the *customer*, not by the hosting company. > > I am still waiting for the day when SELinux will become completely mandatory, > just as the owner/group permissions are today. ;-) > >>> Sometimes there is a message on stderr about "permission denied" or >>> such. But in general every AVC denial is written in >>> /var/log/audit/audit.log. There are also setroubleshootd and sealert, >>> to help you "translate" the AVC denial into something more >>> user-friendly, and suggest what to do about it. >> Yes, once you know that SELinux is the cause, the tools for diagnosing >> what to do are pretty helpful. But what hosting companies care about -- >> in terms of inconvenience to the user -- is that there's no easy way to >> find out for the first time that SELinux is the cause of something not >> working. >> >> Hence the idea for having SELinux send messages to the terminal saying >> "SELinux blocked such-and-such". There's probably some better way. > Well, when something gets blocked by iptables, that doesn't even get into a > log, let alone interactive messages. An administrator needs to be intelligent > enough to *guess* that the app doesn't work because some port might be closed > by the firewall. That's even worse than the situation with SELinux, and nobody > has ever "fixed" that one in decades. :-) Well, yes there would be fewer usability issues if it did send a message to the user. Although, a firewall is something that a user might be more likely to guess about, because firewalls exist on every OS and have for a long time, but SELinux is Linux-only and apparently only one some distros. > I guess it could be easily implemented, though. All AVC denials are being > communicated via dbus, and can probably be caught and sent to a terminal as > well. Read man audispd and related stuff --- I guess one can customize the > relevant log daemon to send messages to the terminal too, in addition to the > log file. > > If you manage to customize it, send us the recipe, I guess it could be helpful > for others as well. :-) > I don't need it for myself, now that I know to look in the logs :) The point was to make it more discoverable for users who may not realize it's turned on and why their new server app isn't working. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 9:58 AM, John R. Dennison wrote: > On Sat, Jan 07, 2012 at 09:09:45AM -0800, Bennett Haselton wrote: >> OK, I followed the instructions at >> http://wiki.centos.org/HowTos/SELinux >> for re-labeling the filesystem and it did not work. Why not? Since you >> said you had "no issues" figuring it out. > It "did not work" _how_? How did it fail? What was on the console > during the relabel? > > I've never had a relabel fail. YMMV. > I've posted several messages about this, but to sum up the current state of the problem: This is a remotely hosted machine so I don't know what's coming up on the console. But ls -lZ reports several files of type "file_t", such as: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO sealert says that a file_t filetype means the relabel failed: >>> Summary: SELinux is preventing access to files with the label, file_t. Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux permission checks on files labeled file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system. Allowing Access: You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot" >>> So, I ran the "touch /.autorelabel; reboot" commands but that didn't fix it. Then I read at http://wiki.centos.org/HowTos/SELinux that sometimes this isn't enough if the machine has been upgraded from an old CentOS version, so I ran # genhomedircon # touch /.autorelabel # reboot but that still didn't fix it as I still get: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO Daniel suggested running "fixfiles restore", which I did, and got this output: >>> [root@g6950-21025 ~]# fixfiles restore /sbin/setfiles: labeling files under / *** ***matchpathcon_filespec_eval: hash table stats: 98376 elements, 30515/65536 buckets used, longest chain length 18 /sbin/setfiles: labeling files under /var/tmp matchpathcon_filespec_eval: hash table stats: 2 elements, 2/65536 buckets used, longest chain length 1 /sbin/setfiles: labeling files under /tmp matchpathcon_filespec_eval: hash table stats: 19 elements, 19/65536 buckets used, longest chain length 1 /sbin/setfiles: labeling files under /boot matchpathcon_filespec_eval: hash table stats: 44 elements, 44/65536 buckets used, longest chain length 1 /sbin/setfiles: Done. >>> and I rebooted for good measure, but I still get: [root@g6950-21025 ~]# ls -lZ /tmp/hostname_SKYSLICE.INFO -rw-r--r-- apache apache system_u:object_r:file_t /tmp/hostname_SKYSLICE.INFO Any ideas? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 6:19 AM, John R. Dennison wrote: > I'm truly sick of the "*cry* selinux makes things _hard_ *cry*" > whining from not only users but hosting providers and alleged > "administrators" that are, at the root of it, too lazy to figure out > how to properly use selinux and similar technologies. I'm not a rocket > scientist and yet _I_ have no issues figuring it out. OK, I followed the instructions at http://wiki.centos.org/HowTos/SELinux for re-labeling the filesystem and it did not work. Why not? Since you said you had "no issues" figuring it out. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 6:50 AM, Marko Vojinovic wrote: > On Saturday 07 January 2012 05:39:15 Bennett Haselton wrote: >> On 1/7/2012 5:25 AM, John R. Dennison wrote: >>> On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote: >>>> Virtually every hosting company I've ever bought a CentOS server from >>>> has had SELinux turned off by default. (So, a partial list would >>>> include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), >>>> AeroVPS (sells dedicated servers despite their name), Netelligent, >>>> ServerBeach and I don't remember all the others). Don't hold me to >>>> that >>>> list 100% since some might have changed their policies for new servers >>>> but it's pretty universal. >>> Then these companies should be universally boycotted as it's pretty >>> evident that they don't place security at the top of the importance >>> stack. >>> >>> People that don't run selinux deserve _everything_ they get and then >>> some. > [snip] >> Apparently the marketplace favors hosting companies turning SELinux off >> because the failures it causes are too obscure and it causes too many >> support headaches. > Ignorance is bliss... ;-) > > A hosting company should certainly have SELinux turned on by default. A > customer who doesn't know how to handle it should be told to RTFM. See what I wrote to John about "should-statements"... you can't change human nature, but you can make better defaults. > If they > don't want to deal with SELinux, they can easily turn it off themselves (at > their own responsibility). > > This is analogous to having a rent-a-car agency renting cars without safety > belts, because "they are inconvenient for the users and most people don't put > them on anyway". Being irresponsible cannot be justified with what marketplace > does or does not favor. > >> A non-changing-human-nature solution might be to >> notify the user directly when SELinux blocks something. The GUI >> apparently already does this via a dialog box when viewing a desktop; >> perhaps there's a way to do it on the command line too. (When the user >> runs something that's blocked by SELinux, just send a message to the >> terminal saying "SELinux blocked this", or something. Would be a start.) > Sometimes there is a message on stderr about "permission denied" or such. But > in general every AVC denial is written in /var/log/audit/audit.log. There are > also setroubleshootd and sealert, to help you "translate" the AVC denial into > something more user-friendly, and suggest what to do about it. > Yes, once you know that SELinux is the cause, the tools for diagnosing what to do are pretty helpful. But what hosting companies care about -- in terms of inconvenience to the user -- is that there's no easy way to find out for the first time that SELinux is the cause of something not working. Hence the idea for having SELinux send messages to the terminal saying "SELinux blocked such-and-such". There's probably some better way. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 5:57 AM, Marko Vojinovic wrote: > On Saturday 07 January 2012 04:43:31 Bennett Haselton wrote: >> On 1/7/2012 4:16 AM, Marko Vojinovic wrote: >>> IMHO, if a hosting company does that sort of things (especially turning >>> off SELinux), I wouldn't touch them with a ten-foot pole. Who knows >>> what else they might have customized, in their infinite wisdom... :-) >>> >>> Care to share the name of that hosting company? >> Virtually every hosting company I've ever bought a CentOS server from >> has had SELinux turned off by default. (So, a partial list would >> include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), >> AeroVPS (sells dedicated servers despite their name), Netelligent, >> ServerBeach and I don't remember all the others). Don't hold me to that >> list 100% since some might have changed their policies for new servers >> but it's pretty universal. >> >> What hosting company sells sub-$100 unmanaged CentOS dedicated servers >> and *doesn't* have SELinux turned off? > I wouldn't know, I don't use such services (typically I have my production > systems on my own hardware). And now that you say most of them turn SELinux > off > by default, I am discuraged to even consider having my system hosted by such > companies... ;-) > >>>> As for the original question -- when the docs say that access is >>>> allowed >>>> only across "similar types", what determines what counts as "similar >>>> types"? How do you know for example that httpd running as type >>>> httpd_t >>>> can access /var/www/html/robots.txt which has type >>>> httpd_sys_content_t? >>> AFAIK, the interactions between various labels (ie. rules "who can >>> access >>> what") are determined by the SELinux targeted policy (the >>> selinux-policy- >>> targeted package). These rules evolve over time (the package sometimes >>> gets updated and your filesystem autorelabeled to match), and IIRC they >>> can get pretty complicated. You want to look inside that package to >>> find all the rules. >> OK. Is it easy to "look inside the package" and where would I look? > Well, a "rpm -ql selinux-policy-targeted" lists a whole bunch of files, mostly > all residing under /etc/selinux/targeted/ directory. So you can take a look at > what is in there. If that is not enough (ie. if you want to look "inside" the > binary modules), you'll probably want to read the corresponding srpm. Use the > Source, Luke! ;-) > > Btw, your question is about some quite low-level-inside-guts of the SELinux > policy. I cannot imagine why you would want to know the detailed relationships > between labels, unless you are a SELinux developer. Or is it just curiosity? I think it's because the doc page said "Access is allowed only between similar types" and I took that to mean that I should look at the type of a process and the type of a file to figure out if something was going to be allowed, if writing a script to do something unusual and hoping for it to work under SELinux. However, maybe the more useful answer is that because SELinux's error reporting is so thorough and human-readable -- you can convert every error message into a mini-article using audit2allow or sealert, telling you exactly what to do -- that you don't need to code "defensively", you can just run a program, see what errors are logged, and look at the report to see exactly what needs to be changed. This takes some getting used to since SELinux is the only thing I've seen that comes with tools to explain its error messages so helpfully. Everything else, the error messages are usually so obscure that it's easier to code defensively and follow guidelines for what you know *will* work. > HTH, :-) > Marko > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 5:25 AM, John R. Dennison wrote: > On Sat, Jan 07, 2012 at 04:43:31AM -0800, Bennett Haselton wrote: >> Virtually every hosting company I've ever bought a CentOS server from >> has had SELinux turned off by default. (So, a partial list would >> include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), >> AeroVPS (sells dedicated servers despite their name), Netelligent, >> ServerBeach and I don't remember all the others). Don't hold me to that >> list 100% since some might have changed their policies for new servers >> but it's pretty universal. > Then these companies should be universally boycotted as it's pretty > evident that they don't place security at the top of the importance > stack. > > People that don't run selinux deserve _everything_ they get and then > some. I remember the same attitude around 2000 and earlier, towards people who spread viruses on Windows. The attitude was that people "should" just learn about their OS (in particular, what types of actions were likely to get you infected), and it wasn't anyone else's "responsibility" to work around it. And the problem kept getting worse. Then there seemed to be a sea change in attitudes toward the problem -- the realization that complaining about human nature was not going to do any good, and if the marketplace favored selling machines to people who were not highly computer-literate, it was going to happen. Making value judgments about what people "should" and "should not" do, did about as much good as complaining about the sun coming up in the morning. So an effort was made to change *default* behaviors so that computers would not do bone-headed things even in the hands of bone-headed users. Email servers started scanning for viruses, email programs started giving more and scarier warnings about opening executable attachments, ISPs started bundling anti-virus software, etc. (All of these things were already on the rise, of course.) And that rolled the problem back a bit. Not complaining about what people "should" know, which never had a chance of working, but changing default behaviors to take into account the fact that most people did not know what the gurus think everyone "should" know. (Of course attackers didn't go away, but switched to trickier methods like browser exploits, which will work even on sophisticated users.) What you think people "should" know is a matter of opinion. However, complaining about what people "should" know, usually doesn't do any good, and that's an empirical fact, not an opinion. Apparently the marketplace favors hosting companies turning SELinux off because the failures it causes are too obscure and it causes too many support headaches. A non-changing-human-nature solution might be to notify the user directly when SELinux blocks something. The GUI apparently already does this via a dialog box when viewing a desktop; perhaps there's a way to do it on the command line too. (When the user runs something that's blocked by SELinux, just send a message to the terminal saying "SELinux blocked this", or something. Would be a start.) > By the way, please learn how to properly respond to a public mailing > list by trimming unnecessary response content. Nobody else was trimming. When in Rome :) (By definition, a quoted-quoted-quoted message can only keep getting longer if nobody else is trimming either.) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/7/2012 4:16 AM, Marko Vojinovic wrote: > On Friday 06 January 2012 18:27:05 Bennett Haselton wrote: >> On 1/6/2012 6:16 PM, RILINDO FOSTER wrote: >>> On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote: >>>> I'm pretty sure this machine was never "upgraded to CentOS 5.2", it >>>> was >>>> just imaged with 5.7 when the hosting company set it up, but SELinux >>>> *was* off until I turned it on. So probably the doc should say, if >>>> the >>>> "system was *installed* with 5.2, then do this" (and presumably it's >>>> 5.2 >>>> or later, not just 5.2). >>> Either that, or the base install was an earlier version of Centos 5.x, >>> with SELinux turned off then upgraded to the current version.> >> Could be in theory but if the hosting company was provisioning a new >> machine I don't know why they'd set up an earlier version and then >> upgrade, instead of just imaging the latest version at the time. > How about --- the hosting company installs CentOS once (the 5.2 version) as > their master image, turns off SELinux, and keeps updating the image over time? > And when a customer asks for a new machine, they just make a copy of the > current state of the master image? I guess that would be much easier (for > them), compared to actually installing the latest version of CentOS from > scratch, for every customer. > > Why don't you ask the hosting company exactly what kind of system did they > provide to you? Since SELinux was off by default, it certainly is not just a > default installation of CentOS 5.7 (nor any other version of CentOS). They > obviously made some manual after-install customizations before they handed you > the system. > > IMHO, if a hosting company does that sort of things (especially turning off > SELinux), I wouldn't touch them with a ten-foot pole. Who knows what else they > might have customized, in their infinite wisdom... :-) > > Care to share the name of that hosting company? Virtually every hosting company I've ever bought a CentOS server from has had SELinux turned off by default. (So, a partial list would include FDCServers, Superb.net, SiteGenie, SecuredServers (ho, ho), AeroVPS (sells dedicated servers despite their name), Netelligent, ServerBeach and I don't remember all the others). Don't hold me to that list 100% since some might have changed their policies for new servers but it's pretty universal. What hosting company sells sub-$100 unmanaged CentOS dedicated servers and *doesn't* have SELinux turned off? >> As for the original question -- when the docs say that access is allowed >> only across "similar types", what determines what counts as "similar >> types"? How do you know for example that httpd running as type httpd_t >> can access /var/www/html/robots.txt which has type httpd_sys_content_t? > AFAIK, the interactions between various labels (ie. rules "who can access > what") are determined by the SELinux targeted policy (the selinux-policy- > targeted package). These rules evolve over time (the package sometimes gets > updated and your filesystem autorelabeled to match), and IIRC they can get > pretty complicated. You want to look inside that package to find all the > rules. OK. Is it easy to "look inside the package" and where would I look? > But in usual circumstances you shouldn't need to know any details, just let > the system label the files as they are supposed to be labeled, and everything > should Just Work (tm). If you need to customize something, you can use > semanage&restorecon to override the default policy. > > HTH, :-) > Marko > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 6:16 PM, RILINDO FOSTER wrote: > On Jan 6, 2012, at 10:35 AM, Bennett Haselton wrote: > >> I tried that and it worked -- the httpd processes are now listed with >> "httpd_t" as their context, the /var/log/audit/audit.log file is listed >> with auditd_log_t as its type instead if file_t, etc. >> >> I'm pretty sure this machine was never "upgraded to CentOS 5.2", it was >> just imaged with 5.7 when the hosting company set it up, but SELinux >> *was* off until I turned it on. So probably the doc should say, if the >> "system was *installed* with 5.2, then do this" (and presumably it's 5.2 >> or later, not just 5.2). > Either that, or the base install was an earlier version of Centos 5.x, with > SELinux turned off then upgraded to the current version. > > - Rilindo Could be in theory but if the hosting company was provisioning a new machine I don't know why they'd set up an earlier version and then upgrade, instead of just imaging the latest version at the time. As for the original question -- when the docs say that access is allowed only across "similar types", what determines what counts as "similar types"? How do you know for example that httpd running as type httpd_t can access /var/www/html/robots.txt which has type httpd_sys_content_t? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 7:13 AM, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/06/2012 09:57 AM, Bennett Haselton wrote: >> On 1/6/2012 5:55 AM, RILINDO FOSTER wrote: >>> On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote: >>> >>>> Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit: >>>> >>>>> On 1/6/2012 4:11 AM, Philippe Naudin wrote: >>>>>> Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit: >>>>>> >>>>>>> On 1/6/2012 2:24 AM, Philippe Naudin wrote: >>>>>>>> Apache running as "init_t" is a call for troubles. >>>>>>> Is it? OK, any idea what caused that and how to fix it? >>>>>> No, sorry. Your httpd comes from CentOS ? >>>>> Yes >>>>>> Afaik, you should not have any process running in context >>>>>> init_t except init itself. If "ps awuxZ | grep [i]nit_t" >>>>>> returns more than only init and httpd, your problem is >>>>>> likely to be more complicated than a broken configuration >>>>>> of apache. >>>>> I've got a few... >>>>> >>>>> [root@g6950-21025 ~]# ps auwxZ | grep init_t >>>>> system_u:system_r:init_troot 1 0.6 0.0 >>>>> 10368 712 ?Ss 04:17 0:00 init [3] >>>>> >>>>> system_u:system_r:init_troot 537 0.2 0.1 >>>>> 13728 1976 ?S>>>> system_u:system_r:init_troot 1684 0.0 0.0 >>>>> 38880 456 ?Ssl 04:18 0:00 brcm_iscsiuio >>>>> system_u:system_r:init_troot 1690 0.0 0.0 >>>>> 12152 476 ?Ss 04:18 0:00 iscsid >>>>> system_u:system_r:init_troot 1691 0.0 0.4 >>>>> 12648 4460 ?S>>>> system_u:system_r:init_tdbus 2081 0.0 0.1 >>>>> 31520 1144 ?Ssl 04:18 0:00 dbus-daemon --system >>>>> system_u:system_r:init_troot 2215 0.0 0.1 >>>>> 52372 1492 ?Ssl 04:18 0:00 automount >>>>> system_u:system_r:init_troot 2254 0.0 0.1 >>>>> 62656 1212 ?Ss 04:18 0:00 /usr/sbin/sshd >>>>> system_u:system_r:init_tntp 2273 0.0 0.4 >>>>> 23412 5044 ?SLs 04:18 0:00 ntpd -u ntp:ntp -p >>>>> /var /run/ntpd.pid -g system_u:system_r:init_troot >>>>> 2287 0.1 1.0 253312 10580 ?Ss 04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2315 0.3 1.3 259488 13376 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2316 0.0 1.0 257436 11124 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2317 0.1 1.1 257436 11288 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2318 0.1 1.1 257436 11292 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2319 0.0 1.0 256720 10504 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2320 0.1 1.0 257436 10752 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2321 0.0 1.1 257436 11272 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_tapache >>>>> 2322 0.1 1.1 257436 11356 ?S04:18 0:00 >>>>> /usr/sbin/httpd system_u:system_r:init_troot >>>>> 2386 0.0 0.0 3812 492 tty1 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty1 system_u:system_r:init_troot >>>>> 2387 0.0 0.0 3812 488 tty2 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty2 system_u:system_r:init_troot >>>>> 2390 0.0 0.0 3812 488 tty3 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty3 system_u:system_r:init_troot >>>>> 2392 0.0 0.0 3812 492 tty4 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty4 system_u:system_r:init_troot >>>>> 2394 0.0 0.0 3812 488 tty5 Ss+ 04:18 0:00 >>>>> /sbin/mingetty tty5 system_u:system_r:init_troot >>>>> 2397 0.0 0.0 3812 488 tty6 Ss+
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 5:58 AM, RILINDO FOSTER wrote: > On Jan 5, 2012, at 7:37 PM, Bennett Haselton wrote: > >> On 1/5/2012 3:14 PM, RILINDO FOSTER wrote: >>> On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote: >>> >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> On 01/05/2012 04:36 PM, Bennett Haselton wrote: >>>>> http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed >>>>> between similar types, so Apache running as httpd_t can read >>>>> /var/www/html/index.html of type httpd_sys_content_t." >>>>> >>>>> however the doc doesn't define what "similar types" means. I >>>>> assumed it just meant "beginning with the same prefix". However >>>>> that can't be right because on my system with SELinux turned on, >>>>> httpd runs as type init_t: >>>>> >>>>> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >>>>> system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 >>>>> 8820 ?Ss 05:05 0:00 /usr/sbin/httpd >>>>> system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 >>>>> 8920 ?S05:05 0:00 /usr/sbin/httpd >>>>> system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 >>>>> 8212 ?S05:05 0:00 /usr/sbin/httpd >>>>> >>>>> and the robots.txt file has type file_t: [root@peacefire04 - /root >>>>> # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root >>>>> system_u:object_r:file_t:s0 /var/www/html/robots.txt >>>>> >>>>> but Apache can of course access that file. So in Type Enforcement, >>>>> what determines what process type can access what file type? >>>>> >>>>> Bennett ___ CentOS >>>>> mailing list CentOS@centos.org >>>>> http://lists.centos.org/mailman/listinfo/centos >>>> Your machine needs to be relabeled. >>>> >>>> touch /.autorelabel >>>> reboot >>>> -BEGIN PGP SIGNATURE- >>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>>> >>>> iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 >>>> lFkAnjLTi3zphekGomv04ZyMu0sOuopg >>>> =cIvM >>>> -END PGP SIGNATURE- >>>> ___ >>>> CentOS mailing list >>>> CentOS@centos.org >>>> http://lists.centos.org/mailman/listinfo/centos >>> WARNING: If you have never enabled SELinux for long time, the boot is going >>> to take a while as the system relabels the whole machine. Do not do this >>> unless you can plan for an extend downtime. >>> >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> I did do >> touch /.autorelabel >> reboot >> >> The machine booted back up in just a few minutes, what looked like >> normal reboot time. And then I ran the same commands as before and got >> what looks to me like the same output: >> >> [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt >> -rw-rw-rw- root root system_u:object_r:file_t:s0 >> /var/www/html/robots.txt >> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >> system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 >> ?Ss 16:23 0:00 /usr/sbin/httpd >> system_u:system_r:init_t:s0 apache2558 0.8 0.8 28308 16392 >> ?S16:23 0:03 /usr/sbin/httpd >> system_u:system_r:init_t:s0 apache2560 0.5 0.5 23248 10236 >> ?S16:23 0:02 /usr/sbin/httpd >> >> So I'm wondering: >> 1) How did you know that the machine needed to be relabeled, was it >> something in the output of the commands the first time I ran them? and >> in that case, >> 2) Why didn't it change after I created /.autorelabel and rebooted? >> (I can confirm the file /.autorelabel is no longer present, so it must >> have been deleted when the auto-relabel was done, like the doc says.) >> 3) If the machine booted back up very quickly, should I be worried that >> the autorelabel might not have happened? Any idea if it logs a message >> somewhere if it fails to start properly? >> ___ >> > That sort of sound like a good thing. I would suggest that you do: > > tail -f /var/log/audit/audit.log | audit2allow > > To see what type of alerts you are getting. Likely you will get a lot, as > some of the file contexts may not be labeled correctly. I did that but it produces descriptions all beginning with "Summary: SELinux is preventing access to files with the label, file_t." In other words, it's describing errors that are the result of the relabeling failure, but it doesn't appear to say anything about what *caused* the relabeling failure (or if it does it's buried in so many other errors I don't know how to find it). Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 5:55 AM, RILINDO FOSTER wrote: > On Jan 6, 2012, at 7:40 AM, Philippe Naudin wrote: > >> Le ven 06 jan 2012 04:21:14 CET, Bennett Haselton a écrit: >> >>> On 1/6/2012 4:11 AM, Philippe Naudin wrote: >>>> Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit: >>>> >>>>> On 1/6/2012 2:24 AM, Philippe Naudin wrote: >>>>>> Apache running as "init_t" is a call for troubles. >>>>> Is it? OK, any idea what caused that and how to fix it? >>>> No, sorry. Your httpd comes from CentOS ? >>> Yes >>>> Afaik, you should not have any process running in context init_t except >>>> init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init >>>> and httpd, your problem is likely to be more complicated than a broken >>>> configuration of apache. >>> I've got a few... >>> >>> [root@g6950-21025 ~]# ps auwxZ | grep init_t >>> system_u:system_r:init_troot 1 0.6 0.0 10368 712 >>> ?Ss 04:17 0:00 init [3] >>> >>> system_u:system_r:init_troot 537 0.2 0.1 13728 1976 >>> ?S>> system_u:system_r:init_troot 1684 0.0 0.0 38880 456 >>> ?Ssl 04:18 0:00 brcm_iscsiuio >>> system_u:system_r:init_troot 1690 0.0 0.0 12152 476 >>> ?Ss 04:18 0:00 iscsid >>> system_u:system_r:init_troot 1691 0.0 0.4 12648 4460 >>> ?S>> system_u:system_r:init_tdbus 2081 0.0 0.1 31520 1144 >>> ?Ssl 04:18 0:00 dbus-daemon --system >>> system_u:system_r:init_troot 2215 0.0 0.1 52372 1492 >>> ?Ssl 04:18 0:00 automount >>> system_u:system_r:init_troot 2254 0.0 0.1 62656 1212 >>> ?Ss 04:18 0:00 /usr/sbin/sshd >>> system_u:system_r:init_tntp 2273 0.0 0.4 23412 5044 >>> ?SLs 04:18 0:00 ntpd -u ntp:ntp -p /var >>> /run/ntpd.pid -g >>> system_u:system_r:init_troot 2287 0.1 1.0 253312 10580 >>> ?Ss 04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2315 0.3 1.3 259488 13376 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2316 0.0 1.0 257436 11124 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2317 0.1 1.1 257436 11288 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2318 0.1 1.1 257436 11292 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2319 0.0 1.0 256720 10504 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2320 0.1 1.0 257436 10752 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2321 0.0 1.1 257436 11272 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_tapache2322 0.1 1.1 257436 11356 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_troot 2386 0.0 0.0 3812 492 >>> tty1 Ss+ 04:18 0:00 /sbin/mingetty tty1 >>> system_u:system_r:init_troot 2387 0.0 0.0 3812 488 >>> tty2 Ss+ 04:18 0:00 /sbin/mingetty tty2 >>> system_u:system_r:init_troot 2390 0.0 0.0 3812 488 >>> tty3 Ss+ 04:18 0:00 /sbin/mingetty tty3 >>> system_u:system_r:init_troot 2392 0.0 0.0 3812 492 >>> tty4 Ss+ 04:18 0:00 /sbin/mingetty tty4 >>> system_u:system_r:init_troot 2394 0.0 0.0 3812 488 >>> tty5 Ss+ 04:18 0:00 /sbin/mingetty tty5 >>> system_u:system_r:init_troot 2397 0.0 0.0 3812 488 >>> tty6 Ss+ 04:18 0:00 /sbin/mingetty tty6 >>> system_u:system_r:init_tapache2405 0.1 1.0 256412 11008 >>> ?S04:18 0:00 /usr/sbin/httpd >>> system_u:system_r:init_troot 2406 0.3 0.3 90156 3456 >>> ?Ss 04:18 0:00 sshd: root@pts/0 >>> root:system_r:initrc_t:SystemLow-SystemHigh root 2458 0.0 0.0 61176 768 >>> pts/0 S+ 04:18 0:00 grep init_t >>> >>> >>> >>> I also found at least one file (the audit.log file) which has file type >>> file_t, even though I thought the filesystem had been re-labeled >&
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 4:11 AM, Philippe Naudin wrote: > Le ven 06 jan 2012 02:41:02 CET, Bennett Haselton a écrit: > >> On 1/6/2012 2:24 AM, Philippe Naudin wrote: >>> Apache running as "init_t" is a call for troubles. >> Is it? OK, any idea what caused that and how to fix it? > No, sorry. Your httpd comes from CentOS ? Yes > Afaik, you should not have any process running in context init_t except > init itself. If "ps awuxZ | grep [i]nit_t" returns more than only init > and httpd, your problem is likely to be more complicated than a broken > configuration of apache. I've got a few... [root@g6950-21025 ~]# ps auwxZ | grep init_t system_u:system_r:init_troot 1 0.6 0.0 10368 712 ?Ss 04:17 0:00 init [3] system_u:system_r:init_troot 537 0.2 0.1 13728 1976 ?S If only httpd is concerned, check "ls -Z /usr/sbin/httpd" : > -rwxr-xr-x root root system_u:object_r:httpd_exec_t /usr/sbin/httpd > and try eventually "yum reinstall httpd" ... > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/6/2012 2:24 AM, Philippe Naudin wrote: > Le ven 06 jan 2012 02:00:27 CET, Bennett Haselton a écrit: > >> On 1/5/2012 1:36 PM, Bennett Haselton wrote: >> ... >> OK, notwithstanding the fact that the filesystem on the above machine >> needs to be re-labeled and I don't know why that's failing -- >> >> I have another CentOS 5.7 machine where I've enabled SELinux (permissive >> mode) and relabeled the filesystem and it actually worked, so that the >> above commands are now giving the expected outputs: >> >> [root@g6950-21025 ~]# ps awuxZ | grep httpd | head -n 3 >> system_u:system_r:init_troot 2302 0.0 1.0 253056 10576 >> ?Ss 00:12 0:00 /usr/sbin/httpd >> system_u:system_r:init_tapache4201 0.1 2.0 274804 20968 >> ?S01:26 0:02 /usr/sbin/httpd >> system_u:system_r:init_tapache4392 0.2 1.2 257308 12512 >> ?S01:39 0:01 /usr/sbin/httpd > Apache running as "init_t" is a call for troubles. Is it? OK, any idea what caused that and how to fix it? I can't find much on Google about it except this page: http://fedoraproject.org/wiki/SELinux/EnforcePolicy says "The init process then runs /etc/rc.d/rc.sysinit, which is labeled initrc_exec_t. The kernel has a rule that says when init_t execs initrc_exec_t it transitions to initrc_t. So this continues until the httpd executable gets started as httpd_t." Even though in my case it's not happening. > $ ps awuxZ | grep [a]pache > system_u:system_r:httpd_t apache ... /usr/sbin/httpd > >> [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt >> -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t >> /var/www/html/robots.txt > This is correct. > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/5/2012 1:36 PM, Bennett Haselton wrote: > http://wiki.centos.org/HowTos/SELinux > says: > "Access is only allowed between similar types, so Apache running as > httpd_t can read /var/www/html/index.html of type httpd_sys_content_t." > > however the doc doesn't define what "similar types" means. I assumed > it just meant "beginning with the same prefix". However that can't be > right because on my system with SELinux turned on, httpd runs as type > init_t: > > [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 > system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 8820 > ?Ss 05:05 0:00 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 8920 > ?S05:05 0:00 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 8212 > ?S05:05 0:00 /usr/sbin/httpd > > and the robots.txt file has type file_t: > [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt > -rw-rw-rw- root root system_u:object_r:file_t:s0 > /var/www/html/robots.txt > > but Apache can of course access that file. So in Type Enforcement, > what determines what process type can access what file type? OK, notwithstanding the fact that the filesystem on the above machine needs to be re-labeled and I don't know why that's failing -- I have another CentOS 5.7 machine where I've enabled SELinux (permissive mode) and relabeled the filesystem and it actually worked, so that the above commands are now giving the expected outputs: [root@g6950-21025 ~]# ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_troot 2302 0.0 1.0 253056 10576 ?Ss 00:12 0:00 /usr/sbin/httpd system_u:system_r:init_tapache4201 0.1 2.0 274804 20968 ?S01:26 0:02 /usr/sbin/httpd system_u:system_r:init_tapache4392 0.2 1.2 257308 12512 ?S01:39 0:01 /usr/sbin/httpd [root@g6950-21025 ~]# ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:httpd_sys_content_t /var/www/html/robots.txt [root@g6950-21025 ~]# So, same question -- the documentation says "Access is only allowed between similar types", but what does "similar" mean? What determines that the httpd process, running under the "init_t" domain, can access the robots.txt file, which has type "httpd_sys_content_t"? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/5/2012 4:37 PM, Bennett Haselton wrote: > On 1/5/2012 3:14 PM, RILINDO FOSTER wrote: >> On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 01/05/2012 04:36 PM, Bennett Haselton wrote: >>>> http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed >>>> between similar types, so Apache running as httpd_t can read >>>> /var/www/html/index.html of type httpd_sys_content_t." >>>> >>>> however the doc doesn't define what "similar types" means. I >>>> assumed it just meant "beginning with the same prefix". However >>>> that can't be right because on my system with SELinux turned on, >>>> httpd runs as type init_t: >>>> >>>> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >>>> system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 >>>> 8820 ?Ss 05:05 0:00 /usr/sbin/httpd >>>> system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 >>>> 8920 ?S05:05 0:00 /usr/sbin/httpd >>>> system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 >>>> 8212 ?S05:05 0:00 /usr/sbin/httpd >>>> >>>> and the robots.txt file has type file_t: [root@peacefire04 - /root >>>> # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root >>>> system_u:object_r:file_t:s0 /var/www/html/robots.txt >>>> >>>> but Apache can of course access that file. So in Type Enforcement, >>>> what determines what process type can access what file type? >>>> >>>> Bennett ___ CentOS >>>> mailing list CentOS@centos.org >>>> http://lists.centos.org/mailman/listinfo/centos >>> >>> Your machine needs to be relabeled. >>> >>> touch /.autorelabel >>> reboot >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 >>> lFkAnjLTi3zphekGomv04ZyMu0sOuopg >>> =cIvM >>> -END PGP SIGNATURE- >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> WARNING: If you have never enabled SELinux for long time, the boot is >> going to take a while as the system relabels the whole machine. Do >> not do this unless you can plan for an extend downtime. >> >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > I did do > touch /.autorelabel > reboot > > The machine booted back up in just a few minutes, what looked like > normal reboot time. And then I ran the same commands as before and > got what looks to me like the same output: > > [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt > -rw-rw-rw- root root system_u:object_r:file_t:s0 > /var/www/html/robots.txt > [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 > system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 > ?Ss 16:23 0:00 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2558 0.8 0.8 28308 16392 > ?S16:23 0:03 /usr/sbin/httpd > system_u:system_r:init_t:s0 apache2560 0.5 0.5 23248 10236 > ?S16:23 0:02 /usr/sbin/httpd > > So I'm wondering: > 1) How did you know that the machine needed to be relabeled, was it > something in the output of the commands the first time I ran them? and > in that case, > 2) Why didn't it change after I created /.autorelabel and rebooted? > (I can confirm the file /.autorelabel is no longer present, so it must > have been deleted when the auto-relabel was done, like the doc says.) > 3) If the machine booted back up very quickly, should I be worried > that the autorelabel might not have happened? Any idea if it logs a > message somewhere if it fails to start properly? OK, I know why Daniel and Rilindo were telling me to relabel -- according to http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions and other sources, if a file is listed as type "file_t", it means the system needs to be relabeled. So I still don't know: after creating /.autorelabel (and verifying that it's there), and rebooting the system (and then verifying that the /.autorelabel file has been deleted, which is supposed to mean the auto-relabel actually happened), why am I still seeing the file type listed as file_t? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/5/2012 3:14 PM, RILINDO FOSTER wrote: > On Jan 5, 2012, at 4:46 PM, Daniel J Walsh wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 01/05/2012 04:36 PM, Bennett Haselton wrote: >>> http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed >>> between similar types, so Apache running as httpd_t can read >>> /var/www/html/index.html of type httpd_sys_content_t." >>> >>> however the doc doesn't define what "similar types" means. I >>> assumed it just meant "beginning with the same prefix". However >>> that can't be right because on my system with SELinux turned on, >>> httpd runs as type init_t: >>> >>> [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 >>> system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 >>> 8820 ?Ss 05:05 0:00 /usr/sbin/httpd >>> system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 >>> 8920 ?S05:05 0:00 /usr/sbin/httpd >>> system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 >>> 8212 ?S05:05 0:00 /usr/sbin/httpd >>> >>> and the robots.txt file has type file_t: [root@peacefire04 - /root >>> # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root >>> system_u:object_r:file_t:s0 /var/www/html/robots.txt >>> >>> but Apache can of course access that file. So in Type Enforcement, >>> what determines what process type can access what file type? >>> >>> Bennett ___ CentOS >>> mailing list CentOS@centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> >> Your machine needs to be relabeled. >> >> touch /.autorelabel >> reboot >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk8GGk4ACgkQrlYvE4MpobMVkgCfVagwQqbzB2UW1+TEsrrCVhF5 >> lFkAnjLTi3zphekGomv04ZyMu0sOuopg >> =cIvM >> -END PGP SIGNATURE- >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > WARNING: If you have never enabled SELinux for long time, the boot is going > to take a while as the system relabels the whole machine. Do not do this > unless you can plan for an extend downtime. > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos I did do touch /.autorelabel reboot The machine booted back up in just a few minutes, what looked like normal reboot time. And then I ran the same commands as before and got what looks to me like the same output: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2530 0.0 0.4 21680 8820 ?Ss 16:23 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache2558 0.8 0.8 28308 16392 ?S16:23 0:03 /usr/sbin/httpd system_u:system_r:init_t:s0 apache2560 0.5 0.5 23248 10236 ?S16:23 0:02 /usr/sbin/httpd So I'm wondering: 1) How did you know that the machine needed to be relabeled, was it something in the output of the commands the first time I ran them? and in that case, 2) Why didn't it change after I created /.autorelabel and rebooted? (I can confirm the file /.autorelabel is no longer present, so it must have been deleted when the auto-relabel was done, like the doc says.) 3) If the machine booted back up very quickly, should I be worried that the autorelabel might not have happened? Any idea if it logs a message somewhere if it fails to start properly? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] SELinux and access across 'similar types'
http://wiki.centos.org/HowTos/SELinux says: "Access is only allowed between similar types, so Apache running as httpd_t can read /var/www/html/index.html of type httpd_sys_content_t." however the doc doesn't define what "similar types" means. I assumed it just meant "beginning with the same prefix". However that can't be right because on my system with SELinux turned on, httpd runs as type init_t: [root@peacefire04 - /root # ps awuxZ | grep httpd | head -n 3 system_u:system_r:init_t:s0 root 2521 0.1 0.4 21680 8820 ?Ss 05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache2550 0.0 0.4 23364 8920 ?S05:05 0:00 /usr/sbin/httpd system_u:system_r:init_t:s0 apache2551 0.1 0.4 22736 8212 ?S05:05 0:00 /usr/sbin/httpd and the robots.txt file has type file_t: [root@peacefire04 - /root # ls -lZ /var/www/html/robots.txt -rw-rw-rw- root root system_u:object_r:file_t:s0 /var/www/html/robots.txt but Apache can of course access that file. So in Type Enforcement, what determines what process type can access what file type? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/5/2012 6:53 AM, Johnny Hughes wrote: > On 01/04/2012 07:47 PM, Bennett Haselton wrote: >> On 1/4/2012 1:59 PM, Lamar Owen wrote: >>> [Distilling to the core matter; everything else is peripheral.] >>> >>> On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote: >>>> To be absolutely clear: Do you, personally, believe there is more than a >>>> 1 in a million chance that the attacker who got into my machine, got it >>>> by brute-forcing the password? As opposed to, say, using an underground >>>> exploit? >>> Here's how I see it breaking down: >>> >>> 1.) Attacker uses apache remote exploit (or other means) to obtain >>> your /etc/shadow file (not a remote shell, just GET the file without >>> that fact being logged); >>> 2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer >>> on 10,000,000 machines against your /etc/shadow file without your >>> knowledge; >>> 3.) Some time passes; >>> 4.) Attacker obtains your password using distributed brute forcing of >>> the hash in the window of time prior to you resetting it; >>> 5.) Attacker logs in since you allow password login. You're pwned by >>> a non-login brute-force attack. >>> >>> In contrast, with ssh keys and no password logins allowed: >>> >>> 1.) Attacker obtains /etc/shadow and cracks your password after some >>> time; >>> 2.) Attacker additionally obtains /root/.ssh/* >>> 3.) Attacker now has your public key. Good for them; public keys >>> don't have to be kept secure since it is vastly more difficult to >>> reverse known plaintext, known ciphertext, and the public key into a >>> working private key than it is to brute-force the /etc/shadow hash >>> (part of the difficulty is getting all three required components to >>> successfully reverse your private key; the other part boils down to >>> factoring and hash brute-forcing); >>> 4.) Attacker also has root's public and private keys, if there is a >>> pair in root's ~/.ssh, which may or may not help them. If there's a >>> passphrase on the private key, it's quite difficult to obtain that >>> from the key; >>> 5.) Attacker can't leverage either your public key or root's key pair >>> (or the machine key; even if they can leverage that to do MitM (which >>> they can and likely will) that doesn't help them obtain your private >>> key for authentication; >>> 6.) Attacker still can't get in because you don't allow password >>> login, even though attacker has root's password. >>> >>> This only requires an apache httpd exploit that allows reading of any >>> file; no files have to be modified and no shells have to be acquired >>> through any exploits. Those make it faster, for sure; but even then >>> the attacker is going to acquire your /etc/shadow as one of the first >>> things they do; the next thing they're going to do is install a >>> rootkit with a backdoor password. >>> >>> Brute-forcing by hash-cracking, not by attempting to login over ssh, >>> is what I'm talking about. >> I acknowledged that the first time I replied to someone's post saying a >> 12-char password wasn't secure enough. I hypothesized an attacker with >> the fastest GPU-driven password cracker in the world (even allowing for >> 100-factor improvements in coming years) and it would still take >> centuries to break. I understand about brute-forcing the hash vs. >> brute-forcing the login, but some others had posted about brute-forcing >> the login specifically and I was commenting on how ridiculous that was. >> >>> This is what I mean when I say 'multilayer metasploit-driven attacks.' >>> >>> The weakest link is the security of /etc/shadow on the server for >>> password auth (unless you use a different auth method on your server, >>> like LDAP or other, but that just adds a layer, making the attacker >>> work harder to get that all-import password). Key based auth is >>> superior, since the attacker reading any file on your server cannot >>> compromise the security. >>> >>> Kerberos is better still. >>> >>> Now, the weakest link for key auth is the private key itself. But >>> it's better protected than any password is (if someone can swipe your >>> private key off of your workstation you have bigger problems, and they >>> will have your /etc/shadow fo
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/4/2012 3:01 PM, Marko Vojinovic wrote: > On Wednesday 04 January 2012 11:58:07 Bennett Haselton wrote: >> If *everyone* used a 12-char random password, then the odds are that >> *none* of the 10 million machines attacking 100 million servers would >> hit on a success, not when there are 10^21 possible passwords to choose >> from. > It is too naive to identify the statement "something has very low probability" > with the statement "it will not happen". > > There are processes in nature that have 1 / 10^21 (or any other) probability > of happening, but they are detected to actually happen every couple of seconds > or so (hint: ask any nuclear physicist). That's because they are observing quantities of particles on the order of 10^21, so the odds of the event occurring are realistic. (Recall Avogadro's number is 6 x 10^23, the number of particles in one mole of a substance.) > In a security-related context, relying on low probability is always a risk > (regardless of how small), and it should be avoided if feasible. IOW, chances > of "10^ to one" are *infinitely* bigger than zero. > Proof --- divide that number by zero to find out how many times it is bigger. > ;-) > > You should never rely on any probability count if you have critical security > concerns. Yes, I also use a strong password rather than ssh key (mostly for > the same reason you do --- convenience), but I understand the risk of doing > so, I don't have any valuable data on the machine, and I never claim that any > password is as effective as a ssh key. Well as I've said it depends on how literally you mean "as effective". If your password is strong enough that there's only a 1 in 10^10 chance of it being broken by an attacker in the next year, then if an alternative method reduces that chance to 1 in 10^20, you could do that, but I wouldn't bother. Again, I would have been perfectly happy to use ssh keys -- it would have been less work to switch to ssh keys than to write all the messages defending 12-char passwords :) The reason I wrote all those messages about 12-char passwords was not because I wanted to avoid switching to ssh keys. It was because I wanted some alternative suggestions for how an attacker could have gotten in, given that the chance of brute-forcing the password (even if the attacker had obtained the password hash) was so astronomically small! > Btw, I am also one of the "lucky" people who managed to get hacked by ssh > brute-forcing. The password was as "random" as it can get, but the attacker > just got lucky Not sure what you mean by "as random as it can get", but -- I can write this in my sleep by now -- if you have a 12-character password, with 10^21 possibilities to search from, the odds of an attacker getting "lucky" and guessing it, are less probable than you being hit by a meteorite tomorrow. I can absolutely guarantee you that either the password was shorter and less random, or else the attacker got it some other way (possibly your machine got infected with malware that captured your password and uploaded it to a botnet). > (he didn't get root, though, just my user password, so I could > mitigate the damage). After that I installed fail2ban, but I still don't keep > anything valuable on that machine... > >>>> However, *then* you have to take into account the fact that, >>>> similarly, >>>> the odds of a given machine being compromised by a man-in-the-middle >>>> attack combined with cryptanalysis of the stream cipher, is *also* >>>> overwhelmed by the probability of a break-in via an exploit in the >>>> software it's running. I mean, do you think I'm incorrect about that? > Are you basically saying that this is a premature optimization problem? If I > understand your argument correctly, some attack vectors are much more probable > than others, so guarding against a low-probability attack vector is > superfluous, given that there are more probable ones still unguarded. Is that > what you are saying here? > > If yes, let me stress --- the premature optimization issue is *void* in a > security-related context. The main guideline is rather the "cover all bases" > principle. The fact that something is unlikely to happen does not mean you > should not guard against it, if you can. You may find the pain/gain ratio too > high sometimes, and you are welcome to ignore some obvious security holes for > the sake of convenience if you like, but you cannot argue that low-probability > holes are safe to ignore *in* *principle*. That is where the cover-all-bases > always wins over avoiding premature optimization. It depend on what you mean by
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/4/2012 1:59 PM, Lamar Owen wrote: > [Distilling to the core matter; everything else is peripheral.] > > On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote: >> To be absolutely clear: Do you, personally, believe there is more than a >> 1 in a million chance that the attacker who got into my machine, got it >> by brute-forcing the password? As opposed to, say, using an underground >> exploit? > > Here's how I see it breaking down: > > 1.) Attacker uses apache remote exploit (or other means) to obtain > your /etc/shadow file (not a remote shell, just GET the file without > that fact being logged); > 2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer > on 10,000,000 machines against your /etc/shadow file without your > knowledge; > 3.) Some time passes; > 4.) Attacker obtains your password using distributed brute forcing of > the hash in the window of time prior to you resetting it; > 5.) Attacker logs in since you allow password login. You're pwned by > a non-login brute-force attack. > > In contrast, with ssh keys and no password logins allowed: > > 1.) Attacker obtains /etc/shadow and cracks your password after some > time; > 2.) Attacker additionally obtains /root/.ssh/* > 3.) Attacker now has your public key. Good for them; public keys > don't have to be kept secure since it is vastly more difficult to > reverse known plaintext, known ciphertext, and the public key into a > working private key than it is to brute-force the /etc/shadow hash > (part of the difficulty is getting all three required components to > successfully reverse your private key; the other part boils down to > factoring and hash brute-forcing); > 4.) Attacker also has root's public and private keys, if there is a > pair in root's ~/.ssh, which may or may not help them. If there's a > passphrase on the private key, it's quite difficult to obtain that > from the key; > 5.) Attacker can't leverage either your public key or root's key pair > (or the machine key; even if they can leverage that to do MitM (which > they can and likely will) that doesn't help them obtain your private > key for authentication; > 6.) Attacker still can't get in because you don't allow password > login, even though attacker has root's password. > > This only requires an apache httpd exploit that allows reading of any > file; no files have to be modified and no shells have to be acquired > through any exploits. Those make it faster, for sure; but even then > the attacker is going to acquire your /etc/shadow as one of the first > things they do; the next thing they're going to do is install a > rootkit with a backdoor password. > > Brute-forcing by hash-cracking, not by attempting to login over ssh, > is what I'm talking about. I acknowledged that the first time I replied to someone's post saying a 12-char password wasn't secure enough. I hypothesized an attacker with the fastest GPU-driven password cracker in the world (even allowing for 100-factor improvements in coming years) and it would still take centuries to break. I understand about brute-forcing the hash vs. brute-forcing the login, but some others had posted about brute-forcing the login specifically and I was commenting on how ridiculous that was. > This is what I mean when I say 'multilayer metasploit-driven attacks.' > > The weakest link is the security of /etc/shadow on the server for > password auth (unless you use a different auth method on your server, > like LDAP or other, but that just adds a layer, making the attacker > work harder to get that all-import password). Key based auth is > superior, since the attacker reading any file on your server cannot > compromise the security. > > Kerberos is better still. > > Now, the weakest link for key auth is the private key itself. But > it's better protected than any password is (if someone can swipe your > private key off of your workstation you have bigger problems, and they > will have your /etc/shadow for your workstation, and probably a > backdoor.). The passphrase is also better protected than the > typical MD5 hash password, too. > > It is the consensus of the security community that key-based > authentication with strong private key passphrases is better than any > password-only authentication, and that consensus is based on facts > derived from evidence of actual break-ins. Well yes, on average, password-authentication is going to be worse because it includes people in the sample who are using passwords like "Patricia". Did they compare the break-in rate for systems with 12-char passwords vs. systems with keys? I h
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/4/2012 9:32 AM, Lamar Owen wrote: > On Tuesday, January 03, 2012 06:12:10 PM Bennett Haselton wrote: >> I'm not sure what their logic is for recommending 80. But 72 bits >> already means that any attack is so improbable that you'd *literally* >> have to be more worried about the sun going supernova. > I'd be more worried about Eta Carinae than our sun, as with it's mass it's > likely to be a GRB. The probability of it happening in our lifetime is quite > low; yet, if it does happen in our lifetime (actually, if it happened about > 7,500 years ago!) it will be an extinction event. So we watch it over time > (and we have plates of it going back into the late 1800's). > > Likewise for security; the gaussian curve does have outliers, after all, and > while it is highly unlikely for a brute-force attack to actually come up with > anything against a single server it is still possible, partially due to the > number of servers out there coupled with the sheer number of brute-forcers > running. The odds are not 1 out of 4.7x10^21; they're much better than that > since there isn't just a single host attempting the attack. If I have a > botnet of 10,000,000 infected PC's available to attack 100,000,000 servers > (close to the number), what are the odds of one of those attacks succeeding? > (the fact is that it has happened already; see my excerpted 'in the wild' > brute-forcer dictionary below). (1) Someone already raised the issue of what if you have 10 million infected machines instead of just 1; multiple people pointed out that it doesn't matter because the limiting factor is the speed at which sshd can accept/reject login requests, so it doesn't matter if the attacker has 10 million machines or 1. (2) If there are 100 million machines being attacked, that still doesn't make a brute force attack any more likely for my machine. It's not correct to say that if 10 million of those 100 million machines are likely to get compromised, then mine has a 10% chance of being compromised, because with a 12-char random password the odds are much lower for me than for others in the sample. If *everyone* used a 12-char random password, then the odds are that *none* of the 10 million machines attacking 100 million servers would hit on a success, not when there are 10^21 possible passwords to choose from. >>> The critical thing to remember is that in key auth the authenticating key >>> never leaves the client system,... >> Actually, the top answer at that link appears to say that the server >> sends the nonce to the client, and only the client can successfully >> decrypt it. (Is that what you meant?) > That's session setup, not authentication. The paragraph I'm reading appears to say that the server sends the nonce to the client, even for *authentication* (after session setup): http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password "After the channel is functional and secure... the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server". So that's what I meant... you'd said the client sends the nonce to the server whereas the page said the server sends the nonce to the client... just wanted to make sure I wasn't missing anything. > The server has to auth to the client first for session setup, but then client > auth is performed. But either way the actual client authenticating key never > traverses the wire and is unsniffable. >> Furthermore, when you're dealing with probabilities that ridiculously >> small, they're overwhelmed by the probability that an attack will be >> found against the actual algorithm (which I think is your point about >> possible weaknesses in the stream cipher). > This has happened; read some SANS archives. There have been and are exploits > in the wild against SSH and SSL; even caused OpenBSD to have to back down > from it's claim of never having a remotely exploitable root attack. > >> However, *then* you have to take into account the fact that, similarly, >> the odds of a given machine being compromised by a man-in-the-middle >> attack combined with cryptanalysis of the stream cipher, is *also* >> overwhelmed by the probability of a break-in via an exploit in the >> software it's running. I mean, do you think I'm incorrect about that? > What you're missing is that low probability is not a preventer of an actual > attack succeeding;
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 4:21 PM, Les Mikesell wrote: > On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haselton > wrote: >>> The critical thing to remember is that in key auth the authenticating key >>> never leaves the client system, rather an encrypted 'nonce' is sent (the >>> nonce is encrypted by the authenticating key), which only the server, >>> possessing the matching key to the authenticating key, can successfully >>> decrypt. >> Actually, the top answer at that link appears to say that the server >> sends the nonce to the client, and only the client can successfully >> decrypt it. (Is that what you meant?) >>> This effectively gives full bit-strength for the whole key; 1024 bits of >>> entropy, if you will, for 1024 bit keys. This would appear to require a >>> 157 character random password chosen from all 95 ASCII printable characters >>> to match, in terms of bit entropy. >> Yes, I've acknowledged that whether you think 1024 bits is more secure >> than 72 bits depends on how literally you mean "more secure". If the >> odds of an attack working in the next year are 1 in 10^10, you can >> reduce the odds to 1 in 10^20, which in a strict mathematical sense may >> make you more secure, but -- not really. > You are still speculating about the wrong things, though. Is your > password written down? Has anyone ever been in the same room when you > typed it? Could a key logger have been installed anywhere you typed > it? Right, but these are all valid concerns if you use keys as well. If someone's in the room when you type in the passphrase for your key, they might come back in later and take the key and use the passphrase. If they install malware, they can capture the passphrase and the key as well. > And for the brute-force side of things, these may be done from > a large number of sources to a large number of targets. They may be > too slow to break any specific target but repeat it enough and you'll > match something, somewhere. Well yes but that doesn't make *my* password any less secure if it's chosen from a space of 10^21 possible passwords. The attacker will just move on. > Maybe you were just the lucky one that > day - and if you used the same password on the other(s) they would be > easy targets. > >> However, *then* you have to take into account the fact that, similarly, >> the odds of a given machine being compromised by a man-in-the-middle >> attack combined with cryptanalysis of the stream cipher, is *also* >> overwhelmed by the probability of a break-in via an exploit in the >> software it's running. I mean, do you think I'm incorrect about that? >> Of the compromised machines on the Internet, what proportion do you >> think were hacked via MITM-and-advanced-crypto, compared to exploits in >> the services? > Proportions don't matter. Unless you have something extremely > valuable to make this machine a target or someone captured your > password and connection destination it was probably a random hit of a > random probe. It doesn't matter if they are likely to work or not, > some do. I either disagree or I'm not sure what you're saying. What do you mean that "proportions don't matter"? If attack A is 1,000 times more likely to work than attack B, you don't think it's more important to guard against attack A? Wasn't that exactly what you were advising when you said to worry more about someone capturing my password with a keylogger, than brute-forcing it? >> The problem with such "basic stuff" is that in any field, if there's no >> way to directly test whether something has the desired effect or not, it >> can become part of accepted "common sense" even if it's ineffective. > If you have multiple layers of protection and look at your logs, > you'll see what people are trying. And they keep trying it because it > works... Well they might be "trying" it because it works against some other systems (in particular, brute-forcing a weak password). That doesn't mean it's any more likely to work on a system with a 12-char random password. > If you aren't looking at your logs there's not much use in > speculating about what might be happening. > > >> Case in point: in the *entire history of the Internet*, do you think >> there's been a single attack that worked because squid was allowed to >> listen on a non-standard port, that would have been blocked if squid had >> been forced to listen on a standard port? > Generalize that question to 'do you think attacks are helped by > permitting applications
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:13 PM, Lamar Owen wrote: > On Sunday, January 01, 2012 06:27:32 PM Bennett Haselton wrote: >> (I have already practically worn out my keyboard explaining the math behind >> why I think a 12-character alphanumeric password is secure enough :) ) > Also see: > https://lwn.net/Articles/369703/ The focus of this article seems to be on systems with multiple users where the admin can't necessarily trust all the users to make smart decisions. I've already said that I can see why in that case it might be desirable to require users to use ssh keys instead of passwords, since you can't force users to use good passwords. My point was that if you're the only user and you can make yourself use a 12-char password with enough entropy, that's good enough. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:10 PM, Pete Travis wrote: > Here's the qualifying statement I made, in an attempt to preempt pedantic > squabbles over my choice of arbitrary figures and oversimplified math: >>> I am not a statistician, but > Here is a statement intended to startle you into re-examining your position: >>> Simplistic probability puts the odds of success >>> at 50% - either the attacker gets it right, or they don't. Oh, did you mean something like, "Let's pick any value p as the probability of the attacker getting in by brute force in a given hour"? OK, that's different. But it's still missing the point that if the odds of an event happening in the next year are less than the Earth crashing into the Sun, then it's not worth worrying about. There's a more basic error in your math. If there are two ways X and Y to attack a server, and X has a 1 in 100 chance of succeeding and Y has a 1 in 10^10 chance of succeeding, then if you reduce the chances of Y succeeding to 1 in 10^20, that's only an order of magnitude change in the likelihood of Y, *not* an order of magnitude change in the overall chance of a break-in, which changes by a negligible amount. >>> Here's the intended take home message: >>> The next guess has the same >>> rough odds of being correct as the 100563674th guess. > Yes, you have to worry about a brute force attack succeeding, every hour of > every day that you give it a window to knock on. > > Here is you nitpicking over figures; acknowledging the opportunity for an > improvement of several orders of magnitude and disregarding it, stuck in > your misconceptions; and wholly missing the point. >> Actually, each time you make a guess and it's wrong, the probability of >> success goes up slightly for your next guess. Imagine having 10 cups >> with a ball under one of them. The probability of turning over the >> right cup on the first try is 1/10. If you're wrong, though, then the >> probability of getting it right on the next cup goes up to 1/9, and so on. >> >> But it's all a moot point if there are 10^24 possible passwords and the >> odds of finding the right one in any conceivable length of time are >> essentially zero. >> >>> Of course, no amount of guessing will succeed on a system that doesn't >>> accept passwords. System security, in terms of probability, seems to > be >>> an 'every little bit helps' sort of endeavour. >> Well it depends on how literally you mean "every little bit" :) If the >> chance of a break-in occurring in the next year from a given attack is 1 >> in 10^10, you can reduce it to 1 in 10^20, but it's already less likely >> than your data center being hit by a meteorite. The real problem is >> that it takes away from time that can be used for things that have a >> greater likelihood of reducing the chance of a break-in. If I had taken >> the advice about ssh keys at the beginning of the thread, I never would >> have gotten to the suggestion about SELinux. >> >> Bennett >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > I'm moving on from this - much better men than I have tried and failed here. > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:04 PM, Lamar Owen wrote: > On Tuesday, January 03, 2012 03:24:34 PM Bennett Haselton wrote: >> That there are 10^21 possible random 12-character alphanumeric passwords >> -- making it secure against brute-forcing -- is a fact, not an opinion. > >> To date, *nobody* on this thread has ever responded when I said that >> there are 10^21 possible such passwords and as such I don't think that >> the password can be brute-forced in that way. > Hmm, methinks you need to rethink the number. The number of truly random > passwords available from a character set with N charaters and of a length L > is N^L. (see https://en.wikipedia.org/wiki/Password_strength#Random_passwords > ) > > If L=12, then: > For: > The numerals only: 10^12. > The Uppercase alphabet only: 26^12 (9.5x10^16) > Uppers and lowers: 52^12 (3.9x10^20) > Numerals plus uppers and lowers: 62^12 (3.2x10^21) > Base64: 64^12 (4.7x10^21) This is the figure I'm using (because I actually use some chars that aren't letters or numbers so I rounded up to 64). You got on the order of 10^21, same as me. > Full ASCII printables, minus space: 94^12 (4.76x10^23) > > This of course includes repeating characters. NIST recommends 80-bit > entropy-equivalent passwords for secure systems; 12 characters chosen at > random from the full 95 ASCII printable characters doesn't quite make that > (at a calculated 78 bits or so). I'm not sure what their logic is for recommending 80. But 72 bits already means that any attack is so improbable that you'd *literally* have to be more worried about the sun going supernova. > Having said all of that, please see and read > http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password > > The critical thing to remember is that in key auth the authenticating key > never leaves the client system, rather an encrypted 'nonce' is sent (the > nonce is encrypted by the authenticating key), which only the server, > possessing the matching key to the authenticating key, can successfully > decrypt. Actually, the top answer at that link appears to say that the server sends the nonce to the client, and only the client can successfully decrypt it. (Is that what you meant?) > This effectively gives full bit-strength for the whole key; 1024 bits of > entropy, if you will, for 1024 bit keys. This would appear to require a 157 > character random password chosen from all 95 ASCII printable characters to > match, in terms of bit entropy. Yes, I've acknowledged that whether you think 1024 bits is more secure than 72 bits depends on how literally you mean "more secure". If the odds of an attack working in the next year are 1 in 10^10, you can reduce the odds to 1 in 10^20, which in a strict mathematical sense may make you more secure, but -- not really. Furthermore, when you're dealing with probabilities that ridiculously small, they're overwhelmed by the probability that an attack will be found against the actual algorithm (which I think is your point about possible weaknesses in the stream cipher). However, *then* you have to take into account the fact that, similarly, the odds of a given machine being compromised by a man-in-the-middle attack combined with cryptanalysis of the stream cipher, is *also* overwhelmed by the probability of a break-in via an exploit in the software it's running. I mean, do you think I'm incorrect about that? Of the compromised machines on the Internet, what proportion do you think were hacked via MITM-and-advanced-crypto, compared to exploits in the services? It was that calculation I was making when I kept insisting that there must be something more probable than brute-forcing the login or decrypting the session -- and if I hadn't stood my ground about that, the discussion never would have gotten around to SELinux, which, if it works in the manner described, may actually help. > Obviously, the authenticating key's protection is paramount, and the > passphrase is but one part of that. But that key never travels over the wire. > > In stark constrast, in password auth the password has to leave the system and > traverse the connection, even if it's over an encrypted channel (it's hashed > on the server end and compared to the server's stored hash, plus salt (always > did like a little salt with my hash!), not the client, right? After all, > the client may not possess the algorithm used to generate the hash, but > password auth still works.). This leaves a password vulnerable to a 'man in > the middle' attack if a weakness is found in the negotiated stream cipher > used in the channel. > > Even with a full man-in-
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:32 PM, m.r...@5-cent.us wrote: > Bennett Haselton wrote: >> mark wrote: > >>>> 1. How will you generate "truly random"? Clicks on a Geiger counter? >>>> There is no such thing as a random number generator. > >> That there are 10^21 possible random 12-character alphanumeric passwords >> -- making it secure against brute-forcing -- is a fact, not an opinion. >> >> To date, *nobody* on this thread has ever responded when I said that >> there are 10^21 possible such passwords and as such I don't think that >> the password can be brute-forced in that way. Almost every time I said > Ok, I'll answer, here and now: YOU IGNORED MY QUESTION: HOW WILL YOU > "RANDOMLY" GENERATE THE PASSWORDS? All algorithmic ones are pseudo-random. > If someone has any idea what the o/s is, they can guess which > pseudo-random generator you're using, and can try different salts. I generally change them from the values assigned by the hosting company, and just bang my fingers around on the keyboard, with the shift key randomly on and off for good measure :) This also removes the possibility that an incompetent hosting company will store their own copy of the password somewhere that it can be compromised. Even when that possibility is very unlikely, it's still astronomically more likely than the attacker guessing the password by brute force. But even if someone did not do that, don't most Linux distros a good crypto-random number generator for generating new passwords, when they're picked by the machine and not the user? You can use salts that depend on the low bits of high-precision performance counters, and other values that are impossible for an attacker to predict. If any Linux implementation is using anything less than a cryptographically strong generator for creating passwords, like I said it's not my problem, but I would take that up with the developers. > Someone > here posted a link to the Rainbow tables, and precomputed partial lists. > >> Again: Do you think I'm wrong that if you use a 12-character mixed-case >> alphanumeric password, then switching to sshkeys or using fail2ban will >> not make the system any more secure? If you think I'm wrong, why? What >> is the exact scenario that you think those would prevent? > Without fail2ban, or something like it, they'll hit your system thousands > of times an hour, at least. Sooner or later, they'll get lucky. OK do you *literally mean that* -- that with 10^21 possible passwords that an attacker has to search, I have to worry about the attacker "getting lucky" if they're trying "thousands of times per hour"? > But I suppose you'll ignore this, as well. > > mark > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:31 PM, Pete Travis wrote: > On Jan 3, 2012 12:36 PM, "Ljubomir Ljubojevic" wrote: >> On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: >>> Having been on vacation, I'm coming in very late in this >>> >>> Les Mikesell wrote: >>>> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton >>>> wrote: >>> >>>>> OK but those are *users* who have their own passwords that they have >>>>> chosen, presumably. User-chosen passwords cannot be assumed to be >>>>> secure against a brute-force attack. What I'm saying is that if > you're >>>>> the only user, by my reasoning you don't need fail2ban if you just > use a >>>>> 12-character truly random password. >>>> But you aren't exactly an authority when you are still guessing about >>>> the cause of your problem, are you? (And haven't mentioned what your >>>> logs said about failed attempts leading up to the break in...). >>> Further, that's a ridiculous assumption. Without fail2ban, or something >>> like it, they'll keep trying. You, instead, Bennett, are presumably >>> generating that "truly random" password[1] and assigning it to all your >>> users[2], and not allowing them to change their passwords, and you will > be >>> changing it occasionally and informing them of the change.[3] >>> >>> Right? >>> >>> mark >>> >>> 1. How will you generate "truly random"? Clicks on a Geiger counter? > There >>> is no such thing as a random number generator. >>> 2. Which, being "truly random", they will write down somewhere, or store >>> it on a key, labelling the file "mypassword" or some such. >>> 3. How will you notify them of their new password - in plain text? >> Bennet was/is the only one using those systems, and only as root. No >> additional users existed prior to breach. And he is very persisting in >> placing his own opinion/belief above those he asks for help. That is why >> we have such a long long long thread. It came to the point where I am >> starting to believe him being a troll. Not sure yet, but it is getting >> there. >> >> I am writing this for your sake, not his. I decided to just watch from >> no on. This thread WAS very informative, I did lear A LOT, but enough is >> enough, and I spent far to much time reading this thread. >> >> >> -- >> >> Ljubomir Ljubojevic >> (Love is in the Air) >> PL Computers >> Serbia, Europe >> >> Google is the Mother, Google is the Father, and traceroute is your >> trusty Spiderman... >> StarOS, Mikrotik and CentOS/RHEL/Linux consultant >> ___ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos > I'm subscribed to this list just because of threads like this. I want to > thank you all for exposing me to knowledge and discussion that reveals far > more than manpages or readmes - it helps a lot to know where to start > reading, and about what. > > I am not a statistician, but I feel an observation should be made on the > idea of an 'unguessable password.' A 12 character string may have 12^42 > possible permutations, I'm not sure where you got the 12^42 figure from. My assumption was that each character has about 64 = 2^6 possible values, so there are 2^72 possible passwords, which is on the order of 10^24. > but you are assuming that the correct guess will be > the last possible guess. Actually I was using the fact that the average time to break the password would be the time required to check half of the possible passwords, not that they won't find it until the last possible one. That's still on the order of 10^24. > Simplistic probability puts the odds of success > at 50% - either the attacker gets it right, or they don't. I can't make sense of this statement at all. Just because there are two possible outcomes doesn't mean that each possibility is equally likely -- you might as well that either the sun comes up tomorrow, or it doesn't, so the odds of success are 50% :) The only time the "50%" figure comes up is that the average time to guess a password is the time taken to check half of all possible passwords, and hence is 50% of the worst-case time to guess a password (which would be the time taken to check all of them). > An intelligent > brute forcing tool could be making some assumptions about the minimum > length and complexity
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 11:36 AM, Ljubomir Ljubojevic wrote: > On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: >> Having been on vacation, I'm coming in very late in this >> >> Les Mikesell wrote: >>> On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton >>> wrote: >> >>>> OK but those are *users* who have their own passwords that they have >>>> chosen, presumably. User-chosen passwords cannot be assumed to be >>>> secure against a brute-force attack. What I'm saying is that if you're >>>> the only user, by my reasoning you don't need fail2ban if you just use a >>>> 12-character truly random password. >>> But you aren't exactly an authority when you are still guessing about >>> the cause of your problem, are you? (And haven't mentioned what your >>> logs said about failed attempts leading up to the break in...). >> Further, that's a ridiculous assumption. Without fail2ban, or something >> like it, they'll keep trying. You, instead, Bennett, are presumably >> generating that "truly random" password[1] and assigning it to all your >> users[2], and not allowing them to change their passwords, and you will be >> changing it occasionally and informing them of the change.[3] >> >> Right? >> >> mark >> >> 1. How will you generate "truly random"? Clicks on a Geiger counter? There >> is no such thing as a random number generator. >> 2. Which, being "truly random", they will write down somewhere, or store >> it on a key, labelling the file "mypassword" or some such. >> 3. How will you notify them of their new password - in plain text? > Bennet was/is the only one using those systems, and only as root. No > additional users existed prior to breach. And he is very persisting in > placing his own opinion/belief above those he asks for help. That there are 10^21 possible random 12-character alphanumeric passwords -- making it secure against brute-forcing -- is a fact, not an opinion. To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Almost every time I said this, I added, "If you think this is incorrect, why do you think it's incorrect?", because I did genuinely want to know. When people didn't reply, I thought maybe they hadn't realized before that I was using actually long, actually random passwords, and maybe they no longer thought that was insecure after all. Again: Do you think I'm wrong that if you use a 12-character mixed-case alphanumeric password, then switching to sshkeys or using fail2ban will not make the system any more secure? If you think I'm wrong, why? What is the exact scenario that you think those would prevent? > That is why > we have such a long long long thread. It came to the point where I am > starting to believe him being a troll. Not sure yet, but it is getting > there. The thread grew so long partly because few people were offering suggestions on *preventive* measures (mostly on what to do differently next time to diagnose after the fact -- which was fine and useful, but I kept trying to steer the discussion back to preventive measures), and the two preventive measures that did come up the most, were using ssh keys and using fail2ban to stop people brute-forcing the login, and I kept explaining why I did not think that would make me any safer the next time around. Note that after over 100 messages had been posted on the subject, someone did mention SELinux and the specific scenario (which has come up in the real world) in which SELinux can stop a break-in (exploit is found where attacker takes control of Apache, Apache writes to /tmp dir and tries to execute a program there). If I had accepted the "advice" offered at the beginning to use keys instead of passwords, the discussion might have never gotten past that. It was because I stood my ground that brute-forcing a 12-character random password was not logically possible, that the discussion eventually turned to something which *might* at least reduce the chance of a future break-in. > I am writing this for your sake, not his. I decided to just watch from > no on. This thread WAS very informative, I did lear A LOT, but enough is > enough, and I spent far to much time reading this thread. > > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:50 AM, Nataraj wrote: > On 01/02/2012 10:48 PM, Bennett Haselton wrote: >> True but I travel a lot and sometimes need to connect to the machines >> from subnets that I don't know about in advance. > You could secure another system somewhere on the internet (could be a > $20/month virtual host), leave no pointers to your production systems on > that system, and allow remote logins on your production systems from > that other host. It's called a back door. But assuming the attacker is targeting my production system, suppose they find a vulnerability and obtain the ability to run commands as root on the system. Then wouldn't their first action be to remove restrictions on where you can log in from? (Or, they could just continue to run root commands using whatever trick they'd discovered?) > You could also take a look > at something like fwknop. That in combination with some type of back > door for the situation where you don't have your keys available should > cover any situation where you need to get to your system. But access > using the key authentication should be preferred and only use the back > door for emergencies. >> If I used openvpn to connect, and then connected via ssh over openvpn, >> this seems like essentially security through obscurity :) by just >> replacing the public ssh daemon with a different public daemon (with a >> different connection protocol) which an attacker could try to >> brute-force the same way they could try to brute-force sshd. > Pretty much all security is based on something that you know/have that > the attacker doesn't know/have. This is true for computer access, the > locks on your front door and the safe at the bank. Yes, but the argument for "security over obscurity" is that the "secret" should reside in something that cannot be obtained even in trillions of trillions of guesses (i.e. a strong password), not in something that could be obtained in a few dozen or a few thousand guesses (i.e. finding OpenVPN listening on a given port). The reason being is that if something is obtainable in a few thousand guesses, then it will create the illusion of being unguessable, but an attacker could still get it. > What your getting > from the people on this list is their experience, comments based on what > they did that worked and what they did that didn't. Unfortunately it may not be possible to tell that a particular safeguard ever actually "worked" or made a difference. How could you ever know, for example, that an attacker was stopped because you used an ssh key instead of a 12-character truly random password? One way you can know is if you have two barriers one behind the other, and attackers get through the first barrier but not the second one, then you know the second barrier mattered. That's why the argument for SELinux sounds persuasive, because of identified instances where attackers circumvented the first barrier (finding a way to make Apache create executables in /tmp/) but were stopped by the second (SELinux prevented those executables from being run). > Check the past 10 > years of cert advisories and count the number of security advisories for > sshd and then count the number for openvpn. OK, that's different from the obscurity factor (since the difference in exploit frequency, would still be a reason to use openvpn instead of sshd, even if the attacker knew that you were using it). However that also has to be weighed against the side effects of using a non-standard setup. I assume, for example, that most security audit tools would look at IP addresses that attempted to log in via ssh. That wouldn't work if your gateway is OpenVPN instead of sshd. (In my experience, everything you're doing differently from everyone else, makes it harder to get help when things go wrong.) >> However it still seems that this would only matter if the attacker got >> in by brute-forcing the login. If they obtained the ability to run >> privileged commands any other way, then (1) they could continue to run >> privileged commands that way anyway, or (2) as their first action they >> could just remove all the IP address restrictions on ssh connections at >> which point they could connect normally via ssh from anywhere. > The more security mechanisms you have in place, the greater is the > probability that even if they made a partial compromise of your system, > they might fail when they try to get through to the next level and if > you have warning systems, such as daily reports or even alerts sent to > your cell phone, you might be able to stop them first. For partial compromises that makes sense. However for total compromises (i.e. if attacker is running root commands on your system), the
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 11:01 PM, John R. Dennison wrote: > On Mon, Jan 02, 2012 at 10:41:15PM -0800, Bennett Haselton wrote: >> Again, you don't have to take my word for it -- in the first 10 Google >> hits of pages with people posting about the problem I ran into, none of >> the people helping them, thought to suggest SELinux as the cause of the >> problem. (By contrast, when iptables causes a problem, people usually >> figure out that's what's going on.) > There's a lot of FUD going around in this thread. If people would > bother to spend some time _reading_ _documentation_ on the systems they > are attempting to admin they might find that subsystems such as selinux > aren't quite as complex as they make them out to be. Well for one thing, much of the documentation for Linux tools is missing, unclear, or sometimes just wrong. Here's a message I posted two years ago: http://forums.mysql.com/read.php?11,280886,280886#msg-280886 about how when you first install MySQL, it tells you -- shouting in all caps, no less -- to set a password by running a pair of commands, where the second command is always guaranteed to fail (for reasons explained in the post). I verified this on every dedicated server I had access to. But the message never got answered, and for all I know MySQL still shouts the wrong information at every new user who installs it. However, completely wrong documentation is actually rare; the problem with most documentation is that it's unclear or ambiguous, because it's written or judged with the mindset that users "should" know enough to resolve the ambiguities and the errors, and if the user doesn't know enough to figure out the errors, it's a failing on the user's part. Or the documentation is extremely long-winded and doesn't contain a short version that is good enough for 99% of users' purposes, because it's assumed that if users don't want to read the 50-page version, that's also a failing on the user's part. I think most unclear documentation could easily be made better. I'd be happy to volunteer for a project where someone writing documentation wanted to check to see if it made sense to people who didn't already know what the author was trying to say. But the authors have to want to do that. The main obstacle is the mindset that problems with documentation are presumed to be the user's fault. (To be fair, this isn't a problem specific to Linux documentation; many instructions out there are pretty bad, because it's notoriously difficult to judge the quality of instructions in a field in which you're an expert, since your brain automatically fixes errors and ambiguities if you know what the author was trying to say. Recipes written by cooking experts are pretty bad.) > Oh, and like all > other aspects of the internet, google is just as susceptible to indexing > idiots as it is to indexing pertinent and accurate results. > > selinux is fully integrated into the system auditing facilities and even > provides multiple tools to aid an administrator in problem isolation > and remediation. These tools are, of course, fully documented. > > There is _ample_ documentation on the web, starting with the CentOS > wiki site, that covers selinux in great detail. I would urge you and > anyone else not familiar with the facilities that selinux offers, both > from an enforcement standpoint and also from a management standpoint, to > spend some quality time reading up on it. > > Blaming selinux itself for creating what you perceive as a "problem" > because you won't make a rudimentary attempt at learning to properly > manage it is ludicrous. > > Anyone that has an internet facing box that does not take advantage of > each and every security technology at their disposal should be in a > different line of work. And taking advantage of such technologies > requires one to read associated documentation. > > And while this response seems to single you out I mean to point a > finger at anyone out there that doesn't bother to take time to learn > about systems / data that they are responsible for. > > > > > John > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 11:04 PM, Les Mikesell wrote: > On Tue, Jan 3, 2012 at 12:41 AM, Bennett Haselton > wrote: >>> Standard/non-standard isn't the point. The point is to control what an >>> app can do even if some unexpected flaw lets it execute arbitrary >>> code. >> What's the scenario where this port restriction would make a >> difference? Suppose an attacker does find a way to make squid execute >> arbitrary code. Then if part of their plan is to make squid start >> listening on a second port in addition the one it's already using (3128, >> the default), they could just make it listen on another port like 8080 >> which is permitted by SELinux. > You are thinking the wrong direction. No one can anticipate every > possibility that someone might do to take advantage of > vulnerabilities. Instead think in terms of the minimum the > application should be allowed to do under any circumstance. Then > you'll also have firewalls blocking every port except where you know > your own application is listening anyway. I agree about minimum permissions, but my argument here is that permitting squid to "listen" on any arbitrary port it wants is just as "minimum", in terms of security implications, as permitting it to "listen" on port 3128. Either way, once the attacker has connected to it, the scenarios are identical from that point on (either the attacker knows an exploit to take control of squid, or they don't; either the squid process runs with sufficiently high privileges that the exploit can be used to do damage, or it can't). >>>> In other words, when SELinux causes a problem, it can take hours or days >>>> to find out that SELinux is the cause >>> Errr, no - all you have to do is disable SELinux and see if the >>> behavior changes. On your test machine where you should be testing >>> changes, this shouldn't be a big risk. >> Well I meant, if you didn't happen to know enough about SELinux to >> realize that it was the cause of many non-standard system behaviors. If >> you knew about SELinux as one of those things that frequently gets in >> the way, then you'd probably think of it a lot faster :) > Well, the other security rules for linux/unix are trivial, so SELinux > should pop to mind immediately for surprising behavior, especially if > you have changed configurations from the expected defaults. > >> One could easily say, "Hey, you should just know about SELinux", but the >> problem is that there can be dozens of things on a machine that could >> potentially cause failures (without giving a useful error message), and >> each additional thing that you "should just know about", decreases the >> chances that any one person would actually know to check them all, if >> they're not a professional admin. > OK, the point here is that you have some unknown vulnerability that > the stock linux security mechanisms aren't handling. I'm more > inclined to think it is a software bug rather than brute-forcing a > password, but that's speculation. So, which do you think will be more > difficult - tracking down some unknown bug in millions of lines of > code with no real evidence, or adding another layer of security that > is mostly pre-configured in the distro anyway? Well I'm trying to weigh the costs of using it -- with all of the silent failures for operations that have no security implications -- against the reduced risks. If many exploits against httpd, for example, could have been prevented by SELinux, that may make it worth it. (And of course the suggestions about how to diagnose problems caused by SELinux are helpful.) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 7:29 AM, Johnny Hughes wrote: > On 01/02/2012 02:04 AM, Craig White wrote: >> On Sun, 2012-01-01 at 14:23 -0800, Bennett Haselton wrote: >>> (Sorry, third time -- last one, promise, just giving it a subject line!) >>> >>> OK, a second machine hosted at the same hosting company has also apparently >>> been hacked. Since 2 of out of 3 machines hosted at that company have now >>> been hacked, but this hasn't happened to any of the other 37 dedicated >>> servers that I've got hosted at other hosting companies (also CentOS, same >>> version or almost), this makes me wonder if there's a security breach at >>> this company, like if they store customers' passwords in a place that's >>> been hacked. (Of course it could also be that whatever attacker found an >>> exploit, was just scanning that company's address space for hackable >>> machines, and didn't happen to scan the address space of the other hosting >>> companies.) >>> >>> So, following people's suggestions, the machine is disconnected and hooked >>> up to a KVM so I can still examine the files. I've found this file: >>> -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl >>> which appears to be a copy of this exploit script: >>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html >>> Note the last-mod date of October 21. >>> >>> No other files on the system were last modified on October 21st. However >>> there was a security advisory dated October 20th which affected httpd: >>> http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update >>> https://rhn.redhat.com/errata/RHSA-2011-1392.html >>> >>> and a large number of files on the machine, including lots of files in */ >>> usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , >>> have a last-mod date of October 20th. So I assume that these are files >>> which were updated automatically by yum as a result of the patch that goes >>> with this advisory -- does that sound right? >>> >>> So a couple of questions that I could use some help with: >>> >>> 1) The last patch affecting httpd was released on October 20th, and the >>> earliest evidence I can find of the machine being hacked is a file dated >>> October 21st. This could be just a coincidence, but could it also suggest >>> that the patch on October 20th introduced a new exploit, which the attacker >>> then used to get in on October 21st? >>> (Another possibility: I think that when yum installs updates, it >>> doesn't actually restart httpd. So maybe even after the patch was >>> installed, my old httpd instance kept running and was still vulnerable? As >>> for why it got hacked the very next day, maybe the attacker looked at the >>> newly released patch and reverse-engineered it to figure out where the >>> vulnerabilities were, that the patch fixed?) >>> >>> 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 >>> weeks by default, it looks like any log entries related to how the attacker >>> would have gotten in on or before October 21st, are gone. (The secure* >>> logs do show multiple successful logins as "root" within the last 4 weeks, >>> mostly from IP addresses in Asia, but that's to be expected once the >>> machine was compromised -- it doesn't help track down how they originally >>> got in.) Anywhere else that the logs would contain useful data? >> > At this point, I would like to point out that if the machine initially > had ssh access only from subnets where you would have logged in from > then the Asian subnets would have been excluded. (Assuming that the > original attack came from there) > > You can also set up openvpn on the server and control ports like ssh to > only be open to you if you are using an openvpn client to connect to the > machine. True but I travel a lot and sometimes need to connect to the machines from subnets that I don't know about in advance. If I used openvpn to connect, and then connected via ssh over openvpn, this seems like essentially security through obscurity :) by just replacing the public ssh daemon with a different public daemon (with a different connection protocol) which an attacker could try to brute-force the same way they could try to brute-force sshd. However it still seems that this would only matter if the attacker got in by brute-forcing the login. If they obtained
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 7:48 PM, Les Mikesell wrote: > On Mon, Jan 2, 2012 at 8:30 PM, Bennett Haselton > wrote: > >>What apps are those (i.e. the ones that >>> SELinux would have broken) and if they are open source, have those >>> projects updated the app or the underlying language(s)/libraries since >>> you have? >> So here's a perfect example. I installed squid on one machine and >> changed it to listen to a non-standard port instead of 3128. It turns >> out that SELinux blocks this. (Which I still don't see the reasoning >> behind. Why would it be any less secure to run a service on a >> non-standard port? > Standard/non-standard isn't the point. The point is to control what an > app can do even if some unexpected flaw lets it execute arbitrary > code. What's the scenario where this port restriction would make a difference? Suppose an attacker does find a way to make squid execute arbitrary code. Then if part of their plan is to make squid start listening on a second port in addition the one it's already using (3128, the default), they could just make it listen on another port like 8080 which is permitted by SELinux. >> But here's the real problem. Since I didn't know it was caused by >> SELinux, all the cache.log file said was: > Things blocked by SELinux show up in audit.log. I agree that the > SELinux implementation is confusing, but it does give more control > over what apps are allowed to do. > >> In other words, when SELinux causes a problem, it can take hours or days >> to find out that SELinux is the cause > Errr, no - all you have to do is disable SELinux and see if the > behavior changes. On your test machine where you should be testing > changes, this shouldn't be a big risk. Well I meant, if you didn't happen to know enough about SELinux to realize that it was the cause of many non-standard system behaviors. If you knew about SELinux as one of those things that frequently gets in the way, then you'd probably think of it a lot faster :) One could easily say, "Hey, you should just know about SELinux", but the problem is that there can be dozens of things on a machine that could potentially cause failures (without giving a useful error message), and each additional thing that you "should just know about", decreases the chances that any one person would actually know to check them all, if they're not a professional admin. Again, you don't have to take my word for it -- in the first 10 Google hits of pages with people posting about the problem I ran into, none of the people helping them, thought to suggest SELinux as the cause of the problem. (By contrast, when iptables causes a problem, people usually figure out that's what's going on.) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 8:11 PM, RILINDO FOSTER wrote: > On Jan 2, 2012, at 9:30 PM, Bennett Haselton wrote: > >> On 1/2/2012 9:18 AM, Les Mikesell wrote: >>> On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haselton >>> wrote: >>>> I tried SELinux but it broke so much needed functionality on the server >>>> that it was not an option. >>> Pretty much all of the stock programs work with SELinux, so this by >>> itself implies that you are running 3rd party or local apps that have >>> write access in non-standard places. Which is a good start at what >>> you need to break in. What apps are those (i.e. the ones that >>> SELinux would have broken) and if they are open source, have those >>> projects updated the app or the underlying language(s)/libraries since >>> you have? >> So here's a perfect example. I installed squid on one machine and >> changed it to listen to a non-standard port instead of 3128. It turns >> out that SELinux blocks this. (Which I still don't see the reasoning >> behind. Why would it be any less secure to run a service on a >> non-standard port? A lot of sources say it's *more* secure to run >> services on a non-standard port if you don't want people poking around! >> In general I don't think it's any more secure to run a service on a >> non-standard port -- all it buys you is time, as it's trivial for an >> attacker to scan all your ports, especially with a botnet -- but even if >> it's not more secure, it certainly shouldn't be *less* secure.) >> >> But here's the real problem. Since I didn't know it was caused by >> SELinux, all the cache.log file said was: >> >> 2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum >> redacted]: (13) Permission denied >> >> Nothing indicating why. Even worse, if you Google >> +squid +"cannot bind socket" +"permission denied" >> *none* of the first ten pages that come up, mention SELinux as a >> possible source of the problem. (One FAQ mentions SELinux but only as >> the source of a different problem.) All they do is recommend other >> workarounds, each of which takes time to test out, and may have other >> side-effects. >> >> In other words, when SELinux causes a problem, it can take hours or days >> to find out that SELinux is the cause -- and even then you're not done, >> because you have to figure out a workaround if you want to fix the >> problem while keeping SELinux turned on. >> > How is it SELinux's problem? Its like running iptables with the default http > ports open and then blaming iptables when you change Apache to a non-standard > port. Well for one thing, if you knew iptables was running and you knew what it was, you might suspect that it's the cause of the problem, since that's the kind of thing iptables is supposed to block. On the other hand, if you knew that SELinux is a security enforcement system, it's much less likely to come to mind as the reason why squid can't run on a different port, since this achieves nothing for the security of your system. Don't take my word for it, you can google for people asking about such problems. If someone reports a problem with port blockage that is caused by iptables, at least some users will usually suggest iptables as the issue. On the other hand, when I googled for my error which was caused by SELinux, nobody in the first ten pages of suggestions knew that SELinux could cause this. So I stand by the statement that SELinux is more likely to cause problems that are hard to figure out for people who aren't professional admins. And then there's the fact that solving a problem caused by iptables is usually trivial, while every problem caused by SELinux has a different solution. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 9:18 AM, Les Mikesell wrote:
> There have been many, many vulnerabilities that permit local user
> privilege escalation to root (in the kernel, glibc, suid programs,
> etc.) and there are probably many we still don't know about. They
> often require writing to the filesystem. For example, one fixed around
> 5.4 just required the ability to make a symlink somewhere. The
> published exploit script (which I've seen in the wild) tries to use
> /tmp. If the httpd process can't write in /tmp, it would fail.
>
So are you saying that SELinux is supposed to prevent httpd from writing
to /tmp ?
Because I just tested that and SELinux didn't appear to stop it. I set
selinux to "enforcing", rebooted just to make sure, and put this perl
script on my webserver:
#!/usr/bin/perl
use IO::File;
use strict;
my $fh = IO::File->new("> /tmp/foo.txt");
close($fh);
print "Content-type: text/html\n\nDone.\n";
then invoked it from the web, and this file was created:
[root@g6950-21025 ~]# ls -l /tmp/foo.txt
-rw-r--r-- 1 apache apache 0 Jan 2 16:47 /tmp/foo.txt
[root@g6950-21025 ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
So it looks like SELinux in this case does not prevent httpd from
writing to /tmp , in which case it would not have prevented the exploit
you're referring to. Or am I missing something?
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 9:18 AM, Les Mikesell wrote: > On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haselton > wrote: >> I tried SELinux but it broke so much needed functionality on the server >> that it was not an option. > Pretty much all of the stock programs work with SELinux, so this by > itself implies that you are running 3rd party or local apps that have > write access in non-standard places. Which is a good start at what > you need to break in. What apps are those (i.e. the ones that > SELinux would have broken) and if they are open source, have those > projects updated the app or the underlying language(s)/libraries since > you have? So here's a perfect example. I installed squid on one machine and changed it to listen to a non-standard port instead of 3128. It turns out that SELinux blocks this. (Which I still don't see the reasoning behind. Why would it be any less secure to run a service on a non-standard port? A lot of sources say it's *more* secure to run services on a non-standard port if you don't want people poking around! In general I don't think it's any more secure to run a service on a non-standard port -- all it buys you is time, as it's trivial for an attacker to scan all your ports, especially with a botnet -- but even if it's not more secure, it certainly shouldn't be *less* secure.) But here's the real problem. Since I didn't know it was caused by SELinux, all the cache.log file said was: 2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum redacted]: (13) Permission denied Nothing indicating why. Even worse, if you Google +squid +"cannot bind socket" +"permission denied" *none* of the first ten pages that come up, mention SELinux as a possible source of the problem. (One FAQ mentions SELinux but only as the source of a different problem.) All they do is recommend other workarounds, each of which takes time to test out, and may have other side-effects. In other words, when SELinux causes a problem, it can take hours or days to find out that SELinux is the cause -- and even then you're not done, because you have to figure out a workaround if you want to fix the problem while keeping SELinux turned on. -Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] 'last' command doesn't include ssh connections made by this perl script?
My home machine has IP 50.54.225.130. I have (for the purposes of this
experiment) one remote machine at www.peacefire.org (69.72.177.140) and
another at www.junkwhale.com.
When I'm logged in to peacefire, I run this perl script to open an ssh
connection to junkwhale and run a command:
my $hostname="www.junkwhale.com";
my $server_password = "[redacted!]";
use Net::SFTP;
use Net::SSH::Perl;
my $ssh = Net::SSH::Perl->new($hostname);
$ssh->login("root", $server_password);
my($stdout, $stderr, $exit) = $ssh->cmd("pwd");
print "Stdout: $stdout\n";
print "Stderr: $stderr\n";
If I then log in by ssh to junkwhale from my home computer and run
grep 'Accepted password' /var/log/secure
the last two lines are:
Jan 2 13:23:17 e2180-20059 sshd[12635]: Accepted password for root from
69.72.177.140 port 1023 ssh2
Jan 2 13:23:28 e2180-20059 sshd[12684]: Accepted password for root from
50.54.225.130 port 52484 ssh2
which is correct -- the first line is from the perl script connecting from
Peacefire (69.72.177.140) and the second line is for the connection I just
opened from my home computer.
If, however, I run the "last" command, the first two lines are just:
root pts/050-54-225-130.ev Mon Jan 2 13:23 still logged in
root pts/050-54-225-130.ev Mon Jan 2 01:52 - 01:52 (00:00)
In other words, the "last" command doesn't list the connection opened up by
the Perl script. It only lists the times that I've connected by opening a
connection manually with my SSH client. Presumably that means the
connection with the perl script is not being logged in /var/log/wtmp ,
although the contents of the file are binary so I couldn't make much sense
of them directly with a screen dump.
This makes me wonder two things:
1) What is the difference, from the server's point of view, between the
connection opened by the script and the one opened by my ssh client; and
2) More seriously, whatever it is that's different about the connection
opened by the perl script, isn't it a bug that that connection is not
recorded in wtmp? If admins frequently use the "last" command to determine
who has logged into the server, couldn't an attacker do this to avoid
detection?
Bennett
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 6:04 PM, Ljubomir Ljubojevic wrote: > On 01/02/2012 02:50 AM, Bennett Haselton wrote: > > I'm not sure what you mean by "an exploit from a web board which is > > apparently designed to pull outside traffic". Like Ljubomir said, it > looks > > like a script that is used from machine X to DOS attack machine Y, if > > machine Y has the VBulletin bulletin board software installed on it. Is > > that what you meant?:) > > > > But anyway, since the file was located at /home/file.pl (and since > attacker > > had console access), presumably it wasn't being invoked by the web > server, > > only from the command line. So how would it have made any difference if > > httpd was running in its own context, if that script was not being > invoked > > by httpd? > > Nobody of us really knows how they got in. All you will get from this > mailing list will be speculations, apart from useful instructions how to > gather as much info as possible. Speculation is fine, I'm interested in any method that the attacker *could* have used to get in to the server if it's *logically possible* that the attack could have had a non-trivial chance of working. (If they could have gotten in by method A, and they could have gotten in by method B, then regardless of which they DID use, I should still try to fix both A and B.) But that still excludes things like "they got in because you used a password instead of an ssh key", as I have said many times why a 12-character random alphanumeric password (with 10^24 possible values) is secure enough even with the most pessimistic assumptions about botnets and GPUs. > So there are many possible ways they > got in including brute force. Knowing that it was a 12-character random alphanumeric password, do you still think it could have been done by brute force? > As I understood you, you do not use > neither fail2ban, denyhosts or/and logwatch, and you haven't checked > those two servers very much in recent months. > > What Rilindo is saying is that SELinux might detect exploits while their > trying to break processes from their routine (allowed by SELinux), and > all of this (if it happened via exploits) might have been prevented by > SELinux. You really do have lot of gaps in your security. A couple of people have pointed out "gaps" in what I was doing for *detection and analysis* after the fact (don't wipe a machine after it's hacked, have logs going back further than 4 weeks, have the logs backed up off-site, etc.), and that's useful. But as far as I can tell nobody has really pointed out any "gap" in what I'm doing on the *prevention* side. To focus on one exact question: What is a *preventive* measure that you think I am not doing, that you think would reduce the chance of a break-in, in some specific scenario? Take fail2ban and denyhosts, which block connections from IPs that make too many invalid ssh logins. In the scenario where the attacker is trying to brute-force the login, then if your ssh login password is already un-bruteforceable, then blocking connections from IPs that are making too many invalid attempts, will not reduce the chance of an attacker brute-force (which is already essentially zero). Do you think I'm incorrect that fail2ban and/or denyhosts (and switching from passwords to ssh keys) do not reduce the chance of a breakin, if your ssh password is a truly random mixed-case-alphanumeric 12-character string? If you think this is incorrect, why? > If I were you, > I would use all advice's given to you here and secure the rest of your > servers (SELinux, fail2ban/denyhosts, logwatch, rsyslog, etc..) > I tried SELinux but it broke so much needed functionality on the server that it was not an option. There are many, many issues where all the forum discussions about how to solve the problem, just end with "Just turn off selinux", and nobody apparently has any other idea how to solve it. But in any case, what exactly does it do for httpd security, that isn't already accomplished by having httpd run as the unprivileged "apache" user? You said SELinux could prevent an exploit from "breaking a process from its routine". But even without SELinux, an attacker who found an exploit that could take control of httpd and make it try any action he wanted, still wouldn't be able to actually do anything while running as "apache", would they? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Mon, Jan 2, 2012 at 12:04 AM, Craig White wrote: > On Sun, 2012-01-01 at 14:23 -0800, Bennett Haselton wrote: > > (Sorry, third time -- last one, promise, just giving it a subject line!) > > > > OK, a second machine hosted at the same hosting company has also > apparently > > been hacked. Since 2 of out of 3 machines hosted at that company have > now > > been hacked, but this hasn't happened to any of the other 37 dedicated > > servers that I've got hosted at other hosting companies (also CentOS, > same > > version or almost), this makes me wonder if there's a security breach at > > this company, like if they store customers' passwords in a place that's > > been hacked. (Of course it could also be that whatever attacker found an > > exploit, was just scanning that company's address space for hackable > > machines, and didn't happen to scan the address space of the other > hosting > > companies.) > > > > So, following people's suggestions, the machine is disconnected and > hooked > > up to a KVM so I can still examine the files. I've found this file: > > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > > which appears to be a copy of this exploit script: > > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > > Note the last-mod date of October 21. > > > > No other files on the system were last modified on October 21st. However > > there was a security advisory dated October 20th which affected httpd: > > > http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update > > https://rhn.redhat.com/errata/RHSA-2011-1392.html > > > > and a large number of files on the machine, including lots of files in */ > > usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , > > have a last-mod date of October 20th. So I assume that these are files > > which were updated automatically by yum as a result of the patch that > goes > > with this advisory -- does that sound right? > > > > So a couple of questions that I could use some help with: > > > > 1) The last patch affecting httpd was released on October 20th, and the > > earliest evidence I can find of the machine being hacked is a file dated > > October 21st. This could be just a coincidence, but could it also > suggest > > that the patch on October 20th introduced a new exploit, which the > attacker > > then used to get in on October 21st? > > (Another possibility: I think that when yum installs updates, it > > doesn't actually restart httpd. So maybe even after the patch was > > installed, my old httpd instance kept running and was still vulnerable? > As > > for why it got hacked the very next day, maybe the attacker looked at the > > newly released patch and reverse-engineered it to figure out where the > > vulnerabilities were, that the patch fixed?) > > > > 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 > > weeks by default, it looks like any log entries related to how the > attacker > > would have gotten in on or before October 21st, are gone. (The secure* > > logs do show multiple successful logins as "root" within the last 4 > weeks, > > mostly from IP addresses in Asia, but that's to be expected once the > > machine was compromised -- it doesn't help track down how they originally > > got in.) Anywhere else that the logs would contain useful data? > > the particular issue which was patched by this httpd (apache) update was > to fix a problem with reverse proxy so the first question is did this > server actually have a reverse proxy configured? > I'm not exactly sure how to tell but httpd.conf contains the lines LoadModule proxy_module modules/mod_proxy.so LoadModule cache_module modules/mod_cache.so so I think that means the answer is yes. > My next thought is that since this particular hacker managed to get > access to more than one of your machines, is it possible that there is a > mechanism (ie a pre-shared public key) that would allow them access to > the second server from the first server they managed to crack? The point > being that this computer may not have been the one that they originally > cracked and there may not be evidence of cracking on this computer. > OK, no I don't have pre-shared keys or any other link between them. > The script you identified would seem to be a script for attacking other > systems and by the time it landed on your system, it was already broken > into. Yes. That's what I've be
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 6:03 PM, Fajar Priyanto wrote: > On Mon, Jan 2, 2012 at 9:33 AM, RILINDO FOSTER wrote: > > The script in question is an exploit from a web board which is > apparently designed to pull outside traffic. If you had SELinux, it would > put httpd in its own context and by default, it will NOT allow connections > from that context to another. You have to enable it with: > > The only time my server got hacked was because of phpBB. Using > cross-site scripting, the hacker managed to put a pl file and when I > ran it, it opened a console. > Apparently you are running one of the web boards. > I'm not running phpBB or vBulletin. The script apparently runs on machine X to attack a *different* machine Y where machine Y has vBulletin installed on it. > Pls follow up any > security advisories of that product and any addon/module closely. > > If you are really curious how yours got hack. You can setup similar > system and put a bounty (maybe $1000) in one of the underground > community for anyone to hack it and tell you how they do it. > > > Is there a non-"underground" place to post such requests? It's not illegal to offer a bounty to someone for finding a security hole in your system -- Facebook, Google, and Mozilla all do it. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 5:01 PM, Les Mikesell wrote: > On Sun, Jan 1, 2012 at 4:23 PM, Bennett Haselton > wrote: > > > > So, following people's suggestions, the machine is disconnected and > hooked > > up to a KVM so I can still examine the files. I've found this file: > > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > > which appears to be a copy of this exploit script: > > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > > Note the last-mod date of October 21. > > Did you do an rpm -Va to see if any installed files were modified > besides your own changes? Even better if you have an old backup that > you can restore somewhere and run an rsync -avn against the old/new > instances. > rpm -Va gives: L... c /etc/pam.d/system-auth S.5T c /etc/httpd/conf.d/ssl.conf SM5...GT c /etc/squid/squid.conf S.5T c /etc/login.defs S.5T c /etc/ssh/sshd_config S.5T c /etc/httpd/conf.d/welcome.conf S.5T c /etc/httpd/conf/httpd.conf S.5. c /etc/ldap.conf S.5. c /etc/openldap/ldap.conf L... c /etc/pam.d/system-auth ...T c /etc/audit/auditd.conf S.5T c /etc/printcap S.5T c /etc/yum/yum-updatesd.conf S.5. c /etc/ldap.conf S.5. c /etc/openldap/ldap.conf According to http://www.rpm.org/max-rpm/s1-rpm-verify-output.html many config files do not verify successfully (and I recognize some of them from modifying them manually, and others presumably could have been modified by the hosting company). I don't have a backup since there is no data stored only on the machine, so if anything is lost on the machine I just ask the host to re-format it and then re-upload everything. > > Anywhere else that the logs would contain useful data? > > /root/.bash_history might be interesting. Obviously this would be > after the fact, but maybe they are trying to repeat the exploit with > this machine as a base. > > > Good idea but it only shows the commands that I've run since logging in to try and find out what happened. Perhaps the attacker wiped /root/.bash_history after getting in. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 5:33 PM, RILINDO FOSTER wrote: > ≈On Jan 1, 2012, at 8:24 PM, Bennett Haselton wrote: > > > On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster wrote: > > > >> > >> > >> On Jan 1, 2012, at 5:23 PM, Bennett Haselton > >> wrote: > >> > >>> (Sorry, third time -- last one, promise, just giving it a subject > line!) > >>> > >>> OK, a second machine hosted at the same hosting company has also > >> apparently > >>> been hacked. Since 2 of out of 3 machines hosted at that company have > >> now > >>> been hacked, but this hasn't happened to any of the other 37 dedicated > >>> servers that I've got hosted at other hosting companies (also CentOS, > >> same > >>> version or almost), this makes me wonder if there's a security breach > at > >>> this company, like if they store customers' passwords in a place that's > >>> been hacked. (Of course it could also be that whatever attacker found > an > >>> exploit, was just scanning that company's address space for hackable > >>> machines, and didn't happen to scan the address space of the other > >> hosting > >>> companies.) > >>> > >>> So, following people's suggestions, the machine is disconnected and > >> hooked > >>> up to a KVM so I can still examine the files. I've found this file: > >>> -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > >>> which appears to be a copy of this exploit script: > >>> http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > >>> Note the last-mod date of October 21. > >>> > >>> No other files on the system were last modified on October 21st. > However > >>> there was a security advisory dated October 20th which affected httpd: > >>> > >> > http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update > >>> https://rhn.redhat.com/errata/RHSA-2011-1392.html > >>> > >>> and a large number of files on the machine, including lots of files in > */ > >>> usr/lib64/httpd/modules/* and > */lib/modules/2.6.18-274.7.1.el5/kernel/* , > >>> have a last-mod date of October 20th. So I assume that these are files > >>> which were updated automatically by yum as a result of the patch that > >> goes > >>> with this advisory -- does that sound right? > >>> > >>> So a couple of questions that I could use some help with: > >>> > >>> 1) The last patch affecting httpd was released on October 20th, and the > >>> earliest evidence I can find of the machine being hacked is a file > dated > >>> October 21st. This could be just a coincidence, but could it also > >> suggest > >>> that the patch on October 20th introduced a new exploit, which the > >> attacker > >>> then used to get in on October 21st? > >>> (Another possibility: I think that when yum installs updates, it > >>> doesn't actually restart httpd. So maybe even after the patch was > >>> installed, my old httpd instance kept running and was still vulnerable? > >> As > >>> for why it got hacked the very next day, maybe the attacker looked at > the > >>> newly released patch and reverse-engineered it to figure out where the > >>> vulnerabilities were, that the patch fixed?) > >>> > >>> 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back > 4-5 > >>> weeks by default, it looks like any log entries related to how the > >> attacker > >>> would have gotten in on or before October 21st, are gone. (The secure* > >>> logs do show multiple successful logins as "root" within the last 4 > >> weeks, > >>> mostly from IP addresses in Asia, but that's to be expected once the > >>> machine was compromised -- it doesn't help track down how they > originally > >>> got in.) Anywhere else that the logs would contain useful data? > >>> ___ > >>> CentOS mailing list > >>> CentOS@centos.org > >>> http://lists.centos.org/mailman/listinfo/centos > >> > >> Do you have SELinux enabled? If not, you might need to turn that on, as > >> that would have prevented that exploit. > >> > >> &g
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 4:57 PM, Rilindo Foster wrote: > > > On Jan 1, 2012, at 5:23 PM, Bennett Haselton > wrote: > > > (Sorry, third time -- last one, promise, just giving it a subject line!) > > > > OK, a second machine hosted at the same hosting company has also > apparently > > been hacked. Since 2 of out of 3 machines hosted at that company have > now > > been hacked, but this hasn't happened to any of the other 37 dedicated > > servers that I've got hosted at other hosting companies (also CentOS, > same > > version or almost), this makes me wonder if there's a security breach at > > this company, like if they store customers' passwords in a place that's > > been hacked. (Of course it could also be that whatever attacker found an > > exploit, was just scanning that company's address space for hackable > > machines, and didn't happen to scan the address space of the other > hosting > > companies.) > > > > So, following people's suggestions, the machine is disconnected and > hooked > > up to a KVM so I can still examine the files. I've found this file: > > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > > which appears to be a copy of this exploit script: > > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > > Note the last-mod date of October 21. > > > > No other files on the system were last modified on October 21st. However > > there was a security advisory dated October 20th which affected httpd: > > > http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update > > https://rhn.redhat.com/errata/RHSA-2011-1392.html > > > > and a large number of files on the machine, including lots of files in */ > > usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , > > have a last-mod date of October 20th. So I assume that these are files > > which were updated automatically by yum as a result of the patch that > goes > > with this advisory -- does that sound right? > > > > So a couple of questions that I could use some help with: > > > > 1) The last patch affecting httpd was released on October 20th, and the > > earliest evidence I can find of the machine being hacked is a file dated > > October 21st. This could be just a coincidence, but could it also > suggest > > that the patch on October 20th introduced a new exploit, which the > attacker > > then used to get in on October 21st? > >(Another possibility: I think that when yum installs updates, it > > doesn't actually restart httpd. So maybe even after the patch was > > installed, my old httpd instance kept running and was still vulnerable? > As > > for why it got hacked the very next day, maybe the attacker looked at the > > newly released patch and reverse-engineered it to figure out where the > > vulnerabilities were, that the patch fixed?) > > > > 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 > > weeks by default, it looks like any log entries related to how the > attacker > > would have gotten in on or before October 21st, are gone. (The secure* > > logs do show multiple successful logins as "root" within the last 4 > weeks, > > mostly from IP addresses in Asia, but that's to be expected once the > > machine was compromised -- it doesn't help track down how they originally > > got in.) Anywhere else that the logs would contain useful data? > > ___ > > CentOS mailing list > > CentOS@centos.org > > http://lists.centos.org/mailman/listinfo/centos > > Do you have SELinux enabled? If not, you might need to turn that on, as > that would have prevented that exploit. > > I don't, but I'm not sure what you mean by "that would have prevented that exploit". How do you know what exploit they used, much less that SELinux would have prevented it? Or are you assuming that my guess was correct that they got in because of a vulnerability that was opened up by the patch being auto-installed on 10/20, and that if *that* is the case, that SELinux would have prevented that? How does that work, how would SELinux have prevented a vulnerability being opened up by the patch install? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Sun, Jan 1, 2012 at 2:55 PM, Eero Volotinen wrote: > 2012/1/2 Bennett Haselton : > > (Sorry, third time -- last one, promise, just giving it a subject line!) > > > > OK, a second machine hosted at the same hosting company has also > apparently > > been hacked. Since 2 of out of 3 machines hosted at that company have > now > > been hacked, but this hasn't happened to any of the other 37 dedicated > > servers that I've got hosted at other hosting companies (also CentOS, > same > > version or almost), this makes me wonder if there's a security breach at > > this company, like if they store customers' passwords in a place that's > > been hacked. (Of course it could also be that whatever attacker found an > > exploit, was just scanning that company's address space for hackable > > machines, and didn't happen to scan the address space of the other > hosting > > companies.) > > > > So, following people's suggestions, the machine is disconnected and > hooked > > up to a KVM so I can still examine the files. I've found this file: > > -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl > > which appears to be a copy of this exploit script: > > http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html > > Note the last-mod date of October 21. > > > > No other files on the system were last modified on October 21st. However > > there was a security advisory dated October 20th which affected httpd: > > > http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update > > https://rhn.redhat.com/errata/RHSA-2011-1392.html > > > > and a large number of files on the machine, including lots of files in */ > > usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , > > have a last-mod date of October 20th. So I assume that these are files > > which were updated automatically by yum as a result of the patch that > goes > > with this advisory -- does that sound right? > > > > So a couple of questions that I could use some help with: > > > > 1) The last patch affecting httpd was released on October 20th, and the > > earliest evidence I can find of the machine being hacked is a file dated > > October 21st. This could be just a coincidence, but could it also > suggest > > that the patch on October 20th introduced a new exploit, which the > attacker > > then used to get in on October 21st? > >(Another possibility: I think that when yum installs updates, it > > doesn't actually restart httpd. So maybe even after the patch was > > installed, my old httpd instance kept running and was still vulnerable? > As > > for why it got hacked the very next day, maybe the attacker looked at the > > newly released patch and reverse-engineered it to figure out where the > > vulnerabilities were, that the patch fixed?) > > > > 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 > > weeks by default, it looks like any log entries related to how the > attacker > > would have gotten in on or before October 21st, are gone. (The secure* > > logs do show multiple successful logins as "root" within the last 4 > weeks, > > mostly from IP addresses in Asia, but that's to be expected once the > > machine was compromised -- it doesn't help track down how they originally > > got in.) Anywhere else that the logs would contain useful data? > > sshd with root login enabled with very bad password? > > Forgot to mention: the root password was: 1WyJstJZnQ!j (I have since changed it). (I have already practically worn out my keyboard explaining the math behind why I think a 12-character alphanumeric password is secure enough :) ) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] an actual hacked machine, in a preserved state
(Sorry, third time -- last one, promise, just giving it a subject line!) OK, a second machine hosted at the same hosting company has also apparently been hacked. Since 2 of out of 3 machines hosted at that company have now been hacked, but this hasn't happened to any of the other 37 dedicated servers that I've got hosted at other hosting companies (also CentOS, same version or almost), this makes me wonder if there's a security breach at this company, like if they store customers' passwords in a place that's been hacked. (Of course it could also be that whatever attacker found an exploit, was just scanning that company's address space for hackable machines, and didn't happen to scan the address space of the other hosting companies.) So, following people's suggestions, the machine is disconnected and hooked up to a KVM so I can still examine the files. I've found this file: -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl which appears to be a copy of this exploit script: http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html Note the last-mod date of October 21. No other files on the system were last modified on October 21st. However there was a security advisory dated October 20th which affected httpd: http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update https://rhn.redhat.com/errata/RHSA-2011-1392.html and a large number of files on the machine, including lots of files in */ usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , have a last-mod date of October 20th. So I assume that these are files which were updated automatically by yum as a result of the patch that goes with this advisory -- does that sound right? So a couple of questions that I could use some help with: 1) The last patch affecting httpd was released on October 20th, and the earliest evidence I can find of the machine being hacked is a file dated October 21st. This could be just a coincidence, but could it also suggest that the patch on October 20th introduced a new exploit, which the attacker then used to get in on October 21st? (Another possibility: I think that when yum installs updates, it doesn't actually restart httpd. So maybe even after the patch was installed, my old httpd instance kept running and was still vulnerable? As for why it got hacked the very next day, maybe the attacker looked at the newly released patch and reverse-engineered it to figure out where the vulnerabilities were, that the patch fixed?) 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 weeks by default, it looks like any log entries related to how the attacker would have gotten in on or before October 21st, are gone. (The secure* logs do show multiple successful logins as "root" within the last 4 weeks, mostly from IP addresses in Asia, but that's to be expected once the machine was compromised -- it doesn't help track down how they originally got in.) Anywhere else that the logs would contain useful data? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] (no subject)
(Tried sending this before but it doesn't look like it went through; apologies if you're seeing it twice.) OK, a second machine hosted at the same hosting company has also apparently been hacked. Since 2 of out of 3 machines hosted at that company have now been hacked, but this hasn't happened to any of the other 37 dedicated servers that I've got hosted at other hosting companies (also CentOS, same version or almost), this makes me wonder if there's a security breach at this company, like if they store customers' passwords in a place that's been hacked. (Of course it could also be that whatever attacker found an exploit, was just scanning that company's address space for hackable machines, and didn't happen to scan the address space of the other hosting companies.) So, following people's suggestions, the machine is disconnected and hooked up to a KVM so I can still examine the files. I've found this file: -rw-r--r-- 1 root root 1358 Oct 21 17:40 /home/file.pl which appears to be a copy of this exploit script: http://archive.cert.uni-stuttgart.de/bugtraq/2006/11/msg00302.html Note the last-mod date of October 21. No other files on the system were last modified on October 21st. However there was a security advisory dated October 20th which affected httpd: http://mailinglist-archive.com/centos-announce/2011-10/00035-CentOSannounce+CESA20111392+Moderate+CentOS+5+i386+httpd+Update https://rhn.redhat.com/errata/RHSA-2011-1392.html and a large number of files on the machine, including lots of files in */ usr/lib64/httpd/modules/* and */lib/modules/2.6.18-274.7.1.el5/kernel/* , have a last-mod date of October 20th. So I assume that these are files which were updated automatically by yum as a result of the patch that goes with this advisory -- does that sound right? So a couple of questions that I could use some help with: 1) The last patch affecting httpd was released on October 20th, and the earliest evidence I can find of the machine being hacked is a file dated October 21st. This could be just a coincidence, but could it also suggest that the patch on October 20th introduced a new exploit, which the attacker then used to get in on October 21st? (Another possibility: I think that when yum installs updates, it doesn't actually restart httpd. So maybe even after the patch was installed, my old httpd instance kept running and was still vulnerable? As for why it got hacked the very next day, maybe the attacker looked at the newly released patch and reverse-engineered it to figure out where the vulnerabilities were, that the patch fixed?) 2) Since the */var/log/httpd/* and /var/log/secure* logs only go back 4-5 weeks by default, it looks like any log entries related to how the attacker would have gotten in on or before October 21st, are gone. (The secure* logs do show multiple successful logins as "root" within the last 4 weeks, mostly from IP addresses in Asia, but that's to be expected once the machine was compromised -- it doesn't help track down how they originally got in.) Anywhere else that the logs would contain useful data? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] why not have yum-updatesd running by default?
On Thu, Dec 29, 2011 at 10:49 AM, Les Mikesell wrote: > > Would it not be best for the vast majority of those users to have updates > > turned on by default? If not, why not? (Power users can always turn > them > > off, after all.) > > If your service is important, then it is worth testing changes before > making them on your important server. But no one else can tell you > whether your server is that important or not... It's fairly trivial > to run a 'yum update' on a lab server daily, and if anything updates, > make sure that things still work before repeating it on the production > box(es). The update checks can be scripted, but the "does it still > work" test will be unique to your services. > But these are all considerations mainly for power users; I'm still talking just about the vast majority of hosting company customers who just lease a dedicated or virtual private server, and don't even have a "test server" and a "production server". Why wouldn't it be best for those servers just to pick up and install updates automatically? > > What would your proposal be? (Remembering that you can't change human > > nature, so if it relies on the majority of end users devoting time that > you > > think they "should" do, it won't happen :) ) > > Mine is to assume that there are very good reasons for 'Enterprise' > distributions to go to the trouble of publishing updates. Install > them. Always assume that there are still more vulnerabilities that > you don't know about yet - and if you have to ask the question, you > aren't going to do better than the developers and Red Hat at keeping > up with them. > > > Yes this is good advice for the individual user; what I was asking is what set of *defaults* would improve security the most for the vast majority of users (who cannot be counted on to change defaults -- or, indeed, to follow any advice that anyone thinks "everyone" "should" do!). ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Wed, Dec 28, 2011 at 6:10 AM, Johnny Hughes wrote: > On 12/27/2011 10:42 PM, Bennett Haselton wrote: > > Everything installed on the machine had been installed with "yum". So I > > assumed that meant that it would also be updated by "yum" if an update > was > > available from the distro. > > > > 1. Are you running PHP apps on the web server? Perl apps? Bad code in > dynamic apps is the main way security breaches happen if via apache. > And in those cases is usually the ability to execute some script > (sometimes one that the bad guys upload first) that is the issue. Many > times this happens because programmers of the dynamic (php, perl, > python, ruby, etc.) do not properly vet the input of some form or other > item. > The only popular third-party script on the server was glype from www.glype.com. I don't know if it's popular enough (compared to, say, WordPress) to make it worthwhile for the bad guys to have developed an exploit against it. On the other hand, if they used an automated tool that can be pointed to *any* PHP script and probe it for weaknesses, they could have found something. > > > 2. Why have password logins at all? Using a secure ssh key only for > logins makes the most sense. > Well that's something that I'm curious about the reasoning behind -- if you're already using a completely random 12-character password, why would it be any more secure to use an ssh key? Even though the ssh key is more random, they're both sufficiently random that it would take at least hundreds of years to get in by trial and error. > > 3. Please do not top post. > My bad. Gmail default. :) > > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] why not have yum-updatesd running by default?
On Wed, Dec 28, 2011 at 11:33 AM, Jim Wildman wrote: > The 'E' in CentOS stands for Enterprise. Enterprises use change > control. Servers do not update themselves whenever they see an update. > Updates are tested (not so much), approved and scheduled, hopefully in > line with a maintenance window. In most enterprises that I've been in, > a server can't even contact the default repo servers. And remember that > for a RHEL server, it has to be registered with RHN before it can > officially receive updates. Defaulting yum-updatesd to on will be a no-op > in almost every 'enterprise' case. > > Enterprises also don't hang servers directly off the Internet. There > are many layers betwixt the wild web and the OS. > > In the decade plus that I've been running RHEL, I've seen 1 update that > was worthy of an emergency change to push it out RIGHT NOW to the > servers. And even that one didn't really need to be done. > > -- > Jim Wildman, CISSP, RHCE j...@rossberry.com http://www.rossberry.net > "Society in every state is a blessing, but Government, even in its best > state, is a necessary evil; in its worst state, an intolerable one." > Thomas Paine > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > To be more clear, I wasn't saying that for the particular people on this list, of whom many are professional sysadmins, that it would be the best option. I'm talking about the majority of users who have leased a dedicated server or a VPS for $5-$50 per month, and cannot ever be realistically expected to change much of the defaults. In that situation, you're weighing the likelihood, and the undesirability, of two outcomes: either (1) the machine ends up going down temporarily because of a bad update, or (2) the machine ends up being hacked and attacking other networks because it wasn't receiving updates. (Side note: my friend replied to clarify that the "kernel exploit" he was talking about that was found in March of this year, was one that allowed a local user to gain root privilege, not one that allowed a remote user to get in through the webserver or sshd. So let's say it really is true that running automatic "yum" updates is not the most important thing to keep out remote users, and that the majority of webserver hacks do occur through out-of-date web apps. Then replace everything I said with "update the web apps" instead of installing the "yum update" patches.) Would it not be best for the vast majority of those users to have updates turned on by default? If not, why not? (Power users can always turn them off, after all.) Look, one may think that root access to dedicated servers (and virtual/dedicated servers, which are almost as powerful/dangerous) should never be given out to people who haven't been professionally trained. (Some people still say that about net-connected computers generally!) But that can never be rolled back now, as long as hosting companies can legally sell unmanaged dedicated/VPS machines to the public, they will. So what can be done to reduce the risks? Or look at it this way: Suppose the government or some foundation offered a $1 million prize for any proposal that permanently lowered the rate at which CentOS servers were compromised. If you actually come up with a solution that lowers the rate, you get the money, but if you say that all end users "should" do such-and-such (and they don't), then you get nothing. What would your proposal be? My suggestion would be: 1) Implement an API call on the OS for "send this message to the machine owner". When the OS is installed on the machine, the person installing it decides how the "notify" call would be implemented -- send an email to an address, send a SMS message, whatever. If a hosting company sets it up, they could implement the call so that it automatically opens a new support ticket waiting for the customer's attention. The reason for #1 is that if the OS wants to notify the machine admin that there's a problem, then -- at least in the case of a remotely hosted cheap server or VPS -- you can't rely on the admin logging in and seeing the message. You have to proactively grab their attention somehow. Then you could use this function call for lots of things, but most importantly for #2: 2) Implement some sort of scanner program (enabled by default) that would regularly scan the machine, not just for known viruses, but for *anything* that was known to be a frequent vector for attacks, that was not configured to update itself automatically. And: - If the scanner finds an app that is not configured to update itself automatically, it sends a low-priority message (using #1) saying "There are no known exploits for this thing right now, but you really ought to turn on updates for it." - If the scanner finds a web app like WordPress that *cannot* update itself a
[CentOS] why not have yum-updatesd running by default?
Ever since someone told me that one of my servers might have been hacked (not the most recent instance) because I wasn't applying updates as soon as they became available, I've been logging in and running "yum update" religiously once a week until I found out how to set the yum-updatesd service to do the equivalent automatically (once per hour, I think). Since then, I've leased dedicated servers from several different companies, and on all of them, I had to set up yum-updatesd to run and check for updates -- by default it was off. Why isn't it on by default? Or is it being considered to make it the default in the future? Power users can always change it if they want; the question is what would be better for the vast majority of users who don't change defaults. In that case it would seem better to have updates on, so that they'll get patched if an exploit is released but a patch is available. If the risk is that a buggy update might crash the machine, then that has to be weighed against the possibility of *not* getting updates, and getting hacked as a result -- usually the latter being worse. After all, if users are exhorted to log in to their machines and check for updates and apply them, that implies that the risk of getting hosed by a buggy update is outweighed by the risk of getting hacked by not applying updates. If that's true for updates that are applied manually, it ought to be true for updates that are downloaded and applied automatically, shouldn't it? Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Tue, Dec 27, 2011 at 10:08 PM, Ken godee wrote: > > password"? That's what I'm talking about -- how often does this sort of > > thing happen, where you need to be subscribed to be a security mailing > list > > in order to know what workaround to make to stay safe, as opposed to > simply > > running yum-updatesd to install latest patches automatically. > > Happens all the time! Really? An exploit is released in the wild, and there's a lag of several days before a patch is available through updates -- "all the time"? How often? Every week? Since Gilbert and "supergiantpotato" seemed to be saying the opposite (that unpatched OS- and web-server-level exploits were pretty rare), what data were you relying on when you said that it "happens all the time"? > Count on it! If running any server available to > the public there is no "set and forget" if you're responsible for that > server you best stay informed/subscribed and ready to take action be it > a work around, update or whatever. > > > > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Tue, Dec 27, 2011 at 10:17 PM, Rilindo Foster wrote: > > > > > On Dec 27, 2011, at 11:29 PM, Bennett Haselton > wrote: > > > On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < > > seben...@weather.admin.niu.edu> wrote: > > > >> On Tue, 27 Dec 2011, Bennett Haselton wrote: > >> > >>> Suppose I have a CentOS 5.7 machine running the default Apache with no > >>> extra modules enabled, and with the "yum-updatesd" service running to > >> pull > >>> down and install updates as soon as they become available from the > >>> repository. > >>> > >>> So the machine can still be broken into, if there is an unpatched > exploit > >>> released in the wild, in the window of time before a patch is released > >> for > >>> that update. > >>> > >>> Roughly what percent of the time is there such an unpatched exploit in > >> the > >>> wild, so that the machine can be hacked by someone keeping up with the > >>> exploits? 5%? 50%? 95%? > >> > >> There's no way to give you an exact number, but let me put it this way: > >> > >> If you've disable as much as you can (which by default, most stuff is > >> disabled, so that's good), and you restart Apache after each update, > >> your chances of being broken into are better by things like SSH brute > >> force attacks. There's always a chance someone will get in, but when you > >> look at the security hole history of Apache, particularly over the past > >> few years, there have been numerous CVE's, but workarounds and they > aren't > >> usually earth-shattering. Very few of them have. The latest version that > >> ships with 5.7 is as secure as they come. If it wasn't, most web sites > >> on the Internet would be hacked by now, as most run Apache > >> > > > > I was asking because I had a server that did get broken into, despite > > having yum-updatesd running and a strong password. He said that even if > > you apply all latest updates automatically, there were still windows of > > time where an exploit in the wild could be used to break into a machine; > in > > particular he said: > > > > "For example, there was a while back ( ~march ) a kernel exploit that > > affected CentOS / RHEL. The patch came after 1-2 weeks of the security > > announcement. The initial announcement provided a simple work around > until > > the new version is released." > > > > What was the nature of the break-in, if I may ask? > I don't know how they did it, only that the hosting company had to take the server offline because they said it was sending a DOS attack to a remote host and using huge amounts of bandwidth in the process. The top priority was to get the machine back online so they reformatted it and re-connected it, so there are no longer any logs showing what might have happened. (Although of course once the server is compromised, presumably the logs can be rewritten to say anything anyway.) > Security is more than just updates and a strong password. > > - Rilindo Foster > Well that's what I'm trying to determine. Is there any set of default settings that will make a server secure without requiring the admin to spend more than, say, 30 minutes per week on maintenance tasks like reading security newsletters, and applying patches? And if there isn't, are there design changes that could make it so that it was? Because if an OS/webserver/web app combination requires more than, say, half an hour per week of "maintenance", then for the vast majority of servers and VPSs on the Internet, the "maintenance" is not going to get done. It doesn't matter what our opinion is about whose fault it is or whether admins "should" be more diligent. The maintenance won't get done and the machines will continue to get hacked. (And half an hour per week is probably a generous estimate of how much work most VPS admins would be willing to do.) On the other hand, if the most common causes of breakins can be identified, maybe there's a way to stop those with good default settings and automated processes. For example, if exploitable web apps are a common source of breakins, maybe the standard should be to have them auto-update themselves like the operating system. (Last I checked, WordPress and similar programs could *check* if updates were available, and alert you next time you signed in, but they didn't actually patch themselves. So if you never signed in to a web app on a site that you'd forgotten about, you might never realize it needed patching.) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
Yeah I know that most break-ins do happen using third-party web apps; fortunately the servers I'm running don't have or need any of those. But then what about what my friend said: "For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released." Is that an extremely rare freak occurrence? Or are you just saying it's rare *compared* to breakins using web apps? Or am I misunderstanding what my friend was referring to in the above paragraph? Bennett 2011/12/27 夜神 岩男 > On 12/28/2011 01:29 PM, Bennett Haselton wrote: > > On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste< > > seben...@weather.admin.niu.edu> wrote: > > > >> On Tue, 27 Dec 2011, Bennett Haselton wrote: > >> > >>> Suppose I have a CentOS 5.7 machine running the default Apache with no > >>> extra modules enabled, and with the "yum-updatesd" service running to > >> pull > >>> down and install updates as soon as they become available from the > >>> repository. > >>> > >>> So the machine can still be broken into, if there is an unpatched > exploit > >>> released in the wild, in the window of time before a patch is released > >> for > >>> that update. > >>> > >>> Roughly what percent of the time is there such an unpatched exploit in > >> the > >>> wild, so that the machine can be hacked by someone keeping up with the > >>> exploits? 5%? 50%? 95%? > >> > >> There's no way to give you an exact number, but let me put it this way: > >> > >> If you've disable as much as you can (which by default, most stuff is > >> disabled, so that's good), and you restart Apache after each update, > >> your chances of being broken into are better by things like SSH brute > >> force attacks. There's always a chance someone will get in, but when you > >> look at the security hole history of Apache, particularly over the past > >> few years, there have been numerous CVE's, but workarounds and they > aren't > >> usually earth-shattering. Very few of them have. The latest version that > >> ships with 5.7 is as secure as they come. If it wasn't, most web sites > >> on the Internet would be hacked by now, as most run Apache > >> > > > > I was asking because I had a server that did get broken into, despite > > having yum-updatesd running and a strong password. He said that even if > > you apply all latest updates automatically, there were still windows of > > time where an exploit in the wild could be used to break into a machine; > in > > particular he said: > > > > "For example, there was a while back ( ~march ) a kernel exploit that > > affected CentOS / RHEL. The patch came after 1-2 weeks of the security > > announcement. The initial announcement provided a simple work around > until > > the new version is released." > > > > Was this a sufficiently high-profile incident that you know what he's > > referring to? If this kind of thing happens once a year or more, than > > surely this is a much greater threat than "brute forcing the SSH > > password"? That's what I'm talking about -- how often does this sort of > > thing happen, where you need to be subscribed to be a security mailing > list > > in order to know what workaround to make to stay safe, as opposed to > simply > > running yum-updatesd to install latest patches automatically. > > Nearly every time servers get broken into they are web servers, and web > servers serving applications the greatest percentage of those. The "web" > never having been intended as an applications platform provides a huge > number of attack vectors which are entirely separate from the OS layer. > > For example, a perfectly secure operating system running a perfectly > secure Apache configuration on a perfectly secure MySQL deployment could > be running an application that permits injection of arbitrary SQL > commands into the database. The server itself may not be compromised (or > it may, depending on what else that SQL command can touch/be referenced > by) in the sense that someone can open a shell, but in most cases there > is nothing of interest on a web server anyway. What is interesting is > what is in the database or lives within the application being served, > and that is an application/database layer problem, not an OS, web-ser
Re: [CentOS] what percent of time are there unpatched exploits against default config?
Everything installed on the machine had been installed with "yum". So I assumed that meant that it would also be updated by "yum" if an update was available from the distro. On Tue, Dec 27, 2011 at 9:38 PM, Karanbir Singh wrote: > On 12/28/2011 04:29 AM, Bennett Haselton wrote: > > I was asking because I had a server that did get broken into, despite > > having yum-updatesd running and a strong password. He said that even if > > the software component compromised was a part of the updates being > dished out from the distro ( and therefore likely covered via the > yum-updatesd? ) > > - KB > ___ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste < seben...@weather.admin.niu.edu> wrote: > On Tue, 27 Dec 2011, Bennett Haselton wrote: > > > Suppose I have a CentOS 5.7 machine running the default Apache with no > > extra modules enabled, and with the "yum-updatesd" service running to > pull > > down and install updates as soon as they become available from the > > repository. > > > > So the machine can still be broken into, if there is an unpatched exploit > > released in the wild, in the window of time before a patch is released > for > > that update. > > > > Roughly what percent of the time is there such an unpatched exploit in > the > > wild, so that the machine can be hacked by someone keeping up with the > > exploits? 5%? 50%? 95%? > > There's no way to give you an exact number, but let me put it this way: > > If you've disable as much as you can (which by default, most stuff is > disabled, so that's good), and you restart Apache after each update, > your chances of being broken into are better by things like SSH brute > force attacks. There's always a chance someone will get in, but when you > look at the security hole history of Apache, particularly over the past > few years, there have been numerous CVE's, but workarounds and they aren't > usually earth-shattering. Very few of them have. The latest version that > ships with 5.7 is as secure as they come. If it wasn't, most web sites > on the Internet would be hacked by now, as most run Apache > I was asking because I had a server that did get broken into, despite having yum-updatesd running and a strong password. He said that even if you apply all latest updates automatically, there were still windows of time where an exploit in the wild could be used to break into a machine; in particular he said: "For example, there was a while back ( ~march ) a kernel exploit that affected CentOS / RHEL. The patch came after 1-2 weeks of the security announcement. The initial announcement provided a simple work around until the new version is released." Was this a sufficiently high-profile incident that you know what he's referring to? If this kind of thing happens once a year or more, than surely this is a much greater threat than "brute forcing the SSH password"? That's what I'm talking about -- how often does this sort of thing happen, where you need to be subscribed to be a security mailing list in order to know what workaround to make to stay safe, as opposed to simply running yum-updatesd to install latest patches automatically. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] what percent of time are there unpatched exploits against default config?
Suppose I have a CentOS 5.7 machine running the default Apache with no extra modules enabled, and with the "yum-updatesd" service running to pull down and install updates as soon as they become available from the repository. (Assume further the password is strong, etc.) On the other hand, suppose that as the admin, I'm not subscribed to any security alert mailing lists which send out announcements like "Please disable this feature as a workaround until this hole is plugged", so the machine just hums along with all of its default settings. So the machine can still be broken into, if there is an unpatched exploit released in the wild, in the window of time before a patch is released for that update. On the other hand, at any point in time where there are no unpatched exploits in the wild, the machine should be much harder to break into. Roughly what percent of the time is there such an unpatched exploit in the wild, so that the machine can be hacked by someone keeping up with the exploits? 5%? 50%? 95%? Hopefully this is specific enough that the answer is not "it depends" :) , an actual numeric answer should exist -- although I don't know if anyone has ever tried to work it out. But if not, then what's a good guess, based on observing how frequently root exploits are released in the wild, and how long the patches usually take. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
