Novell OpenSUSE Server Hacked

abelikoff writes "Both LinuxWorld Australia and SuSE Linux Forums report that OpenSUSE website got hacked last night." This story was submitted quite a number of times.

Comments

ssh scan

[perp]

This server probably had a weak root password and was hacked by one of the several automated ssh bruteforcers out there http://www.linux.com/article.pl?sid=05/09/15/16552 34

I see these attacks all the time on all Internet facing servers.

Re:ssh scan

[jaclu]

I have a hard time to see the gain in security by disalowing root but allowing users to login and then sudo.

In the case of three admins, you would end up with three accounts that could be exploited, rather increasing if anything the risk of direct ssh exploits.

Once the bad guy is in, he has all the local exploit possibilities to gain root, so your already in trouble if they get in.

So as long as you do ssh with passwords, disalowing root-login dosent really buy you any security, but it hassels the admins each and every day.

On the other hand, prefered method would be to login with keys and disallow passwords completely whenever possible.

Re:ssh scan

[Gogo0]

Part of the security comes from non-root logins being unknown.

One could try to use a non-root user to bruteforce their way into my system, but they'll either get one (probably created by an application) with /dev/null as a shell or they will be trying usernames that dont exist.

Re:ssh scan

[despisethesun]

I have a hard time to see the gain in security by disalowing root but allowing users to login and then sudo.

You must not have much experience with sudo. One of the benefits of it is that it allows you to give root permission to people for specific tasks that they would need that access level for. While there are certainly a lot of people who set their sudoers file to "allow all" for everyone, if sudo is properly implemented no one should be able to do anything they don't NEED to do as root. Sudo also has the benefit of keeping track of what users used it to do what tasks, making it easier to trace the path an attack came from.

Gogo0 also mentioned an added benefit to this scheme so I'm not going to repeat it here.

different hacks, different times

[sjvn]

The LinuxWorld Australia story is actually about an earlier break-in of a Novell system that was being used for World of Warcraft related stuff, not the OpenSUSE site at all.

Steven

OpenSUSE website Hacked? No.

[blanks]

The open SuSE website wasnt hacked, it was a damn gamming machine they had on their network.

From TFA:

"The employees that set it up apparently had no idea of security," Brandon said. "But what is really surprising is that Novell would allow employees to set up game servers on their corporate network and then allow the public to access it."

"There was no major breach of security here," Barney said. "Needless to say, we are taking the appropriate steps" to address the situation.

They have a website

[gcnaddict]

the hacker team has a website to add to that, its likely being hosted in iran so no one can do jack shit

Re:Don't blame LINUX

[grub]

Which part actually got hacked, the OS or the webserver itself??

Only those Iranians and the SUSE people know :) Regardless, running something like OpenBSD with its hardened & chroot'd apache could mitigate a lot of the damage. ie.: make most files read only to the httpd process, etc etc.

Re:Practical upshot? Am I safe?

[houghi]

I'm running SuSe 9.3, and this morning, I let the automated update program do it's thing. Did I download and install any breached files?

No. It was just the WiKi server that went down.

Re:OpenSUSE website Hacked? No.

[gregorio]

The open SuSE website wasnt hacked, it was a damn gamming machine they had on their network.

From TFA:

Click the "hacked" link in the submitter's text.

How secure by default?

[starfishsystems]

Isn't this [poor administration] the same flaw Windows has?

It's a reasonable question to ask.

Yes, fundamentally it's true that configuration management has a significant effect on security. To be precise, this is not a flaw, but a characteristic. A site which is in full control of system configuration will have formal security advantages over one which isn't, and this is universally true regardless of platform.

However, the story is told from a much different perspective when it comes to evaluating the security of a given platform. Configuration remains a major factor in security, but it has to be weighed in light of platform capability. So, for example, a very simple network appliance with a very small configuration space has the prospect of being very secure. An ideal appliance cannot be configured insecurely. In practice, that may or not be the case, depending as always on design tradeoffs and correctness of implementation.

Apart from pure appliances, all computing platforms must, for reasons of generality, offer configuration possibilities that put some security tradeoffs in the hands of site administrators. Such is the case for both Linux and Windows, so indeed poor administration can always result in poor security on a sufficiently general platform.

The practical focus, therefore, has turned to how securely these platforms are configured by default. Interestingly, even though Windows is marketed for nonexpert use, it has a long tradition of being configured insecure by default, exactly the opposite of what would be appropriate for a nonexpert market. It also, in my opinion, embodies a lot of fundamentally insecure design tradeoffs, neglecting principles such as modularity, containment, and least privilege, for example. These are extremely deep design problems, not easily fixed.

Linux and Unix, although designed by developers for developers, and therefore intended for expert use, have a record of delivering much better security by default. I can think of lots of particular exceptions, but they have tended to be minor design tradeoffs that could be, and were, easily corrected. Security incident statistics seem to reinforce these observations very strongly.

In my line of work, I get to see what goes on behind the scenes at a lot of sites. It's not often that I come upon a site which is not suffering to some significant degree from a chronic neglect of configuration management. All discussion of platform characteristics aside, this is a real problem on the ground for security.

The issue, in terms of value for effort, then becomes to identify which of these sites is (a) at most immediate risk, and (b) has the best potential of improvement. In the former case, I find that the answer is Windows, and in the latter, it's Linux.