chr.istoph, der Blog

Heute war ich auf einem System bei dem sich die Updates bei SSH aufgegangen haben.

Preparing to replace openssh-client 1:5.5p1-6+squeeze4 (using .../openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb) ...
Unpacking replacement openssh-client ...
dpkg: error processing /var/cache/apt/archives/openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb (--unpack):

configured to not write apport reports
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/openssh-client_1%3a5.5p1-6+squeeze5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Da ein einfaches ls keine besonderen auffällikkeiten ergaben, musste es mit den erweiterten ext Dateisystemberechtigungen zusammen hängen. Das überprüfen ging dann folgendermaßen:
lsattr /usr/bin/ssh
-u--ia------------- /usr/bin/ssh


Die liste der einzelnen Berechtigungen findet man hier: chattr.
Für meine Fall müssen die folgenden Attribute entzogen werden:
chattr -i /usr/bin/ssh
chattr -a /usr/bin/ssh


lsattr /usr/bin/ssh
-u----------------- /usr/bin/ssh


Nach einer Neuinstallation mittels: apt-get install -f lies sich ssh ordentlich Installieren.

Quelle: howtoforge.com

Beim betreten meines Blogs mit einem neu aufgesetzten Rechners bekam ich folgende verwirrende Fehlermeldung:
Invalid OCSP signing certificate in OCSP response.
(Error code: sec_error_ocsp_invalid_signing_cert)

Dies lag nicht etwa daran das die OCSP Abfrage nicht hätte funktionieren können, sondern das das Root CA nicht für den Browser installiert war. Leider gibt das die Fehlermeldung nicht wieder welches CA da fehlt oder das eine Fehler auch ohne OCSP auftreten würde.

Auf meinen KVM Hosts habe ich mittels iptables den heartbleed bug gedropt. So bleibt genügend zeit die openssl zu updaten und die Dienste neuzustarten bzw. alle Kunden zu informieren dies zu tuhen.

#HEARTBLEED
iptables -t filter -A FORWARD -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBLEED"
iptables -t filter -A FORWARD -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Äquivalent muss man dies auch für SMTP, IMAP und co. machen.

Im syslog hat man nun die Möglichkeit alle Bods zu identifizieren die, die heartbleed Lücke derzeit aktiv ausnutzen.
Quelle: fulldisclosure

Für eine Backup einer 4TB Platte auf zwei weitere 4TB Platten haben ich mir dd mit tee zusammen gebastelt.

time dd if=/dev/sda bs=1M | pv | tee >(dd of=/dev/sdb bs=1M) | dd of=/dev/sdc bs=1M

Trotz dessen, dass die 3 Platten an einem UBS 3.0 angeschlossen waren, schafft das dd 140MB/s.
Theoretisch kann man das >(dd of=/dev/sdb bs=1M) noch für weitere Platten wiederholen, abschließend muss aber eine Pipe stehen.

Heute habe ich die Datenbank meines Blogs umgezogen. Um die Datenbank schnell über die Konsole zu kopieren haben ich folgendes gemacht. Zuerst habe ich ein dump von der wp Tabelle gemacht und dies mittels gzip komprimiert. Auf dem neuen Server habe ich dann die DB wieder ausgepackt ins Dateisystem geschrieben.

ssh root@oldserver "mysqldump -hlocalhost -uwp -pPASSWORD wp | gzip" | zcat > wp.sql

Anschließend habe ich die wp.sql im mysql Client auf der Konsole importiert.
mysql -h localhost -u root -p
Enter password: ...

mysql> use wp
Database changed
mysql> source wp.sql
Query OK, 0 rows affected (0.00 sec)
...
mysql>
mysql> quit
Bye