{"id":55510,"date":"2020-01-22T00:00:00","date_gmt":"2020-01-21T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/linux-udalenie-pula-blokirovok-dev-random"},"modified":"2020-02-18T14:03:38","modified_gmt":"2020-02-18T11:03:38","slug":"linux-udalenie-pula-blokirovok-dev-random","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/linux-udalenie-pula-blokirovok-dev-random","title":{"rendered":"Linux: Entfernen des Sperr-Pools \/dev\/random","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wie bekannt ist, hat \/dev\/random, ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG), ein unangenehmes Problem \u2013 Blockierungen. In diesem Artikel wird erl\u00e4utert, wie man dieses Problem l\u00f6sen kann. <\/p>\n

In den letzten Monaten wurden die Mittel zur Generierung von Zufallszahlen im Kernel etwas \u00fcberarbeitet, aber Probleme in diesem Untersystem wurden \u00fcber einen l\u00e4ngeren Zeitraum angegangen. Die aktuellen \u00c4nderungen<\/a><\/noindex>waren die letzten. Diese<\/a><\/noindex> wurden vorgenommen, um zu verhindern, dass der Systemaufruf getrandom() beim Systemstart lange blockiert wird, aber die zugrunde liegende Ursache war das Verhalten des blockierenden Zufalls-Pools. Ein k\u00fcrzlicher Patch w\u00fcrde diesen Pool entfernen, und man konnte erwarten, dass er in den Hauptkernel einflie\u00dft. <\/p>\n

Andy Lutomirski ver\u00f6ffentlichte Ende Dezember die dritte Version des Patches. Er f\u00fchrt ein. \u201ezwei wesentliche semantische \u00c4nderungen in den Zufalls-APIs von Linux\u201c<\/i>. Der Patch f\u00fcgt dem Systemaufruf getrandom() ein neues Flag GRND_INSECURE hinzu (obwohl Lutomirski sich darauf als getentropy() bezieht, das in glibc mit getrandom() und festen Flags implementiert ist); dieses Flag sorgt daf\u00fcr, dass der Aufruf immer die angeforderte Datenmenge zur\u00fcckgibt, jedoch ohne Garantie, dass diese Daten zuf\u00e4llig sind. Der Kernel wird einfach sein Bestes tun, um die besten Zufallsdaten zu liefern, die ihm zu diesem Zeitpunkt zur Verf\u00fcgung stehen. \u201eWahrscheinlich ist es am besten, es \u201eINSECURE\u201c<\/i> zu nennen, um die Verwendung dieser API f\u00fcr Dinge, die Sicherheit ben\u00f6tigen, zu verhindern.\u201c<\/a><\/noindex><\/p>\n

Die Patches entfernen auch den blockierenden Pool. Derzeit unterst\u00fctzt der Kernel zwei Zufallsdaten-Pools, von denen einer \/dev\/random und der andere \/dev\/urandom entspricht, wie in diesem Artikel<\/a><\/noindex> Bericht von 2015 beschrieben. Der blockierende Pool ist der Pool f\u00fcr \/dev\/random; das Lesen von diesem Ger\u00e4t wird blockiert (es wird auf seinen Namen verwiesen), bis im System genug \u201ezuf\u00e4llige\u201c Entropie gesammelt wurde, um die Anfrage zu erf\u00fcllen. Weitere Lesevorg\u00e4nge aus dieser Datei werden ebenfalls blockiert, wenn im Pool nicht genug Entropie vorhanden ist. <\/p>\n

Die Entfernung des Blocking-Pools bedeutet, dass das Lesen aus \/dev\/random sich wie getrandom() mit dem Flag-Wert null verh\u00e4lt (und das GRND_RANDOM-Flag in ein Noop verwandelt). Nach der Initialisierung des Kryptographischen Zufallszahlengenerators (CRNG) f\u00fchrt das Lesen aus \/dev\/random und die Aufrufe von getrandom(…,0) nicht zu einer Blockierung und gibt die angeforderte Menge an Zufallsdaten zur\u00fcck.<\/p>\n

Lutomirski sagt: \u201eIch glaube, dass der Blockierungspool von Linux \u00fcberholt ist. CRNG Linux erzeugt Ausgaben, die gut genug sind, um sie sogar zur Generierung von Schl\u00fcsseln zu verwenden. Der Blockierungspool ist in keiner materiellen Hinsicht st\u00e4rker, und f\u00fcr seine Aufrechterhaltung ist viel Infrastruktur von fraglichem Wert erforderlich.\u201c <\/i><\/p>\n

Die \u00c4nderungen wurden vorgenommen, um sicherzustellen, dass bestehende Programme tats\u00e4chlich nicht betroffen sind, und tats\u00e4chlich wird es weniger Probleme mit langen Wartezeiten bei so etwas wie der Generierung von GnuPG-Schl\u00fcsseln geben.<\/p>\n

\u201eDiese Serien sollten keine bestehenden Programme st\u00f6ren. \/dev\/urandom bleibt unver\u00e4ndert. \/dev\/random wird weiterhin sofort nach dem Booten blockiert, blockiert aber weniger als vorher. getentropy() mit den bestehenden Flags gibt ein Ergebnis zur\u00fcck, das f\u00fcr praktische Zwecke genauso geeignet sein wird wie zuvor.\u201c<\/i> <\/p>\n

Lutomirski stellte fest, dass die Frage offen bleibt, ob der Kernel sogenannte \u201ewahre Zufallszahlen\u201c bereitstellen sollte, was das blockierende Kernel in gewissem Ma\u00dfe tun sollte. Er sieht daf\u00fcr nur einen Grund: \u201eEinhaltung staatlicher Standards\u201c. Lutomirski schlug vor, dass, wenn der Kernel dies bereitstellen soll, es \u00fcber ein v\u00f6llig anderes Interface geschehen sollte oder es in den Benutzerspeicher \u00fcbertragen werden sollte, um ihm die M\u00f6glichkeit zu geben, rohe Ereignismuster abzurufen, die zur Erstellung eines solchen Blockierungspools verwendet werden k\u00f6nnen. <\/p>\n

Stephan M\u00fcller schlug vor, dass sein Satz Patches<\/a><\/noindex> Der Linux-Zufallszahlengenerator (LRNG) (derzeit in Version 26 ver\u00f6ffentlicht) k\u00f6nnte eine M\u00f6glichkeit sein, echte Zufallszahlen f\u00fcr Anwendungen bereitzustellen, die diese ben\u00f6tigen. LRNG entspricht vollst\u00e4ndig den Anforderungen der \"Empfehlungen zu Entropiequellen f\u00fcr die Generierung von Zufallsbits\" SP800-90B, was es zu einer L\u00f6sung f\u00fcr die Probleme staatlicher Standards macht.
\nMatthew Garrett sprach sich gegen den Begriff \"echte Zufallsdaten\" aus und bemerkte, dass die gew\u00e4hlten Ger\u00e4te grunds\u00e4tzlich so genau modelliert werden k\u00f6nnten, dass sie vorhersagbar w\u00e4ren: \"Wir erfassen hier keine quantenmechanischen Ereignisse.\"<\/p>\n

M\u00fcller antwortete, dass dieser Begriff aus dem deutschen Standard AIS 31 stammt, der einen Zufallszahlengenerator beschreibt, der nur Ergebnisse \"in der gleichen Geschwindigkeit wie die Entropie des Basisrauschs ausgibt\". <\/p>\n

Abgesehen von terminologischen Unterschieden wird die Einf\u00fchrung eines Blocking-Pools, wie sie durch die Patches von LRNG vorgeschlagen wird, einfach zu verschiedenen Problemen f\u00fchren \u2013 zumindest, wenn er ohne Berechtigungen verf\u00fcgbar ist. <\/p>\n

Wie Lutomirski sagte: \u201eDas l\u00f6st das Problem nicht. Wenn zwei verschiedene Benutzer dumme Programme wie gnupg ausf\u00fchren, werden sie sich einfach gegenseitig ersch\u00f6pfen. Ich sehe aktuell zwei Hauptprobleme mit \/dev\/random: Es ist anf\u00e4llig f\u00fcr DoS (d.h. Ressourcenausbeutung, sch\u00e4dliche Beeinflussung oder etwas \u00c4hnliches), und da keine Berechtigungen f\u00fcr seine Nutzung erforderlich sind, ist es auch anf\u00e4llig f\u00fcr Missbrauch. Gnupg ist falsch, es ist ein v\u00f6lliger Zusammenbruch. Wenn wir eine neue nicht privilegierte Schnittstelle hinzuf\u00fcgen, die von gnupg und \u00e4hnlichen Programmen verwendet wird, werden wir wieder verlieren.\u201c<\/i> <\/p>\n

M\u00fcller stellte fest, dass die Hinzuf\u00fcgung von getrandom() GnuPG nun die Nutzung dieser Schnittstelle erm\u00f6glichen wird, da sie die notwendige Garantie bietet, dass der Pool initialisiert wurde. Basierend auf Diskussionen mit dem GnuPG-Entwickler Werner Koch glaubt M\u00fcller, dass diese Garantie der einzige Grund ist, warum GnuPG derzeit direkt aus \/dev\/random liest. Wenn jedoch eine nicht privilegierte Schnittstelle vorhanden ist, die anf\u00e4llig f\u00fcr Denial-of-Service ist (wie heute \/dev\/random), wird laut Lutomirski sie von einigen Anwendungen missbr\u00e4uchlich verwendet werden. <\/p>\n

Theodore Yue Tak Ts’o, der Entwickler des Linux-Zufallsystem, hat anscheinend seine Meinung zur Notwendigkeit des Blocking-Pools ge\u00e4ndert. Er sagte, dass die Entfernung dieses Pools effektiv die Vorstellung beseitigen w\u00fcrde, dass Linux einen echten Zufallszahlengenerator (TRNG) hat: \u201eDas ist nicht absurd, denn genau so haben es die *BSD immer gemacht\u201c.<\/i><\/p>\n

Er ist auch besorgt, dass die Bereitstellung eines TRNG-Mechanismus lediglich als K\u00f6der f\u00fcr Anwendungsentwickler dienen wird und h\u00e4lt es f\u00fcr unm\u00f6glich, TRNG im Kern zu garantieren, wenn man die verschiedenen Arten von Hardware ber\u00fccksichtigt, die von Linux unterst\u00fctzt werden. Selbst die M\u00f6glichkeit, nur mit Root-Rechten auf Hardware zuzugreifen, wird das Problem nicht l\u00f6sen: \u201eAnwendungsentwickler weisen darauf hin, dass ihre Anwendung aus Sicherheitsgr\u00fcnden als root installiert werden sollte, denn nur so k\u00f6nnen Sie auf 'wirklich gute' Zufallszahlen zugreifen\u201c.<\/i><\/p>\n

M\u00fcller fragte, ob Tsao die Implementierung des blockierenden Pools, die er selbst vor langer Zeit vorgeschlagen hatte, aufgegeben hat. Tsao antwortete, dass er plant, die Patches von Lutomirski zu \u00fcbernehmen und aktiv gegen das Hinzuf\u00fcgen einer blockierenden Schnittstelle zur\u00fcck in den Kern ist. <\/p>\n

\"Der Kernel kann keine Garantien daf\u00fcr geben, dass die Rauschenquelle ordnungsgem\u00e4\u00df charakterisiert wurde. Das Einzige, was der Entwickler von GPG oder OpenSSL erhalten kann, ist ein schwammiges Gef\u00fchl, dass TRUERANDOM 'besser' ist, und da sie mehr Sicherheit wollen, werden sie es sicherlich verwenden wollen. Irgendwann wird es blockiert, und wenn ein anderer kluger Benutzer (m\u00f6glicherweise ein Distribution-Release-Spezialist) es in das Init-Skript einf\u00fcgt, werden die Systeme ausfallen, und den Benutzern bleibt nur, Linus Torvalds selbst zu beschweren.\"<\/i> <\/p>\n

Tsao spricht sich auch daf\u00fcr aus, Kryptographen und denen, die wirklich TRNG ben\u00f6tigen, zu erm\u00f6glichen, ihre eigene Entropie im Benutzerspeicher zu sammeln, um sie nach eigenem Ermessen zu verwenden. Er sagt, dass das Sammeln von Entropie kein Prozess ist, der vom Kernel auf allen unterst\u00fctzten Hardware-Ger\u00e4ten durchgef\u00fchrt werden kann, au\u00dferdem kann der Kernel selbst nicht einsch\u00e4tzen, wie viel Entropie von verschiedenen Quellen bereitgestellt wird. <\/p>\n

\u201eDer Kernel sollte unterschiedliche Ger\u00e4uschquellen nicht zusammenmischen, und er sollte nat\u00fcrlich nicht versuchen zu behaupten, zu wissen, wie viele Bits Entropie er erh\u00e4lt, wenn er versucht, ein gewisses \u201ezerr\u00fcttetes Entropiespiel\u201c auf einer erschreckend einfachen CPU-Architektur f\u00fcr Benutzerf\u00e4lle im IOT\/Embedded zu spielen, wenn alles mit einem einzigen Mastergenerator unsynchronisiert ist, wenn es keinen Befehl der CPU zum Umordnen oder Umbenennen von Registern gibt usw.\u201c<\/p>\n

\u201eMan kann \u00fcber die Bereitstellung von Werkzeugen sprechen, die versuchen, diese Berechnungen anzustellen, aber solche Dinge sollten auf der Hardware jedes Benutzers stattfinden, was f\u00fcr die meisten Benutzer des Distributionspakets einfach unpraktisch ist. Wenn dies jedoch nur f\u00fcr Kryptographen gedacht ist, dann lassen Sie es in ihrem Benutzerraum geschehen. Und lassen Sie uns GPG, OpenSSL usw. nicht vereinfachen, damit alle sagen: \u201eWir wollen \u201eechte Zuf\u00e4lligkeit\u201c und akzeptieren nichts weniger.\u201c Man kann dar\u00fcber sprechen, wie wir Schnittstellen f\u00fcr Kryptographen bereitstellen, damit sie die ben\u00f6tigten Informationen durch den Zugang zu prim\u00e4ren Ger\u00e4uschquellen, die getrennt und benannt sind, erhalten k\u00f6nnen, und vielleicht kann sich die Ger\u00e4uschquelle irgendwie in der Bibliothek oder Anwendung des Benutzerraums authentifizieren.\u201c<\/i><\/p>\n

Es gab eine kleine Diskussion dar\u00fcber, wie eine solche Schnittstelle aussehen k\u00f6nnte, denn beispielsweise k\u00f6nnen einige Ereignisse Sicherheitsfolgen haben. Cao bemerkte, dass die Codes zum Scannen von Tastaturen (d.h. Tastendrucke) in einen Pool gemischt werden als Teil der Entropiesammlung: \u201eDas in den Benutzerraum zu verlagern, selbst \u00fcber einen privilegierten Systemaufruf, w\u00e4re zumindest unklug.\u201c Es ist durchaus m\u00f6glich, dass andere Zeitereignisse irgendwie Informationsleckagen \u00fcber Seitenkan\u00e4le verursachen k\u00f6nnten. <\/p>\n

So entsteht das Gef\u00fchl, dass das seit langem bestehende Problem des Linux-Zufallszahlensubsystems auf dem Weg zur L\u00f6sung ist. Die \u00c4nderungen, die das Zufallszahlensystem in letzter Zeit durchlaufen hat, f\u00fchrten tats\u00e4chlich nur zu DoS-Problemen w\u00e4hrend seiner Nutzung. Jetzt gibt es jedoch effektive Wege, um die besten Zufallszahlen zu erhalten, die der Kernel bieten kann. Wenn TRNG weiterhin f\u00fcr Linux w\u00fcnschenswert ist, muss dieses Manko in Zukunft behoben werden, aber wahrscheinlich wird dies nicht im Kern selbst geschehen. <\/p>\n

Ein wenig Werbung \ud83d\ude42<\/h3>\n

\nDanke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? M\u00f6chten Sie mehr interessante Inhalte sehen? Unterst\u00fctzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, Cloud-VPS f\u00fcr Entwickler ab 4,99 $<\/a><\/noindex>, ein einzigartiges \u00c4quivalent zu Einsteigerservern, das wir f\u00fcr Sie entwickelt haben:<\/b> Die ganze Wahrheit \u00fcber VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt?<\/a><\/noindex> (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verf\u00fcgbar).<\/p>\n

Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so g\u00fcnstig?<\/b> Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab $199<\/a><\/noindex> in den Niederlanden! Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 ab $99!<\/b><\/b> Lesen Sie, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern f\u00fcr 9000 Euro im Preis-Leistungs-Verh\u00e4ltnis aufbaut?<\/a><\/noindex>
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u043e, \u0443 \/dev\/random, \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u043f\u0441\u0435\u0432\u0434\u043e\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b (CSPRNG), \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u044f\u0442\u043d\u0430\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u2013 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0438. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f, \u043a\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043c\u043e\u0436\u043d\u043e \u0435\u0435 \u0440\u0435\u0448\u0438\u0442\u044c. \u0417\u0430 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u0435\u0441\u044f\u0446\u0435\u0432 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430 \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u0438 \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0432 \u044f\u0434\u0440\u0435 \u0431\u044b\u043b\u0438 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043f\u0435\u0440\u0435\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u044b, \u043d\u043e \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0432 \u044d\u0442\u043e\u0439 \u043f\u043e\u0434\u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u0440\u0435\u0448\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043f\u0440\u043e\u0442\u044f\u0436\u0435\u043d\u0438\u0438 \u0431\u043e\u043b\u0435\u0435 \u0448\u0438\u0440\u043e\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445 \u0440\u0430\u043c\u043e\u043a. \u0421\u0430\u043c\u044b\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0431\u044b\u043b\u0438 \u0441\u0434\u0435\u043b\u0430\u043d\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55510","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Linux: Entfernen des Lock-Pools \/dev\/random | ProHoster","description":"Wie bekannt ist, hat \/dev\/random, ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG), ein unangenehmes Problem \u2013 Blockierungen. In diesem Artikel wird erl\u00e4utert, wie man dieses Problem l\u00f6sen kann.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/linux-udalenie-pula-blokirovok-dev-random","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Linux: \u0443\u0434\u0430\u043b\u0435\u043d\u0438\u0435 \u043f\u0443\u043b\u0430 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043e\u043a \/dev\/random | ProHoster","og:description":"\u041a\u0430\u043a \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u043e, \u0443 \/dev\/random, \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u043f\u0441\u0435\u0432\u0434\u043e\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b (CSPRNG), \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u044f\u0442\u043d\u0430\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u2013 \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0438. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f, \u043a\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043c\u043e\u0436\u043d\u043e \u0435\u0435 \u0440\u0435\u0448\u0438\u0442\u044c.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/linux-udalenie-pula-blokirovok-dev-random","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-21T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55510","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:43:30","updated":"2022-10-02 22:01:02","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55510","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=55510"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/55510\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=55510"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=55510"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=55510"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}