Beiträge von tab

Welche jails sind denn tatsächlich aktiviert? Was sagt also

fail2ban-client status

Edit: Ich meine gleich nach dem Start, bevor sich fail2ban wieder beendet. Das hat ja laut Logifle eine gute Viertelstunde gedauert.

Steht irgendwas in der /var/log/syslog oder einer anderen Logdatei, was zu der Zeit passiert ist?

Edit2: Hast du vielleicht versehentlich unter [DEFAULT] alle jails aktiviert? Immerhin deutet der Fehler auf das selinux-ssh jail hin, das du ja eigentlich gar nicht aktiv zu haben glaubst.

Man merkt teilweise schon deutliche Unterschiede, zwischen Webhostings mit Datenbank auf dem localhost und mit Datenbank auf einem separaten Server, bei der Performance eines CMS wie Wordpress, TYPO3, Joomla, Contao ... Jedenfalls wenn die Seite nicht aus dem Cache genommen werden kann, sondern komplett neu aufgebaut werden muss. Und da geht es meist um vom Netzwerk verursachte Latenzen deutlich unter 1ms. Wenn du jetzt freilich bei einer Anwendung nur alle paar Sekunden einen Datenbankzugriff hast, dann wird so ein Unterschied gar nicht auffallen.

Zitat von aRaphael

Naja, budcup.de wäre noch frei.

budcup.net wäre auch noch frei, wenn auch etwas teurer als die de-Domain

Also ich habe da so meine Zweifel, dass eine verschlüsselte Verbindung zum Datenbankserver aufgebaut werden kann. Macht man ja lokal meist schon nicht, weil es die Datenbankzugriffe langsamer macht und - hier im Shared Webhosting vielleicht noch wichtiger - der Datenbankserver mehr arbeiten muss. Wozu wird denn die Datenbank überhaupt gebraucht? Wenn Performance halbwegs wichtig ist, würde ich mir lieber lokal einen MySQL/MariaDB -Server installieren. Damit würden gleich mehrere Probleme hinfällig...

• Keine Verschlüsselung notwendig, es kommt kein externer an die Datenbank dran.
• Kürzere Zeit beim Aufbau einer Verbindung und auch bei der Übertragung von Daten (Webhosting ist nur mit 100 MBit angebunden, jedenfalls in der Theorie.
• Keine Ausfallzeit bei Änderung der externen IP.

Anders mag es aussehen, wenn die meisten Zugriffe über das Webhosting passieren und nur die Daten von Zeit zu Zeit von lokal abgefragt werden.

Das bedeutet schlicht, dass der Sender der Weiterleitung (=netcup SMTP-Server) laut dem SPF-Eintrag der Absenderdomain nicht berechtigt ist, E-Mails für diese Absenderdomain zu verschicken. Automatisches Forwarding ist halt nicht so "simpel" wie du denkst. Zumindest auf die Absenderdomain und ihren SPF-Record hast du schon mal in der Regel keinen Einfluss. Insofern bleibt eigentlich nur, dass "mx_von_Zieldomain" solche unauthorisierten Mails toleriert. Wenn du auf diesen Mailserver der Zieldomain auch keinen Einfluss hast und er solche Mails nicht durchlässt - wie es hier laut obiger Meldung der Fall ist - dann kann eine einfache Weiterleitung nicht gelingen, wenn die Absenderdomain darauf besteht, dass Mails mit dieser Absenderdomain von einem nicht zugelassenen Absender gelöscht werden sollen.

Zitat von KB19

Hab's vor ca. zwei Stunden neu gespeichert, jetzt ist DNSSEC bei beiden Domains funktionsfähig

War übrigens meine Schuld: Ich Trottel habe den Record 1:1 von deSEC kopiert, anstatt nur den öffentlichen Schlüsselteil ins große Formularfeld einzufügen. Ich dachte fälschlicherweise, dass das CCP sich den benötigten Teil eh selbst extrahiert. Man sollte halt lesen, mit was die Felder beschriftet sind und was nach dem Absenden drinnen steht.

Warum das dann keine Fehlermeldung erzeugt, weiß ich nicht. Offenbar kommt es so ja auch nie bei der DENIC an. Wäre gut möglich, dass gestern aus diesem Grund die Nameserver nie übernommen wurden. Ich glaube da habe ich das genauso 1:1 eingefügt.

Schön, dass es jetzt geklappt hat. Ich denke, da sollte netcup eine Fehlerbehandlung einbauen, damit der Kunde merkt, dass er etwas Falsches eingegeben hat. In Formulare eingegebene Daten weiterzuverarbeiten ohne sie zu validieren, war noch nie eine gute Idee. Das mag an dieser Stelle vielleicht nicht 100% möglich sein, aber zumindest könnte das Formular einen Hinweis ausgeben, wenn Leerzeichen drin sind. Falls das in einem Key zulässig sein sollte, kann man ja eine Möglichkeit zur Bestätigung der Eingabe einbauen. Das würde dem Support wohl so einige Tickets ersparen.

Was sagt DNSviz zu der Domain beimm Thema DNSSEC?

Ich probier jetzt auch mal mein Glück. Habe noch eine nette Domain geschossen zu Ostern, vielleicht bekomme ich da ja auch mal die selben Probleme wie du. Die stelle ich mal auf meinen privaten Server ein und mit Nameserver bei deSEC. Mal sehen ob es klappt und falls ja, wie lange es dauert. Ich starte mal um 22:50 mit dem Eintragen der wichtigsten Records bei deSEC. Danach dann Nameserver umstellen und DNSSEC bei netcup eintragen

- Öffentlicher Schlüssel weiss ich noch nicht

- Flags: KSK (257)

- Algorithmus: ECDSAP256SHA256 (13)

Upps, schon gleich 2 Minuten Verspätung, los gehts.

Edit: So, jetzt heisst es erst mal warten, bis die Nameserver aktualisiert sind.

Edit2: Keine Ahnung was die DENIC schon weiss, aber Google (8.8.8.8) und Cloudflare (1.1.1.1) haben bereits den richtigen A-Record, der in netcups DNS auf geparkt stand. Mein Unbound auf dem Server zeigt die richtigen Nameserver. Also trage ich mal die DNSSEC Werte ein...

Edit3: Die Werte sind eingetragen, jetzt heißt es wieder warten. Ich gehe mal Geschirr spülen ...

00:14 Tadaa! DNSviz sagt, die Zone entenzeit.de ist SECURE, Unbound zeigt mir bei dig das ad Flag. That's it! Ich habe fertig!

Hm, 23 Jahre Mindestlaufzeit?

Zitat von Valkyrie

ich bin nicht der größte Nginx Guru, aber ich glaube das sieht in Ordnung aus. Wirst du ja letztenendes bemerken
Aber willst du wirklich alles auf deine xyz.at umlenken? Die neue Domain ist also nur mehr oder weniger eine Weiterleitung?

In dem Fall dann das canonical Tag nicht vergessen im Header.

Zitat von KB19

Wie lange dauert das eigentlich normalerweise, bis externe Nameserver bei einer Domain aus dem CCP bei der DENIC landen?

Vor mehr als 24h mit zwei (!) Testdomains ausprobiert und jetzt stehen noch immer die netcup NS drinnen und nicht die von deSEC. Hängt das wirklich gleich bei zwei Domains? Habe ich echt so viel Pech?

Ja, oder ich habe immer Glück. Nach 1-2 Stunden war bisher immer alles durch. Habe zwar nie bei der DENIC gecheckt, aner wenn DNSSEC laut DNSviz ohne Warnung funktioniert, dann muss wohl alles ordnungsgemäß eingetragen sein .

Was das anrichten kann sieht man beim roten H. Man wird über zwei (Sub-) Domains von H-Kunden auf die Phishing-Site umgeleitet. Beide Domains haben so einen Wildcard-Eintrag, aber ich bin mir ziemlich sicher, dass kein normaler Kunde den Eintrag so machen würde (auf einen Server von Zenlayer in Fernost ). Langsam frage ich mich, ob das rote H da vielleicht einen klitzekleinen Bug hat beim DNS, der es Außenstehenden oder anderen Kunden irgendwie ermöglicht, so einen Wildcard-Eintrag für eine fremde Domain zu setzen. Vor 2 Stunden war die Phishing-Site immer noch erreichbar über den Link in der Mail . Hat vielleicht jemand die Kreditkartendaten von Martin H? Dann klappts vielleicht etwas flotter, wenn die erste Million transferiert ist .

Wie sehen denn Owner, Group und die Rechte aus für den Ordner und die Datei .htaccess? Sehen und teilweise ändern (die Rechte, aber nicht Owner/Gruppe) kannst du es im Dateimanager und per SSH (chmod).

Vor welchem Problem? Dass es verwirrend ist?

Schau mal nach ob /etc/resolv.conf ein Symlink ist oder wirklich eine Datei. Normalerweise ist es mit systemd-resolved ein Symlink. Die Datei, auf die der Symlink verweist, wird regelmäßig vom System überschrieben. Es gibt da mehrere Modi. Je nachdem muss der Symlink auf eine andere Datei verweisen. Die eigentlichen Einstellungen sind woanders zu machen, in /etc/systemd/resolved.conf. Oder eben alternativ systemd-resolved deaktivieren und disablen, nur deaktivieren/stoppen ist natürlich nicht persistent. Dann den Symlink /etc/resolv.conf löschen und eine Datei /etc/resolv.conf anlegen, darin kannst du dann auch deine Nameserver angeben auf die alte Art und Weise, ohne systemd-resolved.man systemd-resolved hilft , es gibt auch genug Info im Internet dazu, allerdings auch falsche.

Wer weiss, welche Schadsoftware Debian mitbringt...

Weil das Wirtssystem trotzdem läuft.

Super Arbeit, rotes H! Die Phishing-Seite ist über den Link in der Mail immer noch erreichbar. Die Abuse-Meldung ist ja auch erst 24 Stunden her. Scheint also nicht so dringend zu sein.

Aber auch nett, die Konsolenbefehle. Das erinnert mich immer an die Geschichte mit der studentischen Hilfskraft, die sich auf gewohnte Weise vom System abgemeldet hatte: "kill -9 -1", als normaler User an der Konsole eingegeben. Originalzitat: "Das machen wir an der Uni immer so". Das mag dort auch tatsächlich nebenwirkungsfrei funktioniert haben. Das dumme war nur, dass das installierte SCO-Unix irgendwie nicht so toll war, da liefen wichtige Systemprozesse unter dem angemeldeten User, keine Ahnung wer sich das System so ausgedacht hat. Jedenfalls war dann halt ein Neustart fällig, erst danach lief die Kiste zum Glück wieder. Zur Freude der 3-4 anderen Mitarbeiter, die von anderen Stockwerken aus angemeldet und am arbeiten waren.

Hätte man sicher auch über Konsole machen können mit dem geeigneten Bootmedium. Aber ich denke einfacher, sicherer und schneller wird man das gewünschte Ziel schwerlich auf anderem Weg erreichen können.

Zitat von Bud

Da ich vor morgen Mittag eh nicht mehr dazu komme, lasse ich das nun einfach euch entscheiden

Und eine kleine Frage noch zwischendurch: Mir ist aufgefallen das im SCP steht: 17 / 20 GB belegt. Da ich gerne auf einem plattem Server anfangen möchte: Gibt es eine Möglichkeit den Server komplett zurückzusetzen und alles zu löschen? Formatieren quasi?

Im SCP unter Medien -> Festplatte löschen.