We would need more information before any specific advice could be given. Though this might be a good place to start: openSUSE 12.2: Security Guide
The best advice I can give is do not run software you do not trust. Also keep an eye on any network facing services. You might be interested in this approach to security, it is what I keep in mind when I am configuring security: https://en.wikipedia.org/wiki/Principle_of_least_privilege
I’m not saying it will never happen, but I’d have rather seen some comments from a linux kernel developper than another somebody from Kaspersky Labs. I still remember their message about a working linux virus: to be downloaded first, to be installed as root, started as root, ineffective at next boot.
Perfect security doesn’t exist. On a linux machine with defaults installed, you’re pretty secure.
> What sort of risks are involved in this linux rootkit attack? How can
> I protect my opensuse install?
Good to know about this threat. Thanks for posting the link. If you look
at the links contained within the article, you will find that the threat
is to a specific version of debian, via a corrupt kernel module.
So the answer to your question is that you don’t need to do anything to
protect your openSUSE.
In general though, only download software from sources that you trust!
Hmmm. I’d already read the ‘Crowd Strike’ post, and
- this looks like an early stage in a rootkit development; if whoever did this didn’t just do this for fun, it would be reasonable to expect a more sophisticated version to come out at some time
- it seems that some of the programming is, at least, clumsy; maybe a later version cleans that up, maybe it doesn’t
- it is significant that this is new and not a variant of some existing rootkit; it probably wouldn’t show that evidence of clumsy programming if it were a derivative, but, potentially, it is something completely new to worry about
The current version is coded around a specific kernel version; in general, this would be a fairly odd restriction to have in place. It would have to have been coded by someone with very little knowledge indeed if they didn’t know that requiring this specific kernel version would severely restrict the threat value of this piece of malware (you’d have to wonder if someone with that little knowledge could achieve this!) or maybe they have a very specific target (just to come up with a random example, they could be at a college where this kernel version is very common in machines that they would like to exploit).
Possibly they have a plan, possibly it was always intended to be some kind of ‘proof of concept’ just out of intellectual curiosity. Possibly, it was never really intended that this should escape in this form, but this is a development version that has escaped accidentally.
Today, it seems as if this thing is little more than a curiosity to most of us, but that isn’t to say that it couldn’t be developed in to something really worrying. Another reason to follow good security practises!
> Hmmm. I’d already read the ‘Crowd Strike’ post, and
> - this looks like an early stage in a rootkit development; if whoever
> did this didn’t just do this for fun, it would be reasonable to expect
> a more sophisticated version to come out at some time
> - it seems that some of the programming is, at least, clumsy; maybe a
> later version cleans that up, maybe it doesn’t
> - it is significant that this is new and not a variant of some
> existing rootkit; it probably wouldn’t show that evidence of clumsy
> programming if it were a derivative, but, potentially, it is something
> completely new to worry about
I don’t see what there is new to worry about.
If you install somebody’s corrupt kernel module on your machine, you are
owned. The details of what it does once it’s been installed are pretty
much irrelevant. And we haven’t been told anything at all about how the
kernel module was installed, AFAIK. So there’s nothing new to worry
about. If it turns out to have some new means to be installed, then we
need to worry.
Sure the rootkit detectors need upgrading to find it (at least one of
the links said they already had) and sure either the original author or
somebody else could improve its details, but the point is that what
matters about an exploit is how it is installed, not what it does.