🥇Debian + Postfix + Dovecot + Mitme domeeni tugi + SSL + IPv6 + OpenVPN + Mitme liidese tugi + SpamAssassin-õpe + Bind

See artikkel räägib, kuidas seadistada kaasaegset postiserverit.
Postfix + Dovecot. SPF + DKIM + rDNS. IPv6-ga.
TSL-i krüpteerimisega. Toetab mitut domeeni — osa tõelise SSL-sertifikaadiga.
Sisaldab rämpsposti kaitset ja kõrget rämpsposti reitingut teiste postiserverite seas.
Toetab mitut füüsilist liidest.
OpenVPN, millele pääseb juurde IPv4 kaudu ja mis võimaldab IPv6 ühendust.

Kui te ei soovi neid kõiki tehnoloogiaid õppida, kuid tahate sellist serverit seadistada — siis see artikkel on teie jaoks.

Artiklis puuduvad katsetused iga detaili selgitamiseks. Selgitus käib selle kohta, mis on mittestandardsed või tarbija seisukohalt olulised seadistused.

Motivatsioon postiserveri seadistamiseks — minu pikaaegne unistus. Võib-olla tundub see rumal, kuid IMO on see palju parem, kui unistada oma lemmikbrändi uuest autost.

IPv6 seadistamise motivatsioon on kaks. IT spetsialist peab pidevalt õppima uusi tehnoloogiaid, et ellu jääda. Tahaksin anda oma tagasihoidliku panuse tsensuuri vastu võitlemisse.

OpenVPN seadistamise motivatsioon — ainult selleks, et IPv6 töötaks kohaliku masinaga.
Mitme füüsilise liidese seadistamise motivatsioon — mul on serveris üks liides „aeglane, kuid piiramatu“, teine aga „kiire, kuid pakettidega“.

Bind seadistamise motivatsioon — minu teenusepakkuja pakub ebastabiilset DNS-serverit ja Google'il võib samuti esineda tõrkeid. Soovin usaldusväärset DNS-serverit isiklikuks kasutamiseks.

Artikli kirjutamise motivatsioon — mustand kirjutati 10 kuud tagasi ning olen sellesse juba kaks korda vaadanud. Kui isegi autorile on see regulaarselt vajalik — on suur tõenäosus, et ka teistele on see vajalik.

Universaalset lahendust postiserveri jaoks ei ole. Kuid ma püüan kirjutada midagi taolist: „tehke nii ja kui kõik töötab nagu peab — visake üleliigne minema“.

On server, mille colocation on ettevõttes tech.ru. Võimalus võrrelda OVH, Hetzneri, AWS-iga. Selle ülesande lahendamiseks oleks tõhusam koostöö just tech.ru-ga.

Serveris on installitud Debian 9.

Serveris on 2 liidest `eno1` ja `eno2`. Esimene on piiramatu, teine aga vastavalt kiire.

On 3 staatilist IP-aadressi, XX.XX.XX.X0 ja XX.XX.XX.X1 ning XX.XX.XX.X2 liideses `eno1` ja XX.XX.XX.X5 liideses `eno2`.

On XXXX:XXXX:XXXX:XXXX::/64 IPv6 aadresside plokk, mis on määratud liidesele `eno1` ja millest XXX:XXXX:XXXX:XXXX:1:2::/96 määrati minu palve põhjal `eno2`.

On 3 domains `domain1.com`, `domain2.com`, `domain3.com`. There is an SSL certificate for `domain1.com` and `domain3.com`.

There is a Google account, to which I want to link the email `vasya.pupkin@domain1.com` (to receive and send emails directly from the Gmail interface).
There should be an email account `support@domain2.com`, from which I want to see a copy of the emails in my Gmail. And occasionally have the ability to send something on behalf of `support@domain2.com` through the web interface.

There should be an email account `ivanov@domain3.com`, which Ivanov will use from his iPhone.

Sent emails must comply with all modern anti-spam requirements.
The highest level of encryption provided in public networks must be implemented.
There must be support for IPv6 for sending and receiving emails.
There should be SpamAssassin, which will never delete emails but either bounce them or pass them through to the IMAP folder 'Spam'.
Auto-training of SpamAssassin must be configured: if I move an email to the 'Spam' folder, it will train on that; if I move an email from the 'Spam' folder, it will train on that. The training results of SpamAssassin should affect the delivery of emails to the 'Spam' folder.
PHP scripts must be able to send emails on behalf of any domain on this server.
There should be an OpenVPN service with the ability to use IPv6 on clients that do not have IPv6.

First, the interfaces and routing must be configured, including IPv6.
Then, OpenVPN must be set up to connect via IPv4 and provide the client with a static real IPv6 address. This client will have access to all IPv6 services on the server and to any IPv6 resources on the Internet.
Next, Postfix must be configured for sending emails + SPF + DKIM + rDNS and other similar details.
After that, Dovecot must be configured and Multidomain must be set up.
Then, SpamAssassin must be configured and training must be set up.
Finally, Bind must be installed.

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

To configure the interfaces, the following should be written in '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

These settings can be applied to any server in tech.ru (with minor agreement with support) and it will work as expected.

If you have experience configuring similar things for Hetzner, OVH — it works differently there. More complex.

eno1 is the name of network card #1 (slow, but unlimited).
eno2 is the name of network card #2 (fast, but with a rate).
tun0 — see virtuaalne võrkaart OpenVPN-ist.
XX.XX.XX.X0 — IPv4 #1 eno1-l.
XX.XX.XX.X1 — IPv4 #2 eno1-l.
XX.XX.XX.X2 — IPv4 #3 eno1-l.
XX.XX.XX.X5 — IPv4 #1 eno2-l.
XX.XX.XX.1 — IPv4 gateway.
XXXX:XXXX:XXXX:XXXX::/64 — IPv6 kogu serveri jaoks.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 eno2 jaoks, kõik muu tuleb paarituks eno1 kaudu.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 gateway (tuleb märkida, et siin võiks/k peaks olema teistmoodi. Määrake IPv6 lüliti).
dns-nameservers — määratud 127.0.0.1 (sest bind on paigaldatud kohapeal) ja 213.248.1.6 (see on tech.ru poolt).

«table eno1t» ja «table eno2t» — nende route-reeglite mõte on see, et liiklus, mis siseneb läbi eno1, väljub samuti läbi selle, ja liiklus, mis siseneb läbi eno2, väljub samuti selle kaudu. Samuti, mis tahes serveripoolsete algatustega seonduvad ühendused peaksid minema läbi eno1.

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

Selle käsklusega määrame, et kõik arusaamatud andmed, mis langevad mis tahes reegli alla, millel on märgitud «table eno1t», suunatakse eno1 liidesele.

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

Selle käsklusega määrame, et kogu serveri algatatav liiklus suunatakse eno1 liidesele.

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

Selle käsklusega määrame paremad liiklusmärgistamise reeglid.

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

See plokk määrab teise IPv4 liidesele eno1.

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

Selle käsklusega määrame marsruudi OpenVPNi klientide ja kohalike IPv4-de vahel, välja arvatud XX.XX.XX.X0.
Miks piisab sellest käsust kõigi IPv4-de jaoks — ma ei saa siiani aru.

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

Sellega määrame aadressi liidesele. Server kasutab seda «väljuvana» aadressina. Muul viisil ei kasutata.

Miks on märgitud «:1:1::» nii keeruliselt? Et OpenVPN töötaks õigesti ja ainult selleks. Sellest räägime hiljem rohkem.

Gateway teemal — see töötab ja on okei. Kuid õigesti öeldes tuleks siia märgistada IPv6 lüliti, mille kaudu server on ühendatud.

Kuid mingil põhjusel lõpetab IPv6 töötamise, kui ma seda teen. Tõenäoliselt on need teknika.ru kummalised probleemid.

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

See on IPv6 aadressi lisamine liidesele. Kui on vaja sada aadressi — tähendab saja rida selle faili.

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

Märgistasin kõigi liideste aadressid ja alamvõrgud, et see oleks selgem.
eno1 — peab olema kindlasti "\/64" — sest see on kogu meie aadresside partii.
tun0 — alamvõrk peab kindlasti olema suurem kui eno1. Vastasel juhul ei saa avada IPv6 väravat OpenVPN klientidele.
eno2 — alamvõrk peab kindlasti olema suurem kui tun0. Vastasel juhul ei saa OpenVPN kliendid juurdepääsu kohalikele IPv6 aadressidele.
Selguse huvides valisin alamvõrgu sammuks 16, kuid soovi korral võib isegi "1" sammu kasutada.
Seega 64+16 = 80, ja 80+16 = 96.
Veel suurema selguse huvides:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — need on aadressid, mis tuleb määrata konkreetsetele saitidele või teenustele liidesel eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — need on aadressid, mis tuleb määrata konkreetsetele saitidele või teenustele liidesel eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — need on aadressid, mis tuleb määrata OpenVPN klientidele või kasutada OpenVPN teenuslike aadressidena.

Võrgu seadistamiseks peab olema võimalus serverit taaskäivitada.
IPv4 muudatused võetakse kasutusele järgmise käsu täitmisel (kindlasti tuleks see käsk panna screeni — vastasel juhul toob see käsu lihtsalt serveri võrgu alla):

/etc/init.d/networking restart

Faili "\/etc\/iproute2\/rt_tables" lõppu tuleks lisada:

100 eno1t
101 eno2t

Ilma selleta ei saa kasutada kohandatud tabelit failis "\/etc\/network\/interfaces".
Numbrid peavad olema unikaalsed ja alla 65535.

IPv6 muudatused on lihtsasti muudetavad ilma taaskäivitamiseta, kuid selleks tuleb õppida vähemalt kolme käsku:

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

Seadistamine "\/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

Need on minu serveri "sysctl" seaded. Tahan märkida olulise.

net.ipv4.ip_forward = 1

Ilma selleta OpenVPN ei tööta kuidagi.

net.ipv6.ip_nonlocal_bind = 1

Igaüks, kes üritab teha IPv6 bind'i (näiteks nginx) kohe pärast liidese värskendamist — saab vea. Selline aadress on kättesaamatu.

Selle olukorra vältimiseks on selline seadistus tehtud.

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

Ilma nende seadistusteta ei välju OpenVPN kliendi IPv6 liiklus maailma.

Teised seaded kas ei puuduta teemat või ma ei mäleta, miks need on.
Aga igaks juhuks jätan need "selliseks, nagu on".

Kuna selle faili muudatused peab võtma ilma serveri taaskäituseta — peab täitma käsku:

sysctl -p

Üksikasjalikumalt "tabeli" reeglite kohta: habr.com\/post\/108690

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

OpenVPN IPv4 ei tööta ilma iptables'ta.

Minu iptables on sellised VPN-ile:

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 — see on minu staatiline IPv4-aadress kohaliku masina jaoks.
10.8.0.0/24 — IPv4 võrk openvpn. IPv4 aadressid openvpn klientidele.
Reeglite järjekord on oluline.

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

See piirang on mõeldud selleks, et ainult mina oma staatilisest IP-st võiksin OpenVPN-i kasutada.

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

IPv4 pakettide edastamiseks OpenVPN klientide ja Interneti vahel — tuleb kasutada mõnda neist käskudest.

Erinevates olukordades ei sobi üks variant.
Minu olukorrale sobivad mõlemad käsud.
Dokumentatsiooni lugedes valisin esimese variandi, kuna see tarbib vähem CPU-d.

Kuna kõik iptables sätted peaksid olema aktiveeritud pärast taaskäivitamist — tuleb need kuhugi salvestada.

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

Sellised nimetused ei ole juhuslikud. Neid kasutab pakett «iptables-persistent».

apt-get install iptables-persistent

Peamise OpenVPN paketi paigaldamine:

apt-get install openvpn easy-rsa

Seadistame sertifikaatide mallid (asendage oma väärtustega):

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

Muudame sertifikaatide mallide seadeid:

mcedit vars

...
# Need on väljade vaikeväärtused
# mis pannakse sertifikaati.
# Ärge jätke ühtegi neist väli tühjaks.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="admin@domain1.com"
export KEY_OU="VPN"

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

Loome serveri sertifikaadi:

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

Valmistame ette võimaluse luua lõplikud «client-name.opvn» failid:

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

Valmistame ette skripti, mis koondab kõik failid üheks opvn failiks.

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

Loome esimese OpenVPN kliendi:

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

Fail «~/client-configs/files/client-name.ovpn» saadetakse kliendi seadmesse.

iOS klientide tuleb teha trikk:
Tag «tls-auth» sisu peab olema ilma kommentaarideta.
Samuti tuleb panna «key-direction 1» kohe enne tagi «tls-auth».

Seadistame OpenVPN serveri konfiguratsiooni:

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

See on vajalik, et määrata iga kliendi jaoks staatiline aadress (pole kindlasti vajalik, aga ma kasutan):

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

Kõige keerulisem ja võtmekoht.

Kahjuks OpenVPN ei oska iseseisvalt seadistada IPv6 gateway'd klientide jaoks.
Tuleb «käsitsi» edastada see igale kliendile.

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

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

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

Mõlemad skriptid kasutavad faili «/etc/openvpn/variables»:

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

Miks siin nii on kirjutatud — ei oska meenutada.

Praegu näeb imelik välja netmask = 112 (siin peaks olema 96).
Ja prefix on imelik, ei vasta võrgule tun0.
Aga noh, jätan «nagu on».

cipher DES-EDE3-CBC

See on maitseasi — ma valisin sellise ühenduse krüpteerimise viisi.

Rohkem infot OpenVPN IPv4 seadistamisest.

Rohkem infot OpenVPN IPv6 seadistamisest.

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

Põhipaketi paigaldamine:

apt-get install postfix

Paigaldamisel valida «internet-site».

Minu «/etc/postfix/main.cf» näeb välja nii:

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

# .domain'i lisamise eest vastutab MUA.
append_dot_mydomain = no

readme_directory = no

# Vaata http://www.postfix.org/COMPATIBILITY_README.html -- vaikimisi 2 uutel installatsioonidel.
compatibility_level = 2

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

# Salvestustüüp
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 seadistused
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-aadress iga domeeni jaoks
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Vaatame selle konfi üksikasju.

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

Habr'i kasutajate arvates sisaldab see plokk `valeinfo ja eksitavad väited`.Ainult 8 aastat pärast oma karjääri algust hakkasin ma aru saama, kuidas SSL töötab.
Seetõttu võtan endale julguse kirjeldada, kuidas kasutada SSL-i (vastamata küsimustele "Kuidas see töötab?" ja "Miks see töötab?").
Kaasaegse krüpteerimise alus on võtmepaaride loomine (kaks väga pikka tähemärgi stringi).
Üks "võti" on privaatne, teine "avalik". Privaatvõtit hoia äärmiselt hoolikalt saladuses. Avalikku võtit jagame igale soovijale.
Avaliku võtmega saab krüpteerida tekstistringi nii, et ainult privaatvõtme omanik suudab selle dekrüpteerida.
Nii et see on kogu tehnoloogia alus.
Samm #1 — https saidid.
Brauser, kui ta pöördub saidi poole, saab veebiserverilt teada, et sait on https ja seetõttu küsib ta avalikku võtit.
Veebiserver edastab avaliku võtme. Brauser kasutab avalikku võtit HTTP-päringu krüpteerimiseks ja saadab selle edasi.
HTTP-päringu sisu saab lugeda ainult see, kellel on privaatvõti, st ainult server, mille poole pöördutakse.
HTTP-päring sisaldab vähemalt URI-d. Seetõttu, kui riigis üritatakse juurdepääsu piirata mitte kogu saidile, vaid konkreetsele lehele — siis HTTPS-i saitide puhul on see võimatu.
Samm nr 2 — krüpteeritud vastus.
Veebiserver vastab, mida saavad teel kergesti lugeda.
Lahendus on äärmiselt lihtne — brauser genereerib kohapeal sama privaat-avaliku võtme paari iga HTTPS-i saidi jaoks.
Ja koos saidi avaliku võtme päringuga saadab ta oma kohandatud avaliku võtme.
Veebiserver mäletab seda ja HTTP-vastuse saatmisel krüpteerib ta konkreetse kliendi avaliku võtmega.
Nüüd saab HTTP-vastust dekrüpteerida ainult privaatvõtme omanik kliendi brauseris (ehk siis klient ise).
Samm nr 3 — kaitstud ühenduse loomine avalikul kanalil.
Näites nr 2 on haavatavus — pole midagi, mis takistaks pahatahtlikul isikul HTTP-päringu pealtkuulamist ja avaliku võtme teabe muutmist.
Seega näeb vahendaja suurepäraselt kogu saadetavat ja saadud sõnumite sisu seni, kuni sidekanal ei muutu.
Selle vastu on äärmiselt lihtne võidelda — piisab, kui saata brauseri avalik võti sõnumina, mis on krüpteeritud veebiserveri avaliku võtmega.
Veebiserver saadab siis kõigepealt vastuse, mis ütleb: „sinu avalik võti on selline” ja krüpteerib selle sõnumi sama avaliku võtmega.
Brauser vaatab vastust — kui tuli sõnum „sinu avalik võti on selline” — on see 100% garantii, et see sidekanal on turvaline.
Kui turvaline?
Sellise turvalise sidekanali loomine toimub kiirusel ping*2. Näiteks 20ms.
Kurjategijal peab olema kas eelnevalt privaatvõti ühe osapoole jaoks. Või peab ta privaatvõtit paariks millisekundiks proovima.
Ühe tänapäevase privaatvõtme murdmine võtab superarvutis aastakümneid.
Samm nr 4 — avalik andmebaas avalikest võtmetest.
On ilmne, et kogu selles loos on võimalus kurjategijaks, kes istub kliendi ja serveri vahelisel sidekanalil.
Klient saab esindada serverit ja server saab esindada klienti. Ja simuleerida võtmeid mõlemas suunas.
Siis näeb ründaja kogu liiklust ja tal on võimalus "toimetada" liiklust.
Näiteks muutnud aadressi, kuhu raha saata, või kopeerida pangakonto parooli või blokeerida "ebameeldivat" sisu.
Selliste ründajate vastu loodi avalik andmebaas iga https saidi jaoks, kus hoitakse avalikke võtit.
Iga brauser "teab" umbes 200 sellist andmebaasi. See on eelnevalt seadistatud igasse brauserisse.
"Teadmised" on kinnitatud iga sertifikaadi avaliku võtmega. See tähendab, et iga konkreetse sertifitseerimiskeskusega ühendust simuleerida ei saa.
Nüüd on lihtne aru saada, kuidas kasutada SSL-i https jaoks.
Kui natuke mõelda, siis saab selgeks, kuidas spetsiaalteenistused võivad selle struktuuri kaudu midagi häkkida. Kuid see nõuab neilt tohutult pingutust.
Organisatsioonide jaoks on NSA või CIA vähem võimalik, et isegi vip-tasemel on olemasolevat kaitset murda.
Samuti lisan ssh-ühenduste kohta. Seal pole avalikke võtmeid, kuidas siis olla? Küsimus lahendatakse kahel viisil.
Ssh-parooliga variant:
Esimese ühenduse korral peab ssh-kliendi teavitama, et meil on uus avalik võti ssh-serverilt.
Ja edasistes ühendustes, kui ilmneb teade "uus avalik võti ssh-serverilt", tähendab see, et teid üritatakse pealt kuulata.
Või kui esimesel ühendusel pealt kuulatati, räägite nüüd serveriga ilma vahendajateta.
Just seetõttu, et pealt kuulamise fakti on lihtne, kiire ja vaevata paljastada, kasutatakse seda rünnakut ainult erijuhtudel konkreetse kliendi jaoks.
Ssh-võtmega variant:
Võtame USB-mälupulga, salvestame sellele privaatvõtme ssh-serverile (selle jaoks on terminid ja palju olulisi nüansse, kuid ma kirjutan lihtsalt teadmiste jagamiseks, mitte kasutusjuhendiks).
Avaliku võtme jätame masinale, kus on ssh-klient, ja hoidke seda ka saladuses.
Viime USB-mälupulga serverisse, sisestame selle, kopeerime privaatvõtme ja põletame mälupulga ning puistame tuhka tuule kätte (või vähemalt vormindame nullidega).
Nüüd on kõik — pärast sellist protseduuri pole võimalik sellist ssh-ühendust murda. Loomulikult on pärast 10 aastat superarvutiga võimalik vaadata liiklust — aga see on eraldi lugu.
Vabandan off-topic'i pärast.

Nüüd, kui teooria on teada, räägin ssl-sertifikaadi loomise voost.

Kasutades „openssl genrsa“, loome privaatvõtme ja „põhjastikud“ avaliku võtme jaoks.
„Põhjastikud“ saadame kolmanda osapoole ettevõttele, kellele maksame umbes 9 dollarit kõige lihtsama sertifikaadi eest.

Paari tunni pärast saame sellelt kolmandalt osapoolelt meie „avaliku“ võtme ja veel komplekti mitmeid avalikke võtit.

Miks maksta kolmanda osapoole ettevõttele minu avaliku võtme vormistamise eest — see on eraldi küsimus, siin ei pea seda arutama.

Nüüd on selge, mis on selle kirjutise mõte:

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

Kaustas „//ssl“ on kõik ssl-iga seotud failid.
domain1.com — domeeninimi.
2018 — võtmete loomise aasta.
„key“ — tähistus, et fail on privaatvõti.

Ja selle faili mõte:

smtpd_tls_cert_file=//ssl/domain1.com.2018.chained.crt
domain1.com — domeeninimi.
2018 — võtmete loomise aasta.
chained — tähistus, et siin on avalike võtmestiku ahel (esimene — meie avalik ja ülejäänud — need, mis saadeti ettevõttelt, kes vormistas avaliku võtme).
crt — tähistus, et see on valmis sertifikaat (avalik võtme koos tehniliste selgitustega).

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

See seade ei ole antud juhul kasutusele võetud, kuid on kirjutatud näitena.

Sest vale parameeter toob kaasa selle, et teie server saadab rämpsposti (ilma teie tahte).

Seejärel peab kõigile tõestama, et te ei ole süüdi.

recipient_delimiter = +

Paljud ei pruugi teada, kuid see on standardne sümbol rikkaimate e-kirjade järjestamiseks ja see on toetatud enamikus kaasaegsetes e-posti serverites.

Näiteks, kui teil on e-posti aadress „username@gmail.com“, proovige saata „username+spam@gmail.com“ — vaadake, mis juhtub.

inet_protocols = ipv4

See võib teid segadusse ajada.

Aga see ei ole niisama. Iga uus domeen — vaikimisi ainult IPv4, hiljem lülitan igaühe jaoks eraldi IPv6 sisse.

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

Siin määrame, et kogu sissetulev post läheb dovecotisse.
Ja reeglid domeeni, postkasti, alias jaoks — vaadake DB-st.

/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

Nüüd teab postfix, et e-kirjade vastuvõtmine edasitoimetamiseks on võimalik ainult autentimise kaudu dovecoti.

Mulle tõesti ei ole päris selge, miks seda siin dubleerida. Oleme ju juba «virtual_transport» kõik vajalikud määranud.

Kuid postfix on väga vana süsteem — tõenäoliselt on need vanadest aegadest pärit tugimeetmed.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Seda tuleb seadistada iga e-posti serveri jaoks erinevalt.

Mul on kolme e-posti serveri käsutuses, ja need seaded on väga erinevad, kuna kasutuse nõuded on erinevad.

Seadistama peab hoolikalt — vastasel juhul ähvardab teid spämmi voolamine või halvem — spämmi saatmine teie poolt.

# SPF
policyd-spf_time_limit = 3600

Seadistus mõne pluginaga, mis seondub sissetulevate kirjade SPF kontrollimisega.

# 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

Seadistus, et kõik saadetavad kirjad peavad olema varustatud DKIM allkirjaga.

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

See on oluline detail, mis seondub kirjade suunamisega, kui saadetakse kirju php skriptide kaudu.

Fail «/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:

Vasakul — regulaaravaldised. Paremal — märk, millega kiri on tähistatud.
Postfix arvestab vastavalt märgile veel mõne konfigureerimisreegliga konkreetse kirja jaoks.
Kuidas postfix konkreetsena kirja jaoks ümber konfigureeritakse — see on määratud failis «master.cf».
Read 4, 5, 6 — need on peamised. Millise domeeni nimel kiri saadetakse — sellele märgile paneme.
Kuid vanades php skriptides ei ole alati välja «from» määratud. Siis tuleb appi kasutajanimi.
Artikkel on juba ulatuslik — ei tahaks segadusse minna nginx+fpm seadistamisega.
Lühidalt — määrame igale saidile oma linux-kasutaja omaniku. Ja vastavalt oma fpm-pooli.
Fpm-pool kasutab igasugust php versiooni (see on suurepärane, kui samal serveril ei teki probleeme erinevate php versioonide ja isegi erinevate php.ini'dega).
Nii et konkreetsel linux-kasutajal «www-domain2» on sait domain2.com. Sellel saidil on kood, mis saadab kirju ilma «from» välja määramata.
Nii et isegi sellisel juhul lähevad kirjad õigesti ja ei satu kunagi spämmi.

Minu «/etc/postfix/master.cf» näeb välja järgmine:

...
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

Fail ei ole täielikult esitatud — see on juba niigi väga suur.
Märgisin ainult loetletud muudatused.

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}

Need on spamassassini seonduvad seaded, sellele tuleb hiljem keskenduda.

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

Lubame ühenduda meiliserveriga pordi 587 kaudu.
Selleks tuleb kindlasti autentida.

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

Lülitame sisse SPF kontrolli.

apt-get install postfix-policyd-spf-python

Installime ülaltoodud SPF kontrollimiseks paketi.

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

See on kõige huvitavam osa. See on võimalus saata kirju konkreetse domeeni nimel konkreetse IPv4/IPv6 aadressiga.
Seda tehakse rDNS jaoks. rDNS — IP aadressilt mingi rea saamine.
Ja selle võimalust kasutatakse e-posti puhul selleks, et kinnitada, et helo vastab tõeliselt rDNS-ile aadressilt, millelt e-kiri saadeti.
Kui helo ei vasta e-posti domeenile, kelle nime all kiri saadeti — antakse spämmi punkte.
Helo ei vasta rDNS-ile — antakse palju spämmi punkte.
Seega peab igal domeenil olema oma IP aadress.
OVH jaoks — konsoolis on võimalus seadistada rDNS.
tech.ru jaoks — küsimus lahendatakse toega.
AWS-i puhul — küsimus lahendatakse toega.
«inet_protocols» ja «smtp_bind_address6» — see võimaldab IPv6 toe.
IPv6 jaoks tuleb samuti rDNS seadistada.
«syslog_name» — see on mõeldud logide mugavaks lugemiseks.

Osta sertifikaadid soovitan siit.

Postfixi ja Dovecoti seadistamine siin.

SPF seadistamine.

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

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

Seadistame MySQL, installime vajalikud paketid.

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

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autoriseerimine ainult krüpteeritud vormis.

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

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

Siin määrame, kus postkaste hoida.

Soovin, et need oleksid salvestatud failidesse ja grupeeritud domeenide kaupa.

Fail «/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 {
  }
}

See on Dovecoti peamine seadistusfail.
Siin keelame ebaturvalised ühendused.
Ja aktiveerime turvalised ühendused.

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

Seadistame ssl. Määrame, et ssl on kohustuslik.
Ja ise sertifikaat. Ja oluline detail — direktiiv «local». Määrab, millise kohaliku IPv4 puhul millist ssl sertifikaati kasutada.
Muide, IPv6 pole siin seadistatud, parandan selle puudujäägi kunagi hiljem.
XX.XX.XX.X5 (domain2) — sertifikaati ei ole. Klientide ühendamiseks tuleb kasutada domain1.com.
XX.XX.XX.X2 (domain3) — sertifikaat olemas, klientide ühendamiseks võib kasutada domain1.com või domain3.com.

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

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Seda on hiljem vaja spamassassini jaoks.

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

protocol imap {
  mail_plugins = $mail_plugins antispam
}

See on antispami plugin. Vajalik spamassassini õpetamiseks kaustadese vahetamisel «Spam».

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

protocol pop3 {
}

Lihtsalt selline fail on olemas.

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

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

lmtp seadistus.

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

Spamassini treeningu seaded kaustade vahel liikumise ajal „Spam“.

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

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

Fail, kus on sätestatud, mida teha saabuvate kirjateenustega.

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

require ["fileinto", "mailbox"];

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

Fail tuleb koostada: «sievec default.sieve».

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

sql failide määramine autentimiseks.
Ja fail — autoriseerimise meetodina.

Fail «/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';

See vastab Postfixi sarnastele seadetele.

Fail «/etc/dovecot/dovecot.conf»

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

Peamine konfiguratsioonifail.
Oluline on, et siin määrame-lisame protokolle.

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

apt-get install spamassassin spamc

Installeerime paketid.

adduser spamd --disabled-login

Lisame kasutaja nimel, kellelt.

systemctl enable spamassassin.service

Lülitame spamassassini teenuse automaatkäivituse sisse.

Fail «/etc/default/spamassassin»:

CRON=1

Lülitab automaatse reeglite „vaikimisi“ värskendamise sisse.

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

Tuleb luua mysql andmebaas „sa“ kasutajaga „sa“ parooliga „password“ (asendada millegagi mõistlikumaga).

report_safe tähendab, et kirja spämmi e-kiri saadetakse raportina.
use_bayes — need on spamassini masinõppeseaded.

Muud spamassini seaded rakendati eelnevalt artiklis.

Üksikud seaded „spamassassinile“.
Uute spämmi e-kirjade liigutamine IMAP kausta „Spam“.
Lihtne Dovecoti ja SpamAssassini seadistus.
Soovitan lugeda spamassini treeningute teooriat kirjade liikumisel imap kaustades (ja mitte soovita rakendada).

============= Kogukonna pöördumine =============

Samuti tahaksin kogukonnale esitada idee, kuidas suurendada edastatavate kirjade turvalisust. Kuna olen sellesse e-posti teemasse nii sügavale süvenenud.

Kasutaja saaks oma kliendis (Outlook, Thunderbird, brauseri plugin jne) luua paar võtit. Avalik ja privaatne. Avaliku saadaks DNS-i. Privaatne jääb kliendi juurde. E-posti serverid oskaksid kasutada avalikku võtme, et saata seda konkreetsesse aadressi.

Ja spämmi kaitsmiseks nende kirjade puhul (jah, e-posti server ei saa vaadata sisu) tuleb kehtestada 3 reeglit:

Kohustuslik tõeline DKIM allkiri, kohustuslik SPF ning kohustuslik rDNS.
Neuraalvõrk antispämmi koolitamiseks + andmebaas selle kohta kliendi poolel.
Krüpteerimise algoritm peaks olema selline, et saatja pool peab krüpteerimise jaoks kulutama 100 korda rohkem CPU võimsust kui vastuvõtja pool.

Lisaks avalikele kirjadele - arendada välja standard ettepaneku kirja „alustada kaitstud suhtlust”. Üks kasutajatest (e-posti aadress) saadab teisele e-posti aadressile kirja koos manusena. Kirjas on tekst ettepanek alustada kaitstud kommunikatsioonikanalit ja e-posti aadressi omaniku avalik võti (samal ajal säilitades privaatne võti kliendi poolel).

Võib isegi teha paar võtit spetsiaalselt igaks suhtluseks. Vastuvõtja kasutaja võib selle ettepaneku aktsepteerida ja saata oma avaliku võtme (ka spetsiaalselt selle suhtluse jaoks). Seejärel saadab esimene kasutaja teenindusliku kontrollkirja (krüpteeritud teise kasutaja avaliku võtmega) - mille saanud, võib teine kasutaja pidada loodud suhtluskanaali usaldusväärseks. Edasi saadab teine kasutaja kontrollkirja - ja siis võib ka esimene kasutaja pidada loodud kanaali kaitstuks.

Võtmete teel kinni püüdmiseks tuleb protokollis ette näha vähemalt ühe avaliku võtme edastamise võimalus läbi mälupulga.

Ja kõige tähtsam on, et see kõik töötaks (küsimus: „kes selle eest maksab?”):
Sisestage postiserveri sertifikaadi hind alates 10 dollarist 3 aastaks. See võimaldab saatjal näidata DNS-is, et „minu avalikud võtmed on seal“. Ja see annab võimaluse alustada turvalist ühendust, samas aktsepteerides selliseid ühendusi tasuta.
Gmail lõpuks monetiseerib oma kasutajaid. 10 dollari eest 3 aastaks – õiguse luua turvalisi suhtluskanaleid.

============= Järeldus =============

Kogu artikli testimiseks kavatsesin rendida dedikeeritud serveri üheks kuuks ja osta domeeni koos SSL-sertifikaadiga.

Kuid elusündmused venitasid selle küsimuse kahe kuu peale.
Ja nüüd, kui mul on jälle vaba aega, otsustasin artikli avaldada nii nagu on, mitte riskeerida, et avaldamine venib veel aastaks.

Kui tuleb piisavalt palju küsimusi stiilis „aga siin ei ole piisavalt üksikasjalikult kirjeldatud“, siis tõenäoliselt leidub jõudu võtta dedikeeritud server uue domeeniga ja uue SSL-sertifikaadiga ning kirjeldada veel detailselt ning mis kõige tähtsam – tuua esile kõik tähelepanuta jäänud olulised detailid.

Sooviksin ka arvamusi idee kohta postiserveri sertifikaatidest. Kui idee meeldib, siis püüan leida jõudu kirjutada mustand RFC jaoks.

Suuri lõike artiklist kopeerides – palun märkige viide sellele artiklile.
Kui tõlgitakse mõnda teise keelde – palun märkige viide sellele artiklile.
Inglise keele tõlkimise püüan teha ise ja jätta ristviidatud lingid.

Allikas: habr.com