Beiträge von Paul

Zitat von Real-DD-2

Für hier angesprochen 12 % (sorry) völlig inkompetenter Nutzer den Rest massiv zu gefährden ist Fahrlässigkeit.

Sorry, aber das ist einfach nicht richtig. Wie in einem obigen Post erwähnt, betrifft es die meisten User doch überhaupt nicht. Sobald der Client eine sichere Cipher Suite unterstützt, wird diese auch genutzt. Es wird dank der "Server Cipher Order" IMMER die bestmögliche Cipher gewählt, wenn der Server diese als erstes konfiguriert hat - was ja auch bei Netcup der Fall ist. Die ganzen "schlechten" Ciphers sind alles nur Fallback-Lösungen, wenn keine andere Wahl besteht.

Es besteht hier also überhaupt keine Gefahr für User, die aktuelle Software einsetzen. In diesem Fall ist die Verbindung immer sicher. Die alten Ciphers gelten ja nur für alte Clients, die sich noch verbinden wollen. Dass ist ja dann auch ausschließend deren Problem.

Zitat von de_bonner

Es gibt aber Leute, die haben keine Zeit / Lust einen Server zu konfigurieren oder haben auch einfach nicht das umfängliche Wissen [...]

Natürlich können das nicht viele. Aber wer sich wirklich Sorgen um konfigurierte SSL Ciphers macht, der hat doch sicherlich etwas mehr Ahnung von der Materie und wäre dazu durchaus in der Lage. Für mich passt das einfach nicht so richtig zusammen. Webhosting ist an sich ja schon ein Kompromiss. Man teilt sich mit vielen anderen einen Server. Aber auf der anderen Seite kritisiert man dann den Anbieter, dass er versucht auf Kompatibilität zu achten. Darüber hinaus gibt es ja auch immer noch Managed Server. Dort kann man sicherlich seine Wünsche umsetzen lassen, wenn man wirklich keine Zeit oder Wissen hat wie man es selbst konfiguriert.

Ich verstehe das ja im Grunde schon. Ich mache mir selbst auch sehr viele Gedanken um die Sicherheit meiner Dienste. Aber ich nutze deswegen auch kein Webhosting, sondern einen eigenen Server, weil ich diesen so konfigurieren kann wie ich es gerne hätte.

Wobei man das an dieser Stelle vielleicht auch nochmal etwas relativieren muss. Es gibt ja immernoch eine Art "Server Cipher Order" und sobald der Client eine sichere Cipher Suite unterstützt (also 99% aller Clients), dann wird diese auch genutzt. Die zusätzlichen Ciphers kommen ja wirklich nur dann zum Einsatz, wenn gar keine andere Möglichkeit besteht. Die Sicherheit von der Verbindung wird daher für den größten Teil der Clients also überhaupt nicht eingeschränkt. Das reine Anbieten dieser Ciphers ist also nicht unbedingt ein Problem. Problematisch wird es an dieser Stelle nur, wenn es einem MitM gibt, der es schafft, einen Fallback auf eine weniger sichere Verbindung zu erzwingen, wie z.B. bei

Ich denke also, wenn einem die SSL Sicherheit so wichtig ist, ist ein Shared Webhosting vielleicht auch nicht unbedingt das richtige Produkt. Mit einem eigenen Server hat man ja problemlos die Möglichkeit die SSL Konfiguration so zu machen wie man sie gerne hätte.

Zitat von netzroot

Er hat ja explizit nach einem System gefragt, das auf 'nem Webhosting läuft . Außer osTicket fällt mir da spontan auch nichts ein. Die anderen Systeme fallen raus, sofern Du neue Tickets auch bei eingehenden Mails haben möchtest (oder gibt es bei netcup im Webhosting Packet 'ne Funktion für email piping?).

Hast ja recht, aber es ist sicherlich nicht verkehrt, wenn man trotzdem nochmal eine Alternative nennt Die Anforderung muss ja schließlich nicht in Stein gemeißelt sein.

Interessant ist sicherlich auch Zammad (https://zammad.org/). Noch ein recht junges Projekt, aber sehr vielversprechend. Das stammt vom gleichen Entwicklerteam, das damals OTRS entworfen hat. Es wirkt aber deutlich moderner (Oberfläche, Chat-System etc.).

Aber wohl kaum auf einem Webhosting lauffähig...Wobei ich der Meinung bin, dass man für sowas ruhig einen eigenen Server mieten sollten, wenn man schon so etwas wie ein eigenständiges Ticket System benötigt.

Zitat von killerbees19

Hast Du ein Beispiel, welche Provider das sein sollen? Das verstößt nämlich eindeutig gegen geltende RFC und sorgt sicher für Probleme, an denen der Mailserver mit erzwungenem TLS schuld ist.

Spontan hätte ich jetzt gesagt, dass sich das RFC nur auf den Mailserver Teil bezieht (smtpd), nicht aber auf den Client Modus (smtp), welchen man ja nochmal unabhängig davon konfigurieren kann. Auch die Postfix Doku geht nur im Server Teil auf den RFC ein (http://www.postfix.org/TLS_README.html). Zumindest die Symptome machen den Eindruck, dass es daran liegen könnte. Ich selbst betreibe Mailserver seit einiger Zeit nur noch mit erzwungenem TLS. Falls da draußen wirklich noch Mailserver ohne TLS Unterstützung existieren, will ich mit diesen gar nicht kommunizieren und von diesen auch keine Mails empfangen. Wirkliche Probleme hatte ich damit auch noch keine. Aber das ist ein anderes Thema.

Zurück zum eigentlichen Problem. Spliddorama: Siehst du nach der Umstellung (TLS Aktivierung) immer noch nichts in den Logs? Da müsste es doch zumindest Connection Versuche geben.

Zitat von Spliddorama

Warning - Does not support TLS

Das ist eigentlich ziemlich eindeutig! Dein Mailserver unterstützt kein SSL/TLS. Das solltest du ganz dringend nachkonfigurieren bzw. dich in das Thema einlesen. So hast du Glück, dass überhaupt Mails ankamen. Denn viele Mailserver verschicken Mails mittlerweile nur noch, wenn der Empfänger SSL/TLS unterstützt.

Interessante Entwicklung! Gibt es denn bei dem neuen NetApp Storage ebenso ein Traffic Limit wie bei dem GlusterFS Storage? Andernfalls könnte man ihn ja auch als zusätzlichen Speicherplatz nutzen und Daten von den Servern auslagern, was ganz neue Möglichkeiten bieten würde. Oder soll dieser weiterhin eher als Storage für Backups dienen?

Zitat von Timon_78

Failover-IP umschwenken im Fehlerfall

Vielen Dank für den Link. Da ich meist unangemeldet im Forum unterwegs bin, habe ich ihn im internen Bereich bisher noch nicht gesehen. Das Verhalten beschreibt meine Beobachtung sehr gut.

Der letzte Ausfall war übrigens gestern abend. Ich kann nicht 100% ausschließen, ob es da nicht über das Web-Interface funktioniert hätte. Ich kann nur mit Sicherheit sagen, dass ein Schwenk der IP über das SOAP Skript nicht funktioniert hat. Mein Monitoring hat mich dann informiert, dass sowohl die Services als auch Ping auf die Failover IP nicht mehr funktioniert haben. Als der Server wieder online war, auch aber wie in der Vergangenheit das Routing nicht mehr Ok und musste manuell über das SCP korrigiert werden.

Vielleicht schreibe ich dem Support wirklich nochmal eine kurze Mail mit der Info, dass es wohl immer noch Probleme gibt.

Zitat von killerbees19

Dass die Änderung des Routings etwas dauert ist meiner Meinung nach normal.

Danke für die Bestätigung. Ich war immer etwa irritiert, weil es so lange gedauert hat und dies bei kleinen Wacklern zu Problemen geführt hat, weil die IP schon wieder auf dem anderen Server war, das Skript aber immer noch lief und so erneut getriggert wurde (auf dem anderen Server).

Hallo Forum,

ich nutze jetzt seit einiger Zeit eine Failover-IPv4 Adresse für einen Cluster um im Falle eines Ausfalls den Dienst weiterhin verfügbar zu haben. Im Konkreten nutze ich es für meinen Mail-Cluster. Dies habe ich mit Hilfe von Keepalived + einem Skript zum Routing der IP Adresse gelöst (dank Tipps hier aus dem Forum).

Jetzt habe ich nur in den letzten Monaten festgestellt, dass diese Szenario so leider nicht funktioniert. Wenn die IPv4 Adresse auf einen Server geroutet ist und der darunter liegende Host ausfällt, lässt sich die IPv4 Adresse nicht mehr von dem Server lösen. Weder über das SOAP Protokoll noch über das Web-Interface (Es erscheint nur eine Fehlermeldung ohne Details). Nachdem der Host dann wieder da ist und der Server wieder läuft, scheint zudem das Routing der Failover IP kaputt zu sein. Hier hilft es nur, wenn man das Routing der IP manuell im Web Interface löscht und neu anlegt.

Das ist in den letzten Monaten leider ein paar Mal passiert. Die Ausfälle waren nicht weiter tragisch, es macht nur meine Idee des HA-Clusters ziemlich nutzlos.

Mich würde daher an dieser Stelle mal interessieren, wie ihr die Failover IP nutzt. Habt ihr vielleicht andere HA Lösungen? Weil im Grunde könnte ich sie mir auch sparen, wenn im Failover Fall die IP nicht mehr geroutet werden kann.

Darüberhinaus dauert ein Ändern des Routings immer so 30 Sekunden. Mal etwas mehr, mal weniger. Ist das normal?

Gruss
Paul

Wenn die Frage allein auf das Wiederherstellen der Zertifikate zielt, dann ist die Antwort recht simpel: Gar nichts. Du kannst jederzeit neue Let's Encrypt Zertifikate beantragen. Bei einer Laufzeit von 3 Monaten lohnt es sich gar nicht, da groß Backups zu fahren. Auch die private keys kannst du jederzeit neu erstellen. Ist im Falle einer Neuinstallation eh meist einfacher.

Übrigens kannst du letsencrypt auch einfach aus den normalen Paketquellen installieren:

apt install letsencrypt

.
Du hast dadurch zwar nicht die neuste Version, aber sparst dir einige Abhängigkeiten.

Um 18:05 den neuen VPS Hot Summer 2016 bestellt. Um 18.10 kommt die Mail mit der Bereitstellung rein

Vielen Dank für die Info und die schnelle Reaktion auf solche Sicherheitslücken.

Gehe ich richtig davon aus, dass wenn im VCP die Uptime der Server anfängt neu hochzuzählen alles so geklappt hat wie es ausgeführt werden soll?

P.S. Manchmal können MySQL Master-Master Setups ganz schön nervig sein bei solchen Geschichten. Da zerschießt es einem Replikation schneller als einem lieb ist .

Aus meiner Sicht nicht so ganz. Der Happy 2016 ist ja doch eher wie ein normaler M Server.

Mir schwebt da eher so etwas vor wie:
* 2 virtuelle CPU
* 4 GB RAM
* 60-80 GB Festplatte (keine SSD um noch etwas im Preis runter zu gehen)
* Keine Snapshots
* ...

Also schon in etwa genauso wie der Xmas 2015. Nur eben regulär zu einem etwas höherem Preis. (Wofür ich es verwenden würde: Datenbanken in einen eigenen Cluster auslagern (Galera))

Für einen Monitoring Server sollte man auch nicht zu geizig sein, was die Hardware angeht. Hier fand ich den Xmas 2015 Server vom 1. Dezember geradezu perfekt und konnte zum Glück auch einen bestellen. Denn genau als Monitoring Server nutze ich ihn jetzt. Vor allem wenn man etwas wie Nagios, Zabbix etc. einsetzt, braucht man hier schon im Hintergrund eine einigermaßen performante Datenbank und entsprechend RAM (nutze im Durchschnitt von den 4 GB 55%).
Ich persönlich würde mich ja über einen regulären Server freuen, der diese Hardware-Spezifikationen hat. Natürlich nicht zu dem Preis, sondern für etwas mehr (5 - 6 € wären hier im Vergleich zu dem S bzw. M Server sicherlich angemessen, dafür mit 60-80 GB Festplattenspeicher). Aber netcup kann natürlich unmöglich sämtliche Wünsche berücksichtigen. Aber Fragen darf man ja sicherlich mal :D.

Das Microsoft Problem hat aber jetzt nicht direkt etwas mit dem rDNS Problem zu tun, welches bei web.de/gmx.de etc. aufgetreten ist. Microsoft scheint hier schon alleine aufgrund der IP Adresse Mails als Spam zu klassifizieren. Zumindest ist das mein Verdacht. Dass die zusätzlich auch nach rDNS filtern, kann natürlich auch gut sein. Nur hilft ein einfaches Ändern des rDNS Eintrages hier nicht weiter. Microsoft verrät ja auch nicht, warum etwas als Spam klassifiziert wurde, das macht die Analyse natürlich umso schwerer.

Als Gentoo User bleibt einem da z.B. gar nicht anderes übrig. Gerade im Server-Bereich gibt es da wohl recht viele ;-).

FreshRSS ist auch recht nett. Nutze ich schon recht lange. Hat nicht ganz so viele Funktionen wie z.B. TT-RSS, dafür optisch etwas schöner.

-> FreshRSS, a free, self-hostable aggregator…

Hallo in die Runde,

interessante Diskussion. Vielleicht könnte man ja als Kompromiss einen weiteren vServer anbieten, der etwas mehr Fokus auf Speicherplatz hat. Momentan sind die vServer recht gut ausbalanciert. Wenn man jetzt wirklich dem Vorschlag von Herrn Preuß folgen würde und einen zusätzlichen vServer mieten würde, der im Grunde nur als Storage für andere Server dient, hätte man im Moment relativ viel "Leistung" verschenkt. Sinnvoll wird das ganze ja erst ab dem vServer M mit 240 GB Sata Festplatte. Aber selbst da hat man mit 6 RAM schon mehr als man eigentlich für einen Storage Server bräuchte. Wie die genauen Spezifikationen aussehen könnten, ist natürlich schwer zu sagen. Das muss ja schließlich auch noch für netcup rentabel sein. Aber eine Nachfrage sehe ich hierfür schon, gerade wenn man diese Diskussion verfolgt.

In der ersten Zeile deiner .htaccess müsstest du so etwas wie

# Version: 8.1.0

stehen haben. Kontrolliere das mal mit der installierten Version. Das scheint von owncloud überprüft zu werden und gibt die entsprechende Fehlermeldung, falls es nicht passt.

Poste am besten mal deine .htaccess und sage uns welche ownCloud Version du installiert hast.