chr.istoph, der Blog

UPDATE: es liegt eine Aktualisierte lösung für diese Problem vor

Aktuell finden heftige Angriffe auf WordPress Accounts statt. Die schnellste und einfachste Möglichkeit dies zu unterbinden, ist das Droppen aller Aufrufe der wp-login.php mittels iptables:

iptables -I INPUT -i eth0 -p tcp -m tcp --dport 80 -m string --algo bm --string "/wp-login.php" -j DROP

[Update] Besser:

iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-auth"
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 240 --hitcount 10 --name "wp-auth" -j DROP

Alternativ kann man auf fail2ban eine Regel mitgeben um beispielsweise folgende Logeinträge zu filtern:

10.0.0.1 - - [15/Aug/2014:09:07:39 +0200] "POST https://blog.chr.istoph.de/wp-login.php/wp-login.php/ HTTP/1.1" 200 3552 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2"
10.0.0.1 - - [15/Aug/2014:09:08:28 +0200] "POST /blog/wp-login.php HTTP/1.1" 200 2653 "https://blog.chr.istoph.de/blog/wp-login.php" "[% tools.ua.random() %]"

/etc/fail2ban/filter.d/wp-auth.conf

# WordPress brute force auth filter
[Definition]
failregex = ^< HOST > .* "POST*/wp-login.php*
ignoreregex =

/etc/fail2ban/jail.local

[wp-auth]
enabled = true
filter = wp-auth
action = iptables-multiport[name=NoAuthFailures, port="http,https"]
logpath = /var/www/vhosts/*/statistics/logs/access_log
bantime = 1200
maxretry = 3

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

Beim einrichten eines Servers unter 14.04 ist mir folgendes aufgefallen:
SSLCACertificateFile: file ‚/usr/share/ca-certificates/cacert.org/cacert.org.crt‘ does not exist or is empty

Darauf hin schaute ich mir die changelog vom ca-certificates an und war überrascht das cacert.org nicht mehr vertraut wird:
zless /usr/share/doc/ca-certificates/changelog.gz
ca-certificates (20130906ubuntu2) trusty; urgency=medium

-- Marc Deslauriers Wed, 19 Feb 2014 15:57:25 -0500

Daraufhin schaute ich mir den Bugreport genauer an:
Ubuntu ist eine der wenigen Distributionen die CAcert als vertrauenswürdiges Zertifikat anerkennen. Viele Distributionen erwägen [1], CAcert zu entfernen. Mozilla schloss die im Jahr 2003 eröffnete RFE [2] für CAcert im Jahr 2008.

Auf der Debian Mailingliste [3] wurden einige Bedenken bezüglich der Codequalität von CAcert ausgedrückt. Deswegen wurde die Prüfung angehalten.

In der Vergangenheit hat Ubuntu bereits CAcert deaktiviert [4], dies ist nun wieder der Fall. Es ist besser dies wieder zu tun.

Ubuntu is one of the few distributions shipping CAcert as a trusted certificate. Many distributions are considering[1] whether to remove CAcert, and Mozilla closed the RFE[2] for CAcert in 2008, which was opened in 2003.

Concerns were expressed about CAcert’s code quality[3], and their audit appears to be stalled.

In the past, it appears that Ubuntu disabled[4] CAcert, but this is no longer the case. It may be wise to do so again.

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#50
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=215243
[3]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#45
[4]: http://wiki.cacert.org/InclusionStatus?highlight=Ubuntu

Quelle: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1258286

Abhilfe schafft folgendes, dennoch müssen dann die Fingersprints selbst überprüft werden.
wget -O cacert.org.crt http://www.cacert.org/certs/root.crt
wget -O - http://www.cacert.org/certs/class3.crt >> cacert.org.crt

[UPDATE]
Mittlerweile sind auch die andere releases betroffen wie Ubuntu 12.04:
zless /usr/share/doc/ca-certificates/changelog.gz
ca-certificates (20130906ubuntu0.12.04.1) precise-security; urgency=medium

-- Marc Deslauriers Thu, 06 Feb 2014 17:39:43 -0500


Linux Unified Key Setup (LUKS) ist das Standardtool unter Ubuntu für eine Festplatten Vollverschlüsselung. Das noch unter 12.04 verwendete Standartverfahren war CBC das laut Jakob Lell seit dem 22.12.2013 als angreifbar gilt.

Wie aber Überprüft man ob die verwendete crypto betroffen ist und wie sollte es nicht aus sehen:
sudo cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2

Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256


Quelle: heise.de/security