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.
ObviousGuy is a known karma-whore. Reread his post and you'll find nothing of value whatsoever in it to anybody above 12 years of age : everything he posts is noncommital banalities. Consult his posting history...
Yes, I use this.
I also combine it with grsecurity, which adds even more protection.
You should always remember though, these are just added layers of security. If someone can sniff your root password you're still cactus.
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;
... at any of these places where the attacks are occuring have any other information to add? I am interested if there is information that might have been gleaned from any captured code that might indicate the exact identity of whom the attackers were going to DDoS once they had their zombied supercomputers. Or was it going to be a DDoS? Another exploit? I think that info might be a clue (well obviously) to who is behind this. One would think that attempting to zombiefy a super computer run by some advanced admins would be more difficult (and thus more unlikley to be used for such a mundane cause) that just gathering-say- dsl connected joe user boxes. Wouldn't you think they might be up to something else? Such as using these supercomputers in an attempt to crack even larger and perhaps more .. sensitive... supercomputers or facilities elsewhere? A two steps removed compromise in other words, a "force multiplier" effort, perhaps "masked" to the ultimate target by seemingly being a benign connection from a respected place, if you follow? Or better, is there a critical tactical penetration advantage in using a zombied super computer on a big pipe that goes beyond the obvious that is already stated/speculated on in the disclosure?
Or do you (anyone who might have some more AC insider info) have any other pertinent data not covered in the articles?
Not a security guru here, but last time I remember anything like this was like around 2 years ago or so when banks were targeted, something like that anyway.
I think you'll find that ftp and pop/imap are far more frequently a problem than telnet/rsh. The stupidity of using them has been less widely publicised and it's more of a hassle and drain on resources to implement the secure equivalents.
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.
That's right. It's all the sysadmin's fault.
After all, it's our fault that the creators of a particular database removed a 'feature' from the latest version of their product, and upgrading the OS would mean upgrading the database, breaking the application. Which just so happens to be a part of the 911 service.
It's all our fault that there's no money for larger hard disks or servers so that we can physically fit a newer OS onto them. Of course it is.
It's all our fault that the owners of a particular firewall application have lost the original installation media for their application and there's no money to purchase new ones. Right... that's our fault.
It's all our fault that certain vendors insist on a 3-6 month soak period for new patches just to make absolutley sure that their application runs flawlessly.
It's all our fault that when the patches that fix these security holes break another part of a complex and intricate system that the security department who had demanded patches within 48 hours won't take responsibility.
System administrators have all the responsibility for systems, but rarely do they have the authority to make the necessary changes.
Personally, I want shore up my systems, batten down the hatches and keep the bad guys out. But I can't, I'm not allowed to. You've obviously never had to administer a large number of servers (over 600) in a complex environment, with equally complex corporate politics.
Every place that I worked at which enforced these kinds of rules, ended up with Post-It notes with passwords scattered all over the work area. Plus, the users didn't like to ask the admins for help because the "stupid IT-guys are assholes who cause more pain than they solve".
I haven't met too many users that mind getting some help picking a good initial password, but once they've picked it, they don't want to change it unless it is demonstrated that it has been stolen by someone else. Forcing people to constantly change their passwords is pure mental overhead that interferes with their jobs, and will cause them to behave in ways which will undermine your goal of security.