Вопросы Теги

пакеты iptables без uid

Я использовал свои чистые знания Perl и написал небольшой скрипт с обработкой ошибок:

/ usr / local / bin / gethostip: 

#!/usr/bin/perl

# inspired by: https://unix.stackexchange.com/questions/71379/host-lookup-that-respects-etc-hosts#71393

use strict;
use Socket;

my $name = $ARGV[0];
if ($name eq '') {
  print STDERR "Usage: gethostip <hostname>\n";
  exit 1;
}
my $ip = inet_aton($name);
die("Unable to resolve host name $name") if ($ip eq '');
my $ipstr = inet_ntoa($ip);
print "$ipstr\n";

Спасибо, Стефану Шазеласу за первоначальную идею

1
26.02.2018, 21:41
1 ответ

Algunos paquetes realmente no pertenecen a ningún usuario, solo al kernel:

  • paquetes enrutados
  • paquetes generados por el kernel en respuesta a eventos externos. por ejemplo, :al recibir una solicitud de eco icmp -, el kernel responderá con una respuesta de eco icmp -.
  • probablemente todos esos paquetes -j REJECT de iptables.
  • ...

Ahora, sobre los paquetes de los que estás hablando :de las pruebas realizadas con el marcado de paquetes con y sin propietario, parecen pertenecer al final ACKal final del FINfinal -de -negociación de comunicación así como el RSTcuando la conexión se corta más abruptamente. Supongo que en ambos casos, el núcleo ya dejó de considerar que la conexión pertenecía al usuario porque la está destrozando, aunque esto no siempre sucedió para el ACK(, ¿quizás cuando se mezcló con PSH y datos finales? ).

ACTUALIZAR :la respuesta a "Iptables :emparejando tráfico saliente con conntrack y propietario. Funciona con caídas extrañas" brinda información más detallada sobre el problema.

Si no quiere perder esos paquetes y aún quiere usar MARK para la decisión, todavía puede confiar en CONNMARK de Netfilter porque el último paquete, incluso sin propietario, sigue siendo parte del misma conexión. Por ejemplo, probar con estas reglas adaptadas de los ejemplos en el enlace:

#!/bin/sh

iptables -t mangle -N connmark_test
iptables -t mangle -N connmark_log
iptables -t mangle -A connmark_test -j CONNMARK --restore-mark
iptables -t mangle -A connmark_test -m mark ! --mark 0 -j RETURN
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999 -p tcp -j MARK --set-mark 1
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999        -j MARK --set-mark 2
iptables -t mangle -A connmark_test -m mark --mark 0                              -p tcp -j MARK --set-mark 3
iptables -t mangle -A connmark_test -m mark --mark 0                                     -j MARK --set-mark 4
iptables -t mangle -A connmark_test -j CONNMARK --save-mark
iptables -t mangle -A connmark_log -m owner --uid-owner 0-99999 -j LOG --log-prefix "with_owner "
iptables -t mangle -A connmark_log -m owner ! --uid-owner 0-99999 -j LOG --log-prefix "  NO_owner "
iptables -t mangle -A POSTROUTING -j connmark_test
iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j connmark_log

Pude ver concurl -s -L https://google.com/ >/dev/null(que hace dos conexiones )que el ACK o RST de la conexión final, que generalmente falla en la coincidencia del propietario, aún tiene una marca de conexión, ya que hayMARK=0x1:

[14668.179780] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=53193 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.181740] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53194 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK FIN URGP=0 MARK=0x1 
[14668.181914]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53195 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK URGP=0 MARK=0x1 
[14668.182667] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=58460 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.184588] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=58461 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK RST URGP=0 MARK=0x1 
[14668.201316]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=20784 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x1

Última nota :No olvide que la actividad de un usuario puede desencadenar paquetes de otro usuario :, por ejemplo, solicitudes DNS a un servidor DNS local, que luego emitirá solicitudes DNS con paquetes propiedad del usuario que ejecuta el servidor DNS.

2
27.01.2020, 23:44

Теги

Похожие вопросы