Offene Ports um Mail zu senden (javamail)

Java-Forum Netzwerkprogrammierung
1

Hey,

ich möchte ein Mail von einem Server aus via javamail API senden. Ich möchte per SSL über Port 465 versenden. Wenn ich in der Firewall alle Ports aktiviere, funktioniert alles einwandfrei. Um möglichst wenig Angriffsfläche zu bieten, würde ich aber gerne nur Ports offen lassen, die auch benötigt werden. Sobald ich explizit auf dem Server Port 53 (UDP/TCP) in beide Richtungen; und Port 465 (TCP) in beide Richtungen öffne und den Rest schließe, kommt eine java.net.UnknownHostException.

Deswegen wollte ich fragen, welche Ports ich öffnen muss (Eingehend/Ausgehend), um eine Mail an einen smtp-server auf Port 465 zu schicken.

mfg,
BH16

2

Guckst du hier

http://www.tutorialspoint.com/javamail_api/javamail_api_smtp_servers.htm

Da steht was von tcp port 25

3

Auch mit Port 25 findet er den Server nicht. Es scheint am DNS zu liegen, vermute ich, denn Laut Exception (java.net.UnknownHostException) kann er den Host ja nicht einmal auflösen. Da ich aber bereits Port 53 (eigentlich DNS) geöffnet habe, frage ich hier.

Trotzdem danke für die Antwort, icdh werde den Port zum testen mal weiter offen lassen.

mfg
BH16

4

Was soll sich die Firewall bringen?

5

Wenn du eine Firewall mit Stateful inspection hast (heutzutage State of the art), dann brauchst du nur ausgehend TCP Port 465 und ausgehend UDP Port 53 zu öffnen. Du musst aber darauf achten, dass Stateful inspection auch aktiviert ist (sowohl für TCP als auch für UDP).
Wenn die Firewall das nicht kann, musst du eingehend zusätzlich alle Ports größer 1023 öffnen, sowohl TCP als auch UDP.

Port 25 ist der SMTP Port. Wenn der Mailanbieter nur per SMTPS erreichbar ist, dann ist 465 der richtige Port. Besser wäre allerdings Port 25 mit STARTTLS - das ist aber eine Konfiguration beim Anbieter. Beide Ports brauchst du auf jeden Fall nicht gleichzeitig freizugeben.

6

Ich denke, sie soll den Zugriff von außen nach innen und anders herum auf nur bestimmte Ports zulassen, um die Sicherheit zu erhöhen :slight_smile:

Ich nutze einen 1und1 Vserver, der anscheinend keine Stateful inspection hat :confused: (zumindest konnte ich über Parallels Power Panel nichts finden).

Entstehen denn irgendwelche Sicherheitslücken, wenn ich all diese Ports offen lasse? Oder ist das kein Risiko, da der Server auf den Ports eh keinen Service anbietet?

mfg
BH16

7

Solange kein Port offen ist, ist dieser nicht angreifbar. Somit auch keine iptables nötig.

8

Naja, 1&1 halt, hab ich auch mal für Support gemacht (wenn auch “nur” DSL). Beim Hosting anzurufen wird dir wenig bringen da die Leutz da auch nich wirklich Plan haben (hab ich mal gemerkt als ich intern da im BO durchgeklingelt um ne KD-Anfrage zu klären, letzten Endes hab ich dann selbst ne Lösung gefunden).

Grundsätzlich würde ich schon erstmal and TCP/465 zweifeln da dies SMTPS ist und bekanntermaßen auf SSLv3 setzt. Deutlich besser ist wirklich TCP/25 bzw TCP/587 mit STARTTLS, aber wie schon erwähnt : hängt vom Mail-Server-Provider ab.
Darüber hinaus wird TCP/25 grundsätzlich auch für die inter-Serverkommunikation zwischen zwei Mailservern genutzt und muss wenn du selbst einen Mail-Server hostet sowohl eingehend offen sein damit du Mails empfangen kannst als auch ausgehend damit dein MTA Mails auch an andere Server rausschicken kann.

Schon sehr merkwürdig ist die UnknownHostException die ja, wie du richtig erkannt hast, darauf hinweist das was bei der Namensauflösung schief läuft. UDP/53 ist default, TCP/53 ist backup falls die UDP-Kommunikation fehlschlägt. Es hängt aber auch immer vom OS und dessen Implementierung ab wie überhaupt aufgelöst wird und ob überhaupt der Fallback über TCP/53 genutz wird. In der Regel sollte DNS sowohl eingehend als auch ausgehend vom System her automatisch frei sein (und wenn mans dicht macht kommt es zu eben solchen Problemen).

Ich gehe also mal von aus das iptables irgendwie komplett versaut sind. Hier würde ein komplettes clean abhilfe schaffen (gibt dazu laut Google recht einfache commands, zur Not kann man auch glaub ich im Rescue-Mode einfach entsprechende configs löschen und das OS neue defaults bauen lassen). Bezüglich Parallels : ach ja, damit hab ich auch schon so meine Erfahrungen machen dürfen. Kracht sich gerne mal mit Unix iptables. Günstig (zumindest als ich mal so n Ding hatte) : Parallels-Firewall komplett abschalten (sofern möglich, ansonst halt alles ausgehend und eingehend aufmachen) und alles über die OS-Firewall/iptables regeln. Andersrum würde ich dir nicht empfehlen. Auch selbst wenn Parallels da mitlerweile nachgebessert haben sollte. Mit solchen VPS-Firewalls gibts halt immer nur Probleme, ist einfach so.

Auch wäre mal die Frage : zu welchem Server verbindest du dich eigentlich ? Hast du auf deinem VPS einen eigenen MTA aufgesetzt oder nutzt du einen externen ? Ein bissl Code wäre auch hilfreich da ich die typischen “copy’n’paste” Fehler vermute da man im Netz leider nur sehr schlechte Codes findet.

Auf jeden musst du erstmal die Namensauflösung hinbekommen, der Rest sollte dann nur noch einfaches tweaking sein.

Bezüglich der Sicherheit : eine Restriktion von außen nach innen braucht man in der Regel nicht da wie schon erwähnt : nur Ports die überhaupt von irgendwelchen Programmen offen sind können angegriffen werden. Und für die paar internen kann man einfach ein iptable-DENY machen. Ausgehend wäre ich schon etwas restriktiver und verfolge zumindest auf meinen eigenen Server die Idee : nur das nach außen öffnen was ich kenne. Ich will halt nich das “ET mal eben nach Hause telefonieren” kann.

9

Das ich das noch erleben darf: Ein kommentar von dir, in dem du micht sofort explizit als Idiot da stehen lässt :stuck_out_tongue:

Nene, Spaß beiseite - Danke für deine Antwort. Da du dich anscheinend sehr gut mit 1und1 auskennst, werde ich mal mit allen Informationen rausrücken :slight_smile:

Ich habe als Student per 1und1 Campus Code einen VServer L für 8ct pro Monat bekommen (Kann ich nur jedem studenten empfehlen!) zusammen mit einer Domain und 250 1und1 Mail-Adressen. Den Server möchte ich als HTTP-Server und Server für unser Spiel nutzen. Ich habe für den Zugriff per FTP bereits TLS funktionierend eingerichtet und Apache läuft auch bereits. SSH natürlich als standart mit dabei.

Ein Tutorial für das Senden von Mails habe ich hier gefunden, und es funktioniert von meinem PC aus und vom Server aus, wenn ich alle Ports offen habe. Testweise hatte ich SSL probiert, werde aber auf Anraten von euch und nach kurzer Recherche TLS nutzen.

Am Code selber kann es also eigentlich nciht liegen, nur an den Port-Regeln.

Wenn du aber meinst, dass ich lieber auf iptables anstatt der Firewall setzen sollte, werde ich mich wohl mal in iptables einarbeiten und darauf umstellen. Probleme habe ich sonst mit der 1un1 Firewall eigentnlich nciht, sie macht, was sie soll.

Hier sind meine Portregeln ausgehend (eingehend ist hier wohl nciht sehr sinnvoll, sind eh nur genau die selben):

Hier ist gerade DNS TCP aktiviert, habe es aber auch mit UDP und auch mit beidem probiert in beide Richtungen.

mfg
BH16

10

Nicht ganz. TCP Port 25 eingehend bei eigenem Mailserver ist soweit richtig. Ausgehend wird auch bei SMTP Port > 1023 verwendet (geht unter Unix auch gar nicht anders, weil die Ports bis einschließlich 1023 privilegiert sind und root-Rechte benötigen, um geöffnet zu werden).

TCP Port 53 ist nicht fallback, sondern wird verwendet, wenn die Nachrichten zu groß werden. Das ist bei einem Zonentransfer der Fall. Standardmäßig braucht man also kein TCP, es ist aber auch nicht schlimm, wenn man den Port auch auf TCP öffnet.

Die sind komplett falsch. Für den ausgehenden Verkehr musst du auch den Destination Port verwenden. Also die Angaben aus dem Source Port jeweils in Destination Port verschieben, aus dem Source Port any machen (komplett richtig wäre > 1023, ist aber kein großes Sicherheitsrisiko, wenn man dort any einträgt). Und bei der dns-Regel udp statt tcp oder die Regel für tcp / udp machen. Dann sollte das funktionieren.
Die eingehenden Ports brauchst du aller Wahrscheinlichkeit nach nur für deine eigenen Dienste zu konfigurieren. Die „Rückrichtungsregeln“ brauchst du wie in meinem ersten Post gesagt normalerweise nicht mehr.

11

@BH
Nein, war ja nicht gegen dich gerichtet sondern eigentlich eher informativ da ich halt die Interna von 1&1 kenne. Und glaub mir, die haben noch weit aus größere Sicherheitslücken und Probleme als „nur“ VPS-Firewalls die nicht so wollen wie du es ihnen sagst. An die direkt Zuständigen, also wirklich die Typen die da durchs Rechenzentrum flitzen und in der Warte am Kontrollsystem sitzen, kommste auch intern nicht ran. Das läuft da alles nur über teilweise ziemlich umständliche Ticket-Systeme. Die bekommen es halt nicht nur nicht hin ihr eigenes Intranet mal auf die Reihe zu bekommen (was da so teilweise ablief kann ich dir ja mal als ne Top-10 fertig machen) sondern halt auch gerade was Kundensysteme angeht sind sie quasi Meister im Scheißebauen.

Ja, hast ja recht. Ich meinte damit aber das man in der Firewall/iptables auch angeben muss das der MTA-service auch überhaupt „raus darf“, also das halt eine Regel existiert die eine ausgehende Verbindung auf den Ziel-Port TCP/25 erlaubt. Das der Source-Port natürlich irgendwo >1024 liegt ist mir auch bewusst.
Hab ich mal aus Interesse schnell ausprobiert : mache ich die ausgehende Regel auf Ziel-Port TCP/25 dicht so bekomme ich vom MTA einen Fehler das der Verbindungsaufbau gescheitert ist. Gebe ich diese Regel aber frei und mache, wie du gut erklärt hast, die Source-Ports dicht passiert selbiges.

Gut, dann hab ich da bei Wiki was falsch verstanden. Ist aber auch i-wie leicht verwirrend erklärt (zumindest das was ich gelesen/verstanden habe).

[QUOTE=cmrudolph;105145]Die sind komplett falsch. Für den ausgehenden Verkehr musst du auch den Destination Port verwenden. Also die Angaben aus dem Source Port jeweils in Destination Port verschieben, aus dem Source Port any machen (komplett richtig wäre > 1023, ist aber kein großes Sicherheitsrisiko, wenn man dort any einträgt). Und bei der dns-Regel udp statt tcp oder die Regel für tcp / udp machen. Dann sollte das funktionieren.
Die eingehenden Ports brauchst du aller Wahrscheinlichkeit nach nur für deine eigenen Dienste zu konfigurieren. Die „Rückrichtungsregeln“ brauchst du wie in meinem ersten Post gesagt normalerweise nicht mehr.[/QUOTE]
Ungefähr sowas meinte ich mit der Aussage das diese „VPS-Firewalls“ wie ich sie nenne gerne mal kompletten Müll machen / dazu neigen das User Fehlkonfigurationen machen.
Denn zumindest mit den Distributionen die ich bisher so hatte (waren jetzt nicht so viele, dafür aber auch leider nicht so verbreitete) war es vom default her so das erstmal grundsätzlich jede ausgehende Verbindung zugelassen und alles was „rein“ wollte geblockt wurde. Kenne mich da jetzt nicht bei allen aus und ich denke dass das so vermutlich auch nicht unbedingt erwünscht oder Standard ist, aber ich kann halt nur von dem Berichten was ich selbst erlebt habe und was mir halt (vermutlich auch nicht alles korrekt) erklärt wurde.

12

Danke für euere Antworten. Ich werde wohl also die VPS-Firewall wegschmeißen (alles auf Default-Accept setzen) und ausgehende Regeln per iptables definieren, wenn ich euch richtig verstanden habe.

Welche Ports müsste ich denn ausgehend nun freigeben, abgesehen von denen, die ich bereits brauche (siehe Liste oben), um Mails über SMTPS TLS zu versenden? Bzw. wie sollte ich die iptables generell konfigurieren, um eine möglichst hohe Sicherheit zu wahren?

mfg
BH16

13

SMTPS oder TLS ? Beides geht nicht =P.
Ansonsten : ausgehend eigentlich gar nichts weil wie gesagt default eigentlich “raus” alles darf außer du setzt halt so ne allgemeine DENY ALL Regel. Ansonsten : Source : > 1024 / Destitnation : entsprechender Ziel-Port.

14

Ein paar Sachen werden hier im Thread noch durcheinander geworfen. Plesk bietet auch nur ein grafisches Frontend für iptables. iptables für sich allein bringt einem noch nichts, da die Firewallregeln einen Neustart nicht überleben. Unter debian gibt es z. B. ein Paket iptables-persistent, welches die Speicherung der Regeln übernimmt. Erst dadurch überleben die Regeln den Neustart. Plesk übernimmt das mit einem bedienbaren Frontend. Ich glaube nicht, dass gegen dessen Verwendung etwas spricht. Wenn man parallel noch versucht die Regeln über ein anderes Paket zu laden, dann könnte es zu Problemen führen, weil die Reihenfolge der geladenen Regeln relevant ist.

TLS ist der neue Name von SSL (seit Version 3.0). Das kann man unter anderem auf Wikipedia nachlesen.

Bei SMTPS wird von Anfang an eine SSL/TLS-Verbindung aufgebaut. Bei “normalem” SMTP mit STARTTLS wird erst eine unverschlüsselte Verbindung aufgebaut, dann sagt der Mailserver: hey, ich kann auch verschlüsselt kommunizieren! Und dann erst wird die Verbindung verschlüsselt, falls der Client dem zustimmt. Die Konfiguration des Mailservers kann auch ausschließen, dass unverschlüsselte Verbindungen verwendet werden (zumindest für ausgehende Mails) - dann wird die Annahme einer Mail verweigert.

Es muss im übrigen > 1023 heißen. 1024 ist der erste unprivilegierte Port.

Prinzipiell halte ich von einer Firewall auf einem Server aber nicht allzu viel. Ich habe bei meinen Servern nur eine accept all-Regel und iptables nur aktiviert, weil ich fail2ban verwende. Ansonsten laufen keine Dienste, die nicht von außen erreichbar sein sollen. Und diejenigen, die nur über einen Proxy erreichbar sein sollen (z. B. Tomcat) lauschen auf localhost, sodass sie aus dem Internet nicht erreichbar sind.

15

Nah, da hast du jetzt aber ein paar Kleinigkeit durcheinandergewürfelt.

Hmm, also das Problem das nach nem Reboot meine iptable-Regeln weg waren hatte ich noch nie, liegt aber vermutlich an der verwendeten Distribution.

Bezüglich Host-Firewall vs Guest-Firewall : es kommt drauf an wie virtualisiert wird. Wenn nur eine VPS/KVZ hat die als Container läuft mag es zutreffen dass das Plesk-Panel auf die iptables-Regeln zugreift. Bei einer KVM-Hardwarevirtualisierung bildet sie hingegen eine zweite Ebene (vergleichbar mit zwei kaskadierten NAT-Routern).
Ich persönlich bevorzuge es jedoch solche Host-Firewalls komplett zu deaktivieren und nur innerhalb des Guest-OS selbst zu arbeiten. Erspaart einem so manchen Bug falls da irgendwas inkompatible ist.

Das TLS eine neue Bezeichnung für SSL ist stimmt soweit, nur mit der Version hast du dich vertan : TLS ist die Bezeichnung ab SSLv3.1

Bezüglich SMTPS : es ist abhängig von der genutzten Implementierung welches Level zum Einsatz kommt, meist wird jedoch noch SSLv3 genutzt statt sinnvoller weise TLSv1.x
Auch wird bei STARTTLS die Sicherung vom Client eingeleitet, nicht vom Server.
Bezüglich der Konfiguration welche Verbindunge akzeptiert werden und welche nicht : du glaubst gar nicht wie viele Leute selbst jetzt immer noch ungesicherte Verbindungen nutzen obwohl dies schon seit 15 Jahren und mehr von den meisten Providern angeboten wird. Ich hatte da genug am Rohr die plötzlich Panik geschoben haben “Mein Outlook funktioniert nicht mehr !” obwohl “EmiG” mehr als 6 Monate immer wieder angekündigt wurde.

Und ob nun 1023 oder 1024 oder 1025 … is doch egal. Meist wird doch eh irgendwo eine Range weit oberhalb von 20000 genutzt so das dieser eine Sonderfall das gerade irgendein wichtiger Prozess genau 1024 erwischt recht unwahrscheinlich und daher eigentlich zu vernachlässigen ist.

16

Ok, wenn Plesk eine Firewall „außerhalb“ des Servers konfiguriert, dann ist das sogar noch ein Sicherheitsgewinn. Denn dann kann man, sobald man Zugriff auf den Server hat, nicht einmal mehr mit root-Rechten die Firewallregeln umgehen. Das spricht allerdings eher für die externe als für eine interne iptables-Lösung. Auf meinen alten vServern konnte ich übrigens kein iptables verwenden, weil das aus Marketinggründen nicht im Kernel aktiviert war.

Der Server sagt: „ich kann STARTTLS“ (nach dem EHLO-Befehl des Clients) und dann startet der Client die Initialisierung. Wenn der Server das nicht sagt, wird ein RFC-konformer Client nicht versuchen eine TLS-Verbindung zu starten.

Ansichtssache. Port 1023 ist der oberste privilegierte Port und eine Konfiguration, die Ports erst ab Port 1025 freigibt, wäre falsch - off by one. Heutzutage ist es (wie oben geschrieben) sowieso egal, weil die gängigen Paketfilter stateful arbeiten (können).

17

Wie erwähnt : es kommt halt erstmal immer drauf an wie ein solcher “vServer” denn nun eigentlich realisiert wird.
Wird halt eine Container-basierte “emulation” genutzt (auch unter den Namen VPS/(Open)VZ sowie SharedHosting) so gibt es einen gemeinsamen Kernel (nämlich den des Host-Systems) über den dann auch alle guest-os laufen, jedoch über diese Container voneinander getrennt (was sich mehr aufs Dateisystem als auf die restlichen Rechenresourcen bezieht). Da die einzelnen VPS nun quasi lediglich Sub-Prozesse sind kann man auch direkt auf diese zugreifen was bei einem Bruch der Sandbox (relativ einfach über ein CallBack möglich) schwerwiegende Folgen haben kann. Auch werden hier Dinge wie Resourcenzuweisung, Firewall und ähnliches mehr durch direkte Interprozesskommunikation geregelt. alles in allem kann man sagen das der Gast durch die Bindung an den Host-Kernel ziemlich stark verzahnt ist. Außerdem können nur Linux-Gäste des gleichen Distributionszweiges (also z.B. Debian-Host unterstützt nur Debian-Gäste) verwendet werden.

Bei KVM läuft das alles ein wenig anders ab. Hier wird dem Gast-System über bestimmte Kernel-Module die Hardware direkt zugänglich gemacht, weshalb man auch von Hardwarevirtualisierung spricht. Der größte Unterschied dabei ist dass das Host-System nicht mehr die Ausführung direkt übernimmt sondern mehr nur noch eine Steuereinheit ist die für die Verteilung der Hardware-Resourcen an die VMs sorgt. Das hat nicht nur einen deutlichen Performancegewinn zu folge sondern ermöglicht auch das Nutzen beliebiger Gast-Systeme. So kann ein Linux-Host auch Windows-Gäste unterstützen. Auch kann man von der Host-Console nicht mehr direkt in die Gast-VM eingreifen da diese in einem eigenen Kernel-Modus läuft. So liegt das gesamte Dateisystem in einem verschlüsselten Container-File statt wie bei VZ direkt im Dateisystem des Hosts. Auch wird es durch die direkte Nutzung der Hardware-Resourcen möglich das wenn der Host z.B. mehrere NICs hat das diese von den Gästen direkt angesteuert werden können ohne dass das Host-System darauf Zugriff oder gar Einfluss hat (ist wie gesagt möglich, wird aber in der Praxis sowohl aus Sicherheitsgründen als auch z.B. zur Traffic-Erfassung nicht gemacht). Auch kann man z.B. den Host so konfigurieren das der Gast direkt auf ein physisches Laufwerk zugreifen kann was im Host garnicht gemountet ist (wird über spezielle Kernel-Treiber ermöglicht).
Einer der sehr großen Nachteile dieser Technik ist jedoch die schlechtere Skalierbarkeit und das Host/Gast-Verhältnis. Während bei einem VZ-sharing auf einem Host gut und gerne mal 50 bis 100 VM-Gäste laufen ist dies in einer KVM-Umgebung nicht möglich da beim Start der VM die zugeteilten Hardware-Resourcen komplett beansprucht werden und somit anderen nicht mehr zur Verfügung stehen, auch wenn der Gast diese nicht vollständig auslastet. So kommen auch bei sehr großen Host-Systemen meist kaum mehr als 10-15 Gäste zustande, auch unter anderem deshalb weil man KVMs in der Regel in deutliche höheren Leistungsklassen als VZ anbietet (VZ-Container haben z.B. nur 1000MHz rechenpower und 512MB RAM wohingegen eine KVM eine vollen Kern (mit voller Taktrate und daher auch Arbeitsleistung) erhält sowie meist mindestens 2GB-4GB RAM. Nimmt man also so ne gewöhnliche Standard-VM 2 Cores / 4GB RAM ist auch ein großes Host-System mit Multi-CPU und viel RAM schnell am Limit. Außerdem will man seinen Kunden ja auch noch gewissen Burst freihalten weshalb man ein Host also nicht bis zum Anschlag vollkracht.

Abhängig davon welches der zwei Verfahren nun überhaupt genutzt wird kommt halt auch der Punkt Firewall zum tragen. Wo bei einer VZ wie schon erwähnt das Host-Panel eine Art Front-End bildet und dann “von außen” über eine art “Super-Prozess” iptables oder ähnliches bearbeitet wird bei einer KVM eine weitere Ebene aufgebaut. Auch hat die KVM, da sie ihren eigenen Kernel hat und somit auch eigene Module laden kann, die Möglichkeit direkte Tunnel-Verbindungen zu nutzen die bei einem VZ-Container auch wieder über das Host-System laufen.
Ist schon alles ein bisschen tricky und man muss sich da schon näher mit befassen wie welche Technik eingesetzt wird, und natürlich kommts auch immer auf die Eigenheiten des Providers an, aber man kann trotzdem so grobe Richtlinien ausmachen.

@BH : wie Rudi schon ansprach kann die Plesk-Firewall durch ihre Funktionsweise eine zusätzliche Sicherheit sein, ich habe jedoch selbst leider immer nur schlechte Erfahrungen mit so einem Mist machen müssen und würde daher aus meiner Richtung eher von abraten. Oder besser ausgedrückt : du solltest dich halt nur auf eines festlegen und versuchen beide klar voneinander getrennt zu halten. Es kann bei “vermischen” von beiden zu ziemlich merkwürdigen Fehlern kommen die man auch beim dritten Nachprüfen immer noch nicht findet.

18

Ok jetzt bin ich vollends verwirrt, ihr habt es geschafft :slight_smile:

Zuerst einmal zu einem Post, der schon ein wenig zurück liegt:

[QUOTE=cmrudolph]
Die sind komplett falsch. Für den ausgehenden Verkehr musst du auch den Destination Port verwenden. Also die Angaben aus dem Source Port jeweils in Destination Port verschieben, aus dem Source Port any machen (komplett richtig wäre > 1023, ist aber kein großes Sicherheitsrisiko, wenn man dort any einträgt). Und bei der dns-Regel udp statt tcp oder die Regel für tcp / udp machen. Dann sollte das funktionieren.
Die eingehenden Ports brauchst du aller Wahrscheinlichkeit nach nur für deine eigenen Dienste zu konfigurieren. Die „Rückrichtungsregeln“ brauchst du wie in meinem ersten Post gesagt normalerweise nicht mehr.[/QUOTE]

Warum sind meine Regeln falsch? Ausgehend ist mit source port doch eigentlich der vom server sleber gemeint, oder nicht? Wenn jemand von Ausßen sich zu meinem Server verbinden möchte, kann er doch auch über einen anderen Port kommen als den, den ich nutze. Deswegen dachte ich, dass nur die Pakete raus dürfen, die bei mir vom source port ausgehen, der dem protokoll gehört (z.B. hat ein http-paket von mir den Source port 80, kann aber auch an port 124356 gesendet werden). Verstehe ich das so richtig?

Eingehend habe ich es genau anders herum konfiguriert und lasse nur pakete zu, die bei mir am jeweiligen destination port eingehen (z.B. wir ein paket vom clienten von port 123456 an mich als server an port 80 gesendet => destination port = 80). Ist das hier dann auch genau anders herum?

Da einer für und der andere gegen die VPS-FW ist, weiß ich jetzt selber nicht, was genau gegen sie spricht. Ich habe mit einem portscan gesehen, dass offene ports, wenn kein dienst dahinter ist, die selbe nachricht zurückgeben (keine) wie als wenn ich die FW auf drop eingestellt ist. Benötige ich in diesem Fall die FW überhaupt, was eingehende Verbindugnen angeht?

Was ausgehende Verbindungen angeht dachte ich, es würde mehr sicherheit geben, wenn ich nciht alles vom server aus raus lasse. Deswegen hatte ich da hauptsächlich die FW als sinnvol erachtet.
Sehe ich ich das richtig oder falsch oder inwieweit ist eine FW bei einem Server sinnvoll, wenn eh alle nicht interpretierten Pakete gedropt werden?

Wie muss ich jetzt ausgehen die Portregeln definieren, um mit TLS (siehe oberen Link, 1. Beispiel: Mail senden über TLS; lokal funktioniert es; Serverseitig noch nicht getestet, aber sollte mit allen Ports auch gehen und der DNS fehler wird wohl nicht weg sein; werd ich im Verlaufe des Tages testen) mails senden zu können?

mfg
BH16

19

So viel umständliche Beschreibungen. Zeig doch einfach mal die Ausgabe von iptables - L

20

Eine Firewall direkt auf dem zu schützenden System ist nur bedingt sinnvoll, weil sie sich auf dem selbigen konfigurieren lässt. Nach erfolgreichem Eindringen lässt sie sich also ggf. ausschalten oder durch Tricks umgehen, was bei einer externen Firewall nicht möglich ist. Falls die durch Plesk konfigurierte Firewall vor dem System sitzt und nicht nur die lokale Firewall konfiguriert, dann kann diese ein sinnvoller Schutz sein.

Wie oben schon geschrieben, ist eine Firewall auf einem Server nur in Spezialfällen sinnvoll. Ich nutze sie auf meinem Server, um mit fail2ban Bruteforce-Angriffe auf meine Dienste zu verhindern. Ansonsten laufen keine Dienste, die nicht benötigt werden.

Du möchtest eine Mail verschicken. Das Ziel (destination, der Mailserver, zu dem du dich verbindest) ist ein anderer Server. Im Paket steht die Ziel-IP und der Ziel-Port. Der Zielport entspricht dabei dem SMTP- oder SMTPS-Port. Der Quellport wird auf deinem Server mehr oder weniger zufällig vergeben, deshalb muss dort any stehen.

Wovor genau möchtest du dich schützen? Wenn jemand auf deinem Server ist, dann kann er schon ziemlich viel machen. Welches Szenario möchtest du verhindern?

*** Edit ***

Ausgehend entweder accept all oder ausgehend sowohl bei DNS für UDP den Port 53 und bei SMTP den TCP-Port 25 / 465 freigeben.

Die Regeln, so wie du sie angegeben hast, wären richtig, wenn du auf deinem Server die angegebenen Dienste betreiben würdest und die Firewall kein stateful packet inspection beherrschen würde, um die Antwortpakete zuzulassen.