{"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\/es\/blog\/administrirovanie\/linux-udalenie-pula-blokirovok-dev-random","title":{"rendered":"Linux: eliminaci\u00f3n del grupo de bloqueos \/dev\/random","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Como es bien sabido, \/dev\/random, un generador de n\u00fameros aleatorios criptogr\u00e1ficamente seguro (CSPRNG), tiene un problema inc\u00f3modo: los bloqueos. Este art\u00edculo explica c\u00f3mo se puede solucionar. <\/p>\n

En los \u00faltimos meses, se han realizado algunas modificaciones en los m\u00e9todos de generaci\u00f3n de n\u00fameros aleatorios en el n\u00facleo, pero se han abordado problemas en este subsistema durante un per\u00edodo m\u00e1s amplio. marco temporal.<\/a><\/noindex>Los \u00faltimos cambios<\/a><\/noindex> se hicieron con el objetivo de prevenir el bloqueo prolongado de la llamada al sistema getrandom() al arrancar el sistema, pero la causa subyacente de esto fue el comportamiento del grupo aleatorio bloqueante. Un parche reciente elimin\u00f3 este grupo, y se esperaba que se dirigiera al n\u00facleo principal. <\/p>\n

Andy Lutomirski public\u00f3 la tercera versi\u00f3n del parche a finales de diciembre. Este introduce \u201cdos cambios sem\u00e1nticos principales en las API aleatorias de Linux\u201d.<\/i>El parche agrega una nueva bandera GRND_INSECURE a la llamada al sistema getrandom() (aunque Lutomirski se refiere a ella como getentropy(), que se implementa en glibc usando getrandom() con banderas fijas); esta bandera hace que la llamada siempre devuelva la cantidad de datos solicitados, pero sin la garant\u00eda de que estos datos sean aleatorios. El n\u00facleo simplemente se esforzar\u00e1 por proporcionar los mejores datos aleatorios que tenga en ese momento. \u201cProbablemente lo mejor que se puede hacer es llamarlo 'INSECURE'<\/i> (inseguro), para desincentivar el uso de esta API para cosas que necesitan seguridad.\u201d<\/a><\/noindex><\/p>\n

Los parches tambi\u00e9n eliminan el grupo bloqueante. Actualmente, el n\u00facleo mantiene dos grupos de datos aleatorios, uno correspondiente a \/dev\/random y el otro a \/dev\/urandom, como se describe en esta el art\u00edculo<\/a><\/noindex> publicaci\u00f3n de 2015. El grupo bloqueante es un grupo para \/dev\/random; la lectura de este dispositivo se bloquear\u00e1 (como su nombre indica) hasta que se haya recopilado suficiente entrop\u00eda del sistema para satisfacer la solicitud. Lecturas adicionales de este archivo tambi\u00e9n se bloquean si no hay suficiente entrop\u00eda en el grupo. <\/p>\n

La eliminaci\u00f3n del pool de bloqueos significa que la lectura de \/dev\/random se comporta como getrandom() con el valor de flags igual a cero (y convierte el flag GRND_RANDOM en noop). Despu\u00e9s de inicializar el generador criptogr\u00e1fico de n\u00fameros aleatorios (CRNG), la lectura de \/dev\/random y las llamadas a getrandom(…,0) no provocar\u00e1n bloqueos y devolver\u00e1n la cantidad solicitada de datos aleatorios.<\/p>\n

Lutomirsky dice: \u00abCreo que el grupo de bloqueo de Linux ha quedado obsoleto. El CRNG de Linux genera salidas que son lo suficientemente buenas como para ser utilizadas incluso para la generaci\u00f3n de claves. El grupo de bloqueo ya no es m\u00e1s fuerte en ning\u00fan sentido material, y su mantenimiento requiere mucha infraestructura de dudoso valor\u00bb. <\/i><\/p>\n

Se hicieron cambios con la intenci\u00f3n de que los programas existentes no se vean realmente afectados, y de hecho, los problemas con largas esperas para cosas como la generaci\u00f3n de claves GnuPG ser\u00e1n menores.<\/p>\n

\u00abEstas series no deber\u00edan interrumpir ning\u00fan programa existente. \/dev\/urandom permanece sin cambios. \/dev\/random todav\u00eda se bloquea justo despu\u00e9s de la carga, pero ahora se bloquea menos que antes. getentropy() con los flags existentes devolver\u00e1 un resultado que ser\u00e1 tan apropiado para prop\u00f3sitos pr\u00e1cticos como antes\u00bb.<\/i> <\/p>\n

Lutomirsky se\u00f1al\u00f3 que todav\u00eda queda abierta la cuesti\u00f3n de si el n\u00facleo deber\u00eda proporcionar lo que se llaman \"n\u00fameros verdaderamente aleatorios\", que en cierta medida era lo que se supon\u00eda que hac\u00eda el n\u00facleo de bloqueo. Solo ve una raz\u00f3n para ello: \u00abcumplimiento de est\u00e1ndares gubernamentales\u00bb. Lutomirsky sugiri\u00f3 que si el n\u00facleo debe asegurarlo, deber\u00eda hacerse a trav\u00e9s de una interfaz completamente diferente o deber\u00eda trasladarse al espacio de usuario, permiti\u00e9ndole extraer muestras crudas de eventos que puedan ser utilizadas para crear tal grupo de bloqueo. <\/p>\n

Stephan M\u00fcller sugiri\u00f3 que su conjunto de parches<\/a><\/noindex> Para el generador de n\u00fameros aleatorios de Linux (LRNG) (actualmente en su versi\u00f3n 26), puede ser una forma de proporcionar n\u00fameros verdaderamente aleatorios para aplicaciones que lo necesitan. LRNG \"cumple completamente con los requisitos de las 'Recomendaciones sobre fuentes de entrop\u00eda utilizadas para la generaci\u00f3n de bits aleatorios' SP800-90B\", lo que lo convierte en una soluci\u00f3n para el problema de las normas estatales.
\nMatthew Garrett se opuso al t\u00e9rmino 'datos verdaderamente aleatorios', se\u00f1alando que los dispositivos elegidos pueden ser modelados lo suficientemente bien como para hacerlos predecibles: 'no estamos seleccionando eventos cu\u00e1nticos aqu\u00ed'.<\/p>\n

M\u00fcller respondi\u00f3 que este t\u00e9rmino proviene del est\u00e1ndar alem\u00e1n AIS 31 para describir un generador de n\u00fameros aleatorios que solo produce resultados 'a la misma velocidad a la que la fuente b\u00e1sica de ruido genera entrop\u00eda'. <\/p>\n

Adem\u00e1s de las interpretaciones err\u00f3neas de la terminolog\u00eda, la existencia de un pool de bloqueo, tal como se propone en los parches de LRNG, simplemente causar\u00e1 diversos problemas, al menos si est\u00e1 disponible sin privilegios. <\/p>\n

Como dijo Lutomirski: \"Esto no resuelve el problema. Si dos usuarios diferentes ejecutan programas tontos, como gnupg, simplemente se agotar\u00edan entre s\u00ed. Veo que actualmente hay dos principales problemas con \/dev\/random: tiende al DoS (es decir, agotar recursos, impactar maliciosamente o algo por el estilo), y dado que no se requieren privilegios para su uso, tambi\u00e9n es propenso a abusos. Gnupg est\u00e1 mal, es un colapso total. Si a\u00f1adimos una nueva interfaz no privilegiada que utilizar\u00e1n gnupg y programas similares, perderemos nuevamente.\"<\/i> <\/p>\n

M\u00fcller se\u00f1al\u00f3 que a\u00f1adir getrandom() ahora permitir\u00e1 a GnuPG utilizar esta interfaz, ya que proporcionar\u00e1 la garant\u00eda necesaria de que el pool ha sido inicializado. Bas\u00e1ndose en discusiones con el desarrollador de GnuPG Werner Koch, M\u00fcller considera que la garant\u00eda es la \u00fanica raz\u00f3n por la que GnuPG actualmente lee directamente de \/dev\/random. Pero si hay una interfaz no privilegiada que es susceptible a denegaciones de servicio (como lo es hoy \/dev\/random), seg\u00fan Lutomirski, ser\u00e1 mal utilizada por algunas aplicaciones. <\/p>\n

Teodoro Cao (Theodore Yue Tak Ts’o), el desarrollador del subsistema de n\u00fameros aleatorios de Linux, aparentemente ha cambiado de opini\u00f3n sobre la necesidad de un pool bloqueante. Dijo que la eliminaci\u00f3n de este pool permitir\u00e1 deshacerse eficazmente de la idea de que Linux tiene un verdadero generador de n\u00fameros aleatorios (TRNG): \u00abNo es una tonter\u00eda, ya que es exactamente lo que siempre han hecho los *BSD\u00bb.<\/i><\/p>\n

Tambi\u00e9n est\u00e1 preocupado de que proporcionar un mecanismo TRNG simplemente sirva como un se\u00f1uelo para los desarrolladores de aplicaciones y considera que, de hecho, dado los diferentes tipos de hardware soportados por Linux, es imposible garantizar TRNG en el n\u00facleo. El problema no se resolver\u00e1 ni siquiera con la posibilidad de trabajar con hardware solo con privilegios de root: \u00abLos desarrolladores de aplicaciones indican que su aplicaci\u00f3n, por razones de seguridad, debe ser instalada como root, solo de esa manera se puede acceder a los 'n\u00fameros aleatorios realmente buenos'\u00bb.<\/i><\/p>\n

M\u00fcller pregunt\u00f3 si Tsao hab\u00eda renunciado a la implementaci\u00f3n del pool bloqueante que \u00e9l mismo hab\u00eda propuesto hace tiempo. Tsao respondi\u00f3 que planea tomar los parches de Lutomirski y se opone activamente a agregar la interfaz bloqueante de nuevo al n\u00facleo. <\/p>\n

\"El n\u00facleo no puede dar ninguna garant\u00eda sobre si la fuente de ruido ha sido caracterizada adecuadamente. Lo \u00fanico que puede obtener un desarrollador de GPG o OpenSSL es una vaga sensaci\u00f3n de que TRUERANDOM es 'mejor', y como quieren m\u00e1s seguridad, sin duda intentar\u00e1n utilizarlo. En alg\u00fan momento se bloquear\u00e1, y cuando alg\u00fan otro usuario inteligente (quiz\u00e1s un especialista en lanzamiento de distribuciones) lo inserte en el script init y los sistemas dejen de funcionar, a los usuarios solo les quedar\u00e1 quejarse ante Linus Torvalds\".<\/i> <\/p>\n

Tsao tambi\u00e9n aboga por permitir a los cript\u00f3grafos y a quienes realmente necesitan TRNG la forma de recolectar su propia entrop\u00eda en el espacio del usuario, para usarla a su conveniencia. \u00c9l dice que la recolecci\u00f3n de entrop\u00eda no es un proceso que pueda realizar el n\u00facleo en todos los diversos hardware que admite; adem\u00e1s, el propio n\u00facleo no puede evaluar la cantidad de entrop\u00eda proporcionada por las diferentes fuentes. <\/p>\n

\u00abEl n\u00facleo no debe mezclar diferentes fuentes de ruido, y no debe pretender saber cu\u00e1ntos bits de entrop\u00eda recibe al intentar jugar una 'juego de entrop\u00eda' en una arquitectura de CPU incre\u00edblemente simple para casos de uso de IOT\/Embebido, cuando todo est\u00e1 desincronizado con un \u00fanico generador maestro, sin ninguna instrucci\u00f3n de CPU para reordenar o renombrar registros, etc\u00e9tera\u00bb.<\/p>\n

\u00abSe puede hablar sobre proporcionar herramientas que intenten realizar estos c\u00e1lculos, pero tales cosas deben llevarse a cabo en el hardware de cada usuario, lo cual es, para la mayor\u00eda de los usuarios de la distribuci\u00f3n, simplemente poco pr\u00e1ctico. Si esto est\u00e1 destinado solo a cript\u00f3grafos, que se haga en su espacio de usuario. Y no simplifiquemos GPG, OpenSSL, etc., para que todos digan: 'queremos 'verdadera aleatoriedad' y no aceptamos menos'. Se puede hablar sobre c\u00f3mo proporcionamos interfaces a los cript\u00f3grafos para que puedan obtener la informaci\u00f3n necesaria a trav\u00e9s de acceso a fuentes de ruido primarias, separadas y nombradas, y, tal vez, de alguna manera, la fuente de ruido pueda autenticarse en la biblioteca o aplicaci\u00f3n del espacio de usuario\u00bb.<\/i><\/p>\n

Tuvo lugar una peque\u00f1a discusi\u00f3n sobre c\u00f3mo podr\u00eda ser dicha interfaz, ya que, por ejemplo, ciertos eventos podr\u00edan tener implicaciones en t\u00e9rminos de seguridad. Cao se\u00f1al\u00f3 que los c\u00f3digos de escaneo del teclado (es decir, las pulsaciones de teclas) se mezclan en un pool como parte de la recolecci\u00f3n de entrop\u00eda: 'Mover esto al espacio de usuario, incluso a trav\u00e9s de una llamada al sistema privilegiada, ser\u00eda, al menos, imprudente'. Es bastante posible que otros tiempos de eventos puedan crear alguna fuga de informaci\u00f3n a trav\u00e9s de canales secundarios. <\/p>\n

As\u00ed, se tiene la sensaci\u00f3n de que un viejo problema del subsistema de n\u00fameros aleatorios de Linux est\u00e1 en camino de soluci\u00f3n. Los cambios que el subsistema de n\u00fameros aleatorios ha sufrido \u00faltimamente han llevado principalmente a problemas de DoS en su uso. Ahora, sin embargo, hay m\u00e9todos efectivos para obtener los mejores n\u00fameros aleatorios que el n\u00facleo puede proporcionar. Si TRNG sigue siendo deseable para Linux, este defecto tendr\u00e1 que ser corregido en el futuro, aunque es poco probable que se haga dentro del propio n\u00facleo. <\/p>\n

Un poco de publicidad \ud83d\ude42<\/h3>\n

\nGracias por permanecer con nosotros. \u00bfTe gustan nuestros art\u00edculos? \u00bfQuieres ver m\u00e1s contenido interesante? Ap\u00f3yanos haciendo un pedido o recomendando a tus conocidos, VPS en la nube para desarrolladores desde $4.99<\/a><\/noindex>, un an\u00e1logo \u00fanico de servidores entry-level que hemos dise\u00f1ado para Ti:<\/b> Toda la verdad sobre VPS (KVM) E5-2697 v3 (6 n\u00facleos) 10GB DDR4 480GB SSD 1Gbps desde $19, o c\u00f3mo dividir correctamente un servidor?<\/a><\/noindex> (disponibles opciones con RAID1 y RAID10, hasta 24 n\u00facleos y hasta 40GB DDR4).<\/p>\n

\u00bfDell R730xd a mitad de precio en el centro de datos Equinix Tier IV en \u00c1msterdam?<\/b> Solo aqu\u00ed 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB desde $199<\/a><\/noindex> \u00a1en los Pa\u00edses Bajos! Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 \u00a1desde $99!<\/b><\/b> Lee sobre c\u00f3mo Construir infraestructura de clase empresarial usando servidores Dell R730xd E5-2650 v4 que cuestan 9000 euros a un precio asequible?<\/a><\/noindex>
\n
Fuente: 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: eliminaci\u00f3n del grupo de bloqueo \/dev\/random | ProHoster","description":"Como es bien sabido, \/dev\/random, un generador de n\u00fameros aleatorios criptogr\u00e1ficamente seguro (CSPRNG), tiene un problema inc\u00f3modo: los bloqueos. Este art\u00edculo explica c\u00f3mo se puede solucionar.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/linux-udalenie-pula-blokirovok-dev-random","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/55510","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=55510"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/55510\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=55510"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=55510"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=55510"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}