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 booten eines Servers standen die Logical Volume nicht zur Verfügung. Beim Aufrufen von lvs kam folgende fehlermeldung die einen hinwies auf die volle Platte gab.
# lvs
No volume groups found
/etc/lvm/cache/.cache.tmp: write error failed: Auf dem Gerät ist kein Speicherplatz mehr verfügbar


# ls /etc/lvm/cache/.
./ ../ .cache .cache.tmp


Nach dem aufräumen des Root-Filesystems muss man erst das pv nach vgs durchsuchen.
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg1" using metadata type lvm2


# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv1 vg1 -wi--- 100,00g


Anschließend musste man das vg aber noch starten.
# vgchange -a y vg1
7 logical volume(s) in volume group "vg1" now active


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