IT-Blog von Sebastian van de Meer
Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.
Da bekomme ich gerade so ein neues Samsung Ultrabook in die Hand und schaue mir beim Auspacken den Karton an….. Da steht da etwas von Komputer Laptop? Also Komputer mit K?!?
Muss das so? Kenne ich da gerade etwas nicht?
Spannende Sache… Kennt da jemand eine Geschichte zu?
Fragen? Einfach melden.
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.
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 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.
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.
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.
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.
Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.
KLICK: https://de.ssl-tools.net/mailservers/kernel-error.de
Siehe auch: TLSA und DANE manuell prüfen
Fragen? Einfach melden.
Nach dem IPv6-Kongress 2014 war die Verbreitung mal wieder kurz im Rampenlicht. Nach über 15 Jahren IPv6 war die Umstellung noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert. Es gab ja keine Nachfrage. Bis den ISPs die IPv4-Adressen ausgingen.
Wer in Deutschland einen neuen Internetanschluss bei einem Kabelnetzbetreiber bekommt, bekommt oft einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet: Keine eigene öffentliche IPv4-Adresse mehr. Stattdessen eine private Adresse hinter einem zentralen NAT-Router des ISPs. Versteckt wird das hinter Bezeichnungen wie DS-Lite oder DS64-Lite.
Jede TCP-Verbindung verbraucht auf der abgehenden IP-Adresse einen Port. Ports sind 16-Bit-Zahlen, maximal 65.535. Abzüglich der reservierten Ports bleiben rund 64.500 gleichzeitige Verbindungen pro IP. Ein einzelner Benutzer baut schnell 50 und mehr Verbindungen gleichzeitig auf: E-Mail, Messenger, Browser mit parallelen Requests. Dazu kommen Verbindungen die nicht sauber geschlossen werden und bis zum Timeout offen bleiben.
Offene Verbindungen anzeigen:
netstat -tapen
Wenn sich hunderte Kunden eine öffentliche IP teilen, sind die Ports schnell aufgebraucht. Der ISP könnte bestehende Verbindungen nach einer Zeit hart zurücksetzen. Oder die maximale Anzahl gleichzeitiger Verbindungen pro Kunde begrenzen. Beides führt zu Problemen.
Dazu kommt: Viele Webserver und Mailserver begrenzen die Anzahl gleichzeitiger Verbindungen pro IP-Adresse, als Schutz gegen DDoS. Wenn hundert Kunden hinter einer IP sitzen, trifft dieses Limit schnell.
Ein gutes Beispiel war Sipgate. Der VoIP-Anbieter beschwerte sich öffentlich darüber, dass seine Kunden hinter CGN-Anschlüssen Probleme mit ihren Sipgate-Leitungen hatten. Sipgate schob den schwarzen Peter an Unitymedia und hoffte, dass sich jemand meldet um das Problem gemeinsam zu lösen.
Was dabei unterging: Unitymedia hatte auf eigene Kosten einen Workaround eingerichtet, damit Dienste die es nach Jahren noch nicht geschafft hatten IPv6 zu unterstützen überhaupt noch erreichbar waren. Und dann kommt ein Diensteanbieter und sagt: Dein Workaround funktioniert nicht perfekt mit unserem System, bitte nachbessern.
Der Schuldige ist nicht der ISP. Der Schuldige ist der Diensteanbieter, der es nach über 15 Jahren Vorlaufzeit nicht geschafft hat seinen Dienst IPv6-fähig zu machen. Wer Probleme mit seinem Internetanschluss hat die auf CGN zurückzuführen sind: Nicht den ISP anrufen, sondern den Diensteanbieter fragen wann IPv6 kommt.
Fragen? Einfach melden.
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.
Achtung, böser YouTube-Link!
Ich habe vor einiger Zeit ein „Will haben Gerät!“ gesehen… Bzw. den Prototyp eines solchen Gerätes. Zu dem Zeitpunkt wurde noch Geld für das Projekt gesammelt. Inzwischen ist die nötige Summe mehr als vorhanden und es geht seinen Weg…
Das Teil nennt sich Pockethernet, ein Video gibt es unten und einen Link zum Projekt gibt es hier: http://pockethernet.com/
Klar wird es kaum mit einem guten Fluke Gerät mithalten können… Für viele kleine Tests scheint es aber mehr als ausreichend zu sein. Schaut einfach mal ins Video! Wer will es noch?
Fragen? Einfach melden.
Mein Jabber Server hat gerade neue Zertifikate bekommen. Die alten waren ausgelaufen…. Ich spare mit die Fingerprints, prüft bitte per TLSA.
So long…
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑