chr.istoph, der Blog

Da aktuell nur für Debian 9 stretch, für den Meltdown Bug, ein Kernel Update verfügbar ist. Habe ich für die folgenden Versionen ebenfalls einen Kernel nach vorlagen der jeweils letzten Kernelconfig gebaut:

Squeeze
linux-image-4.14.12_1-squeeze_amd64.deb

Wer noch nichts von Meltdown und co mitbekommen hat sollte hier einmal weiter lesen:
meltdownattack.com
access.redhat.com cve-2017-5754

[UPDATE]
Die Updates für Debian und Ubuntu sind endlich veröffentlicht worden. Deshalb habe ich die Versionen für Jessie und Wheezey in diesem Artikel entfernt. Sie sollten nun wieder auf den Distro Kernel wechseln. Für Debian 6 ist noch kein Kernel Update angekündigt, daher bleibt dieser Antiekel hierfür noch bestehen.

Man kann ja zum Glück sagen das Citrix auch unter Linux läuft, aber wenn dies die einzige Art ist um mit einem Netzwerk zu kommunizieren. Muss man sich andere Hintertüren bauen um Daten ins/aus einem Netzwerk zu bekommen.

In meinem Fall wollte ich eine 1MB großes RPM kopieren. Auf meinem Linux rechner habe ich zunächst das Programm xclip installiert, welches dafür sorgt das Texte in die Zwischenablage geladen werden können.

apt install xclip

Dann habe ich die Datei komplett, als base64 kodirte Daten, in die Zeichenablage geladen:

cat Downloads/nginx-1.12.0-1.el7.ngx.x86_64.rpm | base64 | xclip -selection clipboard

Zu dem habe ich natürlich die md5 Summe zur Intigritäts- Prüfung erzeugt.
md5sum Downloads/nginx-1.12.0-1.el7.ngx.x86_64.rpm
6ecea65dc0ed707df767e26d0825b00b Downloads/nginx-1.12.0-1.el7.ngx.x86_64.rpm

Dann habe ich die Base64 Codirte Daten in einem Citrix Terminal gepostet:

cat | base64 -d > nginx-1.12.0-1.el7.ngx.x86_64.rpm
....

Mit STRG + d kann man das schreiben in die Datei beenden. Anschließend noch einmal mit md5sum den gegen Test mach und schon ist die Datei auf der anderen Seite.

Da Stiftung Warentest aktuell die erneuten Tests für E-Mail Server heraus gibt, habe ich mir mal die Mühe gemacht, die Transport Verschlüsselung auf unseren E-Mail Servern herauszufiltern um diese nach Ihrer ciphers zu untersuchen. Spannend war, dass mittlerweile alle eingehenden Verbindungen eine Recht hohe Sicherheit aufwiesen. Microsofts hotmail.com outlook.com so wie Mail.de waren die einzigsten, die noch ein CBS Mode verwenden. Alle anderen sind schon auf den neuen GCM Mode umgestiegen. Bei web.de, mail.de und mailbox.org haben anscheinend unersichtliche Server Infrastruktur die mit unterschiedlichen ciphers E-Mails Ausliefern.

google.com
ECDHE-RSA-AES128-GCM-SHA256

posteo.de
ECDHE-RSA-AES256-GCM-SHA384

Die Resultate habe ich unter 100.000 E-Mailserver-Verbindungen der letzten Woche herauszufiltern. Sortiert sind die aufrufe nach Anzahl der Verbindungen wobei die Anzahl der letzten 3 Anbieter < 1% liegt.

Ich habe im August 2014 bereits eine Lösung mit iptables und fail2ban geschrieben. Da diese aber zu viele „fals positiv“ produziert hat, habe ich mich noch einmal hingesetzt und eine sowohl auf Performance als auch ohne fail2ban optimierte Lösung gesucht.

Mein zweiter Ansatz geht so vor, dass zuerst alle post requests in eine eigene iptbatles chain gepackt werden. Anschließen werden die in der chain noch übrig bleibenden anfragen nach den Schlüsselwörtern wie wp-login.php oder xmlrpc.php untersucht und mit einem Counter von 3 versehen. Beim dritten versuch ein falsches Passwort anzugeben werden die IPs der Botts für 600sec gesperrt.

iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "POST " -j HTTPPOST

iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-auth"
iptables -A HTTPPOST -m string --algo bm --string "/wp-login.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-auth" -j DROP

iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --set --name "wp-xmlrpc"
iptables -A HTTPPOST -m string --algo bm --string "/xmlrpc.php" -m state --state NEW,ESTABLISHED -m recent --update --seconds 600 --hitcount 3 --name "wp-xmlrpc" -j DROP

iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT -m comment --comment "HTTP"

UPDATE: Danke an Jens, die SSL Regeln für Port 443 können so natürlich nicht funktionieren und wurden entfernt.

Um mitzubekommen welche Kable bzw. welche Portds am cisco Switch aktiviert werden leiten wir die Evends an einen Remote Server weiter.

An diesen haben wir lediglich in der /etc/rsyslog.conf das udp Modul aktiviert.
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
In der firewall den Port 514 geöffnet und den Dinst neugestartet.
/etc/init.d/rsyslog restart

Auf dem cisco switch habe ich dann den Server angegeben an den die Login daten gesendet werden sollen.
c6506(config)#logging 10.0.0.2

Und die Interfaces mitgeteilt das auf diesen mitgeloogt werden soll.
c6506(config-if-range)#interface range Gi1/1-48
c6506(config-if-range)#logging event link-status

In /var/log/syslog sieht das dann so aus:
%LINK-3-UPDOWN: Interface GigabitEthernet1/48, changed state to down
%LINEPROTO-SP-5-UPDOWN: Line protocol on Interface GigabitEthernet1/48, changed state to down