Mein Datenhaufen zu IT und Elektronik Themen.

Schlagwort: Security (Seite 2 von 4)

DoH (DNS over HTTPS) mit Bind

Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet.  DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.

Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…

DoH DNS over HTTPS Firefox

Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?

Postfix soll nur für SASL Benutzer verschleiern

Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…

Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.

Man erstellt in der master.cf vom Postfix einen neuen Service:

anonym unix n       -       -       -       0       cleanup
  -o header_checks=pcre:/usr/local/etc/postfix/header_cleanup

Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:

submission inet n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym
[...]
smtps     inet  n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym

Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

FreeBSD OpenSSH OS Banner entfernen

Im Standard ist der OpenSSH Server auf einem FreeBSD so konfiguriert, dass er jeweils die aktuelle Betriebssystemversion mit ausliefert.

Dieses sieht dann im Beispiel so aus:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

Um hier zumindest die genaue OS Version zu verstecken reicht folgendes in der /etc/sshd_config:

#VersionAddendum FreeBSD-20180909
VersionAddendum DemMeisterSeinRennAuto

Testet man nun noch mal sieht man nur noch die Version:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 DemMeisterSeinRennAuto

Auf einem Debian basierten System wäre es hingegen:

DebianBanner no

DoT DNS over TLS mit Bind, stunnel und Android 9

Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter 🙂

Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:

[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
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

[dns6]

accept = 2a03:4000:38:20e::53: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 ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 options = CIPHER_SERVER_PREFERENCE options = DONT_INSERT_EMPTY_FRAGMENTS renegotiation = no

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

DoT Android 9

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu 😀

Postfix client-initiated renegotiation deaktivieren

client-initiated renegotiation beim SMTPD Server kann für DDoS Angriffe ausgenutzt werden. Die einzelnen TLS/SSL Optionen lassen sich über die recht gleichnamige Option im Postfix ein und ausschalten. Gibt es noch keinen mappenden Namen kann die jeweilige Option auch ein/ausgeschaltet werden mit dem jeweiligen Hexwert. Genau Infos findet man hier: http://www.postfix.org/postconf.5.html#tls_ssl_options

If the value of the parameter is a hexadecimal long integer starting with "0x", the options corresponding to the bits specified in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3))

Für ein Postfix  3.3 und einem OpenSSL ab Version 1.1.1 ist der passende Hexwert 0x40000000.

Die Option setzt man wie so oft in der main.cf:

root@smtp:/ # postconf  tls_ssl_options
tls_ssl_options = 0x40000000

Ab Postfix >=3.4 gibt es: NO_RENEGOTIATION

Fragen? Dann fragen 🙂

Postfix soll verschleiern…

Um sich vor Angreifern zu schützen ist ein ganz gutes Mittel, dem Angreifer nicht direkt zu erzählen welche Software genau und in welcher Version man diese einsetzte. Bei Webservern ist dieses fast überall gängige Praxis, meist bekommt man nur noch das Produkt angezeigt. Oder wie bei einem Kollegen nur YOUR MUM. Warum ist das nun ggf. hilfreich? Ganz simples Beispiel. Man setzt einen verwundbaren Mailclient auf seinem Desktop ein, oder hat einen phpmailer (*würk*) in seiner Webseite eingebaut. Versendet man über diesen nun eine E-Mail schreibt er meist seinen eigenen Namen mit der eingesetzten Version in die E-Mail Header. Copy & Paste fertig für einen möglichen Angreifer, damit er die „Bugzilla Page“ nach den brauchbarsten Löchern durchwühlen kann. Dann muss er nur noch eine passende präparierte E-Mail schreiben und der Client wird leiden.

Ähnlich ist es mit den IP Adressen. Die IP Adresse des Clients landet ebenfalls in den Mail Headern. So hat der Angreifer schon mal eine Idee über die Netztopologie oder es gibt ihm ggf. eine Möglichkeit den Benutzer durch verschiedene Netze zu „tracken“.

Beides lässt sich über die smtp_header_checks etwas entschärfen. Über diesen Weg kann man per RegEx bestimmte Mail Header heraussuchen und löschen oder nach eigenem Ermessen ersetzten.

Hier der Eintrag für die main.cf:

root@smtp:/usr/local/etc/postfix # postconf smtp_header_checks
smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Hier das Beispiel für die /usr/local/etc/postfix/header_cleanup:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Im Ergebnis sieht es dann wie folgt aus:

[...]
Received: from ::88 (YOUR MOM [::88])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.kernel-error.de (Postfix) with ESMTPSA id 7458E7B802
	for <wurst@example.com>; Wed, 27 Mar 2019 21:44:10 +0100 (CET)
[...]
X-Mailer: YOUR MOMS MAILER
[...]

Ganz wichtig ist natürlich die Frage ob dabei Signaturen gebrochen werden; das werden sie nicht. Auch DKIM usw. nicht.

Dann mal viel Spaß!

TLS 1.3 für Postfix und Dovecot

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

Kein TLS 1.0 mehr

Da TLS 1.0 zum 30.06.2018 aus dem PCI Support fliegt (was nach knapp 19 Jahren auch mal ok ist), habe ich bei mir gerade überall den TLSv1.0 Support deaktiviert. Nein ich möchte nicht PCI konform sein… Damit sorge ich nun wieder einmal dafür, dass man mich mit einiger alter Software/Hardware und Betriebssystemen nicht mehr erreicht. Für mich ganz persönlich kann ich damit sehr gut leben 🙂 Wer jetzt noch mit so einer „Kiste“ unterwegs ist…. Na, der ist Kummer gewohnt!

Wen es interessiert der kann mit Qualys SSL Labs alles Mögliche scannen und auch direkt sehen welche Systeme wohl bei einem selbst nicht mehr funktionieren werden.

Zusätzlich spiele ich schon länger mit dem Gedanken bei meinem Mailserver Übertragungen ohne Transportverschlüsselung komplett zu verbieten. Für mich selbst kann ich es ja frei entscheiden. Lieber keine E-Mail als eine ohne Krypto! Ich werde mal auswerten wie denn das Verhältnis ist und welche E-Mails mich nicht mehr erreichen würden. Dann sehen wir mal weiter! Ich bin nur deswegen etwas zögerlich, weil mir in der Vergangenheit immer mal wieder Gegenstellen unter die Nase gekommen sind, bei welchen ich fest davon ausgegangen wäre, dass sie TLS einsetzten. Städte, Krankenhäuser, Ärzte, Schulen, IT-Security Dienstleister usw. usw… Hier scheint noch immer Unverständnis darüber zu herrschen, für was man denn wohl bitte dieses TLS braucht. Der Dienstleister meiner Heimatstadt begrüßt mich zumindest inzwischen mit einem Cisco Demo Zertifikat. *kopfschüttel* da hat der Admin nach meinen letzten Fragen zu dem Thema wohl den „security ON Button“ in seiner GUI gefunden O_o

Wobei… Mein Brötchengeber setzt auf einen eigenen Exchange Server bei welchem zuletzt 3DES Cipher abgeschaltet werden mussten. Das macht keinen Spaß und keinen Sinn. Windows-Admins scheinen hier schmerzfrei zu sein, hm?

TLS 1.3, das wäre ja mal was 🙂 ich warte schon mit schwitzigen Fingern. Zumindest sind wir schon mal bei Beta 5 (29.05.2018). Die Beta 1 vom 20.03 habe ich mir zuletzt in einer Jail angesehen und damit sehr zufrieden etwas herumprobiert. Für so etwas bin ich einfach zu ungeduldig. Ist das bei euch anders? Wollt ihr lieber noch TLSv1.0 haben?

TLS 1 ist tot und damit ist es dann jetzt weg, egal ob im stunnel:

;/usr/local/etc/stunnel/conf.d/tls.conf
[...]
options = NO_SSLv3
options = NO_TLSv1
ciphers = ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256
[...]

Oder unter Postfix:

#/usr/local/etc/postfix/main.cf
[...]
smtp_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh2048.pem
[...]

Oder auch im Dovecot:

#/usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
ssl = required
ssl_dh_parameters_length = 4096
ssl_protocols = !SSLv3 !SSLv2 !TLSv1
ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_prefer_server_ciphers = yes
[...]

Selbstverständlich auch im Nginx:

#/usr/local/etc/nginx/nginx.conf
[...]
ssl_stapling on;
ssl_stapling_verify on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1.1 TLSv1.2;
[...]

Und so weiter und so weiter 🙂

SSD Secure-Erase mit FreeBSD

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 😀

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑