Zugschlusbeobachtungen

In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.

Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.

In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.

Schon bei den Vorarbeiten zu diesem und diesem Artikel hat man mir sehr nahegelegt, suphp anzugucken. Das habe ich heute getan.

Auf der Nesus-Mailingliste fand ich heute eine Mail, deren Autor sich darüber wundert, dass
Nessus bei einem Self-Signed Certificate keine Warnung wirft.

Schließlich ist das eine schlechte Security-Maßnahme weil auf diese Weise Man-in-the-Middle-Attacken möglich werden. Das sei insbesondere im kommerziellen Umfeld ein Problem.

Nun, meine Meinung dazu ist, dass es sicherer sein kann, ein selbstsigniertes Zertifikat selbst zu verifizieren als sich blind auf die durchaus durchwachsenen Prozesse einer kommerziellen CA zu verlassen.

Ach ja, die oben zitierte Mail kam von einem Verisign-Mitarbeiter.

In Fortsetzung von suexec my php, baby^wapache habe ich gestern suexec auf dem ersten Produktivsystem verfügbar gemacht, und einige Unzulänglichkeiten im Debian-Setup gefunden.

Von einem der auszog, seine PHP-Scripts nicht mehr als www-data laufen zu sehen.

Auf der Suche nach einer Lösung für ein Standardproblem

20% [1 Packages 24266/117kB 20%]                                    1689B/s 54s

That's actually worse than it was with the old box.

Today, over the day, access to security.debian.org was intermittent as usual in the last few weeks. But this afternoon, things suddenly got much worse. All my cron-apt installations on and behind firewalls began to yell at me that securiy.debian.org was completely unreachable.

But. Wait. I don't know that IP address. I don't know the host name tartini.debian.org.

Once again, the solution was found in Joey's Blog. Apparently, security.debian.org was moved to the new host, and everything is fine.

Nearly everything.

UPDATE: There has been an Announcement, but not where I would have expected it. The IP address hasn't been mentioned there, though, and that announcement wasn't signed.

UPDATE: There has been one more change to the IP addresses of security.debian.org: It now seems to be round-robin DNS of three hosts. While this is now a real advance compared to the old situation, it has - again - been unannounced to the public. And I get a free trip around my firewalls for the second time in 24 hours. Thanks, guys - I'd surely be twiddling my thumbs otherwise.

After taking over aide co-maintainership in January and successfully convincing Mike to put the project on alioth, I have done some work on aide and have uploaded 0.10-8 on September 18 and 0.10-9 on September 27 to experimental.

These two versions acknowledge the two NMUs we recently had and fix some issues that I thought would be worth fixing. Please test. I plan on uploading to unstable on a week, if no bad goofs surface during the experimental phase.

Unfortunately, aide's upstream is quite dead, so it is unlikely that any upstream bugs will get fixed without you submitting patches.

Next step will be convincing Mike to allow creation of a pkg-aide-maintainers mailing list for the Maintainer:-Field, so that messages sent to the maintainer field instead of aide@packages.debian.org can reach me as well.

The recently released security update of Xfree86 for sarge has made something happen what I have been fearing for years: Gazillions of systems downloading the update have slashdotted security.debian.org, which is now sluggishly responding for the second day in a row.

This doesn't make my cron-apts happy, which in turn bury me under error message e-mails. Ungood, since one might miss an important update in the avalanche of "cannot pull packages.gz from security.debian.org" mails.

This experience has shown that having security.debian.org a single point of failure is not as good of an idea as we thought. I am afraid that the security team will have to reconsider and to finally establish mirrors for security.debian.org to spread the load.

Update: After reading much of the discussion about the topic, I find it strange that nobody besides me blogged about the issue, but we actually have an official announcement about the sdo outage. Very good.

Establishing a mirror network for sdo is not quite easy since unlike for the main archive, we cannot use "randomly offered" mirroring services, but we need the sdo mirrors under our control. Main reason for this is that we need sdo mirrors to be fast, because people would begin to complain that an update has not yet hit the mirrors after the advisory has gone out. Already today, it frequently happens that the cron-apt processes have detected an update quite some time before the release of the actual advisory, and you don't want the process to take even longer. Even push mirroring is way too slow.

I like the idea of not establishing mirrors, but caching proxies distributed around the world, so that the issue of a mirror pulse simply vanishes: The proxy would fetch the update on the first incoming request, and deliver from its local cache for some time before looking on the actual sdo server again whether the file is still current. Neat idea.

Marcus Ranum schreibt über die sechs dümmsten Ideen im Berich der Computersicherheit (The six dumbest ideas in Computer Security.)

Wenn ich ihm auch nicht in allen seinen Thesen vorbehaltlos zustimmen kann, lesenswert ist der Artikel allemal.

Gefunden: fast überall.

Looks like there is no passwd-compatible crypt(1) for the command line. htpasswd, unfortunately, uses a different algorithm.

This short perl script might be a replacement:

#!/usr/bin/perl -w

use strict;

while(<>) {
    my $seed = `apg -a 1 -m 8`;
    chomp;
    print crypt(&#8220;$_&#8221;, &#8220;\\$1\\$$seed&#8221;). &#8220;\\n&#8221;;
}

Or do we have something better already in the distribution?

Update: looks like mkpasswd (from the whois package, whatever makes it belong in there) does the job quite nicely, but the script shown above takes care of automatic salt creation as well. Any ideas how to do that more elegantly, without requireing apg?

merlix berichtet darüber, wie sich ein Dieb als telefonierendes Anhängsel eines Hardwaretechnikers in eine Firma eingeschlichen hat und - zum Glück "nur" - Portemonnaies und Wertgegenstände eingesammelt hat. Man möchte gar nicht wissen, was für ein Schaden hätte entstehen können, wenn der Eindringling nach den Geschäftsgeheimnissen des Unternehmens aus gewesen wäre.

Ich persönlich finde es zwar superlästig, erstmal am Empfang seitenlang Formulare mit persönlichen Angaben ausfüllen zu müssen, um dann meinen Ausweis gegen einen offen zu tragenden Hausausweis eintauschen zu dürfen und den ganzen Tag als "Auswärtiger" gebrandmarkt herumzulaufen, kann aber immer mehr verstehen, dass Unternehmen ab einer gewissen Größe gerne kontrollieren wollen, wer sich auf dem Gelände bewegt.

Um so mehr verwundert es mich, dass manche, auch gerade große Firmen, solche Verfahren zwar in den Ansätzen realisiert haben, aber in die Prozesse Sicherheitslücken eingebaut haben, durch die man mit einem ganzen Möbelwagen durchfahren könnte. Nicht selten erlebt man Verfahren, die die Nachteile genauer Zugangskontrolle ("lästig") mit den Nachteilen nicht stattfindender Zugangskontrolle ("wir wissen weder, ob der Besucher wirklich dort war wo er behauptete hinzuwollen, noch ob er schon wieder gegangen ist") verbindet.

In Deutschland scheint es diesbezüglich besonders hohen Beratungsbedarf zu geben. Ob man diesbezügliche Bratungsleistungen in den Rundum-Sorglos-Securityservice mit aufnehmen sollte?

Überall wo man hinkommt (auch dort, wo man eigentlich nicht hin will) sind die Computerbild lesenden "Profis" mit ihren voll krass konkreten persönlichen Feuerwänden schon da. Und unsereins steht da wie der Ochs vorm Berg, will keine Verantwortung tragen und steht im Bekanntenkreis als nicht hilfsbereiter <zensiert> dar.

Ähnlichkeiten mit in den letzten Tagen real besuchten Personen sind rein zufällig und nicht beabsichtigt.

Wir haben derzeit mal wieder eine Schwachstelle in der zlib, und wieder geht die Suche nach statischen zlibs in den Archiven freier Software los. Florian Weimer hat einen automatischen Prozess zum Suchen der zlib entwickelt.

Die Welle an Hiobsbotschaften über Debian reisst nicht ab. Nachdem wir ein halbes Jahr auf die Security-Infrastruktur gewartet haben, ist sie mit dem Release kaputt gegangen, und die dafür zuständigen Leute lassen das Security-Team in der Luft hängen. Joey, das derzeit einzige aktive Mitglied des Security Teams, hat darüber geblogged.

Persönlich beginne ich nicht mehr daran zu glauben, dass die Jungs an der Macht nur gedankenlos sind.