Lektion 12: Connection-Handling, Tuning & Security
service login => service => protocol Section service <xxx>-login PLAIN SSL/TLS Bedient Inet/Unix-Listener-Port Decodiert SSL/TLS Liest protocol <xxx> Macht <xxx>-greeting + Login-Stage imap-login Startet dann <xxx> über Socket login/<xxx> Section service <xxx> PROXY Bedient die eingeloggten Verbindungen Liest protocol <xxx> imap
service imap login { chroot = login client_limit = 0 drop_priv_before_exec = no executable = imap login extra_groups = group = idle_kill = 0 inet_listener imap { address = port = 143 ssl = no inet_listener imaps { address = port = 993 ssl = yes privileged_group = process_limit = 0 process_min_avail = 4 protocol = imap service_count = 0 type = login user = $default_login_user vsz_limit = 64 M service imap { chroot = client_limit = 1 drop_priv_before_exec = no executable = imap extra_groups = group = idle_kill = 0 privileged_group = process_limit = 8192 process_min_avail = 0 protocol = imap service_count = 1 type = unix_listener login/imap { group = mode = 0666 user = user = vsz_limit = 18446744073709551615 B protocol imap { mail_plugins = "quota imap_quota acl imap_acl"
Skalierung und Tuning Per Default wird für jeden Login ein eigener Prozess gestartet Kostet Filehandles und Memory Sinnvoll bei getrennten uids => Mehr Sicherheit Große Setups haben sowieso eine uid für alle User Sparsamkeit in den Filehandles rulez
Security./. Performance beim Login Security: Ein Login-Prozess pro Verbindung Vorteil: Getrennte Umgebungen/Sessions bei Auth-/TLS-Problemen Problem: Memory, Anzahl Filehandles Anzahl Clients: (default_)process_limit = 100 Performance: <n> Login-Prozesse haben <m> Verbindungen Nachteil: Hacker in diesem Prozess könnten Passwörter + Mails entführen Anzahl Clients: client_limit * process_limit = 1000*100 = 100.000 Connections process_min_avail = Anzahl CPU-Cores (SSL/TLS rechnen!) vsz_limit hochsetzen (Viele Clients! SSL/TLS!) service imap login { # Nie neue Prozesse starten, alle Verbindungen über wenige Logins laufen lassen service_count=0 # process_min_avail = Anzahl CPU Cores process_min_avail = 8 # Mehr Memory vsz_limit = 265M
Memory-Management Per Default hat jeder Prozess 256 Mbyte Memory als Grenze Ältere Dovecot-Versionen hatten hier nur nur 64 MB! Normalerweise ausreichend, für SEHR große IMAP-Konten aber zu wenig! Sehr groß heißt sowas wie >> 500.000 Mails in einem Folder... Kann prinzipiell gefahrlos höher angesetzt werden, deswegen werden die Prozesse ja nicht allesamt größer. Aber: Skalierung beachten. Out-of-Memory möglich! 1000 User a 1 GByte sind viel Ram... default_vsz_limit = 256M
Sicherheit gegen Flooding Einzelne Clients / IPs sollen nicht fluten können Problem für Provider: Manchmal hängen ganze Unternehmen hinter einer NAT-IP, auch vom Webmailer kommt viel zusammen... Wenn dann noch viele User das gleiche Role-Account-Postfach eingebunden haben... Im Zweifel leicht erhöhen. Irgendeine Größenbeschränkung nach oben sichert ab # Default: 10 logins eines Users von einer IP mail_max_userip_connections=10
Gesamtanzahl der Prozesse Irgendeine Gesamtanzahl der Clients als Sicherheitsdeckel default_process_limit = 100 Außerdem gehen irgendwann Filehandles aus ulimit -n im Startscript! default_process_limit = 500
Übung: Performance optimieren Stellen Sie imap-login um, so dass nicht mehr für jeden IMAP-Login ein einzelner Prozess gestartet wird Stellen Sie sicher, dass vsz_limit auf 256 MByte gesetzt ist
Was haben wir nun? Unser System wäre jetzt auch in der Lage, viele Hundert simultane Logins parallel zu bedienen. Wir wissen, wo wir vsz_limit anpassen könnten, falls sich im Logfile Hinweise dazu ergeben. Das größe Problem großer IMAP-Server liegt jedoch in der I/O-Leistung der Festplatten......und das ist die nächste Lektion.