Dotaz: IPtables / nftables a "nesouvislá" subnet mask (vyhodnocení adres podle bitů)

[TajnejAgent]

Čus všem, potřeboval bych poradit od znalců firewallů.

Mám IPv4 síť rozdělenou do několika subnetů (každý subnet odpovídá geografické lokalitě) a každý tento subnet se dál dělí podle VLAN. To znamená, že dělení sítě vypadá takhle nějak:

• 10.1.1.0/24 jsou pracovní stanice v Aši
• 10.1.2.0/24 jsou servery v Aši
• 10.1.3.0/24 jsou specifická zařízení v Aši
• 10.2.1.0/24 jsou pracovní stanice v Broumově
• 10.2.2.0/24 jsou servery v Broumově
• 10.2.3.0/24 jsou specifická zařízení v Broumově
• atd.

Komunikace mezi subnety teče přes firewally, na kterých bych rád měl pravidlo àla "všechny pracovní stanice bez ohledu na lokalitu", tedy match na každou IP adresu ve tvaru 10.*.1.*. V iptables jsem to zkusil zapsat přes netmask takhle:

iptables -A --source 10.0.1.0/255.0.255.0 -j NECO

ale to pochopitelně nefunguje, protože netmask musí být souvislá řada bitů.

Existuje v iptables nebo v nftables způsob (např. nějaký modul), který by uměl adresy vyhodnocovat podle konkrétních bitů?

Odpovědi

[X]

Bud a] si muzes treba vyrobit set:

define WORKSTATION = { 10.1.1.0/24, 10.2.1.0/24, 10.3.1.0/24... }

b] nebo si to cele naskriptovat.

[TajnejAgent]

Skriptování jsem už zavrhl v minulosti - jednak vnáší nestandardní prvek do procesu správy, takže dochází k lidským chybám, jednak neřeší přehlednost a čitelnost nasazených pravidel.

Za tip na použití setů děkuju, to už se trochu blíží tomu, co potřebuju (tzn. mít jedno pravidlo na více subnetů), akorát pořád je potřeba udržovat definici subnetu jako seznam, kterej je od určitého počtu subnetů dost nepřehlednej. Tady mi už ale dává smysl skriptem generovat aspoň šikovně pojmenované sety a na ty se pak odkazovat v samotných pravidlech. To už se dá zvládnout i z hlediska lidského faktoru

[xxl]

A nemělo by tam být také napsáno, do jakého chainu se to má přidat?

iptables -A INPUT --source 10.0.1.0/255.0.255.0 -j NECO

Protože jinak se mi zdá, že to funguje.

[X]

Nebude se ta posledni 255 ignorovat?

[xxl]

Zkusil jsem to a zdá se mi, že ne. Že to normálně běhá.

Ale jak to zapsat pro nftables, to tedy nevím.

[TajnejAgent]

Jasně, chain mi chyběl - původní dotaz jsem psal z ruky na mobilu cestou do kanclu.

Každopádně jsem z toho trochu jelen. Že by to mělo fungovat, jsem mezitím našel i na serverfault.com (to je tak, když se člověk na něco zeptá, porovnají se mu myšlenky a najednou se mu rozsvítí, co dát do Googlu), tak jsem to zkusil u sebe, ne zcela úspěšně:

# iptables -A INPUT --source 10.0.1.0/255.0.255.0 -j ACCEPT
# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       10.0.0.0/8           0.0.0.0/0           
(...)

Jinými slovy to dopadlo tak, jak píše X výše, tzn. že druhou 255 to ignorovalo. A aby to bylo ještě lepší, nedaří se mi zreplikovat to chování, kdy jsem zadal pravidlo s "děravou" netmask a iptables mě poslaly do háje, že to neuměj.

[xxl]

iptables -A

přidá pravidlo na konec řetězce, takže ve výpisu, tak jak ho máš, nebude...

[xxl]

A navíc ti to první pravidlo zachytí všechny pakety pro "zájmové" sítě, takže na tom konci chainu nezachytíš už nic.

[TajnejAgent]

Nn, výstup, kterej jsem postnul výše, je z čisté virtuálky, tzn. to jedno pravidlo, co tam je vidět, je opravdu výsledkem toho iptables -A. Za tři tečky jsem schoval jen FORWARD a OUTPUT, žádná další INPUT pravidla. Pro přehlednost ještě jednou bez čištění:

[2022-03-16 11:35:58] root@srv1.lab3a.local:~# iptables -A INPUT --source 10.0.1.0/255.0.255.0 -j ACCEPT
[2022-03-16 11:36:16] root@srv1.lab3a.local:~# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       10.0.0.0/8           0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

[X]

To je zajimave ja to mam jinak:

iptables -A INPUT --source 10.0.1.0/255.0.255.0 -j DROP

iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  10.0.1.0/255.0.255.0  0.0.0.0/0  

[xxl]

root@localhost: #iptables -F
root@localhost: #iptables -A OUTPUT --dst 192.0.192.0/255.0.255.0 -j ACCEPT
root@localhost: #iptables -A OUTPUT --dst 192.0.203.0/255.0.255.0 -j ACCEPT
root@localhost: #iptables -A OUTPUT --dst 192.0.0.1/255.0.0.255 -j ACCEPT
root@localhost: #iptables -A OUTPUT --dst 192.0.1.0/255.0.255.0 -j ACCEPT
root@localhost: #ping 192.168.192.1 -c 2 -q
PING 192.168.192.1 (192.168.192.1) 56(84) bytes of data.

--- 192.168.192.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 40ms
rtt min/avg/max/mdev = 0.816/0.866/0.917/0.058 ms
root@localhost: #ping 192.168.203.1 -c 3 -q
PING 192.168.203.1 (192.168.203.1) 56(84) bytes of data.

--- 192.168.203.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 97ms
rtt min/avg/max/mdev = 0.771/1.025/1.433/0.292 ms
root@localhost: #ping 192.168.1.42 -c 5 -q
PING 192.168.1.42 (192.168.1.42) 56(84) bytes of data.

--- 192.168.1.42 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 131ms
rtt min/avg/max/mdev = 0.439/0.655/1.332/0.341 ms
root@localhost: #ping 192.168.208.1 -c 7 -q
PING 192.168.208.1 (192.168.208.1) 56(84) bytes of data.

--- 192.168.208.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 108ms
rtt min/avg/max/mdev = 0.819/1.266/1.920/0.418 ms
root@localhost: #ping 192.168.207.101 -c 11 -q
PING 192.168.207.101 (192.168.207.101) 56(84) bytes of data.

--- 192.168.207.101 ping statistics ---
11 packets transmitted, 0 received, +11 errors, 100% packet loss, time 345ms
pipe 4
root@localhost: #iptables -nvL
Chain INPUT (policy ACCEPT 33 packets, 3000 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 11 packets, 924 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   168 ACCEPT     all  --  *      *       0.0.0.0/0            192.0.192.0/255.0.255.0
    3   252 ACCEPT     all  --  *      *       0.0.0.0/0            192.0.203.0/255.0.255.0
    7   588 ACCEPT     all  --  *      *       0.0.0.0/0            192.0.0.1/255.0.0.255
    5   420 ACCEPT     all  --  *      *       0.0.0.0/0            192.0.1.0/255.0.255.0
root@localhost: #

[TajnejAgent]

Jako máš verzi iptables pls?

[xxl]

iptables v1.8.2 (legacy)

[TajnejAgent]

Tak tohle už vypadá líp i u mně:

[2022-03-16 13:21:53] root@srv1.lab3a.local:~# iptables-legacy -A INPUT --source 10.0.1.0/255.0.255.0 -j ACCEPT
[2022-03-16 13:22:08] root@srv1.lab3a.local:~# iptables-legacy -L -v -n
Chain INPUT (policy ACCEPT 70 packets, 5664 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       10.0.1.0/255.0.255.0  0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 57 packets, 5528 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[2022-03-16 13:22:15] root@srv1.lab3a.local:~# iptables-legacy --version
iptables v1.8.7 (legacy)

Tím mám v podstatě vyřešeno, celý můj problém byl v použití iptables-nft. Sice nftables nejdou úplně ignorovat a musím hledat řešení i pro ně, ale to už mě teď nepálí tolik.

Díky moc!

[j]

Mrkni sem https://man7.org/linux/man-pages/man8/iptables-extensions.8.html

Mas tam seznam vsemoznych extenzi, trebas najdes neco co by vyhovelo ... jinak tvuj problem === spatny navrh adresovani.

Pokud si pamatuju spravne, melo by na to jit pouzit u32, ale vykon bude meh ...

---

Dete s tim guuglem dopice!

[TajnejAgent]

Zkoušel jsem to projít, nadějný mi přišel IPMARK target, ale tam se zjevně mám ještě hodně co učit.

Pokud jde o špatný návrh adresování, jak by to teda mělo vypadat správně, aby se zachovalo členění na dvou osách, které obě mají význam? Ne, že bych byl úplně kovanej, ale napadá mě leda prohodit pořadí segmentů, tzn. 10.1.*.* by byly všechny pracovní stanice, 10.2.*.* servery apod. a 10.*.1.* by byl Aš, 10.*.2.* Broumov atd. V tu chvíli se "všechny pracovní stanice" napíšou jako 10.1.0.0/16, což je super, ale původní problém najednou řeším u "všechno v Aši" apod., navíc mi tak vedle některých FW pravidel bobtnají i routovací tabulky. Je nějakej lepší způsob, jak adresování řešit?

[j]

Moznosti je vic, jednak je treba se zamyslet, co je a co neni nutny*, druhak si psal, ze tam mas vlany, takze se uplne stejne jako s rozsahem Ipcek da pracovat s rozsahem vlanu. Dalsi moznost kterou muzes vyuzit je mangle + mark. To bude IMO porad levnejsi, nez vymejslet nejaky binarni maskovani.

Dalsi moznosti je to ze stroj muze mit vic IPcek z ruznych rozsahu. Jde o to, ze na routeru bys mel proste minimalizovat jak pocet, tak slozitost pravidel, a jakmile zacnes pouzivat nektery mene bezny konstrukce, tak jde vetsinou pekne dorite vykon. Pokud mas provoz v mbitech, tak se to prevazne nijak neprojevi, ale kdyz se posunes do stovek mbit nebo gbit, tak to zacne byt teprve sranda.

*pro pripomenuti, v historii by se tu zcela jiste nasel blbec, kterej vysvetloval, jak mu 16 bitu v ipv6 nestaci na adresovani site, protoze ma routeru 30, a kazdej bit chce pouzit jako odbocku 0/1 ...

---

Dete s tim guuglem dopice!

[X]

S dobrou SDN automatizaci by to slo "bez prace" filtrovat uz na pobockach a odlehcit tak centralnimu firewallu.

[TajnejAgent]

Tak to si asi docela rozumime, akorat jsem presvedcenej, ze bitwise maskovani je prave ten nejlevnejsi zpusob reseni. Z hlediska vypocetniho vykonu je AND operace nad dvema registry jen jedna procesorova instrukce, neumim si predstavit levnejsi pristup, IMHO se přesně takhle vyhodnocujou i klasický souvisly netmasky, nejen ve firewallu, ale i pri routovani. Celkove se to v uspornym programovani pouziva dost casto. Tzn. V principu slo jen o to, aby se vyhodnoceni netmasky delalo bez omezujiciho predpokladu, kterej je potreba pro routovani, ale uz ne nutne pro filtrovani. Taky se nakonec ukazalo, ze iptables “nesouvisle” masky umi a nftables ma dokonce jeste flexibilnejsi operatory - viz muj souhrn na konci tehle diskuse. Mangle + MARK bych si tipnul, ze bude srovnatelne vypocetne narocny, ale bitova maska mne osobne pripada jednodussi na spravu a prehlednejsi, takze si mangle + mark necham na komplexnejsi situace. Ve vysledku jsem dosahl presne toho, co pises: minimum pravidel v routovaci tabulce, zaroven minimum pravidel ve firewallu (dokonce min, nez s pouzitim mark) a navic jeste s mnimem vyhodnocovanych kriterii (tzn. Staci mi pracovat s adresou, nemusim jako berlicku pouivat VLAN).

Jinak pokud jde o pana s 30 routerama - vidim, ze jsem za dobu, co jsem t moc nebyl, prisel o spoustu srandy :)

[TajnejAgent]

U32 taky velmi zajímavý. Asi to není úplně to, jak bych si to řešení představoval, ale rozhodně jsem si teď rozšířil obzory, díky za to.

[TajnejAgent]

Hmm. Pak navrhuju, abysme si přeměřili verze!

[2022-03-16 12:53:27] root@srv1.lab3a.local:~# iptables --version
iptables v1.8.7 (nf_tables)

Už od nálezu toho dotazu na serverfault.com mám podezření, že iptables by to možná uměly, ale buď to neumí nftables (což se mi úplně nezdá), nebo se to ztrácí někde v překladu v iptables-nft.

[TajnejAgent]

Tohle je pochopitelně odpověď na https://www.abclinuxu.cz/poradna/linux/show/477806#10

[TajnejAgent]

Abych komunitě vrátil vaši snahu, přidávám ještě shrnutí úspěšného řešení doplněné o řešení v nftables.

1. Zápis netmask "s dírami" (tzn. např. --source 10.1.2.0/255.0.255.0) je možný a funguje v původních iptables (tzn. v dnešních systémech je řeč o iptables-legacy, nikoli o iptables-nft).
2. V nftables existuje operátor & (bitwise AND) a jestli jsem to správně pochopil, dá se použít na jakékoli pole, ne jen na adresu. Pravidlo se pak přidá například takhle: nft insert rule ip filter INPUT 'ip saddr & 255.0.255.0 == 10.0.1.0 drop' (matchne všechny adresy 10.*.1.*)
3. iptables-nft (tzn. mezivrstva pro milovníky starých pořádků, která se tváří jako iptables, ale na pozadí pracuje s nftables) si s touhle srandou neporadí: vytvoříme-li pravidlo s "děravou" maskou v iptables-nft, z masky se použije jen část před první dírou (viz komentáře výše), vytvoříme-li pravidlo v nft, iptables-nft už takovou tabulku neumí ani zobrazit: iptables v1.8.7 (nf_tables): table `filter' is incompatible, use 'nft' tool.

Díky všem za pomoc při rozklíčování, jsem rád, že abíčko furt funguje, jako za starejch časů :)