IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: IT-Security (Seite 11 von 15)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Google Browser Chrome wirft SHA1 Zertifikate weg…

Veraltet: SHA-1 in TLS-Zertifikaten ist seit Januar 2017 von allen großen Browsern abgelehnt. Dieser Beitrag ist ein Zeitdokument aus 2014, als Google den Ausstieg ankündigte.

Dass SHA-1 nicht der Brüller ist, wissen wir inzwischen alle. Dass man nicht so lange warten sollte wie bei MD5, bis es nicht nur ein theoretisches, sondern ein echtes Problem gibt, können sich viele denken. Leider bekommt man viele Entscheider nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Softwaremodule müssen getauscht werden, Hardware könnte ersetzt werden müssen. Windows XP wird so zum Beispiel abgehängt.

Googles Ankündigung

Google hat angekündigt, SHA-1 aus Chrome zu entfernen. Nutzt man Zertifikate mit SHA-1-Checksumme, gibt es eine Meldung im Browser: „Diese Seite ist nicht ganz sicher.“ Danach folgt eine deutliche rote Warnung, bis hin zum Punkt, dass solche Zertifikate nicht mehr unterstützt werden. Zeitplan damals: ab ca. 2017. Bei einer durchschnittlichen Gültigkeitsdauer von zwei Jahren für Kaufzertifikate konnte man zum letzten Mal mit gutem Gewissen am 31.12.2014 ein SHA-1-Zertifikat kaufen.

Was mir an Google damals gefiel: Sie haben sanften Druck auf die Entscheider ausgeübt, um mehr Sicherheit ins Internet zu bringen. SHA-1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern. Genau wie RC4 oder MD5. Kein Anwender prüft das von sich aus. Aber wenn die Software anfängt zu meckern, gibt es schnell Bewegung bei den Entscheidern und den „Weiter, weiter, fertigstellen“-Admins. Microsoft und Mozilla hatten sehr ähnliche Pläne.

Die CAs reagieren

Kurz nach der Ankündigung kamen die ersten E-Mails von den großen CAs. Hier die von Symantec:

Wichtiger Servicehinweis

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die
Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1
einzustellen. Das wird voraussichtlich ab Chrome 39 im November 2014
geschehen.

Symantec empfiehlt:
1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer
   Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015
   ablaufen, kostenlos durch Zertifikate mit SHA-2.

Hinweis: Root-Zertifikate mit SHA-1 sind nicht betroffen.

Ihr Support-Team von Symantec Website Security Solutions

Wie es ausgegangen ist

Im Januar 2017 hat Chrome 56 SHA-1-Zertifikate endgültig abgelehnt. Firefox und Edge zogen nach. Heute signiert jede CA mit SHA-256 oder besser. Wer sich für den aktuellen Stand von TLS und Zertifikaten interessiert: Da hat sich seit 2014 einiges getan.

Fragen? Einfach melden.

Google will sicheres Internet.

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Fragen? Einfach melden.

E-Mail-Benachrichtigung bei Root-Login einrichten

Kein Server lässt sich zu 100 Prozent absichern. Wenn sich jemand eine Root-Shell öffnet, will ich das zeitnah wissen. Nicht erst wenn Kunden sich melden oder Abuse-Mails eintrudeln. Eine kurze E-Mail mit IP-Adresse und Zeitstempel bei jedem Root-Login gibt zumindest einen Anhaltspunkt.

Vorweg: Das ist kein Security-Feature. Ein Angreifer mit Root-Rechten kann die Benachrichtigung deaktivieren, die Mail abfangen oder die .bashrc löschen. Es ist Schlangenöl, wenn man es als Schutzmaßnahme verkauft. Aber als ergänzender Hinweis funktioniert es gut, weil die Mail meist schon raus ist bevor der Angreifer sie verhindern kann. Vorausgesetzt, die Mail geht an einen anderen Server.

Variante 1: .bashrc

Die einfachste Methode. Eine Zeile in /root/.bashrc schickt bei jedem Öffnen einer interaktiven Shell eine Mail:

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@example.com

Das Ergebnis sieht dann so aus:

Subject: Alert: Root Access from 203.0.113.42
ALERT - Root Shell Access (bsd01) on: Mi 12. Mär 14:22:03 CET 2026 root pts/0 2026-03-12 14:22 (203.0.113.42)

Damit die IP-Adresse statt eines Hostnamens in der Mail steht, sollte der SSH-Server keine DNS-Abfragen machen:

# /etc/ssh/sshd_config
UseDNS no

Variante 2: PAM

Robuster als die .bashrc-Methode, weil PAM vor der Shell greift und nicht so leicht umgangen werden kann. In /etc/pam.d/sshd am Ende:

session optional pam_exec.so /usr/local/bin/login-notify.sh

Das Script /usr/local/bin/login-notify.sh:

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
echo "SSH Login: $PAM_USER von $PAM_RHOST auf $(hostname) um $(date)" | \
  mail -s "SSH Login: $PAM_USER@$(hostname) von $PAM_RHOST" root-logins@example.com

PAM setzt die Umgebungsvariablen PAM_USER, PAM_RHOST und PAM_TYPE automatisch. Das Script prüft auf open_session, damit es nur beim Login feuert und nicht beim Logout.

FreeBSD

Unter FreeBSD heißt die PAM-Konfiguration /etc/pam.d/sshd (gleicher Pfad). Statt mail steht dort mailx zur Verfügung, oder man nutzt direkt sendmail. Die .bashrc-Variante funktioniert genauso, die Datei liegt unter /root/.profile wenn csh/tcsh die Standard-Shell ist.

Einordnung

Login-Benachrichtigungen ersetzen kein Monitoring und kein Intrusion Detection System. Sie sind ein einfacher Stolperdraht, der in der Praxis überraschend oft hilft. Nicht weil er einen Angriff verhindert, sondern weil er die Reaktionszeit verkürzt. Wenn um drei Uhr nachts eine Login-Mail von einer unbekannten IP kommt, weiß man dass etwas nicht stimmt.

Wer den SSH-Zugang selbst härten will: Multi-Faktor-Authentifizierung mit Google Authenticator macht einen erfolgreichen Login ohne den zweiten Faktor deutlich unwahrscheinlicher. Fragen? Einfach melden.

Aber ich habe doch nichts zu verbergen…

Da ist nun also das Ergebnis von eurem „Ich habe doch nichts zu verbergen“! Klasse, gut gemacht….

http://www.golem.de/news/data-mining-polizei-will-straftaten-mit-predictive-policing-verhindern-1407-107638.html

Jetzt muss du nicht mal was zu verbergen haben, jetzt reicht es, wenn man statistisch leider gerade „auffällig“ ist. Am Ende treten die Jungs euch die Türe ein, verhaften euch und führen euch in Handschellen ab. OK ok… Wird nicht passieren, Rechtsstaat usw…. Riiiiiiccchhhhtttiiiigggg

Glaubt ihr das wirklich?

Klar, wenn sich am Ende herausstellt das ihr nichts zu verbergen hattet, wird schon nichts passieren…. Dem Rest kann man ja auch später erklären das die Vorwürfe völlig haltlos waren und euch nichts nachgewiesen werden konnte. Das verstehen alle und es bleibt kein ~Nachgeschmack~… Ich übertreibe? Na warten wir mal ab, ich denke es wird noch genau so kommen. Genug Metadaten habe sie ja inzwischen.

Ich denke: „It´s time for PANIC!“ Ich habe Angst 🙁

Panic reaction GIF about surveillance and privacy

Wir müssen unbedingt alle etwas mehr auf unsere Daten achten und vor allem etwas „nervöser“ werden wenn es um die Überwachung von egal was geht. Nicht alles sinnfrei glauben, sondern mal mit Hirn hinterfragen! Das Thema: „Ich habe doch nichts zu verbergen“ ist damit wohl hoffentlich erschlagen, oder?

Fragen? Einfach melden.

Openfire: AES-256-Verschlüsselung mit JCE Unlimited Strength aktivieren​

Veraltet: Seit Java 9 (2017) ist JCE Unlimited Strength standardmäßig aktiviert. Die hier beschriebene manuelle Installation der Policy Files ist bei aktuellen Java-Versionen nicht mehr nötig.

Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.

Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!

Die Installation ist recht einfach.

Zuerst einmal die neuen Policy Files herunterladen (für Java 7):

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html  

Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die….  na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:

/usr/lib/jvm/java-7-oracle/jre/lib/security
/usr/lib/jvm/jdk1.7.0_51/jre/lib/security

Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.

Clientreport:

https://xmpp.net/result.php?id=42150

Serverreport:

https://xmpp.net/result.php?id=42151

Noch Fragen? Na dann fragen.

Openfire und StartSSL Zertifikate

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und ist nicht mehr verfügbar. Let’s Encrypt ist der kostenlose Standard für TLS-Zertifikate.

Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.

Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.

1. OpenFire beenden.

2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.

In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.

$ cd /etc/openfire/security
$ wget http://www.startssl.com/certs/sub.class2.server.ca.crt
$ cat sub.class2.server.ca.crt domain.tld.cert > domain.tld.cert.tmp

3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.

$ openssl pkcs12 -export -in domain.tld.cert.tmp -inkey domain.tld.key -out domain.tld.pkcs12 -name domain.tld

4. Als letzten Schritt kann ich nun das Zertifikat in den Keystore meines Openfires aufnehmen:

$ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /etc/openfire/security/keystore -srckeystore domain.tld.pkcs12 -srcstoretype PKCS12 -srcstorepass changeit -alias domain.tld

5. Openfire wieder starten.

Nun lässt sich bereits im Webinterface das neue Zertifikat sehen und ist nutzbar.

Noch Fragen?

Openfire und IPv6: NumberFormatException bei S2S-Authentifizierung

Openfire hat ein Problem wenn in der /etc/resolv.conf der Nameserver als IPv6-Localhost eingetragen ist (::1). Der Java-DNS-Client kann die IPv6-Adresse nicht parsen und wirft eine NumberFormatException. Das Ergebnis: Keine S2S-Verbindungen, keine Authentifizierung mit Remote-Servern.

Fehlerbild

Im /var/log/openfire/error.log findet sich:

org.jivesoftware.openfire.session.LocalOutgoingServerSession
  - Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
    at java.lang.Integer.parseInt(Integer.java:492)
    at com.sun.jndi.dns.DnsClient.(DnsClient.java:125)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession
        .createOutgoingSession(LocalOutgoingServerSession.java:270)

Java versucht ::1 als Portnummer zu parsen und scheitert an dem Doppelpunkt. Der Bug steckt in Javas DnsClient-Klasse die IPv6-Adressen in der resolv.conf nicht korrekt behandelt.

Lösung

In der /etc/resolv.conf den Nameserver von ::1 auf 127.0.0.1 umstellen:

# vorher
nameserver ::1

# nachher
nameserver 127.0.0.1

Openfire neu starten. Der lokale DNS-Resolver lauscht in der Regel auf beiden Adressen, die Namensauflösung funktioniert über IPv4 genauso. Neuere Java-Versionen haben den Bug behoben, aber wer eine ältere Version nutzt oder nicht updaten kann, ist mit dem IPv4-Workaround auf der sicheren Seite.

Weitere Openfire-Probleme mit S2S-Verbindungen: 404 Remote Server Not Found behandelt fehlende Intermediate-Zertifikate.

Fragen? Einfach melden.

DNSSEC-fähiger Registrar

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.

Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.

Mehr zu DNSSEC und BIND gibt es im DNSSEC-HowTo. Fragen? Einfach melden.

Gestohlene FTP-Zugangsdaten BSI

WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen.


CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:

Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten

Sehr geehrte Damen und Herren,

CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.

Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.

Format: ASN | IP-Adresse | FTP-Login

Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.

Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.

Liste der Zugangsdaten für Server in Ihrem Netzbereich:

 12345 | 123.123.123.123  | benutzername:IG******@ftp21.domain.tld

Mit freundlichen Grüßen
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn

————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.

Siehe auch: E-Mail-Benachrichtigung bei Root-Login

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑