Re: Recommend good IDS? was Re: /dev/shm/r?
Hi! john schrieb: I'd be interested to hear some recommendations for IDS to run on internet facing servers. Especially from the point of view of ease of installation, ease of maintenance, quality of the tool, and ability to have it deliver really useful information to the admin. I've used SNORT a bit in the past and my feeling was that it was so chatty that it was actually hard to tell if something bad was happening or not. Don't think it really counts as IDS, but I like to use tiger and rkhunter. They perform some checks on the system on a regular basis. That is not a really good protection against unauthorized access (well; it might catch stupid cracker ;) but at least it helps to protect the systems from myself, e.g. when I tweak some configuration option during a maintenance task in an insecure manner (e.g. allow root login via ssh until I'm finished setting up the system) tiger will remind me to reset the save values :) Best regards, Alexander -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Recommend good IDS? was Re: /dev/shm/r?
On Tue, Jun 2, 2009 at 4:45 PM, Josh Lauricha j...@lauricha.com wrote: I'm surprised more people aren't running tripwire or other IDS. I'd be interested to hear some recommendations for IDS to run on internet facing servers. Especially from the point of view of ease of installation, ease of maintenance, quality of the tool, and ability to have it deliver really useful information to the admin. I've used SNORT a bit in the past and my feeling was that it was so chatty that it was actually hard to tell if something bad was happening or not. John -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommend good IDS? was Re: /dev/shm/r?
In 2be970b50906030853t29dfb90atd60089611f98e...@mail.gmail.com, john wrote: On Tue, Jun 2, 2009 at 4:45 PM, Josh Lauricha j...@lauricha.com wrote: I'm surprised more people aren't running tripwire or other IDS. I'd be interested to hear some recommendations for IDS to run on internet facing servers. I inherited a tripwire installation at some point. It was one mail message per day (and if you didn't get that message you knew something was wrong). It required a bit of tuning to not report errors regularly, but once I spent that time it was fairly hands-off. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Recommend good IDS? was Re: /dev/shm/r?
Remember, that a HIDS (host IDS) is just a detective control on the host. It shows that you have been hacked, you will probably want a good NIDS (network IDS) to see what attacks are being attempted over the wire. HIDS is good to quickly detect a compromise... http://sourceforge.net/projects/aide http://packages.debian.org/search?keywords=aide On Jun 3, 2009, at 9:55 AM, Boyd Stephen Smith Jr. wrote: In 2be970b50906030853t29dfb90atd60089611f98e...@mail.gmail.com, john wrote: On Tue, Jun 2, 2009 at 4:45 PM, Josh Lauricha j...@lauricha.com wrote: I'm surprised more people aren't running tripwire or other IDS. I'd be interested to hear some recommendations for IDS to run on internet facing servers. I inherited a tripwire installation at some point. It was one mail message per day (and if you didn't get that message you knew something was wrong). It required a bit of tuning to not report errors regularly, but once I spent that time it was fairly hands-off. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommend good IDS? was Re: /dev/shm/r?
Quoting Boyd Stephen Smith Jr. (b...@iguanasuicide.net): I inherited a tripwire installation at some point. It was one mail message per day (and if you didn't get that message you knew something was wrong). It required a bit of tuning to not report errors regularly, but once I spent that time it was fairly hands-off. One way to use Tripwire in conjunction with a slightly more modern and lightweight file-based IDS alongside it: http://linuxgazette.net/issue98/moen.html (That article is not, however, a comparative review, which is apparently what the original poster is seeking.) -- Cheers, Notice: The value of your Hofstadter's Constant Rick Moen(the average amount of time you spend each month r...@linuxmafia.com thinking about Hofstadter's Constant) has just McQ! (4x80) been adjusted upwards. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommend good IDS? was Re: /dev/shm/r?
On Wed, Jun 3, 2009 at 5:53 PM, john lists.j...@gmail.com wrote: I'd be interested to hear some recommendations for IDS to run on internet facing servers. Especially from the point of view of ease of installation, ease of maintenance, quality of the tool, and ability to have it deliver really useful information to the admin. I've used SNORT a bit in the past and my feeling was that it was so chatty that it was actually hard to tell if something bad was happening or not. We use aide. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommend good IDS? was Re: /dev/shm/r?
On Wed, 2009-06-03 at 08:53 -0700, john wrote: On Tue, Jun 2, 2009 at 4:45 PM, Josh Lauricha j...@lauricha.com wrote: I'm surprised more people aren't running tripwire or other IDS. I'd be interested to hear some recommendations for IDS to run on internet facing servers. Especially from the point of view of ease of installation, ease of maintenance, quality of the tool, and ability to have it deliver really useful information to the admin. It really depends on what you want. I'm using a combination of PADS (Passive Attack Detection System) and fail2ban ... these can both be run on either a host or a router, and integrate with netfilter. You can customise what they are looking for to report and ban. Fail2ban is good, it lets me blackhole people attempting nasty things in quick order ... even better when combined with ipset and a decent firewall setup. -- Nikolai Lusan niko...@lusan.id.au -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommend good IDS? was Re: /dev/shm/r?
I really like OSSEC. It's licensed under GPL V3. The agent runs on multiple platforms. It's easy to install, relatively easy to configure. The agent is a self-contained HIDS, rootkit detector, log and file monitor. It can also decode Snort, Cisco PIX/ASA, IPTables, and a a whole lot of other logs. This means that it can act as a centralized security monitoring and alerting system. There are tons of other features that I'm not going to mention here. Oh yeah, and you can get commercial support for it if needed. - Jeremy Melanson On Wed, 2009-06-03 at 10:14 -0700, Rick Moen wrote: Quoting Boyd Stephen Smith Jr. (b...@iguanasuicide.net): I inherited a tripwire installation at some point. It was one mail message per day (and if you didn't get that message you knew something was wrong). It required a bit of tuning to not report errors regularly, but once I spent that time it was fairly hands-off. One way to use Tripwire in conjunction with a slightly more modern and lightweight file-based IDS alongside it: http://linuxgazette.net/issue98/moen.html (That article is not, however, a comparative review, which is apparently what the original poster is seeking.) -- Cheers, Notice: The value of your Hofstadter's Constant Rick Moen(the average amount of time you spend each month r...@linuxmafia.com thinking about Hofstadter's Constant) has just McQ! (4x80) been adjusted upwards.
Re: Recommend good IDS? was Re: /dev/shm/r?
Hi, If you run large nuber of hosts, i suggest samhain. You have many features builtin (monitoring of files, system.map altering, suid bits, appending only on log files etc.). It works on client server model (a server who centralize hosts integrity database). Communications are secure (AES for ciphering and SRP for authentication). The deployement procedure is very convenient : you can build samhain instances on dedicated machines and deploying them on network with a sing script. Everything done over SSH. Give it a try ;-) Ressource : http://la-samhna.de/samhain/ 2009/6/3 Jeremy Melanson jmelan...@systemhalted.com: I really like OSSEC. It's licensed under GPL V3. The agent runs on multiple platforms. It's easy to install, relatively easy to configure. The agent is a self-contained HIDS, rootkit detector, log and file monitor. It can also decode Snort, Cisco PIX/ASA, IPTables, and a a whole lot of other logs. This means that it can act as a centralized security monitoring and alerting system. There are tons of other features that I'm not going to mention here. Oh yeah, and you can get commercial support for it if needed. - Jeremy Melanson On Wed, 2009-06-03 at 10:14 -0700, Rick Moen wrote: Quoting Boyd Stephen Smith Jr. (b...@iguanasuicide.net): I inherited a tripwire installation at some point. It was one mail message per day (and if you didn't get that message you knew something was wrong). It required a bit of tuning to not report errors regularly, but once I spent that time it was fairly hands-off. One way to use Tripwire in conjunction with a slightly more modern and lightweight file-based IDS alongside it: http://linuxgazette.net/issue98/moen.html (That article is not, however, a comparative review, which is apparently what the original poster is seeking.) -- Cheers, Notice: The value of your Hofstadter's Constant Rick Moen(the average amount of time you spend each month r...@linuxmafia.com thinking about Hofstadter's Constant) has just McQ! (4x80) been adjusted upwards. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz vladislav.k...@webstep.net wrote: Well, this really looks suspicious. Look for unexpected processes running, open ports, etc. Directory /dev/shm/ is world-writable like /tmp, so chances are that the attacker did not gain root yet. But he might have shell listening on some port and trying hard to get root using some local exploit. I agree, chances are the box hasn't been exploited just yet, but I would be worried about just how he got that file there in the first place. We know that directory is world writable, so it could have been written by anything, but what? Sometimes the ownership of the file will give it away, for example, if the file is owned by www-data, you know some exploit in apache (usually php!) was used to gain file system access. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
Izak Burger schrieb: On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz I agree, chances are the box hasn't been exploited just yet, but I would be worried about just how he got that file there in the first place. We know that directory is world writable, so it could have been written by anything, but what? Sometimes the ownership of the file will give it away, for example, if the file is owned by www-data, you know some exploit in apache (usually php!) was used to gain file system access. Yes, chances are, that it's just some unsecure script in a webspace. Not good, but if you are a webservice provider, you always have some special customer. I even know companies which buy a cms and don't think of who cares for it over the time as long as it's running ... On the other hand, you should keep in mind, that it could be someone who has gained root provileges and hides some of his activities. If he is root, then there has to be some other traces left of him. So you should collect other information: - lsof and /proc, if you find suspicious processes - intrusion detection software - logfile scanning software and manual examining log files including firewall logs Good point is, when you can trace times of activity. But always keep in mind, that the information could be wrong. -- Guntram Trebs freier Programmierer und Administrator g...@trebs.net +49 (30) 42 80 61 55 +49 (178) 686 77 55 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote: Yes, that's a typical location for intruders to drop files. Easiest thing to do is reinstall after thinking about how the compromise may have occurred. (Did you update regularly, including kernel updates? Did all accounts have strong passwords? Do you have web applications not managed by the system that weren't being updated? etc.) We had a serious situation on this computer and several others. Ssh and sshd were replaced by the cracker's own version and in once case nearly all the pam-related stuff were replaced also. Through this customised versions of ssh the cracker harvested every password that was used during ssh logins and ssh sessions. We are winning the battle and will in the next few weeks try do the analysis of what went wrong. Regards Johann -- Johann Spies Telefoon: 021-808 4599 Informasietegnologie, Universiteit van Stellenbosch Thou wilt show me the path of life: in thy presence is fulness of joy; at thy right hand there are pleasures for evermore. Psalms 16:11 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
Although it's worse if an attacker has root, don't think that just because the attacker doesn't have root, it's no big deal. If an attacker can run (even as an ordinary user) unauthorized software on your machine, then your machine may be part of a botnet. And having unauthorized user access to a machine leaves the door open for trojan horse type programs which may give the user root access. Finally, depending on the user account which is compromised, the attacker may already have access to sensitive data. Don't obsess on root access. Any unauthorized use is a problem. --- Wade On Tue, June 2, 2009 00:35, Guntram Trebs wrote: Izak Burger schrieb: On Mon, Jun 1, 2009 at 12:26 PM, Vladislav Kurz I agree, chances are the box hasn't been exploited just yet, but I would be worried about just how he got that file there in the first place. We know that directory is world writable, so it could have been written by anything, but what? Sometimes the ownership of the file will give it away, for example, if the file is owned by www-data, you know some exploit in apache (usually php!) was used to gain file system access. Yes, chances are, that it's just some unsecure script in a webspace. Not good, but if you are a webservice provider, you always have some special customer. I even know companies which buy a cms and don't think of who cares for it over the time as long as it's running ... On the other hand, you should keep in mind, that it could be someone who has gained root provileges and hides some of his activities. If he is root, then there has to be some other traces left of him. So you should collect other information: - lsof and /proc, if you find suspicious processes - intrusion detection software - logfile scanning software and manual examining log files including firewall logs Good point is, when you can trace times of activity. But always keep in mind, that the information could be wrong. -- Guntram Trebs freier Programmierer und Administrator g...@trebs.net +49 (30) 42 80 61 55 +49 (178) 686 77 55 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Wade Richards (w...@wabyn.net) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Tue, Jun 2, 2009 at 6:42 PM, Wade Richards w...@wabyn.net wrote: Don't obsess on root access. Any unauthorized use is a problem. You are right of course. Right after I sent my message saying that perhaps the machine hasn't been exploited yet I realised how wrong such a view is. Someone gained access to an area they should not have access to, it has been exploited already. I have been fortunate enough to only be in this situation twice in the last ten years. The first time was due to a weak password, and luckily our attacker only installed an irc bouncer (renamed to bash so it wouldn't stand out in a process listing). We could literally get away with not reinstalling the entire machine, because the damage was limited to one user account (yes, we did check for replaced binaries :-) ). The second time was caused by a php hosting control panel, which gave the attackers (Turkish crackers unhappy with that Danish cartoon) the ability to create ftp accounts and deface websites. Once again, the damage was limited and we got away without a full reinstall. It was in this sense that I hoped Johann (a former colleague of mine) might be lucky enough to get away with limited damage. Wait, there was a third time. On a CentOS box, I found a core file in /etc/cron.d. I immediately realised what it was as I had an argument about which kernel versions is affected with someone just the previous week (thread here: http://lists.clug.org.za/pipermail/clug-tech/2006-July/032952.html). In this case, we eventually found that a former employee of the organisation tried several exploits on the machine and left some tell-tale signs behind. In this instance, though it seemed none of the exploits succeeded, we decided to trash the CentOS install and move to Debian :-) In any case, enough about me. Good luck Johann, and I look forward to more information on exactly what happened here. regards, Izak -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
Hello, there are few chances of replacing sshd without being root. In your place i would install every server new. I think, he spied out passwords and maybe got root-Passwords in this way. Possibly he has even accessed servers where you didn't find him and left backdoors there. (manipulation of ~/.ssh/authorized_keys, another user with userid 0, replaced software, replaced suid-accesses, added software, ...) When you reinstall your servers think of not using Login+Password but public-private key for user authentication. You can even forward such a combination. But be aware, that if key forwarding is enabled it can be used by attackers too. You should then protect the private key by password and use it only from trusted machines. Avoid keyforwarding unless you need it, for instance when copying files from one server to the other it could be useful. Lock your trusted working computer always when leaving it and think of encrypting the filesystem. (Be aware that a local attacker can install a password sniffer even if you encrypted your system partition) good luck and think of not accessing the new installed computers from old ones ... Regards, Guntram Johann Spies schrieb: On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote: Yes, that's a typical location for intruders to drop files. Easiest thing to do is reinstall after thinking about how the compromise may have occurred. (Did you update regularly, including kernel updates? Did all accounts have strong passwords? Do you have web applications not managed by the system that weren't being updated? etc.) We had a serious situation on this computer and several others. Ssh and sshd were replaced by the cracker's own version and in once case nearly all the pam-related stuff were replaced also. Through this customised versions of ssh the cracker harvested every password that was used during ssh logins and ssh sessions. We are winning the battle and will in the next few weeks try do the analysis of what went wrong. Regards Johann -- Guntram Trebs freier Programmierer und Administrator g...@trebs.net +49 (30) 42 80 61 55 +49 (178) 686 77 55 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
I'm surprised more people aren't running tripwire or other IDS. On Tue, Jun 2, 2009 at 1:37 PM, Guntram Trebs g...@trebs.net wrote: Hello, there are few chances of replacing sshd without being root. In your place i would install every server new. I think, he spied out passwords and maybe got root-Passwords in this way. Possibly he has even accessed servers where you didn't find him and left backdoors there. (manipulation of ~/.ssh/authorized_keys, another user with userid 0, replaced software, replaced suid-accesses, added software, ...) When you reinstall your servers think of not using Login+Password but public-private key for user authentication. You can even forward such a combination. But be aware, that if key forwarding is enabled it can be used by attackers too. You should then protect the private key by password and use it only from trusted machines. Avoid keyforwarding unless you need it, for instance when copying files from one server to the other it could be useful. Lock your trusted working computer always when leaving it and think of encrypting the filesystem. (Be aware that a local attacker can install a password sniffer even if you encrypted your system partition) good luck and think of not accessing the new installed computers from old ones ... Regards, Guntram Johann Spies schrieb: On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote: Yes, that's a typical location for intruders to drop files. Easiest thing to do is reinstall after thinking about how the compromise may have occurred. (Did you update regularly, including kernel updates? Did all accounts have strong passwords? Do you have web applications not managed by the system that weren't being updated? etc.) We had a serious situation on this computer and several others. Ssh and sshd were replaced by the cracker's own version and in once case nearly all the pam-related stuff were replaced also. Through this customised versions of ssh the cracker harvested every password that was used during ssh logins and ssh sessions. We are winning the battle and will in the next few weeks try do the analysis of what went wrong. Regards Johann -- Guntram Trebs freier Programmierer und Administrator g...@trebs.net +49 (30) 42 80 61 55 +49 (178) 686 77 55 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Josh Lauricha -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
/dev/shm/r?
I am a bit worried that my computer have been compromised. Rkhunter reported: [10:35:47] Warning: Suspicious file types found in /dev: [10:35:47] /dev/shm/r: ASCII text [10:35:48] Checking for hidden files and directories [ Warning ] [10:35:48] Warning: Hidden directory found: /etc/.java [10:35:48] Warning: Hidden directory found: /dev/.udev [10:35:48] Warning: Hidden directory found: /dev/.initramfs I think the last three lines are not problematic but in /dev/shm/r I found: spawn /bin/bash interact Do I have reason to be worried? Regards Johann -- Johann Spies Telefoon: 021-808 4599 Informasietegnologie, Universiteit van Stellenbosch Thou wilt show me the path of life: in thy presence is fulness of joy; at thy right hand there are pleasures for evermore. Psalms 16:11 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 10:46:54AM +0200, Johann Spies wrote: I am a bit worried that my computer have been compromised. ... I think the last three lines are not problematic but in /dev/shm/r I found: spawn /bin/bash interact Do I have reason to be worried? Yes, that's a typical location for intruders to drop files. Easiest thing to do is reinstall after thinking about how the compromise may have occurred. (Did you update regularly, including kernel updates? Did all accounts have strong passwords? Do you have web applications not managed by the system that weren't being updated? etc.) Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 12:26:49PM +0200, Vladislav Kurz wrote: On Monday 01 of June 2009, Johann Spies wrote: spawn /bin/bash interact Note that this seems to be a simple expect(1) script which runs a shell. Not necessarily an indication of anything apart from a possible attacker trying to exploit something using expect. -- Marcin Owsiany porri...@debian.org http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/shm/r?
On Mon, Jun 01, 2009 at 12:31:04PM +0100, Marcin Owsiany wrote: Note that this seems to be a simple expect(1) script which runs a shell. Not necessarily an indication of anything apart from a possible attacker trying to exploit something using expect. It's also an indication that the attacker could write to the filesystem... Mike Stone -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
