Email Security

[tsk]

Hallo zusammen,

mein Interesse ist derzeit, einen vServer (Ubuntu 8.0.4/Plesk 9.5.4) so gut als möglich abzusichern. Die Grundsicherung ist erfolgt (ssh nur über PKI, root Login disabled, kein Login mehr mittels Password, Named ssh Users only, FTP abgeschaltet, PHP als FastCGI/suexec mit Suhosin, User gechrootet, ungenutzte Apache Module entfernt, sicherheitsrelevante hinzugefügt). Jetzt möchte ich mich dem Bereich Email Absicherung widmen – und hierbei genau so vorgehen, wie bisher. Nichts tun, ohne es vorher verstanden zu haben. Meine Idee ist, den Server weitgehend abzusichern, BEVOR ich mit Firewall und Denyhosts den (vorerst) letzten Schritt gehen werde (beides also noch nicht installiert).

Ich benötige (leider) auch Webmail. Derzeit ist Horde installiert – und hinsichtlich der diversen (m.E.) hochgefährlichen test.php Dateien in diversen Verzeichnissen abgesichert. Horde ist auch der einzige Grund, warum mod_php noch installiert ist. Ich habe es mit FastCGI alleine nicht hin bekommen und Plesk scheint diese Variante auch nicht zu unterstützen. Also 2x PHP auf dem System und Zähne knirschen.

Ich würde Webmail User gerne zwingen, sich ausschließlich über SSL/LTS anzumelden. Meine Test-Zertifikate laufen. Dummerweise können sie sich aktuell auch noch auf „normalem“ Wege anmelden. Nmap liefert im Moment folgendes Bild (nur mailrelevante Ports):

25/tcp filtered/rot (smtp Service)
106/tcp open (pop3pw Service, poppassd)
110/tcp open (pop3 Service, Courier pop3
143/tcp open (imap Service, Courier imap)
465/tcp open (smtp Service, qmail smtps)
587/tcp open (smtp Service, qmail smtp)
993/tcp open (imap Service, Courier imaps)
995/tcp open (pop3 Service, Courier pop3s)

Jetzt zu meinen Fragen:
Macht es Sinn, ausgewählte Ports (z.B. 106??, 110, 143, 587) abzuschalten?
Falls ja, kann ich die Ports auch ohne Firewall in reboot-fester Weise abschalten, also z.B. über eine Konfigurationsdatei?
Falls nein, was kann ich (ohne Firewall) machen, um meine Email Sicherheit zu erhöhen, ohne unbedarftere spätere Nutzer allzu sehr zu behindern.

Bin für jeden Input dankbar, egal ob Link, zielführendes Stichwort oder Tip für die richtige Richtung. Und bevor üble Rügen kommen. Nein, mein Mail Server ist vorerst schlafen geschickt – ich wecke ihn derzeit nur, während ich an ihm weiterbastle

Wünsch Euch schon mal ein angenehmes Wochenende – baut nicht zu sehr auf gutes Wetter. Die Regenmengen, die gerade auf mich herab prasseln, sind morgen bei Euch.

Grüße,

Thomas

 

[BruceLee]

Alle Ports, die du nicht offen haben willst, kannst du natürlich schließen, solange die von dir gewünschten Funktionen nicht beeinträchtigt werden.
Die services werden über /etc/xinted.d geladen. Du könntest also die nicht benötigten Ports damit schließen indem du die nötigen Dateien löschst/verschiebst/auskommentierst...
Ob Plesk da allerdings ständig dran rumwerkelt weiß ich nicht.

Des weiteren könntest du auf Horde verzichten, wenn du bei den Domains, die Webmail benutzen sollen, einfach eine Subdomain mit einem von dir bevorzugten Webmail-Cleint einsetzt.

 

[tsk]

Danke für Deine Hinweise. Die Dateien unter xinetd.d scheinen alle gleich aufgebaut. Plesk setzt einen Default - und erlaubt wohl, diesen zu überschreiben/ergänzen. Damit werde ich wohl klar kommen.

Was bleibt ist die Frage, ob dies Sinn macht. Gewinne ich damit tatsächlich an Sicherheit oder ziehe ich einen möglichen Angreifer durch eine reduzierte Portanzahl nicht genau zu den verbliebenen, offenen Ports, bei denen es tatsächlich etwas zu holen gibt?

 

[d4f]

oder ziehe ich einen möglichen Angreifer durch eine reduzierte Portanzahl nicht genau zu den verbliebenen, offenen Ports

Eins vorweg; du wirst kaum oder wahrscheinlich gar keine 'manuellen' Angriffe abkriegen sondern das automatisierte 'Grundrauschen' des Internet, sprich das Abklopfen auf dem Angriffsprogramm bekannte Sicherheitsluecken eines oder mehrerer Dienste.

Du reduzierst ausschliesslich das Risiko dass in einem der Dienste ein ausnutzbarer Fehler gefunden wird da weniger Dienste erreichbar sind. Allerdings sind mir in den aktuellen Versionen der genannten Dienste keine Sicherheitsluecken bekannt.

Interessant ist aber dass du nur pop3-ssl und imap-ssl erlauben willst; beachte das es Clients gibt die damit nicht klar kommen. Wenn es ein Sicherheitsloch in Courier, respektiv dessen POP3- oder IMAP-Modulen gibt dann ist dieses idR auf allen Ports (des Modules) ausnutzbar womit das Sperren der nicht-ssl Ports keinen einen Angriff auf den Server nicht hilft.

Die meisten Angriffe sind auch keine Exploit-Versuche sondern Bruteforce, was fail2ban beheben sollte.

 

[tsk]

Interessant ist aber dass du nur pop3-ssl und imap-ssl erlauben willst; beachte das es Clients gibt die damit nicht klar kommen.

Oh, das war mir nicht bekannt. Sind davon auch Major Mail Clients betroffen? Ich selbst arbeite seit Jahren nur mit Thunderbird, gehe aber davon aus, dass viele der späteren Kunden einen MS Client nutzen werden. Entweder, weil sie nicht anders können (Corporate Network) oder es nicht besser wissen.

Wenn es ein Sicherheitsloch in Courier, respektiv dessen POP3- oder IMAP-Modulen gibt dann ist dieses idR auf allen Ports (des Modules) ausnutzbar

Ja, ich denke, dass ist der Punkt. Kein direkter extra Gewinn an Sicherheit. Mein (noch in's Unreine gedachte) Gedanke ist, die non ssl-ports quasi als semi Honeypots zu nutzen. Die entsprechenden Ports bleiben offen, lehnen aber jeden Versuch einer Anmeldung ab. Im Gegansatz zu den ssl-ports, die tatsächlich bedient werden. Schaue ich in meine Logs, so sind die "normalen" Mail Ports deutlich frequentierter als die ssl Ports. Warum auch immer. Wäre das ein vernünftiger Ansatz?

Die meisten Angriffe sind auch keine Exploit-Versuche sondern Bruteforce, was fail2ban beheben sollte.

Angesichts meines kleinen vServers wollte ich eigentlich auf Denyhosts setzen, und mir Iptables komplett sparen. Je mehr ich jedoch darüber nachdenke, desto sinnvoller erscheint mir fail2ban. Mein ssh Zugang ist verriegelt und verrammelt - und macht mir keine wirklichen Sorgen mehr. Genau diese (und nur diese) maximale Sicherheit würde Denyhosts nochmals vergrößern. Macht wenig Sinn. Mit fail2ban könnte ich mich um die Ports bemühen, die mir aktuell die Sorgen bereiten.

Bin zumindest gedanklich schon deutlich weiter gekommen. Ich danke Euch für Euren Input.

 

[d4f]

Sind davon auch Major Mail Clients betroffen?

Nein. Outlook, Thunderbird und alle anderen ueblichen Clients haben dieses Problem nicht.

(Corporate Network)

In einem Corporate-Netz ist oft das Risiko dass (fast) alle Ports verriegelt sind und eventuell nur die nicht-verschluesselten offen sind.

die non ssl-ports quasi als semi Honeypots zu nutzen. Die entsprechenden Ports bleiben offen, lehnen aber jeden Versuch einer Anmeldung ab.

Das verwirrt viele End-Benutzer die ihren Client falsch konfiguriert haben.
Die Idee klingt aber nicht schlecht.

Schaue ich in meine Logs, so sind die "normalen" Mail Ports deutlich frequentierter als die ssl Ports.

Sie sind ueblicher und warum sollte in einem 0815-Setup ein Angreifer ueber den CPU-lastigeren SSL-Port fahren wenn er den unverschluesselten Port nehmen kann?

und mir Iptables komplett sparen.

ipTables ist ja eh drin. Ob du jetzt damit filterst oder nicht

 

[Joe User]

...den CPU-lastigeren SSL-Port fahren...

http://blog.koehntopp.de/archives/3033-Die-Kosten-von-SSL.html

 

[d4f]

Fuer Angreifer die mehrere Tausend gleichzeitige Verbindungen aufhaben ist die CPU-Belastung schon ein Faktor zumals diese Angriffe meist nicht von einer dedizierten Machine sondern moeglichst unauffaellig im Hintergrund gekaperter Rechner laufen sollen.

 

[tsk]

Das verwirrt viele End-Benutzer die ihren Client falsch konfiguriert haben.
Die Idee klingt aber nicht schlecht.

Ja, ich werde aber niemals "allgemeines" Hosting anbieten, sondern ausschließlich Hosting für TYPO3 und ZF Projekte, die ich für meine Kunden realisiere. Da gehört es (leider) für mich sowieso dazu, kundenseitige Email Clients einzurichten. Dafür kann ich dann auch restriktivere Spielregeln festlegen, ohne das dies meine Kunden behindert.

ipTables ist ja eh drin. Ob du jetzt damit filterst oder nicht

Stimmt Ich denke, ich werde einfach ein bißchen filtern - die Kirche aber trotzdem im Dorf lassen. fail2ban scheint mir hier die Idealbesetzung.