Posts by Andi22

    @Dbone um nochmal auf Deine Frage einzugehen, laut den AGBs ist Mining an sich verboten, egal wie viel Ressourcen es benötigt.


    Und sehr viele hier (inklusive mir) finden das auch gut so.

    Unter anderem können Anbieter wie Netcup uns so tolle Angebote machen, weil sie eine Mischkalkulation haben. Wenn jetzt viel Ressourcen für Mining verwendet werden, dann passt diese Kalkulation nicht mehr. Entweder leiden dann die anderen Kunden auf dem Server darunter, weil sie mit den Minern um die Ressourcen kämpfen, oder die Preise müssen angehoben werden.



    Mal blöd gefragt, Du schreibst :

    1. vim /etc/hostname
    2. domain.de

    Steht da wirklich "domain.de" drin ?


    Sollte da nicht ein eigener Server-Name drin stehen, statt einem FQDN ? (Und wenn FQDN, dann aus 3 Teilen bestehend, statt 2 ?)


    z.B.

    1. vim /etc/hostname
    2. meinserver1

    und dazu

    /etc/hosts

    127.0.0.1 meinserver1.domain.de meinserver1


    @Andi22 ja korrekt, wenn ein PW mit "md5/hash" generiert wurde, klappt es nicht direkt mit "hash_equals" sprich es müssen alle PWs "umgewandelt" werden.

    mit strcmp und anderen Abfragen, kann man das ganze schon gut härten.

    Kannst Du das nähers erläutern ?

    Warum soll man "hash_equals" nicht verwenden können ? Funktional entspricht es (strcmp(string1,string2) === 0) (siehe php-git)


    Quote

    meines erachtens sollte man direkt auf password_hash und password_verify gehen, wird ab 5.4 unterstützt. vielleicht nicht direkt auf Argon (da erst ab 7.2).

    Genau das wollte ich damit sagen. Volle Zustimmung.

    Ich will jetzt nicht pedantisch sein, aber für den Fall, dass jemand über eine Suche hier her kommt würde ich gerne ein paar Anmerkungen schreiben.


    Wenn man keinen besonderen Grund hat (z.B. Lerneffekt oder Interoperabilität mit anderen Sprachen) ist es fast immer eine gute Idee die eingebauten Funktionen einer Sprache zu verwenden.


    Hier also password_hash und password_verify


    Man kann bei einer Passwort-Hashing Funktion viel falsch machen, und bei den eingebauten Funktionen haben sich schon viele Entwickler mit dem Problem auseinandergesetzt.

    Und man profitiert automatisch von Verbesserungen die in neuen PHP-Releases implementiert werden.


    @Gunah Du hast Dich wahrscheinlich vertippt. Wegen der Timing Attacken sollte man die (von michi verwendete) hash_equals Funktion verwenden, und nicht strcmp.

    PHP strcmp verwendet die libc memcmp Implemetierung (siehe github und gehe zu ZEND_FUNCTION(strcmp)). Zumindest in der glibc ist diese aber genau für diese Timing Attacken anfällig (siehe Gnu-glibc-git)


    hash_equals macht einen, Timing Attacke sicheren, String Vergleich (Hat genau genommen gar nichts mit einem Hash zu tun. Es werden einfach 2 Strings verglichen).


    password_verify hingegen verifiziert ob ein Passwort-String dem speziell formatierten Hash-String, der von password_hash zurückgegeben wurde, entspricht.

    In diesem Hash-String ist unter anderem der Salt enthalten, so dass password_verify mit diesen Informationen und dem Passwort wieder einen Hash berechnen, und mit dem übergebenen Hash vergleichen kann.


    michi Viel Spaß und Erfolg mit Deinem Projekt!


    Jetzt wünsch ich Euch allen frohe Ostern und ein schönes Wochenende,

    Andi

    Hallo Michi,


    in testpwd erzeugst Du jedes mal einen neuen zufälligen salt. Dadurch kommt auch bei gleichem "alten" Passwort immer ein anderer Hash heraus.

    Du musst den gleichen salt verwenden, wie beim gespeicherten PW.

    Passend zu password_verify , kümmert sich password_hash automatisch darum

    Seit wann limiert netcup eigentlich die ausgehenden Mails pro Mailadresse auf 100 pro Stunde? Gibt es hier keine Möglichkeit, den Wert anzupassen, ich meine ja nur...

    Früher waren es wohl sogar noch weniger.

    Laut diesem Forums-Post wurde die Anzahl im September 2017 auf 100 hoch gesetzt.

    Und laut diesem Post gibt es aber noch folgende Möglichkeit:

    Quote

    Wir können auf Nachfrage und mit guter Begründung das Limit individuell erhöhen. Unsere Erfahrungswerte zeigen, dass ein Kunde nicht mehr E-Mails je Stunde verschickt. Wenn doch, ist dieses meistens aufgrund eines gehackten Scripts oder ähnlichem. Wir sind im Interesse aller Kunden sehr darum bemüht, dass die IP-Adressen der Mailserver nicht in Blacklisten landen. Daher müssen wir hier ausgewogene Limits setzen.

    Hab mir die Links extra aufgehoben, für den Fall dass ich sie mal brauche, wie z.B. jetzt ;)

    Zusätzlich zu DokuWiki würde ich noch 2 andere Wikis empfehlen (Confluence kenne ich nicht)


    http://zim-wiki.org/

    Ist ein Dektop Wiki mit Wysiwyg Eingabe, und es gibt tolle Plugins. Läuft unter Windows und Linux. mac ist etwas aufwändiger.

    Hat den Vorteil, dass man keine Server braucht, wenn man z.B. nur einen hat, und gerade notieren will, was man gemacht hat.

    Nutze ich sehr häufig.


    http://www.pmwiki.org/

    Ist einfacher als DokuWiki, speichert in Files statt in eine DB. Extrem einfach aufzusetzen.

    Hat auch eine große Community.


    P.S. Zim speichert auch in normalen Dateien ab mit einem ähnlichen Syntax wie DokuWiki. kann man also auch mal leicht in einem normalen Editor öffnen

    Wie schon gesagt, der PTR-Record für 1.2.3.4 ist hier irrelevant, da ja 2.3.4.5 die Mails verschickt.


    Wenn 1.2.3.4 keine Mails verschickt, kann auch nichts schief gehen, egal was in dessen PTR-Record steht.


    Der PTR-Record sollte genau dem FQDN entsprechen, den der MTA bei der Kontaktaufnahme mit einem anderen MTA verwendet:

    das könnte z.B. "HELO mein_hostname.meine_domain.de" sein.

    Wie schon geschrieben, kann der Name (FQDN) konfiguriert werden. Postfix z.B. verwendet hierfür den Parameter smtpd_banner.

    Auf vielen Servern entspricht der wahrscheinlich dem FQDN des hostnamen. Muss er aber nicht.


    In diesem konkreten Fall:

    Da es ein Managed Server ist würde ich den Support fragen welcher FQDN für das HELO des MTA konfiguriert ist.


    Offtopic: Wer hat eigentlich das Schachspiel gewonnen ? :)

    Nochmal in klareren Worten ;)


    Der PTR-Record ist nur wichtig, wenn ein Mailserver Mails verschickt. Für den Empfang von Mails ist er unwichtig.


    Beim verschicken einer Mail kontaktiert Dein Mailserver einen anderen und schickt diesem unter anderem ein "HELO" + seinen konfigurierten MTA-Name/Hostname.

    Dieser ist unabhängig davon welche Domain die versendende Emailadresse hat.

    Im PTR-Record muss genau dieser MTA-Name/Hostname stehen.


    Ob das für IP 2.3.4.5, mx1.domain.email oder domain.email, oder gar ein ganz andere Domain ist, musst Du natürlich vorher überprüfen.


    Für die IP 1.2.3.4, falls hier ein Mailserver Mails direkt versenden soll, genauso. Könnte hier z.B. domain.de sein


    Für Postfix kann man das zum Beispiel unter

    /etc/postfix/main.cf

    nachschauen

    Quote

    Mails laufen alle über einen dedizierten Server mit der IP 2.3.4.5


    Ich mach mal einen Versuch. Bitte korrigiert mich, wenn ich mich irre. Ich bin kein Admin.


    Du musst gedanklich eine Unterscheidung zwischen dem Mailserver und den Domains, die er verwaltet, machen.


    Der PTR-Record muss zu dem Mailserver passen.

    Dein Mailserver, vermute ich, ist unter mx1.domain.email erreichbar. Mit dieser Domain sollte er sich dann auch beim oben erwähnten Helo melden (wenn er richtig konfiguriert ist).

    Der PTR-Record von 2.3.4.5 sollte also auf mx1.domain.email verweisen.


    Dass dieser Mailserver deine Mails für domain.de verwaltet ist für den PTR-Record irrelevant.


    Der PTR-Record von 1.2.3.4 ist für Dein Mail-Szenario irrelevant, weil nie ein anderer Mailserver (z.b. der von google, gmx, ...) mit der IP zu tun haben wird.

    Ich gehe hier natürlich davon aus, dass die Mails auch über mx1.domain.email verschickt werden.

    Zuerst mal vielen Dank an Netcup für den tollen, professionellen Service, und die offene Kommunikation, die sie hier bieten. Weiter so :-)


    Bezüglich der "nicht sauber" heruntergefahrenen Gastsysteme:

    Könnte es sein, dass dadurch, dass alle VMs den ACPI Befehl (fast) gleichzeitig bekommen es auf manchen Hosts zu Überlastungen kommt? Also besonders auf Systemen mit SAS-Platten. Wenn die CPU-Last dann hoch ist, und viele VMs gleichzeitig noch versuchen Daten auf die Platte zu schreiben, könnte ich mir vorstellen, dass es zu ordentlichen Verzögerungen kommt. Ob die so groß sind, dass die 5 Minuten, die Netcup wartet, überschritten werden, das ist natürlich eine andere Frage.

    Vielleicht kommt es ja zu einer unglücklichen Verkettung von mehreren Umständen.

    z.B. habe ich gelesen, dass einige HPE Raids Probleme hatten.

    Könnte es sein, dass diese vielleicht noch Daten im Cache hatten, die noch nicht auf die Platte geschrieben wurden?


    Grüße,

    Andreas