Beiträge von Andi22

Verbesserungsvorschlag: VM inaktiv/ SCP Autostart Einstellung bei VM Migration beachten.

Auf meinem Root Server hatte ich das Debian 9 Image installiert.

Allerdings habe ich mich dann nicht einmal eingeloggt, sondern den Server sofort heruntergefahren.

Außerdem habe ich die Autostart Option deaktiviert:

scp_Autostart.png

Am 18.4 habe ich eine Mail erhalten mit der "Meldung über Migration Ihres vServers" (danke dafür).

Heute hatte ich etwas Zeit und habe festgestellt, dass der Server seit 31 Tagen, also seit der Migration, lief.

Erwartet hätte ich, dass er aus ist, da ich ihn ja ausgeschaltet hatte, und Autostart auch aus ist.

Wenn Autostart aus ist, würde ich erwarten, dass der Server auch nicht wieder gestartet wird.

Wenn er im Moment der Migration läuft, kann man darüber diskutieren, ob er auf dem neuen Host wieder gestartet werden soll, oder nicht.

Aber wenn er ausgeschaltet ist, dann sollte er definitiv nicht einfach gestartet werden.

Im SCP-Log stand auch nichts.

scp_log.png

Davon mal abgesehen ist es interessant die Statistiken von einem Root Server zu sehen, der nach einer frischen Image Installation "einfach so" lief.

Stat_CPU.pngStat_IOPS.pngStat_PPS.pngStat_Net.png

Die 2k Write IOPS haben mich doch etwas überrascht. Das finde ich recht viel.

Da ich, auf die Schnelle, bis auf viele erfolglose SSH Brute Force Angriffe nichts feststellen konnte, stammen diese vermutlich von den Log Einträgen der erfolglosen Login Versuche.

Ich bin gerade am überlegen, ob ich

a) mir das Nähers anschaue

b) mal Spaßeshalber den SSH Port ändere, und ein paar Tage später die Statistik anschaue.

Zitat von RHA

Darf ich fisi auf einen Schreibfehler in seinem Angebot hinweisen? ..... Traffic / Monat flaterate

Dann will ich auch

Auf der Newsmailer-Seite : "Sprechen Sie Iren Kunden mit Namen an".

Fehlt da ein h oder ein r

Schön gemacht Seite. gefällt mir.

Zitat von mainziman

wobei aus Gründen des Anstands würde ich mal Fragen ob ein prime95 od. damit vergleichbares auf einem Root-Server erlaubt ist?

(das Ergebnis, daß zumindest 1 Core bzw. 1 Thread der CPU bis zum Anschlag ausgelastet ist, ist das selbe wie beim Mining)

Ich würde es mal so ausdrücken:

Nicht alles was man kann und darf, sollte (oder muss) man auch tun.

Und wie u.a. geekmonkey und ich auch schon geschrieben haben, kann das Konzept leider nicht funktionieren, wenn alle Benutzer ihre Ressourcen voll ausnützen.

In der Praxis war das, vor dem Mining, wahrscheinlich kein Problem, weil es wenige Anwendungen gibt, die die ganze Zeit die CPU, oder den IO voll auslasten.

Sicher haben nur wenige das Geld für einen Server ausgegeben, um monatelang Prime laufen zu lassen

Und die paar die z.B. non-stop Videos oder Bilder konvertiert haben, o.ä. sind wahrscheinlich nicht ins Gewicht gefallen.

Das hat sich mit dem Mining leider geändert.

Hi Peter,

ganz Deiner Meinung.

Leider hat man ein ähnliches Problem, wenn man einen Tor-Server betreibt. Mit einer der Gründe, warum ich dazu zu feige bin.

Grüße,

Andi

Hi Dbone,

ich hab zwar wirklich eine negative Einstellung gegenüber Mining, aber diskutieren, und fragen befürworte ich immer. Wäre ja schlimm wenn das nicht mehr gehen würde

Ich hab mir die Webseite von Storj mal angeschaut, um nicht etwas zu verteufeln, das ich gar nicht kenne.

Wenn ich das richtige verstehe, handelt es sich um ein verteiltes Speichersystem, wo man im Endeffekt Geld für den Speicherplatz, den man zur Verfügung stellt, bekommt.

Ich finde das Wording hier schlecht gewählt. In deren FAQ steht

Zitat

This is comparable to traditional crypto-currency mining; in the same way you can use your computer's GPU to mine Ethereum, you can use the hard drive space to farm STORJ

Aber das hat mit Mining, so wie ich es verstehe, nichts zu tun.

Für alle hier, die storj auch nicht kennen: Dateien werden verschlüsselt, und in kleine Teile zerlegt. Diese Teile werden dann über das ganze Internet, eben auf sogenannte "Storj Share" verteilt. Irgendwo wird dabei auch eine Blockchain verwendet (hab jetzt nicht nachgelesen, wie oder wo). Sie werben damit, dass es schnell, da verteilt, sicher, da verschlüsselt, und verteilt (niemand außer dem Benutzer selbst hat alle verschlüsselten Teile einer Datei), und günstiger ist, da ungenützter Speicher von anderen Usern, wie z.B. von Dbone verwendet wird.

Dafür bekommt man wohl im Endeffekt Geld, aber das hab ich mir nicht mehr durchgelesen (Also keine Ahnung, ob man da "echtes" Geld, oder eine von denen erfundene virtuelle Währung bekommt, oder was auch immer).

Und die nennen den ganzen Vorgang dann Farming.

Bevor ich so was auf hier auf einem Server verwenden würde, würde ich zur Sicherheit bei Netcup nachfragen. Aber anstatt es Farming oder Mining zu nennen, würde ich beschreiben, worum es geht. Sonst kommt man schnell auf falsche Gedanken (wie ich ja auch).

Hallo Dbone,

ich muss zugeben, dass ich Sia und Co nicht kenne.

1-2% CPU und 17 HD Zugriffe pro Tag sind natürlich wirklich nichts was eine Mischkalkulation durcheinander bringen sollte

Außerdem will ich natürlich auch nicht sagen, dass man seinen Server nicht verwenden soll. Wie 03simon10 und Tarry91 schon geschrieben haben, zahlen wir alle schließlich für die angebotene Leistung.

Trotzdem bin ich gegen Mining (zu Farming hab ich mir noch keine Gedanken gemacht). Um etwas virtuelles Geld zu verdienen, werden viele echte Ressourcen (Strom,...) "verbraten". Und darin sind wir Menschen leider sehr gut.

Aber meine Meinung ist in dem Fall eh nicht wichtig. In den AGBs ist Mining nun mal verboten, und die Diskussion ob Farming auch Mining ist oder nicht, muss Netcup (oder ein Gericht) klären.

@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

Zitat von Gunah

@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)

Zitat

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

Zitat von 03simon10

Ich habe gerade nochmal geantwortet und auf Felix' Beitrag verwiesen, mal schauen, was dabei rauskommt.

Dann drücke ich Dir die Daumen, und hoffe Du berichtest.

Zitat von 03simon10

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:

Zitat

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

Inzwischen läuft ASP.NET Core, sogar offiziell, auch unter Linux und OS X.

Man kompiliert die ASP.NET Core Anwendung für Linux und kann das Ganze dann einfach auf, unterstütze Linux Versionen, kopieren und die exe starten.

Mehr Details schreibe ich dann auf Wunsch.

z.B.: Installing the ASP.NET Core 2.0 runtime store on Linux : https://www.devtrends.co.uk/bl….0-runtime-store-on-linux

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

Zitat

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