ubuntuusers.de

Nach ein paar weiteren Runden in meiner Testumgebung konnte ich feststellen, das die Anwesenheit des gpg-agents (oder dessen Abwesenheit als laufender Prozess) keine besonderen Auswirkungen auf die Funktionsfähigkeit von webmin hat.

Da du schreibst, dass es auf test funktioniert, auf prod aber nicht: Wie sieht die Firewallkonfiguration der beiden aus? Dazu bitte mal die Ausgabe von iptables-save überprüfen und ggf. auch hier einfügen. Wenn du Informationen daraus anonymisieren willst, konzentriere dich auf das Entfernen öffentlicher IP-Adressen, identifizierender Eigennamen und vergleichbare Dinge.

Noch eine Anmerkung zu

Emma2 schrieb:

Alle drei Aufrufe https://myprod, https://myprod/sogo und https://myprod/iredadmin funktionieren aber.

Aufrufe an HTTPS ohne Portangabe werden per Definition an Port 443 geschickt, auf dem nach aktuellem Stand der Diskussion ein funktionierender nginx hängt. Du willst aber Port 10000 testen, was bedeutet, dass du an den Hostnamen noch die :10000 anhängen musst. Wenn du weiter ohne Portnummerangabe testest, bestellst du bei dem Mitarbeiter am MCDonald's Schalter gewissermaßen Burger Kind-Angebote. Der Mitarbeiter versteht deine Worte und kann dir auch etwas verkaufen. Aber eben keinen Whopper.

Sorry. da war ich missverständlich: Was ich meinte, war: https://mytest:10000/ funktioniert, während https://myprod:10000/ ins Leere läuft, einen Timeout meldet.

Die Firewall-Einstellungen "sollten" gleich sein, denn ich habe da zunächst gar nichts eingestellt; ich sehe aber sofort nach...

Auf dem funktionierenden mytest ist die Ausgabe leer. Auf dem zickenmachenden myprod steht:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

admin@myprod:~$ sudo iptables-save
# Generated by iptables-save v1.6.1 on Mon Oct 28 08:37:14 2019
*filter
:INPUT DROP [104492:16099960]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1738061:696535636]
:f2b-postfix - [0:0]
-A INPUT -p tcp -m multiport --dports 80,443,25,587,465,110,995,143,993,4190 -j f2b-postfix
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A f2b-postfix -j RETURN
COMMIT
# Completed on Mon Oct 28 08:37:14 2019

Wie in meinem Posting (23. Oktober 2019 10:39) geschrieben, scheint es mir so, als käme ich auf Port 10000 nicht durch. Wie und wo überprüfe ich denn die Firewall-Einstellungen? "ufw status" liefert jedenfalls ein "Status: inactive".

Aber, zur Erinnerung:

1 2 3 4

emma2@clientpc:~$ nc -zvw 3 mytest 10000 Connection to mytest 10000 port [tcp/webmin] succeeded! emma2@clientpc:~$ nc -zvw 3 myprod 10000 nc: connect to myprod port 10000 (tcp) timed out: Operation now in progress

iptables sind ein Steuerungsmechanismus in Linux für die Verarbeitung von Netzwerkpaketen. Unter anderem kann man in iptables eine Firewall implementieren, was auf deiner Produktionsumgebung auch geschehen ist. Was du hier siehst, sind einzelne Regeln, wie mit Datenpaketen umgegangen werden soll. Viele Firewall-Tools (wie auch ufw) bilden einen Wrapper um iptables und wollen damit die Konfiguration erleichtern. Mal klappt es besser, mal schlechter.

Das Gute ist also, dass wir nun wissen, warum Webmin auf deinem Test funktioniert aber nicht auf Prod. Wenn zutrifft, dass iptables-save auf Test keine Regeln ausgegeben hat und für die Chains INPUT und FORWARD ACCEPT statt DROP steht, dann kann einfach jeder auf Test zugreifen und mit den von dort angebotenen Diensten kommunizieren. Wenn dein Test auch ein öffentlich zugänglicher Host mit schwachen Passworten ist, solltest du an einigen der Details in diesem Absatz etwas ändern.

Dein Prod ist bzgl. der Firewall-Konfiguration wesentlich besser abgesichert. Die Chains INPUT, OUTPUT und FORWARD stehen für die drei Standardwege, die ein Paket im Netzwerkstack des Kernels nehmen können: Aus dem Netzwerk zu einem Prozess auf demselben Host hin, von einem Prozess ausgehend ins Netzwerk und als Weiterleitung ohne Einbindung eines lokalen Prozesses. Letztere Chain ist für Router interessant.

INPUT und FORWARD haben als Policy DROP definiert. Eine Policy gibt an, was mit einem Paket passieren soll, wenn es dir Chain vollständig durchlaufen hat und nicht zwischenzeitlich durch andere Regeln behandelt wurde. Hier heißt das also, dass diese Pakete verworfen werden sollen.

Damit du auf den Webmin zugreifen kannst, musst du also den Port 10000 freigeben. Im laufenden System sollte ein ein

sudo iptables -A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT 

reichen, wobei ich mir bei der ersten Regel mit den Multiports nicht sicher bin, ob du da nicht eigentlich auch noch rein müsstest bzw. anstelle von -A -I verwenden. Vorher in der manpage von iptables nachschauen, wie du -I die richtige Stelle zeigst. Hinweis: Während -A eine Regel am Ende der Chain anhängt (a = append), fügt -I die neue Regel an einer bestimmen Position ein (i = insert). iptables hat Optionen, mit denen du die Regeln nummeriert ausgeben kannst und wenn das Platte Beispiel oben nicht klappt, könntest du es erstmal mit -I versuchen, die Regel vor der Multiport-Regel einzufügen.

Um das dauerhaft wirksam einzustellen, müsstest du herausfinden, wer auf deinem Host die Regeln so gebaut hat. Das f2b-postfix deutet darauf hin, dass du mindestens fail2ban einsetzt. Schau dir das mal im Wiki an und vielleicht findest du dort schon eine Möglichkeit, das entsprechend zu konfigurieren.

Wichtig: Sobald du mit iptables herumspielst, gefährdest du deine Netzwerkverbindung zum Server. Wenn du also keine anderen Möglichkeiten zum Steuern hast (iLO, IMM, Bildschirm mit Maus und Tastatur), musst du entweder sehr vorsichtig sein oder erstmal eine ausreichend vergleichbare Testumgebung aufbauen.

Benutzt du auf dem Host ggf. noch so etwas wie Plesk oder irgendein anderes Adminpanel?

Zunächst meinen lieben Dank: Deine "platte Lösung" hat auf Anhieb funktioniert! 😊 BTW: Der Host ist (noch) ein Hyper-V (ja, es gibt noch ein paar Aufgaben...), und ich habe einfach vor dem Testen einen Snapshot erstellt.

Aber habe ich das nun richtig verstanden, dass diese Änderung nur temporär ist? Wer die Regeln so eingestellt hat? Ich jedenfalls nicht (natürlich war ich das, aber nicht bewusst)... sollte ich also annehmen, dass ich meine beiden iRedMail-Installationen doch nicht vollkommen gleich durchgeführt habe?

Dann würde ich mich über ein bisschen weitere Hilfe (ggf. Lesetipps) freuen, wie ich das "reparieren" kann? BTW: Die Rechner sind (bis auf IMAP und SMTP) nur von innen zu erreichen, ich würde annehmen, dass ich dann dort keine Firewall brauche (oder zeugt das wieder von meiner Unkenntnis?)...

Emma2 schrieb:

Aber habe ich das nun richtig verstanden, dass diese Änderung nur temporär ist?

Ja. Kürzlich hatte hier jemand Erfolg, die Regeln mit iptables-persistent dauerhaft zu speichern. Eine kurze Anleitung gibt hier 🇬🇧.

Wer die Regeln so eingestellt hat? Ich jedenfalls nicht (natürlich war ich das, aber nicht bewusst)... sollte ich also annehmen, dass ich meine beiden iRedMail-Installationen doch nicht vollkommen gleich durchgeführt habe?

Sieh es so: Da du anscheinend bei der Installation beider Systeme nicht besonders aufmerksam warst, ist die Annahme doch viel besser, dass du es versehentlich anders gemacht hast, als dass jetzt schon jemand ohne dein Wissen Dinge auf deinem System anstellt.

Dann würde ich mich über ein bisschen weitere Hilfe (ggf. Lesetipps) freuen, wie ich das "reparieren" kann?

Insgesamt empfehle ich dir, die Installation beider Systeme nach Möglichkeit nochmal ganz von vorn anzugehen. Du gleichst jeden Schritt mit der Anleitung ab und dokumentierst jede Abweichung von dieser und auch jede anderlautende Konfiguration, die du vornimmst. Bevor du einen Schritt auslöst oder eine Abfrage bestätigst, überprüfst du, ob du die stattfindende Aktion vollständig verstehst. Wenn nein, dann so lange nicht weitermachen, bis das der Fall ist.

Durch die Menge an Dokumentation, die du lesen und erstellen musst, macht es vielleicht keinen Spaß. Allerdings ist es dann bedeutend einfacher für dich, den genauen Punkt zu finden, and dem du abgewichen bist und eventuell auch nachzuvollziehen, warum.

BTW: Die Rechner sind (bis auf IMAP und SMTP) nur von innen zu erreichen, ich würde annehmen, dass ich dann dort keine Firewall brauche (oder zeugt das wieder von meiner Unkenntnis?)...

Jeder Port, der aus dem Internet erreichbar ist, muss ordentlich abgesichert werden, vor allem wenn es sich um bekannte Port- und Protokollkombinationen handelt. Hier helfen Lösungen wie fail2ban und auch Internetsuchen à la "How to secure <service>?". Machst du das nicht, bindest du unnötig Systemressourcen (die Abwehr der Pakete von einem bestimmten Host ist günstiger als das Fehlschlagen des Anmeldeprozesses beim z.B. IMAP-Server), reduzierst die Sicherheit (irgendwann findet der Bot die richtige Kombination aus Anmeldename und Passwort) und störst oder gefährdest mitunter andere (Verwendung des eigenen Systems als Spam Bot, DDNS-Teilnehmer).

Sieh es so: Wie gern würdest du in einem Flugzeug sitzen, das von Menschen entworfen und gebaut wurde, die irgendwann mal eine Dokumentation zum ersten Flug der Gebrüder Wright gesehen haben? Hier geht's nicht mehr um Heitataita sondern um teilweise ernsthafte wirtschaftliche Folgen - und hoffentlich nicht um Menschenleben.

Danke!