Esto sólo sucede mientras navega. Tengo uno de esos enrutadores que ni siquiera bloquea el tráfico entrante, por lo que el firewall de mi computadora tiene que hacer todo el trabajo. En el registro a continuación utilicé Firefox, pero esto sucede con cualquier navegador. En mi Firefox, HTTP2, trabajadores web, trabajadores de servicios, WebRTC y muchas otras cosas están deshabilitadas/bloqueadas, por lo que es realmente un misterio para mí cómo los servidores logran solicitar conexiones no solicitadas a mi computadora. Esto sucede en varios sitios al navegar por ellos, pero no en todos.
Date Time Direction Process path Protocol Source IP Src Port Dest. IP Dest.Port Action Window title
17/04 16:23:59 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50755 | 204.79.197.200 | 443 | Allowed | Startpage.com - The world's most private search engine - Mozilla Firefox
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50730 | Blocked |
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50735 | Blocked |
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50735 | Blocked |
17/04 16:25:25 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50766 | 37.252.238.25 | 443 | Allowed | unsolicited incoming connections at DuckDuckGo - Mozilla Firefox
17/04 16:25:25 | In | - | TCP | 37.252.238.25 | 443 | 10.0.0.3 | 50766 | Blocked |
17/04 16:29:50 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50785 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50786 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50787 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50788 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:54 | In | - | TCP | 201.48.71.43 | 443 | 10.0.0.3 | 50788 | Blocked |
17/04 17:03:12 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50986 | 151.101.1.69 | 443 | Allowed | Super User - Mozilla Firefox
17/04 17:03:12 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50987 | 151.101.1.69 | 443 | Allowed | Super User - Mozilla Firefox
17/04 17:03:18 | In | - | TCP | 151.101.1.69 | 443 | 10.0.0.3 | 50986 | Blocked |
17/04 17:03:18 | In | - | TCP | 151.101.1.69 | 443 | 10.0.0.3 | 50987 | Blocked |
Hay muchos otros ejemplos, pero todos siguen el mismo patrón: accedo al sitio, lo que crea una conexión a una IP específica, luego ocurren uno o más intentos de conexión entrantes no solicitados provenientes de la misma IP.
¿Alguien sabe qué, por qué y cómo está sucediendo esto?
Respuesta1
No, creo que el firewall de tu computadora te está mintiendo.
A juzgar por la elección de los puertos locales y remotos, probablemente esté viendo paquetes de respuesta perfectamente normales que pertenecen a una conexión saliente existente, pero no puede asociarlos con esa conexión por algún motivo.
Para saber si una conexión es entrante o saliente, un firewall debe tener estado: presta atención a cada paquete TCP y recuerda los pares de dirección y puerto correspondientes. Por ejemplo, sabe que todos los paquetes con dirección local (10.0.0.3, 50766) y dirección remota (37.252.238.25, 443) pertenecen a una conexión saliente que realizó su navegador.
Cuando llega un paquete de respuesta, el firewall mira su tabla de conexiones y ve que el par de direcciones (37.252.238.25, 443) a (10.0.0.3, 50766) ya se conoce; el paquete no es una conexión nueva, es solo una respuesta a una conexión existente (saliente) y debe permitirse.
Pero si la información de estado se desincroniza por alguna razón (por ejemplo, los propios hosts piensan que una conexión todavía está abierta, pero el firewall ya la ha olvidado) entonces no podrá determinar fácilmente el tipo de paquete entrante. En este caso, el firewall ya nosabeque el paquete entrante pertenece a una conexión que originalmente era saliente, por lo que termina asociándolo con una entrada "entrante" separada.
Por ejemplo, una posible causa es que su computadora acaba deenviadoel paquete FIN "cierre de conexión", pero el servidor remotoAún no recibido(porque la transferencia de datos no es instantánea) y sigue enviándole paquetes felizmente. Si su firewall olvida inmediatamente la conexión al ver el FIN saliente, entonces, por supuesto, no podrá reconocer esos paquetes entrantes como si todavía pertenecieran a la misma conexión. (Las conexiones medio cerradas son válidas en TCP, pero no pasaría un firewall para no darme cuenta de esto).
Esto también sucede a veces cuando el firewall tiene un límite de estados muy pequeño, por ejemplo, he visto enrutadores domésticos que no pueden rastrear más de 50 o 100 estados a la vez (eso incluye no solo conexiones TCP, sino también flujos UDP, por ejemplo, cada DNS). La solicitud a través de UDP crea un nuevo estado para que se pueda permitir el paso de la respuesta). De manera similar, algunos firewalls tienen un tiempo de caducidad de estado muy corto: pueden olvidar las conexiones TCP tan pronto como estén inactivas durante uno o dos minutos, aunque es completamente normal que una conexión permanezca inactiva durante un poco más de tiempo.
(A veces, los firewalls están demasiado ansiosos por rechazar cosas que ambos hosts considerarían normales. Por ejemplo, cuando los navegadores comenzaron a experimentar con TCP Fast Open, el enrutador doméstico que me proporcionó el ISP en ese momento bloqueótodoLos paquetes TFO se basaban en su creencia de que "los paquetes SYN no pueden contener datos" y gritaban "alerta de intrusión" en sus registros cada vez. Creo que esto es una gran parte de por qué QUIC se está desarrollando como algo separado de TCP).