Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
although my team did not do a RCA that led to the vector of attack, we do know a fw rule was put in place during the install of the fw which opened many systems to the public on SSH (about 1+ years ago). SSH scanning was well underway when a few months back the compromised system was added as a static NAT to the fw, which inherently allowed SSH to the public due to the rules of installation.
customer installed a Nagios component using default uid/passwd and that account was compromised via a SSH dictionary attack. the attacker downloaded a 100MB file which looked to contain the data needed to create the files the attacker used to launch a UDP flood, a egress SSH scanner, and a IRC bot which connected to a Undernet IRC server in Tampa FL using.
The UDP flooder was a perl script. The SSH scanner was an ELF "pscan2", and we also found a ELF "hide" which could hide processes as alternate names.
There was a cron entry which would check daily for the existence of the ELF PID and re-launch if not found.
the system was an Oracle RAC cluster node, but customer deinstalled the node before i was able to look deeper into the Oracle stuff. however, there was no evidence indicating that the attacker files tried to query Oracle, nor were there any files that contained data the was present in the db. attacker only had limited access of the "nagios" account and thus had no access to db files directly.
the cisco IDS in place (module in ASA) is able to detect SS#'s, but since it would use to much resources such rule cannot be used (per crisco tac), so we were blind to that type of PII detection.
Last edited by Linux_Kidd; 11-22-2012 at 09:27 PM.