Hlavni know-how pri vytvareni firewallu neni v tom,
jak se ta pravidla pisou, ale v tom do jakych casti
vlastne to filtrovani rozdelit. Prijde mi napriklad
naprosto zbytecne filtrovat cokoli v retezci OUTPUT. Take nevim, proc vsichni rozdeluji zvlast UDP a zvlast TCP provoz - tady zadnou funkcnost zavedenim dalsiho chainu neziskame. Naproti tomu kdybychom treba zavedli retezec "spoof", ktery by delal ochranu pred IP spoofingem a treba zahazovani RFC1918 IP adres na vstupu, tak tady se uz zvlastni chain vyplati - jednak muzeme misto ACCEPT/DROP rozhodovat stylem RETURN/DROP a pak zpracovavat dal, a jednak tento chain lze volat jak z INPUT tak z FORWARD (ja vim, ze zrovna tohle lze udelat i pomoci route path filteru, ale jsou situace, kdy rp_filter nelze pouzit - treba IPsec).
Dalsi poznamka je, ze vam to nebude fungovat, aspon pokud mate dostatecne novy BIND - ten pro odchozi dotazy nepouziva zdrojovy port 53, ale neco nahodneho nad 1023 (lze ho ovsem direktivou query-source prinutit k pevnemu portu). Takze odpovedi na vlastni DNS dotazy zahazujete v INPUT (i v INPUT je treba pouzit stavovou filraci, pripadne povolit packety z portu 53 na port query-source).
Ad: rozdělení TCP a UDP.
TCP je vhodné oddělit například tehdy, když chceme
filtrovat TCP pakety s příznakem SYN, které zároven
nejsou ve stavu NEW. Jistě to lze udělat i jinak, ale
tohle mi připadá jako dobrá motivace. Více bude v přpravovaném třetím díle článku.
Ad BIND:
Ano, funkční firewall by měl povolovat --state
ESTABLISHED,RELATED i v řetezci INPUT.
