Beiträge von m_ueberall

Zitat von opus

Zum Hintergrund: ich betreibe auf dem Server aktuell eine MediaWiki-Instanz und möchte das gesamte System inklusive OS und ähnlichen aktualisieren.

Hier würde ich anregen, sofern möglich einmalig den Server kurz herunterzufahren, einen Snapshot zu exportieren/via FTP verfügbar zu machen und diese Kopie als Basis für Updates zu verwenden. Damit hat man zunächst auch eine Vorlage (Format, usw.) für spätere Images, welche man ggf. von Grund auf selbst erstellt. Management-Schnittstellen für das SCP sind hierbei nicht zwangsläufig zu installieren (optional allenfalls das im SCP erwähnte "qemu-guest-agent"-Paket, welches eine Schnittstelle zum Hostrechner darstellt, um Reboots o.ä. zu unterstützen).

Sofern das Wiki online verändert wird, ist natürlich sicherzustellen, dass hier eine Synchronisation im Rahmen der Vorbereitung eines neuen Upload-Images gewährleistet ist – analog sind auch anderweitige Konfigurationsänderungen immer zwischen beiden "Kopien" (Live-Instanz und heimisches Installations-Abbild) abzugleichen. Als willkommener Seiteneffekt lassen sich diese Änderungen dann aber auch immer erst am heimischen Rechner durchtesten (dort hat man ja keinerlei Probleme mit der Erstellung von Snapshots und dem Durchstarten der VM).

Zitat von whoami0501

Alternative? Prozesscheck? Oder ein Check auf die Binary?

Eine Prozessüberprüfung wäre IMHO am sinnvollsten – wenn kein Prozess läuft, welcher Port 443 bedient, entfällt die Notwendigkeit einer Konfigurationsauffrischung mittels "reload". Und wenn ein Prozess läuft, dann lässt sich genau darüber ermitteln, welcher Webserver/Dienst ihn bedient. Etwa wie folgt:

SERVICENAMES=$(netstat -tulpen | grep ':443 ' | sed -e 's|.*/||g' | sort | uniq)

$SERVICENAMES kann mehrere Einträge enthalten, und wenn das Script auf einer Host-Maschine mit entsprechenden Containern läuft, dann sollte hier ggf. noch ermittelt werden, welche Dienste wirklich im Kontext des Scripts ausgeführt werden.

Zitat von Caspar

https://thehackernews.com/2020/01/warnin…w-critical.html

NSA

Da kommt die Frage auf wie lange die die Lücke schon genutzt haben bevor es jetzt endlich zum CVE wurde......

Wahrscheinlich solange, bis der böse Feind die auch entdeckt hat…

Wurde andersherum getestet, dass für beide Domänen die richtigen/selben DNS-Server zuständig sind? Ist das Problem reproduzierbar, wenn die Abfrage direkt an die IP-Adresse desjenigen DNS-Servers gerichtet wird, dessen Zonefile oben auszugsweise angegeben wurde (um jegliche Verwechslung auszuschließen, vom selben Host via 127.0.0.1 und danach von einem anderen aus)?

Zitat von 03simon10

Und zwar schlummert in meinem PC noch ne ältere 250GB HDD, die ich lediglich mal an ner VM hängen hatte, ansonsten war die Platte immer offline/aus […] Insgesamt gute 2 Jahre Laufzeit […]

Ist die Platte zwei Jahre alt oder wurde sie im Laufe ihres Lebens gut 700 Tage (regelmäßig) verwendet? Festplatten längere Zeit nicht zu verwenden ist nicht gut (irgendwo hatte ich auch einmal einen Verweis auf eine interne IBM-Richtlinie gesehen, nach welcher längere Zeit nicht verwendete Festplatten nicht mehr verwendet werden durften):

Zitat von IBM Knowledge Center

Store removable disk drives in their protective containers, on a flat surface with the top side up. The storage area must be clean and dry, must have normal room temperature, and must be away from any magnetic fields. For best storage life, use the removable disk drives every six months.

Angesichts der Kosten für eine neue SSD würde ich ohne lange nachzudenken eine Neuanschaffung ins Auge fassen.

Zitat von timkoop

Ich bin mit Mindfactory sehr zufrieden. Ist aber ein bisschen mit Pokern verbunden, denn die Preise ändern sich gerne mal schnell

Das kann ich unterschreiben. Ein Tip, unabhängig vom jeweiligen Lieferanten: Es empfiehlt sich, beim Einkauf für jeden Artikel über einen Link aus dem Geizhals-Vergleichsportal einzusteigen (auch wenn letztlich alles in einem Warenkorb landen sollte), um mit vergleichsweise vernachlässigbarem Mehraufwand von "Positionierungskämpfen" zu profitieren…

Munin und Monit; Ressourcenverbrauch, auch wenn mehrere Cluster-Knoten gleichzeitig für die Datenaufbereitung zuständig sind und sich damit auch gegenseitig selbst überwachen, hält sich in Grenzen.

Hier wäre ich aber durchaus sehr an Erfahrungsberichten von "Umsteigern" beider Hilfswerkzeuge auf größere/flexiblere/komplexere freie Lösungen interessiert, welche den obengenannten Einsatz mit mehreren unabhängigen Überwachungs-Instanzen ("Active/Active"-Modus) beibehalten haben.

Zitat von friend_of_root

Ein Stable Release in einem Github Archiv so eines Projektes müsste schon für sich als Qualitätsmerkmal gelten. Wenn jemand es schafft, dass sein Changerequest mit einem Trojaner in das Stable gemerged wird, würde eine Prüfsumme auch nicht helfen.

An welche Art der Manipulation denkt ihr, wenn ihr einen Link dieser Plattform anzweifelt?

Grundsätzlich ist kein Zugang zu einer Plattform unangreifbar (vgl. Canonical's GitHub account was briefly compromised). Denkbar wären DNS Cache Poisoning – denn auch GitHub verwendet kein DNSSEC/TLSA – und/oder das Erschleichen von Zugangsdaten für Repositories.

Ein Abgleich mehrerer Kriterien ist in jedem Fall dann hilfreich, wenn der Angreifer den vollständigen Arbeitsablauf (Veröffentlichung neuer Prüfsummen, Änderung der Webseiten – heutzutage von vielen, gerade kleinen Projekten auch via GitHub gehostet, also "ein und dieselbe Quelle") nicht replizieren kann/will (oder schlichtweg etwas vergisst), aus welchem Grunde auch immer.

(Das Einbringen eines Trojaners über einen Change-Request wird von o.g. "einfacher Konsistenzprüfung" nicht abgedeckt; hier hilft nur, Programme aus einer "Downstream"-Quelle zu übernehmen, in der Hoffnung, dass zusätzliche Reviews etwas mehr Sicherheit bringen. Wurde auch schon unterlaufen…)

Zitat von whoami0501

m_ueberall Aber was stellst du dir unter dezentral vor? Dass ich mir den SHA256 Hash aus einer anderen Quelle, statt von phpmyadmin selbst, hole? Woher denn? Außer phpmyadmin bietet den ja eigentlich keiner nochmal an.

Ja, die Prüfsumme/Releases werden leider nicht auf GitHub hinterlegt oder sonstwie gespiegelt. Eine Möglichkeit wäre -- sofern ein git-checkout dieselben Dateien wie im Download-Archiv enthält -- ein Vergleich dieser beiden Quellen. Das Download-Archiv ist auch kryptographisch signiert, was bei strikter Nutzung/Akzeptanz der in der Dokumentation erwähnten Schlüssel zusätzlich eine (notwendige Minimal-)Testmöglichkeit darstellt (besser als die alleinige Verifikation der SHA256-Prüfsumme).

Zitat von whoami0501

Nur falls Bedarf besteht... mir gingen die Updates auf den Sack und ich habs mittels Cronjob und Script automatisiert.

Die Seite bietet kein DNSSEC/TLSA und die Downloads werden nicht gegen (dezentral verteilte) Prüfsummen getestet, sondern gleich installiert?

LinkTip/TechTip (sicher nicht der Einzige aus dem #36c3-Umfeld): SELECT code_execution FROM * USING SQLite; --Gaining code execution using a malicious SQLite database

Zitat von killerbees19

Ich bezweifle, dass die Packages dort besser gepflegt werden. Ist doch alles im gleichen Repository…

Aus diesem Grunde empfiehlt es sich, genau zu analysieren, welche Dienste "nach außen sichtbar" sind und entsprechende Pakete aus sorgsam ausgewählten Dritt-Repositories einzuspielen (Dovecot, MariaDB, Apache/Nginx, PHP, GlusterFS, ...). Wenn man die Umgebung sauber aufsetzt, bietet es sich ferner an, via perlbrew/plenv, pyenv, TeXlive, ... Teile des Stacks "upstream abzugreifen" – Letzeres ist natürlich ggf. mit erhöhtem Wartungsaufwand verbunden, aber unter Beachtung des Kriteriums "Nutzerbasisgröße" ist dies o.B.d.A. immer noch sinnvoller, als sich im größeren Umfang selbst um inoffizielle "Backports" (Nutzerbasis: meist 1 Person) zu kümmern, es sei denn, man weiß sehr genau, was man tut…

(Dass erforderliche Vorabtests hierzu nicht auf exponierten Servern stattfinden dürfen, versteht sich von selbst, weswegen ich das hier im Kleingedruckten verstecke…)

Zitat von whoami0501

Ich muss irgendwie versuchen, dass sich das System selbst scannen kann. Wie ich das anstelle, weiß ich halt noch nicht so ganz... Ich brauche Ideen, und zwar nicht für "was", sondern für "wie".

Linktip: Tor/Usage/Nmap-scan-through-tor (Praktisch aber IMHO nur nutzbar, wenn man hinterher problemlos wieder aufräumen/deinstallieren kann – via Docker/Podman bzw. lxc/lxd o.ä.; schon wesentlich "schwergewichtiger" als ein einzelnes Script, da vorgenanntes "Aufräumen" ggf. auch die Container-Infrastruktur selbst beinhalten muss. Als DIY-Alternative wäre die Einbindung verschiedener (kommerzieller) Werkzeuge/Dienste denkbar, welche bspw. nmap-Scan-Reports anbieten.)

Zitat von monti

ich suche einen Mailserver für Debian oder Windows Pro um Mail´s vor dem senden anzupassen.

Unter Verwendung von Postfix ist es relativ leicht, einen Content-Filter zu definieren, welcher durch ein externes Script realisiert wird (siehe Mail-Signierungsbeispiel). Damit lassen sich Werkzeuge einbinden, welche den Inhalt/Platzhalter beliebig modifizieren. Analog gibt/gab es auch Exchange-Server-basierte Filter (als "Transport-Agenten" ausgeführt, vgl. Beispielprojekt), die jedoch deutlich "schwergewichtiger" sind (und in Verbindung mit Office365 ggf. in dieser Form nicht bereitstehen), so dass im Zweifelsfall ein Linux-basierter Filter die bessere Wahl ist. Dank Linux-Subsystem/Docker unter einer aktuellen Windows-Installation sollte es möglich sein, die entsprechende Postfix-Instanz und den/die Filter auch auf der genannten Maschine direkt laufen zu lassen…

Zitat von H6G

So, letzte Change für ein gutes Serverangebot im Adventskalender.

Ich drücke alle zehn Daumen, dass diesmal eine SAS-/HDD-Option dabei ist... wird aber wohl nichts helfen...

Zitat von mfnalex

Mein 200er hat sich beruhigt und ist jetzt nur noch bei 0,5% Steal

Wie wäre es mit einer CCP-API-Erweiterung für einen cronjob, der hier mindestens alle 30 Minuten automatisiert Nachrichten über sinkende/schwankende IOPS-Statistiken oder aktuelle steal-Werte im Forum veröffentlicht? Wenn das 5% der Netcup-Nutzer machen, ergibt sich daraus bestimmt auch ein hübscher Lasttest für die Forensoftware… <sarcasm/>

Zitat von LanOpa

[…] verdammt, wie war das nochmal, was hab ich alles installiert damit die ganzen Popups unterdrückt bleiben, wie war das im browser nochmal mit der Suchmaschine etc... […]

Stichwort "Agile Dokumentation" – Was man nicht umgehend dokumentiert, ist schnellstmöglich (Murphys Gesetz) aus den Augen, aus dem Sinn…

Hier empfiehlt sich jeweils eine TiddlyWiki-Instanz für ein bestimmtes Themengebiet. Extrem pflegeleicht (wenn nicht mehrere Personen simultan darauf zugreifen wollen) und leicht gesichert/dupliziert/synchronisiert (beispielsweise mittels Syncthing)!

(Wenn die Anforderungen an die Dokumentation anspruchsvoller werden, lohnt sich unbedingt ein Blick auf ein alternatives Wiki wie Foswiki…)

Zitat von friend_of_root

Grund ist, dass es einfach manche Legacyprojekte gibt für die niemand das Budget der Updates übernehmen will. Trotzdem will man die Projekte und Kunden nicht im Stich lassen.

PHP 5.6 ist schon seit einem Jahr ein Sicherheitsrisiko (siehe beispielsweise hier)!

Es gibt einen (mehrere?) Hosting-Anbieter, welche(r) unter dem Stichwort "PHP Extended Support" gegen Bezahlung einen eigenständigen Support übernimmt/-nehmen. Sofern Kunden also nicht zu einem Update zu bewegen sind (hier würde ich mir schriftlich bestätigen lassen, dass diese von mir über die Sicherheitsrisiken aufgeklärt wurden und jegliche aus existierenden Verträgen resultierende sicherheitsrelevante Verpflichtungen diesbezüglich erlöschen), besteht eigentlich keine Alternative zu einer Delegierung der Wartung der alten PHP-Versionen an Dritte, wenn man diese nicht selbst übernehmen kann/will – alles andere ist identisch damit, den Kunden im Stich zu lassen.

Zitat von broda

Den qemu-guest-agent hast Du drauf?

Apropos qemu-guest-agent – Ist es schon einmal Jemandem passiert, dass im SCP das Fehlen desselben angezeigt wurde (nach Anstossen des Herunterfahrens dort), obwohl das entsprechende Paket (hier: unter Ubuntu 16.04 LTS) installiert wurde?

Zitat von tab

Ich wäre für einen vJohann, der könnte bei starker Abnutzung einfach in der Cloud neu erzeugt werden.

Das einzig Wahre ist doch ein Managed Johann/Johann-as-a-Service… keine provozierenden Nachfragen mehr, ob man sicher wäre, mit dem Johann richtig umgehen zu können, obwohl man schon einmal einen Korkenzieher gesehen hat!