Re: [CentOS] what percent of time are there unpatched exploits against default config?
>Agreed. I don't even label as idiots the idiots who post here, asking us >to tell them how to do the job they were hired for, without any indication >that they've read man pages, or googled for an answer. Last time I checked you *were* in this list therefore you are calling yourself an idiot. Jokes apart... calm down. You offend people with your tone and insults so I ask you to stop doing so. Regards ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Checkinstall rpm for CentOS-6 x86_64?
On 12/31/2011 02:24 PM, Tilman Schmidt wrote: >> consider using fpm instead ? it kind of address's the same problem in a >> different way. > > Although I'm not the OP I'm interested in that topic too. https://github.com/jordansissel/fpm/wiki and https://docs.google.com/present/view?id=0Aa9liCTsAyzRZGNtd3dkOTRfMTdmczY2azlkcg&hl=en having said that - *I* am not a big fan of using these kinds of tools, its still way better to get a spec file in place that you can hand edit and maintain. Fpm has its place, it will let you grab a build and make an rpm out of it - but it does nothing for maintainability and nothing for management. BUT its a mile better than a 'make install' or checkinstall ( in that it does use rpmbuild ) installing fpm is tricky, since it has no dependency checks - so its a case of install it, then workout what deps it needs as things fail. Maybe a slightly worthwhile effort would be to package fpm into a rpm with the right deps :) -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219| Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc ___ 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 12/31/2011 11:45 PM, Timothy Murphy wrote: > Les Mikesell wrote: > > Yes, I'm more worried about attacks through port 80. > Can anyone point me to documentation on protecting a web-server? > You should check http://www.snort.org, IDS system. ClearOS has them integrated. I can not remember if can detect crafted http attacks, but it does MySQL, MSSQL protection etc. -- 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
[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
[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
Re: [CentOS] what percent of time are there unpatched exploits against default config?
On 01/01/2012 09:14 PM, Ljubomir Ljubojevic wrote: > On 12/31/2011 11:45 PM, Timothy Murphy wrote: >> Les Mikesell wrote: >> >> Yes, I'm more worried about attacks through port 80. >> Can anyone point me to documentation on protecting a web-server? >> > > You should check http://www.snort.org, IDS system. ClearOS has them > integrated. > > I can not remember if can detect crafted http attacks, but it does > MySQL, MSSQL protection etc. > > > It looks like it can detect (at least certain) http attacks. Also look at: http://www.bleedingsnort.com/about/ http://www.openinfosecfoundation.org/ http://www.emergingthreats.net/ -- 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
Re: [CentOS] an actual hacked machine, in a preserved state
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? -- Eero ___ 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 12/30/2011 09:02 PM, Alex Milojkovic wrote: > Scenario of botnet with 1000 PCs making attempts to crack are password ain't > gonna happen. > On one system that I run, for a fairly popular domain, I see botnet attacks trying to break in to the pop and ftp ports as well as botnet spam and SASL auth attacks on the smtp port. My ssh port is not open to the outside world. The attacks come and go in waves, but If I don't use various limiting tools, they will try sometimes to make as many as 50 simultaneous connections to my server. I saw this the worst with spam on the smtp port. fail2ban is not so effective on botnet attacks. Newer version of postfix include postscreen, a front end which blocks botnet attacks (but only for smtp connections). I plan to install it. I have found that most of the attacks are coming from china, south korea, japan, russia, various south american countries. I would like to start blocking access to certain services from some countries. I've been considering using ipdeny.com data. Does ipset work with the existing kernel under CentOS 5 and if so is there an RPM available? I've goggled around a bit, but haven't found anything. From http://ipset.netfilter.org/ I'm led to believe that the current kernel should support it. Nataraj ___ 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
Re: [CentOS] Centos 6.X compatible to ORACLE DB verssion????
On 29 December 2011 19:15, Johnny Hughes wrote: > They can't very well (at least not with a straight face) tell Red Hat > that RHEL6 is not certified while saying that OEL6 is certified can > they? If they do that for very long, they will be breaching their > support agreements. Really? In what way, out of interest? Hint: they're not. -- Kind Regards, Christopher J. Buckley ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
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. ___ 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 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. > 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. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 01/02/2012 12:27 AM, Bennett Haselton wrote: > On Sun, Jan 1, 2012 at 2:55 PM, Eero Volotinenwrote: > >> 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 :) ) > The Errata you posted does not explain (to me at least) how they would get in. They would still need to brut-force the password. So if it was not a password, they used something else. And that VBullliten exploit looks like they used it to attack other sites with old VBullitens, from your server. Doesn't your Hosting company keep connection tracking from their rooters for 6 months, in case "police" requests them? You could track what happened from those logs. Also, have you used Logwatch to send daily log summaries to your mail? They could have had interesting data. Good practice is to setup remote logging by sending logs to server with rsyslog daemon with IP/host separation. It is done in real time, so attacker can only stop the log daemon on broken system and reconfigure them. One of the reasons I use Virtualmin package is because all servers (httpd, postfix, ) are run under the user that owns that domain. Even if you have only one domain, all services are will lowered privileges, so the damage is lesser then when they are run from root account. -- 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... Star
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 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. >> >> > > 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? 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: setsebool -P httpd_can_network_connect on - Rilindo ___ 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. > >> > >> > > > > 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? > > 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: > > setsebool -P httpd_can_network_connect on > I'm not sure what you mean by "an exploit from a web board which is apparently designed to pull outside traffic". Like
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 1, 2012, at 8:50 PM, Bennett Haselton wrote: > 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. >>> >>> 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? >> >> 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: >> >> setsebool -P httpd_can_network_connect on >> > > I'm not sure
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 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. 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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
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. So there are many possible ways they got in including 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. 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..) -- 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
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] what percent of time are there unpatched exploits against default config?
> Does ipset work with the existing kernel under CentOS 5 and if so is there an > RPM available? > I've goggled around a bit, but haven't found anything. From > http://ipset.netfilter.org/ I'm led > to believe that the current kernel should support it. Well, you have modules on your system, and if you Google you'll see a couple repos have the userland tools. Check out CentALT for example... ___ 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?
I actually found a link on Apnic's web site to their IPv4 netblocks which helped me eliminate their traffic. http://www.apnic.net/publications/research-and-insights/ip-address-trends/ap nic-resource-range This solved most of my problems. There are not as many lines as one would expect. Just go to other NICs and look for this info -Alex -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Nataraj Sent: Sunday, January 01, 2012 3:26 PM To: centos@centos.org Subject: Re: [CentOS] what percent of time are there unpatched exploits against default config? On 12/30/2011 09:02 PM, Alex Milojkovic wrote: > Scenario of botnet with 1000 PCs making attempts to crack are password ain't gonna happen. > On one system that I run, for a fairly popular domain, I see botnet attacks trying to break in to the pop and ftp ports as well as botnet spam and SASL auth attacks on the smtp port. My ssh port is not open to the outside world. The attacks come and go in waves, but If I don't use various limiting tools, they will try sometimes to make as many as 50 simultaneous connections to my server. I saw this the worst with spam on the smtp port. fail2ban is not so effective on botnet attacks. Newer version of postfix include postscreen, a front end which blocks botnet attacks (but only for smtp connections). I plan to install it. I have found that most of the attacks are coming from china, south korea, japan, russia, various south american countries. I would like to start blocking access to certain services from some countries. I've been considering using ipdeny.com data. Does ipset work with the existing kernel under CentOS 5 and if so is there an RPM available? I've goggled around a bit, but haven't found anything. >From http://ipset.netfilter.org/ I'm led to believe that the current kernel should support it. Nataraj ___ 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] Can't find qemu-kvm
I just installed CentOS 6.2 32 bit today. When I try to start the Virtual Machine Manager I get a error: Packages required for KVM usage The following packages are not installed: qemu-kvm These are required to create KVM guests locally. Would you like to install them now? If I click on the [YES] button I'm told that the packages could not be found in any software source. [root@mushroom ~]# yum whatprovides "*qemu-kvm" Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile * base: mirror.cogentco.com * extras: centos.mirror.choopa.net * updates: centos.aol.com No Matches found [root@mushroom ~]# Does anyone know where one can find qemu-kvm? -- °v° /(_)\ ^ ^ Mark LaPierre Registerd Linux user No #267004 www.counter.li.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't find qemu-kvm
On 01/02/2012 01:49 AM, Mark LaPierre wrote: > I just installed CentOS 6.2 32 bit today. When I try to start the > Virtual Machine Manager I get a error: > > Packages required for KVM usage > > The following packages are not installed: > > qemu-kvm > > These are required to create KVM guests locally. > Would you like to install them now? > > If I click on the [YES] button I'm told that the packages could not be > found in any software source. > > [root@mushroom ~]# yum whatprovides "*qemu-kvm" > Loaded plugins: fastestmirror, refresh-packagekit, security > Loading mirror speeds from cached hostfile > * base: mirror.cogentco.com > * extras: centos.mirror.choopa.net > * updates: centos.aol.com > No Matches found > [root@mushroom ~]# > > Does anyone know where one can find qemu-kvm? > This should do it; yum install qemu-kvm qemu-kvm-tools -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
