Slashdot Mirror
Ongoing Linux/Solaris Compromise Epidemic
An anonymous reader writes to point out that Stanford's Information Technology Systems and Services "has written a summary of a series of compromises that have been happening at universities, research institutions, and high performance computing centers, for the last month or more. The attackers are using known vulnerabilities in Linux and Solaris, along with compromised user accounts, to gain access and control of systems, from standalone servers to HPC clusters ... (the attacks are still ongoing)."
It says that good passwords are a good defense.
We know this.
No more default last 4 digits of SSN as a password.
Make them use something more secure! And disable telnet, for goodness sakes.
Inconvieience (sp?) your students in order to secure your system. It's all fun and games until someone uses a rootkit to play with GPAs.
Jay | http://oldos.org
on just how widespread this attack really is. The story IS HERE
...because you never know who you're dealing with.
A cluster is almost always _not_ a heterogenous environment. On top of that, the individual cluster machines should not have, nor do they need, access to the network as a whole. Compared to things like computer labs, HPC clusters should be the easiest thing to secure, since you -can- firewall the hell out of them.
There's no excuse, when putting up a several hundred node cluster to not get an extra machine through which it needs to be accessed that is not part of the cluster. That machine can trivially be kept secure & the cluster can then be updated as is convenient (IE - not replacing the kernel in the middle of a 3-week long computation; even at that, tho, anything that's going to take 3wk should be able to checkpoint itself without loosing much).
my sig's at the bottom of the page.
Here is a list of some things that I feel are worth considering:
:). Next configure swatch to alert you upon recieving such messages! Of course you can always use perl or even grep -v to parse logs, but for repeated use I think a specialised tool would save you some trouble in the long run.
1. Patch your system! As soon as a patch comes out, get it applied and reboot if you have to! Also, stay up to date on security issues by subscribing to mailing lists that are related to the software your using. One good general purpose site is cert.org. Keep in mind that while mailing lists are great ways of being notified, they arent fool proof. If your subscription expires and you dont know about it, you wont be exactly up to date in the community now will you?
2. Use grsecurity. This is a kernel patch that is briefly lagged behind official Linux kernel versions. It has many great features for protecting against stack attacks/buffer overflows. ie: Those latest greatest scripts your local script kiddie just downloaded wont likely do anything against you since special addresses are randomised. It can also hide files on your computer such as intergrity checkers so nobody except you know they exist. Plus it can stop insert code into a running kernel by making kernel memory readonly (which btw, would have prevented at least one of the attacks they mentioned).
3. Install a filesystem intergrity checker. Aide, integrit and tripwire all come to mind and essentially all do the same thing but with different config file syntax. Besides, how can you tell if a file is changed if you dont actually check? Also, dont forget to hide the existence of this program using something like grsec's gradm filesystem ACL util and be careful of automating checks in the crontab!
4. Read a good linux securing article. One such article I have read is called Securing & Optimizing Linux: The Ultimate Solution. It will teach you how to lock a system down a fair bit and how to remove unused/unneeded services from your computer.
5. Watch those logs! Log files provide a wealth of information, but administrators rarely check them (well, not all). If you dont know what a log entry means, research it, or else you may be looking at an attack and not even realise it. Now I know some of you are thinking I am nuts considering just how many logs even a small system generates, but there are tools to help you. One way is to use a program called swatch (a perl script). It can parse existing and old archived log files using a perl regex syntax and trigger actions based on found text. Start by configuring the system to ignore any log entries that are known to be friendly and show you everything. Then slowly eliminate each friendly entry one at a time. What will be left is a list of purely evil enteries
Now I know I could go on forever with suggestions, but I think that these few things should give anyone a kick in the right direction. I hope this has been helpful.