#26 Pero cómo vas a ver lanzar su primer SYN TCP si no es cuando estás en medio ... (MITM). Y si estás en medio, el ataque es mucho más simple! Si no estás haciendo un MITM no puedes hacer nada ... suponer que está intentando visualizar alguna web... pero ya me diras en los milisegundos que dura la conexión TCP (contando con el keep-alive incluso), cómo vas a cortar eso!..
De todos modos pensaba estar seguro!... lo bueno de comentar y que te corrijan es que se aprende. ¿No crees? Hoy aprendí una cosa nueva!
Al mensaje que replicaba no daba detalle técnico alguno, información que poder comprobar ni leer. Entiende que sin esto, uno se reafirme en lo que cree que es cierto.
#18 y #17 Sí! lo comentó #14 ya. Gracias!... de todos modos todo esto venía porque aunque sea 1 conexión TCP para hacer varias peticiones HTTP no tiene sentido hacer el ataque que se explica en #0, porque dicha conexión TCP no dura lo suficiente. Al final de la ristra de peticiones HTTP hay un RST del server ... Por lo que la conexión no se mantiene viva.
#10 No conocía DASH, le echaré un vistazo, gracias por el enlace. En #9 me intento explicar mejor. Todo venía porque en las imágenes de la web de #0 ponen código HTML ....
#7 A ver, me explico mejor. TCP sí es persistente pero el protocolo HTTP que funciona sobre TCP hace que la conexión dure lo que dure el servidor en contestar al cliente. Si te estás bajando un fichero vía HTTP de 20Gb, podría intentarse el ataque.
Lo que identifica una conexión es IP y puerto cliente e IP y puerto del server... Conocer la IP del servidor es trivial con un nslookup, y si es vía HTTP con TLS, será al puerto 443... vale, ya tenemos dos de los 4 datos... Si conocieras la dirección IP de la victima sólo queda su puerto de origen. Hay que spoofear su dirección IP enviando paquetes al server con el flag RST haciéndote pasar por la víctima... para encontrar el puerto del cliente se usa fuerza bruta ... Probando puerto tras puerto. Cuando das con el puerto, el server acepta el RST y cierra la conexión. Es sólo esto.
Si la conexión HTTP es suficientemente duradera como para que te pueda funcionar, funcionará, sin duda. Pero en general, dura milisegundos. No olvidemos el motivo del mensaje original. En las imágenes de la web de #0 ponen código HTML ....
#7 No son persistentes, en cuanto la descarga acabe el servidor cierra la conexión, sigue siendo HTTP.
Conexiones persistentes son las del IRC, las de Whatsapp que reciben nuevos mensajes o notificaciones del servidor al instante de ser recibidas, websockets, etcétera.
Por otro lado los servicios de streaming de video suelen usar UDP, no TCP. Y en UDP no hay conexión alguna, da igual que los paquetes se pierdan por el camino. Más info en es.wikipedia.org/wiki/Protocolo_de_datagramas_de_usuario
#18 Pero entonces queda bajo negociación entre arrendatario y arrendador. Si la orden de mantener un 30% de aforo viene del Estado, por qué no limitar las rentas que se pagan por local al 30% vía Estado también.
Entiendo que entonces lo recaudado por el Estado será menor, pero algo habrá que hacer, si no se quiere mandar a la ruina a tantísimos negocios.
#4 Y si quieres verlo por ti mismo usa telnet contra, pongamos www.google.com:
~ $ telnet www.google.com 80
Trying 216.58.211.228...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP1.1 <------- Esta es mi petición
HTTP/1.0 400 Bad Request <------- cabeceras de respuesta del servidor. Vemos que hay error en mi petición. Y que el body tiene mimetype text/html
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Content-Length: 1555
Date: Wed, 29 Apr 2020 07:32:34 GMT
<!DOCTYPE html> <------- este es el body de la respuesta
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 400 (Bad Request)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (webkitmin-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p>400. <ins>That’s an error.</ins>
<p>Your client has issued a malformed or illegal request. <ins>That’s all we know.</ins>
Connection closed by foreign host. <----- servidor cierra conexión, tras la respuesta.
Este ejemplo es el primer request que el navegador que uses siempre hace. Si el body contiene otros recursos (como en el ejemplo que puse), como imágenes, javascripts y css, el cliente vuelve a requerir mediante sucesivos requests esos recursos adicionales referenciados en el documento html original, causando lo que describí, decenas de requests que uno tras otro van haciéndose con todos los recursos necesarios para visualizar correctamente dicha web.
#4 Eso que dices es incorrecto. Ve a cualquier web, pulsa F12 (developer tools), acude a la pestaña "network", y pulsa F5... verás que hay decenas, sino cientos de peticiones, todas como lo descrito. TCP handshake, una vez abierta conexión, protocolo HTTP de toda la vida, GET <recurso_que_se_quiere_solicitar> HTTP/1.1, servidor responde y se cierra la conexión TCP. Esto se repite para imágenes, javascripts, css, htmls.
El único pero son los websockets, que se inician como HTTP, pero acaban como una conexión TCP persistente y bidireccional, que se mantiene abierta hasta que alguna de las partes hace un RST.
Es que el alquiler del local no les costará el 30% de lo que les costaba ... Ese seguirá al mismo precio. Igual cuotas de autónomos, etcétera. Si los ingresos van a ser los que vienen de un negocio al 30% de su capacidad, están jodidos.
Esto es más viejo que la tana. Se conoce desde tiempos inmemoriales.
Lo jodido de esto es que en las imágenes que acompañan a cómo funciona, ponen código html, cuando en las peticiones web es prácticamente imposible llevarlo a cabo y no tiene sentido. Es en conexiones de larga duración donde lo tiene. Conexiones de Chat, entre clientes de torrents, websockets, todo servicio que necesite una conexión TCP abierta de forma continua.
Http es abrir conexión, pides /index.html, server responde y chapa conexión. Esto ocurre en cada petición en milisegundos. Quizá segundos si el server tiene que hacer alguna operación costosa. Pero si falla la petición, F5 y tienes una nueva.
#64 Hay gente que abandona las drogas. No les quitemos mérito. Si hay gente que abandona las drogas y es mérito suyo, los que no lo hacen tienen también parte de responsabilidad.
Al decir les ha tocado, les quitas responsabilidad a todos ellos. Hay algunos que se lo han ganado a pulso, por su mala gestión de sus vidas, asuntos de drogas, alcoholismo, adicciones en general. Tú y yo también tenemos drogas, alcohol y máquinas tragaperras al lado. Hemos elegido no usarlas de forma enfermiza. Pero decir que el azar hizo que no nos tocasen las drogas o alcohol creo que enturbia el verdadero motivo que tiene un problema. En este último caso, parte de culpa también la tenemos nostros ¿no? que hemos elegido gestionar nuestras vidas de una forma algo más organizada.
Y al asesino, espero que le/los cojan. Menudo descerebrado.
#32 --544691-- * 