defensa y alta disponibilidad con la nueva generación de ... · mayor configurabilidad de tablas y...
TRANSCRIPT
#CyberCamp18
Defensa y alta disponibilidad con la nueva
generación de firewall de linux
Laura García <[email protected]>
Pablo Neira <[email protected]>
#CyberCamp18
Presentación
▪ Pablo Neira Ayuso
Profesor Univ. Sevilla
Soleta Networks (Spin-off)
Mantenedor Netfilter
▪ Laura García Liébana
CEO Zevenet
Contribuidora Netfilter
#CyberCamp18
1.Infraestructura de Netfilter
2.Camino de datos en Netfilter
3.iptables vs nftables
4.Demo cortafuegos con nftables
5.Capa de compatibilidad
6.Balanceador de carga con nftables
7.Casos de uso de balanceo de carga
Índice
#CyberCamp18
Infraestructura de Netfilter
#CyberCamp18
➔ipchains (1997)
➔iptables (1998)
● arptables
● ebtables
● ip6tables
➔ipset (2000)
➔conntrack-tools (2006)
➔nftables (2013 en kernel 3.13) - versión actual 0.9.0
Historia de Netfilter
5
#CyberCamp18
6
Componentes de Netfilter
#CyberCamp18
Camino de Datos en Netfilter
#CyberCamp18
Camino de Datos en Netfilter
8
#CyberCamp18
Camino de Datos en un servidor con firewall
9
#CyberCamp18
Camino de Datos en un firewall perimetral
10
#CyberCamp18
iptables vs nftables
#CyberCamp18
▪ Simplificación de utilidades
nftables =~ iptables + ip6tables + arptables + ebtables + ipset
# iptables -I INPUT -p tcp --dport 80 -j DROP
# ip6tables -I INPUT -p tcp --dport 80 -j DROP
# ebtables -I INPUT -p tcp --dport 80 -j drop
# arptables ...
nft add rule ip filter input tcp dport 80 drop
- sólo modificar familias: ip6, bridge, arp, inet
Diferencias
12
#CyberCamp18
▪ Mejora la gestión de diferentes stacks (ipv4/6)
iptables -A INPUT -p icmp -j DROP
ip6tables -A INPUT -p icmpv6 -j DROP
nft add rule inet filter input ip protocol icmp drop
nft add rule inet filter input ip6 nexthdr icmpv6 drop
Diferencias
13
#CyberCamp18
▪ Mayor configurabilidad de tablas y cadenas
Con iptables, las tablas y cadenas son creadas por defecto.
# iptables-save
*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -t nat -i wan0 -m tcp --dport 80 -j DNAT --to 1.2.3.4:80
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
Diferencias
14
#CyberCamp18
▪ Mayor configurabilidad de tablas y cadenas,
En nftables creamos las tablas que necesitemos.
table ip nat {
chain pre {
type nat hook prerouting priority dstnat; policy accept;
iifname “wan0” tcp dport 80 dnat to 1.2.3.4:80
}
chain no-ve-trafico {
}
}
Diferencias
15
#CyberCamp18
▪ Mayor facilidad de gestión de tablas y cadenas
Por ejemplo, para la eliminación de tablas
iptables -F -t nat
iptables -X -t nat
iptables -F -t mangle
iptables -X -t mangle nft
flush ruleset
iptables -F -t raw
iptables -X -t raw
iptables -F -t filter
iptables -X -t filter
Diferencias
16
#CyberCamp18
▪ Solventa problemas de diseño en la API de iptables:
- mejora en tiempo cambios incrementales
… no hay que reconstruir el blob
- mejoras en concurrencia
… múltiples procesos compiten por actualizar reglas.
- pérdida de estados internos
… tras actualización de una sola regla, por ejemplo, -m quota
Diferencias
17
#CyberCamp18
▪ Lenguaje más natural y expresivo para reducir número de reglas
iptables -A FORWARD -i “wan0” -o “lan0” -j LOG
iptables -A FORWARD -i “wan0” -o “lan0” \
-m state --state ESTABLISHED,RELATED -j ACCEPT
nft add rule filter forward iifname “wan0” oifname “lan0” \
log ct state established,related accept
Diferencias
18
#CyberCamp18
▪ Estructuras de mapas, conjuntos y mapas de decisión nativos
ip6tables -A INPUT -p icmpv6 \
--icmpv6-type packet-too-big -j ACCEPT
ip6tables -A INPUT -p icmpv6 \
--icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p icmpv6 \
--icmpv6-type echo-reply -j ACCEPT
nft add rule ip6 filter input icmpv6 type {
packet-too-big,
time-exceeded,
echo-reply }
Diferencias
19
#CyberCamp18
▪ Nuevo hook: ingress (x2 más rápido)
- iptables desde prerouting/raw:
iptables -I PREROUTING -t raw -p udp –dport 9 -j DROP
5.999.928pps
- nftables desde ingress:
nft add rule netdev ingress udp dport 9 drop
12.356.983pps
nft add rule netdev ingress udp dport { 1, 2, ..., 384} drop
11.844.615pps
Diferencias
20
#CyberCamp18
▪ Fast path (2,75x más rápido)
Diferencias
21
#CyberCamp18
▪ Implementación con mayor rendimiento
Evita uso de llamadas indirectas (tras Meltdown & Spectre)
Casos Performance
iptables DNAT 256,864 http req/s per core
iptables SNAT 262,089 http req/s per core
nft DNAT 608,941 http req/s per core
nft SNAT 560,976 http req/s per core
nft ingress 7,302,517 http req/s per core
con retpoline habilitado:
iptables: 40.77% penalty
nftables: 17.27% penalty
Diferencias
22
#CyberCamp18
▪ Configuración: Fast path
table ip x {
flowtable f {
hook ingress priority 0; devices = { eth0, eth1};
}
chain y {
type filter hook forward priority 0;
ip protocol tcp flow add @f
}
}
Diferencias
23
#CyberCamp18
▪ Scripting: más amigable
#!/usr/sbin/nft
include "another-ruleset.nft"
define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148,
138.100.62.8 }
add rule ip foo bar ip saddr $ntp_servers udp dport 123 counter
Diferencias
24
#CyberCamp18
▪ Biblioteca nativa para aplicaciones
Evita llamadas a comandos del sistema: system()
#include <nftables/libnftables.h>
struct nft_ctx *ctx = nft_ctx_new(NFT_CTX_DEFAULT);
const char *cmd = “nft flush ruleset; \
nft add rule filter input iifname ‘wan0’ drop”;
nft_run_cmd_from_buffer(ctx, cmd, strlen(cmd));
nft_ctx_free(ctx);
Diferencias
25
#CyberCamp18
nft add rule ip foo bar tcp dport { 22, 80, 443 } counter
nft add set ip foo whitelist { type ipv4_addr \; }
nft add rule ip foo bar ip daddr @whitelist counter accept
nft add element ip foo whitelist { \
192.168.0.1, \
192.168.0.10 \
}
Ejemplo: Creando whitelist
26
#CyberCamp18
nft add table ip nat
nft add chain ip nat post { \
type nat hook postrouting priority 0\; }
nft add rule ip nat post snat ip saddr map { \
1.1.1.0/24 : 192.168.3.11 , \
2.2.2.0/24 : 192.168.3.12 \
}
Ejemplo: Mapeo NAT
27
#CyberCamp18
nft add set ip foo whitelist { type ipv4_addr; timeout 1h; }
nft add element ip foo whitelist { \
192.168.2.123,
192.168.2.124,
}
nft add set ip foo whitelist { type ipv4_addr; flags timeout; }
nft add element ip foo whitelist { 192.168.2.123 timeout 10s }
nft add rule ip foo update @whitelist { ip saddr timeout 30s }
Ejemplo: Whitelist dinámico con timeouts
28
#CyberCamp18
nft add chain ip foo tcp-chain
nft add chain ip foo udp-chain
nft add chain ip foo icmp-chain
nft add rule ip foo bar ip protocol vmap { \
tcp : jump tcp-chain, \
udp : jump udp-chain, \
icmp : jump icmp-chain
}
Ejemplo: Diccionarios
29
#CyberCamp18
nft add rule netdev foo bar ip saddr . tcp dport vmap { \
192.168.1.123 . 22 : jump whitelist_chain, \
192.168.1.123 . 80 : jump whitelist_chain, \
}
nft add set netdev foo test { type ether_addr . ipv4_addr \; }
nft add element netdev foo test { \
00:ca:fe:00:be:ef . 192.168.1.123,
00:ab:cd:ef:00:12 . 192.168.1.124 \
}
nft add rule netdev foo bar ether saddr . ip saddr @test accept
Ejemplo: Concatenaciones
30
#CyberCamp18
nft add rule ip foo bar ip daddr 8.8.8.8 counter accept \
comment \“google dns\”
nft add set ip foo dns-whitelist {\
type ipv4_addr\;
}
nft add element ip foo dns-whitelist { \
8.8.8.8 comment “google dns”, \
192.203.230.10 comment “nasa dns”,
}
Ejemplo: Comentarios en las reglas y sets
31
#CyberCamp18
nft add counter filter http-traffic
nft add rule filter output tcp dport https counter name http-traffic
nft add rule filter output counter name tcp dport map { \
443 : "https-traffic", \
80 : "http-traffic", \
22 : “ssh-traffic”, \
25 : "smtp-traffic", \
}
Ejemplo: Contadores y cuota con nombre
32
#CyberCamp18
nft add map filter mystats { type ipv4_addr : counter \; }
nft add rule filter input counter name ip saddr map @mystats
nft add counter filter computer1
nft add counter filter computer2
nft add element filter mystats { 192.168.2.3 : "computer1" }
nft add element filter mystats { 192.168.2.4 : "computer2" }
Ejemplo: Mapas con contadores con nombres
33
#CyberCamp18
Demo cortafuegos con nftables
#CyberCamp18
Entorno de Demo
cliente
192.168.43.0/24
fw-lb
if0: 192.168.43.108/24
if1: 192.168.100.1/24
backend1
192.168.100.10/24
gw: 192.168.100.1
backend2
192.168.100.11/24
gw: 192.168.100.1
#CyberCamp18
Capa de Compatibilidad
#CyberCamp18
▪ iptables-translate
s/iptables/iptables-translate & s/ip6tables/ip6tables-translate
# iptables-translate -A INPUT -p tcp --dport 22 \
-m conntrack --ctstate NEW -j ACCEPT
nft add rule ip filter INPUT tcp dport 22 ct state new counter accept
# ip6tables-translate -A FORWARD -i eth0 -o eth3 -p udp \
-m multiport --dports 111,222 -j ACCEPT
nft add rule ip6 filter FORWARD iifname eth0 oifname eth3 meta l4proto udp udp
dport { 111,222 } counter accept
Utilidades de traducción
37
#CyberCamp18
Capa de compatibilidad
38
#CyberCamp18
▪ nft compat para uso nftables con sintaxis de iptables
iptables en espacio de usuario, nftables en espacio del kernel
Capa de compatibilidad
39
# iptables-nft -A FORWARD -p icmp -j
ACCEPT
# iptables-nft-save
*filter
:INPUT ACCEPT [62:3777]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [62:4074]
-A FORWARD -p icmp -j ACCEPT
COMMIT
# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}
chain FORWARD {
type filter hook forward priority 0; policy accept;
ip protocol icmp counter packets 0 bytes 0 accept
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
#CyberCamp18
Demo de capa de compatibilidad
#CyberCamp18
Balanceador de Carga con nftables
#CyberCamp18
LVS:
infraestructura duplicada con netfilter, chequeos en espacio de usuario,
no preparado para ciertos casos de uso como puede ser proxy
transparente, multipuerto, multi-protocolo, etc. Soporta sNAT, TUN y
DSR, pero no dNAT.
iptables:
sNAT, sNAT pero no DSR, diferentes binarios para diferentes stacks, se
requieren muchas reglas (al menos ~2/servidor), tratamiento secuencial
de reglas y problemas de bloqueo.
Opciones de alta disponibilidad
42
#CyberCamp18
Diseño de nftlb
43
libnftable
s
netfilter datapath (DSR/SNAT/DNAT/STLS DNAT)
#CyberCamp18
▪ Soporta las topologías sNAT, dNAT (con y sin estado) y DSR
▪ Manejo de multipuerto y multiprotocolo de forma nativa
▪ Soporte de tráfico IPv4 e IPv6
▪ Los servicios virtuales están indexados con vmaps, no necesita
tratamiento secuencial de reglas
▪ Programadores: weight, round robin, hash and symmetric hash
Propiedades desde el camino de datos
44
#CyberCamp18
▪ Demonio en espacio de usuario
▪ Optimiza el número de reglas y aislamiento de cadenas por servicio
▪ Soporta múltiples virtual services
▪ Soporte de prioridad por servidor
▪ Gestión remota mediante API JSON y socket HTTP
▪ Key de seguridad
Y en el camino de control
45
#CyberCamp18
Demo de balanceo de carga
#CyberCamp18
GRACIAS