Virenschutz unter Linux

[Trollkirsche]

Auf Wikipedia, bezüglich des TR-069 Protokolls:

Zudem ermöglicht es TR-069 auch andere Geräte zu konfigurieren, die sich im „sicheren Bereich“ hinter der Box oder dem Modem befinden, also hinter der Firewall.

Quelle : https://de.wikipedia.org/wiki/TR-069

Wie soll das gehen, wenn auf der Firewall der eingehende Traffic geschlossen wurde? Was kann man gegen solche Art von Angriffen unternehmen?

[TomL]

Nanana, da wird aber die Ubuntu Community keine Freude haben

Die halten sudo für ein Sicherheits-Feature, obwohl dort bekannt ist, dass es nicht dem eigentlichen Zweck entsprechend verwendet wird.... soll'n se machen.

Das versteh ich jetzt nicht.. Wie kann dir Firejail helfen, youtube Videos anzusehen obwohl du alle Scripte auf Misstrauen hast? (ich nehme mal an du nutzt noscript)

Nein, ich nutze kein NoScript, ich persönlich halte uBlock Origin für das NonPlus-Ultra. Das ist ein sehr radikaler Script-Blocker, der zudem auch Ad-Block kann. Aber das ist vermutlich auch Geschmacksache, was man da nutzt. Gesurft wird von mir eigentlich nur in einer isolierten VM-Bucht und Palemoon ist das Surfbrett... und für dessen uBlock Origin verwende ich keine fertigen Filter, sondern ich habe generell einfach alles verboten. Über Wochen und Monate habe ich UO dann an meine Gewohnheiten langsam angepasst, so das mein regelmäßiges Surfen nun funktioniert. In diesem Aspekt sind allerdings Google und alle anderen Datenkraken immer noch radikal blockiert. Und für solche seltenen Fälle öffne ich in der VM dann einen sonst nicht genutzten Firefox mit Firejail in einer jeweils privaten Neu-Sitzung ohne Filter.... also in einer Sitzung, in der sich nix gemerkt wird. Mein persönliches Browserprofil in meinem Homdir "thomas" auf meiner eigenen Hardware mit Debian Buster wird zum Surfen überhaupt nicht verwendet.

Noch eine Frage : Weiter oben schreibst du, dass die grösste Gefahr von Usern ausgeht, die Admin rechte haben. Das leuchtet ein. Wäre es in dem Falle auch besser auf den Eintrag per visudo zu verzichten, auch wenn ich der einzige User im System wäre? Das würde ja immer noch erfordern, dass man an das vergebene Passwort käme. Wie sehen hier die Angriffsszenarien aus?

Es braucht immer nur einen einzigen User, der angemeldet ist und gelegentlich ein sudo-Statement absetzt.... das reicht völlig aus, wenn Dein PC vor-kompromittiert wurde, um ihn dann endgültig zu übernehmen.

Wie soll das gehen, wenn auf der Firewall der eingehende Traffic geschlossen wurde? Was kann man gegen solche Art von Angriffen unternehmen?

Es gibt Provider, die lassen es gar nicht zu, dass Kunden den schließen können. Einen solchen Router würde ich nicht verwenden. Ich schick dir mal nen Link zu.

[mat6937]

Ja, richtig... aber das bedarf einer vorherigen erfolgreichen Kommunikation, die es bei den oben in meiner Liste enthaltenen IPs aber nicht gibt. Die gelisteten Pakete hatten ja gar nicht erst die Möglichkeit, an einen Fingerprint zu kommen.

Was genau meinst Du mit "erfolgreichen Kommunikation"? Wenn die IP-Adressen geblacklistet sind, ist das klar.
Aber wenn das nicht der Fall ist bzw. bis das der Fall ist, wie verhinderst Du, dass ausgehender Traffic (als Antwort) nicht an die "anfragende" IP-Adresse geht?

EDIT:

Z. B., kannst Du solche Antworten:

Code: Alles auswählen

2x3.xx.xx.x:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
1x4.xx.xx.xx5:22 SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6

, aus denen das OS und die sshd-Version abgeleitet werden kann, _verhindern_ bzw. nicht zulassen, wenn die IP-Adresse noch nicht geblacklistet ist?

EDIT 2:

BTW: Bei FreeBSD ist die Antwort etwas unspezifischer:

Code: Alles auswählen

47.xxx.xxx.x7:22 SSH-2.0-OpenSSH_7.8

EDIT 3:

Man kann es u. a. auch verhindern, durch patchen und selber kompilieren.

[debianoli]

Und wie sieht es mit Angriffen über Pdf Jpg Libreoffice etc aus? Wäre doch möglich, durch eine Lücke in libpoppler zB bei Pdf.

Natürlich könnte ein Angreifer versuchen, eine Linuxkiste zu übernehmen, indem er Lücken in Programmen und Bibliotheken nutzt. Sicherer als Windows ist ein Linxrechner hier jedenfalls nicht.

Die Frage war ja nach jpgs, pdf und so.... ich denke, es gibt da nicht sowas wie 'multiresistente' Viren in einem jpg oder pdf, die gleichermaßen auf einem Android, Apple, Linux oder Windows funktionieren können. Wie soll das denn gehen? Selbst wenn ein unentdeckter Exploit in einer Standard-pdf-format-Lib enthalten wäre, so sind doch deren Lib-Adressen auf den Betriebsystemen völlig unterschiedlich und so haben die Programme dann auch völlig unterschiedliche Ausführungsrechte auf den Geräten. Wer will denn vorhersagen, welches jpg und welche pdf auf welchem Betriebssystem und mit welchem Viewer geöffnet wird und ob überhaupt. Die Frage bleibt, wenn es kein gezielter Angriff ganz konkret auf meine Maschine ist, woher weiss der Angreifer, welches Werkzeug für den Einbruch überhaupt gebraucht wird? Solche Attacken bleiben doch allesamt nur rein zufälliges rumgestochere im Loch, ohne eine garantierte Aussicht auf Erfolg. Für mich ist das eher so wie bei den Schimpansen, wenn sie mit 'nem Stock in tiefen Löchern nach Ameisen fischen.... nur wo sehr viele Ameisen sitzen, bleibe vielleicht einige wenige zufällig hängen... wenn betriffts also? Natürlich Windows.

Und warum sollte das jetzt nicht passieren? Gerade wenn man einen Rechner beruflich nutzt, hat man ständig mit allen möglichen Dateien zu tun, die man von Geschäftspartnern geschickt bekommt. Oder man erhält Rechnungen etc. von vermeintlichen Dienstleistern (gefälschte Email von Paypal, Amazon o.ä.), die in Wahrheit einen Virus enthalten. Klar, das Ding muss gut gemacht sein, doch die Möglichkeit besteht. Und falls das dann wirklich gut gemacht ist, hast du dann zwar kein infiziertes GESAMT-System, aber am Ende ein verschlüsseltes $User-Home. Und das kann sehr viel schlimmer sein, denn dort sind wichtige Geschäftsdaten. Die bei Pech eben nicht in einem Backup stecken.

[uname]

Und warum sollte das jetzt nicht passieren? Gerade wenn man einen Rechner beruflich nutzt, hat man ständig mit allen möglichen Dateien zu tun, die man von Geschäftspartnern geschickt bekommt. Oder man erhält Rechnungen etc. von vermeintlichen Dienstleistern (gefälschte Email von Paypal, Amazon o.ä.), die in Wahrheit einen Virus enthalten. Klar, das Ding muss gut gemacht sein, doch die Möglichkeit besteht. Und falls das dann wirklich gut gemacht ist, hast du dann zwar kein infiziertes GESAMT-System, aber am Ende ein verschlüsseltes $User-Home. Und das kann sehr viel schlimmer sein, denn dort sind wichtige Geschäftsdaten. Die bei Pech eben nicht in einem Backup stecken.

Ich nutze nun schon seit mehr als 20 Jahren Linux. Ich habe noch nie einen Dateianhang erhalten, der z. B. ein Linux-Binary oder ein Shellscript enthalten hatte, welches ich downloaden musste, ausführbar gemacht hätte um es dann auszuführen. Das passiert einfach nicht. Unter Linux funtkionieren Angriffe ganz anders. Das größte Risiko für Linux ist wohl eher der Virenscanner selbst, der einem das System zerlegt. Und natürlich benötigt man aus vielen Gründen ein aktuelles Backup. Jede Hardware inkl. Festplatte oder SSD kann versagen ... vielleicht genau jetzt. Im übrigen würde ich unter Windows auch nur den Microsoft Defender verwenden und vielleicht zusätzlich mein Gehirn einschalten. Nicht-IT-erfahrenen Menschen empfehle ich daher Linux oder ein tägliches, inkrementelles Backup.

Falls jemand Linux-Schadcode kennt kann er oder sie ja mal ein paar Links hier posten oder mir eine PN schicken.

[debianoli]

Ich nutze nun schon seit mehr als 20 Jahren Linux. Ich habe noch nie einen Dateianhang erhalten, der z. B. ein Linux-Binary oder ein Shellscript enthalten hatte, welches ich downloaden musste, ausführbar gemacht hätte um es dann auszuführen. Das passiert einfach nicht.

Von dieser Art Angriffen habe ich doch gar nicht angesprochen.

Es geht um Programm zum Darstellen von Bildern, PDF etc. und dafür bekommt sehr oft Dateien als E-Mail-Anhang. Was auch logisch ist.

Und es gibt eben auch Schwachstellen wie diese im Bereich PNG-Grafiken als Beispiel: "... if a malformed image is processed." https://www.debian.org/security/2019/dsa-4435

Eine Absicherung von bestimmten Programmen macht da schon Sinn, etwa durch das bereits erwähnte firejail . Auch Thunderbird und die Browser sind Kandidaten für Angriffe. Nur weil Debian & Co nicht die Verbreitung wie Windows haben, macht es das doch nicht automatisch sicherer.

[uname]

Das mit firejail mag stimmen auch wenn ich es nicht einsetze. Auch ist es sehr wichtig alle installierten Pakete aktuell zu halten. Aber traditionelle Virenscanner braucht man unter Linux nicht.

[TomL]

Ja, richtig... aber das bedarf einer vorherigen erfolgreichen Kommunikation, die es bei den oben in meiner Liste enthaltenen IPs aber nicht gibt. Die gelisteten Pakete hatten ja gar nicht erst die Möglichkeit, an einen Fingerprint zu kommen.

Was genau meinst Du mit "erfolgreichen Kommunikation"? Wenn die IP-Adressen geblacklistet sind, ist das klar.

Es kann gut möglich sein, dass ich die Wirkungsweise meines Paketfilters falsch verstanden habe, aber bis jetzt wurde meiner Interpretation noch nicht widersprochen. Es geht ja um die von msfree genannte Wiki-Seite zum OS-fingerprinting..... und dabei es ist ja nun mal so, dass das mitunter dutzende von gesendeten Paketen erfordert, um aus deren Antworten dann entsprechende Ableitungen zu treffen oder Ableitungen zu ermöglichen. Aber genau das ist nach meiner Interpretation meines Paketfilters bei mir nicht möglich. Eine bestimmte IP-Adresse hat innerhalb 1 Minute genau 1 einzigen Versuch über ein Paket mit CT-State New (Syn-Flag) eine Verbindung zu etablieren (CT-State Established). Kommt in der gleichen Minute das 2. Paket ist und es ist nicht established, ist diese IP vorübergehend für 60 Minuten gesperrt - also quasi temporär geblacklistet. Jedes weitere Paket danach mit "irgendwas" von dieser IP wird dann gnadenlos gedropt, was bei mir dann so aussieht.

Code: Alles auswählen

Apr 28 03:39:06 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:07 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:09 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:11 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:12 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:14 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:16 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:17 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:19 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:21 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:22 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 
Apr 28 03:39:24 server kernel: Temp.banned IP: IN=eno1 OUT= SRC=106.75.63.218 

Allerdings muss ich darauf hinweisen, dass bei mir kein Web-Server läuft, wahrscheinlich gelten dabei auch völlig andere Regeln... ich glaube msfree hat irgendwo oberhalb schon darauf hingewiesen oder was erwähnt. Aber weil ich mir selber die Kontrolle eines vom Internet zugänglichen Webservers gar nicht zutraue, also konkret bestätigt zu garantieren, dass er nur (wie von mir festgelegt (!)) bestimmungsgemäß genutzt wird, verzichte ich lieber auf einen echten Web-Server und betreibe nur Dienste, die ich im Griff habe.

Meine besondere Konfiguration ist ja ein VPN-Server auf Port 443, und genau der ist auch über das Web erreichbar. Mittlerweile nutze ich seit gut 1/2 Jahr nftables .... und nftables ersetzt m.M.n. mit geradezu brachialer Effektivität fail2ban. Für mich ist failtoban damit regelrecht zu Code-Schrott geworden, ganz ähnlich wie zuvor auch schon sysvinit mit den log-levels, oder rsyslog und dmesg, oder auch sudo..... ... also, wie gesagt, ich glaube momentan, dass mehrere aufeinander folgenden Pakete einer aggressiven IP bei mir nicht möglich sind, weil eine IP genau einen einzigen Versuch (syn-flag) hat, eine Verbindung zu etablieren. Und somit kann sie auch keine Kommunikation erzwingen, die bei Fehlschlag des 1. Paketes erfolgt. Und alles andere, was kein syn-flag ist oder nicht established ist, wird eh verworfen. Das bedeutet, die Pakete werden schon verworfen, bevor sie überhaupt bei irgendeinem regulären Service ankommen können, der irgendwas beantworten würde.

Z. B., kannst Du solche Antworten:

Code: Alles auswählen

2x3.xx.xx.x:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
1x4.xx.xx.xx5:22 SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6

, aus denen das OS und die sshd-Version abgeleitet werden kann, _verhindern_ bzw. nicht zulassen, wenn die IP-Adresse noch nicht geblacklistet ist?

Ja, genau so interpretiere ich meinen Paketfilter, weil mein Paketfilter selber hochdynamisch und kompromisslos ad hoc und just-in-time (!) blacklistet, also genau dann, wenn es notwendig ist.... nach meiner Vorgabe aber temporär nur für 60 Minuten. Darüber hinaus ist natürlich auch eine statische Blacklist enthalten.

[OrangeJuice]

Kann man Firejail auch unter Gnome mit Wayland verwenden? Ist doch etwas für X11 gewesen oder?

[mat6937]

Ja, genau so interpretiere ich meinen Paketfilter, weil mein Paketfilter selber hochdynamisch und kompromisslos ad hoc und just-in-time (!) blacklistet, also genau dann, wenn es notwendig ist.... ...

Das Scannen mit scanssh ist aber kein missglückter Anmeldeversuch und auch kein Portscan wie mit nmap (oder gleichwertig). Evtl. ist das für den sshd ein "friendly scan" und es soll auch einen Eintrag in die Log-Datei des Servers zur Folge haben:

At the moment, scanssh leaves a one line entry in the log file of the ssh server. It is probably not possible to avoid that.

manpage scanssh

[TomL]

Das Scannen mit scanssh ist aber kein missglückter Anmeldeversuch und auch kein Portscan wie mit nmap (oder gleichwertig). Evtl. ist das für den sshd ein "friendly scan" und es soll auch einen Eintrag in die Log-Datei des Servers zur Folge haben:

Ich habe an diesem Punkt bedauerlicherweise das Problem, dass hierbei anscheinend eine Sachkenntnis notwendig ist, die mir vermutlich wie weiteren 99,9999% aller anderen User ebenfalls schlichtweg fehlt. Insofern kann ich hier nur interpretieren.... womit ich aber eben leider auch daneben liegen kann.

Bislang bin ich davon ausgegangen, dass jeder Verbindungsaufbau von einem Syn-Flag-Paket eingeleitet wird, also zu einem Zeitpunkt, der noch weit vor einem missglückten Anmeldungsversuch liegt. Ich hatte auch angenommen, dass das auch für Portscans gilt und das grundsätzlich jeglicher "Dialog" immer zwingend mit einem Syn-Flag-Paket eröffnet werden muss.... wichtig ist, ich rede hier von "Dialog", egal wie rudimentär das auf der Netzwerkebene ganz am Anfang auch noch ist. Das ist der erste Punkt: Bei mir ist ein zweites Syn-Flag-Paket innerhalb der gleichen Minute gar nicht möglich... das zweite Paket führt sofort zu einem Bann der sendenden IP, wodurch sie quasi sofort geblacklistet ist.

Der zweite Punkt ist, auch bei der von der hmac-Firewall abgewiesenen Verbindung beim TLS-Aufbau (TLS-Control-Chanel) hat es ja noch keine Kommunikation mit dem Service an sich gegeben (...denke ich mal, hoffe ich...), also ist die Verbindung auch hier sofort wieder unterbrochen. Und beim nächsten Verbindungsversuch passiert das, was oberhalb im zweiten Absatz beschrieben ist.... die IP ist jetzt geblacklistet. Das ist ja das, was nftables so genial kann.

Zur Sicherheit wiederhole ich das lieber noch mal.... das gilt wahrscheinlich alles nicht für Web-Server... da ist alles anders ... das zu kontrollieren trau ich mir allerdings nicht zu. Und wer einen Web-Server betreibt, muss wahrscheinlich noch an ganz andere Sachen denken. Aber dieses Wissen habe ich nicht - deswegen betreibe ich auch keinen Web-Server.

[mat6937]

Bislang bin ich davon ausgegangen, dass jeder Verbindungsaufbau von einem Syn-Flag-Paket eingeleitet wird, also zu einem Zeitpunkt, der noch weit vor einem missglückten Anmeldungsversuch liegt. Ich hatte auch angenommen, dass das auch für Portscans gilt und das grundsätzlich jeglicher "Dialog" immer zwingend mit einem Syn-Flag-Paket eröffnet werden muss.... wichtig ist, ich rede hier von "Dialog", egal wie rudimentär das auf der Netzwerkebene ganz am Anfang auch noch ist. Das ist der erste Punkt: Bei mir ist ein zweites Syn-Flag-Paket innerhalb der gleichen Minute gar nicht möglich... das zweite Paket führt sofort zu einem Bann der sendenden IP, wodurch sie quasi sofort geblacklistet ist.

Es geht hier beim Versuch mit scanssh nicht um einen Anmeldeversuch (Angriff aud den sshd-Server), sondern um Kommunikation (Anfrage) mit dem sshd-Server (zum feststellen der sshd-Version).
Die Verbindung wird mit "syn, syn+ack, ack" hergestellt, danach kommt ein Austausch in etwa mit "push+ack, ack, fin+ack, rst+ack, rst". D. h. ein 2. syn-Paket wird von scanssh nicht gesendet und ist auch nicht erforderlich, denn der sshd-Server versteht anscheinend ganz genau, was scanssh von ihm will.

Die Frage ist, auf welcher Basis und zu welchem Zeitpunkt der Paketfilter die IP-Adresse blacklisten soll/wird.

[TomL]

Die Frage ist, auf welcher Basis und zu welchem Zeitpunkt der Paketfilter die IP-Adresse blacklisten soll/wird.

Dann hast Du mich offensichtlich missverstanden.... der Service selber (hier SSHD) auf meinem Server sieht ja bei mir überhaupt keine solchen TCP-Pakete, weil die Verbindung durch die HMAC-FW wegen Fehlschlag auf dem TLS-Control-Chanel schon vorher unterbrochen wurde, also bevor TCP-Pakete überhaupt beim Service ankommen können. Und wenn die Verbindung einmal von hier unterbrochen wurde, würde ein in der gleichen Minute durchgeführter Neuversuch sofort zum Blacklisting führen. Wenn ich allerdings jetzt SSH selber direkt verbinden könnte, träfe das vermutlich zu, was Du sagst.

[mat6937]

... die Verbindung durch die HMAC-FW wegen Fehlschlag auf dem TLS-Control-Chanel ...

Benutzt Du ssh via OpenVPN?

EDIT:

... und die IP-Adressen die Du bannen tust, werden mit einem Honigtopf (oder gleichwertig) empfangen?

[TomL]

Von außerhalb gibt es nur den VPN-Zugang in mein Netzwerk. Ich hatte das aber oben schon erwähnt.... aber vielleicht nicht eindeutig genug

Alles zusammengenommen betrachte ich als mein persönliches Firewall-Konzept, was eben auch genau solche OS-Fingerprint-Detections verhindert. Ich mache das also nicht an einem fokussierten Punkt fest, sondern betrachte die erfolgreiche Verhinderung solcher 'Abfragen' als ein (neben anderen) Ergebnis meines gesamten FW-Konzeptes.

... und die IP-Adressen die Du bannen tust, werden mit einem Honigtopf (oder gleichwertig) empfangen?

Nö, kein Honeypot.... das was hier ankommt, ist der ganz normale alltägliche Internetwahnsinn von irgendwelchen Maschinen weltweit, die das Web anscheinend ebenfalls weltweit systematisch nach Löchern untersuchen.

[novalix]

Meine besondere Konfiguration ist ja ein VPN-Server auf Port 443, und genau der ist auch über das Web erreichbar. Mittlerweile nutze ich seit gut 1/2 Jahr nftables .... und nftables ersetzt m.M.n. mit geradezu brachialer Effektivität fail2ban. Für mich ist failtoban damit regelrecht zu Code-Schrott geworden, ganz ähnlich wie zuvor auch schon sysvinit mit den log-levels, oder rsyslog und dmesg, oder auch sudo.....

Dein LAN ist nach außen abgeschottet bis auf den verschlüsselten Verkehr über das virtuelle private Netzwerk.
Das ist ja völlig OK und entspricht ganz offensichtlich Deinen Nutzungsanforderungen.
Dein LAN ist allerdings dementsprechend lediglich ein passiver Nutzer des Internets. Eine aktive Nutzung Deiner Ressourcen durch weitere Teilnehmer ist explizit nicht gewünscht und nicht erlaubt.
Da ist es nur logisch, dass Du mit fail2ban nichts anfangen kannst.

Würdest Du Ressourcen betreuen, die explizit für die öffentliche Nutzung vorgesehen sind, müsstest Du wohl oder Übel Deine Netzfilter überarbeiten. Du könntest dann zu der Erkenntnis gelangen, dass es verdammt schwierig bis unmöglich ist, auf TCP/IP-Level zu entscheiden, was gewollter und was mißbräuchlicher Netzwerkverkehr ist.
Wenn Deine Ressource im Internet also nicht nur bei bestimmten Gestirnskonstellationen erreichbar sein soll und Du trotzdem verhindern willst, dass böswillige Nutzer Deinen Dienst missbrauchen, solltest Du den Verkehr auf Applikationsebene monitoren und ggf. automatisiert eingreifen.
Voila: "fail2ban - Back from the Junkyard Teil 1312"
Und mit ihm im Schlepptau kommt der alte, sehr, sehr alte und gebrechliche rsyslogd.
Schrott von gestern, der allerdings auch heute noch nachvollziehbar funktioniert im Gegensatz zu hochmodernen journal.

[TomL]

Dein LAN ist nach außen abgeschottet bis auf den verschlüsselten Verkehr über das virtuelle private Netzwerk.

Ja, für alles uneingeladen von außen kommende.

Würdest Du Ressourcen betreuen, die explizit für die öffentliche Nutzung vorgesehen sind, müsstest Du wohl oder Übel Deine Netzfilter überarbeiten.

Ja, das stimmt ... und zwar durch Ergänzungen. Das, was jetzt steht, hätte imho im Wesentlichen jedoch auch noch danach Bestand. Du hast auch wegen meines scheinbar unpassenden 'Schrott-Urteils' bezogen auf failtoban Recht. Diese Beurteilung passt wirklich nur auf meine Nicht-öffentliche-Server-Umgebung. Aber ich hatte ja mehrfach eingeräumt, dass ich keinen öffentlichen Server betreibe und das mir bekannt ist, dass dabei völlig andere Regeln gelten. Solche Installationen beurteile ich deswegen auch gar nicht, weil mir dafür schlichtweg das KnowHow fehlt. Deswegen habe ich auch mehrfach deutlich gemacht, dass ich genau solche Installationen ausdrücklich nicht meine und mich allein auf private Maschinen und möglicherweise einem lokalen NAS beziehe.

Darüberhinaus ist es auch nicht die Intention dieses Thread, eine solche Installation mit öffentlichem Server zu betrachten, siehe TO:

Es geht mir nicht so sehr darum, wie man das Thema behandelt, wenn Linux als Fileserver eingesetzt wird, sondern wie man das System selbst sichern kann.

Deine Klatsche ist natürlich sachlich völlig korrekt und den Aussagen kann man nicht widersprechen, was ich auch gar nicht tue. Ich stelle hierbei nur fest, dass das m.M.n aber eben leider auch am Thema vorbeizielt. Mir geht es nicht um öffentliche Server und die betrachte ich auch nicht. Ich versuche lediglich mein nicht-öffentliches Netzwerk gegen Manipulation von außen zu sichern und im zweiten Schritt natürlich auch gegen von innen initiierte oder durch User fahrlässig autorisierte Manipulation. Bezogen auf dieses LAN/HW/SW-Integritäts-Interesse von mir unterscheide ich also gar nicht, ob die Attacke von einem internen Virus ausgeht oder ob es ein von außen agierender Bot ist oder ob es gar der User selber ist. Meine Firewall-Konzept soll sich umfassend mit multiplen Angriffs-Vektoren befassen und nach besten Wissen und Gewissen versuchen, jedem einzelnen Vektor eine konkrete Maßnahme entgegen zustellen.