Averigüe qué software de Linux está intentando llamar a casa

4

He visto algunas comunicaciones salientes sospechosas bloqueadas en mi VPS, que aloja un sitio web experimental pequeño, y quiero saber qué aplicación está haciendo el intento. El servidor ejecuta CentOS y estoy usando iptables para el firewall. Aquí hay un extracto de mi conjunto de reglas de iptables:

# create a new chain for rejecting certain ip addresses  
-N input_tcp_deny  
-A input_tcp_deny -m limit --limit 5/min -j LOG --log-prefix "tcp/ip input denied " --log-level 6  
-A input_tcp_deny -j REJECT  

# create a new chain for rejecting certain ip addresses  
-N output_tcp_deny  
-A output_tcp_deny -m limit --limit 5/min -j LOG --log-prefix "tcp/ip output denied " --log-level 4  
-A output_tcp_deny -j REJECT  

-A INPUT -p tcp -s 171/8 -j input_tcp_deny  
-A OUTPUT -p tcp -d 171/8 -j output_tcp_deny  
-A INPUT -p tcp -s 141/8 -j input_tcp_deny  
-A OUTPUT -p tcp -s 141/8 -j output_tcp_deny  
-A INPUT -p tcp -s 103/8 -j input_tcp_deny  
-A OUTPUT -p tcp -d 103/8 -j output_tcp_deny  
La salida de

iptbles -nvL muestra:

Chain output_tcp_deny (91 references)  
 pkts bytes target     prot opt in     out     source               destination  
    6   120 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 4 prefix 'tcp/ip output denied '  
    6   120 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable  

Al mirar en el archivo de registro de iptables se muestra:

Apr  9 00:19:25 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=171.64.65.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=15407 DF PROTO=TCP SPT=46898 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr  9 00:19:25 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00   ACK SYN URGP=0  
Apr  9 00:19:25 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.219.155.233 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=54760 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=171.64.65.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=15408 DF PROTO=TCP SPT=46898 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.219.155.233 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=54760 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:55 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:55 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.216.10.182 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=53542 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:56 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:56 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:58 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=103.25.63.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43399 DF PROTO=TCP SPT=45638 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:48:58 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:59 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=103.25.63.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43400 DF PROTO=TCP SPT=45638 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:49:01 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=163.178.174.25 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59335 DF PROTO=TCP SPT=37733 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:49:02 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=163.178.174.25 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59336 DF PROTO=TCP SPT=37733 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

Buscando direcciones IP para comunicaciones salientes bloqueadas:
 - 171.64.65.117 stanford.edu
 - 103.25.63.44 Centro de datos al por mayor de Hong Kong LLC

Las comunicaciones entrantes bloqueadas sucedieron muy cerca en el tiempo, así que también busqué:  - 141.214.186.162 Universidad de Michigan
 - 141.219.155.233 mtu.edu (Universidad de Michigan)
 - 141.216.10.182 umflint.edu (Universidad de Michigan)

Para cualquier persona que tenga curiosidad, también tengo IPV6 completamente bloqueado (pero sin registros) y lo he visto desde ip6tables -nvL :

Chain OUTPUT (policy DROP 8 packets, 536 bytes)  

Tengo fechas, horarios y direcciones ip. Pero ahora me gustaría saber qué software de código abierto está haciendo esto.

    
pregunta John L 16.04.2014 - 05:58
fuente

4 respuestas

2

Si tiene instalado auditd, puede usarlo para registrar conexiones:

auditctl -a exit,always -F arch=b64 -S connect -k NETWORK

Si tiene un sistema operativo de 32 bits, use b32 en lugar de b64.

Ahora debería poder buscar en sus archivos de registros de auditoría en / var / log / para encontrar los procesos que establecen conexiones salientes.

Desafortunadamente, el archivo audit.log es un poco críptico. Aquí hay un ejemplo de mis registros después de ejecutar "nc 8.8.8.8 53":

type=SYSCALL msg=audit(1401890039.928:1080289): arch=c000003e syscall=42 success=no exit=-115 a0=3 a1=df3310 a2=10 a3=7fffd8db6910 items=0 ppid=7310 pid=7725 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=pts5 comm="nc" exe="/bin/nc.openbsd" key="NETWORK"
type=SOCKADDR msg=audit(1401890039.928:1080289): saddr=02000035080808080000000000000000

En la línea type = SYSCALL, puede ver el id del proceso, el cmd "/bin/nc.openbsd" e información sobre el uid que ejecuta el proceso. En la línea type = SOCKADDR, tiene el campo saddr que contiene información sobre la conexión ip / tcp:

02000035080808080000000000000000

02 = IP
35 = Port 53
08080808 = 8.8.8.8

Si desea buscar la dirección IP 163.178.174.25, puede hacer lo siguiente en Python para obtener la representación hexadecimal de esta ip.

$ python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct, socket
>>> "%x" % struct.unpack("<L", socket.inet_aton("163.178.174.25"))[0]
'19aeb2a3'

Luego, puede grep el audit.log para las ocurrencias de esta cadena hexadecimal para encontrar la aplicación ofensiva.

Y finalmente, cuando haya finalizado la depuración, recuerde desactivar la regla auditd, ya que puede producir una cantidad justa de registros.

auditctl -d exit,always -F arch=b64 -S connect -k NETWORK

¡Feliz piratería!

Crédito a las respuestas en serverfault:

enlace

enlace

    
respondido por el Dog eat cat world 04.06.2014 - 16:13
fuente
0

Puedes usar un bucle para llamar continuamente a lsof para ver todas las conexiones de red abiertas, registrarlo en un archivo y luego ir a través de él para el puerto 80. Eso te mostraría el proceso de apertura del socket y el usuario que está ejecutando.

Podría ir algo como:

#!/bin/bash
# monitor.sh
while true; do
    date
    lsof -i -P
    sleep 1
done

Para usarlo:

$ chmod +x monitor.sh
$ sudo ./monitor.sh > connections.log 

Para comprobarlo:

$ grep ":80 (" connections.log

Al incluir "(" en el patrón de grep para coincidir con la salida de lsof, grep solo debe coincidir en las conexiones salientes al puerto 80.

Me gustaría grep el registro cada dos horas y también lo probaría primero para asegurarme de que el archivo de registro no fuera demasiado grande y ocupara todo el espacio de mi disco.

    
respondido por el Creek 22.04.2014 - 18:13
fuente
0

Además de las otras buenas respuestas (auditd en particular), su situación puede requerir lo siguiente:

  1. Elimine el parámetro --ulimit de iptables, para asegurarse de que no está perdiendo ninguna conexión
  2. Redirige los registros a un archivo de registro diferente o incluso mejor a un servicio de registro
  3. Configure syslog para capturar esa instalación y redirigir a una tubería (vea este enlace para un ejemplo)
  4. Escriba un script de shell que lea el contenido de la canalización y al recibir un evento:
    1. ejecuta lsof o netstat -nalp para capturar PID y binarios ofensivos
    2. inicia una sesión tcpdump para capturar el tráfico
    3. te envía un correo electrónico para que puedas actuar rápidamente :)

Mi apuesta está en un software inofensivo, como un concurso de popularidad , un demonio NTP o una actualización de software. ¡Todavía tengo curiosidad, así que manténganos actualizados por favor!

    
respondido por el lorenzog 04.06.2014 - 16:34
fuente
-1

Habiendo evaluado el riesgo de apagar mis iptables por unos minutos, estos serían mis primeros pasos:

  1. detenga el proceso iptables para permitir que la aplicación de código abierto inicie una conexión a casa (nuevamente, solo si se siente seguro al hacer esto)
  2. ejecuta netstat -lntp | less . Esta lista debe indicarle las direcciones IP de destino a las que se conecta su buzón. Si encuentra las que mencionó anteriormente, intente buscar el ID de proceso (PID) para esa conexión.
  3. ejecuta ps aux | less . Intente y localice el mismo PID que encontró en el paso 2 anterior. Puede que tenga que investigar un poco y jugar con las opciones de este comando. Esta página puede ser útil.
  4. reiniciar iptables
  5. reinicia el servidor (puede que no sea necesario, pero a veces eso es lo que se necesita para que el código abierto vuelva a llamar a casa, a menos que ya sepas que la llamada a casa es constante)
  6. vuelva a comprobar los registros iptables . Los siguientes pasos dependerán de sus hallazgos aquí.

Como solo ha preguntado cómo identificar , en lugar de bloquear este tráfico, me detendré aquí; Esperemos que esto te ayude un poco.

    
respondido por el Lex 16.04.2014 - 13:28
fuente

Lea otras preguntas en las etiquetas