Wenn die Antwort an sich schon falsch ist ...
Posts by frank_m
-
-
Die /32 bei der zeiten ipv6 solltest du aber noch ändern
/64 reicht da vollkommen aus.Wenn man gezielt eine Adresse angeben will, muss da bei IPv6 /128 hin. Ob das Sinn macht, sei dahingestellt. Auch wenn man eine KI benutzt, erspart das nicht, dass man sich mit den Grundlagen befasst und versteht, was die KI da ausspuckt.
-
Es sei denn, du hast zusätzliche IPv6 Netze geordert. Das Routing-Ziel für diese Netze muss die Standard-IP des Servers sein, und die besteht aus deinem Prefix und der EUI-64 Host-ID.
-
Hm, ist das notwendig? Sperrt man damit nicht auch potenzielle Nutzer aus?
IPs stehen ja nicht ohne Grund auf den Listen. Wie ich oben schon schrieb: wer es dahin geschafft hat, darf sich nicht beklagen.
-
Um das beurteilen zu können, brauchen wir mehr Diagnoseinformationen, z.B von tcpdump. Gibt es Retransmissions, Out of Order Pakete oder so? Was sagen ifconfig, route etc, wie sehen die Interface Statistiken aus?
-
Nein, es geht im IP Blocklisten per ipset (bzw. nftables Listen). Von IPs, die negativ aufgefallen sind - durch Portscans, PHP Angriffe etc.
-
Wieviel IPs sind das dann ungefähr insgesamt?
70k IPv4 und 1000 IPv6.
Bin neugierig: Was ist der Grund das du Tor Exit Nodes sperrst?
Die waren in der Default Config drin, und ich hatte bislang keinen Grund, sie rauszunehmen.
-
Meine Listen:
Code
Display More"file:///root/ipset/badips" # abuseipd confidence Level 90, die hole ich vorher per wget "https://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1" # Project Honey Pot Directory of Dictionary Attacker IPs "https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1" # TOR Exit Nodes "https://www.maxmind.com/en/high-risk-ip-sample-list" # MaxMind GeoIP Anonymous Proxies "http://danger.rulez.sk/projects/bruteforceblocker/blist.php" # BruteForceBlocker IP List "https://www.spamhaus.org/drop/drop.lasso" # Spamhaus Don't Route Or Peer List (DROP) "https://cinsscore.com/list/ci-badguys.txt" # C.I. Army Malicious IP List "https://lists.blocklist.de/lists/all.txt" # blocklist.de attackers "https://blocklist.greensnow.co/greensnow.txt" # GreenSnow "https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset" # Firehol Level 1 "https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/stopforumspam_7d.ipset" # Stopforumspam via Firehol -
Suche ich morgen raus. Ich sitze nicht mehr am PC.
-
Nutzt jemand von euch ip-Blocklisten (z.B. die von FireHol)?
Ja. Ich benutze folgendes Script, um Listen aus verschiedenen Quellen zu sammeln und zusammenzufassen:
https://github.com/trick77/ipset-blacklist/tree/master
Wenn ja, wie bindet ihr die ein? (Falls ihr nicht crwodsec nutzt) Mit ipset?
Ja, (noch) mit ipset. Ich hab auch ein nftables Regelset und das obige Script so angepasst, dass es nftables Regeln erzeugt, aber die nftables Implementierung in Ubuntu 22.04 hat einen Bug, der bei sich überschneidenden Adressbereichen in den Listen einen Fehler wirft. Das kann man beim Zusammenfassen von Listen aus verschiedenen Quellen praktisch nicht verhindern. Neuere Implementierungen bekommen das hin. Deshalb bin ich im Moment noch auf iptables und ipset, obwohl mein Regelset auch schon für nftables existiert, das hatte ich schon mal erzeugt. Mit dem nächsten großen Update wird auf nftables umgestellt.
Und taugt das was, oder ist es eurer Meinung nach zu viel des Guten, was die Absicherung angeht?
Schwer zu sagen. In meiner Statistik werden tatsächlich mehr Zugriffe aufgrund der Blacklists als aufgrund von Scans auf geschlossenen Ports oder durch WAF geblockt. Aber ob es ein Sicherheitsgewinn ist? Ich weiß ja nicht, ob mich einer der geblockten Zugriffe erfolgreich gehackt hätte.
Andererseits: Wer es auf diese Listen geschafft hat, der muss sich auch nicht beklagen, wenn er auf meinen Server keinen Zugriff bekommt. Wenn die IP von den Listen wieder runter ist, wird sie bei mir ja auch nicht mehr geblockt, ich aktualisiere die Listen täglich.
-
Erstell doch einfach mal eine Netzwerk config für Debian 12 Systeme mit 152.53.125.158/22 und Gateway 152.53.124.1
Für welches Framework? Die Frage ist ja auch noch unbeantwortet.
-
Außerdem, doch, hast du so gesagt.
So werden Aussagen verdreht. Lies du noch mal die Diskussion im Kontext der Äußerungen, dann wird dir klar, dass sich diese Aussage ganz woanders drauf bezieht.
Aber klar, man kann es sich schönreden. Zielführender wäre es, mal an der Lösung zu arbeiten.
-
Lies die verdammte Konversationen, dann wüstest du auch dass es die STANDARD KONFIGURATION von NETCUP ist.
In der Standard Konfiguration von Netcup werden ens3 und eth0 nicht vermischt. Und selbst wenn es so wäre: Das richtig einzurichten ist immer noch dein Job.
-
Aber laut frank_m ja reiner Zufall, weil bei ihm "geht es ja".
Das habe ich nicht gesagt. Ich habe nur gesagt, es wäre schön, wenn wenigstens einer mal mit einer sauberen Netzwerkkonfiguration nachweisen könnte, dass es wirklich an Netcup liegt. Denn das, was hier bislang präsentiert wurde, war eher aus der Kategorie Abenteuer-Cowboy, aber nicht aus der Kategorie Netzwerk-Admin.
-
und der Fehler sieht schwer danach aus, dass die Netzwerkanbindung eines Hostsystems nicht korrekt funktioniert.
Aber warum funktionieren dann die VNC Verbindungen?
-
Wie erklärst du aber die identischen Probleme der 2-3 oder mehr anderen User?
Die Frage muss lauten: warum haben so viele andere aus dem gleichen Subnetz das Problem nicht? Und warum funktioniert alles bis zum letzten Hop vorm Server? Damit sind praktisch alle Theorien zur Fehlerursache aus diesem Thread hinfällig. Stattdessen werden Konfigurationen gezeigt, die geradezu hanebüchen sind, und wenn man konkret nachfragt, was da sonst noch sein kann, wird einem vorgeworfen, dass man nicht liest.
Was würdest du denn daraus schließen, wenn offensichtlich kein Interesse besteht, das Problem weiter einzugrenzen und stattdessen vom Thema abgelenkt wird? Aber anderen vorwerfen, dass sie ihre Arbeit nicht machen, darin übertreffen sich alle.
-
Was das bedeutet kannst du dir jetzt entweder selbst erschließen oder einfach vernünftig Fragen aber so definitiv nicht.
Bei mir läuft ja alles. Du brauchst die Hilfe, und zwar nicht vom Notfallsupport, das ist mehr als offensichtlich.
Sorry, aber das sind absolute Anfängerfehler, die einfach nicht passieren dürfen. Vor allem nicht, wenn man sich dabei über andere beschwert, die angeblich ihren Job nicht machen. Räum erst mal bei dir auf und erstelle eine saubere Konfiguration für dein Netzwerk.
Tests im Rescue Image halte ich für nicht aussagekräftig, da das mit DHCP arbeitet. Es muss eine saubere manuelle Konfiguration in der Standard-Installation her, und die hab ich bislang in diesem Thread nicht gesehen.
-
Es wirkt irgendwie so als ob du dir die Sachen überhaupt nicht durchliest.
Es wirkt eher so, als ob du die Sachen nicht liest. Selbst wenn du recht hättest mit deinem "Alias" für ens3 und eth0 (was definitiv nicht so ist): Du hattest widersprüchliche Konfigurationen für das gleiche Interface in deinen Einstellungen. Da darfst du dich nicht wundern, wenn ich skeptisch bin, wenn es um Schuldzuweisungen geht, denn das ist mehr als dilettantisch, das ist eine Todsünde in der Netzwerkkonfiguration. Welche Böcke hast du sonst noch drin? Vielleicht auch noch mehr als ein Netzwerk-Management Tool? Wie ist deine Firewall eingestellt? Auch die kann den Netzwerktraffic zuverlässig verhindern.
So langsam bin ich an dem Punkt, dass ich erst an die Schuld von Netcup glaube, wenn es bewiesen ist. Hier wurde einfach schon zu viel Käse gebaut. Dazu die Ergebnisse meines Traces von außen auf die IPs.
-
Ich hänge jetzt noch mal alle Netzwerk configs von beiden RS an
Was ist eth0 und was ist ens3?
Vielleicht liegt es nicht daran, aber sauber ist was anderes. Möglicherweise hast du da zwei widersprüchliche Konfigurationen fürs gleiche Interface gebaut. Das kann alles und nichts auslösen, vor allem unter der Berücksichtigung, dass DHCP nicht funktioniert.
-
Wenn Du wie gschrieben einfach nur ein gängiges Minimal Image installiert hast, z.B. "Debian 12 minimal" .. kann es ja eigentlich nicht an Dir liegen.
Auch die muss man erst mal einrichten. Wie hier schon steht: DHCP funktioniert nicht. Man muss eine saubere, händische Konfiguration erzeugen, und dabei Import-Dateien wie die 50-cloud-init.cfg beachten, die gerne mal vor der eigenen Konfiguration geladen werden.
Wie sieht die Analyse bei der IPv6 Konnektivität aus? Routen, Traceroutes von innen und von außen?
Was du auch mal machen könntest: Was kommt bei einem tcpdump alles vorbei? Sind da Pakete deines Routers? Funktioniert die ARP Auflösung bzw. die Neighbour Discovery? Das können alles Hinweise sein, ob es eher an dir oder an der Infrastruktur liegt.
