¿Cómo clasifica el comando Netstat las conexiones entrantes y salientes?
No hace ninguna clasificación.
Busqué y encontré que netstat lee / proc / net / tcp para imprimir la salida.
- Cómo rastrear a alguien a través de una dirección IP
- ¿Cuál es la mejor manera de hacer ping a un cliente en un puerto específico después de establecer una conexión TCP entre el cliente y el servidor?
- ¿Cuántos mensajes totales se envían directamente desde y hacia el cliente DNS y el servidor cliente DNS cuando un cliente necesita un nombre resuelto en una dirección IP correspondiente?
- ¿Por qué se usa Dijkstra para el enrutamiento de estado de enlace y Bellman-Ford para el enrutamiento de vector de distancia? ¿Por qué no usar lo mismo?
- ¿Es posible que un dispositivo atacante solicite continuamente direcciones IP de un servidor DHCP real con direcciones MAC que cambian continuamente?
Tienes mucha razón. De hecho, si toma la salida de netstat -ant4 (imprima todas las conexiones TCPv4 sin resolver los nombres de host):
Conexiones activas a Internet (servidores y establecidas)
Proto Recv-Q Send-Q Dirección local Dirección extranjera Estado
tcp 0 0 127.0.0.1:17601 0.0.0.0:* ESCUCHAR
tcp 0 0 0.0.0.0:2049 0.0.0.0:* ESCUCHAR
[…]
tcp 0 0 192.168.99.32:59798 192.229.189.142:443 ESTABLECIDO
tcp 0 0 192.168.99.32:50020 69.163.253.7:993 CLOSE_WAIT
tcp 1 0 192.168.99.32:53738 52.0.152.198:443 CLOSE_WAIT
[…]
y compárelo línea por línea con la salida de cat /proc/net/tcp :
sl local_address rem_address st tx_queue rx_queue tr tm-> cuando se recupera el tiempo de espera del uid inode
0: 0100007F: 44C1 00000000: 0000 0A 00000000: 00000000 00: 00000000 00000000 501 0 4008762 1 0000000000000000 100 0 0 10 0
1: 00000000: 0801 00000000: 0000 0A 00000000: 00000000 00: 00000000 00000000 0 0 26034 1 0000000000000000 100 0 0 10 0
[…]
26: 2063A8C0: E996 8EBDE5C0: 01BB 01 00000000: 00000000 02: 00000906 00000000 501 0 5967787 2 0000000000000000 20 4 28 10 18
27: 2063A8C0: C364 07FDA345: 03E1 08 00000000: 00000000 00: 00000000 00000000 501 0 5976710 1 0000000000000000 40 4 0 10 -1
28: 2063A8C0: D1EA C6980034: 01BB 08 00000000: 00000001 00: 00000000 00000000 501 0 5967337 1 0000000000000000 60 4 10 10 -1
[…]
se daría cuenta (después de reorganizar las direcciones hexadecimales en orden de bytes de red y realizar las conversiones hexadecimales a decimales necesarias) que netstat es, al menos con este grupo de opciones, nada más que una impresora bonita /proc/net/tcp .
¿Por qué no podemos encontrar las conexiones entrantes y salientes de / proc / net / tcp?
En cierto sentido, porque la distinción no tiene sentido para la pila de IP de su sistema después de que se establece la conexión. Como dice la primera ley de Adrian de Linux Data Data Motion :
Cada conexión TCP pasará datos en ambas direcciones con la misma facilidad, a menos que una configuración de
netfilterobligue a lo contrario.
Sin embargo, existe una simple heurística para determinar la dirección en la que se realizó originalmente una conexión arbitraria. Solo necesita recordar un hecho muy simple: las conexiones TCP entrantes a un puerto requieren un proceso de escucha en ese puerto . Sin oyente, sin conexión.
Así que mira tu salida típica de netstat . Ver todas esas líneas en estado ESCUCHAR ? Eso le dice qué puertos tienen escuchas activas y en qué interfaz ( 127.0.0.1 indica que la escucha solo está esperando en la interfaz de bucle invertido de su sistema, 0.0.0.0 significa que está escuchando en todas las interfaces).
Ahora que sabe qué direcciones / puertos está escuchando su sistema, es una buena apuesta que cualquier conexión cuya dirección / puerto local esté en esa lista sea una conexión entrante , y todo lo demás sea saliente . En mi ejemplo anterior, nada está escuchando en los puertos 59798, 50020 y 53738, por lo que puede estar seguro de que las tres conexiones son salientes.
Notas al pie:
¹ Para ser pedante, es posible que un oyente deje de escuchar en cualquier momento después de establecer una conexión, en cuyo caso clasificaría incorrectamente las conexiones relacionadas como salientes. Esto, sin embargo, es extremadamente improbable.
