Desacreditar la broma para reconstruir la conexión entre la conexión TCP y el proceso

Es hora de exponer el truco.

Primero lea lo siguiente:
https://blog.csdn.net/dog250/article/details/108113329

De acuerdo con el truco descrito en el artículo, pirateemos la atribución de la conexión tcp de los dos procesos. Primero, proporcionemos la escena antes del pirateo:

[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.56.110:22       192.168.56.1:55287      ESTABLISHED 1344/sshd: root@pts
tcp        0      0 192.168.56.110:22       192.168.56.1:55589      ESTABLISHED 4791/sshd: root@pts

Luego, después de implementar el hack, se intercambia la conexión tcp a la que pertenece el proceso:

[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.56.110:22       192.168.56.1:55287      ESTABLISHED 4791/sshd: root@pts
tcp        0      0 192.168.56.110:22       192.168.56.1:55589      ESTABLISHED 1344/sshd: root@pts

Si la operación y el mantenimiento del sistema u otros administradores se encuentran con una situación de este tipo, ¿a qué proceso deberían apuntar para depurar?

Tenga en cuenta ⚠️, tenemos que abandonar la presuposición posterior al evento. De hecho, no pueden darse cuenta de que la conexión se ha intercambiado. Es posible que no se den cuenta de que algo anda mal después de mucho tiempo después de reunir a muchas personas para una reunión.

Si yo estuviera ahí, este tipo de cosas no pasarían. Como artesano, prefiero enfrentar la esencia directamente en lugar de usar herramientas para desviarme. En mi opinión, encontrar la conexión entre la conexión tcp y el proceso a través de procfs es rotonda.

¿Por qué no señalarlo?

Considere el siguiente diagrama:
Inserte la descripción de la imagen aquí
Si la pieza pasa por unas pistas no removibles para asociar tcp_sock y socket, sin tener que desviarlo no?

Bien, el siguiente código describe cómo hacerlo:

#!/usr/bin/stap -g
// tcpstat(.stp)

%{
    
    
#include <net/tcp.h>
#include <linux/fdtable.h>

struct result {
    
    
	char laddr[16];
	char raddr[16];
	unsigned short	lport;
	unsigned short	rport;
	unsigned long	ino;
	int pid;
	char comm[32];
};

static inline void ip2str(char *to, unsigned int from)
{
    
    
	int size = snprintf(to, 16, "%pI4", &from);
	to[size] = '\0';
}

void traverse(struct sock *sk, unsigned long ino, struct result *ret)
{
    
    
	struct task_struct *tsk;
	int i;

	for_each_process(tsk) {
    
    
		struct file *file;
		for (i = 0; i < tsk->files->fdt->max_fds; i++) {
    
    
			file = tsk->files->fdt->fd[i];
			if (file == NULL) {
    
    
				continue;
			}
			if (file->f_inode->i_ino == ino) {
    
    
				char laddr[16], raddr[16];

				ip2str(laddr, inet_sk(sk)->inet_rcv_saddr);
				ip2str(raddr, inet_sk(sk)->inet_daddr);

				memcpy(&ret->laddr[0], laddr, 16);
				memcpy(&ret->raddr[0], raddr, 16);
				ret->lport = sk->sk_num;
				ret->rport = htons(sk->sk_dport);
				ret->ino = ino;
				ret->pid = tsk->pid;
				memcpy(&ret->comm[0], tsk->comm, 32);
			}
		}
	}
}
%}

function dump_tcp_info()
%{
    
    
	struct task_struct *tsk;
	struct inet_hashinfo *hashinfo = &tcp_hashinfo;
	struct hlist_nulls_node *node;
	struct socket_alloc *sa;
	struct sock *sk;
	struct result ret;
	int i, ino;

	for (i = 0; i < INET_LHTABLE_SIZE; i++) {
    
    
		struct inet_listen_hashbucket *ilb;

		ilb = &hashinfo->listening_hash[i];
		sk_nulls_for_each(sk, node, &ilb->head) {
    
    
			unsigned long ino;

			sa = (struct socket_alloc *)sk->sk_socket;
			ino = sa->vfs_inode.i_ino;

			traverse(sk, ino, &ret);
			STAP_PRINTF("LISTEN %s:%d  inode:%d/[%d] %s\n",
						ret.laddr,
						ret.lport,
						ret.ino,
						ret.pid,
						ret.comm);
		}
	}

	for (i = 0; i <= hashinfo->ehash_mask; i++) {
    
    
		struct inet_ehash_bucket *head = &hashinfo->ehash[i];

		if (hlist_nulls_empty(&head->chain)) {
    
    
			continue;
		}

		sk_nulls_for_each(sk, node, &head->chain) {
    
    
			unsigned long ino;

			sa = (struct socket_alloc *)sk->sk_socket;
			ino = sa->vfs_inode.i_ino;

			traverse(sk, ino, &ret);
			STAP_PRINTF("ESTABLISHED %s:%d  %s:%d inode:%d/[%d] %s\n",
						ret.laddr,
						ret.lport,
						ret.raddr,
						ret.rport,
						ret.ino,
						ret.pid,
						ret.comm);
		}
	}
%}

probe begin
{
    
    
	dump_tcp_info();
	exit();
}

Vamos, ejecutemos el script anterior para intentar descubrir la verdad sobre el sistema pirateado:

[root@localhost test]# ./tcpstat
LISTEN 0.0.0.0:22  inode:22852/[1001] sshd
LISTEN 0.0.0.0:22  inode:22850/[1001] sshd
ESTABLISHED 192.168.56.110:22  192.168.56.1:55287 inode:25510/[1344] sshd
ESTABLISHED 192.168.56.110:22  192.168.56.1:55589 inode:28747/[4791] sshd

Utilice este resultado para comparar la situación después de haber sido pirateado:

[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.56.110:22       192.168.56.1:55287      ESTABLISHED 4791/sshd: root@pts
tcp        0      0 192.168.56.110:22       192.168.56.1:55589      ESTABLISHED 1344/sshd: root@pts

¡Jaja, la verdad se revela!

¿Qué es un artesano? No confíe en herramientas a gran escala, no confíe en el conocimiento profesional, repare macetas en pueblos pequeños sin rastros. Por supuesto, también se pueden fabricar zapatos de cuero.


Los zapatos de cuero en Wenzhou, Zhejiang están mojados, por lo que no engordan con la lluvia.

Supongo que te gusta

Origin blog.csdn.net/dog250/article/details/108134813
Recomendado
Clasificación