Beiträge von NaN

    logingracetime Ding

    CVE-2024-6387 ist eine Preauth Verwundbarkeit. Dagegen hilft das Port Knocking. Das hilft auch gegen die Brute-Force und Dictionary Angriffe, aber gegen die ist man mit Abschalten von Passwort-Login alleine schon ausreichend abgesichert. Port Knocking hält außerdem die Logs still, so dass ich da keinen Grund für noch eine Schicht mit Wireguard sehe. Ich würde Wireguard statt Port Knocking verwenden, denn immerhin kann man die Anklopfsequenz an geeigneter Stelle im Netz mitlesen, aber da Port Knocking hier nur als zusätzliche Schicht und nicht als alleinige Zugangskontrolle verwendet wird, geht das auch in Ordnung.

    Derzeit nutze ich für SSH nur einen passkey und der root ist abgeschalten sowie nutze ich einen anderen Port.. Zusätzlich habe ich noch knockd als Dienst eingerichtet.

    Das passt schon. Mach dich nicht verrückt. Insbesondere das Port Knocking schützt dich vor Pre-Authentication Angriffen, und wenn du Passwort-Login abgeschaltet hast, brauchen dich die Brute-Force Angriffe darauf nicht mal ohne Port-Knocking zu interessieren.

    Und wo gibt es den?

    Das längste Thema - netcup Kundenforum
    Zu meinem 100. Jubiläum in diesem Forum dieser Spaßthread :p Finde ich immer wieder lustig wie schnell man auf 0 kommt. Lustiger ist es aber neben der Zahl…
    forum.netcup.de

    Aber für den von dir vorgesehenen Zweck reicht der kleinste Server, den du finden kannst, und gegen Wireguard auf dem Host selbst spricht auch nichts, wenn das System das unterstützt. Für Tutorials müsstest du uns verraten, welches System du einsetzen möchtest. Für Debian gibt es drei Varianten im Debian Wiki.

    "anwendung.hosting.de" und "anwendung.meinedomain.anbieter.org" sind verschiedene Domains und müssen entweder im Zeritifikat beide erwähnt werden oder jeweils ein eigenes Zertifikat haben. Wenn du "anwendung.hosting.de" in deinem Nginx konfigurierst und ein entsprechendes Zertifikat bei Letsencrypt besorgst und in deinem Nginx installierst, dann klappt es auch mit der Verschlüsselung. Dass die zwei Domains über den CNAME zur selben IP-Adresse führen, hat für die Zertifikate keine Bedeutung. Die Domains könnten genausogut auf verschiedenen Servern liegen.

    Die Lösung scheint für viele zu sein, einfach zu einem teureren Anbieter zu wechseln, den Spammer wegen des Preises meiden. Das ist natürlich auch eine Lösung. Nur einerseits zu verlangen, dass Netcup etwas gegen die Sippenhaft macht, aber andererseits bei Spamversand nicht hart durchgreifen soll, klingt nach "wasch mich aber mach mich nicht nass".

    Und wie kriegst du die raus?

    UCE3 listet ganze Blöcke von IP-Adressen. Die wenigsten der davon Betroffenen dürften Geld für ein Delisting bezahlen. Ein Loch ist ein kleiner Adressbereich, der nicht gelistet ist, aber von einem großen Bereich gelisteter Adressen umgeben ist. Wie gesagt, die Mühe, die Liste so zu verwenden, wird sich niemand machen.

    Evtl. hilft es, die Absenderadresse des Webformulars bei GMail auf eine Whitelist, 'tschuldigung, Allowlist zu setzen, um diese Fehlklassifizierung der Mails als Spam abzustellen. Der Empfänger will diese Emails haben, und wenn er dies durch die entsprechende Konfiguration bekundet, sollte sich Google nicht in seinem Namen beim Provider des Absenders über die Mails beschweren, selbst wenn da der letzte Dreck drinsteht. "In seinem Namen" deshalb, weil Google unaufgefordert eigentlich gar keine Kenntnis des Mailinhalts haben darf. Automatisierte Abuse-Meldungen sind auch nicht gerne gesehen, oder?

    UCE3 als Blacklist

    Die "Löcher" in UCE3 als Blacklist. Das sind die, die denen Geld gegeben haben. Terrorismus darf man ja auch nicht finanzieren, und wenn man es doch tut, wird man sanktioniert, oder? (Als würde sich jemand die Arbeit machen. Das Beste, was man machen kann, ist wirklich, Uceprotect zu ignorieren, mindestens Level 3, aber dem Rest kann man dann eigentlich auch nicht trauen. Ich will nur deutlich sagen, wie sehr daneben das ist, was da im Namen des Spamschutzes gemacht wird.)

    Wer Uceprotect Level 3 für mehr als eine Warnung verwendet, will keine Emails bekommen. Das einzige, was Netcup sinnvoll tun kann, ist diesen Schutzgeldladen zu ignorieren.

    Wenn du das anders siehst, kannst du deine IP-Adresse aus der Level 3 Liste freikaufen. Aber vielleicht sollten vernünftige Mailadmins keine Mails von Servern annehmen, die in Adressbereichen der Uceprotect Level 3 Liste liegen aber selbst nicht dort gelistet sind, damit Leute diese Methoden nicht auch noch finanziell unterstützen.

    weiß, welcher DNS Eintrag raus muss?

    Am besten der falsche. Den richtigen solltest du nicht löschen.

    (Nach der Anleitung von Framer sollst du zwei A Records für die Domain und einen CNAME Record für die www Subdomain setzen. Alle anderen A und AAAA Records für die Domain und alle anderen Records für die www Subdomain sind damit verkehrt. Wildcard-Records "*" solltest du nicht löschen. Die gelten dann sowieso nicht für die www-Subdomain.)

    da das Problem nicht von mir kommen kann.

    Wenn es nicht von dir kommen kann, also von außerhalb deines Webhostings kommen muss, kannst du es auch nicht lösen. In einem Webhosting-Paket hast du nicht die technischen Möglichkeiten, um anhand des Laufzeitverhaltens herauszufinden, was da los ist. Bei einer Kompromittierung auf dem Hostsystem wäre es aber auch mit vollem Zugriff darauf sehr schwierig, weil man dann davon ausgehen müsste, dass die Bordmittel unwirksam gemacht wurden. Von außerhalb des Systems (z.B. bei einer VM) bräuchtest du forensisches Spezialwissen, um mehr als eine reine Analyse der vorhandenen Dateien anstellen zu können. Nadeln in Heuhaufen sind leichter zu finden. Mit deinem Ansatz, "kann nicht von mir kommen" und "neu aufsetzen ausgeschlossen", wirst du kaum Hilfe finden. Leute, die sich den Stress mit so einem "Auftraggeber" machen, sind nicht für 100€ zu bekommen. Wer gleich mal die wahrscheinlichste Ursache und die sinnvollste Behebung kategorisch ausschließt, braucht ein dickeres Portemonnaie.

    tl;dr drop bringt keinen vorteil

    Die Seite kenne ich. Selbst da wird ein Grund angeführt, warum man evtl. filtern will. Einen weiteren habe ich dir genannt. Mehr Gründe brauche ich nicht. Es tut mir leid, Gesprächigkeit gehört für mich in Zeiten von Shodan und Konsorten einerseits und DDoS andererseits nicht mehr zu einer guten Konfiguration. Ich brauche keinen Portscan, um zu sehen, welche Ports offen sind, und netzseitig habe ich auch andere Möglichkeiten. Wenn ich etwas debuggen muss, habe ich einfachsten Zugriff auf das filternde System und kann genau sehen, was dort ankommt. Wenn jemand anders meint, meine Systeme "debuggen" zu müssen, muss er sich eben etwas mehr anstrengen. Du darfst selbstverständlich weiter deine Firewalls konfigurieren, wie es dir beliebt.

    was denkst Du damit verstecken zu können?

    Nicht viel, aber mein Lieblingsbeispiel ist Wireguard: Das verhält sich genau wie eine "drop" Firewall, wenn die andere Seite den Key nicht kennt. Dann wird einfach gar keine Antwort geschickt. Wenn sich auch deine übrigen UDP-Ports taub stellen, kann ein Portscanner nicht unterscheiden, ob und auf welchem Port etwas ist oder nicht.

    Ein anderer Grund, der meiner Meinung nach für das Abschalten der ICMP-Antworten spricht, ist, dass diese Antworten an die unauthentifizierte IP-Adresse der anderen Seite geschickt werden, also an eine von einem Angreifer frei wählbare Adresse. Damit ist zwar keine Amplification drin, aber Kleinvieh macht auch Mist.

    Das hat NaN doch bereits geschrieben

    Nein, eigentlich nicht. Dass eine default-drop Firewall auch versehentliche Dienste schützt, ist der zweite und wichtigere Grund für eine Firewall, aber das Ziel erreicht man auch mit default-reject. Der Unterschied zwischen reject und drop ist nicht groß und vielleicht eine Frage persönlicher Präferenz.

    Das typische Antwortverhalten von Hosts ohne Firewall, nämlich dass Ports, an die keine Programme gebunden sind, ICMP-Antworten zurückschicken, ist nicht mehr unbedingt, was man heute im wilden Internet haben will. Wenn man eine Firewall als "nur offen, was ausdrücklich erlaubt ist (default deny/drop)" konfiguriert, schützt das auch versehentlich aktive Dienste. Also mach die Firewall an.

    Um die ursprüngliche Frage zu beantworten: Das ist eine Warnung, kein Fehler. PhpMyAdmin erzeugt SQL, das eine Funktion verwendet, die in einer zukünftigen MySQL-Version entfernt wird, aber noch so existiert und funktioniert wie bisher. Bis die Funktion entfernt wird, hat PhpMyAdmin hoffentlich ein Update bekommen, das die neuere Syntax verwendet. Solange kannst du diese Warnung ignorieren.

    Ich verwende schon seit geraumer Zeit dnsmasq

    Dnsmasq ist kein "recursive resolver", d.h. der stellt nur Anfragen mit "recursion requested", weil der sich nicht selbst vom DNS Root ausgehend durchhangeln kann. Die DNS-Server von Spamhaus weigern sich wie die meisten anderen autoritativen Server, solche Anfragen zu beantworten. Du kannst mit Dnsmasq also die Server von Spamhaus nicht direkt abfragen. Für Dnsmasq bräuchtest du einen anderen Resolver, der einerseits Rekursion erlaubt und andererseits von Spamhaus nicht als öffentlich angesehen wird. Solche Server dürften schwer zu finden sein, und auch von Spamhaus gesperrt werden, wenn sie bekannter werden. Du kommst also wahrscheinlich nicht darum herum, einen eigenen recursive Resolver aufzusetzen. Wie das geht, habe ich etwas weiter oben schon am Beispiel von Unbound beschrieben.