Beiträge von Ente-Unser

    Selbstverständlich werde ich euch berichten.

    Ich bin wirklich sehr gespannt und werde immer mehr bestärkt, dass es an Netcup liegt.

    Habe ebenfalls folgenden Artikel gefunden:

    Der primäre Grund, aus dem wir den 502 Bad Gateway Error typischerweise sehen, ist wegen eines Problems mit dem Web-Host. Manchmal braucht eine Abfrage, ein Skript oder eine Anfrage zu lang und deswegen wird es abgebrochen oder vom Server gekillt. Viele Hosts, vor allem Shared-Hoster wenden etwas an, was sie „Kill Skript“ nennen. Was dies grundsätzlich macht, ist, dass es eine Anfrage nach einiger Zeit beendet, damit die Seite nicht zusammenbricht oder andere User beeinträchtigt werden. Wenn du eine Twitter-Suche für Bad Gateway machst, kannst du tausende von Tweets sehen, die jeden Tag auftauchen, um ihre Hosting-Company auf das Problem aufmerksam zu machen.

    Quelle: https://kinsta.com/de/blog/502-bad-gateway/

    Uhm ja.. Das sind einfach nur Timeouts, gerade um DoS zu vermeiden ?!

    Das sagt rein gar nichts. Die Frage ist doch eher an wem es liegt: Ist der Host zu langsam für dein Script oder hat dein Script 'n Schaden und läuft in eine Loop ?!

    Fun story: Fehlermail heute bekommen von einem Stück Software von mir "Retried 10 times, waiting 4800 seconds max.".

    Denk mir nix, nutze ja 'ne fremde API, schaue in die Logs:

    Code
    Response: {"APImessage":"Invalid column name 'RANK_REWARD_RECV'.","APIresult":"E500","Total_Count":null,"Count":0,"members":null}

    Warte was, das ist deren API Antwort..

    Schaue auf die Website: Alles broken "No information available".

    Billig in den Käfig holen, dann Preise anziehen. Als ich das vor 4 Jahren sagte bekam ich einen Vogel gezeigt. Willkommen in der Realität

    Das ist ja auch kein angezogener Preis. Das liegt nur an der Inflation, Corona, dem Wetter und der roten Ampel. Ist quasi der gleiche Preis wie vorher.

    Wer Ironie findet hat 'n VogelEnte

    Oder war das anders gemeint

    War so gemeint dass mir gerade aufgefallen ist, dass meine Config wohl nicht mehr aktuell ist. Glaube das Problem hast du nicht ;)

    Wäre mir auch net aufgefallen, wenn ich mich net mal wieder ins Adminpanel eingeloggt hätte. In den Updates teilt ers einem ja net mit.

    Nginx config für nextcloud hat sich mal wieder geändert. Und meine php8.2 zu 7.4 installation hat natürlich den cronjob erschlagen. Erstmal auf systemd timer migriert, damit ist wenigstens das log durchschauen einfacher.

    ist der begriff softwareless-server schon etabliert? damit ich mich um keine updates kümmern muss? oder der begriff single-user-for-everything?

    und wer seine services nicht auf vhosts betreibt dem kann man eh nicht helfen. aber ist vielleicht auch nur eine frage der zeit bis die abgegrast werden.

    jeder größere webhoster hat phpmyadmin zugänglich.

    Eine große Kiste für alles kann sich für einige mehr lohnen. Gerade wenn du manchmal viel Leistung für A und manchmal für B brauchst. Genauso wie du offenbar gerne deine Systeme so fährst, fahren andere sie gerne anders.

    das trifft auf jeden anderen service auch zu: wordpress, webmail, imap, smtp, ssh, cal-, carddav, webdav, …

    Dein Wordpress wird von vielen Leuten betrieben und entsprechend eingerichtet mit dem Wissen, dass dieses von außen erreichbar ist. Gilt erst recht für alle anderen Anwendungen die du genannt hast.

    Mein PhpMyAdmin kommt nachträglich auf eine DB-Installation welche vorher nie damit konfrontiert wurde, dass sie jetzt von außen mit Logins rechnen muss. Weitere mögliche Problematik: Socketauth. Dann ist der Login in dem Moment geschehen wo der Web-User auf den Socket connected.

    Alles in allem mag das alles gehen, ich packe aber eine Administrationsoberfläche mit php, welche auf meine zentrale Datenbank zugreift lieber hinter irgendeine Form der Absicherung. Und sei es ein Verzeichnis mit gewürfeltem Namen. Dann ersparst du dir im übrigen die Menge an Fail2Ban Einträgen, welche alle mal den 0815 Kram im Login durch probieren. Ich werde daher für eine unbekannte Konfiguration im Forum eher davon abraten sich eine potenzielle Sicherheitslücke ins Boot zu holen. Erst recht weil es eine weitere Applikation ist, welche Updates erhalten muss, ansonsten wird der PHP-Code selbst das nächste Einfallstor. Und seien wir ehrlich: Wer updated sein phpmyadmin regelmäßig ?

    P.S.: Bei den Wordpressinstallationen gibts ja auch genug Angriffe und Suchen nach /admin bereichen.. Scheint sich also auch hier zu lohnen.

    Edit: Kenne auch Mysql installationen mit anonymen default user für stats, dann ist hoffentlich nix falsch in den Rechten gesetzt..

    das durchprobieren von passwörtern zu verlangsamen

    Hm, aber in der Praxis willst du eigentlich nie eine IP beim login komplett ausschließen. Sonst erschießt du dich selber oder sorgst bei CG-NAT für einige Probleme. Und für echten Login-DoS gibts genug IPs dass dein Filter einfach irgendwann gigantische IP-Mengen in den Tables packen. Da hilft es eher wenn dein System a) lange genug braucht um den Login als Falsch ab zu weisen und b) per Rate-Limiting sehr viel unterschiedliche IPs braucht. Du musst da ja garnicht viel Limitieren, es reicht wenn ich ein paar ms pro Anfrage und viele IPs brauche, dann wirds schon unwahrscheinlich bei guten Passwörtern ein Ergebnis vor dem Hitzetod des Universums zu finden. Sonst nimm echte Captchas, dann hast du das beste aus beiden Welten: Harte Limitierung aber kein Ausschließen von echten Nutzern.

    Persönlich ist mir da die Menge an Log-Parsing und IP-Table befüllen zu viel "Gefühlte Sicherheit". Wenn ich in diese Probleme wirklich fallen sollte, dann packe ich gleich Cloudflare davon, mit 'ner WAF-Rule für "managed captcha" auf "/login".

    was spricht dagegen

    Ich bekomme genug Botanfragen ob ich net phpmyadmin drauf habe, und ich möchte nicht ausprobieren wie gut mein system hier mit einem login DDOS leben kann, oder ob alle Datenbanken hier auch gute Passwörter verwenden. Es ist eine indirekte Schnittstelle zur Datenbank, welche normalerweise extra nur auf localhost reagiert. Außerdem gibt es ja extra eine Config-Option für auto login.. Daher lieber garnicht erst zugänglich machen.

    Ich gebe mal eine Gegenmeinung: Ich habe lange f2b eingesetzt, ich nutze es seit einiger Zeit gar nicht mehr.

    F2B hat nämlich zwei Probleme. Erstens muss deine Applikation sowieso damit klar kommen, was so an Müll hereinkommt, dein SSH muss also auch entsprechend sicher sein. Damit hilft F2B daher nicht viel gegen einen echten verteilten Angriff. Und zweitens müllt es dir im Zweifel nur die Nftables mit IPs voll. Was bei IPv6 richtig lustig werden kann. AFAIK gab es irgendwann die Entscheidung daher ganze /64er Netze zu blocken, immerhin bekomme ich hier auch einfach ein ganzes /64er Netz, viel Spaß, das einzeln zu blockieren. Es zeigt aber die Problematik auf. Die ganzen Mails von F2B erzeugen dazu noch einiges an Noise.

    Daher würde ich einfach den Port von SSH ändern, key-login-only, am besten ohne Root. Und dann ein paar Ratelimits auf kritische Bereiche (login) packen, was dein Apache/Nginx/.. schon kann. Wenn einer dir wirklich böse will, dann wird die F2B vermutlich auch nicht mehr viel bringen, im zweifel ist deine Kiste dann einfach überfordert.

    Deine Sicherheit sollte nicht davon abhängen ob jemand zufällig rechtzeitig von F2B erwischt wird, bevor deine Systeme gehackt sind, und die paar Logins auf SSH sollten auch kein Problem sein. Gerade mit anderem Port.

    Für mysql/mariadb kannst du natürlich phpmyadmin nutzen um herum zu experimentieren, das nimmt einem anfänglich das erstellen von dem ganzen SQL ab und ermöglicht visuelles editieren. Für PostgreSQL gibts gleich 'ne ganzen admin oberfläche mitgeliefert. Phpmyadmin bitte _nicht_ öffentlich zugänglich machen, zur not pack es passwortgeschützt in einen Ordner aus 20 Zeichen an Zufall.