Man kann auch so rangehen:
Alles was gesperrt wird, loggen (Log für Default-Deny-Regel am Ende der Filter-Kette). Nur freigeben, was man bekanntermaßen benötigt. Also vor der Default-Deny-Regel. Was unbekannt war - aber benötigt wird (siehe "Drop-Logs" und Nachdenken/Recherche darüber) im Nachhinein und wiederum vor der Default-Deny-Regel freigeben.
Zuletzt Scan von außen mit nmap. Ist nicht Allheilmittel - aber schon mal gut zu wissen, was von außen erreichbar ist.
Die GUI für nmap ist zenmap. Für Nichtexperten ganz hilfreich. Default-Scans kann man ändern/erweitern.
Eine Stateful Packet Inspection Firewall (auch mit iptables auf einem Linux-Host/Server realisierbar) sperrt erst mal alles aus der Gegenrichtung: Initiierter Traffic nur von 1 Seite möglich, also (meist) LAN/Server -> WAN/Internet. In die SPI-FW "bohrt" man bei Bedarf einzelne, wohlüberlegte "Löcher" (Ports) für Erreichbarkeit von Diensten im LAN (oder auf Server) vom WAN/Internet.
[Erledigt] Verständnisfrage zu fail2ban und iptables
Re: [Erledigt] Verständnisfrage zu fail2ban und iptables
Das stimmt nicht, mailx wird nur als Paket empfohlen, aber definitiv nicht gleichzeitig mit fail2ban installiert. Entweder war exim vorher schon installiert, oder es wurde nachträglich installiert. Und wenn man exim nicht will oder nicht benötigt, kann man testweise auch einfach den Dienst stoppen.EEK hat geschrieben:15.12.2017 09:14:42Also zunächst Mal, um dir zwei Beispiel zu nenne. Fail2ban installiert bei mir unter Debian „bsd-mailx“ mit und öffnet den smtp Port.
Code: Alles auswählen
systemctl stop exim4.service
Code: Alles auswählen
systemctl disable exim4.service
Re: [Erledigt] Verständnisfrage zu fail2ban und iptables
Na gut, dann stimmt es eben nicht. Dann frage ich mich nur, warum "bsd-mailx" vor der Installation von fail2ban nicht installier war, und danach schon, obwohl "exim" nicht installier ist und das unter Debian, Ubuntu und CentOS.TomL hat geschrieben:15.12.2017 10:40:12Das stimmt nicht, mailx wird nur als Paket empfohlen, aber definitiv nicht gleichzeitig mit fail2ban installiert. Entweder war exim vorher schon installiert, oder es wurde nachträglich installiert.EEK hat geschrieben:15.12.2017 09:14:42Also zunächst Mal, um dir zwei Beispiel zu nenne. Fail2ban installiert bei mir unter Debian „bsd-mailx“ mit und öffnet den smtp Port.Code: Alles auswählen
systemctl stop exim4.service
Na dann, weil es hier (was nur ein Beispiel war) Quatsch ist, ist es natürlich grundsätzlich Quatsch eine Port zu sperren. Abgesehen davon, hatte ich geschrieben, dass ich den Port (egal welchen) vielleicht auch nur zum Testen sperren will. Aber wenn du sagst, es ist Quatsch, muss das natürlich für die gesamte Menschheit und auf jeden Fall stimmen.TomL hat geschrieben:15.12.2017 10:40:12Und wenn man exim nicht will oder nicht benötigt, kann man testweise auch einfach den Dienst stoppen.
Danach wird auf Port 25 nicht mehr gelauscht. Darüber hinaus ist es m.M.n. sowieso Quatsch, den Port zu sperren, weil eh nur auf Localhost gelauscht wird. Imho kann der Port also gar nicht von außerhalb des PCs missbraucht werden. Und wenn man den Dienst wirklich dauerhaft nicht nutzt, wird er endgülltig deaktiviert:Code: Alles auswählen
systemctl disable exim4.service
Re: [Erledigt] Verständnisfrage zu fail2ban und iptables
Exim ist der default-mta im Paket bsd-mailx. Ich weiss nicht, was mit ubuntu ist, oder mit centos, und das interessiert mich auch nicht, unter Debian wird es jedenfalls nicht per default mit fail2ban installiert:EEK hat geschrieben:15.12.2017 11:19:48Dann frage ich mich nur, warum "bsd-mailx" vor der Installation von fail2ban nicht installier war, und danach schon, obwohl "exim" nicht installier ist und das unter Debian, Ubuntu und CentOS.
Code: Alles auswählen
apt install fail2ban -s
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
The following additional packages will be installed:
python3-pyinotify python3-systemd whois
Vorgeschlagene Pakete:
mailx system-log-daemon monit python-pyinotify-doc
Die folgenden NEUEN Pakete werden installiert:
fail2ban python3-pyinotify python3-systemd whois
0 aktualisiert, 4 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Inst fail2ban (0.9.6-2 Debian:9.3/stable [all])
Inst python3-pyinotify (0.9.6-1 Debian:9.3/stable [all])
Inst python3-systemd (233-1 Debian:9.3/stable [amd64])
Inst whois (5.2.17~deb9u1 Debian:9.3/stable [amd64])
Conf fail2ban (0.9.6-2 Debian:9.3/stable [all])
Conf python3-pyinotify (0.9.6-1 Debian:9.3/stable [all])
Conf python3-systemd (233-1 Debian:9.3/stable [amd64])
Conf whois (5.2.17~deb9u1 Debian:9.3/stable [amd64])
Bitte verdreh nicht meine Aussagen in eine Richtung, die nichts mit meiner Aussage zu tun haben. Ich habe das "Quatsch" allein auf den Sachverhalt "localhost" bezogen und auf meine Eingangsfrage in meinem ersten Post, was man überhaupt erreichen will. Und wenn Du ein Beispiel nennst, solltest Du auch akzeptieren, wenn andere diesen Andwendungsfall als "sinnbefreit" einschätzen. Wenn das Ziel allerdings ist, einfach nur mal zu sehen, ob man imstande ist, einen Port zu sperren... dann ist das auch kein Quatsch. Die Kernfrage bleibt jedoch, was man für den Produktivbetrieb erreichen will. Und für den Produktivibetrieb gibt es m.E. sinnvolle echte Lösungen und Lösungen, die nur vermeintlich was lösen. Insbesondere haben Iptables und Virenscanner unter Linux ein großes Potential für Missverständnisse, wenn man nicht Windowsgewohnheiten in seinen Zielvorstellungen ausblendet....ist es natürlich grundsätzlich Quatsch eine Port zu sperren. Abgesehen davon, hatte ich geschrieben, dass ich den Port (egal welchen) vielleicht auch nur zum Testen sperren will. Aber wenn du sagst, es ist Quatsch, muss das natürlich für die gesamte Menschheit und auf jeden Fall stimmen.
Re: [Erledigt] Verständnisfrage zu fail2ban und iptables
Gut, mag sein, dass ich das bei Debian falsch in Erinnerung hatte, und das Beispiel wirklich falsch/Quatsch war. Ich kann die Zeit nicht zurückdrehen um es zu kontrollieren. Auf meiner Debian VM ist jedenfalls kein exim, dafür aber fail2ban und bsd-mailx. Aber lassen wir das, ich will gar nicht behaupten, dass ich hier Recht habe.TomL hat geschrieben:15.12.2017 12:00:14Exim ist der default-mta im Paket bsd-mailx. Ich weiss nicht, was mit ubuntu ist, oder mit centos, und das interessiert mich auch nicht, unter Debian wird es jedenfalls nicht per default mit fail2ban installiert:EEK hat geschrieben:15.12.2017 11:19:48Dann frage ich mich nur, warum "bsd-mailx" vor der Installation von fail2ban nicht installier war, und danach schon, obwohl "exim" nicht installier ist und das unter Debian, Ubuntu und CentOS....ist es natürlich grundsätzlich Quatsch eine Port zu sperren. Abgesehen davon, hatte ich geschrieben, dass ich den Port (egal welchen) vielleicht auch nur zum Testen sperren will. Aber wenn du sagst, es ist Quatsch, muss das natürlich für die gesamte Menschheit und auf jeden Fall stimmen.
Mal abgesehen davon, dass es überhaupt nicht meine Absicht war, hier irgendwas zu verdrehen, machst du das doch bei mir die ganze Zeit. Das Einzige was ich gesagt haben, und das habe ich mittlerweile oft genug wiederholt, war, dass man nicht unbedingt für alles immer Profi sein muss, um es richtig zu machen. Auch Debian nicht grundsätzlich sicher sein muss. Dass ich mir, trotz Komplexität von iptables, trotzdem zutrauen würde, einen Port per itables zu sperren. Und es sehr wohl Fälle gibt, sei es nur zum Testen, einen einzelnen Port zu sperren. Von „das macht man so“ oder „das ergibt Sinn“… habe ich nie ein Wort gesagt. Aber sobald ich „iptables“ schreibe, wird mir hier unterstellt, dass das was ich vorhabe (was habe ich denn eigentlich vor? Meine Ausgangsfrage ist längst beantwortet, und auch das habe ich bereits gesagt) ja Quatsch und Sinnlos ist. Und selbst wenn es keinen Fall in der Praxis gäbe, bei dem es Sinn macht, dann gehöre zumindest ich zu den Menschen, die „learning by doing“ bevorzugen, weil dadurch wesentlich schneller und besser lerne. Und spätestens dann macht es Sinn, weil ich zumindest sehe, dass das nichts bringt und/oder es bessere Alternativen gibt.TomL hat geschrieben:15.12.2017 12:00:14Bitte verdreh nicht meine Aussagen in eine Richtung, die nichts mit meiner Aussage zu tun haben. Ich habe das "Quatsch" allein auf den Sachverhalt "localhost" bezogen und auf meine Eingangsfrage in meinem ersten Post, was man überhaupt erreichen will. Und wenn Du ein Beispiel nennst, solltest Du auch akzeptieren, wenn andere diesen Andwendungsfall als "sinnbefreit" einschätzen. Wenn das Ziel allerdings ist, einfach nur mal zu sehen, ob man imstande ist, einen Port zu sperren... dann ist das auch kein Quatsch. Die Kernfrage bleibt jedoch, was man für den Produktivbetrieb erreichen will. Und für den Produktivibetrieb gibt es m.E. sinnvolle echte Lösungen und Lösungen, die nur vermeintlich was lösen. Insbesondere haben Iptables und Virenscanner unter Linux ein großes Potential für Missverständnisse, wenn man nicht Windowsgewohnheiten in seinen Zielvorstellungen ausblendet.