¿Pueden los paquetes TCP SYN transportar carga útil?

Para el servicio complementario, ¿está cansado de la complicada configuración del servidor?

¿Enviar paquete TCP SYN con carga útil?

Como todos sabemos, los paquetes TCP SYN no pueden transportar carga útil porque:

El número de serie aún no se ha negociado y no se puede determinar el rango de números de serie de los datos.
La ventana de recepción aún no se ha determinado y no sé si se puede recibir la carga útil.
...

Etcétera etcétera…

¡aburrido! En el proceso, realmente odio hablar de estándares. Odio que la gente hable como "Regulaciones RFC ... pero no obligatorias ...", "Intel manual XXX ... pero ...", como "¿Cuántas variables no inicializadas en lenguaje C?" La pregunta es igual de aburrida.

¿No estaría bien intentarlo?

Consulte el código para agregar datos sin procesar al mensaje SYN en el cliente:

#include <linux/module.h>
#include <net/netfilter/nf_conntrack.h>
#include <linux/netfilter/nf_conntrack_common.h>
#include <net/tcp.h>

int port = 22;
module_param(port, int, 0644);

char *templ = NULL;
module_param(templ, charp, 0);

unsigned int knock_out_hook(void *priv, struct sk_buff *skb,
                             const struct nf_hook_state *state)
{
    
    
	struct iphdr *iph = ip_hdr(skb);
	struct tcphdr *th = NULL;
	unsigned int extra, len;
	char *cookie;
	struct sock *sk = skb->sk;

	if (templ == NULL)
		return NF_ACCEPT;

	if (iph->version != 4 || iph->protocol != IPPROTO_TCP)
		return NF_ACCEPT;

	iph = ip_hdr(skb);
	th = (struct tcphdr *)((unsigned char *)iph + (iph->ihl * 4));

	if (ntohs(th->dest) != port)
		return NF_ACCEPT;

	if (!th->syn) // 仅仅处理SYN报文
		return NF_ACCEPT;

	cookie = kmalloc(128, GFP_ATOMIC);
	memcpy(cookie, templ, strlen(templ));
	extra = strlen(templ);
	skb_put(skb, extra);
	memcpy((char *)th + th->doff*4, cookie, extra);
	len = ntohs(iph->tot_len) + extra;
	iph->tot_len = htons(len);
	iph->check = 0;
	ip_send_check(iph);
	if (sk) {
    
     // 重算校验码
		skb_pull(skb, sizeof(struct iphdr));
		inet_csk(sk)->icsk_af_ops->send_check(sk, skb);
		skb_push(skb, sizeof(struct iphdr));
	}

	return NF_ACCEPT;
}

static struct nf_hook_ops knock_out_ops = {
    
    
	.hook     = knock_out_hook,
	.pf       = AF_INET,
	.hooknum  = NF_INET_LOCAL_OUT,
	.priority = NF_IP_PRI_LAST,
};

static int __init knock_init(void)
{
    
    
	if (nf_register_net_hook(&init_net, &knock_out_ops) < 0) {
    
    
		return -1;
	}

	return 0;
}

static void __exit knock_exit(void)
{
    
    
	nf_unregister_net_hook(&init_net, &knock_out_ops);
}

module_init(knock_init);
module_exit(knock_exit);
MODULE_LICENSE("GPL");

OK, vamos, intentémoslo. Primero cargue el módulo compilado por el código anterior en el cliente:

insmod ./padding.ko port=22 templ="ZheJiang_WenZhou_Skinshoe_Wet_Rain_Flooding_Water_Will_Not_Fat"

Entonces encontrará que la conexión SSH iniciada desde este cliente está funcionando: el
Inserte la descripción de la imagen aquí
impresionante "Wenzhou, los zapatos de cuero de Zhejiang están mojados, no engordan con la lluvia" se acolchaban en la parte posterior, oh, obviamente el inglés de esta oración está mal. La traducción correcta debe ser "Zhejiang Wenzhou skinshoe mojado, la lluvia en el agua no puede engordar!"

De manera similar, busque un sistema Win7 como servidor y acceda a telnet en su puerto 5357. Aún funciona:
Inserte la descripción de la imagen aquí
así que, sin importar cuál sea el estándar, puede adivinar que en la mayoría de los casos, esto está bien.

Quizás alguien se sorprende de nuevo:

Cuando no se ha negociado el número de secuencia de TCP, ¿cómo se asegura de que los datos transportados en el paquete SYN puedan llegar de manera confiable?
Cuando no hay una ventana de recepción, ¿cómo se asegura de que el par tenga suficiente espacio para recibir los datos transportados por el paquete SYN?
...

No necesito garantizarlo, ni siquiera necesito que estos datos sean útiles para TCP. Pero sigue siendo útil:

Se puede usar directamente como un mensaje de llamada, por lo que el servidor no necesita una configuración tan complicada de ipset o nf_conntrack.
Puede enviar más información sobre el cliente al servidor antes del protocolo de enlace TCP, lo que afecta la determinación de la opción en SYN / ACK en el servidor.
Se puede utilizar como información fuera de banda del protocolo de enlace de TCP, lo que permite que el servidor comprenda mejor al cliente.
...

¿Puede cada mensaje ACK puro transportar tal pieza de datos de relleno? Por un lado, no es necesario que este tipo de datos llegue de manera confiable para que, por otro lado, puedan existir como datos fuera de banda. La respuesta es obviamente sí.

No defienda los estándares por defender los estándares. Eso es una cuestión académica. La ingeniería siempre da prioridad al pragmatismo.

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

¿Pueden los paquetes TCP SYN transportar carga útil?

Supongo que te gusta