Bei den Barcamps Ende letzten Jahres kam immer wieder die Diskussion über No-Show-Raten bei Barcamps auf. Damit sind Personen gemeint, die sich anmelden, aber nicht erscheinen. Das erschwert die Planung – gerade was die Essensmengen angeht – natürlich erheblich. Üblicherweise wird hier ein Wert von 25-30% angesetzt.

Bei der Planung des Barcamp Stuttgart 2010 ist uns nun noch ein weiterer Faktor aufgefallen, den wir mit einbeziehen: Die Anwesenheitsquote. Denn selbst wenn am Samstag von 200 angemeldeten Teilnehmern über den Tag verteilt 150 erscheinen (25% No-Show-Rate), sind zum Frühstück und Abendessen längst noch nicht alle von denen anwesend. Beispielsweise weil die Leute später kommen oder früher gehen.

Letztes Jahr haben wir in Stuttgart mit folgenden Anwesenheitsquoten gearbeitet, die wir nach Abzug der No-Shows angesetzt haben, und sind damit gut gefahren:

Samstag Frühstück: 70%
Samstag Mittagessen: 90%
Samstag Kaffee/Kuchen: 90%
Samstag Abendessen: 90%

Sonntag Frühstück: 70%
Sonntag Mittagessen: 80%
Sonntag Kaffe/Kuchen: 70%

In der Fußzeile bzw. dem Footer vieler Websites findet sich häufig ein Copyright-Hinweis mit Name, dem Jahr in dem das Projekt umgesetzt wurde und der aktuellen Jahreszahl. Und nicht selten kommt es vor, dass die aktuelle Jahreszahl manuell festgelegt wurde und Jahr für Jahr auch wieder händisch geändert werden muss.

Bei Contao (vormals TYPOlight) lässt sich die Jahreszahl einfach mittels Inserttag {{date::Y}} in einen Artikel oder ein Modul einbinden. Dadurch entfällt das jährlich anstehende Anpassen der Footer-Zeile.

Ein Beispiel: © 2005 - {{date::Y}} Hans Mustermann

Für manche Nutzungen ist es erforderlich, auf Windows Mobile Handys die Eingabe der PIN zum Telefonieren zu deaktivieren. Das bedeutet, dass man danach ohne Eingabe einer PIN das Handy zum Telefonieren genutzt werden kann.

Dies sollte natürlich nur konfiguriert werden wenn dies wirklich notwendig ist, da es einem Missbrauch des Handys durch Dritte Tür und Tor öffnet. Wenden Sie dies also bitte nur an, wenn Sie sicher sind, dass Sie dies brauchen.

Wählen Sie dazu im Menü die “Einstellungen” und dort das “Telefon”. Unten finden Sie nun eine Reihe von Registern, darunter auch “PIN/PIN2″, welchen Sie bitte wählen. Eventuell müssen Sie dazu in den Registern etwas nach rechts blättern. In diesem Dialog (siehe Screenshot) kann dann der Haken bei PIN ist zur Benutzung des Telefons notwendig entfernt werden. Danach muss nur noch einmal die aktuelle PIN eingegeben werden um den Vorgang zu bestätigen.

In einigen Fällen erscheint nach der Eingabe der korrekten PIN dennoch eine Fehlermeldung wie im zweiten Screenshot zu sehen: “PIN/PIN2 Warnung: Ungültiges altes Kennwort. Versuchen Sie es noch einmal.” Zusätzlich werden Sie feststellen, dass in diesen Fällen der Zähler für die drei Eingabeversuche nicht zurückgesetzt wurde.

In diesem Fall unterstützt Ihre SIM-Karte diese Funktion nicht. Das kann vor allem vorkommen, wenn es sich um alte SIM-Karten handelt. Wenden Sie sich an Ihren jeweiligen Handy-Anbieter und lassen Sie sich eine neue SIM-Karte zusenden, die diese Funktion unterstützt. Je nach Vertrag können damit Kosten verbunden sein. Dies wird Ihnen aber bei der Bestellung oder auf Rückfrage mitgeteilt.

Seit einigen Tagen kursieren Gerüchte über eine mögliche Sicherheitslücke in OpenSSH in Red Hat Enterprise Linux (RHEL) und Derivaten wie CentOS. Für den Unternehmenseinsatz optimierte Linux-Distributionen halten üblicherweise an einer Software-Version fest und die Entwickler der Distribution portieren Fehlerkorrekturen und Sicherheitsaktualisierungen auf genau diese Version zurück; im Falle dieser angeblichen Sicherheitslücke müsste es sich um eine nicht korrigierte Schwachstelle in OpenSSH 4.3 handeln.

Das vermeintliche Protokoll des Angriffs zeigt einen SSH-Login auf ein aktuelles Red Hat Enterprise Linux 5.3-System über den standardmäßig von SSH verwendeten Port 22.

Auf Anfrage eines Mitarbeiters von Red Hat hat sich der OpenSSH-Entwickler Damien Miller auf der OpenSSH-Mailingliste dazu geäußert, jedoch liegen ihm keine geheimen Informationen vor, noch sieht er genügend Beweise für die Existenz einer solchen Sicherheitslücke, vielmehr geht er von einer simplen Brute-Force-Attacke aus. Auch das SANS-Institut sieht ebenfalls noch keinen Beweis für den angeblichen Zero-Day-Exploit, obwohl mittlerweile Hinweise über die Existenz der unbekannten Sicherheitslücke eingegangen sind. Ein weiterer kürzlich von SANS veröffentlichter Artikel lässt jedoch vermuten, dass es sich doch um eine simple Brute-Force-Attacke statt um eine Sicherheitslücke in OpenSSH handeln dürfte.

Als Mitwirkender beim Fedora Project habe ich mit Leuten des Fedora Sicherheitsteams gesprochen, die gleichzeitig im Red Hat Security Response Team arbeiten: Bislang wurden Red Hat keinerlei Einbrüche über eine OpenSSH-Sicherheitslücke auf Kunden-Systeme mit Red Hat Enterprise Linux gemeldet. Der Support von Red Hat steht auch im Kontakt mit den Kunden, um bei Bedarf proaktiv helfen und unterstützen zu können. Zudem konnte Red Hat bei den bislang von Kunden gemeldeten Verdachtsfällen keinen Hinweis für eine OpenSSH-Sicherheitslücke entdecken.

Zusätzlich hat sich ein Team bei Red Hat mit den Unterschieden zwischen OpenSSH 4.3 und der aktuellen Version 5.2 beschäftigt und konnte bei einer Quellcode-Analyse der beiden Versionen keine neuen bzw. korrigierten Sicherheitslücken finden.

Weiter verweist das Red Hat Security Response Team darauf, dass es vermutlich lediglich einen einzigen bekannten Angriff auf eine Webhosting-Firma gab und keine Angriffe auf größere bzw. interessantere Ziele, wie Banken oder Firmen, bei denen geheime Informationen erlangt und verwendet werden könnten. Wäre soetwas der Fall gewesen, hätte Red Hat darüber bereits Kenntnis erlangt und Administratoren würden diese Probleme auf Security-Mailinglisten wie Vendor-Sec oder bei diversen CERTs melden und beschreiben.

Scheinbar plant Red Hat in der nächsten Zeit eine offizielle Stellungnahme zu abzugeben, da trotz diverser investierter Ressourcen und Zeit keinerlei Anhaltspunkte für eine OpenSSH-Sicherheitslücke entdeckt werden konnten. Sollten widererwartend doch mehr Informationen und vor allem technische Details bekannt werden, wird Red Hat entsprechend reagieren. Laut Hinweisen die das SANS-Institut erhalten hat, sollen die Details zur Lücke auf der Ende Juli in Las Vegas stattfindenden Black-Hat-Sicherheitskonferenz öffentlich gemacht werden…

Edit am 1.6.2010: Toter Link zum Protokoll gelöscht.

Wie ihr mitbekommen habt, ist inzwischen die Organisation für das Barcamp Stuttgart 2009 angelaufen. In diesem Zusammenhang habe ich ein paar Punkte zusammengestellt, die helfen ein Barcamp zu organisieren. Es würde mich freuen, wenn dieses Howto euch bei der Organisation eures Barcamps oder Themencamps hilft. Die Liste erhebt keinen Anspruch auf Vollständigkeit. Ihr dürft also gerne in den Kommentaren ergänzen. weiter lesen »