-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Kategorie: IT-Security (Seite 7 von 14)

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

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

20. März 2018 / / Ein Kommentar

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen.

Siehe auch: ZFS Encryption

Fragen? Einfach melden.

DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten

22. Dezember 2017 / / Keine Kommentare

DNS-Abfragen laufen normalerweise im Klartext über UDP Port 53. Jeder der den Traffic mitlesen kann (ISP, Hotspot-Betreiber, Geheimdienst) sieht welche Domains aufgelöst werden. RFC 7858 definiert DNS over TLS (DoT): DNS-Abfragen über eine TLS-verschlüsselte TCP-Verbindung auf Port 853.

BIND9 konnte zum Zeitpunkt dieses Beitrags kein natives DoT. Die Lösung: stunnel als TLS-Wrapper vor den BIND stellen. stunnel terminiert die TLS-Verbindung auf Port 853 und leitet die entschlüsselten DNS-Pakete an BIND auf Port 53 weiter.

Stunnel-Konfiguration

Unter FreeBSD liegt die Konfiguration in /usr/local/etc/stunnel/conf.d/. Für IPv4 und IPv6 jeweils eine Sektion:

# /usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

[dns6]
accept = :::853
connect = ::1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

accept ist der Port auf dem stunnel lauscht (853 = DoT-Standard). connect ist der lokale BIND9. Das Zertifikat muss für den Hostnamen des DNS-Servers gültig sein, sonst schlägt die Validierung auf der Client-Seite fehl.

Testen

TLS-Verbindung prüfen:

openssl s_client -connect ns1.kernel-error.de:853

In der Ausgabe sollte Verify return code: 0 (ok) stehen und eine TLS-1.2- oder TLS-1.3-Verbindung angezeigt werden.

DNS-Abfrage über TLS mit getdns_query (in den FreeBSD-Ports als getdns):

getdns_query @ns1.kernel-error.de -s -a -A -l L www.kernel-error.de AAAA

Die Option -l L erzwingt TLS. Bei Erfolg kommt ein JSON-Objekt mit "status": GETDNS_RESPSTATUS_GOOD und der aufgelösten Adresse zurück. Alternativ kann man mit kdig (aus dem Paket knot-utils) testen:

kdig +tls @ns1.kernel-error.de www.kernel-error.de AAAA

Clients

Android 9+ hat DoT nativ eingebaut (Einstellungen → Netzwerk → Privates DNS). Dort den Hostnamen des eigenen DNS-Servers eintragen. Unter Linux kann systemd-resolved DoT, oder man nutzt stubby als lokalen DoT-Proxy.

Weiterentwicklung

Neben DoT gibt es inzwischen auch DNS over HTTPS (DoH), das DNS-Abfragen über HTTPS auf Port 443 tunnelt. DoH hat den Vorteil, dass es durch Firewalls und Proxies nicht blockiert werden kann, weil es wie normaler HTTPS-Traffic aussieht. Mein DNS-Resolver dns.kernel-error.de bietet inzwischen beides an. Fragen? Einfach melden.

BIND: EDNS-PMTU-Fehler bei DNSSEC beheben

5. Juli 2017 / / Keine Kommentare

Mir ist an ein paar Systemen ein Problem im Zusammenhang mit DNSSEC, IPv6 und UDP-Paketgrößen aufgefallen — genauer gesagt hat mich DNSviz darauf gestoßen:

domain.tld/A: No response was received until the UDP payload size
was decreased, indicating that the server might be attempting to
send a payload that exceeds the path maximum transmission unit
(PMTU) size. (2001:db8::1, UDP_0_EDNS0_32768_4096)

Was passiert da?

Der DNS-Server (hier BIND 9.11) versucht, auf eine Anfrage mit einem UDP-Paket von 4096 Byte zu antworten. Irgendwo auf dem Weg — Firewall, Netzwerkfilter, MTU-Einschränkung — wird das Paket verworfen. Da UDP kein Feedback gibt, merkt BIND davon nichts und glaubt, die Antwort sei zugestellt.

Beim Client fällt das kaum auf: dig und andere Resolver verringern automatisch die EDNS-Puffergröße und wiederholen die Anfrage — es dauert nur etwas länger. DNSviz testet aber systematisch und meldet das Problem.

Maximale UDP-Größe ermitteln

Mit dem Reply Size Test von DNS-OARC lässt sich herausfinden, welche Paketgröße vom eigenen System aus durchkommt:

$ dig +short rs.dns-oarc.net txt
rst.x490.rs.dns-oarc.net.
rst.x499.x490.rs.dns-oarc.net.
rst.x457.x499.x490.rs.dns-oarc.net.
"2001:db8::1 sent EDNS buffer size 512"
"2001:db8::1 DNS reply size limit is at least 499"

In diesem Fall enden die Antworten bei 512 Byte — alles darüber wird unterwegs gefressen.

BIND konfigurieren

BIND anweisen, die UDP-Paketgröße zu begrenzen:

options {
    edns-udp-size 1232;
    max-udp-size 1232;
};

edns-udp-size begrenzt die empfangene Paketgröße, max-udp-size die gesendete. Clients bekommen damit auf ihre erste Anfrage direkt eine Antwort, ohne schrittweise herunterhandeln zu müssen.

Warum 1232 und nicht 512?

512 Byte ist das klassische DNS-Limit ohne EDNS — funktioniert überall, ist aber unnötig klein. Seit dem DNS Flag Day 2020 empfehlen die großen DNS-Betreiber 1232 Byte als EDNS-Puffergröße. Der Wert ergibt sich aus der minimalen IPv6-MTU (1280 Byte) minus IPv6-Header (40 Byte) minus UDP-Header (8 Byte) = 1232 Byte. Das passt durch jedes korrekt konfigurierte Netzwerk.

Wenn selbst 1232 nicht durchkommt, liegt das Problem im Netzwerk — Firewalls die UDP-Pakete über einer bestimmten Größe filtern oder ICMP Packet Too Big unterdrücken. In dem Fall den dns-oarc-Test wiederholen und den Wert entsprechend anpassen.

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

Brute-Force Angriffe auf Joomla

10. April 2017 / / Keine Kommentare

Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.

Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!

Siehe auch: SSH-Server absichern mit MFA

Fragen? Einfach melden.

GlobalSign S/MIME und so…

31. März 2017 / / Keine Kommentare

Nach dem „tot“ von StartSSL brauche ich ja auch mal ein neues S/MIME Zertifikat. Class 2 bei GlobalSign sollte für mich privat reichen (auch wenn ich schon auf Class 3 geschielt habe, mal sehen ob ich das noch nachziehe). Als erstes habe ich da trocken angerufen und gefragt ob ich auf sie bauen kann oder mich am Ende so ärgere wie über StartSSL / Symantec usw… Klar es ist eine große CA die zu viel Geld für Mist bekommen und der Anruf war total nutzlos. Er hat dennoch für Spaß bei mir und da bin ich mir sicher, ebenfalls bei GlobalSign geführt.

Nun klicke ich mich also gerade durch die Anmeldung und muss alle möglichen Daten eingeben sowie Vereinbarungen zustimmen usw. an einer Stelle soll ich dann schon mal mein Kennwort für die Zertifikatsverwaltung festlegen. Ich überzeuge also wie immer pwgen mir eines zu würfeln werfe es rein. Die Info unter dem Kennwortformular lese ich natürlich nicht und bekomme direkt die Quittung. Ich habe unerlaubte Sonderzeichen in meinem Passwort für die Zertifikatsverwaltung angegeben. Unerlaubte Sonderzeichen?!?!? Stimmt… Die Kennwörter dürfen nur aus Zahlen und Buchstaben (groß/klein) bestehen..

Das Kennwort für die Zertifikatsverwaltung darf also keine Sonderzeichen enthalten. Den Satz habe ich jetzt schon ein paar mal gesagt aber öhm ich begreife ihn irgendwie noch nicht. *kopfschüttel* Kann mir das bitte mal jemand verständlich machen? Am besten ich ruf da noch mal an, oder?

Siehe auch: S/MIME per DNS mit SMIMEA

Fragen? Einfach melden.

ownCloud / Nextcloud Security Scanner

6. März 2017 / / Keine Kommentare

Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud

Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.

Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!

So long…

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Die Jungs vom BSI und Nextcloud: Zusammenarbeit für mehr Sicherheit

8. Februar 2017 / / Keine Kommentare

Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.

Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!

Oh ja, die abuse Mail:

Sehr geehrte Damen und Herren,
 
 ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst
 gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch
 von Daten.
 
 Das Unternehmen Nextcloud GmbH hat offen aus dem Internet
 erreichbare Installationen von ownCloud und Nextcloud geprft.
 Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit
 veralteten Software-Versionen laufen, welche verschiedene
 Sicherheitslcken aufweisen.
 
 Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem
 unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen.
 Dabei knnen die Angreifer ggf. sensible Informationen wie z.B.
 persnliche Dokumente, Fotos oder Kundendaten von Unternehmen
 aussphen und diese anschlieend im Internet verffentlichen oder
 fr kriminelle Zwecke wie Erpressungen nutzen.
 Andere Schwachstellen ermglichen Angreifern die Ausfhrung
 beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf.
 zu einer vollstndigen Kompromittierung des Systems und dessen
 Missbrauch fr weitere kriminelle Aktivitten fhren.
 
 Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen
 zur Untersttzung bei der Benachrichtigung betroffener Server-
 Betreiber bereitgestellt.
 
 Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in
 Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann
 die verwundbare Cloud-Installation identifiziert wurde.
 Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine
 eindeutige ID (UUID) angegeben.
 
 Die Nextcloud GmbH stellt unter folgender URL detaillierte
 Informationen zu den bei der jeweiligen Cloud-Instanz erkannten
 Schwachstellen und deren Behebung zur Verfgung:
 https://scan.nextcloud.com/results/[UUID]
 
 Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz
 angegebene UUID ersetzt werden. Beispiel:
 https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678
 
 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
 Aktualisierung der Cloud-Installationen auf den betroffenen Systemen
 zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle
 auf den betroffenen Systemen identifizierten Schwachstellen stehen
 entsprechende Sicherheitsupdates der Hersteller zur Verfgung.
 
 Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen
 wenden Sie sich bitte direkt an die Nextcloud GmbH unter
 <cloud-security-scan@nextcloud.com>.
 
 
 Diese E-Mail ist mittels PGP digital signiert.
 Informationen zu dem verwendeten Schlssel finden Sie unter
 <https://reports.cert-bund.de>.
 
 Bitte beachten Sie:
 Dies ist eine automatisch generierte Nachricht.
 An die Absenderadresse kann nicht geantwortet werden.
 Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte
 unter Beibehaltung der Ticketnummer in der Betreffzeile an
 <certbund@bsi.bund.de>.
 
 ======================================================================
 
 Betroffene Systeme in Ihrem Netzbereich:
 
 Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname
  12345 | 1.2.3.4    | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high       | 80     | cloud.domain.de
  12345 | 1.2.3.5    | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium     | 80     | cloud.wurst.com
  12345 | 1.2.3.6    | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low        | 80     | cloud.alalaa.de 
  12345 | 1.2.3.7    | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high       | 443    | cloud.butani.cn
  12345 | 1.2.3.8    | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high       | 80     | cloud.bima.org
  12345 | 1.2.3.9    | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high       | 80     | cloud.2083a.net
  12345 | 1.2.3.10   | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low        | 443    | cloud.lutzola.nl
  12345 | 1.2.3.11   | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high       | 80     | cloud.weglaa.wu
  12345 | 1.2.3.12   | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium     | 80     | cloud.breck.aa
  [.....]

 
 Mit freundlichen Gren / Kind regards
 Team CERT-Bund
 
 Bundesamt fr Sicherheit in der Informationstechnik (BSI)
 Federal Office for Information Security
 Referat CK22 - CERT-Bund
 Godesberger Allee 185-189, D-53175 Bonn, Germany

Fragen? Einfach melden.

Neues Zertifikat für die Homepage von Let’s Encrypt

24. Januar 2017 / / Keine Kommentare

Tach zusammen,

StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*

Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

https://startssl.com/NewsDetails?date=20160919

Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.

Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?

So long…

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑