Beiträge von Paul

Zitat von mainziman

äh, gerade da geht es super; nur wenn das Endgerät der MitM-CA nicht vertraut und derartiges auch checkt bekommst

entsprechende Fehler ...

Davon bin ich aber auch ausgegangen. Wenn der Client kompromitiert ist, ist es eh vorbei. So ohne vorherige Manipulation des Clients geht das ja nicht. Zusätzlich muss der MitM dich auch recht gut kennen um entsprechende Angriffe zu fahren. Gmail umzuleiten mag ja vielleicht noch naheliegend sein. Dein privater Mailserver mit der eigenen Domain muss dem Angreifer aber erstmal bekannt sein.

Die ganze Zertifikats/CA Geschichte gibt es ja genau deswegen, damit es einen MitM nicht so leicht geben kann, sonst hätten wir ja auch einfach self-signed Zertifikate nutzen können. Bei der Transportverschlüsselung geht es ja auch um die Authentizität.

Zitat von Green14

Und jetzt los steinigt mich

Also wenn du so darauf bestehst

Aus mathematischer Sicht kann ich dir sagen, dass die Transport-Verschlüsselung, die wir heute so einsetzen, ausreichend sicher ist. Mit sehr viel Rechenaufwand/Zeit kann man das vielleicht entschlüssen, aber so "on-the-fly" als MitM geht das nicht. Egal, ob man seinem ISP oder dem Netzwerk, in dem man sich gerade befindet, vertraut oder nicht. D.h. man kann durchaus davon ausgehen, dass die Daten, die verschlüsselt an einen Server geschickt werden, dort angekommen ohne dass eine dritte Partei währenddessen Zugriff auf die eigentlichen Daten hatte. Das ist ja der eigentlich entscheidende Punkt, warum wir SSL/TLS überhaupt einsetzen.

Nur sobald die Daten den entsprechenden Server/Dienst erreichen, beginnt ja der eigentliche Spaß. Sobald die Daten nämlich auf der Gegenseite entschlüsselt werden, weißt du eben nicht mehr was damit passiert, wenn du den Server/Dienst nicht unter eigener Kontrolle heißt. Du weißt nicht, was der Anbieter mit den Daten alles anstellt. Ob er die unverschlüsselt irgendwo speichert, sie an andere Dienste weiterleitet, verkauft, manipuliert, gegen dich verwendet, andere Personen darauf zugreifen lässt, ...

Zum Thema Google: Man darf nicht vergessen, dass Google in erster Linie ein Werbe-Netzwerk ist. Deren Kern-Geschäft ist das Ausliefern von Werbung. Sämtliche Dienste, die Google betreibt bzw. anbietet, dienen in erster Linie dazu, entweder darüber direkt Werbung auszuliefern oder Daten zu sammeln, damit man sie früher oder später für Werbung verwenden kann oder einfach nur um sie zu verkaufen. Wenn dann ein Dienst nicht mehr lukrativ genug ist, wird er eingestellt. Das ist mein großes Problem mit Google und warum ich die Dienste nicht gerne nutze. Wenn ich einen externen Anbieter auswähle, dann achte ich in der Regel darauf, dass der Dienst auch das Kern-Geschäft der Firma ist. Für E-Mail Dienste gehe ich zu einem E-Mail Provider, für Hosting Produkte/VMs zu einem Hosting Provider (Netcup), usw. Daher kaufe ich auch keine Kleidung bei Aldi. Das ist für mich ein Discount Supermarkt für Lebensmittel und kein Modegeschäft ;-).

Aber unter dem Strich muss das jeder für sich selbst entscheiden. Man kann niemanden verbieten seine Daten irgendwo hochzuladen und sie zur Verfügung zu stellen. Daher ist diese Frage auch immer nur subjektiv zu beantwortet. Nur wenn mich jemand fragt, dann empfehle ich grundsätzlich immer den "Datenschutz-Weg" zu gehen

Zitat von SilSte

Mal vom ÖPNV zu einem Serverthema...

Die Tage über Blocklist.de als Ergänzung zu fail2ban gestolpert. Hat das jemand im Einsatz? Erfahrungen?

Wäre mir persönlich etwas zu heikel. Die Gefahr bei solchen Listen ist immer, dass du auf einmal IPs sperrst, du du gar nicht sperren wolltest. Wir kämpfen hier gerade in der EU gegen die flächendeckende Einführung von Zensur-Werkzeugen, da kann ich in diesem Zusammenhang solche Dienste nicht wirklich mit gutem Gewissen empfehlen.

Zitat von Olgsi

Ich frage mich nur, ob ich als Laie es überhaupt sicher hinbekomme?

Und neben der Arbeit und den kleinen Kindern immer den aktuellsten Stand habe... schwierig.

Der Anfang ist etwas schwierig und zeitraubend. Hat man aber mal verstanden wie etwas funktioniert und entsprechend automatisiert, dann ist die weitere Wartung eher vernachlässigbar. Ich habe bei mir alles mit Ansible Playbooks automatisiert. Sowohl das eigentliche Setup als auch die nötige Wartung der Dienste (z.B. Updates). Würde ich mich rein darauf konzentrieren, würde mich die Pflege der Server/Services nur wenige Minuten pro Monat kosten. Und die findet man eigentlich immer, wenn man denn möchte.

Was ich aber als Tipp geben kann: Wenn man seine Services selbst betreibt, sollte man sich nicht zu schade sein, eine Testumgebung für seine wichtigen Dienste zu betreiben. Das kann ein ganz kleiner VPS sein, aber das erspart einem jede Menge Frust, wenn man größere Updates einspielen muss. Das ist ein Fehler, der leider häufig gemacht wird. Seine "Prod" Umgebung nach einem missglückten "Change" wieder zu reparieren, kostet oft die meiste Arbeit. Wenn man dies vermeidet, sollte Zeit nicht die primäre Rolle spielen bei der Frage nach Komfort vs. Datenschutz.

Mir persönlich ist Datenschutz wichtiger als Komfort. Daher hoste ich so gut wie alles selbst (Mail, Nextcloud, Git, etc.). Ich mache nur ein paar wenige Ausnahmen:
* DNS (Cloudflare). Da bin ich noch unentschlossen. Aktuell ist es für mich ok.
* Docker Images (Dockerhub, Gitlab). Da sind die Daten eh öffentlicher Natur.

* OpenSuse Build Service (Zum Bauen eigener RPM Pakete)

Es ist einfach ein gutes Gefühl, wenn man alles unter eigener Kontrolle hat. Diese Dienste sind für mich jetzt auch nicht überlebensnotwendig. Wichtig ist im Grunde hauptsächlich der Mailserver. Aber gerade deswegen betreibe ich den lieber selbst. So kann ich selbst in den Logs nachschauen, ob eine Email zugestellt wurde, welche Emails aufgrund von Spam/Blacklisten abgelehnt wurde, kann Backups erstellen, beliebige Domains aufschalten etc.

Komfort ist immer etwas trügerisches. Man begibt sich in eine Abhängigkeit, aus der man nur schwer wieder raus kommt. Google ist jetzt auch ein schönes Beispiel von einem Anbieter, der gerne man (auch beliebte Dienste) einfach mal so einstellt. Das passiert dir nicht, wenn du dein eigener Anbieter bist ;-).

Zitat von eripek

Womit ich zu folgender Überlegung komme: einen VPS und eine Plesk-Lizenz nehmen oder VPS und ISPconfig verwenden - oder eben einen ML-Dienstleister benützen. Dadurch, dass die IP hier nicht mit anderen Kunden geteilt wird, Sollten tab 's Bedenken hierbei keine Grundlage haben

Die Bedenken von tab sind aber immernoch durchaus berechtigt. Denn selbst im Falle eines VPS ist dieser Server ja immer noch Teil eines größeren Netzwerkes (Hier bei Netcup üblicherweise /22). Die Vergangenheit hat leider gezeigt, dass bestimmte große Mail-Provider dann gerne mal das komplette Netzwerk auf die Blackliste nehmen. Insofern betrifft das durchaus andere Kunden. Natürlich ist die Gefahr jetzt nicht unbedingt größer als bei anderen Kunden, die ihren Mailserver nicht ordentlich konfigurieren, nur kann man hier in diesem Fall ja direkt einen entsprechenden Tipp geben, damit man es von Anfang an besser machen kann.

Vielleicht wäre es an dieser Stelle interessant, wie groß denn diese Mailing-Liste überhaupt werden soll. Wenn es hier eh nur um eine Handvoll Empfänger geht, braucht man sich da sicherlich keine so großen Gedanken machen.

Zitat von Cictani

Auf Stackoverflow gibts dazu auch einige interessante Ideen

Die Argumente bzgl. der Version Control Systeme gefallen mir. Da macht das wirklich Sinn.

Software wird ja nicht nur entwickelt, die muss auch über den gesamten Zeitraum gepflegt werden. Gerade die Wartung so einer Software wie ein Shopsystem ist ja das eigentliche, was auf Dauer viel Geld kostet. Hinzu kommen dann noch die ganzen Spielereien wie Sicherheitsaudits/-updates. Da man ja bei einem Shopsystem in der Regel auch Finanzdaten von Kunden speichert, ist hier ja besondere Vorsicht geboten.

Mit so einem Zwei-Wochen-Sprint ist es da nicht getan

Wenn man selbst eine Nextcloud betreiben kann, würde ich das auch immer machen. Wenn du die rein privat nutzt, ist die für Angreifer auch relativ uninteressant und da braucht man sich in der Regel auch keine großen Sorgen morgen (regelmäßige Patches vorausgesetzt). Da muss es jemand schon ganz gezielt auf dich abgesehen haben. Dass persönliche Daten verloren gehen, halte bei größeren Anbietern für wahrscheinlicher als in der eigenen privaten Cloud, da die Angriffer meist auf die große Beute aus sind und sich kaum für so kleine private Cloud Instanzen interessieren.

Ich selbst hoste für mich auch alles selbst, was ich selbst hosten kann/möchte. Da hat man einfach immer noch die beste Kontrolle über seinen Daten. Möchte man die Daten nicht mehr in der Cloud haben, löscht man sie einfach.

Hallo,

ich nehme an, du bindest das NFS Verzeichnis erst einmal lokal auf dem Host ein und gibst es dann an den Container als Host Folder durch? Das halte ich für etwas ungünstig, da Docker selbst direkt mit dem NFS Server sprechen kann und einen NFS Treiber dafür bereit stellt. Dadurch lässt sich das NFS Verzeichnis als Docker Volume behandeln, was es etwas einfacher macht.

Hier ist auch ein Beispiel dazu: https://docs.docker.com/engine/referen…/volume_create/

Ansonsten hat CmdrXay da schon recht mit seiner Andeutung. Der Prozess in dem Container läuft mit einer UID, die so genau auch auf dem Host sichtbar ist. Nur gitb es auf dem Host keinen User mit der UID, daher steht da einfach nur eine Zahl. Das passt aber ingesamt dann schon.

Wenn du die Berechtigungen des Ordners auf dem Host auf die entsprechende UID setzt, sollte das aber im Grunde funktionieren.

Zitat von randysoft

Hallo die Haupt IP ist die IP1

Die beiden anderen sind zusätzlich.

D.h. dein Server kommuniziert nach außen mit IP 1. Also müsstest du den PTR Eintrag für die IP 1 auf mail.meinedomain.de setzen. Alternativ kann man natürlich auch die "src" IP auf deinem Server umkonfigurieren, aber wirklich schön fände ich das nicht.

Ich würde in diesem Fall einfach IP 1 für die Maildienste nutzen. Da erspart man sich einiges an Arbeit. Und die beiden zusätzlichen IPs dann fürs Webhosting.

Darf man mal fragen, warum diese zusätzlichen IPs überhaupt nötig sind? Im Grunde könnte man dann doch lieber gleich zusätzliche Server nutzen, wenn man das schon so trennen möchte.

Entscheidend ist die "src" IP, mit der dein Server nach außen kommuniziert. Ich vermute fast, dass es die IP 1 sein wird, sind IP 2 und 3 zusätzliche (geroutete) IPs? Bzw. wie stehen denn die IPs zueinander? Was ist die ursprüngliche (Haupt-) IP deines Servers?

Zitat von m_ueberall

Habe gerade festgestellt, dass ein Backport einer neueren Version von curl (aktuell: 7.64.0) auf Ubuntu 16.04[.5] LTS nicht ohne weiteres möglich ist, da libcurl4 hier automatisch HTTP/2 versucht und Repository-Server, welche letzteres "gemeinerweise" auch verstehen und sprechen, apt aus dem Tritt bringen ("The HTTP server sent an invalid reply header"). Eine einfache und insbesondere saubere Möglichkeit (ohne Modifikation von curl/apt), das Problem zu umgehen, sehe ich nicht. (Das ist genau so lustig wie mit GnuPG, welches man unter Ubuntu 16.04 auch nicht ohne Weiteres "auffrischen" kann.)

Ich meine, mich dunkel zu erinnern, dass man apt irgendwie mit wget zusammenarbeiten lassen konnte, aber einen Online-/man-page-Hinweis habe ich nicht gefunden. Durch den Code mag ich mich jetzt nicht durchlesen...

Na dann wird es ja mal Zeit auf eine "anständige" Distribution zu wechseln

Zitat von schimmelmann

Bin ich da im Irrtum?

Alles ok. Ich nehme meinen Einwand zurück. Überrascht bin ich aber trotzdem. So eine Kombination sehe ich nämlich zum ersten Mal Hast du da zufällig selbst an den udev Regeln geschraubt?

Wie konfigurierst du denn die Firewall? Manuell mit iptables. Oder mit einem Wrapper wie UFW, Shorewall oder Firewalld?

Irgendwas passt da auch bei den Interface Namen noch nicht. Auf der einen Seite nutzt du eth0, dann aber bei dem VLAN Interface ens6. Schau lieber erstmal auf dem System nach wie die wirklich heißen (wie auch whoami0501 angedeutet hat).

Zitat von vmk

Ausnahme: Du hast irgendwelche "lustige" Software, die in diesem Quartal nach Sockets lizenziert wird.

Z.B. Windows

Zitat

Wieso ist das nicht übertragbar? Es geht doch um Virtualisierung allgemein.

So wie ich das verstehe geht es da allein um die vNUMA Technologie, die bei VMWare eingesetzt wird. Ich bin da jetzt auch kein Experte auf diesem Gebiet. Aber ich würde das so nicht auf KVM übertragen wollen, die das intern vermutlich ganz anders regeln. Mir ist auch nicht bekannt, dass es bei KVM überhaupt eine Rolle für die Perfomance spielt. Ich würde da ganz einfach $socket * $cores = $kvm_threads rechnen.

Zitat von Steini

Habt ihr zur Zeit auch ungewöhnlich viele SSH Verbindungsversuche? Ich benutze einen einen nicht-standard Port und Public-Key-Authentification. Wer versucht sich hat mit Passwort einzuloggen wird per fail2ban gesperrt. Normal habe ich da immer so 1-2 IPs auf der Sperrliste. Seit gestern steigt das Sprunghaft an. Was mich wundert: Die "illegal users" im Logfile sehen nach aufsteigendem Wörterbuch aus. Aber jede Anfrage kommt von einer anderen IP (muss ja, die alte wird ja gesperrt).

Kann hier ebenfalls beobachten. Mal von den üblichen "devops", "admin" Versuchen abgesehen, habe hier etliche Versuche mit "nadya", "alexandria", "adriana", ... typische Namen von Systemadministratoren . Aber immer von einer anderen IP, daher ist meine Fail2Ban Liste auch recht leer. Die Anzahl an fehlgeschlagenen Versuchen dagegen deutlich erhöht.

Zitat von vmk

Mit nur Cores anstatt Sockets kann die Leistung gemindert werden, vgl. https://blogs.vmware.com/vsphere/2013/1…erformance.html

Was sich allerdings auf die VMWare Plattform bezieht. Das würde ich so nicht 1:1 auf KVM übertragen, was ja bei Netcup zum Einsatz kommt. Wenn man auf Nummer sicher gehen will, testet man es einfach schnell selbst.

Zitat von fs86

Okay, vielen Dank. Kann ich diese Einstellung denn einfach so ändern oder hätte das evtl. ungewünschte Auswirkungen?

Kannst du einfach so ändern. Dazu muss aber der Server komplett ausgeschaltet werden. Daher geht das nur mit Downtime. Würde ich also dann machen, wenn sowieso mal wieder Updates anstehen und der Server einen Neustart benötigt.

Zitat von vmk

Was ist (zur Zeit) die beste Distribution für Docker? Man liest an jeder Ecke, dass jede Distribution hier ihre eigenen Macken (alter Kernel, falsches Filesystem, etc) hat. Bei z.B. Rancher fehlen direkt die openvm-Tools und docker-compose).

Kommt immer ein wenig auf die eigenen Bedürfnisse an. Ich setze für meine Docker Umgebungen Fedora 29 (Server Edition) ein. Hauptsächlich deswegen, weil ich neben Docker auch noch klassische Pakete installiere (Monitoring und Backup Agents), die ich nicht als Container laufen lassen möchte.

Vorteile sehe ich u.a. darin:
* Aktueller Kernel
* Zusätzliche Absicherung durch SELinux
* Guter Support und Pflege durch RedHat. Große und hilfreiche Community.

Nachteile:
* Einmal im Jahr muss ein Upgrade auf die nächte Major Version gemacht werden
* Alte Docker Version, wenn man es aus den offiziellen Fedora Quellen installiert (Docker 1.13.1)

Für meine k8s Umgebung setze ich auf die mitgelieferte Docker Version, für meine Docker Swarm Umgebungen kommt Docker aus dem offiziellen docker.io upstream repo.

Würde ich nur Container laufen lassen, würde ich vermutlich auf Fedora Atomic OS oder CoreOS setzen.