blog
Inhaltsverzeichnis
Network Bound Disk Encryption
In diesem Artikel gebe ich euch einen Überblick, was Network Bound Disk Encryption (NBDE) ist und beschreibe einen konkreten Anwendungsfall. Am Ende des Artikels führe ich einige Verweise auf, mit deren Hilfe ihr NBDE bei Interesse selbst implementieren könnt.
Linux Unified Key Setup (LUKS)
Bevor ich auf NBDE eingehe, möchte ich kurz ein paar Worte zu LUKS verlieren.
Bei LUKS handelt es sich um das Standardverfahren zur Festplattenverschlüsselung unter Linux 1). Dieses erweitert dm-crypt um einen Header, welcher Slots zum Speichern von bis zu acht Schlüsseln bietet 2).
Ich benutze dieses Verfahren auf nahezu all meinen Rechnern. Ich möchte damit erreichen, dass meine Daten bei Diebstahl des Rechners bzw. der Festplatte möglichst lange vor unberechtigtem Zugriff geschützt sind.
Typischerweise wird zur Entschlüsselung einer Festplatte bzw. Partition während des Boot-Vorgangs die Eingabe eines Kennworts benötigt. Die Sicherheit des Verfahrens hängt dabei direkt von der Stärke des verwendeten Passworts ab.
Steht der Rechner im Büro und man ist täglich vor Ort, ist es kein Problem, bei Neustart des Rechners das LUKS-Kennwort einzugeben. Wenn man allerdings im Homeoffice arbeitet und Zugriff auf seinen Büro-Rechner braucht, sieht die Sache anders aus.
Möchte man den entfernten Rechner neustarten, z.B. nach der Installation von Updates, muss man dafür extra ins Büro fahren. Alternativ kann man ein zweites Kennwort einrichten, dieses einem Kollegen mitteilen und diesen bitten, es vor Ort einzugeben. Beides ist nicht komfortabel. Und hier kommt NBDE ins Spiel.
LUKS an Netzwerkressource binden
Network Bound Disk Encryption heißt auf Deutsch in etwa netzwerkgebundene Festplattenverschlüsselung und bedeutet, dass die Verschlüsselung an eine oder mehrere Ressourcen im Netzwerk gebunden ist.
Das Prinzip ist ganz einfach. Wenn ein Rechner mit einer verschlüsselten Festplatte oder Partition startet, sucht er nach einer bestimmten Ressource im Netzwerk. Kann der Rechner diese Netzwerkressource erreichen, wird die Festplatte bzw. Partition entschlüsselt und der Startvorgang fortgesetzt. Folgende Abbildung soll dies veranschaulichen.
Im eigenen LAN werden zwei sogenannte Tang-Server positioniert. Diese stellen die Netzwerk-Ressource dar, welche erreichbar sein muss, damit ein an Tang gebundenes Gerät entschlüsselt werden kann. In diesem Beispiel werden zwei Tang-Server betrieben, um die Verfügbarkeit des Dienstes zu gewährleisten, wenn ein Server gewartet wird.
Auf dem Client kommt die Anwendung Clevis zum Einsatz, bei welcher es sich um die Client-Komponente zum Tang-Server handelt. Diese empfängt einen Schlüssel vom Tang-Server und verwendet diesen, um einen Token in einem LUKS-Slot zu speichern. Beim Start eines Rechners wird nun versucht, einen der Tang-Server zu erreichen, an die man sich gebunden hat.
Wird der Rechner bzw. seine Festplatte gestohlen, sind die Tang-Server nicht erreichbar und die Daten werden nicht automatisch entschlüsselt. Der Dieb muss nun die Verschlüsselung bzw. das verwendete Kennwort brechen.
Steht der Rechner jedoch an seinem Platz, kann er aus der Ferne neugestartet werden und den Startvorgang beenden, ohne dass jemand vor Ort ein LUKS-Kennwort eingeben muss.
Damit diese Konfiguration Sinn macht, dürfen die Tang-Server nicht weltweit erreichbar sein. Ihr Standort und die Netze, aus denen sie erreichbar sind, sind daher sorgfältig zu planen.
Zusammenfassung
Ohne NBDE muss an einem Rechner mit LUKS-Verschlüsselung bei jedem Startvorgang das LUKS-Kennwort eingegeben werden, was einen Neustart aus der Ferne enorm erschwert.
NBDE ist leicht zu implementieren und löst dieses Problem. Gleichzeitig bleiben die Daten im gleichen Maße bei einem Diebstahl des Rechners geschützt.
Schleswig-Holstein führt den digital souveränen IT-Arbeitsplatz ein
Mit einem Kabinettsbeschluss zur flächendeckenden Einführung der quelloffenen Software LibreOffice als Standard Office-Lösung hat die Regierung von Schleswig-Holstein mit Daniel Günther als Ministerpräsident den Startschuss für den ersten Schritt in Richtung vollständige digitale Souveränität des Landes gegeben.
»Die Verwendung von LibreOffice als Standard Office-Paket in der Kommunikation zwischen Ministerien und Behörden erfolgt kurzfristig und deren Verwendung ist verpflichtend«. Landesregierung SW
Microsoft ade
LibreOffice löst damit Microsoft Office für rund 30.000 Landesbedienstete ab. Aber damit nicht genug. Microsoft muss auch den Platz des Betriebssystems freigeben, denn dort soll künftig Linux laufen.
Bereits im Jahr 2020 hatte Schleswig-Holsteins Digitalminister Jan Philipp Albrecht einen Bericht zur Nutzung von Open-Source-Software verfasst, der die zunehmende Bedeutung von Open Source in der Verwaltung angesichts von aktuellen Entwicklungen verdeutlicht. Die dort postulierten Schritte weg von proprietärer Software in der Verwaltung wurden seitdem konsequent umgesetzt und waren nicht, wie so oft, Lippenbekenntnisse zum Zwecke der Wiederwahl.
Die Bestandteile des digital souveränen IT-Arbeitsplatzes werden in Schleswig-Holstein in insgesamt sechs Projektsäulen aufgebaut:
- Umstieg von Microsoft Office auf LibreOffice
- Umstieg des Betriebssystems von Microsoft Windows auf Linux
- Kollaboration innerhalb der Landesverwaltung und mit Externen: Nutzung der Open Source Produkte Nextcloud, Open Xchange/Thunderbird in Verbindung mit dem Univention AD-Connector zur Ablösung von Microsoft Sharepoint sowie Microsoft Exchange/Outlook
- Konzeption eines Open Source basierten Verzeichnisdienstes zur Ablösung von Microsoft Active Directory
- Bestandsaufnahme der Fachverfahren hinsichtlich Kompatibilität und Interoperabilität mit LibreOffice und Linux
- Entwicklung einer Open Source basierten Telefonie-Lösung zur Ablösung von Telekom-Flexport
Ein Schulungsangebot für die Mitarbeiter ist vorhanden. Zudem wird bei der Einführung von LibreOffice Personalunterstützung seitens des Zentralen IT-Managements des Landes zur Verfügung gestellt.
Ubuntu 24.04 Beta wegen CVE-2024-3094 verschoben
Die Veröffentlichung der Beta-Version von Ubuntu 24.04 LTS »Noble Numbat« war eigentlich für den heutigen 4. April geplant. Das Release wird allerdings um eine Woche nach hinten auf den 11. April verschoben. Der Grund ist, wie man sich denken kann, die am Karfreitag entdeckte Hintertür in dem Paket xz-utils.
Auswirkungen von CVE-2024-3094
Bereits am Wochenende hatte Debian die Verschiebung von Debian 12.6 bekannt gegeben. openSUSE baute aus Gründen der Sicherheit die gesamte Codebasis von Tumbleweed neu. Jetzt hat Canonical beschlossen, alle Binärpakete für Noble Numbat, die nach dem 26. Februar, dem Stichtag für den bösartigen Commit in xz-utils hinzugefügt wurden, zu überprüfen und in einer sauberen Build-Umgebung neu zu bauen.
Canonical geht auf Nummer sicher
Ubuntu war den Auswirkungen der eklatanten Sicherheitslücke nur knapp entgangen. Ubuntu-Entwickler wurden von den Leuten um Jia Tan kontaktiert und zur Aufnahme des mit der Hintertür versehenen Pakets aufgefordert, da es wesentliche Verbesserungen enthalte. Die Aufnahme wurde lediglich durch den zu späten Zeitpunkt im Release-Zyklus verhindert. Trotzdem stellt Canonical an dieser Stelle die Sicherheit an erste Stelle, vor allem, weil weiterhin nicht alle möglichen Auswirkungen dieses Angriffs bekannt sind.
Die Verschiebung der Beta um eine Woche scheint die stabile Veröffentlichung von Ubuntu 22.04 LTS nicht zu beeinflussen, im Zeitplan steht diese immer noch beim bisherigen Datum, dem 25. April.
Wie ein paar Nerds an Ostern den vielleicht schlimmsten Hack der Geschichte verhinderten
Es ist eine wahre Geschichte, die aus einem Tech-Thriller stammen könnte. Durch Zufall stiess ein Linux-Entwickler auf raffinierte Hacker, die Millionen Server im Visier hatten – und reagierte goldrichtig.
Ein Artikel für Nicht-Nerds
Einem bei Microsoft angestellten Software-Entwickler ist es zu verdanken, dass verheerende Cyberangriffe quasi im letzten Moment verhindert werden konnten.
Der Schweizer IT-Experte Marcel Waldvogel bringt das Geschehen, das sich an Ostern ereignete und über die Fachwelt hinaus kaum für Aufsehen sorgte, auf den Punkt:
«Wir sind dieses Wochenende nur durch unglaublichen Zufall extrem knapp an einer schon lange vorbereiteten, wohl grössten Katastrophe rund um die globale IT-Sicherheit vorbeigeschrammt.»
Tatsächlich ist es unbekannten Elitehackern um ein Haar gelungen, eine sogenannte «Backdoor» (Hintertür) in ein äusserst populäres Linux-Programm einzubauen. Dies hätte Millionen Server weltweit angreifbar gemacht.
Zu den potenziellen Folgen kommentiert Waldvogel:
«Das Resultat hätte für unsere persönlichen Daten, unsere Wirtschaft und deren Abläufe, sowie für die davon abhängigen Prozesse inklusive kritische Infrastrukturen desaströs enden können.»
Das Wichtigste in Kürze
- Profihacker versuchten mit beträchtlichem Aufwand und grosser Hinterlist eine Hintertür in eine weitverbreitete Open-Source-Software einzubauen.
- Es handelte sich um die Vorbereitungen für sogenannte «Supply-Chain»-Attacken, bei der die Angreifer über eine Drittsoftware zum eigentlichen Ziel – einem geschützten Server, respektive Datenträger – vordringen.
- Die ausgeklügelte Methode hätte Millionen Linux-Server weltweit angreifbar gemacht – aber nur für die Urheber der massgeschneiderten Malware. Sie hätten so fast jeden Befehl auf dem Zielrechner ausführen können.
- Im Visier hatten sie die Standardmethode für die Fernwartung von Unix-, respektive Linux-Systemen: SSH (Secure Shell). Dies sei mutmasslich die meistverbreitete Variante, um sich auf anderen Rechnern anzumelden, hält Waldvogel in seiner lesenswerten Analyse fest.
- Die Hintertür, die über eine Werkzeugsammlung zur effizienten Datenkompression namens «xz» implementiert werden sollte, war raffiniert konzipiert. Sie konnte nur unter gewissen Bedingungen ausgenutzt werden, wenn die Angreifer den richtigen, geheimen Schlüssel dafür kannten. Abgesehen davon war sie nahezu perfekt getarnt.
- Der bösartige Programmcode wurde von einem Entwickler mit dem Pseudonym «Jia Tan» eingeschleust. Dieser hatte sich während drei Jahren das Vertrauen der Open-Source-Community erschlichen, indem er nützliche Beiträge zu Linux-Projekten leistete. Seine Herkunft sowie die seiner Helfer und Auftraggeber ist nicht bekannt.
- Die Hacker verfolgten eine langfristige Strategie und bereiteten eine Art Plug-in-System vor, um für zukünftige Attacken weitere Elemente einschleusen zu können.
- Schlimmeres konnte nur verhindert werden, weil ein misstrauischer Linux-Entwickler beim Testen eines Programmes auf eine ungewöhnliche Verzögerung gestossen war und beschloss, der Ursache auf den Grund zu gehen.
- Entdecker des Angriffs ist der Microsoft-Angestellte und erfahrene Linux-Entwickler Andres Freund. Nachdem er am Karfreitag über eine Mailing-Liste eine Warnung veröffentlicht hatte, machten sich auch andere Open-Source-Entwickler aus allen Teilen der Welt über Ostern an die Eindämmung und Aufklärung des Falles.
- Der Angriff wurde erfolgreich vereitelt. Es sind keine Meldungen über Schäden und Opfer bekannt.
Was lernen wir daraus?
Dazu IT-Experte Waldvogel:
«Innert weniger Tage wurde dank aufmerksamen Open-Source-Leuten mehrere Jahre akribische Vorbereitung einer gross angelegten Cyberattacke zunichte gemacht.»
Solche Supply-Chain-Attacken seien aber äusserst schwierig zu entdecken. Und man müsse davon ausgehen, dass Elitehacker im Staatsauftrag an weiteren Methoden arbeiten.
Angreifern aus China, Russland oder auch bei den US-Geheimdiensten, die über grosse Mittel verfügen, steht ein Heer von häufig ehrenamtlichen Entwicklern gegenüber. Bei einigen wichtigen Softwarebibliotheken hängt die Qualitätssicherung von nur wenigen «Betreuern» ab, so Waldvogel.
«Hier könnten durchaus auch nationale IT-Sicherheitszentren – in der Schweiz das Bundesamt für Cybersicherheit, BACS – diese Aufgabe übernehmen. Denn es fördert ihre eigene Cybersicherheit und die ihrer Wirtschaft und Bürger.»
Kommentatoren rufen in Erinnerung, dass auch grosse Techkonzerne mit ihrer proprietären Software von der unbezahlten Arbeit der Linux-Community profitieren.
Der «Guardian» erklärt, dass solch raffinierte Attacken auch ein Unternehmen wie Apple oder Google treffen könnten. Dann wäre es für Dritte aber äusserst schwierig, die entsprechende Schwachstelle überhaupt zu entdecken.
Eine weitere Möglichkeit, das Risiko zu verkleinern, sieht Waldvogel in der Rückbesinnung auf einfachen Code:
«Wir sollten uns bei Software wieder auf die wichtigen Komponenten besinnen und nicht einfach alles an zusätzlichen Softwarekomponenten importieren, nur weil es praktisch ist. Oder zumindest versuchen, diese Abhängigkeiten so weit wie möglich zu isolieren.»
Linux-Out-of-Memory-Killer
Aus aktuellem Anlass.
Was ist das ?
Der „OOM Killer“ oder „Out of Memory Killer“ ist ein Prozess, den der Linux-Kernel einsetzt, wenn das System kritisch wenig Arbeitsspeicher hat. Diese Situation tritt auf, weil Prozesse auf dem Server viel Speicher verbrauchen und das System mehr Speicher für seine eigenen Prozesse und zur Zuweisung an andere Prozesse benötigt. Wenn ein Prozess startet, fordert er einen Speicherblock vom Kernel an. Bei dieser ersten Anfrage handelt es sich in der Regel um eine große Anfrage, die der Prozess nicht sofort oder überhaupt nicht vollständig nutzen wird. Der Kernel ist sich der Tendenz von Prozessen bewusst, redundanten Speicher anzufordern, und weist dem Systemspeicher zu viel zu. Das heißt, wenn das System beispielsweise über 8 GB RAM verfügt, kann der Kernel Prozessen 8,5 GB zuweisen. Dadurch wird die Nutzung des Systemspeichers maximiert, indem sichergestellt wird, dass der den Prozessen zugewiesene Speicher aktiv genutzt wird.
Normalerweise stellt diese Situation kein Problem dar. Wenn jedoch genügend Prozesse beginnen, alle angeforderten Speicherblöcke zu nutzen, ist nicht genügend physischer Speicher vorhanden, um sie alle zu unterstützen. Das bedeutet, dass die laufenden Prozesse mehr Speicher benötigen, als physisch verfügbar ist. Diese Situation ist kritisch und muss sofort gelöst werden.
Die Lösung, die der Linux-Kernel verwendet, besteht darin, den OOM Killer aufzurufen, um alle laufenden Prozesse zu überprüfen und einen oder mehrere davon zu beenden, um Systemspeicher freizugeben und das System am Laufen zu halten.
Prozessauswahl
Immer wenn ein Speichermangel auftritt, wird die Funktion out_of_memory() aufgerufen. Darin wird die Funktion select_bad_process() verwendet, die einen Score von der Funktion badness() erhält. Der „schlechteste“ Prozess ist derjenige, der geopfert wird. Es gibt einige Regeln, denen die Funktion badness() für die Auswahl des Prozesses folgt.
- Der Kernel muss eine Mindestmenge an Speicher für sich selbst beschaffen
- Versuchen Sie, eine große Menge Speicher zurückzugewinnen
- Beenden Sie einen Prozess nicht mit wenig Speicher
- Versuchen Sie, die Mindestanzahl an Prozessen abzubrechen
- Einige sorgfältige Algorithmen, die die Opferpriorität für Prozesse erhöhen, die der Benutzer beenden möchte
Nach all diesen Checklisten prüft der OOM-Killer den Score (oom_score). OOM legt den „oom_score“ für jeden Prozess fest und multipliziert diesen Wert dann mit der Speichernutzung. Bei Prozessen mit größeren Werten besteht eine hohe Wahrscheinlichkeit, dass sie vom OOM-Killer beendet werden. Die Prozesse, die dem privilegierten Benutzer zugeordnet sind, haben einen niedrigeren Bewertungswert und eine geringere Wahrscheinlichkeit, von OOM beendet zu werden.
postgres=# SELECT pg_backend_pid(); pg_backend_pid — — — — — — — — 3813 (1 Zeile)
Die Postgres-Prozess-ID ist 3813, daher können Sie in einer anderen Shell den Score-Wert mithilfe dieses oom_score-Kernelparameters abrufen:
$ sudo cat /proc/3813/oom_score 2
Wenn Sie wirklich möchten, dass Ihr Prozess nicht durch OOM-Killer getötet wird, gibt es einen weiteren Kernel-Parameter oom_score_adj. Sie können einen großen negativen Wert hinzufügen, um die Wahrscheinlichkeit zu verringern, dass Ihr Prozess abstürzt.
sudo echo -100 > /proc/3813/oom_score_adj
oder oomprotect des rcctl-Befehls kann verwendet werden, um dies festzulegen.
rcctl set <i>Dienstname</i> oomprotect -1000
Einen Prozess beenden
Wenn ein oder mehrere Prozesse ausgewählt sind, ruft OOM-Killer die Funktion oom_kill_task() auf. Diese Funktion ist dafür verantwortlich, das Beendigungs-/Kill-Signal an den Prozess zu senden. Im Falle von nicht genügend Speicher oom_kill() rufen Sie diese Funktion auf, damit sie das SIGKILL- Signal an den Prozess senden kann. Es wird eine Kernel-Protokollmeldung generiert.
Nicht genügend Speicher: Prozess [pid] [name] abgebrochen.
So steuern Sie OOM-Killer
Linux bietet eine Möglichkeit, den OOM-Killer zu aktivieren und zu deaktivieren, es wird jedoch nicht empfohlen, den OOM-Killer zu deaktivieren. Der Kernel-Parameter vm.oom-kill wird zum Aktivieren und Deaktivieren des OOM-Killers verwendet. Wenn Sie die OOM-Killer-Laufzeit aktivieren möchten, verwenden Sie den Befehl sysctl, um dies zu aktivieren.
sudo -s sysctl -w vm.oom-kill = 1
Um den OOM-Killer zu deaktivieren, verwenden Sie denselben Befehl mit dem Wert 0:
sudo -s sysctl -w vm.oom-kill = 0
Dieser Befehl stellt dies nicht dauerhaft ein und wird durch einen Neustart des Computers zurückgesetzt. Um es dauerhaft festzulegen, fügen Sie diese Zeile in die Datei /etc/sysctl.conf ein:
echo vm.oom-kill = 1 >>/etc/sysctl.conf
Die andere Möglichkeit zum Aktivieren oder Deaktivieren besteht darin, die Variable panic_on_oom zu schreiben. Sie können den Wert jederzeit in /proc überprüfen.
# cat /proc/sys/vm/panic_on_oom 0
Wenn Sie den Wert auf 0 setzen, bedeutet dies, dass der Kernel nicht in Panik gerät, wenn ein Fehler wegen unzureichendem Arbeitsspeicher auftritt.
$ echo 0 > /proc/sys/vm/panic_on_oom
Wenn Sie diesen Wert auf 1 setzen, bedeutet dies, dass der Kernel bei einem Fehler wegen nicht genügend Arbeitsspeicher in Panik gerät.
echo 1 > /proc/sys/vm/panic_on_oom
Es gibt neben der Aktivierung und Deaktivierung noch einige weitere Einstellungen für den OOM-Killer. Da wir bereits erwähnt haben, dass Linux den Speicher durch die Zuweisung von Prozessen zu stark beanspruchen kann, kann dieses Verhalten durch die Linux-Kernel-Einstellung gesteuert werden. Der vm.overcommit_memory wird variabel verwendet, um dieses Verhalten zu steuern.
Der Variablenspeicher vm_overcommit_memory kann mit den folgenden Einstellungen gesteuert werden:
0: Setzen Sie die Variable auf 0, wobei der Kernel entscheidet, ob ein Overcommit durchgeführt wird oder nicht. Dies ist der Standardwert für die meisten Linux-Versionen.
1: Wenn Sie die Variable auf 1 setzen, bedeutet dies, dass der Kernel immer überlastet ist. Dies ist eine riskante Einstellung, da der Kernel den Speicher immer für Prozesse überbelegt. Dies kann dazu führen, dass dem Kernel nicht mehr genügend Speicher zur Verfügung steht, da die Wahrscheinlichkeit groß ist, dass Prozesse am Ende den vom Kernel zugewiesenen Speicher nutzen.
2: Wenn Sie die Variable auf 2 setzen, bedeutet dies, dass der Kernel keinen Speicher über das overcommit_ratio hinaus überbelegen soll. Dieses overcommit_ratio ist eine weitere Kernel-Einstellung, mit der Sie den Prozentsatz des Speichers angeben, den der Kernel überbelegen kann. Wenn kein Platz für eine Überbelegung vorhanden ist, schlägt die Speicherzuweisungsfunktion fehl und die Überbelegung wird verweigert. Dies ist die sicherste Option und der empfohlene Wert für PostgreSQL.
Die zweite Sache, die den OOM-Killer beeinflussen kann, ist das Verhalten von swappiness. Dieses Verhalten kann durch die Variable cat /proc/sys/vm/swappiness gesteuert werden. Diese Werte geben die Kernel-Einstellung für die Handhabung des Seitenaustauschs an. Je größer der Wert, desto geringer ist die Wahrscheinlichkeit, dass OOM den Prozess abbricht, aber es wirkt sich aufgrund der E/A auf die Datenbankeffizienz aus. Ein kleinerer Wert für die Variable, die die Swapiness steuert, bedeutet, dass die Wahrscheinlichkeit, dass OOM-Killer eingreift, höher ist, aber es verbessert auch die Datenbankleistung. Der Standardwert ist 60, aber wenn Ihre gesamte Datenbank in den Speicher passt, wird empfohlen, diesen Wert auf 1 zu setzen.
Warum wird Apache/MySQL/Postgres immer getötet?
Die oben aufgeführten Kriterien bedeuten, dass der OOM Killer bei der Auswahl eines Prozesses zum Beenden einen Prozess auswählt, der viel Speicher beansprucht und über viele untergeordnete Prozesse verfügt, die keine Systemprozesse sind. Eine Anwendung wie Apache, MySQL, Nginx, Clamd (ClamAV) oder ein Mailserver sind ein guter Kandidat. Da diese Situation jedoch normalerweise auf ausgelasteten Webservern auftritt, sind Apache oder MySQL die größten systeminternen Prozesse im Arbeitsspeicher und werden folglich abgebrochen.
Denken Sie daran, dass der Webserver oder der DB-Server zwar für Sie sehr wichtig sind, die Situation jedoch kritisch ist, wenn der Kernel den OOM-Killer aufruft. Wenn durch das Beenden eines Prozesses kein Speicher freigegeben wird, stürzt der Server kurz darauf ab. Eine Fortsetzung des Normalbetriebs ist zu diesem Zeitpunkt nicht mehr möglich.
Häufige Ursache
Eine der häufigsten Ursachen dafür, dass Apache/Nginx/MySQL durch den OOM Process Killer getötet wird, besteht darin, dass die Website eine große Menge an Datenverkehr empfängt. Hierbei kann es sich um echten Datenverkehr von einer neuen Werbeaktion, einer Medienaufmerksamkeit oder ähnlichem handeln ein Bot, der die Website crawlt, oder in manchen Fällen kann es sich um Botnetze handeln, die versuchen, Ihre Website mit Brute-Force anzugreifen. Die Überprüfung der Apache-/Nginx-Protokolle ist ein guter Ausgangspunkt, um festzustellen, ob dies der Fall ist.
Zusammenfassung
Der Name Killer (OOM-Killer) muss Sie nicht verwirren. Der Mörder ist nicht immer schädlich; Es ist ein Retter für Ihr System. Es tötet den schlimmsten Prozess ab und bewahrt Ihr System vor einem Absturz. Um zu vermeiden, dass OOM-Killer zum Beenden von PostgreSQL verwendet werden muss, wird empfohlen, den vm .overcommit_memory-Wert auf 2 zu setzen. Dadurch wird der OOM-Killer nicht zu 100 % vermieden, aber die Wahrscheinlichkeit verringert, dass der PostgreSQL-Prozess beendet wird.
<< Neuere Einträge | Ältere Einträge >>
This page has been accessed for: Today: 1 / Yesterday: 1 Until now: 456
blog.txt · Zuletzt geändert: von marko