Discuss January 2012

discuss@lists.centos.org

222 participants
221 discussions

Since 6.2 USB-dvices will not be recognized automatically
by Timothy Kesten 04 Jan '12

04 Jan '12

Hi Folks, since the update from 6.1 x86_64 to 6.2 x86_64 my external USB-HDs are not any longer recognized automatically. I mean that popup where I can mount/umount the devices. /var/log/messages says Jan 4 10:37:28 server1 kernel: usb 1-7.3: new high speed USB device using ehci_hcd and address 15 Jan 4 10:37:29 server1 kernel: usb 1-7.3: New USB device found, idVendor=0bc2, idProduct=2300 Jan 4 10:37:29 server1 kernel: usb 1-7.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 4 10:37:29 server1 kernel: usb 1-7.3: Product: Portable Jan 4 10:37:29 server1 kernel: usb 1-7.3: Manufacturer: Seagate Jan 4 10:37:29 server1 kernel: usb 1-7.3: SerialNumber: 2GH5KBG2 Jan 4 10:37:29 server1 kernel: usb 1-7.3: configuration #1 chosen from 1 choice Jan 4 10:37:29 server1 kernel: scsi15 : SCSI emulation for USB Mass Storage devices What goes wrong here? Thx Timothy

1 0

vsftpd log issues
by Timo Neuvonen 04 Jan '12

04 Jan '12

I have an up-to-date CentOS 6 with reasonable amount of ftp activity (a dozen of network cameras uploading images every second 24x7). The first issue was that the whole /var filesystem was about to get full, because of huge ftp daemon log. vsftpd.conf says: # You may override where the log file goes if you like. The default is shown # below. xferlog_file=/var/log/vsftpd.log Ok, the above works now. But while the setting was (by default) commented out, the default wasn't /var/log/vsftpd.log but /var/log/xferlog which was growing without limits (it was over 6 GB when I first time noticed the problem) since logrotate tried to rotate vsftpd.log -rw------- 1 root root 0 Dec 31 03:07 vsftpd.log -rw------- 1 root root 39134459 Dec 31 12:19 vsftpd.log.1 -rw------- 1 root root 433305200 Dec 30 22:03 xferlog Now, after uncommenting the log file setting line in the conf the next issue is, that logrotate does rotate the log files (the old one gets .1 postfix added to its name and a new file is created), but it still keeps writing to the original file (which is renamed now) In the ls -l listing above: - vsftpd started to write log vsftpd.log around 10pm last night (when I uncommented the log setting from the conf and restarted the daemon, until that it was logging to xferlog) - during the night logrotate has changed the name of the existing log file to ...log.1 but now, several hours later, this renamed old file is still used for logging, and the new ...log file remains empty! Is there some simple option in logrotate's conf that could change this behaviour? Or how to fix this. There must be many others who already have run into this issue. Regards, Timo

3 2

Passwords apparently stopped working.
by James B. Byrne 04 Jan '12

04 Jan '12

I encountered a couple of strange events with respect to password authentication this morning. Two of our staff were unable to login onto several systems using their usual passwords. Both users had last logged in on these hosts using their accounts and passwords on Friday past. The two accounts could not log on to any of the servers for which they had access and the message log on each showed that access was denied for a failed password. The systems involved were running either CentOS-4.9 or CentOS-5.7. So, the effect was uniform across multiple hardware and software platforms. I also checked these accounts against our warm backup machine and encountered the same problems for both. I verified that the passwords being used were correct for the accounts. I also verified that neither of passwords had been reset in some months and there were no expiry dates set for the accounts. I would accept the coincidence of both forgetting their passwords except for the fact that each had kept a record of their password in their wallets and I was able to confirm those values against our records as well. Resetting both the passwords to their current values using the passwd utility on each system corrected the problem insofar as the users were concerned. However, I am somewhat perplexed as to the reason for their passwords to stop working in the first place. Is anyone here aware of any reason why this might happen? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

4 3

probleme with my wifi card on centos 6
by fakessh 04 Jan '12

04 Jan '12

Hello list 6 centos I wish you a very good year for this festive period I am writing to report a problem I encounter with my wireless card realtek 8150 the installer does not detect the device so the /etc/sysconfig/network-script/ifcfg-wlan0 is absent I can not find the driver for the deposit elrepo No I have in any case managed to detect my peripheique by the system Despite my many attempts sincerely -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting

3 11

CentOS-announce Digest, Vol 83, Issue 1
by centos-announce-request＠centos.org 03 Jan '12

03 Jan '12

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2012:0001 CentOS 6 vsftpd Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 Jan 2012 01:53:55 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:0001 CentOS 6 vsftpd Update To: centos-announce(a)centos.org Message-ID: <20120103015355.GA18562(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:0001 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-0001.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: de412bb59ce6fcb08bcbb745aaa73429a18aadba12e5d71e85fa672701d6f677 vsftpd-2.2.2-6.el6_2.1.i686.rpm x86_64: 38f46bd3a896ef31ce879764cb9cd27c878e5070e1f6d4a016c9b9e54853a143 vsftpd-2.2.2-6.el6_2.1.x86_64.rpm Source: 62c140cbd2d670a8010f490dfc3a7c69d09030d913ddcc01328f637bfd19db4e vsftpd-2.2.2-6.el6_2.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 83, Issue 1 **********************************************

1 0

Can't find qemu-kvm
by Mark LaPierre 03 Jan '12

03 Jan '12

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

4 5

'last' command doesn't include ssh connections made by this perl script?
by Bennett Haselton 02 Jan '12

02 Jan '12

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/0 50-54-225-130.ev Mon Jan 2 13:23 still logged in root pts/0 50-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

3 2

raid resync deleting data?
by Nathan 02 Jan '12

02 Jan '12

Hello, I have a c5 box with a 6 drive raid 6 array. I was going away over Christmas so I was shutting the machine down, I noticed a raid resync (on the raid 6 array) so i stopped it, using the command # echo "idle" > /sys/block/md5/md/sync_action then shut the machine down. A week later I turned the machine on and started copying data to it around 24 hours later a raid resync occurred and wiped all the new data I had copied to it. To me this seems broken, is it because I manually stopped a previous resync that it got in this state? Any ideas? As for log messages there is nothing in the /var/log/messages file, only Jan 2 19:38:39 bolivia kernel: md: syncing RAID array md5 Jan 2 19:38:39 bolivia kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc. Jan 2 19:38:39 bolivia kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction. no other errors or anything. Thanks Nathan

1 0

what percent of time are there unpatched exploits against default config?
by Bennett Haselton 02 Jan '12

02 Jan '12

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

28 97

(no subject)
by Bennett Haselton 01 Jan '12

01 Jan '12

(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… 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?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss January 2012