Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 8 von 47)

FreeBSD: Native ZFS Encryption einrichten und nutzen

FreeBSD portierte bisher seinen ZFS Zweig von Illumos. Dieses wechselt nun zu ZFS on Linux. Was es für mich so spannend macht ist der Verschlüsselungssupport. ZFS on Linux bietet diesen bereits und somit wird er wohl auch bald für FreeBSD zur Verfügung stehen 🙂

Gerade eben lese ich eine E-Mail von Kris Moore auf der FreeBSD-Current Mailingliste. In der E-Mail werden zwei ISO Images genannt welche es ermöglichen FreeBSD mit ZFS on Linux zu testen. \o/ Natürlich ist es nicht die Version welche am Ende „drin“ sein wird und es ist nichts was man auch nur im Ansatz produktiv einsetzten kann/sollte. ABER testen soll man es ja und ich möchte unbedingt mal die Verschlüsselung sehen!

Daher habe mich mir die gepatchte FreeBSD13 Version einmal herunter geladen: https://pkg.trueos.org/iso/freebsd13-zol/FreeBSD13-ZoL-20190418-x64.iso

Zuletzt habe ich den Einsatz unter Solaris beschrieben. Nun also einmal ganz kurz und knapp in FreeBSD 🙂

Erstellen eines neuen Datasets:

root@freebsd13-zol:~ # zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:

Als Art der Verschlüsselung habe ich hier aes-256-gcm gewählt und der Schlüssel soll als passphrase von mir eingegeben werden. Nachdem ich mein passphrase eingegeben habe wird das neue Dataset erstellt und direkt für mich ein gehangen, wie man es gewohnt ist:

root@freebsd13-zol:~ # zfs list usbpool/test01
NAME             USED  AVAIL     REFER  MOUNTPOINT
usbpool/test01    99K   899G       99K  /usbpool/test01
root@freebsd13-zol:~ # zfs get encryption usbpool/test01
NAME            PROPERTY    VALUE        SOURCE
usbpool/test01  encryption  aes-256-gcm  -
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Da ein passphrase von mir jeweils eingegeben werden muss, kann dieses Dataset bei einem reboot oder impot/export nicht automatisch eingehangen werden.

root@freebsd13-zol:~ # zpool export usbpool
root@freebsd13-zol:~ # zpool import usbpool
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   no       -

Daher muss ich dieses von Hand anstoßen.

root@freebsd13-zol:~ # zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Genau so habe ich es mir gewünscht. Schnell, einfach und unkompliziert. Ob es ebenfalls über Snapshots send/recv und mit Keyfiles usw. so arbeitet wie ich es mir wünsche, werde ich nun probieren können!

Ein verschlüsseltes Dataset anlegen zu können, erfreut mich aber jetzt schon sehr!

Fragen? Dann fragen 🙂


Update

Um Fragen zu beantworten. Ja, die Userland Tools und das Kernelmodul sind bereits in den Ports. Will man es auf einem FreeBSD 12.x RELEASE bauen funktioniert dieses nicht:

root@test:/usr/ports/sysutils/zol-kmod # make install clean
===>  zol-kmod-2019041800 needs FreeBSD 12/13 with AES-CCM support.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/zol-kmod

Es funktioniert sauber mit FreeBSD 13 CURRENT und dem FreeBSD 12 STABLE. CURRENT ist bei FreeBSD immer die nächste Version. Die RELEASE Versionen sind die stabilen Versionen welche auch nur noch Security und Bugfixes bekommen. Die STABLE Verstion bekommt zudem noch „Veränderungen“ mit. Ganz grob kann man es also mit Stable, Testing, Unstable bei Debian vergleichen 🙂

Der AES-CCM Support ist also nur in FreeBSD 13 CURRENT und in FreeBSD 12 STABLE im Kernel aktiviert. Man kann also nun zum Testen auf die 13 wechseln, auf die 12 Stable gehen, auf das nächste RELEASE warten, seinen Kernel neu bauen oder eines der ISOs oben probieren. Jetzt ist auch klar, warum ich die ISOs so empfehlenswert fand/finde 😀 Vor allem da das FreeBSD 12 ISO das FreeBSD 12.0-RELEASE-p3 ist und man so schon seine Produktivumgebung testen kann!

Ich kann dir keine E-Mail schicken. Ich bekomme immer einen Fehler

703px Email not availablesvg

Einer der Vorteile eines eigenen Mailservers ist, dass man hier so restriktiv in seiner Konfiguration sein kann wie man es selbst für sich und seine Zwecke für richtig erachtet. So habe ich für mich entschieden, dass ich nur E-Mails annehmen möchte, welche über eine Transportverschlüsselung (TLS) bei mir eingeliefert werden. Wer also die folgende Meldung in seiner Errormail hat, dessen Mailserver hat sicher probiert die E-Mail bei mir ohne Transportverschlüsselung (also im Klartext) abzuliefern.

[...]
530-5.7.0 Must issue a STARTTLS command first
530 5.7.0 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
[...]

Transportverschlüsselung ist dabei bitte nicht zu verwechseln mit einer signierten oder gar verschlüsselten E-Mail. Ich nehme auch E-Mails an, welche weder signiert oder verschlüsselt sind. Die Transportverschlüsselung ist hier etwas wie das s bei httpS://. Das Mitlesen der E-Mail auf dem Weg zwischen eurem und meinem Mailserver soll damit nach Möglichkeit verhindert werden.

Möglichst verhindert werden? Ja, einen 100%tigen Schutz gibt es selbstverständlich nicht. Man kann nur versuchen sich diesem zu nähern. Dieses Nähern betrifft nun den zweiten Punkt welcher verhindern könnte, dass ihr mir eine E-Mail senden könnt. Die eingesetzte Transportverschlüsselung muss nämlich als „sicher“ gelten. Ich nehme also keine SSLv3 RC4 MD5 bla Verbindungen an. Wer also etwas wie das Folgende oder halt „Verbindung nicht möglich“ bekommt, dessen Mailserver ist nicht in der Lage eine „sichere“ TLS Verbindung aufzubauen.

warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared ciphe

warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol

warning: TLS library problem: error:142090FC:SSL routines:tls_early_post_process_client_hello:unknown protocol

Warum macht dieses nun nicht jeder so? Nun… Möchte man als Unternehmen Geld damit verdienen, dass man in irgendeiner Form Benutzer dazu bringt bei einem einen E-Mail Service zu nutzen, dann möchte man natürlich seinen Kunden einen möglichst reibungsfreien Austausch ermöglichen. Denn der normale Benutzer wird es kaum verstehen und sicher einfach einen Anbieter wählen bei dem es „funktioniert“. Dieses könnte man daher als Grund anführen warum nicht jeder so restriktiv in seinen Empfangseinstellungen ist. Davon abgesehen hindert es kein Unternehmen daran, seinem Mailserver für ausgehende E-Mails die Möglichkeit zu schaffen gutes TLS zu sprechen. Ok, es sei denn dieser Server steht in China oder Nordkorea. Mein Mailserver ist also weit davon entfernt etwas Unmögliches zu verlangen!!!

Sprecht also mal mit der zuständigen Person eures Mailservers und fragt aus welchem Grund euer Mailserver nicht in der Lage ist sicheres TLS zu sprechen und ob man dieses nicht vielleicht doch ändern könnte!

Um mich in der Zwischenzeit dennoch irgendwie zu erreichen gibt es verschiedene Möglichkeiten welche man >>hier<< findet. Am einfachsten sicher über Matrix/Riot: @kernel-error:kernel-error.com.

Bis dahin 🙂

E-Mails nur noch mit TLS: Transportverschlüsselung erzwingen

Eigentlich wollte ich erst im März 2020 so weit gehen und alle E-Mails abweisen, die nicht über einer brauchbare Transportverschlüsselung kommen… Nun sagt mir mein Monitoring, dass 97,32 % der E-Mails über eine Transportverschlüsselung eingeliefert werden. Fast alle wichtigen Großen bekommen es hin. Hier und da kann es ein Onlinebesteller oder eine Kiste aus Asien noch nicht, das ist dann aber für mich ok.

Da ich bei mir ebenfalls MTA-STS einsetze, Will ich ja absichtlich zu TLS zwingen. Mal sehen wie anstrengend die letzten knapp 3% E-Mails nun wirklich werden. Dieses betrifft nun nicht nur mich selbst sondern ebenfalls einige andere Nutzer meines des Mailsystems. Der Kreis ist dafür überschaubar und Sicherheit ist allen wichtiger als eine nicht bekommene E-Mail aus Asien. Zumindest in der Theorie 😉

Wobei inzwischen die Benutzer meist eine „bessere“ Transportverschlüsselung nutzen als einige Mailserver zur S2S Kommunikation…..

Vor kurzem bin ich in Kontakt mit jemandem von mail.de gekommen. Haben insg. einen wirklich sehr freundlichen und kompetenten Endruck bei mir hinterlassen. Wenn ich mal wieder um einen Rat zu Mailhosting vefragt werde, wird mail.de ganz vorne mit dabei in der Liste sein 🙂

Warum jetzt mail.de? Nun sie haben ebenfalls vor einiger Zeit TLSv1.3 eingeführt und dazu einen übersichtlicehen Graphen erstellt. Die meisten Clients spielen also auch dort schon >=TLSv1.2.

Bei Webseiten hat sich eine brauchbare Transportverschlüsselung inzwischen viel Weiter durchgesetzt. Ich denke daran waren der Druck der Browserhersteller sowie die einfachen Testmöglichkeiten durch Anbieter wie Qualys stark beteiligt. Hätten nun also ein paar große internationale E-Mail Provider (?Google/Microsoft?) den Schneid ebenfalls eine Transportverschlüsselung zu erzwingen würde hier sicher schnell Bewegung in die Geschichte kommen. Da nicht mal Google bisher ihre MTA-STS Policy „scharf“ geschaltet hat, wird es wohl so schnell nichts.

Postfix: Client-Initiated Renegotiation sicher 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 🙂

FreeBSD als IPsec/L2TP-Client für Microsoft Windows Routing und RAS VPN

FreeBSD IPsec L2TP Client to Microsoft Windows Routing RAS Server

Vor einigen Monaten habe ich meinen FreeBSD (damals noch 11 heute 12) Desktop an einen Microsoft Windows Routing und RAS VPN Server angebunden. Das eingesetzte VPN war ein IPsec L2TP. Heute schaffe ich es endlich das Thema mal wegzuschreiben. Grob gesehen ist dieses der Aufbau.

Der FreeBSD Desktop hat dabei die IPv4 Adresse 192.168.10.57, der Windows Routing RAS VPN Server hat den FQDN vpnserver.domain.tld mit der IPv4 88.88.88.88 und der IPsec Tunnel hat den Namen vpnname. Die Netze im Unternehmen sind 172.16.0.0/12 und 10.0.0.0/8.

Tunneltyp ist ein IPsec L2TP an dem Windows „Ding“ mit PSK für den IPsec Tunnel und normaler Dämenenanmeldung über L2TP.

Auf meinem FreeBSD Desktop brauche ich also ipsec für den Tunnel und ich nutze mpd5 für L2TP. Ich „glaube“ l2tpd wäre vielleicht etwas besser, da mpd5 etwas manuelle Arbeit benötigt. Da ich an ein paar anderen Stellen ebenfalls mpd5 nutze und hier ohne Windows auch keine Handarbeit mehr nötig ist…. Es geht mir halt leichter von der Hand 🙂 Insg. ist die gesamte Konfiguration aber sehr einfach.

Meine ipsec Konfiguration sie wie folgt aus:

/usr/local/etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

#config setup
	# strictcrlpolicy=yes
	# uniqueids = no

# Add connections here.

# Sample VPN connections

#conn sample-self-signed
#      leftsubnet=10.1.0.0/16
#      leftcert=selfCert.der
#      leftsendcert=never
#      right=192.168.0.2
#      rightsubnet=10.2.0.0/16
#      rightcert=peerCert.der
#      auto=start

#conn sample-with-ca-cert
#      leftsubnet=10.1.0.0/16
#      leftcert=myCert.pem
#      right=192.168.0.2
#      rightsubnet=10.2.0.0/16
#      rightid="C=CH, O=Linux strongSwan CN=peer name"
#      auto=start

config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=psk

conn vpnname
        type=transport
        leftfirewall=yes
        right=vpnserver.domain.tld
        rightid = %any
        rightsubnet=0.0.0.0/0
        auto=add
        left=%defaultroute
        leftprotoport=17/%any
        rightprotoport=17/1701
        ike=3des-sha1-modp1024!
        esp=3des-sha1
        modeconfig=push

Der PSK steht in der /usr/local/etc/ipsec.secrets

# ipsec.secrets - strongSwan IPsec secrets file
vpnserver.domain.tld %any : PSK "abcdefg1234567"

Den IPsec Tunnel baut man nun einfach wie folgt auf:

root@errortest:~ # ipsec up vpnname
initiating Main Mode IKE_SA vpnname[20] to 88.88.88.88
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.10.57[500] to 88.88.88.88[500] (176 bytes)
received packet: from 88.88.88.88[500] to 192.168.10.57[500] (208 bytes)
parsed ID_PROT response 0 [ SA V V V V V V ]
received MS NT5 ISAKMPOAKLEY vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received FRAGMENTATION vendor ID
received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.10.57[500] to 88.88.88.88[500] (244 bytes)
received packet: from 88.88.88.88[500] to 192.168.10.57[500] (260 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.10.57[4500] to 88.88.88.88[4500] (68 bytes)
received packet: from 88.88.88.88[4500] to 192.168.10.57[4500] (68 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA vpnname[20] established between 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
scheduling reauthentication in 3402s
maximum IKE_SA lifetime 3582s
generating QUICK_MODE request 2082742542 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from 192.168.10.57[4500] to 88.88.88.88[4500] (220 bytes)
received packet: from 88.88.88.88[4500] to 192.168.10.57[4500] (212 bytes)
parsed QUICK_MODE response 2082742542 [ HASH SA No ID ID NAT-OA NAT-OA ]
selected proposal: ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ
CHILD_SA vpnname{38} established with SPIs c387d93f_i 4720cab6_o and TS 192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]
connection 'vpnname' established successfully

Ob der IPsec Tunnel steht sieht man mit:

root@errortest:~ # ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 12.0-RELEASE-p3, amd64):
  uptime: 12 hours, since Apr 03 21:26:07 2019
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock counters
Listening IP addresses:
  2003:88:53dd:a800:eef4:bbff:fe47:c54c
  fd00::eef4:bbff:fe47:c54c
  192.168.10.57
Connections:
      vpnname:  %any...vpnserver.domain.tld  IKEv1
      vpnname:   local:  [192.168.10.57] uses pre-shared key authentication
      vpnname:   remote: uses pre-shared key authentication
      vpnname:   child:  dynamic[udp] === 0.0.0.0/0[udp/l2f] TRANSPORT
Security Associations (1 up, 0 connecting):
      vpnname[20]: ESTABLISHED 14 seconds ago, 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
      vpnname[20]: IKEv1 SPIs: 8d3cfef7264b42cc_i* 0d322a1593a9db84_r, pre-shared key reauthentication in 56 minutes
      vpnname[20]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      vpnname{38}:  INSTALLED, TRANSPORT, reqid 10, ESP in UDP SPIs: c387d93f_i 4720cab6_o
      vpnname{38}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 14 minutes
      vpnname{38}:   192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]

Jetzt fehlt also nur noch L2TP, meine mpd5 Konfiguration sieht dabei so aus /usr/local/etc/mpd5/mpd.conf :

startup:
      # Set web self 127.0.0.1 5008
      # Set user vpntest vpntest admin
      # Set web open
log +ALL +EVENTS -FRAME -ECHO
default:
      load L2TP_client

L2TP_client:
    create bundle static B1
	set iface up-script /home/kernel/vpnname-up.sh
	set iface down-script /home/kernel/vpnname-down.sh
	set bundle enable crypt-reqd
	set bundle enable compression
	set bundle enable ipv6cp
	set ccp yes mppc
	set mppc no e40 e56
	set mppc yes e128 stateless
	set ipcp ranges 0.0.0.0/0 0.0.0.0/0
	set ipcp enable req-pri-dns
	set ipcp enable req-sec-dns
	set iface route 172.16.0.0/12
	set iface route 10.0.0.0/8
	set iface enable tcpmssfix



    create link static L1 l2tp
    set link action bundle B1
    set auth authname "AD-USERNAME"
    set auth password "AD-PASSWORD"
    set link max-redial 0
    set link mtu 1400
    set link keep-alive 20 75
    set link accept chap-msv2
	set link no pap eap


    set l2tp peer vpnserver.domain.tld
    open

Einfach starten mit:

root@errortest:/ # mpd5
Multi-link PPP daemon for FreeBSD

process 10142 started, version 5.8 (root@120amd64-quarterly-job-15 02:54  8-Feb-2019)
[B1] Bundle: Interface ng0 created
[L1] [L1] Link: OPEN event
[L1] LCP: Open event
[L1] LCP: state change Initial --> Starting
[L1] LCP: LayerStart
L2TP: Initiating control connection 0x800caa310 0.0.0.0 0 <-> 88.88.88.88 1701
L2TP: Control connection 0x800caa310 192.168.10.57 38844 <-> 88.88.88.88 1701 connected
[L1] L2TP: Incoming call #7540000 via control connection 0x800caa310 initiated
[L1] L2TP: Call #7540000 connected
[L1] Link: UP event
[L1] LCP: Up event
[L1] LCP: state change Starting --> Req-Sent
[L1] LCP: SendConfigReq #1
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: SendConfigReq #2
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: rec'd Configure Request #0 (Req-Sent)
[L1]   MRU 1400
[L1]   AUTHPROTO EAP
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   CALLBACK 6
[L1]   MP MRRU 1614
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigRej #0
[L1]   CALLBACK 6
[L1]   MP MRRU 1614
[L1] LCP: rec'd Configure Ack #2 (Req-Sent)
[L1]   ACFCOMP
[L1]   PROTOCOMP
[L1]   MRU 1500
[L1]   MAGICNUM 0x2d8654b6
[L1] LCP: state change Req-Sent --> Ack-Rcvd
[L1] LCP: rec'd Configure Request #1 (Ack-Rcvd)
[L1]   MRU 1400
[L1]   AUTHPROTO EAP
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigNak #1
[L1]   AUTHPROTO CHAP MSOFTv2
[L1] LCP: rec'd Configure Request #2 (Ack-Rcvd)
[L1]   MRU 1400
[L1]   AUTHPROTO CHAP MSOFTv2
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: SendConfigAck #2
[L1]   MRU 1400
[L1]   AUTHPROTO CHAP MSOFTv2
[L1]   MAGICNUM 0x74943399
[L1]   PROTOCOMP
[L1]   ACFCOMP
[L1]   ENDPOINTDISC [LOCAL] 01 d0 15 a9 b4 71 4f f4 a0 97 8e 3c e4 ef 93 d7 00 00 0
[L1] LCP: state change Ack-Rcvd --> Opened
[L1] LCP: auth: peer wants CHAP, I want nothing
[L1] LCP: LayerUp
[L1] CHAP: rec'd CHALLENGE #0 len: 26
[L1]   Name: "VPN-SERVER"
[L1] CHAP: Using authname "AD-USERNAME"
[L1] CHAP: sending RESPONSE #0 len: 60
[L1] CHAP: rec'd SUCCESS #0 len: 46
[L1]   MESG: S=39CCB87E756B7996C5A261EEC4CA14D30E4616E0
[L1] LCP: authorization successful
[L1] Link: Matched action 'bundle "B1" ""'
[L1] Link: Join bundle "B1"
[B1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
[B1] IPCP: Open event
[B1] IPCP: state change Initial --> Starting
[B1] IPCP: LayerStart
[B1] IPV6CP: Open event
[B1] IPV6CP: state change Initial --> Starting
[B1] IPV6CP: LayerStart
[B1] CCP: Open event
[B1] CCP: state change Initial --> Starting
[B1] CCP: LayerStart
[B1] IPCP: Up event
[B1] IPCP: state change Starting --> Req-Sent
[B1] IPCP: SendConfigReq #1
[B1]   IPADDR 0.0.0.0
[B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[B1]   PRIDNS 0.0.0.0
[B1]   SECDNS 0.0.0.0
[B1] IPV6CP: Up event
[B1] IPV6CP: state change Starting --> Req-Sent
[B1] IPV6CP: SendConfigReq #1
[B1] CCP: Up event
[B1] CCP: state change Starting --> Req-Sent
[B1] CCP: SendConfigReq #1
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] IPV6CP: rec'd Configure Request #4 (Req-Sent)
[B1] IPV6CP: SendConfigAck #4
[B1] IPV6CP: state change Req-Sent --> Ack-Sent
[B1] CCP: rec'd Configure Request #5 (Req-Sent)
[B1]   MPPC
[B1]     0x01000001:MPPC, stateless
[B1] CCP: SendConfigNak #5
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] IPCP: rec'd Configure Request #6 (Req-Sent)
[B1]   IPADDR 10.16.100.13
[B1]     10.16.100.13 is OK
[B1] IPCP: SendConfigAck #6
[B1]   IPADDR 10.16.100.13
[B1] IPCP: state change Req-Sent --> Ack-Sent
[B1] IPCP: rec'd Configure Reject #1 (Ack-Sent)
[B1]   COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[B1] IPCP: SendConfigReq #2
[B1]   IPADDR 0.0.0.0
[B1]   PRIDNS 0.0.0.0
[B1]   SECDNS 0.0.0.0
[B1] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
[B1] IPV6CP: state change Ack-Sent --> Opened
[B1] IPV6CP: LayerUp
[B1]   eef4:bbff:fe47:c54c -> e467:e46a:5b1f:dfc1
[B1] IFACE: Up event
[B1] CCP: rec'd Configure Ack #1 (Req-Sent)
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: state change Req-Sent --> Ack-Rcvd
[B1] CCP: rec'd Configure Request #7 (Ack-Rcvd)
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: SendConfigAck #7
[B1]   MPPC
[B1]     0x01000040:MPPE(128 bits), stateless
[B1] CCP: state change Ack-Rcvd --> Opened
[B1] CCP: LayerUp
[B1] CCP: Compress using: mppc (MPPE(128 bits), stateless)
[B1] CCP: Decompress using: mppc (MPPE(128 bits), stateless)
[B1] IPCP: rec'd Configure Nak #2 (Ack-Sent)
[B1]   IPADDR 10.16.100.34
[B1]     10.16.100.34 is OK
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: SendConfigReq #3
[B1]   IPADDR 10.16.100.34
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: rec'd Configure Ack #3 (Ack-Sent)
[B1]   IPADDR 10.16.100.34
[B1]   PRIDNS 10.16.0.53
[B1]   SECDNS 10.16.0.52
[B1] IPCP: state change Ack-Sent --> Opened
[B1] IPCP: LayerUp
[B1]   10.16.100.34 -> 10.16.100.13

Ob alles steht sieht man ebenfalls mit ifconfig :

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396
	inet6 fe80::eef4:bbff:fe47:c54c%ng0 prefixlen 64 scopeid 0x3
	inet 10.16.100.34 --> 10.16.100.13 netmask 0xffffffff
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Damit sollte auch schon der Tunnel stehen.

Der Windows VPN Server übermittelt zwar eigentlich die Routen, DNS Server usw., dieses nimmt der mpd5 aber nicht alles gut an. Das meinte ich mit manueller Handarbeit. Sicher nichts für die Masse aber wenn man als Admin „ran“ möchte sicher kein größeres Problem. set ccp yes mppc activiert hierbei die MPPC Komprimierung und Verschlüsselung. set mppc yes e128 stateless ist dabei für die Zusammenarbeit mit dem Windows Server wichtig, denn e128 / stateless ermöglicht als einzige Option die Zusammenarbeit mit MS-CHAPv2 (was hier zum Einsatz kommt). Per IPCP frage ich zwar die Konfiguration wie die ersten beiden DNS-Server ab ( set ipcp enable req-pri-dns / set ipcp enable req-sec-dns ), aktuell mache ich aber damit nichts. Diese Werte werden automatisch mit an die iface up-scripte/down-scripte übermittelt und könnten dort mitbenutzt werden, da ich nur eine solche Verbindung habe und die DNS Konfiguration kenne, nutze die die up/down-scripte nur um die jeweilige /etc/resolv.conf zu kopieren.

Mit den Routen ist es ähnlich, ich kenne die Routen und kann sie also einfach mitgeben: set iface route 172.16.0.0/12 / set iface route 10.0.0.0/8 diese Liste kann nach Belieben eingepasst werden.

Wie gesagt, alles sehr einfach und überschaubar.

Ich starte IPsec und in folge mpd5 meist von Hand, wenn ich es mal brauche, man kann aber auch alles per Dienst starten lassen oder sich irgendeinen Startknopf bauen.

Fragen? Dann fragen!

Ausfall bei Telekom SmartHome

Das Telekom SmartHome System hat seit gestern am Morgen Probleme. Die automatischen Regeln tun was sie sollen und lokal kann man sich ebenfalls noch mit der Box verbinden und fast wie gewohnt steuern. Online ist aber kein Stich zu machen. Ebenfalls die Anbindung mit anderen Onlineservices ist damit tot.

https://community.qivicon.de/questions/ausfall-im-qivicon-rechenzentrum-homebases-aktuell-nicht-online

Ausfällt und Probleme kann es immer mal geben. Vor allem dieses Qivicon / Telekom „Ding“ ist mäßig stabil, tat aber in den letzten Monaten recht brauchbar seinen Dienst. Ein Ausfall von nun knapp 24Stunden ist dennoch echt heftig. Ich kann mir nicht viele Dinge vorstellen bei denen es zu so einem langen Ausfallen kommen kann, vor allem das die Herren so ja keinen besonderen Peak haben dürften. Hier hat wohl jemand echt massiv verkackt, sofern nicht gerade jemand die Jungs mit einem DDoS „warm“ hält. Das hätte man sicher schon über andere Wege erfahren.

Ob da wohl jemand die Datenbank kaputt gemacht hat? Vielleicht ist hier ja was out of sync, das wieder zusammen zu bekommen kann schon mal echt lange dauern 🙂 Fast alles andere ist: An der falschen Stelle gespart oder halt epic fail.

Samstag am Morgen hat es angefangen, na da werden wohl jetzt ein paar Bereitschaftsadmins und Devs um ihr Wochenende gebracht. Na dann….

Postfix: E-Mail-Verschleierung gezielt einrichten

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ß!

Postfix-Fehlerantworten anpassen: So gehst du vor

Wieder wurde ich gefragt wie ich bei meinem Postfix den Error Reply für rejected 5xx E-Mails geändert habe. Nun ja, das habe ich überhaupt nicht.

Postfix hat seit vielen Jahren die Option: smtpd_reject_footer diese wurde in 2011 beim „Aufräumen“ umbenannt in: smtpd_reject_footer

Cleanup: smtpd_reject_contact_information is renamed to smtpd_reject_footer, because it can be used for non-contact information.

Beide Optionen sind anscheinend eher unbekannt. Was ich gut verstehen kann. Denn setzt man nun in seiner main.cf den smtpd_reject_footer wird diese zwar brav angehangen und taucht sogar beim Absender im Postfach auf, nur welcher Benutzer liest diese schon und folgt dann noch dem jeweiligen Hinweis? Bisher ist diese Rückmeldung meines Systems nur sehr wenigen überhaupt aufgefallen ;-P

Vor ~12 Jahren habe ich sie wohl zum ersten Mal gesetzt. Ich meine da auf die Adresse vom Postmaster verwiesen zu haben, damit die Nutzer sich dort hin melden können. Später hatte ich mal einen Link auf eine zweisprachige Hilfeseite bei mir und noch später etwas wie: „Das Problem ist zu 99% dein Mailserver, frag DEINEN Admin!“. Dieses war es bis heute, denn heute habe ich die erneute Frage zum Anlass genommen, dieses hier zu schreiben und natürlich direkt auf riot.im zu verlinken. Dann kann man mich direkt anschreiben. Sicher etwas freundlicher als: „geh weg du bist eh das Problem“ und einfacher als noch eine E-Mail an den Postmaster zu schreiben. Sicher werde ich nun durch diese Nachricht 1 oder 2 mal im Jahr angeschrieben, wenn es dieses überhaupt wird.

Achja, so sieht der Eintrag in der main.cf von Postfix aus:

root@smtp:/usr/local/etc/postfix # postconf smtpd_reject_footer
smtpd_reject_footer = For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com

Damit lässt sich nun dieses Ergebnis erzielen:

banane@bsd03:~ # telnet smtp.kernel-error.de 25
Trying 2a01:4f8:150:1095::25...
Connected to smtp.kernel-error.de.
Escape character is '^]'.
220 smtp.kernel-error.de ESMTP Postfix
helo asdf
250 smtp.kernel-error.de
mail from: <test@spam.de>
250 2.1.0 Ok
rcpt to: <spamlover@kernel-error.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: test
.test
.
554-5.7.1 Spam message rejected
554 5.7.1 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
Connection closed by foreign host.

Fragen? Dann wie immer bitte fragen…

Raspberry Pi verstärkt als Angriffsziel

In den einen oder anderen meiner Honeypots greifen in den letzten Monaten verstärkt Bots beim Versuch sich mit dem Benutzernamen PI anzumelden. Im November 2018 waren am SSH 13% der Loginversuche mit dem User pi. Für März 2019 sieht es so aus als wenn es etwas um 87/88% werden. Ganz früher waren es ja mal die User root oder test und so etwas… Inzwischen also pi, gut gut. So verstärkt ist nur etwas auffällig. Ist da ein Loch? Sind zu viele Anwender zu nachlässig bei der Zugangssicherung und die Dinger stehen wirklich so „nackt“ im Internet? Leider scheint mir das Letztere nicht sehr unwahrscheinlich :-/

Alles >= Pi3 hat ja schon eine ganz gute Rechenleistung. Hoffen wir einfach mal darauf, dass die Bots dieses nur zum Rechnen von Cryptogeld nutzen wollen und nicht zum Spammen oder noch schlimmer für Angriffe. Loginversuchszahlen größer 70% habe ich sonst oft nur kurz vor einem großen DDoS gesehen. Jemand andere Zahlen für mich?

Mar 25 06:20:21 pot06 sshd[93829]: Invalid user pi from xx.xx.xx.xx port 55312
Mar 25 06:20:21 pot06 sshd[93829]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55312 ssh2
Mar 25 06:20:21 pot06 sshd[93827]: Invalid user pi from xx.xx.xx.xx port 55310
Mar 25 06:20:21 pot06 sshd[93827]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55310 ssh2
Mar 25 06:20:21 pot06 sshd[93829]: Connection closed by invalid user pi xx.xx.xx.xx port 55312 [preauth]
Mar 25 06:20:21 pot06 sshd[93827]: Connection closed by invalid user pi xx.xx.xx.xx port 55310 [preauth]

Oh was ebenfalls sehr verdächtig ist: Die Quellen dieser Loginversuche kommt nicht wie sonst aus Indien, China usw… Sondern inzwischen ebenfalls sehr oft aus dem DACH-Raum. Nicht das hier dem Menschen besonders sicher und vorsichtig sind; nein es zeigt nur, dass die Angriffe wohl schon oft erfolgreich waren.


Kleines Update

Habe hier drei Rückmeldungen welche sich sehr ähnlich anhören 🙁 Alles aber aus der gleichen unprofessionellen Sicherheitsblase. Vielleicht kommt ja noch eine „unabhängige“ Meinung?!?

Da hat jemand SSLv3 bei Bechtle abgeschaltet….

Erinnert ihr euch noch an meine Onlinetool Empfehlung und den dort verwiesenen Mailserver der Domain bechtle.com/de? Auf meine Frage hin hat mir ja leider niemand richtig geantwortet, nicht mal der Postmaster 🙁 Aber inzwischen ist SSLv3 abgeschaltet!

Es hätte ja zumindest mal jemand etwas anders sagen können als: „Geh weg du bist privat, dafür haben wir hier so nen anderen…“ Aber naja… Nun gibt es am Mailserver von Bechtle zumindest kein SSLv3 mehr 😀 Ich stelle mir einfach weiterhin vor, dass es durch meinen Hinweiß abgeschaltet wurde.

In diesem Sinne…

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑