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
#!/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;
}
}
