mknod /dev/blog c 1 3

Foarte des (cam o data pe saptamana) dau de cate cineva care cauta disperat un “iptables god” sa-l ajute cu scriptul lui. De cele mai multe ori, constat ca respectivul vrea pe cineva care a fost dispus sa priceapa cum functioneaza netfilter (engine-ul de packet filtering din kernelul Linux) si sa-i dea mura in gura un script sau mai rau, niste reguli pe care sa le ruleze direct. Sarind peste teoria cu “nu trebuie sa rulezi comenzi date de necunoscuti pe internet”, consider aceasta abordare drept o lipsa totala de respect pentru cel care te ajuta, timpul si cunostintele lui (de obicei le recomand documentul lui Eric Raymond despre cum sa pui intrebari inteligente, disponibil si pe wiki-ul RLUG in limba romana). Orisicat, imi dau silinta sa-i ajut, prin Metoda din Trei Pasi a lui Petre pentru Iptables:

Mai intai incerc sa-i fac sa priceapa ca sa “inveti iptables” e echivalent cu quote-ul favorit al lui Bruce Lee: “[..] ca degetul care arata luna. Nu pierdeti timpul uitandu-va la deget. Luna este importanta.” Cu alte cuvinte, sintaxa comenzii iptables se gaseste imediat in manual, daca stii ce vrei sa-i spui lui netfilter sa faca. Un excelent punct de plecare (eu de acolo am invatat) este setul de howto-uri scris de Rusty Russell (autorul principal al netfilter), disponibile la http://netfilter.org/ .

Pasul doi se aplica celor care sustin ca n-au experienta suficienta sa puna la punct un firewall suficient de safe. Le recomand urmatorul setup (fara sa dau comenzi iptables explicite):

• Toate chainurile au policy ACCEPT. Unii “specialisti” ar scuipa in san cand aud de chestia asta. Respectivii specialisti probabil nu au avut ocazia sa editeze firewallul de la distanta si astfel au ratat minunatele momente Kodak cauzate de ssh + drop policy pe INPUT + flush la firewall. Se zice ca cea mai buna experienta e cea proprie, dar oamenii inteligenti se folosesc de a altora
• In chainurile INPUT si FORWARD se permit toate pachetele din conexiuni deja existente, indiferent de interfata pe care vin. Acest lucru se poate datorita extensiei de connection tracking din netfilter, considerand valide pachetele din conexiuni ESTABLISHED sau RELATED. Astfel, nu mai e nevoie sa reverificam conexiuni deja permise de regula urmatoare:
• Atat in INPUT, cat si in FORWARD se permit conexiunile noi initiate dinspre interfata interna (presupun aici ca reteaua interna se considera curata si de incredere, pentru cazuri mai paranoice se pot considera “untrusted” toate interfetele si sari acest pas)
• Urmeaza reguli specifice de ACCEPT pentru serviciile cu acces public sau doar de la anumite ip-uri. Aceste reguli trebuie scrise tinand minte ca la ele ajunge doar primul pachet din conexiunile initiate dinspre interfete untrusted, orice altceva a fost deja permis. Minimul recomandat ar fi mesajele icmp de tip “echo-request”, asa cum zice RFC1812 (contrar legendelor, nu esti invizibil daca nu raspunzi la pachete, doar nepoliticos)
• La sfarsitul INPUT si FORWARD vine un DROP neconditionat (precedat eventual de niste linii de LOG pentru a putea vedea ce pachete nesolicitate circula pe retea). Asta emuleaza policy=DROP fara efecte secundare nedorite. De notat ca ordinea regulilor in chainuri conteaza. Algoritmul de parcurgere e simplu: fiecare pachet parcurge regulile din chain la rand pana la prima care se potriveste. Se alege targetul acelei reguli, restul sunt ignorate (exista si targeturi care nu cauzeaza acest lucru, cum ar fi LOG, dar hai sa nu complicam prea mult). In cazul in care nu s-a gasit un match perfect, se alege targetul din politica chainului (implicit ACCEPT, si recomand sa fie lasat asa). Desi iptables stie sa introduca reguli in orice pozitie din chain, se recomanda ca in scripturile de firewall sa se goleasca mai intai complet chainurile si sa se puna reguli pe rand ( cu -A de la append), pentru o mai buna claritate.
• Cam asta e tot. pasi urmatori ar fi setarea ip_forward=1 , in cazul in care se doreste mutarea pachetelor dintr-o parte in alta, configurarea NAT (care se foloseste de connection tracking si ca atare trebuie scrisa regula doar pentru primul pachet).
• Acum ca “mi-am facut pomana” cu acest pseudo-tutorial, sa arunc putina lumina si pe ce fac cele trei chainuri din tabela filter - INPUT, OUTPUT si FORWARD. Un pachet care trece prin router va trece prin unul si numai unul din aceste chainuri (iarasi mint, cu foarte multa silinta se poate forta sa mai treaca prin tabela filter inca o data, dar nu ma mai contraziceti ), dupa sistemul urmator: pachetele care au ca destinatie finala routerul trec prin INPUT. Cele generate de router trec prin OUTPUT. Cele care sunt doar “in trecere” trec prin FORWARD (inclusiv in cazul NAT, pt. ca routerul stie deja ca nu sunt pentru el). O diagrama foarte frumoasa cu ordinea de parcurgere a tuturor chainurilor se gaseste in ghidurile lui Rusty, asa ca n-o mai detaliez si eu.

Pasul trei se aplica celor care zic “Dar am citit toate documentatiile alea si n-am inteles nimic! Mai bine uite scriptul meu de firewall (urmeaza 200 de linii) , zi-mi ce am gresit! Am citit ca trebuie sa mai pun cuvintele OUTPUT DROP pe undeva, asa e? DE CE NU MERGE NIMIC?????….”. Mai exact, nu se aplica lor, mi se aplica mie. In cazul in care constat ca imi irosesc bunele intentii pe niste oameni care nu vor sa invete absolut de loc si se bazeaza pe informatii gata mestecate de altii, ii las frumos cu durerile lor si imi propun sa scriu articole despre cum ar trebui sa se intample intr-o lume ideala. Si uneori chiar o fac.

# the end