On Mon, 2 Jan 2012 19:18:57 +0000
Liam Proven <email@example.com> wrote:
> If you really want a two-panel desktop, then install Xubuntu.
A question, Liam, if you please. You have two monitors as have I. I
use an nVidia 3D-enabled graphics card with compiz also enabled. I
cannot get Xfce to use both monitors as one RE: background images. It
insists on using separate backgrounds/wallpapers although it will
stretch the panel(s) across both monitors if desired. I think it to be
strange behavior as ti seems to me that it should do either both or
neither. Do you know any tricks to get one single image across both
monitors? It /is/ an option using LXDE which I found surprising in view
of its reputation as lightweight.
Cybe R. Wizard
Strength through Unity.
Unity through faith.
ubuntu-users mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Mon Jan 2 22:30:01 2012
Delivery-date: Mon, 02 Jan 2012 22:26:54 +0200
Received: from mail.centos.org ([126.96.36.199]:45854)
by s2.java-tips.org with esmtp (Exim 4.69)
for firstname.lastname@example.org; Mon, 02 Jan 2012 22:26:54 +0200
Received: from mail.centos.org (voxeldev.centos.org [127.0.0.1])
by mail.centos.org (Postfix) with ESMTP id 168616F67F;
Mon, 2 Jan 2012 15:26:55 -0500 (EST)
Received: from carmen.lorenzomartinez.es
by mail.centos.org (Postfix) with ESMTP id 55FEF6F67F
for <email@example.com>; Mon, 2 Jan 2012 15:26:52 -0500 (EST)
Received: (qmail 15485 invoked by uid 7797); 2 Jan 2012 20:26:52 -0000
Received: from 192.168.52.133 by Carmen (envelope-from
<firstname.lastname@example.org>, uid 500) with qmail-scanner-2.08
(clamdscan: 0.97.2/13407. Clear:RC:1(192.168.52.133):.
Processed in 0.015238 secs); 02 Jan 2012 20:26:52 -0000
Received: from unknown (HELO LawBook.local) (192.168.52.133)
by Carmen with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP;
2 Jan 2012 20:26:52 -0000
Date: Mon, 02 Jan 2012 21:26:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
rv:9.0) Gecko/20111222 Thunderbird/9.0.1
To: CentOS mailing list <email@example.com>
Subject: Re: [CentOS] an actual hacked machine, in a preserved state
Reply-To: CentOS mailing list <firstname.lastname@example.org>
List-Id: CentOS mailing list <centos.centos.org>
Content-Type: text/plain; charset="iso-8859-1"
just if it helps, please find below these lines the steps I have used to =
analyze several suspicious machines in some customers, to check if they =
have been compromised or not:
* Chrootkit && rkhunter -> To search for known trojans and common linux =
* unhide (http://www.unhide-forensics.info/) -> to check for hidden =
processes and tcp sockets
* rpm -Va -> To check binary integrity against installed rpms
* If netstat binary looks to be sane, check listening sockets
* If ps binary looks to be sane, check shown running processes
* Check console connections with "last" and "lastb" commands
* Tcpdump on network interfaces avoiding traffic for known running =
services (80, 25, 21, etc... depending on the role of the machine) to =
check for the weird traffic
* grep -i segfault /var/log/* -> to check for buffer overflows in logs
* grep -i auth /var/log/* |grep -i failed -> to check authentication =
* lsmod -> to check loaded kernel modules (it is ver difficult to find =
out something wrong here, but just to be sure nothing weird appears).
* lsof -> to check opened current files
* Check xinetd -> to find out if someone has added some new "service"
* have a look to /tmp, /opt, /usr/bin, /usr/local/bin, /usr/sbin and =
* check /etc/passwd and verify created users are licit to be there.
* check crontab for every user to avoid any process to be programmed
Hope the checklist helps...
El 02/01/12 09:04, Craig White escribi=F3:
> 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 apparen=
>> been hacked. Since 2 of out of 3 machines hosted at that company have n=
>> 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, sa=
>> 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 hosti=
>> So, following people's suggestions, the machine is disconnected and hook=
>> 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:
>> 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:
>> 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 go=
>> 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 sugge=
>> that the patch on October 20th introduced a new exploit, which the attac=
>> 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? =
>> 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 attac=
>> 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 week=
>> 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?
> 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.
> 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
> There are some tools to identify a hackers access though they are often
> obscured by the hacker...
> last # reads /var/log/wtmp and provides a list of users, login date/time
> login duration, etc. Read the man page for last to get other options on
> its usage including the '-f' option to read older wtmp log files if
> lastb # reads /var/log/btmp much as above but list 'failed' logins
> though this requires pro-active configuration and if you didn't do that,
> you probably will do that going forward.
> looking at /etc/passwd to see what users are on your system and then
> search their $HOME directories carefully for any evidence that their
> account was the first one compromised. Very often, a single user with a
> weak password has his account cracked and then a hacker can get a copy
> of /etc/shadow and brute force the root password.
> Consider that this type of activity is often done with 'hidden' files&
> directories. This hacker was apparently brazen enough to operate openly
> in /home so it's likely that he wasn't very concerned about his cracking
> being discovered.
> The most important thing to do at this point is to figure out HOW they
> got into your systems in the first place and discussions of SELinux and
> yum updates are not useful to that end. Yes, you should always update
> and always run SELinux but not useful in determining what actually
> Make a list of all open ports on this system, check the directories,
> files, data from all daemons/applications that were exposed (Apache?
> PHP?, MySQL?, etc.) and be especially vigilant to any directories where
> user apache had write access.
> Again though, I am concerned that your first action on your first
> discovered hacked server was to wipe it out and of a notion that it's
> entirely possible that the actual cracking occurred on that system and
> this (and perhaps other servers) are simply free gifts to the hacker
> because they had pre-shared keys or the same root password.
Lorenzo Martinez Rodriguez
Visit me: http://www.lorenzomartinez.es
Mail me to: email@example.com
My blog: http://www.securitybydefault.com
My twitter: @lawwait
PGP Fingerprint: 97CC 2584 7A04 B2BA 00F1 76C9 0D76 83A2 9BBC BDE2
CentOS mailing list