Beiträge von Andi22

    Hallo Panda,


    Du hast einen Fehler in Deiner Apache Konfiguration.


    In der "systemctl status apache2.service" Ausgabe in Zeile 11 "AH00526: Syntax error on li.." steht in welcher Datei und in welcher Zeile.


    Das mit dem "-l" ist ganz einfach. Das ist ein optionaler Parameter von systemctl. Also z.B.:

    systemctl -l status apache2.service

    Dann solltest Du auch sehen, wie die Datei heißt, und welche Zeile gemeint ist.


    Der Fehler an sich steht in Zeile 12 "Invalid command 'SSLStaplin..."

    Ich kann jetzt nur vermuten dass das

    SSLUseStapling on

    sein sollte, um eben SSL Stapling zu aktivieren.


    Hast Du das da eingetragen, oder hat das Froxlor gemacht ?


    Am einfachsten ist es sicher, wenn Du die Zeile zuerst einfach mal entfernst, und dann den Apache neu startest.

    Dann sollte hoffentlich kein Fehler mehr kommen, oder ein anderer ;)


    Wenn alles läuft kannst Du probieren "SSLUseStapling on" hinzuzufügen.

    Wie wichtig ist Ihnen eigentlich unsere doch recht hohe garantierte Mindestverfügbarkeit von 99,6% bei unseren VPS? Würde jemand von Ihnen VPS mit 98% Mindestverfügbarkeit kaufen, wenn der Preis dafür halbiert wäre?


    Mit freundlichen Grüßen


    Felix Preuß

    Also ich könne mir vorstellen, dass es einige gibt, die dann die 98% Mindestverfügbarkeit nehmen würden, ist schließlich billiger ;)

    Besonders da es kein Unterschied ist, den man auf den ersten Blick war nimmt.

    RAM, CPUs, Festplatte sind sofort ersichtlich, und kann man testen. Mindestverfügbarkeit nicht.


    Aber ich kann mir auch sehr gut vorstellen, dass sich einige trotzdem bitterlich beschweren werden, wenn der VPS dann auch nur für ein paar Stunden nicht erreichbar ist.

    War da nicht erst letzte Woche ein Thread, wo einer sogar Schadenersatz wollte wegen den tausenden von Euros die er verloren hat, weil der VPS/RDS nachts 1-2 Stunden nicht erreichbar war :D


    Wenn es Beide Varianten gibt, ich also entscheiden kann ob ich 98% oder 99,6% haben möchte, dann finde ich prinzipiell gut (auch wenn ich den 98% nicht buche ;)).

    Wenn es nur noch die 98% Variante geben würde, wäre ich dagegen.

    Zitat

    Mitbewerber (nachfolgend Mbe) Dedicated


    Wahrscheinlich ist mit "Dedicated" wirklich ein dedizierter Server gemeint, und keine VM-Hostsystem.

    Die diversen Daten in den Screenshots sprechen auch dafür, dass es ein dedizierter Server ist.


    Hätte ich aber auch nicht gedacht, dass der RS8000, für mysql, langsamer ist, als der Xeon(R) CPU D-1521 Server.

    Zeig mir einmal bitte wer einen Geschäftsführer, der so offen und ausführlich Fragen zur Infrastruktur beantwortet, wie Felix!

    Was, zumindest bei mir, einer der Gründe war, mich für Netcup zu entscheiden.

    Ein anderer war, u.a., das tolle Forum hier :)

    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:

    Zitat

    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)