Für alle, dies es noch nicht mitbekommen haben: Seagate hat grade massive Probleme mit ihren Festplattenserien, die Reihen Barracuda 7200.11, Barracuda ES.2 SATA und DiamondMax 22 fallen nach wenigen Monaten total aus. Im KB #207931 ist zusammengefasst, welche Festplatten betroffen sind. Man kann dort ein Windows-Tool herunterladen und damit überprüfen, ob der eigene Rechner betroffen ist – für Linux gibt es von Seagate mal wieder nichts, es wurde daher von fähiger Hand schnell etwas entwickelt!
Download seagate-207931.sh
Das Tool kann die Daten nicht nur von direkt angeschlossenen Festplatten anzeigen, sondern auch von RAIDs, sofern ein 3Ware-Controller und tw_cli oder Adaptec mit arcconf benutzt wird. Das Praktische daran ist, dass man mit dem Script dann gleich z.B. per SSH seine ganze Serverfarm durchchecken kann und weiß, was auf einen zukommt…
Besonders tragisch finde ich, dass auch die Raid Edition 2 betroffen ist, die man ja grade für professionell eingesetzte Systeme kauft… :/
Peinlich: mit der 1,5TB-Serie gab es kürzlich auch gravierende Probleme – bei Disk flushs fror die Platte ein. Machen die überhaupt QS?!?
Bei uns steht übrigens grade die Anschaffung von ~20 Servern vor der Tür, ich weiß schon, Festplatten welches Herstellers nicht gekauft werden.
Ich wünsche allen adminlife.net Besuchern und Feed-Abonnenten ein Frohes Weihnachtsfest 2008!
mehr Christmas-Cards
Carter, Ts & Eckstein: Using Samba
The first for loop, with a link name starting with an S (S35smb), causes Samba to be started when entering runlevels 3 or 5, which are the runlevels in which network file sharing (NFS) is normally enabled.
Instructions / Anleitung:
- Grab the nearest book. / Greif Dir das nächst erreichbare Buch.
- Open it to page 56. / Schlage Seite 56 auf.
- Find the fifth sentence. / Finde den fünften Satz.
- Post the text of the sentence in your journal along with these instructions. / Veröffentliche den Text des Satzes in Deinem Blog zusammen mit dieser Anleitung.
- Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST. / Greif nicht Dein Lieblingsbuch oder ein cooles Buch oder ein intellektuelles: Nimm das, das Dir am nächsten ist.
via
Eventuell habt ihr schon davon gelesen, es wurde in diverse Red Hat und Fedora Server eingebrochen. Laut RHSA-2008-0855 hat der Angreifer seinen Zugriff genutzt, um veränderte OpenSSH Pakete zu signieren. Autsch. Laut der Meldung ist man nicht in Gefahr, wenn man das “Red Hat Network” zum Updaten seiner Pakete benutzt.
Leider gibt es keine Informationen darüber, wie die Angreifer die Server gehackt haben, wer etwas darüber weiß, möge hier bitte kommentieren!

All den hier mitlesenden Adminkollegen einen fröhlichen SysAdmin Day!
Auf dass die Server laufen, die Kunden ruhig und zufrieden sind und die Kollegen an den Ehrentag denken.
Trotz der aktuellen DNS Exploit Welle wünsche ich einen entspannenden Freitag sowie ein angenehmes Wochenende. Und nicht vergessen den Gerstensaft für das heut redlich verdiente Feierabend Bier kalt zu stellen!
P.s.: Wer noch eine kleine und günstige Aufmerksamkeit für den Administrator seines Vertrauens sucht, sollte sofort dieses PDF an den nächstgelegenen Drucker senden und mit Tesafilm in Sichtweite des Kollegen fixieren.

SSH Brute-Force Attacken sind nichts neues und gehören zum gewöhnlichen Netzrauschen. Auch gibt es bereits wirksame Methoden gegen die unerwünschten Einbruchversuche, wie z.B. fail2ban. Mit fail2ban werden häufige Anfragen einer IP erkannt und eine neue Firewall Regel für iptables erstellt, die zum Blocken der IP dient.
Eine neue Masche scheint die Nutzung von Botnetzen für die Brute-Force Attacken auf den SSH Dienst zu sein. Dadurch werden hunderte verschiedene Anfragen von ebenso vielen Hosts gestartet, die kollektiv miteinander verbunden sind. Hier versagt fail2ban. Bereits im Mai diesen Jahres wurden solche Versuche vermehrt festgestellt.
So lange der Admin und seine User sichere Passwörter nutzen und das root-Login generell verwehrt wird, haben Angriffe auf Basis von Standard Wörterbüchern auch weiterhin keine Chance. Noch sicherer ist es das Login mit Passwort komplett zu deaktivieren und nur noch die Authentifizierung via Public Key zu ermöglichen. Andere Empfehlungen raten zu dem Verstecken des SSH Dienstes auf einen ungewöhnlichen Port – Security through obscurity.
Wer sich jedoch mit dem größeren und unübersichtlichen Netzrauschen nicht abfinden will, muss wohl oder übel den Stecker ziehen oder zukünftliche Lösungsmöglichkeiten abwarten.

Nach einer missglückten MailScanner Konfiguration lief der Daemon Amok und wollte ständig seine neu startenden Kindprozesse töten. Wenigstens war die Ausgabe von htop witzig anzusehen.
Ich denke auf Kurz oder Lang werde ich um einen Wechsel zu amavisd-new nicht herumkommen, das fluppt einfach besser mit Postfix (so lautet jedenfalls der allgemeine Tenor unter Postfix Usern).