{"id":39415,"date":"2019-10-31T22:32:08","date_gmt":"2019-10-31T19:32:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/check-point-optimizatsiya-cpu-i-ram\/"},"modified":"2019-10-31T22:32:08","modified_gmt":"2019-10-31T19:32:08","slug":"check-point-optimizatsiya-cpu-i-ram","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","title":{"rendered":"Check Point: optimizaci\u00f3n de CPU y RAM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Check
\n\u00a1Hola, colegas! Hoy me gustar\u00eda discutir un tema muy relevante para muchos administradores de Check Point: \u00abOptimizaci\u00f3n de CPU y RAM\u00bb. No es raro que la puerta de enlace y\/o el servidor de gesti\u00f3n consuman inesperadamente muchos de estos recursos, y nos gustar\u00eda entender a d\u00f3nde se \u201cescapan\u201d y, en la medida de lo posible, usarlos de manera m\u00e1s eficiente. <\/p>\n

1. An\u00e1lisis<\/h3>\n

\nPara analizar la carga del procesador, es \u00fatil utilizar los siguientes comandos, que se ingresan en modo experto:
\n<\/a><\/noindex>
\ntop<\/b> muestra todos los procesos, la cantidad de recursos CPU y RAM consumidos en porcentaje, el tiempo de actividad, la prioridad del proceso y otro<\/a><\/noindex> en tiempo real<\/i>y <\/p>\n

\"Check
\n
\ncpwd_admin list<\/b> Check Point WatchDog Daemon, que muestra todos los m\u00f3dulos del appliance, su PID, estado y cantidad de ejecuciones<\/i><\/p>\n

\"Check
\n
\ncpstat -f cpu os<\/b> uso de CPU, su n\u00famero y distribuci\u00f3n del tiempo de procesador en porcentajes<\/i><\/p>\n

\"Check
\n
\ncpstat -f memory os<\/b> uso de RAM virtual, cu\u00e1nto hay de activa, RAM libre y otros datos<\/i><\/p>\n

\"Check
\n
\nUn comentario acertado es que todos los comandos cpstat se pueden ver con la herramienta cpview<\/b>. Para ello, simplemente hay que ingresar el comando cpview desde cualquier modo en una sesi\u00f3n SSH.<\/p>\n

\"Check
\n\"Check
\n
\nps auxwf<\/b> lista larga de todos los procesos, sus ID, la memoria virtual ocupada y la memoria en RAM, CPU<\/i><\/p>\n

\"Check
\n
\nOtra variaci\u00f3n del comando: <\/p>\n

ps -aF<\/b> mostrar\u00e1 el proceso m\u00e1s intensivo<\/i><\/p>\n

\"Check
\n
\nfw ctl affinity -l -a<\/b> distribuci\u00f3n de n\u00facleos entre las diferentes instancias del firewall, es decir, tecnolog\u00eda CoreXL<\/i><\/p>\n

\"Check
\n
\n fw ctl pstat<\/b> an\u00e1lisis de RAM y estad\u00edsticas generales de conexiones, cookies, NAT<\/i><\/p>\n

\"Check
\n
\nfree -m<\/b> memoria cach\u00e9<\/i><\/p>\n

\"Check
\n
\nEs importante destacar el comando netsat <\/b>y sus variaciones. Por ejemplo, netstat -i<\/b> puede ayudar a resolver la tarea de monitoreo de buffers. El par\u00e1metro RX dropped packets (RX-DRP) en la salida de este comando suele aumentar por s\u00ed solo debido a drops de protocolos ileg\u00edtimos (IPv6, Bad \/ Unintended VLAN tags y otros). Sin embargo, si los drops ocurren por otra raz\u00f3n, se debe consultar esta art\u00edculo<\/a><\/noindex>, para comenzar una investigaci\u00f3n y entender por qu\u00e9 esta interfaz de red est\u00e1 descartando paquetes. Al identificar la causa, tambi\u00e9n se puede optimizar el funcionamiento del appliance.<\/p>\n

\"Check
\n
\nSi el blade Monitoring est\u00e1 habilitado, se pueden ver estos indicadores gr\u00e1ficamente en SmartConsole, al hacer clic en el objeto y seleccionar la opci\u00f3n \u00abInformaci\u00f3n del Dispositivo & Licencia\u00bb. <\/p>\n

No se recomienda habilitar el blade Monitoring de forma permanente, pero para pruebas durante un d\u00eda es completamente aceptable.<\/p>\n

\"Check
\n
\nAdem\u00e1s, se pueden agregar m\u00e1s par\u00e1metros para el monitoreo, uno de los m\u00e1s \u00fatiles es Bytes Throughput (capacidad de procesamiento del appliance).<\/p>\n

\"Check
\n
\nSi hay alg\u00fan otro sistema de monitoreo, por ejemplo, uno gratuito Zabbix<\/a><\/noindex>, basado en SNMP, tambi\u00e9n servir\u00e1 para identificar esos problemas.<\/p>\n

2. \"Fuga\" de RAM con el tiempo<\/h3>\n

\nA menudo surge la pregunta de que, con el tiempo, el gateway o el servidor de gesti\u00f3n comienzan a consumir cada vez m\u00e1s RAM. Quiero tranquilizar: esto es normal en sistemas similares a Linux. <\/p>\n

Al observar la salida de los comandos free -m<\/b> y cpstat -f memory os<\/b> en el appliance desde el modo experto, se pueden contar y observar todos los par\u00e1metros relacionados con la RAM.<\/p>\n

En realidad, la memoria disponible en el gateway en este momento Memoria libre<\/b> + Memoria de buffers<\/b> + Memoria cacheada<\/b> = +-1.5 Gb<\/b>, por lo general.<\/p>\n

Como dice el S.R., con el tiempo el gateway\/servidor de gesti\u00f3n se optimiza y usa cada vez m\u00e1s memoria, alcanzando aproximadamente el 80% de uso, y se detiene. Puede reiniciar el dispositivo y entonces el indicador se restablecer\u00e1. 1.5 Gb de RAM libre es m\u00e1s que suficiente para ejecutar todas las tareas, y el servidor de gesti\u00f3n rara vez llega a esos valores m\u00e1ximos.<\/p>\n

Adem\u00e1s, las salidas de los comandos mencionados mostrar\u00e1n cu\u00e1nto tiene Baja memoria<\/b> (memoria RAM en espacio de usuario) y Alta memoria<\/b> (memoria RAM en espacio del kernel) utilizada.<\/p>\n

Los procesos del kernel (incluidos los m\u00f3dulos activos, como los m\u00f3dulos del kernel de Check Point) solo utilizan memoria baja. Sin embargo, los procesos de usuario pueden utilizar tanto memoria baja como alta. Adem\u00e1s, la memoria baja es aproximadamente Memoria total<\/b>.<\/p>\n

Solo se debe preocuparse si en los registros aparecen errores \"m\u00f3dulos reiniciados o procesos siendo asesinados para recuperar memoria debido a OOM (Fuera de memoria)\"<\/b>. Entonces se debe reiniciar el gateway y contactar con soporte, si el reinicio no ayuda.<\/p>\n

Una descripci\u00f3n completa se puede encontrar en sk99547 <\/a><\/noindex>y sk99593<\/a><\/noindex>.<\/p>\n

3. Optimizaci\u00f3n<\/h3>\n

\nA continuaci\u00f3n se presentan preguntas y respuestas sobre la optimizaci\u00f3n de CPU y RAM. Es importante que se responda honestamente y escuche las recomendaciones.<\/p>\n

3.1. \u00bfSe eligi\u00f3 correctamente el appliance? \u00bfHubo un proyecto piloto?<\/h4>\n

\nA pesar de un dimensionamiento adecuado, la red podr\u00eda haber crecido y este hardware simplemente no puede soportar la carga. La segunda opci\u00f3n es que, efectivamente, no hubo dimensionamiento.<\/p>\n

3.2. \u00bfEst\u00e1 habilitada la inspecci\u00f3n HTTPS? Si es as\u00ed, \u00bfest\u00e1 configurada de acuerdo con las mejores pr\u00e1cticas? <\/h4>\n

\nConsulte el art\u00edculo<\/a><\/noindex>, si usted es nuestro cliente, o el sk108202<\/a><\/noindex>.<\/p>\n

El orden de las reglas en la pol\u00edtica de inspecci\u00f3n HTTPS es muy importante para la optimizaci\u00f3n de la apertura de sitios HTTPS.<\/p>\n

Orden recomendado de las reglas:<\/p>\n

    \n
  1. Reglas de bypass con categor\u00edas\/URL<\/li>\n
  2. Reglas de inspecci\u00f3n con categor\u00edas\/URL<\/li>\n
  3. Reglas de inspecci\u00f3n para todas las dem\u00e1s categor\u00edas<\/li>\n<\/ol>\n

    \n\"Check
    \n
    \nDe manera similar a la pol\u00edtica de cortafuegos, Check Point busca coincidencias en los paquetes de arriba hacia abajo, por lo que es mejor ubicar las reglas de bypass en la parte superior, ya que el gateway no gastar\u00e1 recursos procesando todas las reglas si se debe omitir este paquete.<\/p>\n

    3.3 \u00bfSe utilizan objetos de rango de direcciones?<\/h4>\n

    \nLos objetos con rango de direcciones, por ejemplo, la red 192.168.0.0-192.168.5.0, consumen significativamente m\u00e1s RAM que 5 objetos de red. En general, se considera una buena pr\u00e1ctica eliminar objetos no utilizados en SmartConsole, ya que cada vez que se aplica una pol\u00edtica, el gateway y el servidor de gesti\u00f3n gastan recursos y, lo que es m\u00e1s importante, tiempo en verificar y aplicar la pol\u00edtica.<\/p>\n

    3.4. \u00bfC\u00f3mo est\u00e1 configurada la pol\u00edtica de Prevenci\u00f3n de Amenazas? <\/h4>\n

    \nEn primer lugar, Check Point recomienda colocar IPS en un perfil separado y crear reglas espec\u00edficas para este blade. <\/p>\n

    Por ejemplo, el administrador considera que es necesario proteger el segmento DMZ \u00fanicamente con IPS. Por lo tanto, para que el gateway no gaste recursos procesando paquetes con otros blades, es necesario crear una regla espec\u00edficamente para este segmento con un perfil que incluya solo IPS.<\/p>\n

    En cuanto a la configuraci\u00f3n de perfiles, se recomienda configurarlo siguiendo las mejores pr\u00e1cticas de este documento<\/a><\/noindex>(p\u00e1ginas 17-20).<\/p>\n

    3.5. En la configuraci\u00f3n de IPS, \u00bfcu\u00e1ntas firmas est\u00e1n en modo Detect? <\/h4>\n

    \nSe recomienda trabajar intensamente en las firmas en el sentido de que se deben desactivar las no utilizadas (por ejemplo, las firmas para la explotaci\u00f3n de productos de Adobe requieren mucha potencia de c\u00e1lculo, y si el cliente no tiene tales productos, tiene sentido desactivarlas). Luego, establecer Prevent en lugar de Detect donde sea posible, porque el gateway gasta recursos en procesar toda la conexi\u00f3n en modo Detect; en modo Prevent, descarta inmediatamente la conexi\u00f3n y no gasta recursos en el procesamiento completo del paquete.<\/p>\n

    3.6. \u00bfQu\u00e9 archivos son procesados por los blades de Emulaci\u00f3n de Amenazas, Extracci\u00f3n de Amenazas, Anti-Virus?<\/h4>\n

    \nNo tiene sentido emular y analizar archivos de extensi\u00f3n que sus usuarios no descargan, o que usted considera innecesarios en su red (por ejemplo, los archivos bat, exe se pueden bloquear f\u00e1cilmente con el blade de Content Awareness a nivel de firewall, por lo que los recursos del gateway se utilizar\u00e1n de manera m\u00e1s eficiente). Adem\u00e1s, en la configuraci\u00f3n de Threat Emulation, se puede elegir el Environment (sistema operativo) para emular amenazas en la sandbox, y establecer el Environment Windows 7 cuando todos los usuarios est\u00e1n en la versi\u00f3n 10 tampoco tiene sentido.<\/p>\n

    3.7. \u00bfEst\u00e1n las reglas del firewall y las reglas de nivel de aplicaci\u00f3n en l\u00ednea con las mejores pr\u00e1cticas? <\/h4>\n

    \nSi una regla tiene muchas coincidencias, se recomienda colocarla en la parte superior, mientras que las reglas con pocas coincidencias deben ir en la parte inferior. Lo principal es asegurarse de que no se crucen ni se superpongan. La arquitectura recomendada de la pol\u00edtica del firewall es:<\/p>\n

    \"Check
    \n
    \nExplicaciones: <\/p>\n

    First Rules \u2014 aqu\u00ed se colocan las reglas con la mayor cantidad de coincidencias
    \nNoise Rule \u2014 regla para descartar tr\u00e1fico par\u00e1sito, como NetBIOS
    \nStealth Rule \u2014 prohibici\u00f3n de accesos a gateways y administraciones para todos, excepto aquellos or\u00edgenes que se indicaron en las reglas de Authentication to Gateway Rules
    \nClean-Up, Last y Drop Rules, generalmente se combinan en una sola regla para prohibir todo lo que no se permiti\u00f3 previamente<\/p>\n

    Estos Best practices se describen en sk106597<\/a><\/noindex>.<\/p>\n

    3.8. \u00bfQu\u00e9 configuraciones tienen los servicios creados por los administradores? <\/h4>\n

    \nPor ejemplo, se crea alg\u00fan servicio TCP en un puerto espec\u00edfico, y tiene sentido en las configuraciones avanzadas del servicio desmarcar la opci\u00f3n \u201cMatch for Any\u201d. En este caso, el servicio se ajustar\u00e1 espec\u00edficamente a la regla en la que aparece, y no participar\u00e1 en las reglas donde est\u00e1 en la columna Services 'Any'.<\/p>\n

    \"Check
    \n
    \nHablando de servicios, es importante mencionar que a veces es necesario ajustar los timeouts. Esta configuraci\u00f3n permitir\u00e1 utilizar mejor los recursos del gateway, para no mantener sesiones TCP\/UDP de protocolos que no requieren un timeout largo. Por ejemplo, en la captura de pantalla a continuaci\u00f3n, reduje el timeout del servicio domain-udp de 40 segundos a 30 segundos.<\/p>\n

    \"Check
    \n<\/p>\n

    3.9. \u00bfSe est\u00e1 usando SecureXL y cu\u00e1l es el porcentaje de aceleraci\u00f3n? <\/h4>\n

    \nSe puede verificar la calidad del funcionamiento de SecureXL con los principales comandos en modo experto en el gateway. fwaccel stat<\/b> y fw accel stats -s<\/b>. Luego, es necesario investigar qu\u00e9 tr\u00e1fico se est\u00e1 acelerando, qu\u00e9 templates se pueden crear adicionalmente. <\/p>\n

    Por defecto, las Plantillas Drop no est\u00e1n habilitadas, habilitarlas beneficiar\u00e1 el funcionamiento de SecureXL. Para ello, acceda a la configuraci\u00f3n del gateway y a la pesta\u00f1a Optimizations:<\/p>\n

    \"Check
    \n
    \nAdem\u00e1s, al trabajar con un cl\u00faster, para optimizar la CPU, se puede desactivar la sincronizaci\u00f3n de servicios no cr\u00edticos, como UDP DNS, ICMP y otros. Para esto, es necesario ingresar en la configuraci\u00f3n del servicio \u2192 Avanzado \u2192 Sincronizar conexiones de State Synchronization en el cl\u00faster.<\/p>\n

    \"Check
    \n
    \nTodas las Mejores Pr\u00e1cticas est\u00e1n descritas en     sk98348<\/a><\/noindex>.<\/p>\n

    3.10. \u00bfC\u00f3mo se utiliza CoreXL? <\/h4>\n

    \nLa tecnolog\u00eda CoreXL, que permite usar m\u00faltiples CPU para instancias de firewall (m\u00f3dulos de firewall), definitivamente ayuda a optimizar el funcionamiento del dispositivo. Primero, el comando fw ctl affinity -l -a <\/b>mostrar\u00e1 las instancias de firewall utilizadas y los procesadores asignados para las necesidades de SND (el m\u00f3dulo que distribuye el tr\u00e1fico a las entidades del firewall). Si no se utilizan todos los procesadores, se pueden a\u00f1adir con el comando cpconfig <\/b>en el gateway.
    \nOtra buena opci\u00f3n es instalar     el hotfix <\/a><\/noindex>para habilitar Multi-Queue. Multi-Queue resuelve el problema cuando el procesador con SND se utiliza en muchos porcentajes, mientras que las instancias de firewall en otros procesadores est\u00e1n inactivas. Entonces, SND tendr\u00eda la oportunidad de crear m\u00faltiples colas para una NIC y establecer diferentes prioridades para el tr\u00e1fico en el nivel del n\u00facleo. Por lo tanto, los n\u00facleos de CPU ser\u00e1n utilizados de manera m\u00e1s eficiente. Las metodolog\u00edas tambi\u00e9n est\u00e1n descritas en sk98348<\/a><\/noindex>.<\/p>\n

    En conclusi\u00f3n, me gustar\u00eda decir que este no es el \u00fanico conjunto de Mejores Pr\u00e1cticas para optimizar el funcionamiento de Check Point, pero s\u00ed las m\u00e1s populares. Si desea solicitar una auditor\u00eda de su pol\u00edtica de seguridad o resolver un problema relacionado con Check Point, no dude en contactar a sales@tssolution.ru. <\/p>\n

    \u00a1Gracias por su atenci\u00f3n!
    \n
    Fuente:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435, \u043a\u043e\u043b\u043b\u0435\u0433\u0438! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u043e\u0431\u0441\u0443\u0434\u0438\u0442\u044c \u043e\u0447\u0435\u043d\u044c \u0430\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u0443\u044e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u0432 Check Point \u0442\u0435\u043c\u0443 \u00ab\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f CPU \u0438 RAM\u00bb. \u041d\u0435\u0440\u0435\u0434\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u0438, \u043a\u043e\u0433\u0434\u0430 \u0448\u043b\u044e\u0437 \u0438\/\u0438\u043b\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442 \u0441\u0435\u0440\u0432\u0435\u0440 \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044e\u0442 \u043d\u0435\u043e\u0436\u0438\u0434\u0430\u043d\u043d\u043e \u043c\u043d\u043e\u0433\u043e \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432, \u0438 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u043a\u0443\u0434\u0430 \u043e\u043d\u0438 \u201c\u0443\u0442\u0435\u043a\u0430\u044e\u0442\u201d, \u0438 \u043f\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0433\u0440\u0430\u043c\u043e\u0442\u043d\u0435\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0438\u0445. 1. \u0410\u043d\u0430\u043b\u0438\u0437 \u0414\u043b\u044f \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0437\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430 \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u043a\u043e\u043c\u0430\u043d\u0434\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39416,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39415","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Check Point: optimizaci\u00f3n de CPU y RAM | ProHoster","description":"\u00a1Hola, colegas!","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","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\udd47Check Point: \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f CPU \u0438 RAM | ProHoster","og:description":"\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435, \u043a\u043e\u043b\u043b\u0435\u0433\u0438!","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","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":"2019-10-31T19:32:08+00:00","article:modified_time":"2019-10-31T19:32:08+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39415","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":"2026-01-24 01:55:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:50:24","updated":"2026-01-24 01:55:21","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\/39415","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=39415"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39415\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/39416"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=39415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=39415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=39415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}