 Buenas. Bueno, vengo con esto porque yo vengo de Canarias y aquí hace un pelete de narices. Bueno, ya más o menos me han presentado, no voy a perder mucho tiempo porque para lo que tengo que hablar no hay mucho más que decir. En 2015 empecé a trabajar en Sucuri y a partir de 2019 ya empiezo a trabajar o estoy trabajando además en la gestión del equipo de IT de Goda de España. Sucuri es una empresa americana que se dedica al tema de ciberseguridad web. Voy a pasar un par de minutitos rápidos para decirles o explicarles exactamente qué es la ciberseguridad web. La mayoría de la gente me dice, pero tú puedes hackear servidores y tal. Tengan en cuenta que Sucuri pasó a formar parte de la familia Goda de a partir de 2017, pero se fundó en 2008, ha tenido un crecimiento muy grande y la verdad es que una de las cosas interesantes es que somos un equipo remoto que estamos a lo largo de 25 países. Hice una ponencia en la WordPress Zaragoza en la que explicaba un poco sobre tema de backdoors en general. Me puse un par de ejemplos y una de las feedbacks que me dieron es que les interesaba saber cómo había llegado yo a descubrir esa backdoor o una de las backdoors que estábamos hablando en esa ponencia. Entonces monté esta que va a ser una ponencia que tiene una parte técnica, espero que no se aburran, voy a contarles algún chiste a ver si consigo que se ríe un poco mientras aquellos que se aburran. Así que bueno, a este caso le hemos llamado el caso a 18682 y vamos a empezar primero por intentar ponernos en la mente de un CSI que al final es lo que hacemos, por lo menos en Sucuri o todos los que somos analistas de ciberseguridad, ¿de acuerdo? Por ahora, si me meto un poco en el... no sé si imagino que habéis visto CSI y Las Vegas, ¿cuál era el otro? Miami, ¿no? Pues me metería un poco yo en el rol de Grison o de Horatio y en fin, lo que voy a intentar ahora es transmitirlos a ustedes que están un poco empezando en este mundillo o vamos a hacer un poco ese juego de rol. Una serie de conceptos que son importantes para entender esta parte, ¿de acuerdo? Bien, lo primero es hablarles o decirles que obviamente cuando hablamos de ciberseguridad son datos muy sensibles, son contenidos sensibles y lo que quiero intentar transmitirles es que muchos de los datos que están aquí están tratados, nunca más haber dicho, para que no refresque la realidad, ¿de acuerdo? También otra cosa, yo no siento cátedra, esto lo cojo de la charla de Joanca que además es muy interesante, no siento cátedra, es decir, lo que yo digo soy responsable pero no de lo que ustedes interpreten, ¿vale? Así que en cualquier caso, cualquier duda que tengan siempre consultarlo con un especialista en ciberseguridad. La primera cosa importante que hay que hablar es la diferenciación entre hacker y ciberterrorista. Lo típico, todo el mundo dice los hackers y eso es lo malo, no. Un hacker es una persona que va más allá de un objetivo establecido. Pues si ustedes toman café por las mañanas para despertarse, están autohaqueándose, ¿vale? Para que vean hasta qué punto es una tontería el tema de hacker. Lo que nosotros vamos a hacer es una diferencia entre el hacker y el ciberterrorista que es aquel que hace algo para su propio beneficio o para el perjuicio de lo demás. Un poco para agilizar el tema, le llamamos el hacker malo, el criminal, ¿vale? Y en la analista en este caso es el CCI. Bien, vamos a hablar una cosa muy rapidita sobre qué es un abagdor, rapidito en cuestión de conceptos, ¿vale? Un abagdor es una pieza de código cuyo objetivo es permitir o bien una ejecución de comandos en remoto, o bien un acceso no autorizado a un sistema, en este caso un WordPress que es lo que estamos hablando en este evento, ¿no? Es importante entender que lo hace saltándose los protocolos de seguridad, es decir, no tiene mucho sentido que para yo ejecutar un comando pues me pide a mí una notificación. Si yo soy un hacker o un criminal, un hacker malo, quiero ejecutar algo en un WordPress, quiero saber cuál es la contraseña de la base de datos, extrayéndola del USB config, pues no tiene sentido que además me pide la contraseña, lo importante es que se salta los protocolos de seguridad. Lo importante además también es que las backdoors no existen en el aire, no es algo que se infecte, tienen que ser introducidas primero en un sistema, ¿de acuerdo? Entonces yo no voy a hablar de exploits, que es el nombre o el término con el que conocemos los procesos por los que se incorpora un abagdor dentro de un sistema. Sólo voy a hablarles de lo que una vez incorporado está abagdor dentro de un sistema, ¿qué pasa? ¿Cómo se puede introducir un abagdor? Pues bueno, ya sea por ingeniería social, lo típico, es que no me quiero gastar dinero en este plugin porque no quiero por lo que sea. Me veo lo bajo de la red de Mule, no sé si son muy viejos, o de cualquier página de Descárgate en plantorrents, o lo que sea, ¿de acuerdo? Esos fake plugins a veces vienen incorporados con regalo, ¿vale? Nadie da duros a cuatro pesetas. Bien, una vez que sabemos más o menos esto me gustaría invitarles a que alguien me dijera que es este código. Así, a primera vista, no sé cuánto domina es código de PHP, pero es un comentario de una licencia GNU, ¿vale? Es un comentario de una licencia, digamos, es un típico fichero de licencia. Aquí está en plano, aquí está coloreado. Cuando coloreado le ponemos, dijimos, oye, estos códigos PHP vamos a incorporar lo que es un comentario con su color habitual. Si vemos en el mapa, vemos que hay dos cosas que no están coloreadas. Es decir, si hay un comentario, el comentario acaba y empieza un código, ¿vale? Este fichero, que es una licencia totalmente normal, tiene incorporada, si no lo ves de manera coloreada, un abactor en la que te extrae un contenido que le pasas a través de una cookie y además después te lo ejecuta. ¿Vale? Tan sencillo como esto. Y no lo verías si no te molestas en hacerlo. Entonces, una de las cosas importantes cuando te dedicas un poco al tema de análisis de seguridad en la parte de policía, no? Es que tienes que entender cómo piensa un criminal, ¿vale? En este sentido pues un poco aplicar los típicos conocimientos de la arte de la guerra. Para defendernos primero, tenemos que saber cómo nos atacaríamos, ¿vale? Lo primero es, oye, mi sitio es seguro, pues primero, ¿cuál es la debilidad de nuestro sitio? ¿Cuáles son las que yo aprovecharía? Otra cosa, a más puertas y ventanas, más difíciles de proteger una fortaleza. Esto traducido a la art God Wordpress significa a más plugins, a más temas, a más cosas, más accesos posibles, ¿vale? Déjense en cuenta que los temas los desarrollan personas, los plugins los desarrollan personas y el humano. ¿Cómo era la frase aquella, no? Errar un humano en esto. Después está el término de la cadena de confianza. Necesitamos confiar en los distribuidores. No vamos a hacerlo todo a mano desde cero nosotros. Con lo cual al final siempre usamos software de terceros. Tenemos de alguna manera que utilizar lo que llamamos la cadena de confianza y hay que entender que tenemos que confiar en que el código que viene está bien. Bien programado, no tiene nada adentro, etcétera. Es necesario, ¿vale? Bien, ¿qué objetivo son los más típicos dentro de un entorno Wordpress? Usuario, base de datos, información, usar la propia estructura para un ataque, usar tu estructura como un nodo de ataque o un nodo de uso para un salto o incluso usar tu reputación o hundirla, ¿vale? Aquellas personas que usan mucho SEO o se dedican al tema de SEO y demás saben el trabajo que significa, sobre todo si trabajan en SEO orgánico, el trabajo que significa mantener una reputación en los buscadores, ¿de acuerdo? Bien, hasta aquí más o menos conceptos generales importantes. Vamos a entrar en la parte chunga. Voy a intentar hacerlo lo más a menos posible. Vamos a meternos de nuevo en la... en la piel de un CSI. Llegamos a una escena del crimen y le voy a explicar en qué consiste esa escena del crimen y le voy a explicar los pasos que se se llegó para detectar el problema. La escena. Vemos un Wordpress que ya ha sido tratado por lo que se ve, con esos ficheros y esas carpetas por ahí. Si se fijan, los que tengo seleccionados son ficheros y carpetas con nombres medio random, ¿de acuerdo? Y nos hemos dado cuenta anteriormente, en este caso, que eso contiene spam, ¿de acuerdo? Entonces el sitio del cliente está lleno de spam. Ya no hablo de los aspectos que están un poco más abajo, sino por ahora vamos a centrarnos en los que están seleccionados. ¿Qué pasa cuando una página está llena de spam y además Google ya lo ha indexado? ¡Oh! Que tu SEO baja. Y no solo baja, sino que en muchos casos te eliminen del Google Rank. Eso puede significar, en muchos casos, que el cliente será mejor hasta dos años de trabajo a la basura. Y en este caso concreto, además, se daba que el cliente se le trataba, se le arreglaba y, además, volvía otra vez a reinfectarse y volvía a pasar lo mismo. Entonces, evidentemente, esto generaba una frustración bastante importante del cliente. Entonces, cuando nos llega este caso, es evidente que solo limpiar no tiene sentido. Vamos a investigar qué es lo que pasa. Aquí algo huele mal. Esto es un ejemplo. He intentado tachar un poco la información sensible, pero vaya, es una página que pretende ser una, en este caso, una página de contacto. Como ven, tiene introducido un banner de compra de Viagra, que no sé cuánto lo habrás visto en Internet, pero son de los más típicos de spam que encontramos por ahí, ¿de acuerdo? Típica imagen. Esto es como si tomáramos fotos de la escena del delito. Típica imagen que nos pasa cuando... no sé si alguno le ha pasado, alguno le ha pasado que levanten la mano, alguno le ha pasado que le han hackeado la página y Google les ha dicho, bien, veo que es bastante habitual. Bien, pues esta es la típica imagen, digamos, del horror, cuando no conoces mucho de este mundito, y Google ya ha detectado que tienes un problema. Entonces, de repente le dice a todos tus clientes, a todos tus visitantes, que tu sitio está infectado. Es más, apareces en los buscadores, así he puesto ejemplo, este sitio igual está hackeado, ¿eh?, que lo sepas. Vale, esto es un poco eso, la galería del horror de la... de cualquier persona que tiene un negocio basado en este tipo de... de... de páginas como web. Bien, diagnosis. Lo primero que intentamos evaluar es qué pasa en este sitio. Primero, no tiene un WAF, ¿vale? No tiene un firewall de aplicaciones... de web, ¿vale? Los scripts que tenemos de limpieza, ya sean los que usamos en su curio, los que son ustedes libres en sistemas, o los que usan por los antivirgos. Bueno, limpian clas y han detectado incluso cosas en los plugins y en la página, digamos, en la raíz, que es ahí. De hecho, estos ficheros suspected, que están ahí, que no están seleccionados, son ficheros que han sido renombrados por plugin de seguridad, ya de por sí, ¿vale? Pero no los hemos hecho nosotros. Y además, sin hacer... haber hecho un análisis forense, se ha determinado que se limpia el spam, que se detecta que hay un problema con alguno de los plugins que está desactualizado y se dice que ese es el vector de acceso de infección. Pero, en el caso concreto, una vez que lo hemos tomado y no hemos visto que, evidentemente, no es sólo eso, no hemos dado cuenta de una cosa importante. Ficheros core están cambiados. ¿Qué son los ficheros core? Los ficheros principales de un WordPress. Es decir, aquí hay ficheros que no deben cambiar ustedes nunca. Todos aquí están dentro de WP Admin, todos los que están dentro de WP Includes, el index, por ejemplo, etcétera, ¿vale? Entonces, cuando un análisis o un scanner te canta que uno de esos ficheros o una de esas carpetas ha sido modificada, ¡zaz! Problemón. Vamos a ver el index, que es el que nos canta que tiene un problema. Vemos este fichero index que, si lo habéis visto en algún momento, debería estar ya más o menos en vuestra mente lo más clásico, ¿de acuerdo? El index PHP. Sin embargo, eso que tengo seleccionado ahí arriba es un poco raro. De hecho, cojo el original y lo comparo. Si se fijan ahí, hay al menos tres líneas más de código que no debería estar. ¿Vale? La comparación rapidita. Bien. Vamos a lo que hago es recuperar una copia anterior de la limpieza para ver qué es lo que había ahí. Y me encuentro con que había una línea donde había un Include con un código ofuscado. ¿Bien? Digo, oye, pues aquí esto debe ser interesante. Si lo ha limpiado nuestros plugins de seguridad o nuestros scripts, está claro que se ha sido detectado, pero como vemos que el problema sigue existiendo, pues vamos a intentar desenredar un poco más la madea. Bien, traducimos eso y vemos que el Include realmente es una dirección de un fichero llamado Fabicón con un numerito puntoico. Para aquellos que saben un poquito de código o saben un poquito de desarrollo web o incluso de diseño, un Fabicón nos permite poner el iconito arriba en un navegador, en el tab del navegador. Normalmente alguien que ve un Fabicón con un numerito random pues ya podemos quedarse, pero bueno, puede haber algo de caché o algo entre medias que lo renombra. Vemos esto, muy bien. ¿Cómo he llegado hasta aquí para aquellos que tengan curiosidad? Pues simplemente con una consola directamente utilizo una sección interactiva, cojo y lo le metemos un hecho un echo en PHP para que esto lo traduzca y esto es lo que sale. Simplemente para aquellos que tengan un poquito de curiosidad. Además utilizo o puedo utilizar un scanner como amphp.net que os lo recomiendo si tenéis algún código o lo que sea que no es claro que está enfoscado o lo que sea si queréis volverlo leíble, no todos, pero lo metéis aquí, lo decodifíca. Bien, volvamos al ficherito ese que salió en nuestro código. El favicón este dichoso. Vamos a abrirlo. Único debería ser una imagen. Sin embargo, no vemos este código, ¿de acuerdo? No voy a burglar demasiado, pero este código evidentemente no es una imagen. ¿Vale? Si se fijan, además tiene nombres bastante random y tal. Voy a hacer un pequeño rapidito repaso para aquellos que le gusta el código. Hay unas varias secciones. Un segundo, fuera de ejecución. Un código sucio en base de 64 ¿Por qué digo sucio? Porque si usted intenta decodificarlo en base de 64 le va a decir que eso no tiene sentido. Entonces, hay algo ahí que no cuadra. Justo debajo hay una clave de sustitución. Oye, donde encuentras un 1 pongo una E, donde encuentras un 0 pongo un 9, donde encuentras un 3 pongo una A mayúscula. Donde es un 2 una S mayúscula, etcétera. Eso es una clave de sustitución. A partir de ahí, vale, tenemos una función que además mezcla la clave, coge el código sucio, sustituye los valores y tenemos que decodificarlo. Y tenemos el código el código limpio. Yo tengo aquí, el código limpio. Vale, a partir de ahí, decodificamos ese código limpio y tenemos un código en general. Código malicioso. Además, notamos cuenta que dentro de ese código hace uso de un comentario. Algo que casi todo el mundo pasaría por encima hasta todos los escáneres de seguridad es que cuando hay algo que está comentado no es disputable para que lo vamos a estar mirando. Sin embargo, el código que sacamos de aquí arriba hace mención al código que estaba abajo comentado. Entonces, es bastante interesante. De hecho, el código que está abajo es la backdoor de verdad. Todo lo demás es simplemente un sistema para engañar a nuestros plugins de seguridad. Vale, pues así un poco en plan rápido, la estructura que acabo de definir es esta, pero quitando nombres y poniéndolo todo más o menos bonito. No voy a entrar a más detalles de esto. ¿Qué herramientas he utilizado para llegar hasta aquí? Hasta este punto. Aparte del Amphp, que les he comentado y la propia consola, que la podéis usar cuando queráis, a que tenéis algunas herramientas y escáneres que deberíais utilizar siempre que queráis empezar a entrar en este mundillo o empezar un poco a chequear cosas. ¿Vale? A la izquierda herramientas de codificación base 64, el típico código este que te viene todo en una sola línea de JavaScript y no lo entiendes, pues hay beautifiers que le llamamos, que lo hacen leíble y después, bueno, en su query tenemos un decodificador que lo podemos usar si quiere. Y a la derecha tenéis escáneres en caso de mi página está hackeada, pues mira, lo puedo chequear con el side check. Si te sale ahí que no está hackeada, no significa que no lo esté, significa que visualmente de primeras no lo parece, ¿vale? Pero si le dice que sí, sí quiero estar. Performance les ayuda un poco a medir el rendimiento de vuestra página para ver si va rápido o no va rápido a lo largo de todo el mundo. Y, bueno, lo que vamos a hacer es echarle frente a Blacklist o listadas negras, ¿de acuerdo? Web page test es una escáner que les permite ver exactamente qué se está cargando en cada momento y cuánto tarde. Vale, bien, pasamos al siguiente. Evidentemente hemos llegado hasta un código malicioso de un abagdor y desenredando el proceso que tiene varias fases, llegamos hasta un punto en el que vemos una serie de opciones que son básicamente Section A. Si le pasas una variable A infectas con Spang. Si les metes una variable B eliminas el abagdor. Si le metes una variable C infectas con un plugin fake. Si le metes una variable D, etcétera. Tienes con varias opciones. Y aquí en esta parte particular les comienta además, les hace una especie de chequeo en el que dice, oye, eres Facebook, oye, tienes un agente que es alguno de estos pues no quiero saber nada de ti. Para todos los demás, conectate a esta IP y a este fichero. ¿Esto qué significa? ¿Cuál es nuestra conclusión? Significa que este sitio particular ha sido infectado como un node de una botnet. ¿Qué significa eso? Que para que este backdoor funcione tiene que estar conectado a un engine PHP que lo vemos aquí en esta imagen en Java PHP y eso está en alguna IP, en un sitio donde hay un sitio, una persona que tiene un dashboard con todos los sitios infectados y dice, oye, voy a coger este rango de sitios infectados y los quiero meter con spam. Y a este rango quiero que ataquen todos a esta IP, etcétera. O sea, que el sistema ya de seguridad se está llevando al... O sea, la parte de chequeo de criminal se está llevando hasta un nivel hasta que lo puede manejar cualquier persona. Entonces, esta conclusión que nos da es que tiene una habilidad 0day, es decir, la tienes infectada en tu ordenador pero se puede activar cuando a uno le dé la gana. Pertenece a una botnode. Además pueden ser opciones configurables como les comentaba antes, entre otras espamearlo, llenerlo de spam. Y además pues tiene acceso a un dashboard donde pueden ser manejados. Pan. Y es un ficherito eco escondido. Bien, yo sé que a ustedes interesa demasiado. Para mí que soy una pasionada de este mundo a mí ver un icono convertiendo tu sitio en un botnode es como wow. ¿Vale? Y a ustedes cuanto menos, lo que me gustaría que se sacaran de aquí es que tengan cuidado. Bien, dos cosillas así rapiditas sobre cómo evitar que esto nos ocurra. Esto más o menos siempre me gusta comentarlo. La seguridad 100% no existe. ¿Quién le diga que WordPress es seguro 100%? No voy a decir que miente, hombre. Pero vaya. No está siendo exacto. ¿Qué significa esto? Desde el punto de vista de que WordPress o cualquier código lo hace un humano y los humanos fallamos ya es imposible 100% de fiabilidad. Para que esté seguro debes tener en cuenta siempre la seguridad por capas. Es decir que instalo un plugin y sois 100% seguro o instalo su query y ya lo tenemos todo solucionado o instalo WordPress y ya está, esto es un crack, no. Va por capas y resulta que la capa de arriba es la más débil de todas. ¿De acuerdo? ¿Qué es el social hacking? Lo típico que te llega un correo y te dice oiga, mira que estamos cambiando la política de privacidad de PayPal y necesitamos que usted se logue aquí, pinche aquí, vas te logueas, ponen tu sobreconto a señas que está todo ok y ya está, ahí te vas a casa tranquilita. Lo que no te atada cuenta es que la página que has cargado no es PayPal y que alguien se ha quedado con eso tanto. Y a partir de ahí, desde tu o de tú como persona tu dispositivo, la conexión la página, el firewall, los creenciales y la última cosa que parece que nadie entiende que nadie, o sea una vez que ya las cubre todas dice ya estoy seguro, es que una vez o de vez en cuando, no, hay que hacer un mantenimiento constante, no se olviden que cualquier página web, cualquier WordPress que ustedes tengan, cualquiera puede ser utilizado por ejemplo en una botnet por un fabricón. Así que hay que mantenerse siempre al tanto. ¿Cómo descubrimos esto? ¿O cómo conseguimos encontrar cuando esto nos pasa? Los escáneres de integridad esto no sale en side check no sale en los escáneres que vas a encontrar gratuitos en las calles que vas a salir solo y exclusivamente cuando tengas un escáner o un hosting que por detrás tenga un sistema de escáner de integridad de ficheros. ¿Qué significa eso? Oye, te informo que este fichero acaba de ser añadido por alguna razón a esta carpeta pero tiene que haber alguien que lo esté mirando. Eso genera muchísimo ruido pero es la forma más útil de encontrar todo el tema de la pack door y demás. Los plugin ayuda, pero no son determinantes. Lo más importante, el escáner de integridad hablamos de back doors. Hay muchos otros tipos de amenazas. Bien, me gusta decirlo repetirlo y más que repetirlo la pack apps. Hace poco fue el día mundial de la pack apps. Eso que tanto echamos de menos cuando nos hace falta y nunca hacemos porque son un engorro. Utilizan servicios externos que no les quite tiempo. Y otra cosa importante, nunca bajo ningún concepto, ni aunque se lo digan que es normal almacenen sus copias de seguridad en el propio server donde tengan la página web. ¿De acuerdo? ¿Nunca? ¿Por qué? Porque utilizar una copia de seguridad con plugins desactualizados dentro de esa copia de seguridad es posible. Y normalmente las copias de seguridad están ahí al infinitum. ¿Vale? Y otra cosa también importante, una vez que hagas copias de seguridad prueba hacer una restauración a ver si pirula. ¿Vale? Porque muchas veces ocurre que oye, sí, tengo copias de seguridad, pero vamos a... Con chales está corrupto, no puedo abrirlo ni de ninguna manera. Es decir, por eso es un rayo funcional. ¿Cómo sabemos si es funcional? Restauren, a ver qué pasa. Creo que no tengo que decir nada. Muchísimos administradores del sistema dicen, no, pero es que actualizaremos una puñeta porque, claro, me tira la página abajo. ¿Vale? Es posible, pero ese riesgo es mucho menor que el hecho de no actualizar por evitar eso y que te infecten tus páginas. Si tu página se cae porque la actualizas y está mal porque has pasado de WordPress 49 a WordPress 51 y resulta que hay un plugin ahí que no es compatible con Gutenberg pues arreglarlo. Pero si ese arreglaro te va a salvar mucho más tiempo que si te haquean y mucho más dinero. Lo último es hablar de mi amigo Waf. Un perro de guarda. Yo siempre hago este chiste, pero nadie lo coge y es que suena como un perro cuando dice Waf, ¿vale? Un Waf es un Firewall Application Web Firewall, ¿vale? Y funciona así. Es decir, es un Firewall no el típico que distale en los antivirus es un Firewall exclusivamente para vuestra web que es lo que hace, oye, entra todo tu tráfico por un lado pero en vez de ir directamente a tu página pasa a través de lo que yo llamo para que la gente lo entienda más fácil un túnel de lavado. Entonces, en este túnel de lavado analizamos esas conexiones que entran en tu página si vemos que hay una que está atacando un Fabicón con un numerito.ico y la gente lo evita. Dice, no, esto no se puede. O, yo qué sé, intenta atacar una vulnerabilidad típica que ya conocemos todo de Revolution Slayer o de algún otro plugin y lo evita, ¿vale? Por eso el Firewall de aplicaciones es muy interesante. Si todo va bien, llega a tu página y ya está. Bueno, para terminar dos reflexiones así rapiditas para los que no más o menos no dominen el inglés este señor que es el director ejecutivo de Cisco ¿vale? Tiene una frase que es muy interesante. Dice, solo hay dos tipos de empresas aquellas que han sido hackeadas y aquellas que aún no saben que han sido hackeadas y todo el mundo necesita un hacker, ¿vale? Eso de hacker malo intenta tener cuidado con cuando lo dicen hackear es lo mejor que podemos hacer todos los días y hacer que nuestros hijos hackeen o nuestras familiares hackeen cosas estimula la humanidad en general. Vamos a ir con dos preguntas breves y con respuestas igual así todavía lo aprovechamos. ¿Vas a estar en el happiness bar? Ya estuve, pero estaré por ahí igualmente. Vale, y estás todo el día con nosotros. Lo podéis pillar, lo acribilláis que él se deja. Vamos con la primera pregunta. Hola Néstor, muy buena charla. Quería preguntarte aprovechando lo que ponen tu camiseta por los análisis automáticos de ProSites los premios de la funcionar. Esa parte no te la puedo contestar yo. Yo trabajo en el departamento de goda de security hasta donde yo sé no trabajamos con la parte de ProSites por ahora. ¿Vale? No tengo claro si trabajan con Side Lock o utilizan algún otro plugin por detrás. Si somos nosotros te puedo decir que funciona. Pero todavía no te podría contestar esa pregunta. Cuando hablas de los WAF ¿puedes dar algún ejemplo? Es un servicio que se contrata. Es un plugin. Un WAF es un servicio. Hay plugins que ya te vienen con ese servicio instalado. Uno de ellos el WAF este que particularmente nombrado aquí es cómo funciona la red de Sukuri. El WAF de Sukuri que antes se llamaba Cloud ProSites. Funcionan todos más o menos igual. Cloudflare creo que tiene uno. Warfans creo que tiene otro. Son servicios porque lo que hace es al final es modificar la TNS de direccionamiento de tu web. Solo de tu web no de e-mail ni nada. Solamente la WWW aquellos que pasan por el porto 80 en 443 y pasan a través de un IP donde hay un sistema que limpia esas conexiones. Entonces es un servicio realmente. Aquí hay una por aquí. ¿El qué? Bueno, en el caso concreto no sé otros porque no los he testado pero en el caso concreto del WAF de Sukuri es que además viene con un CDN. Entonces viene con una capa de caché que lo que hace es precisamente hacer una copia de todo tu sistema alrededor del mundo y lo que hace es acelerarlo por un lado. Pero la verdad es que no hemos notado realmente una realitización realmente en el proceso. O sea, seguramente la habrá muy pequeña pero yo de hecho si haces los performance utilizando el performance.sukuri.net o cualquier otro tipo de performance que hay por ahí y lo haces frente a tu web directamente o frente al WAF de Sukuri y verás que va mucho más rápido con el WAF de Sukuri. Muy cortado. En el caso de un hosting multisitio es necesario instalar el WAF en cada sitio o con hacerlo en el principal CDSW. En el principal es suficiente. Vamos a darle un fuerte aplauso a Néstor Angulo, por favor.