Preocupado por el contenido de ip_conntrack

Resumen

  • Servidor OS: Debian Squeeze
  • Servidor Web: Apache2
  • IP Tables 'script': arno-iptables-firewall

Hay 170 inputs en /proc/net/ip_conntrack en el server. En la actualidad, 134 de ellos se refieren a una dirección IP que se resuelve como cl59.justhost.com (sugiero que no navegar a ella, por si acaso). No entiendo las inputs de conntrack, y me preocupa que puedan indicar una violación de security.

Detalle

Las 134 inputs en /proc/net/ip_conntrack parecen a esto (mi IP de server sustituida por 192.168.0.1),

 tcp 6 282883 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33053 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33053 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 282877 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33064 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33064 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60963 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60963 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 284392 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=60950 packets=1 bytes=1500 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=60950 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 283131 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33221 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33221 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 283080 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33253 packets=11 bytes=17948 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33253 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 tcp 6 282879 ESTABLISHED src=192.168.0.1 dst=69.175.58.106 sport=80 dport=33208 packets=2 bytes=3000 [UNREPLIED] src=69.175.58.106 dst=192.168.0.1 sport=33208 dport=80 packets=0 bytes=0 mark=0 secmark=0 use=2 

No veo ninguna connection activa en netstat ,

 Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:842 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 192.168.0.1:22 xx.xx.xx.xx:54586 ESTABLISHED tcp6 0 0 :::25 :::* LISTEN tcp6 0 0 :::443 :::* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 192.168.0.1:80 xxx.xx.196.80:30010 TIME_WAIT tcp6 0 0 192.168.0.1:80 xx.xx.13.54:60767 TIME_WAIT tcp6 0 0 192.168.0.1:80 xxx.xx.196.11:33402 TIME_WAIT tcp6 0 0 192.168.0.1:80 xx.xxx.142.192:58280 TIME_WAIT tcp6 0 0 192.168.0.1:80 xx.xxx.142.192:58281 TIME_WAIT tcp6 0 0 192.168.0.1:80 xx.xx.13.54:62025 TIME_WAIT udp 0 0 192.168.0.1:123 0.0.0.0:* udp 0 0 127.0.0.1:123 0.0.0.0:* udp 0 0 0.0.0.0:123 0.0.0.0:* 

El server ejecuta Apache2, PHP5 y tiene un número de blogs wordpress y un solo foro phpBB3 (así como otros pequeños bits aleatorios aquí y allá).

¿Puede alguien arrojar algo de luz sobre una posible fuente para esas conexiones. ¿Son conexiones fallidas / atascadas a mi server a partir de 69.175.58.106 y así no mucho a preocuparse, o son conexiones que salen de mi server a 69.175.58.106 que puede indicar algo siniestro que va encendido?

Si no están en sí mismos y una preocupación, ¿hay una razón por la que no parece que se va?

Actualizar:

Por lo tanto, hizo un poco más de excavación, y el tercer campo en la input es el momento en que la input permanecerá en vivo. Así que por alguna razón, todas estas inputs tienen una vida útil muy grande. Eso explica por qué no se han ido, pero todavía no su causa original, y ahora, cómo se crearon con tan grandes duraciones.

Actualización 2:

Así que más excavaciones me sugieren que las inputs deben leerse como, mi server (192.168.0.1) envió un package a 69.175.58.106, que hasta ahora no ha respondido. Esto me lleva a sospechar 69.175.58.106 datos originalmente solicitados desde el server, y luego desconectado, y iptables ha decidido mantener la input alnetworkingedor de un time.

Aún me interesaría saber si esta evaluación es correcta, o si hay algo más sucediendo.

One Solution collect form web for “Preocupado por el contenido de ip_conntrack”

Derecho, por lo que más de excavación y tengo mi respuesta.

  1. los TTL largos en las conexiones son el pnetworkingeterminado para el kernel y Debian Squeeze que tengo, son alnetworkingedor de 5 días para las conexiones establecidas, y se establecen en /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

  2. Al leer las inputs de conntrack, ahora interpreto que significan, 69.175.58.106 conectado al server web en el puerto 80, y el server web respondió con algunos datos, pero antes de que la connection pudiera ser cerrada, fue simplemente dejada caer por algo entre mi server y 69.175.58.106, o por 69.175.58.106 en sí. Las conexiones cerradas tienen un TTL mucho más corto.

  3. No es posible decir si 69.175.58.106 conectado muchas veces y luego simplemente dejó de comunicarse, o si hubo un problema de networking entre mi server y 69.175.58.106, pero a juzgar por el hecho de que la dirección IP 69.175.58.106 apunta a otro server y no una connection de usuario, estoy inclinado a pensar que algo extraño estaba pasando, pero que en última instancia no causó ningún problema en mi final.

  4. iptstate parece ser una buena herramienta basada en curses para ver los datos de conntrack.

  • Servidor multi-IP: ¿cómo saben los progtwigs qué IP utilizar?
  • Configurar el tráfico saliente para controlar las velocidades de descarga con Linux
  • Puede server de ping, pero no telnet o www
  • Accidentalmente establecer .255 dirección IP - ¿cómo puedo ssh a la máquina?
  • Herramientas Iproute2 vs herramientas conntrack
  • Diagnóstico de pérdida de packages / alta latencia en Ubuntu
  • ¿cuáles son las implicaciones de ejecutar un FQDN como dominio AD interno y punto A-logging para el website a diferentes host?
  • ¿Por qué se está utilizando el model tcp / ip para desarrollar protocolos y no OSI
  • Puerto a otro puerto Ip
  • Cómo boost el tamaño MTU en Linux 2.6?
  • ¿Por qué la característica TCP Chimney Offload en algunas tarjetas ethernet no puede pasar algunos packages de networking al sistema operativo?
  • ¿Hay forms más sencillas de hacer la conformación del tráfico en linux, además de tc?
  • ¿Cómo puedo supervisar el tráfico TCP / IP (o HTTP) de una máquina remota?
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.