All of lore.kernel.org
 help / color / mirror / Atom feed
* HELP rules nftables conntrack works
@ 2020-09-17 18:56 Luis Mario Niedas Hernández
  2020-09-18  2:22 ` kfm
  0 siblings, 1 reply; 2+ messages in thread
From: Luis Mario Niedas Hernández @ 2020-09-17 18:56 UTC (permalink / raw)
  To: netfilter, Lista cubana de soporte técnico en Tecnologias Libres

Hola. Necesito que me ayuden a comprender como funciona conntrack, sus
estados y como estos estan relacionados con las reglas en nftables.
Voy a mostrarles mi nftables.conf para que me puedan entender.
Hello. I need help to understand how works conntrack, it's state and
how this one is related with the rules in nftables. I will show you my
nftables.conf just so you can understand me.

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
        iifname "lo" accept
        iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh counter
packets 21512 bytes 1833976 accept
        iifname "ens18" ip saddr 192.168.1.0/24 tcp dport 3128 counter
packets 1781072 bytes 216353018 accept
        iifname "ens19" ip saddr 201.220.211.68 tcp sport 3128 counter
packets 2995294 bytes 3960634157 accept
        iifname "ens19" udp sport domain counter packets 33955 bytes
3076365 accept
        iifname "ens19" tcp sport domain counter packets 0 bytes 0 accept
        iifname "ens19" tcp sport http counter packets 41966 bytes
68096526 accept
        iifname "ens19" tcp sport https counter packets 10348 bytes
6399161 accept
        icmp type { echo-reply, echo-request } counter packets 408
bytes 24692 limit rate 1/second accept
        icmp type { echo-reply, echo-request } counter packets 0 bytes 0 drop
        iifname "ens18" ip saddr 192.168.1.0/24 udp dport ntp counter
packets 229 bytes 17404 accept
        iifname "ens19" ip saddr 201.220.222.146 udp sport ntp counter
packets 197 bytes 14972 accept
        iifname "ens19" ip saddr 201.220.222.91 tcp sport {
xmpp-client, 5223 } counter packets 0 bytes 0 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
        oifname "lo" accept
        oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh counter
packets 16396 bytes 2435939 accept
        oifname "ens18" ip daddr 192.168.1.0/24 tcp sport 3128 counter
packets 2469407 bytes 4127574258 accept
        oifname "ens19" ip daddr 201.220.211.68 tcp dport 3128 counter
packets 2082185 bytes 250047659 accept
        oifname "ens19" tcp dport domain counter packets 0 bytes 0 accept
        oifname "ens19" udp dport domain counter packets 34127 bytes
2295099 accept
        oifname "ens19" tcp dport http counter packets 27180 bytes
1721552 accept
        oifname "ens19" tcp dport https counter packets 10387 bytes
2430969 accept
        icmp type { echo-reply, echo-request } counter packets 410
bytes 24808 limit rate 1/second accept
        icmp type { echo-reply, echo-request } counter packets 0 bytes 0 drop
        oifname "ens18" ip daddr 192.168.1.0/24 udp sport ntp counter
packets 229 bytes 17404 accept
        oifname "ens19" ip daddr 201.220.222.146 udp dport ntp counter
packets 201 bytes 15204 accept
        oifname "ens19" ip daddr 201.220.222.91 tcp dport {
xmpp-client, 5223 } counter packets 0 bytes 0 accept
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "ens19" ip saddr 192.168.1.1 udp dport 53 counter
packets 0 bytes 0  snat to 10.16.10.11

    }
}

Yo deseo permitir solo las conexiones que se hagan por el puerto ssh
que vengan desde mi red local (192.168.1.0) hacia mi
firewall(192.168.1.3). Entiendo que el primer paquete que mi servidor
vea, lo pondrá como NEW y que cuando mi servidor responda, se
establecerá la conexión, y entonces el conntrack actualizará la
conexión establecida.

I  want to allow only the connection made by my lan
network(192.168.1.0) against to my firewall(192.168.1.3). I understand
that the first packet that my firewall sees, it's tagged  like a NEW
connection and when my server replies, then the connection will be
tagged like established.

Mi duda sería: cómo implementar la reglas utilizando conntrack?
debería de sustituir esta regla en la cadena input :
My dude will: How i can implement the rules using contrack states? I
should replace the following rule in the input chain

iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh counter packets
21512 bytes 1833976 accept
por::
for  :

iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh  ct state new,
established counter packets 21512 bytes 1833976 accept

o solo esta:
or only this one:

iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh  ct state new
counter packets 21512 bytes 1833976 accept

y en la cadena output entonces modificar esta regla:
and  in the output chain then i should modify this one rule:

oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh counter packets
16396 bytes 2435939 accept
por esta:
for this one:

oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh  ct state
established counter packets 16396 bytes 2435939 accept

La verdad no entiendo como implementar las reglas utilizando los
estados del conntrack, he leído este link
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE
y entiendo los estados de conntrack pero no sé como utilixzarlos. Pido
disculpas por el tiempo que vayan a dedicar a ayudarme. Espero poder
algún día devolver la ayuda recibida. Saludos.

Truly, I don't understand how I can make my rules using the contrack
states. I read this link:
https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE
and i understand the conntrack states concept, but i don't know how to
use it.I apologize for the time you are spending helping me. I hope
one day to return the help received. Regards








-- 
"El futuro tiene muchos nombres. Para los débiles es lo inalcanzable.
Para los temerosos, lo desconocido. Para los valientes es la
oportunidad"
Victor Hugo

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: HELP rules nftables conntrack works
  2020-09-17 18:56 HELP rules nftables conntrack works Luis Mario Niedas Hernández
@ 2020-09-18  2:22 ` kfm
  0 siblings, 0 replies; 2+ messages in thread
From: kfm @ 2020-09-18  2:22 UTC (permalink / raw)
  To: netfilter; +Cc: Luis Mario Niedas Hernández

[-- Attachment #1: Type: text/plain, Size: 6980 bytes --]

On 17/09/2020 19:56, Luis Mario Niedas Hernández wrote:
> Hola. Necesito que me ayuden a comprender como funciona conntrack, sus
> estados y como estos estan relacionados con las reglas en nftables.
> Voy a mostrarles mi nftables.conf para que me puedan entender.
> Hello. I need help to understand how works conntrack, it's state and
> how this one is related with the rules in nftables. I will show you my
> nftables.conf just so you can understand me.
> 
> #!/usr/sbin/nft -f
> 
> flush ruleset
> 
> table inet filter {
>      chain input {
>          type filter hook input priority 0; policy accept;
>          iifname "lo" accept
>          iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh counter
> packets 21512 bytes 1833976 accept
>          iifname "ens18" ip saddr 192.168.1.0/24 tcp dport 3128 counter
> packets 1781072 bytes 216353018 accept
>          iifname "ens19" ip saddr 201.220.211.68 tcp sport 3128 counter
> packets 2995294 bytes 3960634157 accept
>          iifname "ens19" udp sport domain counter packets 33955 bytes
> 3076365 accept
>          iifname "ens19" tcp sport domain counter packets 0 bytes 0 accept
>          iifname "ens19" tcp sport http counter packets 41966 bytes
> 68096526 accept
>          iifname "ens19" tcp sport https counter packets 10348 bytes
> 6399161 accept
>          icmp type { echo-reply, echo-request } counter packets 408
> bytes 24692 limit rate 1/second accept
>          icmp type { echo-reply, echo-request } counter packets 0 bytes 0 drop
>          iifname "ens18" ip saddr 192.168.1.0/24 udp dport ntp counter
> packets 229 bytes 17404 accept
>          iifname "ens19" ip saddr 201.220.222.146 udp sport ntp counter
> packets 197 bytes 14972 accept
>          iifname "ens19" ip saddr 201.220.222.91 tcp sport {
> xmpp-client, 5223 } counter packets 0 bytes 0 accept
>      }
> 
>      chain forward {
>          type filter hook forward priority 0; policy drop;
>      }
> 
>      chain output {
>          type filter hook output priority 0; policy accept;
>          oifname "lo" accept
>          oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh counter
> packets 16396 bytes 2435939 accept
>          oifname "ens18" ip daddr 192.168.1.0/24 tcp sport 3128 counter
> packets 2469407 bytes 4127574258 accept
>          oifname "ens19" ip daddr 201.220.211.68 tcp dport 3128 counter
> packets 2082185 bytes 250047659 accept
>          oifname "ens19" tcp dport domain counter packets 0 bytes 0 accept
>          oifname "ens19" udp dport domain counter packets 34127 bytes
> 2295099 accept
>          oifname "ens19" tcp dport http counter packets 27180 bytes
> 1721552 accept
>          oifname "ens19" tcp dport https counter packets 10387 bytes
> 2430969 accept
>          icmp type { echo-reply, echo-request } counter packets 410
> bytes 24808 limit rate 1/second accept
>          icmp type { echo-reply, echo-request } counter packets 0 bytes 0 drop
>          oifname "ens18" ip daddr 192.168.1.0/24 udp sport ntp counter
> packets 229 bytes 17404 accept
>          oifname "ens19" ip daddr 201.220.222.146 udp dport ntp counter
> packets 201 bytes 15204 accept
>          oifname "ens19" ip daddr 201.220.222.91 tcp dport {
> xmpp-client, 5223 } counter packets 0 bytes 0 accept
>      }
> }
> 
> table ip nat {
>      chain postrouting {
>          type nat hook postrouting priority 100; policy accept;
>          oifname "ens19" ip saddr 192.168.1.1 udp dport 53 counter
> packets 0 bytes 0  snat to 10.16.10.11
> 
>      }
> }
> 
> Yo deseo permitir solo las conexiones que se hagan por el puerto ssh
> que vengan desde mi red local (192.168.1.0) hacia mi
> firewall(192.168.1.3). Entiendo que el primer paquete que mi servidor
> vea, lo pondrá como NEW y que cuando mi servidor responda, se
> establecerá la conexión, y entonces el conntrack actualizará la
> conexión establecida.
> 
> I  want to allow only the connection made by my lan
> network(192.168.1.0) against to my firewall(192.168.1.3). I understand
> that the first packet that my firewall sees, it's tagged  like a NEW
> connection and when my server replies, then the connection will be
> tagged like established.
> 
> Mi duda sería: cómo implementar la reglas utilizando conntrack?
> debería de sustituir esta regla en la cadena input :
> My dude will: How i can implement the rules using contrack states? I
> should replace the following rule in the input chain
> 
> iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh counter packets
> 21512 bytes 1833976 accept
> por::
> for  :
> 
> iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh  ct state new,
> established counter packets 21512 bytes 1833976 accept
> 
> o solo esta:
> or only this one:
> 
> iifname "ens18" ip saddr 192.168.1.0/24 tcp dport ssh  ct state new
> counter packets 21512 bytes 1833976 accept
> 
> y en la cadena output entonces modificar esta regla:
> and  in the output chain then i should modify this one rule:
> 
> oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh counter packets
> 16396 bytes 2435939 accept
> por esta:
> for this one:
> 
> oifname "ens18" ip saddr 192.168.1.0/24 tcp sport ssh  ct state
> established counter packets 16396 bytes 2435939 accept
> 
> La verdad no entiendo como implementar las reglas utilizando los
> estados del conntrack, he leído este link
> https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE
> y entiendo los estados de conntrack pero no sé como utilixzarlos. Pido
> disculpas por el tiempo que vayan a dedicar a ayudarme. Espero poder
> algún día devolver la ayuda recibida. Saludos.
> 
> Truly, I don't understand how I can make my rules using the contrack
> states. I read this link:
> https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE
> and i understand the conntrack states concept, but i don't know how to
> use it.I apologize for the time you are spending helping me. I hope
> one day to return the help received. Regards
> 

The first thing that you should understand is that your sample ruleset 
performs almost no ingress (input) filtering at all. The reason for this 
is that the input chain has a policy of accept. Almost all of the rules 
are of no consequence, because the packet would eventually be accepted 
anyway. Only the rate-limiting ICMP rules are an exception.

Composing a stateful ruleset that utilizes the conntrack system is quite 
easy. For an input-hooking chain, a common approach is to allow all 
packets matching "established" and "related" to pass. Next, you match 
the "new" state to facilitate the opening of any new connections, based 
on your needs. Finally, you drop any packets that have not otherwise 
matched the preceding rules.

I have attached a stateful ruleset that you may use as a template. To 
keep it as simple as possible, it is written in such a way that it only 
performs IPv4 filtering. Nevertheless, it should give you some idea of 
how to proceed.

-- 
Kerin Millar

[-- Attachment #2: nft-stateful-ruleset.txt --]
[-- Type: text/plain, Size: 1561 bytes --]

#!/usr/sbin/nft -f

flush ruleset

table ip filter {
	chain input {
		# Drop by default, otherwise the rules below will be useless.
		type filter hook input priority 0; policy drop;

		# Never block lo
		iifname "lo" accept

		# Allow packets related to an existing flow or valid state to pass.
		ct state established,related accept

		# For packets that would establish a new state, jump to another chain
		# based on the protocol. This is a stylistic choice, intended to keep
		# the input chain short and easy to understand, and to avoid having
		# to repeatedly match the "new" state in the remaining rules.
		ct state new meta l4proto vmap {
			tcp  : jump in_tcp,
			udp  : jump in_udp,
			icmp : jump in_icmp
		}
	}

	chain in_tcp {
		# Define your open TCP services here. If you need to filter by
		# iifname and/or saddr then feel free to do so.
		tcp dport { 22, 53, 80, 443 } accept
	}

	chain in_udp {
		# Define your open UDP services here. If you need to filter by
		# iifname and/or saddr then feel free to do so.
		udp dport { 53 } accept
	}

	chain in_icmp {
		# Allow ping. For IPv4, the established/related rule in the
		# input chain will allow other necessary ICMP packets to pass.
		icmp type echo-request accept
	}

	chain forward {
		# Drop, because no packet forwarding is expected for this host.
		type filter hook forward priority 0; policy drop;
	}

	chain output {
		# Do NOT filter output unless you have a very good reason! In fact,
		# this chain does not need to exist.
		type filter hook output priority 0; policy accept;
	}
}

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-18  2:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-17 18:56 HELP rules nftables conntrack works Luis Mario Niedas Hernández
2020-09-18  2:22 ` kfm

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.