Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
me gusta lo que mencionas de tener preocupación por la privacidad. Si no me quiero preocupar por mi privacidad, cuando tenemos un sitio web y tenemos usuarios, tenemos la responsabilidad de proteger la privacidad de nuestros usuarios. Esa responsabilidad cae sobre nosotros. Si a mí me da igual qué hacen con mi información,
no puedo pensar de la misma manera de mis usuarios eso sería irresponsable entonces tenemos que definitivamente asegurar y los tips que hemos dado hasta el momento van agregado, van en esa línea,
Juan (00:25)
Mm-hmm.
Douglas (00:38)
Hola a todos y bienvenidos a Dev & Ops. Este es su espacio favorito en el que hablamos de desarrollo, tecnología, DevOps y su cultura en general. Y hoy, como siempre, me encuentro con mi gran amigo y co-host, Juan Ramos. Juan, bienvenido a este episodio. ¿Qué tal estás hoy?
Juan (00:58)
Hola Douglas me encuentro muy bien el día de hoy, gracias a Dios. Tengo salud, todo bien en casa, no hay problemas hasta el momento y esperemos que así sea. Y me encuentro muy alegre por el tema de hoy que es un tema que siempre me interesa, que veo yo a los mis compañeros cuando trabajan en esta área y yo siempre ando curioseando y preguntando cosas pero igual, tengo muchas cosas que aprender todavía.
Douglas (01:26)
Sí, qué bueno Juan, qué bueno y esa curiosidad es la importante, esa curiosidad es la que nos hace crecer como profesionales, sobre todo en este rubro, el momento en que perdamos esa curiosidad yo creo que nos vamos a estancar mucho y pues qué bueno, qué bueno y para ir avanzando entonces con el tema ya que lo mencionas Juan, lo que hoy queremos hablar es dar tips o ideas de cómo asegurar o proteger una aplicación web.
desde la perspectiva en este episodio desde la perspectiva de un SRE o un sysadmin
para SRE o sysadmin para proteger una aplicación o sitio web. En el próximo episodio Juan vos nos vas a llevar y guiar un poco más a dar tips pero desde el lado de desarrollo. Ahí vos se la vas a arreglar, vas a compartir tal vez algunos tips de backend que obviamente es tu área fuerte. No sé si nos vas a compartir tips de frontend pero bueno ya eso lo vamos a dejar ahí a tu criterio y obviamente pues
Juan (02:20)
jajaja
Douglas (02:32)
pues
por supuesto tus experiencias, ¿verdad? Y yo creo Juan que vale aclarar aquí que estamos hablando, el enfoque de estos tips van a ser aplicaciones y sitios web.
Algunos pueden aplicar para otro tipo de aplicaciones, ya sabemos que existen aplicaciones móviles, aplicaciones para escritorio, incluso puede ser una aplicación para un wearable, para un smartwatch. Hay diferentes tipos de aplicaciones para smart TVs, ⁓ hoy en día hasta las refrigeradoras son smart. Entonces existen todo ese tipo de aplicaciones y algunas cosas de repente pueden aplicar ahí, pero estamos en este enfoque de aplicaciones web.
Entonces quiero que la gente tenga eso en mente de que hacia ahí van dirigidos estos tips. Y muy probablemente la mayoría de personas que nos ven y nos escuchan y pues trabajan o están más interesados, muy probablemente en lo que tenga que ver con esas áreas de desarrollo de nuevo, aunque hay más. Pero Juan, entrando al tema, pues yo quiero que nos compartas ya los tips como tal, nos los vas a dar la próxima semana, pero en tu,
nos contó cuál ha tu exposición en esto que tiene que ver con seguridad de aplicaciones web. No necesariamente que te toca vos hacer la parte de seguridad, pero cuál ha sido tu envolvimiento, tu experiencia alrededor de ello.
Juan (04:00)
siempre que hablamos de seguridad de un programa o una aplicación
es algo que involucra a todo el equipo, creo yo y obviamente cada quien empieza a desarrollar soluciones y estrategias para cada una de esas áreas pero definitivamente es un tema que requiere que todo el equipo esté en sintonía y lo menciono porque en cuanto al desarrollo bueno hay muchas herramientas, muchas soluciones, muchos consejos que podemos dar pero siempre tiene que estar de la mano con lo que se está haciendo
en sysadmin sre por ejemplo yo una forma muy común de proteger tus endpoints y las urls que estás exponiendo al público es a través de un api key es una llave que en teoría no la tiene nadie más solo las personas o aplicaciones que a quienes le queremos dar acceso y eso en teoría tiene que también saberlo el
tipo de sysadmin y sre porque todo depende de como este configurado el sistema como este configurado ya sea el gateway y las diferentes capas que están alrededor de nuestra aplicación porque la aplicación al final del día pues está en un ambiente en específico y hay muchas handshakes que suceden en el proceso
pero bien, mi exposición ha sido de ese tipo donde me pongo en sintonía o me pongo de acuerdo con las personas encargadas del lado del servidor y luego en el lado de desarrollo nosotros tomamos nuestras decisiones ya sea API keys, rate limit, permisos, roles, todas estas cosas que podemos ir haciendo pero por ejemplo, ahorita que mencione el rate limit, eso es algo que se puede
hacer a nivel de la aplicación. Yo puedo decir que en mi aplicación, más que todo en el lado del backend, yo puedo decir, yo puedo configurar una cantidad de peticiones que yo espero tener en un determinado período de tiempo, pero también puede ser configurado a nivel del servidor o la instancia como tal, del container y todas estas... bueno, en Kubernetes ya hemos visto que se puede hacer de todo, ⁓
Así que eso hay que tenerlo en cuenta y saber si no estoy duplicando código, estoy duplicando esfuerzo o trabajo computacional que al final del día se traduce en coste monetario.
También hay ciertas soluciones cuando trabajamos por ejemplo con JWT con los JSON Web Tokens es muy común que recibimos un token y hay muchas formas de hacerlo. De nuevo tenemos que ponernos de acuerdo con todo el equipo. Una de las formas de hacerlo sin entrar en muchos detalles es que el servicio, el microservicio que recibió la petición se comunica con otro servicio externo que se encarga de validar.
o el mismo servicio que recibió la petición es quien valida el token como tal, la firma y hay muchas cosas, todas esas cosas, esos pasos o esas estrategias hay que tomarlas en equipo. Me parece que es importante mencionarlo Douglas porque
Bueno, en mi experiencia he visto que a veces muchos desarrolladores pues quieren implementar algo y están ansiosos por hacerlo, muy muy bueno en ese aspecto pero dejamos por fuera el hecho de cómo se va a realizar y no lo transmitimos correctamente al equipo. Me he encontrado por ejemplo con ciertos microservicios que tienen configuradas ciertas reglas de el course
He olvidado cuáles son las siglas realmente de course, pero bueno, básicamente es... No lo tengo en la mente realmente. De manera simplificada es los dominios o IPs de quienes estemos permitidos recibir peticiones, podríamos dejarlo por ahí. Alguien en los comentarios nos puede corroborar la definición correcta.
Douglas (08:00)
también, si me la preguntas hoy no la sé, pero sé muy bien a qué te referís.
Juan (08:22)
Bien, me he topado con reglas de course que no se apegan al resto de los servicios. Y eso no es que esté malo, pero no está... No fue comunicado de la mejor manera. Pero bueno, generalmente mi exposición con la seguridad ha sido así, Douglas. Y es algo que siempre trato de tener en mente. Es muy fácil pasarlo por de largo y no prestarle la atención necesaria porque es más fácil simplemente lanzar...
ya sea un micro service o un producto, pero es muy importante darle la import... la...
el peso que tiene la seguridad. Me refiero desde los permisos y roles de un usuario, cómo van a acceder. Hay que pensar en las diferentes situaciones de qué pasa si un usuario captura este token y nos ataca desde otro lado, qué podríamos hacer. O tal vez no es un ataque, tal vez un usuario hizo algo en el sistema que no esperábamos.
y eso se traduce en que ahora puede ver recursos que no debería. Por ejemplo, en el ámbito de los videojuegos, así es como se suelen hacer muchos trucos, empezar a hacer diferentes acciones que los developers no previeron y ahora esas acciones modifican la memoria de tal manera que les permite acceder a cosas que no deberían. Entonces siempre es importante...
pensar el peor de los casos, hay que prepararnos para el peor de los casos y tratar de actuar de esa manera y ponernos de acuerdo con todo el equipo.
Douglas (09:57)
Vos decís hacerlo como el QA. El QA usa la aplicación totalmente antiintuitivo y encuentra errores que uno dice, pero es que nadie va a hacer eso.
Juan (10:05)
Exacto,
Douglas (10:08)
Pero bueno, es el trabajo de ellos, Pero
obviamente me resulta gracioso. Me gusta lo que estás diciendo, porque en efecto, por eso yo quería saber tu opinión y cuál ha sido tu experiencia alrededor de asegurar o proteger una aplicación y sitio web, porque es un trabajo en conjunto. Vos mencionaste algo de que vos pudieras aplicar un rate limit a nivel de código si quisieras.
es posible, sin embargo, ¿es el mejor lugar para aplicar un rate limit? Lo más seguro es que la respuesta sea no. Y es ahí donde solo porque se puede, es mejor hablar con el resto del equipo, la contraparte, el de sysadmin, puede ser el de networking incluso, verdad. Si son dos departamentos diferentes, a ver si ahí es el mejor lugar. O a veces hay cosas que se pueden proteger en una capa, pero la capa que sigue puede hacer como un fallback, como una protección por si la de arriba
Juan (10:59)
Ok, sí.
Douglas (11:00)
fallan es menos fuerte.
pero ya solo está lista para capturar por si algo en la capa más arriba falla, etcétera, pero me gusta lo que está diciendo, al final se trata de colaboración y por eso queremos tocar este tema. Y entonces yo voy a aprovechar a compartir cuál es mi experiencia alrededor de asegurar y proteger una aplicación web o sitio web, por qué alguien debería de considerar los tips que quiero darles hoy en día. No me dedico a la rama de seguridad, no trabajo en seguridad.
Juan (11:15)
Mm-hmm.
Douglas (11:33)
seguridad. De hecho, de hecho en una empresa apropiada, correcta, idealmente todo lo que es el departamento de SIS Admin o SRI, lo que tiene que ver con infraestructura de sistemas, tiene que ser completamente separado de los departamentos de ciberseguridad, separados incluso a nivel de, a nivel gerencial.
Juan (11:58)
ok
Douglas (11:59)
A nivel alto, quien sea que reporte a los dueños o reporte a los ejecutivos, tienen que ser diferentes porque si yo soy el, digamos, un vicepresidente en tecnología y tengo a mi cargo el departamento de Sysadmin y también tengo a cargo el departamento de ciberseguridad, si el de ciberseguridad encuentra algo bien crítico...
y yo tengo que rendirle cuenta de eso a los ejecutivos o a los dueños, en ese momento yo soy juez y parpe, puede que quieran cubrir algo, puede que digan, ⁓ quitemos esto para que no lo miren y lo corregimos luego, verdad, entonces no es correcto. Idealmente tienen que ser totalmente separados donde ya a quien se le rinde cuentas que hasta ahí sea alguien que es, porque el dueño pues tiene que ver todo, ¿no? O los ejecutivos altos.
Juan (12:26)
Mm-hmm.
Douglas (12:49)
un CEO, CTO, etcétera, pues ya él sí tiene que ver todo, pero que sea que hasta llegar ahí sea el mismo jefe, de lo contrario no, entonces esto es una mejor práctica de hecho y es por eso que yo no me dedico a ciberseguridad, sin embargo...
Juan (13:05)
Necesitamos una autonomía,
básicamente, dentro de la empresa, ¿verdad?
Douglas (13:08)
Si una autonomía, además que yo no tenga tacto o nada que me preocupe o me ate en decir yo voy a decir que la aplicación tiene esta vulnerabilidad, si esto expone a Juan lo siento, no es mi culpa, no lo estoy haciendo personal contra Juan.
Juan (13:17)
Ok
Es culpa de él.
Douglas (13:24)
si es culpa de él
o yo estoy enfocando en la aplicación y yo voy a decir la aplicación tiene esto, eso hace que yo no tenga ningún interés propio en querer hacerlo bien si no está bien. Al final eso lo que buscas, que la persona que exponga estos problemas de seguridad no tenga ninguna preocupación o ningún interés en reportar que las cosas están bien cuando no lo están, ¿verdad? Y ese es el objetivo, ese es el punto.
Y en mi caso, si puedo mencionar, bastante experiencia protegiendo aplicaciones. Por ejemplo, he sido encargado de que los sistemas que yo he corrido, que son muchos, a vos te consta sean, por ejemplo, PCI Compliance. PCI es un tipo de Compliance, es un tipo de estándar que tiene que cumplir tu infraestructura. Nosotros corríamos en data centers propios.
para que a la empresa le permitieran hacer transacciones y cobras de tarjeta de crédito, porque la empresa no tenía un servicio externo para tarjetas de crédito, o no se pegaba a un API del banco para tarjetas de crédito, sino que lo hacía ella misma, era su propio, ella desarrollaba y mantenía su propio servicio de cobras de tarjeta de crédito.
Juan (14:42)
propias trajes.
Douglas (14:43)
Su propio Stripe, si lo queremos explicar de una manera simple de explicar, de ilustrar, perdón, y entonces había que pasar este PCI Compliance que un agente externo, una compañía externa nos hacía scans, nos mandaba las cosas que se encontraban vulnerables, paquetes, a todo nivel, desde el nivel de web server hasta el nivel del sistema operativo, y nosotros nos encargábamos de mantener que todo eso estuviera bien.
Y a medida progresamos, cada aplicación nueva, ya no éramos solo reactivos ante un scan, sino que éramos, preveníamos porque ya sabíamos esto es una vulnerabilidad, a tal tecnología le tenemos que cubrir este endpoint, tenemos que aplicar un rate limit aquí, etcétera, etcétera, etcétera. Entonces, sí tengo mucha experiencia protegiendo aplicaciones web. Además, en general, lo que estamos en Sysadmin en SRE, no podemos entregar una aplicación
vulnerable, no podemos usar la IA a la ligera porque nos puede dar algo lleno de hoyos y de fallas donde un hacker pueda pasar, alguien malicioso pueda pasar caminando.
Juan (15:49)
Uno creería
que así es.
Douglas (15:52)
Si uno creería, y eso siempre ha existido, nunca ha sido de solo copiar y pegar el código de Stack Overflow, nunca ha sido así. Solo porque alguien lo probó y le funcionaba, no significa que hacía bien. Entonces ocurre lo mismo con la IA. Y lo que estamos en CSAT en SRE, estamos obligados a que nuestras aplicaciones...
Juan (16:05)
Sí.
Douglas (16:13)
sean seguros, hoy en día trabajo para clientes grandes en la industria y ellos se encargan de cumplir normas serias, es más, a mí me toca estar haciendo training de seguridad cada tres, cuatro meses y varios de esos trainings porque si le trabajo a, le trabajo a Uber, entonces Uber quiere que yo pase ciertos trainings cada tres meses, cada seis meses, aunque sea lo mismo, pero ellos necesitan que yo lo pase y lo mismo quiere que haga GoDaddy.
Juan (16:35)
ok
Douglas (16:42)
cuando les trabajo y lo mismo quiere Microsoft y lo mismo quiere Salesforce, si así. Entonces, en realidad que yo paso recibiendo trainings muchas veces al año, aunque sea más de lo mismo, pero es por esa razón que sí tengo mucha experiencia protegiendo aplicaciones y páginas web, ¿verdad? Entonces, habiendo dicho eso, Juan, no sé si te parece que entremos de un solo a los tips que quiero dar.
Juan (16:42)
jajaja
Douglas (17:10)
para proteger aplicaciones y sitios web ¿Te parece?
Juan (17:15)
Me parece muy bien, sí.
Douglas (17:17)
OK, OK. Entonces entrando al primero, yo siempre lo miro, la forma en que afronto esto, yo miro siempre desde la capa más alta hacia abajo porque eso me permite visualizar el flujo de los requests, el flujo de los llamados.
Usualmente, mira que interesante, usualmente comenzamos configurando las capas bajas, no? Comienzo configurando el servidor web, el hosting o comienzo configurando el clóset de Kubernetes y a medida voy configurando, sí, voy aplicando reglas de seguridad. Sin embargo, pienso en cómo vienen las peticiones desde arriba, desde que las hizo el usuario y cómo van bajando.
para tratar de ir capturando esos huecos que pudieran quedar en seguridad. Entonces, es por esa razón que los tips los voy a dar, no desde la capa de abajo hacia arriba, sino que al nivel contrario, como se origina el request desde el usuario hasta llegar al servidor donde están las cosas, ¿verdad? Y el primer tip es simple y sencillamente comenzar con el Edge. Sería implementada en toda aplicación o sitio web.
un WAF, un servicio de proxy encima que te proteja, que te permite implementar un WAF y protección contra DDOS, ¿verdad?
Para quienes no sepan WAF es un Web Application Firewall. El firewall que tenemos conocido para tu red interna que bloquea puertos y bloquea servicios y bloquea IPs, este WAF funciona para tu aplicación web. Hace cosas similares pero también puede inspeccionar headers, puede inspeccionar cualquier cosa en capa 7 porque corre en capa 7. No corre a nivel del network que es el capa 4, sino que corre en capa 7.
Entonces todo lo que viene en capacete te permite inspeccionarlo y permite aplicar políticas alrededor de ellos, políticas de seguridad, reglas de seguridad. Y un DDoS, es un Distributed Denial of Service, que es un servicio que simplemente busca bajar tu aplicación, hacer daño, verdad, hacer daño. Entonces poner eso encima de tu aplicación para mí es, en estos días Juan, no se debería de saltar ningún tipo de aplicación.
Yo recomiendo, yo uso y recomiendo Cloudflare, me encanta Cloudflare, pues aquí no hay nada, ningún tipo de patrocinio. Ya quisiera, de repente pues si quiere que nos contacte ahí Cloudflare, porque siempre donde yo esté me van a ver recomendándolo. ¿Por qué lo recomiendo? No porque se cayó hace unas cuantas semanas y nos afectó a la mitad del internet, ¿verdad? Si no por sus cosas positivas. Realmente Cloudflare es muy poderoso.
La cantidad de empresas grandes que se vieron impactadas por esa falla de Cloudflare demuestra quiénes lo usan y entonces no es a la ligera que lo van a utilizar. Eso demuestra lo grande que ellos son. Y otra razón por la cual recomiendo Cloudflare es que el tier gratis, el paquete gratis, es poderoso. Es poderoso, ofrece, ofrece pero un montón, un montón y realmente que no lo deberían de desaprovechar. Yo lo uso, el paquete gratis de Cloudflare.
tanto nuestro sitio web de Debenops.show, nos pueden visitar ahí, en mi propio blog personal también lo uso el paquete gratis.
Y no he tenido la necesidad de pasar a ningún tier pagado y tengo desde protección que ya voy a mencionar un poquito más adelante hasta que hasta tengo un R2 que es un buckets como los de S3 para manejar ahí la y tener un CDN y todo eso dentro del tier gratis, verdad. Entonces esa es otra razón por la cual yo recomiendo Cloudflare. Pero al final el que tengan a disposición si están en AWS y quieren usar Cloudfront
Juan (21:02)
Ok.
Douglas (21:18)
Pues perfecto, solo que en AWS tienen que usar CloudFront para CDN y reglas de WAF para protecciones si que hagan lo mismo. Front Door, no me equivoco, es el de Azure, Acamai y hay otros, La idea es que pongan un...
una capa, un proxy arriba de su aplicación protegiendo. ¿Qué vamos a agregar en el proxy, Juan? Vamos a agregar los rate limits que mencionabas. Ahí es donde es ideal hacerlo. Porque queremos agregar el rate limit ahí y para quienes no sepan, un rate limit es poner ciertas métricas y request máximos a ciertos endpoints.
para evitar que alguien malicioso quiera aprovecharse y causar daño a través de ellos. Por ejemplo, un endpoint que devuelve, no sé, que devuelve inventario.
Entonces, ser que pongamos un rate limit que en un minuto un usuario no pueda hacer más de 10 requests, digamos. ¿Quién puede necesitar más de 10 requests? Un bot. Pero en un usuario real es difícil que en un minuto va a querer más de 10 requests.
Juan (22:32)
Claro.
Douglas (22:35)
puede ser que digan, hey, agreguemosle un rate limit que cuando un IP quiere hacer más de 10 requests por minuto, que haga algo. Ese algo puede ser bloquear la IP o que ese es como el más agresivo, el más agresivo que puede haber. Normalmente se hacen cosas como challenges, como retos. No sé, yo estoy seguro que aquí la mayoría que hemos navegado, y Juan, yo sé qué te ha pasado, que estamos, que queremos entrar a algún lugar y nos aparece un...
un box que pregunta ¿eres humano? y yo no, sí, soy humano, verdad, soy humano y ya le doy click, es irónico como exacto, tal cual, es lo que yo pienso, pero también es gracioso porque esa validación tan simple un bot no la puede superar, verdad, muchas veces eso lo hacemos con la capa de WAF, con ese layer encima de WAF de tu aplicación
Juan (23:08)
el famoso capture.
Qué irónico que me lo pregunte una máquina.
Douglas (23:34)
donde si hace un re-limit a veces puedes proteger por país si tu aplicación no tiene por qué tener tráfico de Asia por ejemplo muchas veces ataques distribuidos vienen desde Asia y te generan problemas y no tenés usuarios ahí alguien puede decir sabes que voy a bloquear todo Asia no me voy a complicar y eso lo voy a hacer desde esta capa desde el WAF otras protecciones que se agregan ahí se agregan reglas para proteger contra cross-site scripting y no voy a
Juan (23:55)
Así es.
Douglas (24:04)
profundizar en qué es cada uno de estos ataques comunes verdad porque al final se trata de proteger por aplicación pueden buscarlo por ahí o si les interesa que en algún momento hablemos de esto déjenos en los comentarios y podemos tocar el tema más adelante o incluso invitar a alguien que que tengan experiencia en esta parte y que nos ayude a abordar este tema no pero desde el edge desde el WAF
Juan (24:17)
Mm-hmm.
Douglas (24:30)
protegemos nuestra aplicación para cosas como cross-site scripting, SQL injection, code injections, que son los ataques como más comunes que se hacen en contra de un sitio web.
o una aplicación web en general, ¿verdad? Y algo que a mí también me gusta implementar, Juan, con el WAF desde el Edge es proteger endpoints críticos como un login de tus usuarios o tu página de admin, por ejemplo, tu administrador, tu dashboard interno, porque pues tenés diferente, ¿no? Un usuario puede crear su cuenta y...
se loguea y mira su servicio cualquiera, su carrito de compra, su wishlist o cualquier servicio que estés dando, su estado como usuario interno. Y también tenés un admin para las personas internas, por ejemplo en WordPress puede ser el WordPress admin, verdad. Entonces si vos tenés un WAF encima podés proteger eso. Esto por ejemplo algo que a mí me gusta hacer con Cloudflare es
la página de login o las diferentes páginas de login ya sea para usuarios o para admin internos que les agregue un challenge que siempre verifique si es un usuario real y que le pregunte porque muchos bots hay en internet Juan que están atacando constantemente la página de login intentando querer hacer brute force attack
Juan (25:55)
Mm-hmm.
Douglas (25:59)
ataques de fuerza bruta, intentando usuarios y password que encuentran ahí por internet para intentar entrar, verdad, y ponerles, poner esa regla simple para un usuario real solo va a ver una pantadita ahí un rato de Cloudflare y luego se quita y si Cloudflare no logró ver si es humano o no, lo peor que puede pasar es que le pregunta ¿eres humano? y ya estuvo y continúa. Para un usuario solo es eso, verdad, pero si fuera, pero un bot ya no sigue llegando a tu, a tu...
tu sitio, tu sistema y para los dashboard internos a mí me gusta protegerlos todavía más ¿de qué manera? puedes hacerlo bloqueando ips que sólo ciertas ips pueden accesar al dashboard si tenés una oficina o si en tu casa tenés una ip fija puedes decir que sólo esa ip puede entrar al dashboard
y no otras IPs, Entonces así cualquier bot que quiera atacar no puede porque su IP no está permitida. ¿Y para qué querés permitir que alguien fuera de la oficina se conecte?
si solo cuando están en hora de trabajo se conectan al admin, por ejemplo, ¿no? O si vos sos el que administra un sitio solo y lo haces desde tu casa, ¿por qué vas a, querés que esté abierto? Si siempre trabajas desde tu casa. Si querés tener más movilidad, yo te recomiendo que adquiras un servicio de VPN. Hay muchos servicios de VPN, no voy a mencionar ninguno por publicidad. No, pero puedes agregar un servicio, comprar un servicio de VPN, pedir una IP dedicada y ya permítigas esa IP. Y así donde quiera que
te conectas al VPN primero y luego el WAF te va a dejar entrar a tu admin interno. A mí me gusta usar, que este es el que yo uso, yo uso siempre de Cloudflare un servicio que se llama Zero Trust. Zero Trust tiene varias formas de autenticación, yo se lo pongo al endpoint del admin y lo puedo que me pida validar con...
con mi cuenta de github o que me permita validar con mi cuenta de gmail y solo usuarios que yo le di permiso pueden validar, autenticar y pasar luego a la parte del admin. Esto no tiene que ver con autenticación dentro del admin. Todo lo que he hablado hasta ahorita Juan está del lado del edge, del lado del proxy.
Juan (28:14)
Sí, ni siquiera hemos llegado al admin como tal, al panel.
Douglas (28:17)
no
es tal cual, no ha llegado. ¿Y por qué esto es importante, Juan? Porque queremos quitar esa carga computacional de tu sistema. Vos podés agregar, como te decía, ¿no? El rate limit lo podés agregar en código.
y vas a evitar de que alguien quiera abusar de un endpoint que sea pesado. Sin embargo, tu aplicación tiene que estar haciendo esa carga computacional de estar viendo quién cumple o no el rate limit y dejarlo pasar y siempre puedo llegar a estresar tu sitio. Está llegando el tráfico, el bandwidth hasta tu hosting y en la nube se paga mucho dinero por bandwidth. De hecho, el bandwidth es de lo más caro en la nube, ¿verdad? Entonces, el tráfico termina de...
Juan (28:58)
Mm-hmm.
Douglas (29:01)
llegar hasta tu hosting y siempre vas a estar pagando por ese tráfico que no es útil para tu sitio, verdad? Aunque tengas bien protegido y aunque tengas bastantes recursos para que lo manejen, no hay necesidad de que ese tráfico llegue hasta tu sitio.
Por eso el primer tip, Juan, es hacerlo en el Edge, implementarle Cloudflare, implementarle Akamai, implementarle Cloudfront y WAV, lo que esté a tu disposición para proteger en el Edge, que toda esa carga computacional quede en el Edge, ¿verdad? Y así los usuarios ni siquiera llegan hasta tu aplicación. Entonces, no sé qué opinión te merece, Juan, este primer tip.
Juan (29:39)
Mm-hmm.
Bueno, me salta la vista muchas cosas, pero estaba recordando en este momento cuando mencionabas el hecho de bloquear IPs y tener solo ciertos lugares permitidos. Por ejemplo, en mi HomeLab yo hago eso, yo bloqueo todos los países excepto donde estoy porque no tiene sentido que tenga acceso desde Rusia, por ejemplo.
pero no pero estaba pensando en que eso ha sido un gran problema también para que muchas empresas adopten el modelo de trabajo remoto creo que en cierto momento viviste esa transición no de poder permitirle a los developers que puedan trabajar con recursos pero siempre desde afuera me imagino que debe haber sido muy complicado porque bueno al menos en ese momento tuviste que haberlo hecho tuvieron que haberlo hecho un poco sobre el
la contratiempo, porque estábamos en pandemia y todo eso. Pero sí, eso me salta a la vista, el hecho de que...
es bien complejo muchos developers nos quejamos de que no nos permitan trabajar desde casa pero es que no es tan fácil no es solamente decir bueno sí subí tu código a github y ya sino que también hay muchas más cosas involucradas pero pero bueno sí eso lo que veo es complicado y no es tan gratis como pensaríamos
Douglas (31:14)
Fíjate que no es gratis, por supuesto, no es gratis. Sin embargo, fíjate que no es tan complicado. Aún con la pandemia, no fue tan complicado porque todo terminó con conexiones de VPN. ⁓
Juan (31:31)
Ok, sí.
Douglas (31:32)
Ahora cuando la pandemia ocurrió, todavía estaba en esta empresa donde vos y yo coincidimos y teníamos data centers y las conexiones de VPN llegan hasta el data center. Aquí hoy en día en Field tenemos nuestros propios servidores de VPN y cuando hay un cliente externo
que no tienen conexiones abiertas a todo el mundo, sino que lo hacen únicamente a ciertas IPs y nos exigen que les demos ciertas IPs, les damos las IPs de nuestras servidores de VPN. Y ellos permiten solo esas IPs, nosotros como usuarios, los conectamos al VPN de la compañía y el VPN tiene permiso para pegarse. Entonces, pues sí, no es gratis, ¿no? La compañía tiene como seis o...
seis o siete servidores de VPN en diferentes lugares en Estados Unidos, en Sudamérica, en Asia, en Europa para que los usuarios, empleados, los colaboradores, se conecten al VPN más cerca a su región y luego se conecten al servicio. Entonces es costo y también se necesita obviamente muchos recursos. Si vos tenés un internet lento en tu casa.
Juan (32:36)
Ok
Douglas (32:48)
Entonces tu servicio está en San Francisco, que es en la costa oeste de Estados Unidos. Entonces yo desde Honduras me tengo que conectar primero a un VPN en Nueva York.
Y luego de Nueva York, el tráfico va a ir al servicio del cliente en San Francisco. Está viajando bastante y eso va volviendo el tráfico un poco lento. Entonces hay que lidiar con recursos, pero realmente, Juan, y los developers se quejan bastante, me llama la atención que lo digas, los developers se quejan bastante, pero realmente que la seguridad no tiene precio.
La seguridad no tiene precio, entonces mejor se trabaja con eso. Se requiere que alguien desde su casa tenga un buen internet, un buen área de trabajo. Eso es indispensable. Si alguien quiere trabajar desde su casa y tiene el internet más barato, que es compartido con todos sus vecinos o que le roba wifi al vecino, no espere conseguir un trabajo remoto. Hay que comenzar por ahí. Pero sí, realmente que no es tanto lo complicado.
Pero sí el costo y sí hay que tener en cuenta el rendimiento, el performance, por esa parte sí. Pero bueno, si te parece Juan, avancemos al otro tip que quisiera dar y estos este tip ya van avanzando en el flujo, en la conexión. Como dijimos, llamado el usuario va a llegar al proxy, a tu Cloudflare, a tu Wacamai, a tu Cloudfront, ¿verdad? Va a llegar ahí.
Juan (33:58)
Sí.
Perfecto.
Douglas (34:22)
va pasar todas las validaciones y si las pasa va a hacia tu, va a empezar a continuar el camino hacia tu servidor de hosting o tu ambiente de hosting, tu cluster de Kubernetes, tu cluster web, lo que sea que tengas, verdad, ya pasó el primer peaje, primer prueba, el primer checkpoint en el aeropuerto ya lo pasó.
Juan (34:35)
Ya pasó el primer peaje.
Douglas (34:43)
Entonces lo siguiente que yo sugeriría Juan es encriptar la conexión entre tu capa de proxy, tu CDN, tu proxy, encriptar la conexión entre el proxy y tu servidor de origen ¿Verdad? ¿Cómo se hace esto? Simple, tu servidor de origen configuras un certificado SSL, un TLS SSL, lo puedes hacer un certificado gratis con Let's Encrypt.
puede ser un certificado que vos mismo generés, como ese certificado no lo va a ver el cliente, va a cumplir su trabajo de encriptar. Porque el certificado que el cliente va ver es el certificado que te muestra el proxy. Si tenés Cloudflare, el cliente va a el certificado de Cloudflare. Si tenés Akamai o lo que sea que pongas en frente, ahí donde el cliente va a ver el certificado. Porque eso se llama S-Cert termination. Para el cliente la conexión llega ahí y se corta.
y él va a decidir si avanza o no y quien le va a responder al cliente luego va a ser la capa de proxy, entonces el certificado que va a estar entre el proxy y tu servidor no lo ven los usuarios finales, no lo ven el navegador web, entonces pudiera ser incluso un certificado que generes vos mismo, aunque no es la mejor práctica se puede hacer, Cloudflare por ejemplo te ofrece algo que se llama Origin Certificate, vos puedes generar un certificado en Cloudflare.
Y eso lo puedes hacer que dure meses o que dure muchos años. Hasta 10 años creo que acepta, si no me acuerdo, si no, qué más. Y el propósito de ser certificado es que vos lo instales en tu servidor de hosting para que Cloudflare se comunique con él. Si vos querés poner ese certificado que Cloudflare genera, ese Origin Certificate.
directo para que alguien lo mire desde el navegador web le va a dar un error, va a decir de que no es un certificado seguro, verdad, porque Cloudflare lo está diseñando únicamente para encriptar la conexión entre Cloudflare y tu servidor de hosting, verdad. Recordemos de nuevo cuando hacemos eso el cliente final va a ver los certificados instalados en tu capa de proxy, no en tus servidores, pero
Juan (36:39)
ok
Douglas (36:52)
¿Por qué queremos encriptar la conexión? Pues porque no queremos que alguien se pueda poner en medio. Aunque tengo todo eso de proxy y todo protegido, por si alguien se pone en medio y la información va en texto plano, pues es fácil. Es fácil, ¿no? Para un atacante realmente no le damos trabajo en ese sentido. aunque el proxy nos protege arriba, encriptamos para evitar que alguien malicioso se pueda poner en medio de la transmisión.
identificar que robamos, perdón que estamos pasando y lo puedan robar. Ahora, continuando con eso Juan, otra cosa que hay que hacer y esta es clave, es importante y he visto mucha gente fallar en esto, he visto clientes grandes fallar en esto, verdad. Tienen aquella gran protección en Cloudflare y tiene reactivo y rate limits y valida a esto país y funciona maravilloso, maravilloso.
y tienen el proxy y todo, verdad, pero el servidor de origen, el hosting, el cluster, el op balancer, lo que sea que querrás, aceptan conexiones en puerto 80 y 443, para quienes no sepan 80 es una conexión HTTP y 443 es una conexión HTTPS, verdad, entonces sus server de origen aceptan conexiones de cualquier parte del mundo, de cualquier, están abiertos al mundo esos puertos.
Entonces eso quiere decir que cualquiera que vaya por el dominio, como pasa por su capa de proxy, su cloud versus Akamai, va a ser protegido. Pero un atacante tiene la posibilidad de ir directo a la IP del hosting, a la IP del load balancer y atacar el sitio, haciéndole un bypass a toda la protección que tenés en tu Edge.
a toda la protección que tenés en tu capa de proxy porque el servidor acepta conexiones de HTTP y HTTPS desde cualquier lado del mundo. Entonces, ¿qué es lo que vamos a hacer? Tenemos que bloquear, ya sea con un firewall o con diferentes reglas, que tu servidor de origen solo acepte conexiones en puerto 80 y en puerto 443 de las redes de tu servicio de proxy.
que solo acepte conexiones desde las redes de Cloudflare si estás usando Cloudflare, ¿verdad? O desde las redes de Akamai si estás usando Akamai. Y de hecho lo ideal, lo ideal aquí ya que menciono esto, es usar una combinación de bloquear por la red de Akamai y también hacemos que Cloudflare genere un header y lo inyecte en el request con un valor, no encriptado, un valor único, ¿verdad?
Y que el servidor de origen, ya sea con otro servicio de WAF, o ya sea con reglas de NGINX, o de la manera que tenga disponible, que tu servidor también de origen verifique que venga ese header con ese valor específico para que lo deje entrar. Entonces, tendrás una validación doble.
que venga de la red de tu proxy y que también que incluya el header seguro que vos estás permitiendo. Pero lo que estamos buscando con esto Juan es de nuevo evitar que alguien pueda hacerle un bypass a toda la protección que yo tengo en mi capa de proxy y que pueda intentar atacar de manera directa y alguien puede decir pero quién puede atacar de manera directa mi sitio si yo tengo una paginita pequeña verdad entonces
Yo les voy a sugerir que hagan esta prueba, cualquiera que pueda hacerlo. Creen una instancia, una VM en la nube, Easy2 de Amazon, un Droplet en DigitalOcean, una instancia en Linux, en el servicio que ustedes quieran. Creen una instancia, configuren SSH.
que para quienes no sepan SSH y corren el porto 22 es el servicio para que algún servidor Linux pueda conectarme de manera remota y correr comandos dentro del servidor, verdad. Entonces configuren SSH con password, con SSH key como ustedes quieran, idealmente solo SSH key, ¿no? Pero configúrenlo como quieran y aseguren de dejar logs de todas las personas que intentan conectarse a su instancia. Y se van a sorprender cómo una instancia recién creada
la cantidad de peticiones e intentos de ataques que va a tener de personas intentando romper el puerto 22 para poder entrar a tu instancia y ganar acceso a tu red es increíble es increíble la cantidad de bots que hay en internet escaneando ips, escaneando servicios para luego intentar atacarlos, verdad y eso es una manera facilita de verlo y les aseguro que en horas empiezan a ver esa cantidad de conexiones, esa cantidad
Juan (41:44)
Sí.
Douglas (41:49)
de bots intentando romper su seguridad. Entonces, si protegemos bien en el Edge, en Proxy, en Cloudflare, en Acaba, en lo que usen, pero nuestro servidor de origen acepta conexiones HTTP y HTTPS. ⁓
desde cualquier lado del mundo, no estamos protegiendo de manera correcta nuestra aplicación y siempre nos vamos a ver con problemas de seguridad. Entonces, no sé si te habías topado con algo como esto, Juan, en el pasado o en tu experiencia.
Juan (42:14)
Sí.
Nunca he revisado de la manera en lo estás recomendando.
pero si estoy totalmente enterado de que siempre hay gente atacando por ejemplo en WordPress cuando instalamos algún sitio WordPress hay diferentes plugins que nos permiten bloquear eso y siempre nos reporta que algo o no alguien estuvo intentando también se da mucho de en WordPress vas a notar que dejan comentarios intentan enviar formularios de contacto
y están intentando muchas maneras de cómo romper tu seguridad y poder poder ingresar a tu instancia. Aquí es donde yo creo que muchas personas no le dan la importancia que se merece a la
protección de tus datos a la privacidad y la seguridad porque para que querrían ingresar a tu instancia por ejemplo si es algo nuevo y no tenemos nada bueno siempre es útil tener una botnet para los hackers entonces van a estar utilizando tus recursos para hacer sus mandracadas como decimos por aquí
Y bueno, ese sería como el menor de los problemas. De hecho, de ahí para adelante pueden hacer cualquier cosa. Y eso también pasa con nuestros dispositivos personales, celulares, computadoras, todo eso. Pero definitivamente creo que muchas veces no le damos la importancia. Tal vez por eso, porque no vemos ese montón de logs donde empezamos a ver toda la gente que intenta ingresar.
tal vez las personas que han tratado de proteger sus cuentas de Facebook y Meta y Google
en apple también tal vez ellos han empezado a notar cuando ves los logs de quienes han intentado iniciar sesión en tu cuenta vas a notar que de todas las partes del mundo intentan iniciar en nuestras cuentas y bueno y toda la gente dirá bueno pero por qué porque me debo preocupar si no no tengo nada malo el que nada debe nada teme dicen pero no se trata de eso se trata de la seguridad de tus datos la privacidad de datos y tener
soberanía sobre tu información y esto a nivel personal ya en un nivel empresarial pues es importantísimo que nuestro servidor esté más que asegurado porque bueno la información de una empresa es más importante que el stack de tecnología que estemos utilizando la base de datos es el corazón y tratan de llegar ahí y hacer lo que lo que necesiten cuántas
¿Cuántas noticias no hemos visto?
de empresas que son hackeadas y luego se le quean, se difunden en la red toda la información de las tarjetas de crédito, de los usuarios, las direcciones, información personal. Así que sí, es bien importante. Lo bueno Douglas que veo es que hay muchas cosas que hoy por hoy son mucho más simples de lo que eran antes. Hoy en día, por ejemplo, el SSL es bastante fácil de configurar en tu página, ya sea
con let's encrypt o muchos servicios ya te lo venden con ciertos planes al momento de que comprase el dominio y cositas así. Lo del rate limit pues bueno Cloudflare ha venido a simplificar muchos de esos procesos así que eso es algo que me parece muy positivo de nuestros de nuestros tiempos que asegurar una un sitio web
eso es muy simple así que si no lo estamos haciendo es enteramente nuestra culpa por no prestar atención no me imagino antes como era
Douglas (46:10)
Sí, sí, no, yo recuerdo los tiempos en los que la empresa por cada host, por cada dominio, tenía que pagar 150, 200 dólares mínimos anuales por cada certificado de seguridad. Hicieron un certificado STAR, que era que agarraba múltiples dominios bajo un mismo dominio. mucho, sí, subdominios mucho más caros aún, ¿verdad?
Juan (46:33)
los subdominios.
Douglas (46:37)
Y como vos decís, hoy en día tenemos menos excusa. Y también me gusta lo que mencionas de tener preocupación por la privacidad. Si no me quiero preocupar por mi privacidad, cuando tenemos un sitio web y tenemos usuarios, tenemos la responsabilidad de proteger la privacidad de nuestros usuarios. Esa responsabilidad cae sobre nosotros. Si a mí me da igual qué hacen con mi información,
no puedo pensar de la misma manera de mis usuarios eso sería irresponsable entonces tenemos que definitivamente asegurar y los tips que hemos dado hasta el momento van agregado, van en esa línea,
Juan (47:06)
Mm-hmm.
Douglas (47:15)
el primer tip proteger el edge, el segundo tip asegurarte que tu servidor de origen solo acepte conexiones de
de tu proxy, verdad, y de manera encriptada, y de manera encriptada. Si te parece Juan, voy a dar el, como el tercer y último tip que tengo en cuestión de seguridad, tengo un par más ahí que son situacionales, pero el tercero que quiero dar, verdad, es que ya en tu, tu hosting, en tu origin, que agregues una capa, que agregues un web server o un reverse proxy a tu application server.
Juan (47:28)
Sí.
Ok.
Douglas (47:56)
Para hacer la distinción de manera rapidita, el application server, cuando hablamos de hosting de aplicaciones o sitio web, el application server es el servicio que corre el código. Puede ser, si Node.js por ejemplo, tiene su application server que ejecuta el código de Node.js. En Go.
Por ejemplo, vos trabajas en Go, ¿no? Go genera un binario y cuando lo ejecutas levanta un servicio que escucha para llamados web, pero ese es el Application Server porque está hecho para interactuar con la parte del código, con la parte, con todo lo es la parte lógica. PHP, por ejemplo, tenés algo como PHP, FPM, tenés servicios internos.
Juan (48:19)
Sí.
Douglas (48:41)
que corren, ejecutan esa parte y el web server es el que se encarga de servir contenido estático página web, HTML, CSS, imágenes, etc. ¿Verdad? Entonces yo he visto mucho, pero mucho más de lo que crees el error de personas que trabajan por ejemplo en una aplicación en Node.js y ellos directamente el servicio de Node.js, sea directamente el application server
es el que publica el sitio o la página al internet y aunque pasen por por Cloudflare, cuando los requests llegan a tu servidor los recibe directamente Node.js, recibe directamente Python, Golang y eso no solo es malo para el rendimiento porque las imágenes, el CSS y todo lo que tiene que ver con el front end de la página lo va a servir el Application Server
que solo porque lo pueda hacer no significa que está hecho para eso. El Application Server está hecho para correr el código.
puede servirte imágenes, puede servirte HTML y CSS, pero está más hecho para correr el código y servir el código a los usuarios. no sólo es malo para el rendimiento porque el application server no está haciendo eso, pero también es malo para la seguridad, porque estas reglas de seguridad, algunas se pueden implementar ahí, pero es muy complicado, otras no.
Si ponemos un web server en frente, un reverse proxy, yo hoy en día sí o sí recomiendo NGINX, verdad, no encuentro ninguna razón para que alguien quiera usar otro servicio, pero pues si quieren usar Apache lo pueden hacer perfectamente, si trabajan en Windows no sé por qué trabajan en Windows, a nivel de servidor, a nivel de servidor, verdad web, no a nivel personal, a nivel personal es perfecto.
Juan (50:40)
Sí.
Douglas (50:43)
Pero si a nivel de servidor web trabajan en Windows no sé por qué lo hacen pero bueno pueden usar ahí mismo IIS también verdad de Windows tengo 16 años tal vez de no tocar IIS no sé cómo funciona pero se puede hacer ¿no? En mis planes sigue así Juan ¿verdad? Pero en fin cuando ponemos en frente Traffic, que es más como un ingres pero hace lo mismo.
Juan (50:56)
y ojalá que siga así
o Traffic, buena opción también.
Douglas (51:11)
puede ser que lo pongas a nivel de Ingress y tenés contenedores, perfectamente válida y me gusta que lo mencionés porque también aplica, estás poniendo esa capa de proxy, el Ingress, ya sea Docker Swarm o Kubernetes, es una capa de proxy más, ¿verdad? Y hace esa función tal cual. Entonces, ¿por qué queremos eso ahí? En primer lugar, porque ahí en tu reverse proxy agregás políticas de seguridad a nivel de hosting.
como manera de un fallback, como manera de un respaldo por si algo falla en el Edge. Tengo un montón de capturas y todo lo que haré en el Edge, rate limit y protección por IP y cosas, Pero una vez que llega a mi hosting...
y pasa por NGINX, pasa por Traffic, pasa por cualquiera que sea que configuraste como el REST proxy, si algo se coló por ahí, él todavía va a verificar esta regla, que esta regla se cumplan y todavía ahí puede bloquear uno que otro que se haya querido escapar.
Normalmente eso no pasa, o sea, si lo tenés bien configurado en el Edge no va a pasar, no se va a colar nada, pero es una buena práctica agregar estas reglas de seguridad también en tu reverse proxy, en Nginx en este caso en particular, para proteger la aplicación de esa manera. Igual hay otras cosas.
Juan (52:40)
si lo que pasa es que aunque
no, aunque sea muy poco probable que suceda la ley de morphy siempre está en nuestra contra entonces es necesario
Douglas (52:47)
Sí, sí. No,
absolutamente. Y esa tiene que ser nuestra mentalidad, por supuesto.
¿Verdad? Pero además de eso, Juan, me permita agregar otras normas como los headers, los course headers que mencionabas, ¿verdad? Y otro tipo de headers de seguridad. Ocultar información del application server, hacerlo desde NGINX, que no le diga a todo el mundo de manera facilita qué lenguaje de programación estoy usando. Porque aunque no lo crean, a veces con quitar un
con esconder la extensión de un archivo con eso me quito encima el 90 % de los bots que hay en internet ¿alguien puede fácilmente averiguar que lenguaje estoy usando? sí, sí, pero los bots que están corriendo ahí con sólo esconder a veces la extensión de un archivo o esconder un endpoint ya no siguen intentando atacar, verdad, el tener NGINX, tener un reverse proxy en frente del application server
me da esa opción y de nuevo recomendado sí o sí para mejor rendimiento pero para manejar la seguridad desde el REST proxy también es un sí o sí en mi opinión, ahí manejamos esas cosas además igual nos da la posibilidad de agregar logs más más como friendly, verdad, y eso me sirve para ver qué logró pasar la capa de ledge.
y qué puedo ver acá en los logs de NGINX que me ayude a ⁓ identificar posibles problemas.
Juan (54:31)
que con los logs
solo como un dato ahí interesante para las personas que no tienen mucha experiencia con eso o que tal vez no se habían reparado a pensar en esto
a veces es problemático lo que estamos logueando, hay que tener mucho cuidado con la información que estamos dejando en los logs de nuestro servidor porque muchas veces hay diferentes políticas dependiendo de los países, por ejemplo hay información que es considerada muy sensitiva, obviamente no podemos dejar en el log el número de una tarjeta de crédito, no podemos dejar los passwords,
incluso con el tiempo he visto que incluso el email ya se considera como información sensitiva entonces no lo podemos dejar en los logs así que de nuevo sólo como como un pequeño comentario ahí es importante también revisar qué estamos logueando porque ya aquí no es tanto seguridad de afuera sino más bien de no tener problemas legales en lo que estamos haciendo en nuestros servidores
Douglas (55:42)
No, y tiene que ver con seguridad, fíjate Juan, porque de nuevo si alguien lograra entrar a tu sistema, se va a encontrar con esa información en un log file que está en texto plano, verdad, y con respecto al número de tarjeta de crédito, ningún sistema debería de guardar en ningún lugar.
Juan (55:47)
Sí. Sí.
en ningún
Douglas (55:59)
la tarjeta de crédito,
Juan (55:59)
paso.
Douglas (56:01)
O sea, ni en base de datos, ni en logs, ni en cripto, en ningún lugar. Eso es totalmente ilegal. ¿Verdad? Así que personas que trabajan en esa área con cobros, si en algún lugar se está haciendo, es totalmente antiético, es ilegal. Inmediatamente y borren todo rastro de ello.
Juan (56:18)
quítenlo rápido
Douglas (56:25)
me han pasado historias Juan, me han pasado historias, créeme pero bueno esos son los tres tips principales que para mí son innegables y son inevitables y relativamente fáciles de implementar en la parte de sistemas para proteger una aplicación y con eso créanme con eso se quitan el 95, 98, obviamente estoy inventando ese número ahorita pero lo que quiero decir es que se quitan
Juan (56:41)
Sí.
Douglas (56:54)
a la vasta mayoría de bots que están ahí en internet y aparte, aun a cualquiera que quiera hacer un ataque dirigido hacia ustedes va a tener dificultades para encontrar cómo hacerlo y aun aquellas personas que encuentren cómo hacerlo si de verdad tienen malicia contra su sitio o su aplicación con todo esto ya implementado
va a ser fácil desde el CDN o desde el WAF bloquear a un usuario, aplicar una nueva regla de Ray Limit porque todos estos servicios me van dando logs, me van dando métricas que yo voy usando para identificar bloquear un país, bloquear un usuario, agregar un nuevo challenge, ¿verdad? Ese que pregunta si soy humano o no.
agregar un nuevo challenge, agregar lo que sea y si llego a enginex, ahí voy a ver los logs, voy a identificar, voy a bloquear este, voy a habilitar este, voy a agregar un caching, etcétera, etcétera, verdad? Entonces ya con esto lo poquito que se logre filtrar me va a hacer fácil identificarlo y fácil reaccionar a ello. Ahora quiero cerrar Juan con dos tips más que son situacionales, esto puede ser muchas veces
por requerimientos de la empresa, por diferentes normas o estándares que ellos tengan que cumplir, aquí se aplican esto o para aquellas personas que tienen bastante paranoia, lo cual es bueno, miren, en todo lo que tiene que ver con configuración de servidores, sistemas y ciberseguridad, la paranoia nunca está de más. Es más, es preferible ser así que ser demasiado confiado. ⁓
Juan (58:27)
Uh-huh.
Douglas (58:29)
Pero estos dos yo no siempre los hago dependiendo de la situación porque ya para que alguien pueda sacarle beneficio a esto ya tiene que haber ganado acceso a tu red interna ¿Verdad?
Juan (58:44)
Ok.
Sí.
Douglas (58:46)
Y
si alguien tiene acceso a tu red interna, tenés un problema más serio, ¿verdad? Tenés un problema más serio que un simple WAF. Pero bueno, aún así, muchas empresas lo requieren y nunca está de más. Lo primero es...
Juan (58:51)
No,
Douglas (59:00)
que todos los llamados internos dentro de tu red internet sean encriptados, sean por TLS o SSL desde la base de datos, ¿verdad? O otros APIs internos, otros sistemas o servicios internos, aunque estén dentro de tu red.
que estén protegidos tanto por firewalls donde solo ciertas IPs internas puedan accesar a ellos y que estén encriptados. De nuevo, para que alguien le saque beneficio a que no esté encriptado tiene que meterse a tu red y ponerse en medio en la comunicación para poder verlo. Sin embargo, bancos exigen esto, PCI lo exige y hay otro tipo de industrias que también lo requieren.
El consejo es de nuevo situacional, se llama Encryption at Rest. Tenemos lo que es el concepto de Encryption at Transit, es HTTPS, la conexión que está encriptada, el SSL, que ya lo dijimos, entre Cloudflare, o entre Proxy, y to Hosting, que está encriptado, o internamente si lo requieren las diferentes comunicaciones que estén.
Juan (1:00:00)
El SSL.
Douglas (1:00:12)
por ese cell, esa es Encryption at Transit, pero también está Encryption at Rest, eso significa que el disco donde se guarda la información está encriptado. Hay diferentes maneras, por ejemplo si es base de datos, si usas MariaDB, MySQL, Postgres, tienen manera de encriptar.
solamente el file system de donde se guarda la base de datos o puedes encriptar todo el disco duro y esto lo dicta los estándares de la empresa porque hay empresas que quieren que no sea el disco duro que está encriptado sino que el file system donde está la base de datos por ejemplo verdad o ambos
En mi caso por ejemplo, a muchos les puede pasar, en donde trabajan se les exige que las computadoras estén el disco encriptado. ¿Por qué es esto? Porque si a mí me roban la laptop y alguien quiere sacar el disco y ver la información, no va a poder ver nada porque está encriptado.
encriptado y sin mi contraseña no pueden robarse información porque está encriptada entonces el encryption at rest lo que busca es eso proteger de que cuando la empresa de nube esté descartando servidores verdad viejos esté botando discos duros y ellos te aseguran que van a destruir todo verdad antes de deshacerse de ello pero si por alguna razón lo hicieron si por alguna razón alguien malicioso robó un disco duro de la empresa de la nube
no va a poder sacar tu información porque está encriptada en disk, en encryption address, ¿verdad? Entonces, de nuevo, estos últimos dos son situacionales. Normalmente yo no los hago porque de nuevo, si alguien le va a sacar beneficio a ello...
hay demasiadas cosas arriba las que ya dañó verdad pero pero hay cierta información que es muy crítica como vos decías no bancos usuarios o cosas que no queremos que eso lo vaya a robar si alguien tiene acceso físico a la información pero Juan mira
Juan (1:02:10)
Si, que vienen siendo como
el ultimo bastion de defensa. Todo se cayo, derribaron nuestras murallas, entraron. Pero tenemos ese ultimo que bueno ahora el disco esta cifrado o las peticiones estan cifradas. Por si alguien se lo pregunta, porque en un cierto momento yo me hacia esa pregunta.
el hecho de tener todo el disco duro cifrado sí tiene un impacto en el rendimiento y bueno la respuesta técnica es que sí porque definitivamente está haciendo algo más allá de simplemente guardar la información está cifrando todo pero hoy en día al menos en linux y quiero creer que también en windows y mac en tu laptop pero al menos en linux el impacto es mínimo
Douglas (1:02:35)
Sí.
Juan (1:02:59)
es básicamente imperceptible para uno así que no hay ningún problema de rendimiento supongo que tal vez haya algún caso, algún uso de alguna aplicación que sí se vea impactada por eso estoy imaginando alguna aplicación que es demasiado específica, demasiado que realmente le afecta pero por lo general el 99.9 % de los casos
tener algo cifrado en el disco incluso si es el disco entero no debería impactar en nuestro rendimiento
Douglas (1:03:33)
Sí, sí, además ahí ya, obviamente se aplican otro tipo de técnicas. Ningún proceso, servicio o aplicación debería de arquitectarse de manera que dependa fuertemente en cálculos en la base de datos y que requieran de mucha lectura y escritura. Realmente deberíamos de hacer todo ese procesamiento a nivel de capa en memoria, usando otro tipo de cosas, ¿no? Porque aunque no esté cifrado, si dependemos fuertemente de lectura y escritura en disco,
vamos a consumir muchos recursos, ¿verdad? Ahí se aplican otras capas, pero me gusta que lo menciones, ¿verdad? Realmente que el impacto en rendimiento hay, porque hay un cifrado, hay una encriptación, pero no afecta, no debería de afectar, ¿verdad? Y de nuevo, ahorita estamos hablando de los tips de seguridad, entonces, es válido mencionar que no le tengan miedo si su aplicación lo requiere, lo necesita.
Juan (1:04:19)
Si, sin efecto.
De hecho solo
como para que tengan una noción un poco más clara yo podría jugar videojuegos en la laptop y el disco está cifrado y me refiero tal vez a un juego de los más actuales y no debería impactarme de manera que sea notoria para mí. Así de bien estamos en ese aspecto hoy en día.
Douglas (1:04:52)
Sí, sí, hay que entender que los momentos en los el encriptado es un factor es cuando leemos y escribimos en disco, ¿verdad? Una vez que se cargó en RAM, ya no estamos leyendo el disco, ya no se vuelve un problema. Si un sistema página, porque al paginar usa el disco duro como RAM, son esos los puntos en los que eso se vuelve un factor y de nuevo, aunque se vuelve un factor...
Juan (1:05:01)
Exacto.
Douglas (1:05:19)
o sea la carga que pone el encriptado es mínima no debería de afectar entonces no me gusta que lo menciones Juan y que lo hayas aclarado y bueno esos son los consejos que yo les puedo dar verdad esto yo los hago sí o sí en todo tipo de aplicación esto que les mencioné lo tengo aplicado en mi blog personal lo tengo aplicado en la página de Deben Ops que yo administro obviamente el hosting de la página y cualquier cliente pequeño
Juan (1:05:24)
Exacto.
Douglas (1:05:49)
o mediano que sea y presente cero requerimientos de seguridad lleva estos tips implementados sí o sí como mínimo. Esto no es negociable para mí en ninguna página o aplicación web y por eso se los quería compartir. Juan, no sé si nos querés dar algunas palabras de cierre.
Juan (1:06:10)
Bueno, me gustaría mencionar que realmente son pequeños tips que podemos ir agregando, como ya mencionaba son bastante, son relativamente fáciles y hay que pensar que con esto estamos bloqueando bots, estamos bloqueando ataques, incluso recuerdo, hay un libro que leí hace mucho tiempo, se llama El Arte de la Intrusión, es escrito por un hacker muy famoso llamado Kevin Mitnick.
Y en una de las historias que cuenta dentro del libro menciona que un hacker, este hacker iba a dirigir un ataque a una empresa, pero a medio camino se rindió y no siguió, se fue por otra empresa. ¿Por qué? Porque en ese entonces, estamos hablando de los años, creo que 80 o 70, el hacker menciona que esa empresa tenía configurado lo todo con dispositivos de Cisco, y él mencionaba que iba a ser demasiado tiempo el
iba a tardar en siquiera tratar de atacarlo que no valía la pena. Así que esa es una como buena métrica para nosotros el hecho de que si tenemos todo muy bien seteado va a ser tan engorroso para un hacker.
que van a decidir no hacerlo y ojo aquí tampoco estoy asegurando que no lo van a hacer pero si nos ponemos del lado de los zapatos de un hacker van a preferir invertir tiempo en todos aquellos sitios que esté más fácil así que porque lo menciono porque estoy seguro que va salir alguien y decir que bueno si todo es posible de vulnerar y que siempre hay métodos y sí pero la idea aquí es protegernos lo más que podamos y todo lo que podamos
hacer pues hacerlo así si el día de mañana sucede una catástrofe dentro de nuestro de nuestro sistema vamos a poder reaccionar y también vamos a poder identificar todo lo que sucedió y porque va a estar todo muy bien seteado eso es lo que esperamos así que sí yo si lo quieren ver de esa manera veanlo como que lo vamos a poner más difícil a todos aquellos criminales que intentan atacarnos
Douglas (1:08:18)
Me gusta, me gusta como lo dijiste y yo creo que son las perfectas palabras para cerrar este episodio Juan, entonces aquí nos despedimos pero nos vemos en el próximo episodio donde Juan nos va a contar sus tips y consejos para asegurar una aplicación web o sitio web en la parte de código, entonces nos veremos a la próxima, bye.
Juan (1:08:40)
Hasta la próxima.