Este curso no es la continuación del otro, deben ser parte de un grupo de cursos paralelos que comparten la intro y hacen referencias cruzadas.
No logro distinguir claramente que parte es confidencial y cuál pública, para discernirlo tendría que leer la documentación pública que debe ser interminable, así que me voy a limitar a comentar el efecto del curso sobre mí, expresando más mi visión sobre el tema que lo visto.
Trata de detección y prevención del accionar de bots, los cuales no dejan de ser automatizaciones de acciones humanas y pueden tener un mayor o menor parecido al accionar de un humano. Esta diferencia de parecidos es lo que permite detectarlo.
Según las cifras provistas, la mitad del tráfico de Internet es bot, siendo mitad y mitad "bueno" y "malo".
Bueno viene a ser google indexando, chat bots, feed fetchers, herramientas de monitoreo de salud de servicios
Malo robo y explotación de credenciales, intermediarios de datos, scrappers para recopilación de información por fuera de APIs, automated inventory purchasers que son los que compran cuando se abre una oferta limitada para la reventa y por supuesto, no me olvido de DDoS
Claramente, lo bueno y malo puede ser difuso.
Una navegación desde un navegador deja una traza de eventos con un patrón que la distingue de una herramienta de descarga como pueden ser wget o curl. Estas últimas pueden bajar elementos de más o de menos, más probable. No ejecutan el código javascript, lo que produce falta de mensajes y descargas.
Tambien hay múltiples maneras de detectar un bot por sus headers, tanto presencia como orden, ausencia y valores utilizados.
Un recurso más completo es usar headless browsers, como puede ser webdriver, lo que se usa con selenium. Este método reproduce el patrón, pero no de forma humana, no hay movimientos del cursor en la pantalla, no hay demoras o son fijas entre las interacciones.
Desde el servidor es improbable detectarlo, pero agregando un poco de javascript en algunos puntos cruciales se detecta a mejor. Supongo que siguiendo este link eventualmente llegarás a una demo que no pongo pues aún no me han contestado si puedo mostrar capturas de pantalla.
Otro recurso es por reputación de IP, pero no es decisivo, podés estar navegando legítimamente desde una máquina que tiene un bot haciendo un 5% de tráfico. O podés estar junto con mil personas y un bot mas detrás de un NAT y ahí se complica.
Una vez que detectaste un bot, ¿qué hacés? Bueno, depende de si es bueno o malo y de lo que esté haciendo. Si es bueno pero no se está portando bien, lo frenás o le dás contenidos cacheados, entendiendo que no te quiere molestar, sólo está mal configurado.
Si es malo, depende de la inteligencia que haya detrás, siempre es bueno que cuando te atacan lo hagan por donde conocés. Si vos le decís que ya sabés que es un bot y lo rebotás, estás haciendo que busque otro lugar por donde molestar. Entonces quizás sea mejor darle diversas respuesta, todas inhabilitantes pero que no revelen que ha sido descubierto como bot. Podés negarle a veces, demorarle otras, mandarle a contenido alternativo o a un honey pot.
Como en todo curso y más tan pautado como son estos de tipo corporativo, lo más importante es el área docente y la interacción del resto del alumnado, lo que hace la diferencia con leer el material provisto. En la intro previamente mencionada se mencionó algo que quizás me perdí en el otro, no creo pues nació de una pregunta.
Llega una petición al Edge y después de un INCREIBLE manoseo sin salir del Edge y quizás sumado a otro manoseo al llegar al Site, recién ahí llega al servidor protegido, la pregunta es, ¿cómo afecta eso a la latencia?
Da justo la casualidad que estoy leyendo un breve libro de los liberados por ACM debido al covid que se llama
Heterogeneous Computing: Hardware and Software Perspectives, Mohamed Zahran
en el cual se menciona que uno de los más importantes factores a considerar es la comunicación entre los nodos que procesan la información, al punto que pueden haber operaciones que te conviene hacer en este nodo ineficiente en lugar de en el optimizado para no perder tiempo en la transferencia de los operandos y el resultado.
Menciona por ejemplo los cores de aceleración que están en el mismo silicio como los APU de AMD en contraste con tener que ir vía PCI hasta la otra placa.
Eso ya se adivina en el chip Epiphany de la placa parallella, que tiene un sistema de mensajería interno entre los 16 cores. Y parece ser la tendencia al usar los Zynq y los MPSocZynq por el lado de Xilinx y tambien por Intel.
Volviendo a Akamai, lo que explicaron es que por un lado no es tanto tiempo el de procesamiento en comparación a viajar por Internet, lo cual queda compensado por no utilizar el enrutamiento normal si no el suyo propio.
Recordá que esto es sólo TCP, en particular 80 y 443, no te sirve usar Akamai para evitar el lag en UrbanTerror o el FPS de tu preferencia.
No hay comentarios:
Publicar un comentario