Re: Security incident on Alioth and other Alioth news
On Wed, 06 Sep 2006, Christoph Berg wrote:
> Re: Raphael Hertzog 2006-09-06 <20060906102554.GL13426@ouaza.com>
> > 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 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
Having immediate SVN access once someone has been added is a nice
enhancement for everybody.
- 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
- 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. :-)
Premier livre français sur Debian GNU/Linux :