Posts by Andi22

    Oha. Also ich weiß mittlerweile, dass es um eine Fabrik geht, die Namen "vermietet" ( :D ) aber ich hab damit irgendwie gar nichts rausgefunden :( Außer n paar tweets von dir in denen aber nur diskutiert wurde.

    Ich dachte es geht um Probleme (Router Probleme, etc) in dem Cloud Angebot eines Konkurrenten, der erst seit Anfang dieses Jahres ein cloud Angebot hat, und häufig auf der letzten c't Seite wirbt

    Richtig, aber die hätten sowieso keinen Erfolg wegen unbekanntem Benutzernamen und starkem Passwort + Fail2Ban, daher ist es völlig egal, ob die sich am Port 22 abarbeiten oder nicht. Nach 5 Fehlversuchen innerhalb vordefinierter Zeit ist erst einmal Schluss.


    Daher sehe ich auch nur den Vorteil der weniger zugemüllten Logfiles.

    Ich seh noch einen weiteren Vorteil. Wenn es einen zero-day-exploit für SSH gibt, oder so was wie den Debian-Bug im OpenSSL-Zufallszahlengenerator, dann hat man etwas mehr Zeit zum updaten als die, die den Port nicht geändert haben. Je mehr den Port nicht geändert haben, umso mehr Zeit hat man, weil die Bösewichte ja gar nicht mehr wissen wohin mit den ganzen gehackten Servern :D

    Zum Glück darf ja jeder seine eigene Meinung haben.

    Und ich persönlich bin jedem dankbar, der den SSH-Port nicht ändert (oder sein Fahrrad vorm Haus lässt ;)). Würden nämlich alle ihren Port ändern, würde es gar nichts mehr bringen.

    Danke an das Suse-Team. Dank ihrer 6.x bin ich heute verheiratet :love:

    Und ich schäme mich etwas dafür, dass ich trotzdem hauptsächlich Debian verwende :whistling:

    C64 rulez :saint:

    Quote

    Zum Port Knocking und zum Ändern von Ports: Das ganze soll in einer Standard Umgebung funktionieren. Sprich auch, wenn ich mich in einer "Enterprise" Umgebung mit Proxy und Company Firewall befinde. Und das geht nun mal nur über Port 22.


    Was haltet ihr von der Idee Port Knocking über den Umweg Webserver zu machen (wenn eh einer auf dem Server läuft).


    Also Port Knocking wird von einem Skript, z.b. in PHP oder Pyhton, ausgeführt, das ganz normal über http oder https aufrufbar ist.

    Evtl mit Passwort-Schutz, wenn man will.


    Vorteile:

    - Port ist nur offen, wenn er gebraucht wird, Port Knocking eben

    - sollte auch mit erwähnter ""Enterprise" Umgebung mit Proxy und Company Firewall" funktionieren

    - kann leicht automatisiert werden, indem besagte Webseite einfach vorher per curl aufgerufen wird

    - Webserver-Skript benötigt, dank Port Knocking, keine root Rechte


    Varianten

    - Port Knocking nur auf localhost erlauben

    - noch mehr security by obscurity, indem die Webseite ein ganz normale Seite mit einem Formular ist, und nur wenn z.B. bei Straße und Postleitzahl etwas bestimmtes steht, wird geknockt.

    - Skript könnte auch auf einem anderen Server laufen, wenn man das für mehrere VMs verwenden will, aber dann geht Punkt 1 nicht mehr (localhost)

    Geht es Dir um das übertragen der Datei, oder willst Du jetzt wissen, woran es liegt ?

    Wenn es um die Datei geht, und da Alice eh bald abgestellt wird, könntest Du sie doch einfach mittels des Rettungssystems kopieren.

    Zählst Du security through obscurity als Vor- oder als Nachteil? Wenn Dich die IO-Spikes stören, solltest Du eher Dein Logging überdenken.

    Oh je, oh je. Ich wollte eigentlich keine Grundsatzdiskussion lostreten.

    Aber da bin ich selbst Schuld, wenn ich so was schreibe wie "Wie die meisten sicher eh schon wissen, lohnt es sich den SSH Port zu ändern".

    Offensichtlich schlecht gewählt Worte.


    Das mit den IO-Spikes fand ich einfach nur interessant. Der Server hätte ja eigentlich gar nicht laufen sollen (siehe verlinkten Thread).


    Ich minimiere gerne die Angriffsfläche, soweit ich sie erkennen kann.

    Dazu verwende ich gerne auch, zusätzlich, security through obscurity.

    Ich verwende einfach alles, von dem ich Denke, dass es mir hilft. Den Link von ___ hab ich mir auch gleich gebookmarkt. Die iptables Verwendung finde ich klasse, und auch sonst fand ich den Artikel sehr lesenswert.


    Bei einigen meiner Linux-Maschinen habe ich den SSH-Port geändert, bei einigen nicht. Das hängt von verschiedenen Faktoren ab.

    Aber bei allen habe ich u.a. die Verwendung von Passwörtern verboten, lasse nur bestimmte User überhaupt zu, verbiete root, ...

    Danke für den interessanten Link!!!

    Ich finde zwar, dass er mit den meisten Punkten recht hat, aber nicht mit allen. Und das, zusätzliche, ändern des SSH Ports hat, manchmal, durchaus seine Daseinsberechtigung. Auf welchen Port ist natürlich eine ganz andere Frage ;)

    Wie meistens halt. Man muss seine eigene Situation analysieren, und sich dann entscheiden. Hat halt alles seine Vor- und Nachteile.

    Wie die meisten sicher eh schon wissen, lohnt es sich den SSH Port zu ändern. Man ist viel weniger Angriffen ausgesetzt.


    Nachdem mein frisch installierter Root Server einige Tage unverändert gelaufen ist, konnte man im SCP schön sehen, wie viel Ressourcen ein frisch installierter Server benötigt, der sonst nichts zu tun hat.

    Mehr Details in diesem Thread: verbesserungsvorschlag-vm-inaktiv-scp-autostart-einstellung-bei-vm-migration-beachten

    Besonders verwundert hatten mich die IOPS-Spikes.


    Jetzt hat mich interessiert, wie stark wirkt sich das Ändern des Standard Ports in der Praxis aus.

    Und für den Fall, dass es jemand anderes auch interessiert, kommen jetzt die Bilder dazu.


    Die letzten 19 Tage ist der Server also mit geändertem Port weiter gelaufen.


    nc-cpu.pngnc-iops.pngnc-pps.pngnc-nw.png


    Wie man an den SCP Statistiken schön sehen kann, sind besonders die Spikes bei den IOPS verschwunden. Was so ein paar Logfiles doch ausmachen können.

    Die anderen Ressourcen wurden auch etwas entlastet. Sehr angenehm :)


    Aus Spaß/Interesse hab ich noch ein paar Minuten lang "stress" laufen lassen, um die CPU G-Skala etwas besser einschätzen zu können:


    nc-cpu-6.pngnc-cpu-31.png



    @killerbees19

    Also ich hab von den E14:

    1x seit 14.12.2013

    6x seit 24.2.2014

    2x seit 3.4.2017

    Eine davon ist vor ein paar Monaten kaputt gegangen, weiß aber nicht von wann die war.

    Und 2x E27 seit 29.11.2015


    Vielleicht hatte ich da einfach mehr Glück.


    Ich hatte auf Amazon Marketplace mal einen 10er Pack E14 Noname gekauft. Die sind gestorben wie die Fliegen.

    Das hat mich genauso geärgert wie Dich.

    Der Händler war auch kulant. Aber ich musste jedes mal Bilder machen, die gezeigt haben, dass die LED nicht mehr ging.

    Irgendwann hatte ich dann keine Lust mehr, und hab es sein lassen.

    Zur Zeit kaufe ich gerne Philips. Aber keine 2700K

    die Wahrscheinlichkeit, daß Du einen kaufen kannst ist in Relation zu dem, was sein kann wenn man den Bedarf hat, sowas wie der Unterschied zwischen Eisbär und Pinguin ist; :D

    oder anders: den wollte ich schon seit ein paar Monate kaufen, und ist immer ausverkauft ...

    Dann wäre jetzt ein guter Zeitpunkt es wieder zu probieren, da mindestens 2000 zur Verfügung stehen (zumindest laut News)

    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.

    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.

    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 :D

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

    Quote

    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.