feed-image -=Kernel-Error=- BlogFeed

Keine E-Mail mehr ohne TLS Transportverschlüsselung

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 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 :-)

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.

  • Screenshot_20190330-223447
  • Screenshot_20190331-093955
  • Screenshot_20190331-122930

Simple Image Gallery Extended

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

FreeBSD als IPsec L2TP Client an einem Microsoft Windows Routing und RAS VPN 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.FreeBSD IPsec L2TP Client to Microsoft Windows Routing RAS Server

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!

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