Lektion 12: Connection-Handling, Tuning & Security

Transkript

1 Lektion 12: Connection-Handling, Tuning & Security

2 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

3 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 = B protocol imap { mail_plugins = "quota imap_quota acl imap_acl"

4 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

5 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 = 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

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

7 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

8 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

9 Ü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

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