Kategorie: IT-Security (Seite 11 von 15)

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!

OK ok, ein altes Thema, denn noch habe ich es gerade an der Hand und somit kommt wieder ein kleiner Beitrag dazu hier 🙂

Man kann seine Server nicht zu 100% absichern. Um im Fall der Fälle einen kleinen Anhaltspunkt zu haben, lasse ich mir vom jeweiligen Server gerne eine E-Mail schicken sobald jemand eine root-shell öffnet. Selbstverständlich ist es Schlangenöl, wenn ich es als Security Feature bezeichnen würde! Warum ich es denn noch gerne einsetzte möchte ich daher kurz erklären.

Erlangt ein Angreifer (aus welchen Gründen auch immer) erweiterte Rechte auf einem System, möchte ich ungern erst später von Kunden davon hören…. Weil Mist auf der Webseite steht oder irgendwelche Abuse-Mails bei mir aufschlagen…. Hat sich ein Angreifer erweiterte Rechte auf dem Server erarbeitet, kann er natürlich seine Aktivitäten und Anwesenheit „verschleiern“.

Verschickt das System bei jeder Eröffnung einer root shell eine E-Mail an mich, habe ich zumindest einen Anhaltspunkt. Denn wenn sich auf irgendeinem Server jemand als root anmeldet ohne das ich eine solche Anmeldung erwarten würde und dann vielleicht noch von einer IP-Adresse, welche mir komisch vorkommt, ja dann habe ich meinen Anhaltspunkt dieses zu hinterfragen!

Natürlich sollte die verschickte E-Mail nicht an den gleichen Server geschickt werden, sonst frisst der Angreifer die E-Mail auf, noch bevor ich sie lesen kann. Da die E-Mail direkt mit dem Login verschickt wird, ist sie meist schon unterwegs, noch bevor der Angreifer sie aufhalten kann. Es ist und bleibt aber Schlangenöl!!!!

Die eigentliche Befehlszeile kursiert in den gängigen Suchmaschinen. Folgendes ist also copy & paste….

Das Programm mailx sorgt dabei für den Mailversand auf der Shell. Die folgende Befehlszeile tut nichts weiter als den letzten „SSH“-Login abzugreifen, den ~Absender~ des Logins heraus zu fummeln und es mir per E-Mail zu schicken. Damit es bei jedem Start der Bash des Users Root erfolgt, landet die Zeile im Home des Roots in der Datei: /root/.bashrc

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

Ich darf an der Stelle noch erwähnen, das ich meinem SSH-Server verboten habe DNS Abfragen zu tätigen. So landet in meinem Fall direkt die IP Adresse in der E-Mail und kein Hostname.

/etc/ssh/sshd_config

UseDNS no

Ein Login sorgt nun also für eine E-Mail mit folgendem Inhalt:

ALERT - Root Shell Access (dlg-srv88) on: So 3. Aug 19:28:18 CEST 2014 root pts/0 2014-08-03 19:28 (1.2.3.4)

Dieses kann nun auf gleichem Wege auf andere Benutzer ausgeweitet werden. Man könnte auch zusätzlich noch die letzten und wichtigen Logdateien anhängen. Ich denke aber es sollte nur ein Hinweis bleiben und nicht versucht werden zu einer Security Lösung ausgebaut werden, denn es greift sicher nicht in jedem Fall und es lässt sich ebenfalls aushebeln.

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 🙂

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?

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.

Mein Jabber Server hat gerade neue Zertifikate bekommen. Die alten waren ausgelaufen…. Ich spare mit die Fingerprints, prüft bitte per TLSA 😀

So long…