On Wed, 06 Sep 2006, Christoph Berg wrote: > Re: Raphael Hertzog 2006-09-06 <[EMAIL PROTECTED]> > > Alioth's web server was unavailable for most of the 5th of september. It was > > simply stopped because we discovered that some script kiddies were running > > an > > IRC proxy. After thorough investigation, we discovered that they exploited a > > pmwiki security hole[1] to deface some web pages, to install some malicious > > php > > pages which in turn were used to setup the IRC proxy. > [...] > > On a related matter, we're preparing the move of Alioth to a new (and > > bigger) > > machine (called wagner.debian.org), and we'll make use of that opportunity > > to > > further strengthen the security measures as well as add more security > > checks. > > In that light, wouldn't it make sense to keep svn.debian.org separate > from the highly exposed http://*.alioth.debian.org services?
It could be argued that way. We decided to merge them for various reasons: - Many groups have their website under VCS control and would like to use the commit hooks to auto-update the website - Local (read-only) access to the repository can also be interesting for some specific web applications (cf my idea of web interface for the collaborative maintenance, http://wiki.debian.org/CollaborativeMaintenance) - Even if gforge was meant to be used on multiple machines, having gforge infrastructure on multiple machines is complicated and is already causing us numerous support request because people do not pay attention to the propagation delays between the change made on the web-interface. Having immediate SVN access once someone has been added is a nice enhancement for everybody. Concerning security: - the new Alioth will be hosted in a Xen host (wagner.debian.org will be restricted to Alioth admins only, whereas alioth.debian.org will point directly to the Xen host). This means it's easy to stop (or shutdown) the Alioth host for inspection, or to simply reinstall it from scratch. That's why while preparing the new Alioth, I'm documenting the configuration of all the services. - The most common security issues come up with web applications and thus concerns mainly the www-data user. The combination with a local exploit is less frequent and requires another hole in a packaged software. - We're running famke and are thus informed within 24 hours if some security updates are waiting to be installed. - Using Xen also has the advantages that it's easier to install a new kernel, and since official Xen Debian kernels will be shipped with etch, we'll have security support for that as well. - And last point, the new host will be firewalled, and will not allow incoming connections on random ports anymore. If I'd have more time I'd look further in things like SELinux or NuFW to impose additionnal restrictions on the www-data user or apache process. But external help is always welcome. :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]