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)."
Uhm, I think it was a joke ..
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.
Don't send passwords in plain text on the network, and enforce proper password policies (8 char minimum, numbers, letters and symbols etc).
Servers were down much of last week. The ITS website has a few brief details.
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.
Not really. The vulnerablities in Linux/Solaris have been fixed, thus it is a security issue. The vulnerablities in Windows are still current, thus it is a bug.
Since when has this country used intellectual elite as a pejorative term?
Washington Post has more coverage in this article, Hackers Strike Advanced Computing Networks.
If the Government becomes a lawbreaker, it breeds contempt for law;
Its hard to sit idly by as some statements like this are made. As an individual who has helped out with these systems and further helps maintain processes to keep systems up to date (almost all linux boxen involved use apt-get updates to state up to date pretty religiously), it has generally been the case the successfully attacked systems have come by unique approaches to each machine. Most have been indirect attacks via local root exploits using compromised user names from other institutions. Passwords are generally cracked and not sniffed, with almost all exploits using recently announced local root exploits on systems otherwise protected from direct access to the internet. In a nutshell, these are focused, diligent attempts using a wide arsenal of previously known and unknown attacks (yes, some locally compromised systems were truly patched!) to gain as much resources as possible. It pains me that the people here are apt to paint with such a wide paint brush, when in fact these types of attacks are generally successful whenever there is a keen focus to gain resources and its not your run-of-the-mill script kiddie.
I'll also answer that our redhat-based distros used to use libsafe, but newer 9-based versions have incompabilities with that library (matlab and other standard tools don't work with it, and it hasn't been updated for the new nptl stuff). Also, libsafe doesn't help against the kernel exploits (it didn't help). grsecurity is hard to deploy uniformly, especially when you rely on stock vendor kernels because of other vendor requirements.
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.