[gentoo-user] bluetooth device bd address is 11:11:11:11:11:11
hi, i have a usb bluetooth device, after i plug it into the usb slot and ran hciconfig, it shows the bd address is 11:11:11:11:11:11. is it correct? or maybe the driver is not loaded correctly? -- Best Regards, Xi Shen (David) http://twitter.com/davidshen84/
[gentoo-user] Rooted/compromised Gentoo, seeking advice
Hi, today when working remotely I ran nethogs and noticed suspicious network traffic coming from my home gentoo box. It was very low traffic (less than 1KB/sec bandwidth usage) but according to nethogs it was between a root user process and various suspicious-looking ports on outside hosts in other countries that I have no business with. netstat didn't show anything, however, but when I ran chkrootkit told me that netstat was INFECTED. I immediately issued shutdown -h now and now I won't be able to take a further look at it until I get home and have physical access to the box. System uptime was a few months. It was last updated for installation of a 2.6.33 kernel (2.6.35 is out now). I have 3 goals now: 1) Figure out what is running on my box and how long it has been there. 2) Find out how it got there. 3) Sanitizing, or most likely rebuilding the system from scratch. I won't feel comfortable about doing item 3 until I learn the cause of 1 and 2. Since this is a home PC, it's not mission-critical and I have other computers so I can afford to leave it offline while I investigate this security breach, but at the same time it's worrisome because I do banking etc from this machine. I'll obviously have to check the status of any other computer on the same network. My user account has sudo-without-password rights to any command. In hindsight this risk may not be worth the extra convenience... A rogue sudo install-bad-stuff anywhere over time could have done me in. Alternatively I was running vulnerable/compromised software. My box has sshd running, root login in ssh is not allowed, and pubkey only logins (no passwords). It is behind a wireless router but port 22 is open and pointing to this box, and a few others needed by other applications. So I will check out which keys exist on the compromised machine and make sure I recognize them all. I'll also need to check the status of any other computer my key is stored on (a mix of linux windows, and my mobile phone). Sigh... I am using ~amd64 and I update deep world about 3 times a week normally. The computer is only a few months old, but it was created by cloning a ~2-years-old computer. I did emerge -e world as part of the upgrade process. If anyone has advice on what I should look at forensically to determine the cause of this, it is appreciated. I'll first dig into the logs, bash history etc. and really hope that this very happened recently. Thanks for any tips and wish me good luck. :)
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Monday 09 August 2010 18:25:56 Paul Hartman wrote: Hi, today when working remotely I ran nethogs and noticed suspicious network traffic coming from my home gentoo box. It was very low traffic (less than 1KB/sec bandwidth usage) but according to nethogs it was between a root user process and various suspicious-looking ports on outside hosts in other countries that I have no business with. netstat didn't show anything, however, but when I ran chkrootkit told me that netstat was INFECTED. I immediately issued shutdown -h now and now I won't be able to take a further look at it until I get home and have physical access to the box. System uptime was a few months. It was last updated for installation of a 2.6.33 kernel (2.6.35 is out now). I have 3 goals now: 1) Figure out what is running on my box and how long it has been there. 2) Find out how it got there. 3) Sanitizing, or most likely rebuilding the system from scratch. Here's the bad news: An intruder probably gained access through a script kiddie script, which has likely already removed all the logs. Or they have possibly been rotated away by now. I would proceed as follows: 1. Keep that machine off the internet till it is reinstalled 2. Fresh reinstall using boot media that you have downloaded and written elsewhere, plus a portage tree. Don't worry about distfiles - a fresh portage tree won't use existing copies on that machine if the hashes don't match. So you can re-use them. If you boot off new install media it is safe to download new distfiles using it. 3. Keep your old partitions around if you want to do forensics, you can mount them somewhere when a reinstall is done and peruse them at your leisure. However, doing that is often a waste of time unless you still have logs. You can use a scanner like nessus to look things over. 4. And it goes without saying that you should change all passwords and keys used on that trojaned machine. I won't feel comfortable about doing item 3 until I learn the cause of 1 and 2. Since this is a home PC, it's not mission-critical and I have other computers so I can afford to leave it offline while I investigate this security breach, but at the same time it's worrisome because I do banking etc from this machine. I'll obviously have to check the status of any other computer on the same network. My user account has sudo-without-password rights to any command. In hindsight this risk may not be worth the extra convenience... A rogue sudo install-bad-stuff anywhere over time could have done me in. Alternatively I was running vulnerable/compromised software. My box has sshd running, root login in ssh is not allowed, and pubkey only logins (no passwords). It is behind a wireless router but port 22 is open and pointing to this box, and a few others needed by other applications. So I will check out which keys exist on the compromised machine and make sure I recognize them all. I'll also need to check the status of any other computer my key is stored on (a mix of linux windows, and my mobile phone). Sigh... I am using ~amd64 and I update deep world about 3 times a week normally. The computer is only a few months old, but it was created by cloning a ~2-years-old computer. I did emerge -e world as part of the upgrade process. If anyone has advice on what I should look at forensically to determine the cause of this, it is appreciated. I'll first dig into the logs, bash history etc. and really hope that this very happened recently. Thanks for any tips and wish me good luck. :) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, Aug 9, 2010 at 11:48 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Monday 09 August 2010 18:25:56 Paul Hartman wrote: Hi, today when working remotely I ran nethogs and noticed suspicious network traffic coming from my home gentoo box. It was very low traffic (less than 1KB/sec bandwidth usage) but according to nethogs it was between a root user process and various suspicious-looking ports on outside hosts in other countries that I have no business with. netstat didn't show anything, however, but when I ran chkrootkit told me that netstat was INFECTED. I immediately issued shutdown -h now and now I won't be able to take a further look at it until I get home and have physical access to the box. System uptime was a few months. It was last updated for installation of a 2.6.33 kernel (2.6.35 is out now). I have 3 goals now: 1) Figure out what is running on my box and how long it has been there. 2) Find out how it got there. 3) Sanitizing, or most likely rebuilding the system from scratch. Here's the bad news: An intruder probably gained access through a script kiddie script, which has likely already removed all the logs. Or they have possibly been rotated away by now. I would proceed as follows: 1. Keep that machine off the internet till it is reinstalled 2. Fresh reinstall using boot media that you have downloaded and written elsewhere, plus a portage tree. Don't worry about distfiles - a fresh portage tree won't use existing copies on that machine if the hashes don't match. So you can re-use them. If you boot off new install media it is safe to download new distfiles using it. 3. Keep your old partitions around if you want to do forensics, you can mount them somewhere when a reinstall is done and peruse them at your leisure. However, doing that is often a waste of time unless you still have logs. You can use a scanner like nessus to look things over. 4. And it goes without saying that you should change all passwords and keys used on that trojaned machine. Hi Alan, thanks for the advice. I just remembered that my DD-WRT router stats page had an anomaly, on 31st of July it showed I had over 700 terabytes of traffic, which is impossible. Coincidentally, my cable modem stopped working on the same day, so I wrote it off as a bug or a result of the broken modem. I replaced the modem and everything seemed to work normally after that. At this point my mind is running wild thinking of all of the possibilities. Could the router have been infected? The modem? It'll still be another 5 or 6 hours before I'm able to lay my hands on the machine. I'm imagining every doomsday scenario. :) My hope is that it was only a botnet or ssh-scanner or something, and not sniffer or keylogger or anything nefarious. I fear I may never truly be able to know, though.
[gentoo-user] Re: Rooted/compromised Gentoo, seeking advice
On 08/09/10 12:25, Paul Hartman wrote: [] If anyone has advice on what I should look at forensically to determine the cause of this, it is appreciated. I'll first dig into the logs, bash history etc. and really hope that this very happened recently. Thanks for any tips and wish me good luck. :) AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus signatures; you might scan your box with that. It has an on-access, realtime monitor option as well, which I use it to monitor anything downloaded and or compiled on my box (in case the distribution screen gets hacked). http://www.free-av.com/en/download/download_servers.php Presuming you're rooted, you might first try their stand-alone, linux live-disk scanner so as to avoid borked kernel and/or core utilities: http://www.free-av.com/en/tools/12/avira_antivir_rescue_system.html
Re: [gentoo-user] Re: Rooted/compromised Gentoo, seeking advice
On Mon, Aug 9, 2010 at 1:59 PM, 7v5w7go9ub0o 7v5w7go9u...@gmail.com wrote: On 08/09/10 12:25, Paul Hartman wrote: [] If anyone has advice on what I should look at forensically to determine the cause of this, it is appreciated. I'll first dig into the logs, bash history etc. and really hope that this very happened recently. Thanks for any tips and wish me good luck. :) AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus signatures; you might scan your box with that. It has an on-access, realtime monitor option as well, which I use it to monitor anything downloaded and or compiled on my box (in case the distribution screen gets hacked). http://www.free-av.com/en/download/download_servers.php Presuming you're rooted, you might first try their stand-alone, linux live-disk scanner so as to avoid borked kernel and/or core utilities: http://www.free-av.com/en/tools/12/avira_antivir_rescue_system.html Was not aware of that one, I'll give it a try. Thanks.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Monday 09 August 2010 17:25:56 Paul Hartman wrote: My user account has sudo-without-password rights to any command. Ouch! There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? You have decided wisely to reinstall because you can't be sure of this OS anymore. Please keep us updated on what you find from the forensic analysis. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] GDBM incompatibility woes; any experts out there?
Around 2002, I started working on a project that involved a few simple
database tables, and I wanted it
simple, so I used python and the gdbm module. Since then, all has been
well. Now I find that not only
do the gdbm modules of python and perl reject my files, but so does a C
program that uses the distributed
libgdbm.
Okay, so you think I broke my files somehow. I was afraid that was true, so
I used the gdbm source
I had in distfiles, configured it with default setup but did not install
it. Instead I compiled it with my
C test program, and set out to find the problem in the data, more or less
expecting
to spend a long time in the debugger. But lo and behold, it worked just
fine. Now I'm suspecting that
the ebuild does something (Large File support?) to the GDBM that it didn't
used to do.
I did not know when I started how much configuration information I was going
to need, and so there's
a configuation database. As it happens, I never put more than one record in
it, so it's perfect for
simple testing. The database is called dbhex.control, and the single record
key is control. I've
attached it.
I used this Makefile, with no targets or rules, just to get the flags I
want: I have my testfile 'testgdbm.c' in
the same directory with the makefile, and a gdbm-1.8.3 directory.
I make testgdbm, run testgdbm dbhex.control and get exactly what I
should. If I link against the
Gentoo gdbm distribution, I get error 22 invalid argument. Not knowing
much about ebuilds, I'm not sure
how to tell what has changed.
Can anybody help me with:
1) why it fails now with Gentoo tools.
2) the best way to get it working again, preferably with both python and
C. I expect there's either
a compatibility flag, or I may need to do a file conversion. Overall,
my databases run to about
3 gigabytes, so it's doable either way.
Thanks in advance for any help.
# Makefile for tests
CC=gcc
CFLAGS=-Wall -g -m32 -ansi
LDFLAGS=-m32 gdbm-1.8.3/global.o gdbm-1.8.3/gdbmopen.o
gdbm-1.8.3/gdbmerrno.o gdbm-1.8.3/gdbmclose.o gdbm-1.8.3/update.o
gdbm-1.8.3/falloc.o gdbm-1.8.3/bucket.o gdbm-1.8.3/gdbmfetch.o
gdbm-1.8.3/findkey.o gdbm-1.8.3/version.o gdbm-1.8.3/gdbmseq.o
gdbm-1.8.3/hash.o
My test file:
/**
* @file
*
* Program to test minimal functionality of the gdbm library on a known gdbm
file.
*
* Last Modified: Mon Aug 9 12:01:32 PDT 2010/pre
* @author Kevin O'Gorman
*/
#include unistd.h
#include stdlib.h
#include stdio.h
#include gdbm.h
#include string.h
#include errno.h
void
fatal(void) {
fprintf(stderr, Fatal function called\n);
fprintf(stderr, Errno is %d\n, errno);
exit(EXIT_FAILURE);
}
/** The main thing.
* @param argc the number of tokens on the input line.
* @param argv an array of tokens.
* @return 0 on success, 1-255 on failure
*/
int
main(int argc, char *argv[])
{
datum key;
datum value;
datum nextkey;
char longbucket[4096];
printf(Running with GDBM: %s\n, gdbm_version);
if (argc !=2) {
fprintf(stderr, Usage:\n %s filename\n, argv[0]);
exit(EXIT_FAILURE);
}
errno = 0;
GDBM_FILE control = gdbm_open(argv[1], 1024, GDBM_READER, 0666, fatal);
if (control == NULL) {
perror(gdbm);
fprintf(stderr, Open returned NULL\n);
fprintf(stderr, Errno is %d\n, errno);
exit(EXIT_FAILURE);
}
printf(is open\n);
key = gdbm_firstkey(control);
while (key.dptr) {
memcpy(longbucket, key.dptr, key.dsize);
longbucket[key.dsize] = '\0';
printf(Key: %s, longbucket);
value = gdbm_fetch(control, key);
memcpy(longbucket, value.dptr, value.dsize);
longbucket[value.dsize] = '\0';
printf(, val: \%s\\n, longbucket);
free(value.dptr);
nextkey = gdbm_nextkey(control, key);
free(key.dptr);
key = nextkey;
}
gdbm_close(control);
printf(That's all, folks...\n);
return EXIT_SUCCESS;
}
/* vim: set et ai sts=2 sw=2: */
--
Kevin O'Gorman, PhD
dbhex.control
Description: Binary data
Makefile
Description: Binary data
/**
* @file
*
* Program to test minimal functionality of the gdbm library on a known gdbm file.
*
* Last Modified: Mon Aug 9 12:01:32 PDT 2010/pre
* @author Kevin O'Gorman
*/
#include unistd.h
#include stdlib.h
#include stdio.h
#include gdbm.h
#include string.h
#include errno.h
#define DBFILE dbgames/ogdb-
void
fatal(void) {
fprintf(stderr, Fatal function called\n);
fprintf(stderr, Errno is %d\n, errno);
exit(EXIT_FAILURE);
}
/** The main thing.
* @param argc the number of tokens on the input line.
* @param argv an array of tokens.
* @return 0 on success, 1-255 on failure
*/
int
main(int argc, char *argv[])
{
datum key;
datum value;
datum nextkey;
char longbucket[4096];
printf(Running with GDBM: %s\n, gdbm_version);
if (argc !=2) {
fprintf(stderr, Usage:\n %s filename\n, argv[0]);
exit(EXIT_FAILURE);
}
errno = 0;
GDBM_FILE control = gdbm_open(argv[1], 1024, GDBM_READER, 0666, fatal);
if (control == NULL) {
perror(gdbm);
fprintf(stderr,
[gentoo-user] kde-4.4.5 Seamonkey weirdness
Hello, Ever since my upgrade to kde-4.4.5 my seamonkey windows sporadically go black, when I move the mouse away from them. Both the Web browser and the mail client do this sporadically. Headers, toolbars and where the text appears all sporadically get into the act. Even just the subject window of this message is affected. Today, the color is solid gray. The maligned behavior always returns upon exiting kde or even rebooting the system. Also the scroll bar seems extraordinarily slow and often buffers up my keystrokes to the point of aimlessly wandering back and forth ignoring any new input, until it's wandering dance is exhausted. recompiling loads of stuff, as we speed to see if it fixes the problem. Anyone got any hints on this? bugs.gentoo.org did not reveal any pearls of wisdom that I could find ideas? James
Re: [gentoo-user] Re: Rooted/compromised Gentoo, seeking advice
On Monday 09 August 2010 19:59:11 7v5w7go9ub0o wrote: On 08/09/10 12:25, Paul Hartman wrote: [] If anyone has advice on what I should look at forensically to determine the cause of this, it is appreciated. I'll first dig into the logs, bash history etc. and really hope that this very happened recently. Thanks for any tips and wish me good luck. :) AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus signatures; you might scan your box with that. It has an on-access, realtime monitor option as well, which I use it to monitor anything downloaded and or compiled on my box (in case the distribution screen gets hacked). http://www.free-av.com/en/download/download_servers.php Presuming you're rooted, you might first try their stand-alone, linux live-disk scanner so as to avoid borked kernel and/or core utilities: http://www.free-av.com/en/tools/12/avira_antivir_rescue_system.html Another idea to help with your forensics would be to bring a netstat and lsof binary over to your machine and run them to see which actors are running and trying to get out. That could help you detect what is running on that machine and google your way from there. You could also run rkhunter. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, Aug 9, 2010 at 8:09 PM, Mick michaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. RobbieAB
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On 08/09/2010 01:08 PM, Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mick michaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. ...excepting, of course, sudo bash -l which means you've given away the keys to the kingdom.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mickmichaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. RobbieAB I don't use sudo here but I assume a admin would only know that a nasty command has been ran well after it was ran? Basically, after the damage has been done, you can go look at the logs and see the mess some hacker left behind. For me, that isn't a whole lot of help. You still got hacked, you still got to reinstall and check to make sure anything you copy over is not infected. Assuming that they can erase dmesg, /var/log/messages and other log files, whose to say the sudo logs aren't deleted too? Then you still have no records to look at. I agree with the other posters tho, re-install from scratch and re-think your security setup. Dale :-) :-)
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
100809 Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mick michaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. I follow 2 simple rules: (1) never start X as root -- I open in a raw terminal, then 'startx', so it's ok to login there as root to get some system fixes done, but of course logout again before starting X as user -- (2) do all system stuff in a virtual root terminal on its own desktop, where the prompt says 'root' in red letters the background is black (my user terminal has a white background): that's down in the basement, where all the pipes wires are you need a hard hat safety boots you need to unlock the basement door, whose key is the root password. also, my user terminal says : 524: gx which sudo which: no sudo in (/sbin:/usr/sbin:/usr/local/sbin::/bin:/usr/bin:/usr/local/bin:/usr/kde/3.5/bin) -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Monday 09 August 2010 21:25:37 Dale wrote: Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mickmichaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. RobbieAB I don't use sudo here but I assume a admin would only know that a nasty command has been ran well after it was ran? Basically, after the damage has been done, you can go look at the logs and see the mess some hacker left behind. For me, that isn't a whole lot of help. You still got hacked, you still got to reinstall and check to make sure anything you copy over is not infected. Assuming that they can erase dmesg, /var/log/messages and other log files, whose to say the sudo logs aren't deleted too? Then you still have no records to look at. I agree with the other posters tho, re-install from scratch and re-think your security setup. That's the problem with any compromise worth its salt, all logs will be tampered to clear traces of interfering with your system. Monitoring network traffic from a healthy machine is a good way to establish suspicious activity on the compromised box and it also helps checking for open ports (nmap, or netcat) to find out what's happening to the compromised box. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: GDBM incompatibility woes; any experts out there?
On 08/09/2010 12:33 PM, Kevin O'Gorman wrote: ... Now I find that not only do the gdbm modules of python and perl reject my files, but so does a C program that uses the distributed libgdbm. You didn't say how long ago the problem started, but looking at the files in sys-libs/gdbm I see nothing newer than March 20. Is your problem newer than March 20? Have you tried running your test program with strace?
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
Mick wrote: On Monday 09 August 2010 21:25:37 Dale wrote: Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mickmichaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. RobbieAB I don't use sudo here but I assume a admin would only know that a nasty command has been ran well after it was ran? Basically, after the damage has been done, you can go look at the logs and see the mess some hacker left behind. For me, that isn't a whole lot of help. You still got hacked, you still got to reinstall and check to make sure anything you copy over is not infected. Assuming that they can erase dmesg, /var/log/messages and other log files, whose to say the sudo logs aren't deleted too? Then you still have no records to look at. I agree with the other posters tho, re-install from scratch and re-think your security setup. That's the problem with any compromise worth its salt, all logs will be tampered to clear traces of interfering with your system. Monitoring network traffic from a healthy machine is a good way to establish suspicious activity on the compromised box and it also helps checking for open ports (nmap, or netcat) to find out what's happening to the compromised box. Yep, cause when they are in the system, they can do what they want. Once they get root privileges, nothing else matters after that. It's just a matter of the clean up which from what I have always read is a reinstall. It's not good to hear but it's the best way to know for sure you are safe. Me tho, I would start from scratch and not even chroot into the old install. I might mount and try to read a log file or copy my world file but that would be about it. I'm not sure I would trust anything else. I just hope this never happens to me. :/ Dale :-) :-)
[gentoo-user] gnome 2.30 and laptop
I have upgraded to gnome 2.30 and while there are a few rough edges, the display is causing real problems. When I am using a projector (beamer for the yanks here :) on external vga and LCD at the same time, the screen sometimes treats the vga out as a second screen (not a clone of the first which is what I want). Its random on how it happens. Then if I start any application, Mr Murphy will ensure it starts on the wrong output :) I suspect running vmware at some point before connecting the projector may have something to do with it (has never happened unless I have run vmware sometime since boot) Earlier gnome (=2.28) had a panel icon for managing the display but this had dissappeared with 2.30. so: 1. how can I manage the display from gnome 2.30 2. how can I fix the underlying problem of being cloned sometimes and not others. 3. how can I do an emergency fix without having to restart X (maybe a script/xrandr command if it exists?) i.e., its somewhat disastrous to discover this at the start of a presentation!) BillK -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, Aug 9, 2010 at 2:09 PM, Mick michaelkintz...@gmail.com wrote: On Monday 09 August 2010 17:25:56 Paul Hartman wrote: My user account has sudo-without-password rights to any command. Ouch! Having still not physically touched the machine yet, I don't know if sudo had anything to do with it at all at this point. But I'll assume for a moment that its use was perhaps involved... There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? Essentially. I did not think it through from an internally-defensive standpoint. I only thought of sudo as I am deciding whether to run this command as user or as root. Assuming *I* would be the only one running a program on my computer. My thinking was clearly flawed there... The idea of an attacker being in my system didn't really enter my mind. Or an untrusted program shelling out and running sudo some-bad-stuff without my knowing. Every sudo command is logged, sure, but as Bill pointed out that only works for as long as it takes someone to sudo himself into a root shell (or delete the logs). I don't really audit the sudo logs regularly because of the stupid assumption that I was the only one running any sudo commands. You have decided wisely to reinstall because you can't be sure of this OS anymore. I'm most concerned about learning how this happened because I don't want to reinstall everything only to be compromised again, and with the hope that perhaps any info I find can help others avoid finding themselves in this same situation. If I'm only going to re-create the exact same set-up, I don't know if I can be sure of it then even after reinstalling... Please keep us updated on what you find from the forensic analysis. Sudo was one of the first things that popped into my head. sshd is really the only service open to the outside. Some other ports are open for specific apps, like bittorrent traffic, which is what I was monitoring when I noticed the suspicious activity -- and I was downloading a Linux ISO, I swear. My original plans for tonight were to install Sabayon on an old laptop that is becoming unmanageable from a Gentoo standpoint due to infrequent use and days-long update sessions. I'll put that little project on hold for now... My sshd setup is pubkey only, no root logins, and I use denyhosts to block after 3 failed logins, and it syncs its blocklist from the denyhosts master server many times a day. I use NX Server, but not with the default key, and I don't think there have been any (publicly disclosed) remotely-exploitable opensshd vulnerabilities that would allow an attacker direct entry into a system. I haven't noticed anything out of place on my system, no unusual files or missing items. I take infrequent peeks at my ssh logs, w/who/last and network traffic (as I did today when I discovered it), but I am not religious about reading every log. Life has been quite busy lately and I haven't had as much time to dedicate to that sort of stuff. I has been more like log on, check my email, pay my bills, log off. So, from that outside-entry standpoint I was certainly lulled into a false sense of security about my system. My root account has a very long and complicated password, and my user account was surely impenetrable since I was using pubkey-only SSH logins, right... I have encrypted partitions, but they are mounted when the system is up and running, so they are really pointless against an online attack... Typing that long password into sudo every time I ran a command was a hassle, and clearly I thought myself too intelligent to ever run a malicious piece of code on my own computer. I mean, that's the kind of thing I would never do. I'm careful. I usually look at things before I run them, scan them with clamscan (not that I run outside scripts/binaries very often at all). Right? And what if a seemingly-safe program decided to download and run malware on its own? What if there was a vulnerability that was exploited before it was discovered patched by the community (and my Gentoo update cycle)? What if there was a rogue Firefox add-on stealing passwords or running shell scripts? That would probably never happen, surely someone else would have noticed it and put a stop to it before it got to me, or I would have read a warning about it in the tech news someplace. Yeah, I'm being a bit sarcastic here. ;) I do hope I can find some evidence that leads me to the point of entry. It would set my mind at ease.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman bill.long...@gmail.com wrote: On 08/09/2010 01:08 PM, Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mick michaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. ...excepting, of course, sudo bash -l which means you've given away the keys to the kingdom. I actually prefer sudo su - -- as long as I'm giving it away! :o) -- Kevin O'Gorman, PhD
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, Aug 09, 2010 at 05:30:40PM -0700, Kevin O'Gorman wrote: On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman bill.long...@gmail.com wrote: On 08/09/2010 01:08 PM, Robert Bridge wrote: On Mon, Aug 9, 2010 at 8:09 PM, Mick michaelkintz...@gmail.com wrote: There have been discussions on this list why sudo is a bad idea and sudo on *any* command is an even worse idea. You might as well be running everything as root, right? sudo normally logs the command executed, and the account which executes it, so while not relevant for single user systems, it STILL has benefits over running as root. ...excepting, of course, sudo bash -l which means you've given away the keys to the kingdom. I actually prefer sudo su - -- as long as I'm giving it away! :o) Afaik, there is no reason for sudo su - It should be either su - or, if you are using sudo, sudo -i The disadvantage of su - is that it requires the user to know the root password. But, sudo -i does the same thing without requiring the user to know the root password. William
Re: [gentoo-user] Re: GDBM incompatibility woes; any experts out there?
On Mon, Aug 9, 2010 at 2:49 PM, walt w41...@gmail.com wrote: On 08/09/2010 12:33 PM, Kevin O'Gorman wrote: ... Now I find that not only do the gdbm modules of python and perl reject my files, but so does a C program that uses the distributed libgdbm. You didn't say how long ago the problem started, but looking at the files in sys-libs/gdbm I see nothing newer than March 20. Is your problem newer than March 20? Have you tried running your test program with strace? I hadn't done anything with that application in over a year, so I did not have any way to narrow it down. As it happens, I had a sudden rush of brains to the head and read the ewarn message that comes out when you compile gdbm, to the effect that 32-bit systems may have to rebuild, etc, etc. As I suspected, it was LFS-related. Write it off as a case of RTFLog. Now all I have to do is discover why an ewarn wasn't emailed to me -- I thought I had that set up. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
Am Dienstag, 10. August 2010 schrieb Paul Hartman: Typing that long password into sudo every time I ran a command was a hassle I’ve never used sudo, and never really liked the idea of it. In fact I’m always amused and slightly annoyed by the sheer amount of sudo one can find in your typical ubuntu howto. ;-) It’s one reason why I abstained from installing Truecrypt 6, because it requires sudo (Yes I know, in default setup you can’t do much with it. It is but an issue of principle). However, because I need root commands regularly (for example to initiate the VPN to my uni’s WiFi), I usually have one tab in Yakuake where I do a normal su once after login. And for more safety on my part, I also use different prompts: red hostname for root console, green u...@hostname for nonroot. -- Gruß | Greetings | Qapla' What’s right is right, otherwise it’d be wrong. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2010, at 11:44 AM, Frank Steinmetzger wrote: Am Dienstag, 10. August 2010 schrieb Paul Hartman: Typing that long password into sudo every time I ran a command was a hassle I’ve never used sudo, and never really liked the idea of it. In fact I’m always amused and slightly annoyed by the sheer amount of sudo one can find in your typical ubuntu howto. ;-) It’s one reason why I abstained from installing Truecrypt 6, because it requires sudo (Yes I know, in default setup you can’t do much with it. It is but an issue of principle). However, because I need root commands regularly (for example to initiate the VPN to my uni’s WiFi), I usually have one tab in Yakuake where I do a normal su once after login. And for more safety on my part, I also use different prompts: red hostname for root console, green u...@hostname for nonroot. -- Gruß | Greetings | Qapla' What’s right is right, otherwise it’d be wrong. I hope you realise the use of sudo -i will give you a root shell just like su. The reason sudo is preferred is that it means between multiple administrators, you can eliminate the need for a shared password. sudo can also control who and what groups can access sudo, and even subsets of commands. sudo also has a grace timer in which once you prove your identity with your password once, you can use sudo without a password for a period of time after that. This can also be canceled with sudo -k In terms of system administration best practices, sudo is the way to go. You will see it used in all server administration tasks to escalate privileges, in a secure manner. William Brown pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBAgAGBQJMYLhgAAoJEHF16AnLoz6JhJ8QAL5SO5DRmcQ3wXLdtMZooACu WT4qyfKBnfMqakLJlSWYOH6tuIoK/mVYpeCpQmjpTuKaE90tnLnngCOVnG7puyqG LkPBNew3iOsO0JJcNzCcMiwWQ1C7d2hkSyNl48FVwBwaVgbPmWL6flPLxwHxdbU1 O2Kke8ku2dAVRTg9NdnPnTcc7y1h2/VYLwqSY10ybHS4I6a7YuhEIeGZtCqfEZ6d 0WkbUaU2IJFEVskR2pRV3Oh8FOgjW1XpYPzGrzQgpByghVgDxalFpC89g3xVw2ue bbRZNcn6NfZnfS/ltsCLr0mzSkV9xUXtYJkSQWN2jZbXM5rr+5gQXk1CqYLeDkjS 4HFST6bFfUUl7KMlo/mfH7PSD3Coa1J/DwcZFM9xkMx/sTy/TDsQhG1Qgb5jSn4u /TVYRwkvNj/KXBolDPcEQkZ6h35R8h9gGFRaW9u1+O2YyLC8uOyFUhd0iHNo0+s0 r4Q0wiwnY7I5CI2ZQ5h2blbYzqyvgSa43rYp3rho9cp4LktDKO2qfoIW/CV/0Q6r NmWcuzaU17QTAQn8VL2SUfG0zqXgCI4NlQcU8iNnYFRGUTvdx4crjzrgIqYm2rc+ PbpFuLl4Uz000hsQYXWfy9hwIMbxilT4F9AOpKmyU392GZ/22WUvoMk2uhzt8aCf w44gvZvW1e44buFM2L/z =AR4J -END PGP SIGNATURE-
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
On Mon, 9 Aug 2010 18:07:15 -0500 Paul Hartman paul.hartman+gen...@gmail.com wrote: I do hope I can find some evidence that leads me to the point of entry. It would set my mind at ease. Please let us know. I'm really curious about this also. I hope it wasn't a trojaned package in portage. -- -- -- Keith Dart =
Re: [gentoo-user] kde-4.4.5 Seamonkey weirdness
Ever since my upgrade to kde-4.4.5 my seamonkey windows sporadically go black, when I move the mouse away from them. Both the Web browser and the mail client do this sporadically. Headers, toolbars and where the text appears all sporadically get into the act. Even just the subject window of this message is affected. Today, the color is solid gray. The maligned behavior always returns upon exiting kde or even rebooting the system. Also the scroll bar seems extraordinarily slow and often buffers up my keystrokes to the point of aimlessly wandering back and forth ignoring any new input, until it's wandering dance is exhausted. recompiling loads of stuff, as we speed to see if it fixes the problem. Anyone got any hints on this? bugs.gentoo.org did not reveal any pearls of wisdom that I could find Interesting - sounds similar to what i get - see my thread Some corruption after gnome 2.30. I rebuilt world and still have the problem. So perhaps.there is something lower level than gnome/kde that causes this issue.
Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice
Alternatively I was running vulnerable/compromised software. My box has sshd running, root login in ssh is not allowed, and pubkey only logins (no passwords). It is behind a wireless router but port 22 is open and pointing to this box, and a few others needed by other applications. So I will check out which keys exist on the compromised machine and make sure I recognize them all. I'll also need to check the status of any other computer my key is stored on (a mix of linux windows, and my mobile phone). Sigh... Since you're sshd setup is pretty secure i'd look at other network services. What else was running, and were there any servers that were only available from the local net (or were less protected from connections from the local net) than the Internet? That's the only case where a router compromise would assist in attacking your gentoo box. There have been some web browser based attacks that have come out against routers recently. They run the attack on your browser (cross site scripting IIRC) to get access to the web interface of the router because that is typically not available via the Internet side interface. Then then run a password guessing attack. Did your router have a strong password?
