Möglicherweise liegt es schlichtweg daran, das der Bezugszeitraum ein anderer ist.
Bei der 24h Ansicht ist das Intervall, in dem gezählt und gemittelt wurde, vermutlich kleiner wie bei der 7 Tage und 31 Tage Ansicht, wodurch sich die Durchschnittswerte leicht unterscheiden.
Ich meine den VPS 16 Year:
https://www.netcup.de/bestellen/produkt.php?produkt=2194
8 vCores, 16GB RAM, 1,6TB SAS, 80TB Traffic/Monat für 16€/Monat bei 1 Monat Laufzeit.
Ich konnte nicht widerstehen und hab ihn mal bestellt, richte ihn aktuell als Plexserver ein, die Leitung zu Hause glüht schon 
Uh gibt gute Sonderangebote mal wieder, 1,6TB SAS VPS für 16€/Monat... 
Ja, ist ja auch ein Argument für Portänderungen. Für den Fall daß mal eine unbekannte Sicherheitslücke alle SSHDs der Welt angreifbar macht, ist es doch besser, der SSHD läuft nicht auf dem Standardport sondern woanders, wo du dann vielleicht nicht so schnell gefunden wirst. Kann so passieren. Ändert nichts daran, daß das alles als Security by Obscurity anzusehen ist.
"Security by Obscurity" meint ein System, bei dem die Sicherheit darauf beruht das der Angreifer nicht deine Konfiguration/Algorithmen weiß. Das geht oft bzw. immer schief, ganz krasses Beispiel war der Crypto-1 Algorithmus der Mifare Classic Karten. Aber im Grunde ist auch das ändern des SSH-Portes, wie von dir erwähnt, Security by Obscurity, da der Angreifer bei Kenntnis der Config keinen Nachteil hat und einfach den Port ändert. Zudem dürfte es recht leicht sein den SSH-Port zu finden, selbst das scannen des IPv6 Adressraumes ist machbar.
Dagegen ist ein Aussperren nach zu vielen Fehlversuchen nicht "Security by Obscurity", da der Angreifer selbst bei Kenntnis der Config nichts dagegen unternehmen kann, nach 3/5/10 Fehlversuchen ausgesperrt zu werden und sich immer eine neue IP holen muss, was den Einsatz von Ressourcen auf Seiten des Angreifers erhöht. Aus genau dem gleichen Grund hat man auch stetig die Länge der Schlüssel erhöht, um den Ressourcen Einsatz auf Seiten des Angreifers zu erhöhen. Ob fail2ban ein geeignetes Mittel ist (weil wenig Angriffe erwartet werden) oder "überfordert" ist (wie bei http-logs) weil nicht das richtige Werkzeug für den Fall ist erst mal egal, aber es ist halt nicht "Security by Obscurity", was negativ besetzt ist (zu Recht). Quasi jeder mir bekannte Dienst nutzt einen solchen Brute-Force Schutz, ob mit fail2ban umgesetzt oder nicht. Und ein grundlegender Brute Force Schutz ist meiner Meinung nach ein muss, und damit bin ich wohl nicht alleine unterwegs, und am einfachsten geht das mit fail2ban für SSH.
Bei IPv4 gibt es 4294967296 IPs, 1 davon gehört dir, der Rest dem Gegner.
Korrekt, sofern man nicht über GeoIP etliche aussperrt. Kostet aber Firewallresourcen und ist ebenfalls eine zusätzliche Maßnahme und blieb bisher auch unerwähnt. Aber wenn man solch mächtige Angreifer fürchten muss sollte man sich dagegen wappnen (oder der Angreifer kann das Netzwerk im RZ übernehmen).
fail2ban kann soll darf man ruhig machen. Aber man braucht sich nicht einbilden, daß es eine starke Sicherheitsmaßnahme ist. Wer das umgehen möchte der kann das einfach tun. Wer 100'000 geleakte Keys hat und weiß, einer davon gehört dir, dann wird der sich ein Botnetz mieten und von 100'000 IPs je eine Anfrage zu dir schicken, kein Ding. Wenn es jemand wirklich auf dich abgesehen hat und was in der Hand hat gegen dich, dann bringt das mit fail2ban gar nichts.
Klar mag fail2ban nicht die Barriere für den größt möglichen Angreifer sein (wobei vielleicht doch, indem die Rechenlast den Server down gehen lässt und somit sicher vor dem Angriff ist 
), aber schon nur das andere nicht 100.000 Passwörter und Keys ausprobieren können dürfte ein Plus an Performance sein, für das einmalige scannen der Log Files und anlegen der Firewall-Regel (i.d.R. lassen die Angreifer ab sobald der Port gesperrt ist).
Wobei ich ehrlich sagen muss, ich weiß nicht wie die Logfiles ohne fail2ban bei SSH aussehen würde, aber bei mir sind meist ständig 50-100 IPs gesperrt von fail2ban (48h bantime). Und damit sind diese schon mal raus und können keine Zero-Day-Exploits oder ähnliches ausnutzen. Abschließend müsste man eigentlich analysieren was mehr Performance kostet: fail2ban die logs analysieren lassen und das mehr an Firewall-Regeln oder einfach das Zulassen von BruteForce und der zusätzliche Aufwand für größere Logs und fehlgeschlagene Login-Versuche
Ein Beispiel aus der Praxis: Eines meiner Projekte hat in 7 Tagen zirka 5 Millionen Hits. Hier habe ich versucht übermütige User mit Fail2ban auszufiltern. Kann man voll vergessen. Es kommen schneller Log Einträge dazu als sie analysiert werden können.
Du sprichst hier aber nicht über SSH, oder? Über SSH hatte ich das Problem noch nie schon nur weil fehlgeschlagene Login-Versuche sowieso einen kurzen Timeout haben, aber du hast Recht, für Gewisse Dienste ist fail2ban unbrauchbar: Vor allem HTTP-Logs bei größeren Projekten oder ähnliches sind nicht bewältigbar mit fail2ban, da muss man einen anderen Schutz gegen Brute-Force/DoS-Attacken implementieren.
Das kommt darauf an, wie Du Portknocking definierst. Mit einer modernen kryptografischen Lösung wie sie z.B. fwknop(d) bietet, würde ich das nicht verteufeln!
fwknop sieht ja richtig interessant aus, wobei die Autoren es selbst ja schon als "Single Packet Authorization > Port Knocking" bezeichnen, was im Grunde alles sagst. Und im Gegensatz zum "simplen" Port Knocking ist fwknop definitiv nicht Obscurity: wenn ich meinem Angreifer alle Details offenbare außer meinem geheimen Key, bringt ihm das immer noch rein gar nichts.
Das steht auf jeden Fall mal auf meiner Liste zum näher anschauen, vielleicht als "Login-Schutz" wenn ich nicht im internen VPN bin
Das System muss sicher sein, egal ob dein SSH auf Port 22 oder 222 läuft, egal ob du fail2ban benutzt oder nicht. Ist das so, dann hast du Security. Der ganze Rest ist Obscurity.
Und da sind wir beim Punkt: 100% Sicherheit gibt es nie, was gerade die jüngste Vergangenheit gezeigt hat, sei es Spectre, Meltdown, Heartbleed oder sonst was. Und dann ist es doch besser, wenn man potentielle Angreifer frühzeitig aussperrt, anstatt sie "unendlich lange" probieren zu lassen. Auf jedem System läuft ja Drittsoftware bei der du dir nie 100% sicher sein kannst, dass es keine Sicherheitslücken gibt. Und das Verwenden von fail2ban hat schlichtweg nichts mit Obscurity zu tun sonder ist "reale" Security, keine Ahnung warum du fail2ban mit diesem Begriff schlechtreden willst.
Was gefährlich an deinem Post ist: Du vermittelst den Eindruck, fail2ban zu benutzen wäre was für "Anfänger" und echte Profis bräuchten das nicht weil deren Systeme zu 100% sicher sind, was totaler Schwachsinn ist; zudem sagst du fail2ban bringt "keine zusätzliche Sicherheit". Und selbst wenn der Key sicher erzeugt ist, kann er immer mal abhanden kommen, in irgendwelchen Datenbanken landen oder sonst wo enden weil der "Login-PC" infiziert ist/war. Und dann will man nicht das ein Angreifer alle Zeit der Welt hat alle jemals geleakten Keys zu testen. Oder Rainbow-Tables an Passwörtern. Laut deiner Argumentation wären ja auch IPS (Intrusion Prevention System) und IDS (Intrusion-Detection-Systeme) völlig unnötig, da ja jeder alles 100% sicher machen kann.
Ich sehe absolut keinen Grund, Bruteforce "zu dulden" einfach nur weil man sagt "pff mein System ist sicher macht nur" und Methoden, um dies effektiv zu verhindern, abwertend als "Obscurity" darzustellen. Schon nur weil Bruteforce Attacken eine Systemlast erzeugen, die Logs zumüllen und das Netzwerk belasten (wenn auch nur minimalst). Außerdem, wer weiß, vielleicht Schütz fail2ban dich vor einer Sicherheitslücke die noch nicht entdeckt wurde in deinem perfekt sicheren Setup weil sie noch keiner kennt außer ein paar böse Buben 
Und nirgendwo wurde geschrieben, das fail2ban schwache Passwörter "stark" macht. Natürlich ist eine zusätzliche Maßnahme wie fail2ban kein Grund, andere Sicherheitsmaßnahmen zu ignorieren. Zum Thema IP: IPv6 ist generell verboten für SSH, da fail2ban in Debian das noch nicht supported (wenn dann würde ich den ganzen 64er-Block sperren), und bei IPv4 hat man als Angreifer auch nicht mal auf die schnelle ein paar Millionen Adressen zum durchprobieren, außer der Angreifer ist ein großer Brocken der es ernst meint.
Gerne kannst du mich aber auch vom Gegenteil überzeugen indem du mir beweist, dass es niemals eine Sicherheitslücke geben wird oder kann in der fail2ban dir ein Plus an Sicherheit gibt 
Andere sorgen mit fail2ban o.ä. Geschichten für diese Übersicht. Dabei ist fail2ban im Prinzip auch nur reine Obscurity. Wenn du eine Sicherheitslücke hast, dann kommen die beim ersten Versuch rein bzw. holen sich einfach eine neue IP, das ist ja kein Problem. Aber das ist halt "kulturell akzeptierte" Obscurity wogegen die Leute Hautausschlag bekommen wenn du nur anfängst, was von geändertem SSH-Port zu faseln.
Warum ist fail2ban bitte Obscurity!? "Security through Obscurity" heißt zu deutsch "Sicherheit durch Unklarheit" und das ist hier definitiv nicht der Fall, im Gegenteil: ein Ban nach einer gewissen Zahl an fehlerhaften Logins ist absoluter Standard eigentlich.
Das ist eine echte Sicherheitsmaßnahme, die effektiv Brute-Force Attacken verhindert. Und sich eine neue IP zu besorgen ist auch nicht all zu einfach Aber z.B. fail2ban ist ein echter Sicherheitsgewinn, genau wie eine Funktion beim Login nach 3-maligen falschen Passwort eine "Zwangspause" einlegen zu müssen, wie es z.B. bei vielen Online-Banking Portalen der Fall ist. Und das hat nichts mit "kulturell akzeptierte" zu tun.
Wenn man eine IP nach 5 fehlerhaften Logins für 48h sperrt (bzw bei versuchtem root-login direkt) spart einem das etliche Einträge im Logfile und sperrt fast alle "bösen Buben" effektiv aus 
Obscurity wäre eher, wenn man so etwas wir Portknocking nutzt um den SSH-Port freizugeben.
Es ging um Cachet, nicht um Staytus von dem der Screenshot stammt.
Cachet wird "installiert", indem man den Code runterläd und danach ein compsoer install ausführt (composer soll hier auf den Webspaces klappen):
https://docs.cachethq.io/docs/installing-cachet
Beim Überfliegen hab ich da nichts gesehen, was ein "normales" Webhosting nicht kann.
Composer läuft, benutzt ich selbst Über ein paar Tweaks kann man es native in der Shell nutzen.
Von daher sollte es kein Problem sein cachet zu installieren. Und beim Webhosting hast du ebenfalls eine Shell über die du arbeiten kannst, wenn auch der Funktionsumfang etwas eingeschränkt ist. Im Forum hier gibt es meine ich sogar eine Anleitung wie man composter im Webhosting "einrichtet". Also leg einfach los, ich sehe nichts was dagegen spricht
Paar Threads aus meiner Liste:
https://forum.netcup.de/anwend…wcp-bash-alias-dauerhaft/
Allerdings ist es auch hier wieder nur für Server (z.B. UBUNTU) ausgerichtet, also nichts, was man sozusagen via FTP auf eine Webseite hochladen und dann dort administrieren könnte, obwohl sich das theoretisch anböte. Warum muss das alles immer mit Servern laufen, haha?!
Das verstehe ich gerade nicht... Cachet ist eine "einfache" php-Anwendung und die solltest du ohne Probleme im Webhosting installieren können. Oder was meinst du mit "Server", dein Webhosting läuft auch nur auf einem Server Und Cachet dürfte alles können was auch staytus kann.
staytus braucht wohl ruby und nodejs, beides bietet das Webhosting an, die Einrichtung ist vermutlich aber komplizierter wenn man es überhaupt zum laufen bekommt.
Cachet würde doch passen, soweit ich das sehe "bloggst" du nur Ausfälle oder Wartungsfenster, und genau dafür ist Cachet doch da, also würde ich das einfach mal testen
Der Netcup Support ist nicht über Wochenende erreichbar
Das stimmt so nicht, man bekommt durchaus Antworten auf Anfragen per E-Mail/über das CCP, es kann nur etwas länger dauern.
Ist es eigentlich als Privatperson ratsam, einen AV-Vertrag zu schließen, kosten tut er bis auf das Porto ja nichts, und sicher ist sicher...
Jetzt gibt es erste Infos zu zumindest 2 der 8 Sicherheitslücken:
https://www.heise.de/security/…es-rollen-an-4051900.html
Aber das Marketing lernt, jetzt gibt es sogar schon schön bunt animierte Videos
Zusätzlich: https://www.nic.at/de/meine-at…domain-suche/whois-policy
Zitat: Will eine Privatperson trotzdem öffentlich aufscheinen, ist dies auf ausdrücklichen Wunsch möglich
möglich heißt aber nicht, dass du das Recht darauf hast Das WHOIS sieht wohl keinen "DSGVO-visible-Parameter" vor, daher wird bei nic.at wohl der ORGANISATION-Typ dazu "missbraucht". Aber du bist ja keine Organisation, sondern eine Privatperson was von nic.at wohl nicht ganz clever gelöst ist. Von daher liegt das Problem hier eher an nic.at, die etwas den Standard verbiegen.
Ad Aussage Tech-C müsse eine Person beinhalten - falsch, auch hier habe ich den Link oben bereits gepostet. Gerne nochmals:
Die Empfehlung der NIC.at lautet auch beim Tech-C keine natürliche Person anzugeben: https://www.nic.at/de/meine-at…domain-suche/whois-policy
Zitat: Diese Regelung gilt nicht nur für den Domain-Inhaber, sondern auch für die technische Kontaktperson (Tech-C) ... Aus datenschutzrechtlichen Gründen empfiehlt nic.at bei juristischen Personen auf die Angabe von natürlichen Personen als Ansprechperson und personalisierten E-Mail-Adressen zu verzichten.
Auch hier ist es eine Empfehlung, und kein Zwang. Allgemein wird beim tech-c fast immer eine "Kontaktperson" angegeben was in gewisser Weiße auch sinnvoll ist. Bei größeren Unternehmen mit vielen Mitarbeitern ist es schon gut direkt zu wissen an wen man sich wenden muss, und eine personalisierte E-Mail wird nicht verwendet. Von daher kann ich das auch nicht nachvollziehen. Der Hinweis ist wohl eher im Zuge der DSGVO entstanden, da Datensparsamkeit jetzt Vorschrift ist.
Der derzeit aufscheinende Tech-C Handle ist ganz offensichtlich also keine PERSON sondern eine ORGANISATION, und die Empfehlung lautet hier keinen Personennamen einer natürlichen Person einzutragen.
Das widerspricht sich doch jetzt etwas... oder was willst du uns damit sagen, demnach dürfte wenn du als ORGANISATION anerkennt wirst auch nicht dein Name da stehen Davon ab empfiehlt die nac.at dir quasi nicht öffentlich im WHOIS zu stehen, dieser Empfehlung willst du ja auch nicht folgen.
Die Schuld für die Problematik auf nic.at zu schieben erscheint mir nicht ganz passend. Immerhin reagiert nic.at nur auf die DSGVO und hat ja auch kommuniziert welche Möglichkeiten und Änderungen sich dadurch ergeben.
Ist es aber im Grund schon, der Typ "ORGANISATION" ist man einfach nicht als Privatperson, ist nun mal so. Und dass das WHOIS für dich so "missverständlich" aussieht, liegt auch an nic.at. Wobei ich das auch nicht nachvollziehen kann, was da missverständlich sein soll. Im Impressum stehst du, ins WHOIS schaut quasi niemand außer die die sich auskennen. Und in Zukunft werden bei nic.at wohl 99% der Privatpersonen nicht mehr sichtbar sein. Nur weil einer vielleicht nicht richtig lesen kann, ist es doch nicht gleich für alle missverständlich.
Ich nehme zur Kenntnis, dass trotz dieser 3 gemachten Vorschläge seitens Netcup scheinbar bislang keine Flexibilität besteht hier eine Lösung anzudenken. Dass damit auch technische Probleme (siehe mein geschildertes Problem beim Umzug zu einem Mitbewerber) auftreten wird auf den Mitbewerber geschoben.
Und das liegt wohl eindeutig an besagtem Mitbewerber, wenn dieser sich nicht Standard-Konform verhält trifft netcup keine Schuld, vielleicht überdenkt dieser ja in Zukunft seine Praxis da es bei sehr vielen nic.at-Domains in solchen Fällen in Zukunft Probleme geben wird. Im Zuge der GDPR werden sicherlich auch noch andere Top-Level-Domains davon betroffen sein.
Mich würde mal interessieren ob es auch eine "500er" Version der Generation 8 geben wird
Du kannst z.B. ein git-Repo recht bequem klonen, wenn du dein Projekt also auf einem git-Server hast ist das eine Option.
Wohl ein Opfer der DSGVO 
Ist es möglich den Server erst mit einer Laufzeit von einem Monat zu bestellen und dann bei Gefallen auf die halbjährliche Abrechnung umstellen?
Bestell ihn einfach für 6 Monate und nutze bei nichtgefallen die Zufriedenheitsgarantie
