🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind

Denne artikel handler om, hvordan man opsætter en moderne mailserver.
Postfix + Dueslag. SPF + DKIM + rDNS. Med IPv6.
Med TSL-kryptering. Med understøttelse af flere domæner - del med et rigtigt SSL-certifikat.
Med antispambeskyttelse og en høj antispamvurdering fra andre mailservere.
Understøtter flere fysiske grænseflader.
Med OpenVPN, hvortil forbindelsen er via IPv4, og som giver IPv6.

Hvis du ikke ønsker at lære alle disse teknologier, men ønsker at sætte en sådan server op, så er denne artikel noget for dig.

Artiklen forsøger ikke at forklare alle detaljer. Forklaringen går til, hvad der ikke er konfigureret som standard eller er vigtigt fra forbrugerens synspunkt.

Motivationen til at oprette en mailserver har været en lang drøm for mig. Det lyder måske dumt, men IMHO, det er meget bedre end at drømme om en ny bil fra dit yndlingsmærke.

Der er to motiver for at opsætte IPv6. En it-specialist skal konstant lære nye teknologier for at overleve. Jeg vil gerne yde mit beskedne bidrag til kampen mod censur.

Motivationen for at opsætte OpenVPN er blot at få IPv6 til at fungere på den lokale maskine.
Motivationen for at opsætte flere fysiske grænseflader er, at jeg på min server har en grænseflade "langsom men ubegrænset" og en anden "hurtig men med en takst".

Motivationen for at opsætte Bind-indstillinger er, at min internetudbyder leverer en ustabil DNS-server, og google fejler også nogle gange. Jeg ønsker en stabil DNS-server til personlig brug.

Motivation til at skrive en artikel - Jeg skrev et udkast for 10 måneder siden, og jeg har allerede set på det to gange. Selvom forfatteren jævnligt har brug for det, er der stor sandsynlighed for, at andre også får brug for det.

Der er ingen universel løsning til en mailserver. Men jeg vil prøve at skrive noget i stil med "gør dette og så, når alt fungerer som det skal, smid de ekstra ting ud."

Virksomheden tech.ru har en Colocation-server. Det er muligt at sammenligne med OVH, Hetzner, AWS. For at løse dette problem vil samarbejde med tech.ru være meget mere effektivt.

Debian 9 er installeret på serveren.

Serveren har 2 grænseflader `eno1` og `eno2`. Den første er ubegrænset, og den anden er henholdsvis hurtig.

Der er 3 statiske IP-adresser, XX.XX.XX.X0 og XX.XX.XX.X1 og XX.XX.XX.X2 på 'eno1'-grænsefladen og XX.XX.XX.X5 på 'eno2'-grænsefladen .

Tilgængelig XXXX:XXXX:XXXX:XXXX::/64 en pulje af IPv6-adresser, der er tildelt til `eno1`-grænsefladen, og fra den blev XXXX:XXXX:XXXX:XXXX:1:2::/96 tildelt `eno2` på min anmodning.

Der er 3 domæner `domain1.com`, `domain2.com`, `domain3.com`. Der er et SSL-certifikat for `domain1.com` og `domain3.com`.

Jeg har en Google-konto, som jeg gerne vil knytte min postkasse til[e-mail beskyttet]` (modtagelse af mail og afsendelse af mail direkte fra gmail-grænsefladen).
Der skal være en postkasse`[e-mail beskyttet]`, en kopi af den e-mail, som jeg vil se i min gmail. Og det er sjældent, man kan sende noget på vegne af `[e-mail beskyttet]` via webgrænsefladen.

Der skal være en postkasse`[e-mail beskyttet]`, som Ivanov vil bruge fra sin iPhone.

Sendte e-mails skal overholde alle moderne krav til antispam.
Der skal være det højeste niveau af kryptering i offentlige netværk.
Der bør være IPv6-understøttelse til både afsendelse og modtagelse af breve.
Der burde være en SpamAssassin, der aldrig vil slette e-mails. Og den vil enten hoppe eller springe over eller sende til IMAP "Spam"-mappen.
SpamAssassin auto-learning skal konfigureres: hvis jeg flytter et brev til Spam-mappen, lærer det af dette; hvis jeg flytter et brev fra Spam-mappen, lærer det af dette. Resultaterne af SpamAssassin-træning bør have indflydelse på, om brevet ender i Spam-mappen.
PHP-scripts skal kunne sende mail på vegne af ethvert domæne på en given server.
Der bør være en openvpn-tjeneste, med mulighed for at bruge IPv6 på en klient, der ikke har IPv6.

Først skal du konfigurere grænseflader og routing, inklusive IPv6.
Derefter skal du konfigurere OpenVPN, som vil oprette forbindelse via IPv4 og give klienten en statisk ægte IPv6-adresse. Denne klient vil have adgang til alle IPv6-tjenester på serveren og adgang til alle IPv6-ressourcer på internettet.
Så skal du konfigurere Postfix til at sende breve + SPF + DKIM + rDNS og andre lignende småting.
Derefter skal du konfigurere Dovecot og konfigurere Multidomain.
Derefter skal du konfigurere SpamAssassin og konfigurere træning.
Til sidst skal du installere Bind.

============= Multi-interfaces ==============

For at konfigurere grænseflader skal du skrive dette i "/etc/network/interfaces".

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eno1
iface eno1 inet static
        address XX.XX.XX.X0/24
        gateway XX.XX.XX.1
        dns-nameservers 127.0.0.1 213.248.1.6
        post-up ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t
        post-up ip route add default via XX.XX.XX.1 table eno1t
        post-up ip rule add table eno1t from XX.XX.XX.X0
        post-up ip rule add table eno1t to XX.XX.XX.X0

auto eno1:1
iface eno1:1 inet static
address XX.XX.XX.X1
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X1
        post-up ip rule add table eno1t to XX.XX.XX.X1
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE

# The secondary network interface
allow-hotplug eno2
iface eno2 inet static
        address XX.XX.XX.X5
        netmask 255.255.255.0
        post-up   ip route add XX.XX.XX.0/24 dev eno2 src XX.XX.XX.X5 table eno2t
        post-up   ip route add default via XX.XX.XX.1 table eno2t
        post-up   ip rule add table eno2t from XX.XX.XX.X5
        post-up   ip rule add table eno2t to XX.XX.XX.X5
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t

iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE

# OpenVPN network
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Disse indstillinger kan anvendes på enhver server i tech.ru (med lidt koordinering med support), og det vil straks fungere, som det skal.

Hvis du har erfaring med at sætte lignende ting op for Hetzner, OVH, er det anderledes der. Sværere.

eno1 er navnet på netværkskort #1 (langsomt, men ubegrænset).
eno2 er navnet på netværkskort #2 (hurtigt, men med en takst).
tun0 er navnet på det virtuelle netværkskort fra OpenVPN.
XX.XX.XX.X0 - IPv4 #1 på eno1.
XX.XX.XX.X1 - IPv4 #2 på eno1.
XX.XX.XX.X2 - IPv4 #3 på eno1.
XX.XX.XX.X5 - IPv4 #1 på eno2.
XX.XX.XX.1 - IPv4-gateway.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 for hele serveren.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 for eno2, alt andet udefra går ind i eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6-gateway (det er værd at bemærke, at dette kan/bør gøres anderledes. Angiv IPv6-switchen).
dns-navneservere - 127.0.0.1 er angivet (fordi bind er installeret lokalt) og 213.248.1.6 (dette er fra tech.ru).

"tabel eno1t" og "tabel eno2t" - betydningen af disse ruteregler er, at trafik, der kommer ind gennem eno1 -> ville forlade den, og trafik, der kommer ind gennem eno2 -> ville forlade den. Og også forbindelser initieret af serveren ville gå gennem eno1.

ip route add default via XX.XX.XX.1 table eno1t

Med denne kommando specificerer vi, at enhver uforståelig trafik, der falder ind under en regel markeret "table eno1t" -> sendes til eno1-grænsefladen.

ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t

Med denne kommando specificerer vi, at al trafik initieret af serveren skal dirigeres til eno1-grænsefladen.

ip rule add table eno1t from XX.XX.XX.X0
ip rule add table eno1t to XX.XX.XX.X0

Med denne kommando sætter vi reglerne for afmærkning af trafik.

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

Denne blok specificerer en anden IPv4 for eno1-grænsefladen.

ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

Med denne kommando indstiller vi ruten fra OpenVPN-klienter til lokal IPv4 undtagen XX.XX.XX.X0.
Jeg forstår stadig ikke, hvorfor denne kommando er nok til alle IPv4.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1

Det er her, vi sætter adressen til selve grænsefladen. Serveren vil bruge den som en "udgående" adresse. Bliver ikke brugt på nogen måde igen.

Hvorfor er ":1:1::" så kompliceret? Så OpenVPN fungerer korrekt og kun til dette. Mere om dette senere.

Om emnet gateway - det er sådan det virker, og det er fint. Men den korrekte måde er her at angive IPv6 for switchen, som serveren er forbundet til.

Men af en eller anden grund holder IPv6 op med at virke, hvis jeg gør dette. Dette er sandsynligvis en slags tech.ru-problem.

ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE

Dette tilføjer en IPv6-adresse til grænsefladen. Hvis du har brug for hundrede adresser, betyder det hundrede linjer i denne fil.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
...
iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
...
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Jeg noterede adresserne og undernettene for alle grænseflader for at gøre det klart.
eno1 - skal være "/64" - fordi det her er hele vores pulje af adresser.
tun0 - undernettet skal være større end eno1. Ellers vil det ikke være muligt at konfigurere en IPv6-gateway til OpenVPN-klienter.
eno2 - undernettet skal være større end tun0. Ellers vil OpenVPN-klienter ikke kunne få adgang til lokale IPv6-adresser.
For klarhedens skyld valgte jeg et undernettrin på 16, men hvis du ønsker det, kan du endda udføre "1" trin.
Følgelig er 64+16 = 80 og 80+16 = 96.

For endnu større klarhed:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY er adresser, der skal tildeles til specifikke websteder eller tjenester på eno1-grænsefladen.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY er adresser, der skal tildeles til specifikke websteder eller tjenester på eno2-grænsefladen.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY er adresser, der skal tildeles OpenVPN-klienter eller bruges som OpenVPN-tjenesteadresser.

For at konfigurere netværket skal det være muligt at genstarte serveren.
IPv4-ændringer opfanges, når de udføres (sørg for at pakke det ind på skærmen - ellers vil denne kommando simpelthen nedbryde netværket på serveren):

/etc/init.d/networking restart

Tilføj til slutningen af filen "/etc/iproute2/rt_tables":

100 eno1t
101 eno2t

Uden dette kan du ikke bruge brugerdefinerede tabeller i filen "/etc/network/interfaces".
Numrene skal være unikke og mindre end 65535.

IPv6-ændringer kan nemt ændres uden at genstarte, men for at gøre dette skal du lære mindst tre kommandoer:

ip -6 addr ...
ip -6 route ...
ip -6 neigh ...

Indstilling af "/etc/sysctl.conf"

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward = 1

# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0

# For receiving ARP replies
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.arp_filter = 0

# For sending ARP
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0

# Enable IPv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

# IPv6 configuration
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_ra = 0

# For OpenVPN
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

# For nginx on boot
net.ipv6.ip_nonlocal_bind = 1

Dette er min servers "sysctl" indstillinger. Lad mig påpege noget vigtigt.

net.ipv4.ip_forward = 1

Uden dette fungerer OpenVPN slet ikke.

net.ipv6.ip_nonlocal_bind = 1

Enhver, der forsøger at binde IPv6 (for eksempel nginx) umiddelbart efter, at grænsefladen er oppe, vil modtage en fejl. At denne adresse ikke er tilgængelig.

For at undgå en sådan situation foretages en sådan indstilling.

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

Uden disse IPv6-indstillinger går trafik fra OpenVPN-klienten ikke ud i verden.

Andre indstillinger er enten ikke relevante, eller jeg kan ikke huske, hvad de er til.
Men for en sikkerheds skyld lader jeg det være "som det er".

For at ændringer til denne fil kan hentes uden at genstarte serveren, skal du køre kommandoen:

sysctl -p

Flere detaljer om "bord"-regler: habr.com/post/108690

============= OpenVPN ==============

OpenVPN IPv4 virker ikke uden iptables.

Mine iptables er sådan her for VPN:

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
##iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

YY.YY.YY.YY er min statiske IPv4-adresse på den lokale maskine.
10.8.0.0/24 - IPv4 openvpn netværk. IPv4-adresser til openvpn-klienter.
Konsistensen af reglerne er vigtig.

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
...
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

Dette er en begrænsning, så kun jeg kan bruge OpenVPN fra min statiske IP.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
  -- или --
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

For at videresende IPv4-pakker mellem OpenVPN-klienter og internettet, skal du registrere en af disse kommandoer.

For forskellige tilfælde er en af mulighederne ikke egnet.
Begge kommandoer passer til mit tilfælde.
Efter at have læst dokumentationen valgte jeg den første mulighed, fordi den bruger mindre CPU.

For at alle iptables-indstillinger kan hentes efter genstart, skal du gemme dem et sted.

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Sådanne navne blev ikke valgt tilfældigt. De bruges af pakken "iptables-persistent".

apt-get install iptables-persistent

Installation af den primære OpenVPN-pakke:

apt-get install openvpn easy-rsa

Lad os oprette en skabelon til certifikater (erstat dine værdier):

make-cadir ~/openvpn-ca
cd ~/openvpn-ca
ln -s openssl-1.0.0.cnf openssl.cnf

Lad os redigere indstillingerne for certifikatskabelonen:

mcedit vars

...
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="[email protected]"
export KEY_OU="VPN"

# X509 Subject Field
export KEY_NAME="server"
...

Opret et servercertifikat:

cd ~/openvpn-ca
source vars
./clean-all
./build-ca
./build-key-server server
./build-dh
openvpn --genkey --secret keys/ta.key

Lad os forberede evnen til at oprette de endelige "client-name.opvn" filer:

mkdir -p ~/client-configs/files
chmod 700 ~/client-configs/files
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf
mcedit ~/client-configs/base.conf

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

# Address/Port of VPN server
remote XX.XX.XX.X0 1194

# Don't bind to local port/address
nobind

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Remote peer must have a signed certificate
remote-cert-tls server
ns-cert-type server

# Enable compression
comp-lzo

# Custom
ns-cert-type server
tls-auth ta.key 1
cipher DES-EDE3-CBC

Lad os forberede et script, der vil flette alle filer til en enkelt opvn-fil.

mcedit ~/client-configs/make_config.sh
chmod 700 ~/client-configs/make_config.sh

#!/bin/bash

# First argument: Client identifier

KEY_DIR=~/openvpn-ca/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf

cat ${BASE_CONFIG} 
    <(echo -e '<ca>') 
    ${KEY_DIR}/ca.crt 
    <(echo -e '</ca>n<cert>') 
    ${KEY_DIR}/.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/.ovpn

Oprettelse af den første OpenVPN-klient:

cd ~/openvpn-ca
source vars
./build-key client-name
cd ~/client-configs
./make_config.sh client-name

Filen "~/client-configs/files/client-name.ovpn" sendes til klientens enhed.

For iOS-klienter skal du gøre følgende trick:
Indholdet af "tls-auth"-tagget skal være uden kommentarer.
Og sæt også "key-direction 1" umiddelbart før tagget "tls-auth".

Lad os konfigurere OpenVPN-serverkonfigurationen:

cd ~/openvpn-ca/keys
cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn
gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | tee /etc/openvpn/server.conf
mcedit /etc/openvpn/server.conf

# Listen port
port 1194

# Protocol
proto tcp-server

# IP tunnel
dev tun0
tun-ipv6
push tun-ipv6

# Master certificate
ca ca.crt

# Server certificate
cert server.crt

# Server private key
key server.key

# Diffie-Hellman parameters
dh dh2048.pem

# Allow clients to communicate with each other
client-to-client

# Client config dir
client-config-dir /etc/openvpn/ccd

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

# Server mode and client subnets
server 10.8.0.0 255.255.255.0
server-ipv6 XXXX:XXXX:XXXX:XXXX:1:3::/80
topology subnet

# IPv6 routes
push "route-ipv6 XXXX:XXXX:XXXX:XXXX::/64"
push "route-ipv6 2000::/3"

# DNS (for Windows)
# These are OpenDNS
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Configure all clients to redirect their default network gateway through the VPN
push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway ipv6" #For iOS

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Ping every 10s. Timeout of 120s.
keepalive 10 120

# Enable compression
comp-lzo

# User and group
user vpn
group vpn

# Log a short status
status openvpn-status.log

# Logging verbosity
##verb 4

# Custom config
tls-auth ta.key 0
cipher DES-EDE3-CBC

Dette er nødvendigt for at indstille en statisk adresse for hver klient (ikke nødvendigt, men jeg bruger det):

# Client config dir
client-config-dir /etc/openvpn/ccd

Den sværeste og vigtigste detalje.

Desværre ved OpenVPN endnu ikke, hvordan man selvstændigt konfigurerer en IPv6-gateway til klienter.
Du skal "manuelt" videresende dette for hver klient.

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

Filen "/etc/openvpn/server-clientconnect.sh":

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
        echo $ipv6
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Create proxy rule
/sbin/ip -6 neigh add proxy $ipv6 dev eno1

Filen "/etc/openvpn/server-clientdisconnect.sh":

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Delete proxy rule
/sbin/ip -6 neigh del proxy $ipv6 dev eno1

Begge scripts bruger filen "/etc/openvpn/variables":

# Subnet
prefix=XXXX:XXXX:XXXX:XXXX:2:
# netmask
prefixlen=112

Jeg har svært ved at huske, hvorfor det er skrevet sådan.

Nu ser netmaske = 112 mærkeligt ud (det burde være 96 lige der).
Og præfikset er mærkeligt, det matcher ikke tun0-netværket.
Men okay, jeg lader det være som det er.

cipher DES-EDE3-CBC

Dette er ikke for alle - jeg valgte denne metode til at kryptere forbindelsen.

Lær mere om opsætning af OpenVPN IPv4.

Lær mere om opsætning af OpenVPN IPv6.

============= Postfix ==============

Installation af hovedpakken:

apt-get install postfix

Når du installerer, skal du vælge "internetside".

Mit "/etc/postfix/main.cf" ser sådan ud:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key
smtpd_use_tls=yes
smtpd_tls_auth_only = yes
smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

smtp_tls_security_level = may
smtp_tls_ciphers = export
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_loglevel = 1

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = domain1.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = domain1.com
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

internal_mail_filter_classes = bounce

# Storage type
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

# SMTP-Auth settings
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        #reject_invalid_hostname,
        #reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        check_policy_service unix:private/policyd-spf

smtpd_helo_restrictions =
        #reject_invalid_helo_hostname,
        #reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_non_fqdn_helo_hostname,
        permit

# SPF
policyd-spf_time_limit = 3600

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

# IP address per domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Lad os se på detaljerne i denne konfiguration.

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key

Ifølge beboere i Khabrovsk indeholder denne blok "misinformation og forkerte teser."Kun 8 år efter starten af min karriere begyndte jeg at forstå, hvordan SSL fungerer.

Derfor vil jeg tage mig den frihed at beskrive, hvordan man bruger SSL (uden at besvare spørgsmålene "Hvordan virker det?" og "Hvorfor virker det?").

Grundlaget for moderne kryptering er oprettelsen af et nøglepar (to meget lange strenge af tegn).

Den ene "nøgle" er privat, den anden nøgle er "offentlig". Vi holder den private nøgle meget omhyggeligt hemmelig. Vi distribuerer den offentlige nøgle til alle.

Ved at bruge en offentlig nøgle kan du kryptere en tekststreng, så kun ejeren af den private nøgle kan dekryptere den.
Nå, det er hele grundlaget for teknologien.

Trin #1 - https-websteder.
Når du tilgår et websted, lærer browseren fra webserveren, at webstedet er https og anmoder derfor om en offentlig nøgle.
Webserveren giver den offentlige nøgle. Browseren bruger den offentlige nøgle til at kryptere http-anmodningen og sende den.
Indholdet af en http-anmodning kan kun læses af dem, der har den private nøgle, det vil sige kun den server, som anmodningen sendes til.
Http-anmodning indeholder mindst en URI. Derfor, hvis et land forsøger at begrænse adgangen ikke til hele webstedet, men til en bestemt side, så er dette umuligt at gøre for https-websteder.

Trin #2 - krypteret svar.
Webserveren giver et svar, der nemt kan aflæses på farten.
Løsningen er ekstremt enkel - browseren genererer lokalt det samme private-offentlige nøglepar for hver https-side.
Og sammen med anmodningen om webstedets offentlige nøgle sender den sin lokale offentlige nøgle.
Webserveren husker den, og når den sender http-svar, krypterer den med den offentlige nøgle for en specifik klient.
Nu kan http-svar kun dekrypteres af ejeren af klientens browser private nøgle (det vil sige klienten selv).

Trin nr. 3 - etablering af en sikker forbindelse via en offentlig kanal.
Der er en sårbarhed i eksempel nr. 2 - intet forhindrer velvillige i at opsnappe en http-anmodning og redigere information om den offentlige nøgle.
Formidleren vil således tydeligt se alt indholdet af sendte og modtagne beskeder, indtil kommunikationskanalen ændres.
Det er ekstremt simpelt at håndtere dette - send blot browserens offentlige nøgle som en besked krypteret med webserverens offentlige nøgle.
Webserveren sender derefter først et svar som "din offentlige nøgle er sådan" og krypterer denne besked med den samme offentlige nøgle.
Browseren ser på svaret - hvis beskeden "din offentlige nøgle er sådan" modtages - så er dette en 100% garanti for, at denne kommunikationskanal er sikker.
Hvor sikkert er det?
Selve oprettelsen af en sådan sikker kommunikationskanal sker med en hastighed på ping*2. For eksempel 20ms.
Angriberen skal have en af parternes private nøgle på forhånd. Eller find en privat nøgle på et par millisekunder.
Hacking af en moderne privat nøgle vil tage årtier på en supercomputer.

Trin #4 - offentlig database med offentlige nøgler.
Naturligvis er der i hele denne historie en mulighed for en angriber at sidde på kommunikationskanalen mellem klienten og serveren.
Klienten kan foregive at være serveren, og serveren kan foregive at være klienten. Og efterlign et par nøgler i begge retninger.
Så vil angriberen se al trafikken og vil være i stand til at "redigere" trafikken.
For eksempel skal du ændre adressen, hvortil penge skal sendes, eller kopiere adgangskoden fra netbank eller blokere "stødende" indhold.
For at bekæmpe sådanne angribere kom de med en offentlig database med offentlige nøgler for hvert https-sted.
Hver browser "ved" om eksistensen af omkring 200 sådanne databaser. Dette kommer forudinstalleret i alle browsere.
"Viden" understøttes af en offentlig nøgle fra hvert certifikat. Det vil sige, at forbindelsen til hver specifik certificeringsmyndighed ikke kan forfalskes.

Nu er der en enkel forståelse af, hvordan man bruger SSL til https.
Hvis du bruger din hjerne, vil det blive tydeligt, hvordan specialtjenesterne kan hacke noget i denne struktur. Men det vil koste dem uhyrlige anstrengelser.
Og organisationer mindre end NSA eller CIA - det er næsten umuligt at hacke det eksisterende niveau af beskyttelse, selv for VIP'er.

Jeg vil også tilføje om ssh-forbindelser. Der er ingen offentlige nøgler der, så hvad kan du gøre? Problemet løses på to måder.
Mulighed ssh-by-password:
Under den første forbindelse skal ssh-klienten advare om, at vi har en ny offentlig nøgle fra ssh-serveren.
Og under yderligere forbindelser, hvis advarslen "ny offentlig nøgle fra ssh-serveren" vises, vil det betyde, at de forsøger at aflytte dig.
Eller du blev aflyttet på din første forbindelse, men nu kommunikerer du med serveren uden mellemled.
Faktisk, på grund af det faktum, at aflytning afsløres nemt, hurtigt og ubesværet, bruges dette angreb kun i særlige tilfælde for en specifik klient.

Mulighed ssh-for-key:
Vi tager et flashdrev, skriver den private nøgle til ssh-serveren på den (der er vilkår og mange vigtige nuancer til dette, men jeg skriver et uddannelsesprogram, ikke brugsanvisninger).
Vi efterlader den offentlige nøgle på maskinen, hvor ssh-klienten vil være, og vi holder den også hemmelig.
Vi bringer flashdrevet til serveren, indsætter det, kopierer den private nøgle og brænder flashdrevet og spreder asken for vinden (eller i det mindste formater det med nuller).
Det er alt - efter sådan en operation vil det være umuligt at hacke sådan en ssh-forbindelse. Selvfølgelig vil det om 10 år være muligt at se trafik på en supercomputer - men det er en anden historie.

Jeg undskylder for offtopic.

Så nu hvor teorien er kendt. Jeg vil fortælle dig om strømmen ved at oprette et SSL-certifikat.

Ved at bruge "openssl genrsa" opretter vi en privat nøgle og "blanks" for den offentlige nøgle.
Vi sender "blanks" til et tredjepartsfirma, hvortil vi betaler cirka $9 for det enkleste certifikat.

Efter et par timer modtager vi vores "offentlige" nøgle og et sæt af flere offentlige nøgler fra denne tredjepartsvirksomhed.

Hvorfor skal en tredjepartsvirksomhed betale for registreringen af min offentlige nøgle er et separat spørgsmål, vi vil ikke overveje det her.

Nu er det klart, hvad meningen med inskriptionen er:

smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key

Mappen "/etc/ssl" indeholder alle filer til ssl-problemer.
domæne1.com - domænenavn.
2018 er nøgleskabelsens år.
"nøgle" - betegnelse for, at filen er en privat nøgle.

Og betydningen af denne fil:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domæne1.com - domænenavn.
2018 er nøgleskabelsens år.
kædet - betegnelse, at der er en kæde af offentlige nøgler (den første er vores offentlige nøgle, og resten er, hvad der kom fra firmaet, der udstedte den offentlige nøgle).
crt - betegnelse for, at der er et færdigt certifikat (offentlig nøgle med tekniske forklaringer).

smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

Denne indstilling bruges ikke i dette tilfælde, men er skrevet som et eksempel.

Fordi en fejl i denne parameter vil føre til, at spam sendes fra din server (uden din vilje).

Så bevis for alle, at du ikke er skyldig.

recipient_delimiter = +

Mange mennesker ved det måske ikke, men dette er et standardtegn til rangering af e-mails, og det understøttes af de fleste moderne mailservere.

For eksempel, hvis du har en postkasse "[e-mail beskyttet]"prøv at sende til"[e-mail beskyttet]"- se hvad der kommer ud af det.

inet_protocols = ipv4

Dette kan være forvirrende.

Men sådan er det ikke bare. Hvert nyt domæne er som standard kun IPv4, så slår jeg IPv6 til for hvert enkelt domæne.

virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Her angiver vi, at al indgående post går til svaleslag.
Og reglerne for domæne, postkasse, alias - kig i databasen.

/etc/postfix/mysql-virtual-mailbox-domains.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_domains WHERE name='%s'

/etc/postfix/mysql-virtual-mailbox-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_users WHERE email='%s'

/etc/postfix/mysql-virtual-alias-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT destination FROM virtual_aliases WHERE source='%s'

# SMTP-Auth settings
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

Nu ved postfix, at post kun kan accepteres til videre afsendelse efter autorisation med svaleslag.

Jeg forstår virkelig ikke, hvorfor dette er duplikeret her. Vi har allerede specificeret alt, hvad der er nødvendigt i "virtuel_transport".

Men postfix-systemet er meget gammelt - sandsynligvis er det et tilbageslag fra gamle dage.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Dette kan konfigureres forskelligt for hver mailserver.

Jeg har 3 mailservere til min rådighed, og disse indstillinger er meget forskellige på grund af forskellige brugskrav.

Du skal konfigurere det omhyggeligt - ellers vil spam strømme ind til dig, eller endnu værre - spam vil strømme ud fra dig.

# SPF
policyd-spf_time_limit = 3600

Opsætning af et plugin relateret til kontrol af SPF for indgående breve.

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

Indstillingen er, at vi skal levere en DKIM-signatur med alle udgående e-mails.

# IP address per domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Dette er en nøgledetalje i brevdirigering, når du sender breve fra PHP-scripts.

Filen "/etc/postfix/sdd_transport.pcre":

/^[email protected]$/ domain1:
/^[email protected]$/ domain2:
/^[email protected]$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

Til venstre er regulære udtryk. Til højre er en etiket, der markerer bogstavet.
Postfix i overensstemmelse med etiketten - vil tage højde for et par flere konfigurationslinjer for et bestemt bogstav.

Hvordan postfix vil blive rekonfigureret til et bestemt bogstav, vil blive angivet i "master.cf".

Linje 4, 5, 6 er de vigtigste. På vegne af hvilket domæne vi sender brevet, sætter vi denne etiket.
Men feltet "fra" er ikke altid angivet i PHP-scripts i den gamle kode. Så kommer brugernavnet til undsætning.

Artiklen er allerede omfattende - jeg ønsker ikke at blive distraheret af at konfigurere nginx+fpm.

Kort sagt, for hvert websted sætter vi sin egen linux-bruger-ejer. Og dermed din fpm-pool.

Fpm-pool bruger enhver version af php (det er fantastisk, når du på den samme server kan bruge forskellige versioner af php og endda forskellige php.ini til nabosider uden problemer).

Så en specifik linux-bruger "www-domain2" har et websted domain2.com. Dette websted har en kode til at sende e-mails uden at angive fra-feltet.

Så selv i dette tilfælde vil brevene blive sendt korrekt og vil aldrig ende i spam.

Mit "/etc/postfix/master.cf" ser sådan ud:

...
smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
...
policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}
...
domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

domain2  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X5
   -o smtp_helo_name=domain2.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:2:1:1
   -o syslog_name=postfix-domain2

domain3  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X2
   -o smtp_helo_name=domain3
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:5:1
   -o syslog_name=postfix-domain3

Filen leveres ikke i sin helhed - den er allerede meget stor.
Jeg noterede kun, hvad der blev ændret.

smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Disse er indstillinger relateret til spamassasin, mere om det senere.

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Vi giver dig mulighed for at oprette forbindelse til mailserveren via port 587.
For at gøre dette skal du logge ind.

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

Aktiver SPF-tjek.

apt-get install postfix-policyd-spf-python

Lad os installere pakken til SPF-tjek ovenfor.

domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

Og dette er det mest interessante. Dette er muligheden for at sende breve til et bestemt domæne fra en specifik IPv4/IPv6-adresse.

Dette gøres af hensyn til rDNS. rDNS er processen med at modtage en streng efter IP-adresse.
Og til mail bruges denne funktion til at bekræfte, at heloen nøjagtigt matcher rDNS på den adresse, hvorfra e-mailen blev sendt.

Hvis heloen ikke matcher det e-mail-domæne, som brevet blev sendt på vegne af, tildeles spampoint.

Helo matcher ikke rDNS - der tildeles mange spampoint.
Derfor skal hvert domæne have sin egen IP-adresse.
For OVH - i konsollen er det muligt at angive rDNS.
For tech.ru - problemet er løst gennem support.
For AWS er problemet løst gennem support.
"inet_protocols" og "smtp_bind_address6" - vi aktiverer IPv6-understøttelse.
For IPv6 skal du også registrere rDNS.
"syslog_name" - og dette er for at lette læsning af logs.

Køb certifikater Jeg anbefaler her.

Opsætning af postfix+dovecot link her.

Indstilling af SPF.

============= Dueslag ==============

apt-get install dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-mysql dovecot-antispam

Opsætning af mysql, installation af selve pakkerne.

Filen "/etc/dovecot/conf.d/10-auth.conf"

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autorisation er kun krypteret.

Filen "/etc/dovecot/conf.d/10-mail.conf"

mail_location = maildir:/var/mail/vhosts/%d/%n

Her angiver vi opbevaringsstedet for bogstaverne.

Jeg vil have dem til at blive gemt i filer og grupperet efter domæne.

Filen "/etc/dovecot/conf.d/10-master.conf"

service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 993
    ssl = yes
  }
}
service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 995
    ssl = yes
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}
service imap {
}
service pop3 {
}
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }

  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  user = dovecot
}
service auth-worker {
  user = vmail
}
service dict {
  unix_listener dict {
  }
}

Dette er den primære dueslagskonfigurationsfil.
Her deaktiverer vi usikrede forbindelser.
Og muliggør sikre forbindelser.

Filen "/etc/dovecot/conf.d/10-ssl.conf"

ssl = required
ssl_cert = </etc/nginx/ssl/domain1.com.2018.chained.crt
ssl_key = </etc/nginx/ssl/domain1.com.2018.key
local XX.XX.XX.X5 {
  ssl_cert = </etc/nginx/ssl/domain2.com.2018.chained.crt
  ssl_key =  </etc/nginx/ssl/domain2.com.2018.key
}

Opsætning af ssl. Vi angiver, at ssl er påkrævet.
Og selve certifikatet. Og en vigtig detalje er det "lokale" direktiv. Angiver hvilket SSL-certifikat der skal bruges, når der oprettes forbindelse til hvilken lokal IPv4.

I øvrigt er IPv6 ikke konfigureret her, jeg retter denne udeladelse senere.
XX.XX.XX.X5 (domæne2) - intet certifikat. For at forbinde klienter skal du angive domain1.com.
XX.XX.XX.X2 (domæne3) - der er et certifikat, du kan angive domain1.com eller domain3.com for at forbinde klienter.

Filen "/etc/dovecot/conf.d/15-lda.conf"

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Dette vil være nødvendigt for spamassassin i fremtiden.

Filen "/etc/dovecot/conf.d/20-imap.conf"

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Dette er et antispam-plugin. Nødvendig til træning af spamassasin på tidspunktet for overførsel til/fra "Spam"-mappen.

Filen "/etc/dovecot/conf.d/20-pop3.conf"

protocol pop3 {
}

Der er bare sådan en fil.

Filen "/etc/dovecot/conf.d/20-lmtp.conf"

protocol lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = [email protected]
}

Opsætning af lmtp.

Filen "/etc/dovecot/conf.d/90-antispam.conf"

plugin {
  antispam_backend = pipe
  antispam_trash = Trash;trash
  antispam_spam = Junk;Spam;SPAM
  antispam_pipe_program_spam_arg = --spam
  antispam_pipe_program_notspam_arg = --ham
  antispam_pipe_program = /usr/bin/sa-learn
  antispam_pipe_program_args = --username=%Lu
}

Spamassasin træningsindstillinger på tidspunktet for overførsel til/fra Spam-mappen.

Filen "/etc/dovecot/conf.d/90-sieve.conf"

plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
  sieve_after = /var/lib/dovecot/sieve/default.sieve
}

En fil, der specificerer, hvad der skal gøres med indgående breve.

Filen "/var/lib/dovecot/sieve/default.sieve"

require ["fileinto", "mailbox"];

if header :contains "X-Spam-Flag" "YES" {
        fileinto :create "Spam";
}

Du skal kompilere filen: "sievec default.sieve".

Filen "/etc/dovecot/conf.d/auth-sql.conf.ext"

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

Angivelse af sql-filer til godkendelse.
Og selve filen bruges som en godkendelsesmetode.

Filen "/etc/dovecot/dovecot-sql.conf.ext"

driver = mysql
connect = host=127.0.0.1 dbname=servermail user=usermail password=password
default_pass_scheme = SHA512-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

Dette svarer til lignende indstillinger for postfix.

Filen "/etc/dovecot/dovecot.conf"

protocols = imap lmtp pop3
listen = *, ::
dict {
}
!include conf.d/*.conf
!include_try local.conf

Hovedkonfigurationsfil.
Det vigtige er, at vi her angiver - tilføj protokoller.

============= SpamAssassin ==============

apt-get install spamassassin spamc

Lad os installere pakkerne.

adduser spamd --disabled-login

Lad os tilføje en bruger på hvis vegne.

systemctl enable spamassassin.service

Vi aktiverer automatisk indlæsning af spamassassin-service ved indlæsning.

Filen "/etc/default/spamassassin":

CRON=1

Ved at aktivere automatisk opdatering af regler "som standard".

Filen "/etc/spamassassin/local.cf":

report_safe 0

use_bayes          1
bayes_auto_learn   1
bayes_auto_expire  1
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn      DBI:mysql:sa:localhost:3306
bayes_sql_username sa
bayes_sql_password password

Du skal oprette en database "sa" i mysql med brugeren "sa" med adgangskoden "password" (erstat med noget passende).

report_safe - dette vil sende en rapport om spam-e-mail i stedet for et brev.
use_bayes er spamassassin maskinlæringsindstillinger.

De resterende spamassassin-indstillinger blev brugt tidligere i artiklen.

Generel indstilling "spamassassin".
Om at flytte nye spam-e-mails til IMAP-mappen "Spam"..
Om en simpel kombination af Dovecot + SpamAssassin.
Jeg anbefaler at læse spamassasin-læringsteorien, når du flytter bogstaver i imap-mapper (og jeg anbefaler ikke at bruge den).

============= Appel til fællesskabet ==============

Jeg vil også gerne smide en idé ud i fællesskabet om, hvordan man kan øge sikkerhedsniveauet for videresendte breve. Da jeg er så dybt fordybet i emnet mail.

Så brugeren kan oprette et par nøgler på sin klient (outlook, thunderbird, browser-plugin, ...). Offentlige og private. Offentlig - send til DNS. Privat - spar på klienten. Mailservere ville være i stand til at bruge en offentlig nøgle til at sende til en bestemt modtager.

Og for at beskytte mod spam med sådanne breve (ja, mailserveren vil ikke være i stand til at se indholdet) - skal du indføre 3 regler:

Obligatorisk ægte DKIM-signatur, obligatorisk SPF, obligatorisk rDNS.
Et neuralt netværk om emnet antispam træning + en database til det på klientsiden.
Krypteringsalgoritmen skal være sådan, at den afsendende side skal bruge 100 gange mere CPU-kraft på kryptering end den modtagende side.

Ud over offentlige breve skal du udvikle et standardforslagsbrev "for at begynde sikker korrespondance." En af brugerne (postkasse) sender et brev med en vedhæftet fil til en anden postkasse. Brevet indeholder et tekstforslag om at starte en sikker kommunikationskanal til korrespondance og den offentlige nøgle for ejeren af postkassen (med en privat nøgle på klientsiden).

Du kan endda lave et par nøgler specifikt til hver korrespondance. Modtagerbrugeren kan acceptere dette tilbud og sende sin offentlige nøgle (også lavet specifikt til denne korrespondance). Dernæst sender den første bruger et servicekontrolbrev (krypteret med den anden brugers offentlige nøgle) - ved modtagelse af hvilket den anden bruger kan betragte den dannede kommunikationskanal som pålidelig. Dernæst sender den anden bruger et kontrolbrev - og så kan den første bruger også betragte den dannede kanal som sikker.

For at bekæmpe aflytning af nøgler på vejen skal protokollen give mulighed for at transmittere mindst én offentlig nøgle ved hjælp af et flashdrev.

Og det vigtigste er, at det hele fungerer (spørgsmålet er "hvem skal betale for det?"):
Indtast postbeviser, der starter ved $10 for 3 år. Hvilket vil tillade afsenderen at angive i dns'en, at "mine offentlige nøgler er derovre." Og de vil give dig mulighed for at starte en sikker forbindelse. Samtidig er det gratis at acceptere sådanne forbindelser.
Gmail tjener endelig penge på sine brugere. For $10 pr. 3 år - retten til at oprette sikre korrespondancekanaler.

============= Konklusion ==============

For at teste hele artiklen skulle jeg leje en dedikeret server i en måned og købe et domæne med et SSL-certifikat.

Men livsbetingelserne udviklede sig, så dette problem trak ud i 2 måneder.
Og så, da jeg havde fri igen, besluttede jeg at udgive artiklen som den er, frem for at risikere, at udgivelsen ville trække ud i endnu et år.

Hvis der er ret mange spørgsmål som "men det er ikke beskrevet tilstrækkeligt detaljeret", så vil der nok være styrke til at tage en dedikeret server med et nyt domæne og et nyt SSL-certifikat og beskrive det endnu mere detaljeret og, de fleste vigtigere, identificere alle de manglende vigtige detaljer.

Jeg vil også gerne have feedback på ideer om postbeviser. Hvis du kan lide ideen, vil jeg prøve at finde styrken til at skrive et udkast til rfc.

Når du kopierer store dele af en artikel, skal du angive et link til denne artikel.
Når du oversætter til et andet sprog, skal du angive et link til denne artikel.
Jeg vil selv prøve at oversætte det til engelsk og efterlade krydshenvisninger.

Kilde: www.habr.com

Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind