debianforum.de

Hallo,

ich habe bisher nie ausgehenden Traffic auf root-Servern gedropt, weil ich dachte, wenn etwas Schädliches auf meine Kisten kommt, ist es eh zu spät. Würdet ihr ausgehenden Traffic blocken und jede Verbindung, also auch die von dpkg, ntp, ssh, smtp etc, einzeln freigeben, was ja doch einiges an Konfigurationsaufwand bedeutet? Macht das Sinn auf einem root-Server der direkt im Internet hängt, am Ende vielleicht sogar auf IP's zu beschränken? Die gängigen Regeln wie "halte die Software immer aktuell" oder "lasse nichts unnützes laufen" etc. halte ich natürlich ein. Und ich bin quasi alleiniger Admin, es gibt kaum bis keine andere PAM-User auf den Kisten und AllowUsers in der sshd_config ist gut gepflegt.

Beim eingehenden Traffic mache ich das schon immer so, nur die Ports per iptables zu öffnen, die tatsächlich gebraucht und genutzt werden.

Was meint ihr?

Exxter hat geschrieben:

04.12.2019 07:54:16

Würdet ihr ausgehenden Traffic blocken und jede Verbindung, also auch die von dpkg, ntp, ssh, smtp etc, einzeln freigeben, was ja doch einiges an Konfigurationsaufwand bedeutet?

Der Konfigurationsaufwand sollte und kann hier kaum ein Argument sein. Die 4 von dir genannten Dienste lassen sich in 4 Zeilen mit iptables konfigurieren, jeder weitere Dienst erfordert halt eine weitere Zeile. Der Aufwand ist also sehr, sehr gering und vor allem nur einmalig.

Grundsätzlich ist es aber schon so, daß wenn sich jemand Zugang zu deiner Kiste verschafft, er auch die Firewallregeln ziemlich einfach deaktivieren kann. Der zusätzliche Schutz, ausgehenden Verkehr zu blockieren, ist also überschaubar gering.

Wichtiger wäre mir, alles an eingehendem Verkehr zu blockieren, was nicht absolut notwendig ist und den Adminzugang, typischerweie SSH, nach allen Regeln der Kunst abzusichern, also über Schlüsseldateien und einen weiteren Faktor. Ich habe bei meinem privaten Router den SSH-Zugang mit Pingknocking geschützt. Erst, wenn man dem Router ein bestimmtes Ping-Paket schickt, öffnet sich der SSH-Port für eine kurze Zeit für die IP-Adresse des Absenders des Pingpakets. Man könnte auch 2nd Factor Authentication verwenden. 2FA hat aber die (zugegeben kleine) Schwäche, daß der SSH-Server schon im Zugriff ist und hier ggfls. Sicherheitslücken genutzt werden könnten, die SSH-Key und 2FA umgehen.

Macht das Sinn auf einem root-Server der direkt im Internet hängt, am Ende vielleicht sogar auf IP's zu beschränken?

Der zusätzliche Schutz durch das Blockieren von ausgehendem Verkehr, bzw. das Beschränken auf IP-Adressen, ist eher marginal. Wenn eine Sicherheitslücke exisiert, wirst du sie kaum durch ein paar zusätzliche Firewallregeln aufhalten.

Danke für deine Einschätzung, die genau meine Meinung widerspiegelt.

Wie hast du das Pingknocking realisiert, vermutlich mit knockd? Wäre schon deshalb interessant, weil das die zich Fehllogins per SSH vermutlich komplett eindämmen würde.

Exxter hat geschrieben:

04.12.2019 09:30:26

Wie hast du das Pingknocking realisiert?

Ich habe dazu etwas selbst programmieren müssen, fertiges gibt es meines Wissens nicht.

Anfangs hatte ich nur ein Tool, das eine Schwäche von iptables umgehen sollte. iptables kann nur auf IPs filtern, Bindet man seinen DSL-Zugang mit der aktuellen IP an einen DynDNS-Provider, kann man den Server zwar finden, aber der Client, der ebenfalls meistens an einem Zugang mit variabler IP hängt, kann nicht ausgefiltert werden. Erst, wenn beide an DynDNS gebunden sind, könnten sie sich gegenseitig über die IP identifizieren, aber iptables unterstütz keine reverse-DNS-Lookups. Die erste Version meines Programmes hat bei reinkommenden Paketen ein DNS-Lookup mit einer Liste erlaubter Hostnamen durchgeführt und die IPs mit der Quell-IP des reinkommenden Pakets verglichen.

DynDNS ist aber zumindest auf Clientseite etwas mühselig, die DynDNS-Provider sind nicht immer zuverlässig und zumindest der damals größte hat nach und nach seinen Dienst auf ein Bezahlmodell umgebaut und wurde unattraktiv. Es gibt zwar Alternativen, aber auch da gibt es immer wieder Veränderungen, so daß man alle paar Jahre mal aktiv werden muß, und je mehr Rechner betroffen sind, desto umfangreicher wird der Aufwand.

Es wäre also gut, wenn man nur einen Rechner bei Veränderungen der DynDNS-Landschaft angepaßt werden muß, und das hat mich dann zu Portknocking gebracht, wobei Portknocking nicht durch jede Firewall kommt, wenn die Admins nicht jeden Port ausgehend zulassen. Im Internet habe ich dann einiges zu Pingknocking gefunden, aber nur, wie an es realisieren könnte, jedoch keine fertigen Softwarepakete.

Das, was ich selbst programmiert habe, ist ein servereseitiges Programm, das sich an die libnetfilter_queue hängt, also eine Standardschnittstelle, und ein clientseitiges Programm, das Pingpakete mit der nötigen Payload versieht, um die gewünschte Aktion auszuführen. Im Grunde ist das Clientprogramm nur ein modifiziertes Ping-Programm.

Die Filterung nach den "alten" Muster, also das oben genannte Paaren über Hostnamen, ist ebenfalls in der Software integriert.

Einen Nachteil hat Pingknocking allerdings, denn private DSL-Anschlüße kann man so nicht abdichten, weil die Plastikrouter ping nicht an Zielrechner durchreichen, da hilft nur die erstgenannte Methode oder ein Linuxrechner als Router mit einem reinen DSL-Modem.

Exxter hat geschrieben:

04.12.2019 09:30:26

Wäre schon deshalb interessant, weil das die zich Fehllogins per SSH vermutlich komplett eindämmen würde.

Das ständige Rauschen auf Port 22 kannst Du aber auch dadurch eliminieren, in dem Du SSHD auf einen exotischen Port >50000 änderst. In Abhängigkeit davon, ob dieser Zugang nur von einem oder von vielen genutzt, kann das eine sehr einfache aber hochwirksame Maßnahme sein. Damit sollten sich die Fehlversuche fast auf Null reduzieren... wenn überhaupt, kommen dann gelegentlich allenfalls noch mal ungezielte 'Irrläufer' rein.

TomL hat geschrieben:

04.12.2019 10:31:20

Das ständige Rauschen auf Port 22 kannst Du aber auch dadurch eliminieren, in dem Du SSHD auf einen exotischen Port >50000 änderst.

Der Nachteil wäre aber, daß in vielen Firmennetzen mit ausgehender Firewall so ein exotischer Port blockiert ist. Man kommt dann aus vielen Netzen gar nicht mit SSH auf den Server drauf.

MSfree hat geschrieben:

04.12.2019 11:32:46

Der Nachteil wäre aber, daß in vielen Firmennetzen mit ausgehender Firewall so ein exotischer Port blockiert ist. Man kommt dann aus vielen Netzen gar nicht mit SSH auf den Server drauf.

Ja, das ist richtig... aber diesen Umstand blende ich aus, weil ich davon ausgehe, dass die Compliance-Regeln des Unternehmens im Rahmen eines Firewall-Konzeptes so etwas sowieso generell verbieten. Zumindest hätte ich Sorge um meinen Arbeitsplatz bzw. wg. arbeitsrechtlicher Konsequenzen und würde so etwas aus dem Firmennetzwerk heraus eh nicht tun. Aber ich sagte ja, ob das geht, muss man von Fall zu Fall abwägen. Sind es viele Clients, würde ich das auch nicht tun und stattdessen lieber ein VPN einrichten. Ist es jedoch nur ein Ein-Personen-Zugang mit ein oder zwei Admin-Geräten, ist das eine sehr wirksame und leicht umzusetzende Maßnahme.

Ich nutze schon seit längerem den Port 22222 - leider mit mäßigem Erfolg Aber das wäre ein anderes Thema.

Vielen Dank für euren Erfahrungsaustausch!

MSfree hat geschrieben:

04.12.2019 09:08:51

Wichtiger wäre mir, alles an eingehendem Verkehr zu blockieren, was nicht absolut notwendig ist und den Adminzugang, typischerweie SSH, nach allen Regeln der Kunst abzusichern, also über Schlüsseldateien und einen weiteren Faktor. Ich habe bei meinem privaten Router den SSH-Zugang mit Pingknocking geschützt. Erst, wenn man dem Router ein bestimmtes Ping-Paket schickt, öffnet sich der SSH-Port für eine kurze Zeit für die IP-Adresse des Absenders des Pingpakets.

SSH bietet schon so ein Ping Paket wartet auf Port 22 und will als Inhalt username und Passwort haben. (Wenn man mit Keys oder 2FA abrbeitet wirds komplizierter) Was um größenordnungen schwieriger zu erraten ist als irgend welch Ports. – Zumal man die einfach mitschneiden kann, währen SSH das pw verschlüsselt haben will.
Sorry, nein. Ich führe das regelmäßig vor, dass solche Eigenbaulösungen regelmäßig exploitbar sind. (Gerade wenn sie mit DNS-Abfragen und/oder bash Skripten arbeiten. Lieblingsopfer ist da fail to ban.)
Lasst Sicherheit doch die machen, die das können. – Zum Beispiel den OpenSSH-Entwicklern. Da ne Lüke zu finden ist üblicherweise ne ganz andere Kategorie als in irgend welchen reverse-Lookup oder Portöffner Skripten oder ähnlichem. Und solange ihr das nicht vorführt, wie ihr nen aktuellen OpenSSH kaputt machen könnte braucht ihr auch nicht danach fragen wie man jetzt irgend welche Scripte exploited. Am SSH haben sich schon mehr versucht und entsprechend mehr Sicherheit sollte man dem erst mal zugestehen.
Wenn du "lasse nichts unnützes laufen" das einhältst bist du ohne eingehende Firewall sicherer. Denn was nützlich ist musst du in der Firewall eh freischalten. Die Firewall nützt also nichts. Fügt aber einen Zusätzlichen Angriffspunkt hinzu.

Der zusätzliche Schutz durch das Blockieren von ausgehendem Verkehr, bzw. das Beschränken auf IP-Adressen, ist eher marginal. Wenn eine Sicherheitslücke exisiert, wirst du sie kaum durch ein paar zusätzliche Firewallregeln aufhalten.

Das sehe ich anders: Dienste laufen (hoffentlich) nicht als root. Wenn du doch mal ne Lücke hast, ist der Angreifer erst mal mit den Rechten des Dienstes unterwegs. Wenn du dann ein schönes hartes setup hast, das insbesondere auch ausgehenden Verkehr beschränkt (und entsprechende Nutzer/Dienste auch keine bind(machen dürfen)) ist das ziemlich hart für die Malware schaden anzurichten.

Zuerstmal ist der exploit selbst meist sehr klein. Irgend wann muss die Software die eigentlich "nützliche" Malware nachladen. Üblicherweise versucht der das zuerst per wegt oder curl, weil das im System ist, und nicht mitgebracht werden muss. Beschränkt man ausgehende Verbindungen tut das nicht. Damit funktioniert schon mal ein grosteil der exploits nicht. Auf der anderen Seite ist das mehr obscurity. Die Software könnte meist andere Wege finden ihre Daten auszuleiten.

Aber das nächste Porblem ist grundsätzlicher. Es gibt üblicher weise 3 Sorten von exploits
* Ransomware/DOS... Die braucht bei ausreichend harten Beschränkungen für den Nutzer root rechte. Und scheitert daran. – Tut nicht.
* Nutzung von Ressourcen. Vor allem das versenden von Spam-E-Mails und Bitconminer. Die brauchen ausgehende Verbindungen zum Mailserver bzw. Miningpool. – Tut nicht.
* "Diebstahl" von Nutzerdaten. Auch die müssen irgend wie raus. Hast du ne feste Liste von IP-Adressen auf die du connecten darfst, wird das seinen Empfänger nicht finden. Einige VMs bei mir bekommen ihre Uhrzeit vom host und dürfen nur auf den Mirror in Esslingen zugreifen. Daneben kommt man per SSH über nen Proxy drauf, der auch freigeschalten ist. Malwre kann da Daten stehlen wie sie will. – Solange sie nicht den sshd exploitet (und damit root-rechte bekommt) Kann die Daten sammeln wie sie will. Die kann die entweder an meinen Proxy senden oder an den Mirror in Esslingen. Beide werden sich nicht dafür interessieren. Wo es geht machen harte IP-Listen also durchaus Sinn.

Grundsätzlich gilt: Wenn du wirklich eine Ressource Blockst. (Zugang zum Internet. Zugriff auf bestimmte Dateien.) hast du wirklich Sicherheit geschaffen. Sobald du die erste ausnahme machst ist es sinnlos. – Wenn du eine feste IP-Liste hast auf die du dich Verbiden kannst, ist das ein Hindernis. Machst du aber ausgehende Verbindungen auf Port 443 überall hin auf ist die Regel sinnlos. Malware wird die nehmen. Du schaffst dir mit dem Firewalling nur zusätzliche Angriffsfläche. – Einen grundsätzlichen block auf ausgehende Verbindungen auf Port 25 ist dagegen wirksam, weil man Spam-Mails über keinen anderen Port verschicken kann.
Blocken von eingehenden Verbindungen ist sinnlos, solange du es nicht auch für ausgehende machst und umgekehrt.


Und ganz wichtig: Fehlgeschlagene Loginverscuhe sind ein gutes Anzeichen dafür, dass dein System sicher ist. Da versucht es jemand und kommt nicht rein. Erfolgreiche sind ein Problem.

wanne hat geschrieben:

04.12.2019 15:17:32

SSH bietet schon so ein Ping Paket wartet auf Port 22 und will als Inhalt username und Passwort haben.

Es ist zwar schon viele Jahre her, aber ich bin bezüglich SSH ein gebranntes Kind. Durch einen Fehler in SSH wurde ein von betreuter Router gekapert. Ich hatte es gerade noch rechtzeitig bemerkt und das Netzwerkkabel gezogen.

Der Fehler wurde zwar in SSH behoben, aber mein Vertrauen ist diesbezüglich grundlegend zerstört. Ich würde nie wieder einen SSH-Server ohne Vorschaltschutz ins Netz hängen.

Was um größenordnungen schwieriger zu erraten ist als irgend welch Ports. – Zumal man die einfach mitschneiden kann,

Deswegen nutze ich ja auch kein Portknocking.

Sorry, nein. Ich führe das regelmäßig vor, dass solche Eigenbaulösungen regelmäßig exploitbar sind.

Vielen Dank, daß du mir hier so wenig zutraust.

Lasst Sicherheit doch die machen, die das können.

Genau deswegen nutze ich ja auch bewährtes, in meinem Fall libnetfilter_queue und SHA256, aufgerufen von einem überschaubaren C-Programm.

MSfree hat geschrieben:

04.12.2019 16:28:42

Durch einen Fehler in SSH wurde ein von betreuter Router gekapert. Ich hatte es gerade noch rechtzeitig bemerkt und das Netzwerkkabel gezogen.

OpenSSH hatte seit existenz (zumindest wenn man nicht manuell X11-Forwarding oder ähnliches bekanntermaßen gefährliche Optionen angeschaltet hat keine OpenSSH seit Existenz keine Sicherheitslücken gehabt, die man ohne weitere Kenntnisse aus dem Internet ausführen hätte können. Irgend welche MItM oder gar Privilege escalations nach dem login fängt dein Script nämlich garantiert nicht ab.

Was um größenordnungen schwieriger zu erraten ist als irgend welch Ports. – Zumal man die einfach mitschneiden kann,

Deswegen nutze ich ja auch kein Portknocking.

Das du wunderbar mitschneiden kannst und dann wiederholen.

Sorry, nein. Ich führe das regelmäßig vor, dass solche Eigenbaulösungen regelmäßig exploitbar sind.

Vielen Dank, daß du mir hier so wenig zutraust.

Lasst Sicherheit doch die machen, die das können.

Genau deswegen nutze ich ja auch bewährtes, in meinem Fall libnetfilter_queue und SHA256, aufgerufen von einem überschaubaren C-Programm.

[/quote]Sorry, wenn irgend ein dahergelaufener Forennutzer meint, er kann alleine mal kurz Authentifizierung besser bauen als das das weitestgehend renomierteste Team mit 2x4-Augenprinzip, dann bezeichne ich den schlicht zurecht als größenwahnsinnig.

wanne hat geschrieben:

04.12.2019 15:17:32

das einhältst bist du ohne eingehende Firewall sicherer. Denn was nützlich ist musst du in der Firewall eh freischalten. Die Firewall nützt also nichts. Fügt aber einen Zusätzlichen Angriffspunkt hinzu.

Diese Aussage halte ich nicht grundsätzlich für falsch, aber zumindest teilweise, und definitiv jedoch für unzureichend. Ja, richtig, eine Firewall und dann auch noch fail2ban um einen SSH-Port zu überwachen, halte ich auch für mehr schädlich als nützlich. Gerade auch solche Firewalls wie ufw, die schon als Basic-Ruleset ein Regelmachwerk erzeugt, was mit Transparenz und Überschaubarkeit nun wirklich gar nix mehr zu tun hat, würde ich nie für diesen Zweck der SSH-Port-Überwachung einsetzen. Wenn dann auch noch fail2ban da drin rumfummelt wird das ganze mehr zu einem Glückspiel mit der Sicherheit, als das es eine echte Sicherheit ist.

Aber das gilt mMn absolut nicht für ein individuell und explizit erstelltes 'stateful ruleset' für SSH-Services ... und zwar ohne Firewall-Software und ohne fail2ban. Und die Aussage, dass das sinnlos ist, weil man den SSS-Port ja eh freigeben muss, ist völliger Unsinn. In meinem Regelwerk sind bestimmte Port natürlich freigegeben, aber das heisst noch lange nicht, dass dieses Ruleset irgendeinen WWW-Hansel munter probieren lässt, ob er SSH oder einen anderen Port (resp. den Service dahinter) knacken kann.... pustekuchen, das geht nicht, er hat einen Versuch, dann noch einen zweiten, und das wars. Genau solche Attacken verhindert eben dieses 'stateful ruleset'.

wanne hat geschrieben:

04.12.2019 15:17:32

Erfolgreiche sind ein Problem.

Das Problem bei denen wird aber sein, dass man die gar nicht erst bemerkt... sind die so clever reinzukommen, sind sie vermutlich auch so clever, dass unbemerkt zu tun.