Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
High ProfileHigh ProfilePosted Nov 17, 2004 20:33 UTC (Wed) by madscientist (subscriber, #16861)In reply to: High Profile by elanthis Parent article: freedesktop.org site compromised
> We've fairly recently seen Debian.org, GNOME.org, Savannah.GNU.org, and now FreeDesktop.org security breaches.
I'm not familiar with the details of gnome.org or fd.org, but the big problem with both Debian and Savannah is that they allow remote login to any registered user. It's one thing to secure a system against remote attacks, but it's an astronomically more difficult thing to secure a system which is intended to let a wide range of users remotely log in.
(Log in to post comments)
High Profile Posted Nov 17, 2004 21:43 UTC (Wed) by thomask (guest, #17985) [Link] Hmm. Security in online collaboration could become the achilles heel of the OSS community if we don't work hard enough to secure our systems.
High Profile Posted Nov 17, 2004 21:50 UTC (Wed) by madscientist (subscriber, #16861) [Link] > Security in online collaboration could become the achilles heel of the OSS community if we don't work hard enough to secure our systems.
There's no particular reason that online collaboration environments _HAVE_ to allow remote login; indeed, Savannah has since removed that capability IIRC. Debian has a much more difficult problem to solve but with sufficient automation it could still be done.
The reality is there are always jerks out there and little you can do about it. Similarly, there are always bugs and not much you can do about that. The best we can hope for is to implement enough features like chroot jails and selinux etc. to make the jerks' lives difficult.
High Profile Posted Nov 17, 2004 23:35 UTC (Wed) by Ross (subscriber, #4065) [Link] Short of removing access completely you can do a few things to improve thesituation. These are common knowledge but I'll repeat them anyway :)
* make any suid or sgid program which doesn't absolutely need to be that
You missed some critical steps Posted Nov 18, 2004 3:20 UTC (Thu) by ringerc (guest, #3071) [Link] Another really important one is to deny users the option to use passwords as their only form of authentication for a service. If you must have a password on their account (instead of an invalid hash, so login is impossible), do not permit it to be used for shell logins and don't let anything that takes the password be accessed except by the local hot. Run _everything_ over ssh, and require users to supply an ssh public key during account setup.
If the sshd is trojaned by a local attacker who got in with a password stolen from a less secure system (Apache/SourceForge compromise), they can't steal logins to attack other hosts. Remember, many people use the same usernames/passwords for many sites, and there's little you can do to prevent this. This improves your users' security. It's also considerably harder to steal an ssh key than a password, so it helps your security too.
Next, if at all possible deny local logins. Use ssh to set up port forwards or run automatic commands (like '/usr/bin/cvs server'), but never give users a shell. Unfortunately, this may require the users to manage multiple keys. If you absolutely must give them a shell, if at all possible give them a very restricted shell that can only run a couple of commands. I'm talking not even `ls'. If at all possible, chroot it.
A similar approach can be configured for things like authenticated https. Generate client certificates for the user, and require them before authentication is attempted. This makes brute-force attacks very hard, and means that a stolen password is no good without the attacker also successfully stealing the client certificate from the same person. Passwords compromised as a result of someone using the same username/password with an insecure protocol do the attacker no good at all.
There's also some obvious stuff - run as few services as root as possible, use chroot like there's no tomorrow, run as few services _at_ _all_ as possible, etc.
Just because your server is a public host doesn't mean it shouldn't have a firewall. Lock it down.
SELinux may be a right pain, but perhaps it's less painful in the long run than a compromise? (Frankly, I'm not convinced. It's _really_ painful.)
Finally: Be utterly, foaming paranoid. If you're running a public service, there's no such thing as a trustworthy user. Work as if all of them are actively trying to get you cracked.
I don't know what happened to fd.o or if any of these steps would help them. Sometimes there's just nothing you can do, such as when a major hole is discovered in a daemon you have no choice but to run as root and it's exploited before it becomes public. Still, these steps may well help.
You missed some critical steps Posted Nov 18, 2004 3:43 UTC (Thu) by walters (subscriber, #7396) [Link] SELinux may be a right pain, but perhaps it's less painful in the long run than a compromise? (Frankly, I'm not convinced. It's _really_ painful.) Have you tried Fedora Core 3? I think that its strict policy has made a huge amount of advancement in the last 6 months since FC2. Not to mention that with the targeted default policy, many FC3 users are probably unaware (unless they read the release notes) that daemons like syslog and portmap are transparently protected.
High Profile Posted Nov 18, 2004 3:42 UTC (Thu) by jtc (guest, #6246) [Link] "The reality is there are always jerks out there and little you can do about it. Similarly, there are always bugs and not much you can do about that."
I disagree with the second sentence. While it's usually not possible to produce a system with no bugs, there are a lot of actions that can be taken to develop a system with fewer bugs (often much fewer) than would otherwise occur. Most or all of these actions fall under the category of good software engineering procedures, practices, and techniques. It's not always practical to follow such procedures completely, but I suspect that the ROI for many OSS projects would be significantly higher - less money spent on bug fixing and related maintenance and less money lost to security problems - if a solid subset of these procedures were put in place.
|
|||||||||||