ProHoster > Blogg > Administrasjon > Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind

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

Denne artikkelen handler om hvordan du setter opp en moderne e-postserver.
Postfix + Dovecot. SPF + DKIM + rDNS. Med IPv6.
Med TSL-kryptering. Med stþtte for flere domener — del med ekte SSL-sertifikat.
Med antispam-beskyttelse og hĂžy antispam-rating hos andre e-postservere.
Med stĂžtte for flere fysiske grensesnitt.
Med OpenVPN, som kobles til via IPv4, og som gir IPv6.

Hvis du ikke Ăžnsker Ă„ lĂŠre deg disse teknologiene, men Ăžnsker Ă„ sette opp en slik server — da er denne artikkelen for deg.

Artikkelen mangler forsÞk pÄ Ä forklare hver detalj. Forklaringen gÄr til det som er per definisjon ikke standard eller viktig sett fra forbrukerens perspektiv.

Motivasjonen for Ă„ sette opp en e-postserver er min gamle drĂžm. Kanskje det hĂžres dumt ut, men IMO, det er mye bedre enn Ă„ drĂžmme om en ny bil av favorittmerket.

Motivasjonen for Ä sette opp IPv6 er todelt. En IT-spesialist mÄ konstant lÊre nye teknologier for Ä overleve. Jeg Þnsker Ä bidra med mitt beskjeden innsats i kampen mot sensur.

Motivasjonen for Ä sette opp OpenVPN er bare for at IPv6 skal fungere pÄ den lokale maskinen.
Motivasjonen for Ă„ sette opp flere fysiske grensesnitt — jeg har en 'langsom, men ubegrenset' interface pĂ„ serveren min, og en annen 'rask, men med tariff'.

Motivasjonen for Ă„ sette opp Bind — min leverandĂžr tilbyr en ustabil DNS-server, og Google kan ogsĂ„ ha nedetid. Jeg Ăžnsker en stabil DNS-server for personlig bruk.

Motivasjonen for Ă„ skrive artikkelen — utkastet ble skrevet for 10 mĂ„neder siden, og jeg har allerede sett pĂ„ det to ganger. Hvis selv forfatteren trenger Ă„ sjekke det regelmessig — er det stor sjanse for at andre ogsĂ„ vil ha behov for det.

Det finnes ingen universell lĂžsning for e-postservere. Men jeg skal prĂžve Ă„ skrive 'gjĂžr det slik, og nĂ„r alt fungerer som det skal — kast det overflĂždige'.

Det er en Colocation-server hos tech.ru. Det er mulig Ă„ sammenligne med OVH, Hetzner, AWS. For Ă„ lĂžse denne oppgaven vil samarbeid med tech.ru vĂŠre mye mer effektivt.

Serveren kjĂžrer Debian 9.

Serveren har 2 grensesnitt `eno1` og `eno2`. Den fĂžrste er ubegrenset, og den andre er rask, henholdsvis.

Det er 3 statiske IP-adresser, XX.XX.XX.X0, XX.XX.XX.X1 og XX.XX.XX.X2 pÄ grensesnittet `eno1`, og XX.XX.XX.X5 pÄ grensesnittet `eno2`.

Det finnes et XXXX:XXXX:XXXX:XXXX::/64 IPv6-adresseomrÄde, som er tildelt til grensesnittet `eno1`, og fra dette har de etter min forespÞrsel tildelt XXXX:XXXX:XXXX:XXXX:1:2::/96 til `eno2`.

Det finnes 3 domener `domain1.com`, `domain2.com`, `domain3.com`. For `domain1.com` og `domain3.com` er det et SSL-sertifikat.

Det finnes en Google-konto som jeg Ăžnsker Ă„ knytte til e-postboksen `vasya.pupkin@domain1.com` (mottak og sending av e-post direkte fra Gmail-grensesnittet).
Det mÄ vÊre en e-postboks `support@domain2.com`, en kopi av e-posten fra den vil jeg se i Gmail. Og jeg skal sjelden ha mulighet til Ä sende noe fra `support@domain2.com` gjennom webgrensesnittet.

Det mÄ vÊre en e-postboks `ivanov@domain3.com`, som Ivanov vil bruke fra sin iPhone.

Sendte e-poster mÄ oppfylle alle moderne anti-spam krav.
Det mÄ vÊre det hÞyeste nivÄet av kryptering tilgjengelig i offentlige nettverk.
Det mÄ vÊre stÞtte for IPv6 bÄde for sending og mottak av e-poster.
SpamAssassin mÄ vÊre der, som aldri vil slette e-poster. Den vil enten returnere dem eller la dem gÄ eller sende dem til IMAP-mappen «Spam».
SpamAssassin mÄ vÊre konfigurert for automatisk opplÊring: hvis jeg flytter en e-post til «Spam»-mappen, skal den lÊre av dette; hvis jeg flytter en e-post fra «Spam»-mappen, skal den lÊre av det. Resultatene av SpamAssassin sin lÊring skal pÄvirke om e-posten havner i «Spam» mappen.
PHP-skript mÄ ha muligheten til Ä sende e-post pÄ vegne av hvilket som helst domene pÄ denne serveren.
Det mÄ vÊre en OpenVPN-tjeneste, med mulighet for Ä bruke IPv6 pÄ klienten som ikke har IPv6.

FÞrst mÄ du konfigurere grensesnittene og rutingen, inkludert IPv6.
Deretter mÄ OpenVPN konfigureres for Ä koble til via IPv4 og gi klienten en statisk, ekte IPv6-adresse. Denne klienten vil ha tilgang til alle IPv6-tjenester pÄ serveren og til alle IPv6-ressurser pÄ internett.
Deretter mÄ Postfix konfigureres for Ä sende e-poster + SPF + DKIM + rDNS og andre lignende smÄting.
Deretter mÄ Dovecot konfigureres og multidomene settes opp.
SÄ mÄ SpamAssassin konfigureres og treningen settes opp.
Til slutt installeres Bind.

============= Multi-grensesnitt =============

For Ä konfigurere grensesnittene mÄ du skrive dette inn 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 innstillingene kan brukes pÄ hvilken som helst server i tech.ru (med liten godkjenning fra stÞtte) og det vil fungere umiddelbart som det skal.

Hvis du har erfaring med Ă„ konfigurere lignende ting for Hetzner eller OVH – der er det annerledes. Vanskeligere.

eno1 er navnet pÄ nettverkskort #1 (langsom, men ubegrenset).
eno2 er navnet pÄ nettverkskort #2 (rask, men med tarifflimitt).
tun0 — dette er navnet pĂ„ det virtuelle nettverkskortet 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 annet kommer inn i eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 gateway (det er viktig Ă„ merke seg at dette kan/skal gjĂžres annerledes. Angi IPv6 for svitsjen).
dns-nameservers — angitt som 127.0.0.1 (fordi bind er installert lokalt) og 213.248.1.6 (dette er fra tech.ru).

«table eno1t» og «table eno2t» — meningen med denne route-rule er at trafikk som kommer inn gjennom eno1 -> skal gĂ„ ut gjennom den samme, og trafikk som kommer inn gjennom eno2 -> skal gĂ„ ut gjennom den samme. I tillegg skal forbindelser initiert av serveren gĂ„ ut gjennom eno1.

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

Med denne kommandoen angir vi at all ukjent trafikk som faller inn under noen regel merket med «table eno1t» -> skal sendes til grensesnittet eno1.

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

Med denne kommandoen angir vi at all trafikk initiert av serveren skal sendes til grensesnittet eno1.

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

Med denne kommandoen angir vi selve reglene for merking av trafikk.

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 blokken angir et annet IPv4 for grensesnittet eno1.

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

Med denne kommandoen angir vi ruten fra OpenVPN-kunder til lokale IPv4, unntatt XX.XX.XX.X0.
Hvorfor denne kommandoen er tilstrekkelig for alle IPv4 — jeg forstĂ„r fortsatt ikke.

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

Her angir vi adressen for selve grensesnittet. Serveren vil bruke den som «utgÄende» adresse. Den vil ikke bli brukt til annet.

Hvorfor er «:1:1::» angitt sÄ komplisert? For at OpenVPN skal fungere riktig, og kun for det. Mer om dette senere.

NĂ„r det kommer til gateway — det fungerer slik, og det er greit. Men riktig sett — her mĂ„ vi angi IPv6 for svitsjen som serveren er koblet til.

Men av en eller annen grunn slutter IPv6 Ä fungere hvis jeg gjÞr det pÄ denne mÄten. Kanskje det er noen sÊrheter fra tech.ru.

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

Dette er legging av IPv6-adresse pĂ„ grensesnittet. Hvis det er nĂždvendig med hundre adresser — sĂ„ betyr det hundre linjer i denne filen.

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 har merket adresser og subnett for alle grensesnitt, slik at det blir tydelig.
eno1 — mĂ„ vĂŠre «/64» — fordi dette er hele vĂ„r adressepool.
tun0 — subnettet mĂ„ nĂždvendigvis vĂŠre stĂžrre enn eno1. Ellers kan ikke IPv6-gatewayen for OpenVPN-kundene konfigureres.
eno2 — subnettet mĂ„ nĂždvendigvis vĂŠre stĂžrre enn tun0. Ellers vil ikke OpenVPN-kundene kunne fĂ„ tilgang til de lokale IPv6-adressene.
For klarhetens skyld valgte jeg subnettsteget 16, men hvis Þnskelig kan man til og med bruke «1» som steg.
SĂ„ledes 64+16 = 80, og 80+16 = 96.

For enda mer synlighet:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — dette er adressene som skal tildeles spesifikke nettsteder eller tjenester pĂ„ grensesnittet eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — dette er adressene som skal tildeles spesifikke nettsteder eller tjenester pĂ„ grensesnittet eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — dette er adressene som skal tildeles OpenVPN-kunder eller brukes som interne adresser for OpenVPN.

For Ă„ konfigurere nettverket — mĂ„ serveren kunne startes pĂ„ nytt.
IPv4-Ă€ndringar fanges opp nĂ„r man utfĂžrer (viktig Ă„ kjĂžre i screen — ellers vil denne kommandoen bare knekke nettverket pĂ„ serveren):

/etc/init.d/networking restart

Legg til pÄ slutten av filen «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Uten dette kan man ikke bruke tilpassede tabeller i filen «/etc/network/interfaces».
Tallene mÄ vÊre unike og mindre enn 65535.

IPv6-endringer kan gjÞres enkelt uten omstart, men for dette mÄ man lÊre seg minst tre kommandoer:

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

Konfigurasjon av «/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 «sysctl»-innstillingene for serveren min. Viktig Ä merke seg.

net.ipv4.ip_forward = 1

Uten dette vil OpenVPN ikke fungere pÄ noen mÄte.

net.ipv6.ip_nonlocal_bind = 1

Enhver som prĂžver Ă„ binde IPv6 (for eksempel nginx) umiddelbart etter at grensesnittet er blitt tildelt — vil fĂ„ en feil. At slike adresser ikke er tilgjengelige.

For Ä unngÄ en slik situasjon, er slik en innstilling laget.

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

Uten disse innstillingene kommer ikke IPv6-trafikk fra OpenVPN-kundene ut i verden.

Andre innstillinger er enten irrelevante eller jeg husker ikke hvorfor de er der.
Men bare for sikkerhets skyld lar jeg dem stÄ «som de er».

For at endringene i denne filen skal tre i kraft uten omstart av serveren — mĂ„ man utfĂžre kommandoen:

sysctl -p

Mer detaljer om «tabell»-regler: habr.com/post/108690

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

OpenVPN IPv4 fungerer ikke uten iptables.

Mine iptables ser slik ut 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 — dette er min statiske IPv4-adresse pĂ„ den lokale maskinen.
10.8.0.0/24 — IPv4-nettverket til OpenVPN. IPv4-adressene for OpenVPN-klientene.
RekkefÞlgen pÄ reglene er viktig.

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 begrensning slik at bare jeg, fra min statiske IP, kan bruke OpenVPN.

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

For Ä videresende IPv4-pakker mellom OpenVPN-klientene og internett, mÄ du bruke en av disse kommandoene.

For ulike tilfeller passer ikke en av alternativene.
For mitt tilfelle passer begge kommandoene.
Etter Ă„ ha lest dokumentasjonen, valgte jeg det fĂžrste alternativet fordi det bruker mindre CPU.

For at alle iptables-innstillingene skal bli tilgjengelige etter reboot, mÄ du lagre dem et sted.

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

Slik navn er valgt med vilje. Disse brukes av pakken «iptables-persistent».

apt-get install iptables-persistent

Installasjon av hovedpakken OpenVPN:

apt-get install openvpn easy-rsa

La oss konfigurere malen for sertifikatene (sett inn dine egne verdier):

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

La oss redigere innstillingene for sertifikatmalen:

mcedit vars

...
# Dette er standardverdiene for feltene
# som vil bli plassert i sertifikatet.
# Ikke la noen av disse feltene vĂŠre tomme.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Egen"
export KEY_EMAIL="admin@domain1.com"
export KEY_OU="VPN"

# X509-subjektfelt
export KEY_NAME="server"
...

Vi oppretter sertifikatet for serveren:

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

La oss forberede muligheten til Ä opprette 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

La oss forberede et skript som vil kombinere alle filene 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}/${1}.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/${1}.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/${1}.ovpn

Vi oppretter den fĂžrste OpenVPN-klienten:

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 enheten til klienten.

For iOS clients, you will need to perform a trick:
The content of the 'tls-auth' tag must be without comments.
And also place 'key-direction 1' right before the 'tls-auth' tag.

Let's configure the OpenVPN server:

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

This is needed to assign a static address to each client (not mandatory, but I use it):

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

The most complex and crucial detail.

Unfortunately, OpenVPN still cannot set up the IPv6 gateway for clients by itself.
It has to be 'manually' forwarded for each client.

# 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"

File '/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

File '/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

Both scripts use the file '/etc/openvpn/variables':

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

I can't remember why it's written like this.

It now looks strange netmask = 112 (should be 96 here).
And the prefix is strange, does not match the tun0 network.
But okay, I'll leave it 'as is'.

cipher DES-EDE3-CBC

It's a matter of taste — I chose this method of encryption for the connection.

More details on configuring OpenVPN for IPv4.

More details on configuring OpenVPN for IPv6.

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

Installing the main package:

apt-get install postfix

During installation, choose 'internet-site'.

My '/etc/postfix/main.cf' looks like this:

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

# Legg til .domain er MUA sin oppgave.
append_dot_mydomain = no

readme_directory = no

# Se http://www.postfix.org/COMPATIBILITY_README.html -- standard til 2 pÄ
# ferske installasjoner.
compatibility_level = 2

# TLS-parametre
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

# Lagringstype
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 innstillinger
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-adresse per domene
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

La oss se pÄ detaljene i denne konfigurasjonen.

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

IfÞlge Habr-brukere inneholder dette blokket `desinformasjon og feilaktige pÄstander`.Bare etter Ä ha jobber i 8 Är i karrieren min begynte jeg Ä forstÄ hvordan SSL fungerer.

Derfor vil jeg ta meg friheten til Ä beskrive hvordan man bruker SSL (uten Ä svare pÄ spÞrsmÄlene «Hvordan fungerer det?» og «Hvorfor fungerer det?»).

Grunnlaget for moderne kryptering er Ă„ lage et nĂžkkelpar (to veldig lange strenger med tegn).

En «nÞkkel» er privat, den andre nÞkkelen er «offentlig». Den private nÞkkelen oppbevares veldig nÞye hemmelig. Den offentlige nÞkkelen distribueres til alle som Þnsker den.

Ved hjelp av den offentlige nĂžkkelen kan man kryptere en tekststreng slik at bare eieren av den private nĂžkkelen kan dekryptere den.
Og der har du grunnlaget for teknologien.

Trinn #1 — https-nettsteder.
Nettleseren, ved besÞk til nettstedet, fÄr vite fra webserveren at nettstedet er https, og ber derfor om den offentlige nÞkkelen.
Webserveren sender den offentlige nĂžkkelen. Nettleseren bruker den offentlige nĂžkkelen til Ă„ kryptere http-forespĂžrselen og sender den.
Innholdet i http-forespĂžrselen kan bare leses av den som har den private nĂžkkelen, det vil si kun serveren som forespĂžrselen rettes mot.
Http-forespĂžrselen inneholder minst URI. SĂ„ hvis et land prĂžver Ă„ begrense tilgangen ikke til hele nettstedet, men til en bestemt side — sĂ„ er det umulig Ă„ gjĂžre dette for https-nettsteder.

Trinn №2 — kryptert svar.
Webserveren gir et svar som lett kan leses underveis.
Lþsningen er ganske enkel — nettleseren oppretter lokalt et par privat-offentlig nþkkel for hver https-nettside.
Og sammen med forespĂžrselen om nettstedets offentlige nĂžkkel sender den sin lokale offentlige nĂžkkel.
Webserveren husker den og krypterer http-svaret med denne offentlige nĂžkkelen til den spesifikke klienten.
NĂ„ kan http-svaret bare dekrypteres av eieren av den private nĂžkkelen til klientens nettleser (det vil si selve klienten).

Trinn №3 — opprettelse av en sikker forbindelse over en offentlig kanal.
I eksempel №2 er det en sĂ„rbarhet — ingenting hindrer en angriper fra Ă„ fange http-forespĂžrselen og redigere informasjonen om den offentlige nĂžkkelen.
Dermed vil en mellommann se alt innholdet av de sendte-mottatte meldingene inntil kommunikasjonskanalen skiftes.
Å motvirke dette er ganske enkelt — det er tilstrekkelig Ă„ sende nettleserens offentlige nĂžkkel som en melding kryptert med webserverens offentlige nĂžkkel.
Webserveren sender da fÞrst et svar av typen «din offentlige nÞkkel er slik» og krypterer denne meldingen med den samme offentlige nÞkkelen.
Nettleseren ser pĂ„ svaret — hvis meldingen «din offentlige nĂžkkel er slik» kommer, er det 100% garanti for at denne kommunikasjonskanalen er sikker.
Hvor sikker er den?
Selve opprettelsen av en slik sikker kommunikasjonskanal skjer med hastigheten ping*2. For eksempel 20 ms.
En angriper mÄ enten ha den private nÞkkelen til en av partene pÄ forhÄnd. Eller finne den private nÞkkelen pÄ noen millisekunder.
Å knekke en moderne privat nĂžkkel vil ta tiĂ„r selv pĂ„ superdatamaskiner.

Trinn №4 — offentlig database med offentlige nþkler.
Det er Äpenbart at det i hele denne historien eksisterer en mulighet for en angriper som sitter pÄ kommunikasjonskanalen mellom klienten og serveren.
Muligheten til Ă„ presentere seg selv som en server for klienten, og som klient for serveren. Og emulere et par nĂžkler i begge retninger.
Da vil en angriper kunne se all trafikk, og fÄ muligheten til Ä «redigere» trafikken.
For eksempel, endre adressen dit penger sendes, eller kopiere passordet fra nettbanken, eller blokkere «uÞnsket» innhold.
For Ă„ bekjempe slike angripere ble det oppfunnet en offentlig database med offentlige nĂžkler for hver https-nettside.
Hver nettleser «vet» om eksistensen av omtrent 200 slike databaser. Dette er forhÄndsinstallert i hver nettleser.
«Kunnskapen» er bekreftet med den offentlige nÞkkelen fra hvert sertifikat. Det vil si at forbindelsen til hvert spesifikke sertifiseringssentrum er umulig Ä forfalske.

NÄ har vi en enkel forstÄelse av hvordan vi bruker SSL for https.
Hvis man tenker seg litt om, vil det bli klart hvordan etterretningstjenester kan bryte seg inn i denne konstruksjonen. Men det vil koste dem enorme anstrengelser.
Og for organisasjoner mindre enn NSA eller CIA er det praktisk talt umulig Ä bryte eksisterende beskyttelsesnivÄ, selv for vip.

Jeg vil ogsÄ legge til noe om ssh-forbindelser. Der finnes det ingen offentlige nÞkler, hva gjÞr vi da? SpÞrsmÄlet lÞses pÄ to mÄter.
Alternativ ssh-med-passord:
Ved fÞrste forbindelse mÄ ssh-klienten varsle om at det er en ny offentlig nÞkkel fra ssh-serveren.
Og ved videre tilkoblinger, hvis det dukker opp en advarsel om «ny offentlig nĂžkkel fra ssh-serveren» — betyr det at noen prĂžver Ă„ lytte.
Eller ved fÞrste forbindelse har du blitt lyttet til, og nÄ kommuniserer du med serveren uten mellomledd.
Faktisk er det slik at det Ă„ oppdage en avlytting er lett, raskt og uten anstrengelser — denne metoden brukes bare i spesielle tilfeller mot en bestemt klient.

Alternativ ssh-med-nĂžkkel:
Vi tar en USB-stasjon, skriver det private nÞkkelen for ssh-serveren pÄ den (for dette finnes det termer og mange viktige nyanser, men jeg skriver en generell instruksjon, ikke en bruksanvisning).
Den offentlige nÞkkelen holder vi pÄ maskinen hvor ssh-klienten skal vÊre, og den holder vi ogsÄ hemmelig.
Vi tar USB-stasjonen til serveren, setter den inn, kopierer den private nÞkkelen, og sÄ brenner vi USB-stasjonen og sprer asken for vinden (eller i det minste formaterer den med nuller).
Og sĂ„ er det gjort — efter denne operation vil det vĂŠre umuligt at bryde sĂ„ en ssh-forbindelse. SelvfĂžlgelig kan det om 10 Ă„r pĂ„ en supercomputer vĂŠre muligt at se trafikken — men det er en anden historie.

Jeg undskylder for off-topic.

SÄ nu, nÄr teorien er kendt. Lad os tale om flowet til oprettelse af et ssl-certifikat.

Ved hjÊlp af «openssl genrsa» opretter vi en privat nÞgle og «skabeloner» til den offentlige nÞgle.
«skabelonerne» sender vi til et tredjepartsfirma, som vi betaler cirka $9 for det enkleste certifikat.

Efter et par timer modtager vi vores «offentlige» nÞgle fra dette tredjepartsfirma samt et sÊt af flere offentlige nÞgler.

Hvorfor betale et tredjepartsfirma for at oprette min offentlige nĂžgle — det er et separat spĂžrgsmĂ„l, som vi ikke vil behandle her.

Nu er meningen med teksten klar:

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

I mappen «\/etc\/ssl» ligger alle filer til ssl-relaterede spÞrgsmÄl.
domain1.com — doménenavnet.
2018 — Ă„ret for nĂžglegenerering.
«key» — angivelse af, at filen er en privat nĂžgle.

Og meningen med denne fil:

smtpd_tls_cert_file=\/etc\/ssl\/domain1.com.2018.chained.crt
domain1.com — doménenavnet.
2018 — Ă„ret for nĂžglegenerering.
chained — angivelse af, at dette er en kéde af offentlige nþgler (den fþrste er vores offentlige nþgle, og de þvrige kom fra firmaet, der udstedte den offentlige nþgle).
crt — angivelse af, at dette 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 anvendes ikke i dette tilfĂŠlde, men er skrevet som et eksempel.

Fordi en fejl i denne parameter vil fĂžre til, at din server sender spam (uden din vilje).

Derefter skal du bevise for alle, at du ikke er skyldig.

recipient_delimiter = +

Mange ved mÄske ikke, at dette er standardtegnet til rangering af passem, og det understÞttes af de fleste moderne mailservere.

For eksempel, hvis du har en e-mailkonto «username@gmail.com», sĂ„ prĂžv at sende til «username+spam@gmail.com» — se, hvad der sker.

inet_protocols = ipv4

Dette kan vĂŠre forvirrende.

Men det er ikke uden grund. Hvert nyt domÊne er som standard kun IPv4, og sÄ aktiverer jeg IPv6 for hver enkelt.

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 indkommende mail gÄr til dovecot.
Og reglerne for doméne, postkasse, alias — skal ses 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

Noe veit postfix at det bare kan ta imot mail for videre sending dersom det er autentisering med dovecot.

Eg forstÄr egentlig ikkje kvifor dette skal doblerast her. Vi har jo alt spesifisert i «virtual_transport» det som trengs.

Men postfix-systemet er veldig gammalt — kanskje dette er tidlegare lappeteknikk frĂ„ den tida.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Dette mÄ konfigurerast for kvar e-postserver pÄ sin eigen mÄte.

Eg har tre e-postserverar, og innstillingane er veldig forskjellige grunna ulike krav til bruk.

Det er viktig Ă„ konfigurere nĂžye — elles vil spam renn inn til deg eller endĂ„ verre — spam vil renne ut frĂ„ deg.

# SPF
policyd-spf_time_limit = 3600

Innstilling for ein viss plugin knytt til sjekking av SPF for innkomande e-post.

# 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

Innstilling som krev at alle utreisepost mÄ ha DKIM-signatur.

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

Dette er ein nÞkkelkomponent i rutinga av e-post nÄr ein sender post frÄ php-skript.

Filen «/etc/postfix/sdd_transport.pcre»:

/^www-domain1@domain1.com$/ domain1:
/^www-domain2@domain1.com$/ domain2:
/^www-domain3@domain1.com$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

Til venstre — regulére uttrykk. Til hþgre — ein label som merke e-posten.
Postfix vil med basis i labelen ta hensyn til ytterlegare nokre linjer med konfigurasjon for den spesifikke e-posten.

Korleis postfix skal bli rekonfigurert for den spesifikke e-posten vil bli spesifisert i «master.cf».

Linje 4, 5, 6 — dei er viktige. I namnet pĂ„ kva domene me sender e-post frĂ„ — set vi den merkelappen.
Men ikkje alltid i php-skriptene i den gamle koden blir feltet «from» spesifisert. DÄ kjem brukarnamn til hjelp.

Artikkelen er sĂ„ omfattande — eg vil ikkje bli distrahert med konfigurering av nginx+fpm.

Kort sagt — for kvart nettsted angir vi ein eigen linux-brukar som eigar. Og medan vi tilpassar sin eigen fpm-pool.

Fpm-pool bruker kva som helst versjon av php (det er fantastisk nÄr ein pÄ ein server utan problem kan bruke ulike versjonar av php og til og med ulik php.ini for nabosidene).

SÄ dette spesifikke linux-brukarnamn «www-domain2» har nettstedet domain2.com. PÄ dette nettstedet er det kode for Ä sende e-post utan at feltet from blir spesifisert.

SĂ„ sjĂžlv i slike tilfelle vil e-postane sendast korrekt og aldri havne i spam.

Min «/etc/postfix/master.cf» ser slik ut:

...
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 er ikke helt komplett — det er allerede veldig stort.
Jeg har kun merket det som er endret.

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}

Dette er innstillinger relatert til spamassassin, om dette 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 tillater tilkobling til e-postserveren via port 587.
For dette mÄ man nÞdvendigvis autentisere seg.

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

Vi aktiverer SPF-kontroll.

apt-get install postfix-policyd-spf-python

La oss installere pakken for SPF-kontroller 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 her er det mest interessante. Dette Ă„pner muligheten for Ă„ sende e-poster for et spesifikt domene fra en spesifikk IPv4/IPv6 adresse.

Dette gjĂžres for rDNS. rDNS er prosessen med Ă„ hente en streng fra en IP-adresse.
Og for e-post brukes denne muligheten til Ă„ bekrefte at helo virkelig stemmer overens med rDNS for adressen som sendte e-posten.

Hvis helo ikke stemmer overens med domenet til e-posten som sendte meldingen — erfarer man sĂ„kalte spam-poeng.

Helo stemmer ikke overens med rDNS — mange spam-poeng tildeles.
Dermed mÄ hvert domene ha sin egen IP-adresse.
For OVH — i kontrollpanelet er det mulighet for Ă„ spesifisere rDNS.
For tech.ru — spĂžrsmĂ„let lĂžses via support.
For AWS — spĂžrsmĂ„let lĂžses via support.
«inet_protocols» og «smtp_bind_address6» — dette aktiverer stĂžtte for IPv6.
For IPv6 mÄ vi ogsÄ konfigurere rDNS.
«syslog_name» — dette er for lettere lesbarhet av logger.

KjĂžp sertifikater anbefaler her.

Konfigurering av postfix+dovecot her.

Konfigurasjon av SPF.

============= Dovecot =============

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

Konfigurering av mysql, vi installerer pakkene selv.

Fil «/etc/dovecot/conf.d/10-auth.conf»

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autentisering bare i kryptert form.

Fil «/etc/dovecot/conf.d/10-mail.conf»

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

Her angir vi lagringsstedet for e-poster.

Jeg vil at de skal lagres i filer og grupperes etter domener.

Fil «/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 hovedkonfigurasjonsfilen for dovecot.
Her deaktiverer vi usikre forbindelser.
Og aktiverer sikre forbindelser.

Fil «/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
}

Vi konfigurerer ssl. Vi angir at ssl er pÄkrevd.
Og selve sertifikatet. En viktig detalj — direktivet «local». Det angir hvilket ssl-sertifikat som skal brukes ved forbindelse til hvilken lokal IPv4.

Forresten, IPv6 er ikke konfigurert her, jeg skal rette pÄ dette senere.
XX.XX.XX.X5 (domain2) — sertifikat er ikke tilgjengelig. For klienter mĂ„ domain1.com angis for forbindelser.
XX.XX.XX.X2 (domain3) — sertifikat er tilgjengelig, for klienter kan bĂ„de domain1.com og domain3.com angis for forbindelser.

Fil «/etc/dovecot/conf.d/15-lda.conf»

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Dette vil vĂŠre nĂždvendig senere for spamassassin.

Fil «/etc/dovecot/conf.d/20-imap.conf»

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Dette er antispam-pluginet. NÞdvendig for Ä trene spamassassin nÄr e-poster flyttes til/fra «Spam»-mappen.

Fil «/etc/dovecot/conf.d/20-pop3.conf»

protocol pop3 {
}

Det finnes bare en slik fil.

Fil «/etc/dovecot/conf.d/20-lmtp.conf»

protokoll lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = admin@domain1.com
}

Konfigurasjon av lmtp.

Fil «/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
}

Innstillinger for opplÊring av spamassassin nÄr man flytter til/fra mappen «Spam».

Fil «/etc/dovecot/conf.d/90-sieve.conf»

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

Fil som angir hva som skal gjĂžres med innkommende meldinger.

Fil «/var/lib/dovecot/sieve/default.sieve»

require ["fileinto", "mailbox"];

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

Filen mÄ kompilere: «sievec default.sieve».

Fil «/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 av sql-filer for autentisering.
Selve filen – som en metode for autentisering.

Fil «/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 samsvarer med lignende innstillinger for postfix.

Fil «/etc/dovecot/dovecot.conf»

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

Hovedkonfigurasjonsfilen.
Viktig at vi her angir/legger til protokoller.

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

apt-get install spamassassin spamc

Vi installerer pakkene.

adduser spamd --disabled-login

Legger til bruker i egenskap av hvilken.

systemctl enable spamassassin.service

Aktiverer automatisk oppstart av spamassassin-tjenesten ved oppstart.

Fil «/etc/default/spamassassin»:

CRON=1

Aktiverer automatisk oppdatering av regler «som standard».

Fil «/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

Det er nÞdvendig Ä opprette en MySQL-database «sa» med brukeren «sa» med passordet «password» (bytt til noe mer hensiktsmessig).

report_safe – dette betyr at det vil bli sendt en rapport om spam-meldingen i stedet for selve meldingen.
use_bayes – dette er innstillinger for maskinléring i spamassassin.

De andre spamassassin-innstillingene ble tidligere brukt i artikkelen.

Generell innstilling av «spamassassin».
Om flytting av nye spam-meldinger til IMAP-mappen «Spam».
Om enkel integrasjon av Dovecot + SpamAssassin.
Anbefales Ă„ lese teorien om opplĂŠring av spamassassin ved flytting av meldingene i IMAP-mapper (og ikke anbefales til bruk).

============= Henvendelse til fellesskapet =============

Jeg Þnsker ogsÄ Ä sende en idé til fellesskapet om hvordan man kan Þke sikkerheten til sendte e-poster. Siden jeg har dykket sÄ dypt inn i emnet e-post.

For at brukeren skal kunne opprette et par nÞkler pÄ sin klient (Outlook, Thunderbird, nettleser-plugin, ...) - en offentlig og en privat. Den offentlige sendes til DNS. Den private lagres pÄ klienten. E-postserverne skal vÊre i stand til Ä bruke den offentlige nÞkkelen for sending til en spesifikk mottaker.

Og for Ä beskytte mot spam i slike e-poster (ja, e-postserveren kan ikke se innholdet) - mÄ vi innfÞre tre regler:

  1. Obligatorisk ekte DKIM-signatur, obligatorisk SPF, obligatorisk rDNS.
  2. En nevrale nettverk for opplÊring mot spam + en database for dette pÄ klientsiden.
  3. Krypteringsalgoritmen mÄ vÊre slik at avsenderen mÄ bruke 100 ganger mer CPU-kraft til kryptering enn mottakeren.

I tillegg til offentlige e-poster - utvikle en standard for e-poster som foreslÄr 'Ä begynne en sikker korrespondanse'. En bruker (e-postboks) sender en annen e-postboks en melding med et vedlegg. I e-posten er det en tekst med forslag om Ä starte en sikker kommunikasjonskanal og den offentlige nÞkkelen til e-postboksens eier (med den private nÞkkelen pÄ klientsiden).

Man kan ogsÄ lage et par nÞkler spesielt for hver korrespondanse. Mottakerbrukeren kan akseptere dette forslaget og sende sin offentlige nÞkkel (ogsÄ laget spesielt for denne korrespondansen). Deretter sender den fÞrste brukeren en kontrollmelding (kryptert med den andre brukerens offentlige nÞkkel) - ved mottakelsen av denne kan den andre brukeren anse den etablerte kommunikasjonskanalen som pÄlitelig. Deretter sender den andre brukeren en kontrollmelding - og da kan ogsÄ den fÞrste brukeren anse den etablerte kanalen som beskyttet.

For Ä kjempe mot avlytting av nÞkler pÄ veien - mÄ protokollen forutsi muligheten for Ä overfÞre minst én offentlig nÞkkel ved hjelp av en USB-minnepinne.

Og det viktigste - at alt dette fungerer (spÞrsmÄlet 'hvem skal betale for dette?'):
InnfÞre e-postsertifikater som koster fra 10$ for 3 Är. Disse vil la avsenderen angi i DNS at «mine offentlige nÞkler er der borte». Og vil gi mulighet til Ä starte en sikker forbindelse. Samtidig vil slike forbindelser vÊre gratis Ä motta.
Gmail monetiserer endelig sine brukere. For 10$ i 3 Är fÄr man rett til Ä opprette sikre kommunikasjonskanaler.

============= Konklusjon =============

For Ä teste hele artikkelen planla jeg Ä leie en dedikert server i en mÄned og kjÞpe et domene med SSL-sertifikat.

Men livsomstendigheter gjorde at denne saken ble utsatt i 2 mÄneder.
Og nĂ„ nĂ„r jeg igjen hadde litt fritid — bestemte jeg meg for Ă„ publisere artikkelen som den er, i stedet for Ă„ risikere at publiseringen skulle bli forsinket enda et Ă„r.

Hvis det kommer mange spĂžrsmĂ„l som «her er det ikke beskrevet nok detaljert» — da vil det kanskje finnes krefter til Ă„ leie en dedikert server med et nytt domene og et nytt SSL-sertifikat og beskrive det enda mer detaljert, og viktigst av alt — avdekke alle manglende viktige detaljer.

Jeg vil ogsĂ„ sette pris pĂ„ tilbakemeldinger pĂ„ ideen om e-postsertifikater. Hvis ideen faller i smak — vil jeg prĂžve Ă„ finne krefter til Ă„ skrive et utkast til RFC.

NĂ„r man kopierer store deler av artikkelen — skal man oppgi lenke til denne artikkelen.
Ved oversettelse til noe annet sprĂ„k — skal man oppgi lenke til denne artikkelen.
Jeg vil selv prĂžve Ă„ oversette til engelsk og legge igjen gjensidige lenker.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster