Archive for the ‘tipps’ Category
Seltsamerweise funktionierte die Gobi 2000 Karte meins x201 mit 2.6.36 noch, 2.6.37 nicht mehr.
Nach einigem git bisect’en ergab sich vorhin:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[1992de83e375acc789daf66b7b72a812a5235b75] USB: qcserial: Enable Diagnostics Monitor and GPS ports on Gobi 2000
Nun muss /dev/ttyUSB1 statt wie bisher /dev/ttyUSB0 genutzt werden. Aber wer liest schon dauernd die LKML oder guckt sich alle Changes vor einem Kernel-Update an? 
Achtung: die Western Digital 250 GB Raid Edition Festplatten haben bei mir im Rechenzentrum derzeit eine gefühlte Ausfallquote von 10%. Angeblich ist eine bestimmte Charge von den Ausfällen betroffen, offizielle Angaben gibt es derzeit soweit ich weiß (noch?) nicht.
Unser Lieferant erledigt Garantiefälle für uns recht unbürokratisch – wir schicken nie direkt zu WD, weil wir teils Platten im Vorabaustausch bekommen. Er hat jedenfalls eine größere Menge defekte Festplatten weitergeleitet und nun haben wir für einige Platten als Ersatz 500 GB Modelle bekommen – für lau. Man munkelt, dass aufgrund der extrem hohen Rücklaufzahlen der Bedarf an 250ern derzeit nicht gedeckt werden kann.
Es bleibt spannened. Sobald ich etwas genaueres weiß, werde ich hier was schreiben.
Edit: Falls bei euch in letzter Zeit auch viel ausgefallen ist, schreibt bitte das Alter der Festplatten dazu!
Auch immer wieder gesehen: falsche Berechtigungen von Backups.
[user@srv2342 ~]$ ls -l /opt/backup
-rw-r--r-- 1 root root 2,6M 09. Apr 20:30 etc-20100409.tgz
-rw-r--r-- 1 root root 2,6M 10. Apr 20:30 etc-20100410.tgz
-rw-r--r-- 1 root root 2,6M 11. Apr 20:30 etc-20100411.tgz
-rw-r--r-- 1 root root 2,6M 12. Apr 20:30 etc-20100412.tgz
Natürlich war auch die /etc/shadow enthalten… john macht damit bekanntlich meist kurzen Prozess.
Beliebt sind scheinbar auch Scripte, die etwas der folgenden Art machen, um Backups zu erstellen und die Rechte korrekt zu setzen:
tar -czf /opt/backup/etc-backup.tgz /etc
chmod 600 /opt/backup/etc-backup.tgz
Hier entsteht eine klassische Race-Condition. Falls der Angreifer die Platten verlangsamt (z.B. per dd) und/oder eine while true Schleife nutzt, die er kurz vor Backupbeginn startet, kann er evtl. Teile oder das gesamte Backup kopieren.
Besser: Global umask 0027 setzen. Falls nicht möglich (z.B. Firmen-Policy), einfach vor dem Aufruf von tar ausführen:
umask 0027
tar -czf /opt/backup/etc-backup.tgz /etc
Backups müssen genauso wie die Originaldaten behandelt werden und gehören nicht nach /tmp oder mit unsicheren Dateirechten sonstwohin.
Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen: id. Auch das ist unsicher, wenn man es falsch macht. Ich benutze hier einfach mal die UIDs statt der Usernamen. Der folgende Code wäre dann die id-Variante, wer findet das Sicherheitsproblem? 
#!/bin/bash
if [ "$(id -u)" != "1001" ] && [ "$(id -u)" != "1002" ]
then
echo "Zugriff verweigert."
else
echo OK
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Umgehen kann man es jedoch wieder trivial, man erstelle ~/id:
[stefan@srv2342 ~]$ sh authme.sh
Zugriff verweigert.
[stefan@srv2342 ~]$ echo "echo 1001" > ~/id
[stefan@srv2342 ~]$ chmod +x ~/id
[stefan@srv2342 ~]$ PATH=".:$PATH" sh authme.sh
OK
[stefan@srv2342 ~]$
Wir haben hier PATH so geändert, dass zuerst im aktuellen Pfad nach id Datei gesucht wird – die Datei haben wir grade angelegt und sie gibt aus, was das Script als Antwort sehen möchte. Whoops! ;D
Um die Security awareness etwas zu erhöhen, habe ich überlegt, noch ein paar witzige Schnippsel zu posten! Vielleicht entdeckt ja jemand auch etwas, das er selbst mal gemacht hat!
Hier folgt nun ein sinngemäßer Auszug aus einem Script, das bei einem ISP sehr kritische Aktionen für Domains ausführt:
#!/bin/bash
if [ "$USER" != "franz" ] && [ "$USER" != "karl" ]
then
echo "Zugriff verweigert."
else
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Wichtig ist hier vor allem das Audit Log. Umgehen kann man es jedoch trivial:
USER=franz ./domain-delete.sh [domain]
Leider bedachte der Programmierer nicht, dass $USER natürlich trivial von jedem Shelluser geändert werden kann. Das Audit-Log würde ggfs. sehr unerfreuliche Folgen haben.
Bessere Lösung: sudo benutzen und nur den zwei Usern, die es wirklich benötigen, Rechte auf das Script gewähren.
Hier eine Kurzanleitung für all diejenigen, die ein FreeBSD unter kvm mit Point-to-Point benutzen wollen und daran verzweifelt sind, ins Netz zu kommen (dies ist ein kleiner Reminder für mich selbst *g):
Lokal ist hier die IP 192.168.0.220, Remote ist 192.168.0.210.
/etc/rc.conf:
ifconfig_em0="inet 192.168.0.220 192.168.0.210"
static_routes="default"
route_default="-net 0.0.0.0 -iface -interface em0"
Ist auf der anderen Seite Linux im Einsatz, so macht man dort:
ip addr add 192.168.0.210 peer 192.168.0.220/32 dev tunX
Natürlich erst, nachdem das neue tun-Interface oben ist (also z.B. im eigenen up-Script).
Hier ein Tipp für Sysadmins, die url_rewrite in Squid nutzen: schaut euch genau an, wie performant eure Scripte sind und benchmarkt diese unbedingt!
Ich hatte die Tage ein Problem mit einem Squid, der ungewöhnlich hohe Load verursachte – es lag an ineffizienter Programmierung des Rewriters. Für eine Hand voll URLs sollte er Umleitungen vornehmen, etwa von ^http://domain/formular auf https://domain/formular.
Das ursprüngliche Script war in BASH programmiert – es verwendete externe Programme wie grep, sed – und war für geringe Bandbreiten (5MBit/s) performant genug. Die Bandbreite stieg jedoch bald auf 20MBit/s, was die Last schon sehr deutlich erhöhte, und es werden voraussichtlich bald ~200MBit/s sein.
Das Script wurde daraufhin in Perl reimplementiert und läuft laut Benchmark um den Faktor 180 (!) schneller. Als Benchmark empfiehlt sich:
[code language="shell"]time tail /var/log/squid/access_combined.log -n 100000 | awk '{print $7}' | /pfad/zum/url_rewriter.pl > /dev/null[/code]
Wenn dort (z.B. bei einem komplizierterem Script) Werte von mehr als 5 Sekunden stehen, sollte man sein Script für hohe Bandbreiten ggfs. überarbeiten und/oder in einer performanteren Sprache reimplementieren, z.B. in C oder für Extremfälle in Assembler.
Wer kennt das nicht – man braucht schnell eine ISO von Linux Distribution X oder benötigt ein Update zu Programm Y. Der einzige auffindbare Mirror ist jedoch extrem langsam oder drosselt sogar die Verbindung. wget startet für einen Download nur einen Thread und nutzt damit die Leitung häufig nicht voll aus. Eine Alternative ist das Kommandozeilenprogramm axel.
axel startet mehrere Threads gleichzeitig und kann somit den Download deutlich beschleunigen. Doch dies ist nicht die einzige Funktion von dem Programm. axel kann verschiedene Mirror gleichzeitig nutzen. Möchte man beispielsweise den Linux Kernel 2.6.28 nicht vom langsamen kernel.org Mirror herunterladen, so startet folgender Aufruf den Download der Datei vom be, nl, uk und de Mirror gleichzeitig:
[code language="css"]axel ftp://ftp.{be,nl,uk,de}.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2[/code]
axel kann aber auch selbständig nach passenden Mirrorservern für eine angegebene Datei suchen. Im folgenden Beispiel sucht axel nach der Datei linux-2.6.28.tar.bz2 auf filesearching.com und nutzt die vier schnellsten Mirror zum Download:
[code language="css"]axel -S4 ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2[/code]
Weitere Parameter erlauben u.a. die Downloadgeschwindigkeit zu beschränken sowie die Anzahl der Downloadthreads direkt anzugeben. Für alle gängigen Distributionen sollte axel über den Paketmanager installiert werden können.
Offizielle Homepage von axel
