Dynamicka uprava pravidel iptables pomoci weboveho rozhrani. (diskuse)

[Josef Kufner]

Pokud nenajdeš žádné hotové řešení, tak bych to viděl na kombinaci odděleného skriptu + sudo na přidávání pravidel a atd na timeouty. Akorát si velice pečlivě ošetřuj parametry, ktere budeš předávat tomu scriptu na otvírání firewallu.

[Dalibor Smolík]

V tomhle by nepomohl projekt webmin-firewall?

[Lemmy]

Myslim si, ze spis ne (i kdyz myslet znamena h***o vedet :). Webmin vyzaduje od uzivatele nejake dalsi akce po prihlaseni. Ja potrebuju mit pro uzivatele akorat prihlasovaci formular a odhlasovaci tlacitko. Vsechno ostatni bude pred uzivatelem skryto a bude se provadet automaticky, skriptem na zaklade prihlasovaciho jmena a uzivatelovy ip adresy.

Dik za reakci

[Piškot]

webmin není moc dobrá volba na velké množství záznamů, když jich bylo více jak 250 trvalo mu zpracování úkolu dost dlouho.

[Věroš]

Ahoj, podobnou věc jsem řešil (a možná bych ji i někde vyhrabal).

Jediné dvě myšlenky, které jsem tam použil byly

- zavést si speciální chain v iptables, do kterého se bude zasahovat z toho povolovacího/zakazovacího skriptu. Skript nebude sahat nikam jinam, takže nerozbije konfiguraci v iptables (čehož jsem se bál nejvíc)

- aktivitu zjišťovat pomocí počitadel u jednotlivých pravidel v tom chainu.

Zbytek je už jenom hrubá ruční práce (protože do iptables můžeš sahat jenom jako root )

[Piškot]

Tak tohle řeším tak že na serveru je klasicky napsaný iptables a je do části MACFILTER vložen include. Za pomocí dat z MySQL a php vygeneruju pravidla a přepíšu vloženou část. dá se tak snadno uživatelsky "z formuláře" přidávat uživatel, zároveň mi php skript i generuje značkování paketů a htb filtry ... jenom je třeba dát si pozor na to aby při chybě přenosu -> tudíž prázdném konfiguráku byl stav firewallu průchozí a nahlásil chybu.

[Piškot]

ještě bych dodal že samotnou změnu řeší bash skript, který zkontroluje zda se pravidla změnila a aplikuje je.

[Jary]

Proč to takhle fintit a nepoužít VPN?

[xkucf03]

Když už to má být takhle (a nechceš VPN), tak bych aplikaci doporučil rozdělit do více vrstev. Přecejen je to dost citlivá věc.

Jedna vrstva bude webová aplikace (klidně PHP, nebo něco v čem umíš , která zjistí IP adresu, ověří uživatele a zapíše do DB pravidlo, které se má nastavit.

Druhá vrstva bude program, který bude z DB číst pravidla a nastavovat je na iptables. Do DB si také poznamená, kdy pravidlo nastavil a kdy má vypršet. Program poběží v nekonečné smyčce a bude si držet jedno spojení do DB. Pokud spojení spadne, obnoví se. Pokud spadne celý proces, v cronu bude skript, který ho znovu nahodí...

Celé tohle bych nasadil na oddělený stroj, např. proto, aby špatně napsaný program nemohl ohrozit hlavní internetovou bránu podniku. Když to špatně napíšeš, tak uživatelé přijdou o vzdálený přístup, ale nezesere se ti net v celé firmě.

Bohužel je ale ještě potřeba ošetřit uživatele, kteří sdílí IP adresu, nemají vlastní veřejnou. V tom případě totiž povolíš přístup třeba tisíci lidem, místo jednoho zaměstnance.

Přijde mi to dost kostrbaté řešení, za lepší bych považoval nějaké tunelování, buď SSH nebo celou VPN.

[Josef Kufner]

Na udržení procesu je lepší použít init než cron. Ale vypršení pravidel bych řešil spíš spouštěním uklízítka z cronu, které by kouklo do db a případně uklidilo. Ale asi bych to pověsil do atd a DB neřešil vůbec.

[xkucf03]

DB mi přijde jako dobré rozhraní mezi "frontendem" a "backendem" -- dělat nějaké zásahy do systému přímo z PHP považuju za šílenost. Ale obecně je celé toto řešení dost ošidné.

[Josef Kufner]

DB má jasně definované API. Pokud dokážeš udělat jasně definované API i u sady skriptů, tak nemáš problém a bude to fungovat lépe (méně částí, jednodušší části, žádné oťukávání nových dat,...).

[xkucf03]

Nejen to, výhodou DB jsou transakce a víceuživatelský přístup. V tomto případě je jedním uživatelem webové rozhraní a druhým uživatelem program v pozadí, který nastavuje pravidla firewallu. DB za tebe udělá spoustu práce (více uživatelský přístup), proto je dobré se na ni spolehnout. Kdyby si to člověk měl psát sám, tak je dost velká pravděpodobnost, že tam udělá chybu a rozhodně to nebude optimální (DBMS se vyvíjejí desítky let a je v nich spousta zkušeností, bylo by naivní si myslet, že skript, který napíšu za týden bude stejně kvalitní).

[Josef Kufner]

Možná nebude tak kvalitní, ale může být výrazně vhodnější k danému účelu.

[xkucf03]

Jak bys to tedy udělal? Z webu může přijít více požadavků současně. Nejdřív potřebuješ ověřit uživatele (jméno/heslo...), ti nemusí být v systému, takže to chce mít někde seznam uživatelů. Pak přichází autorizace, jestli můžeš danému uživateli zpřístupnit službu, kterou chce. Tyhle pravidla taky musí být někde uložena. Pak se schválené pravidlo někam uloží a jiný program ho nastaví do iptables. Někam -- do souborů bych to nedával, protože jak píšu na začátku, uživatelů tam může přistupovat víc najednou. Napsat všechno tohle bez DB je hazard (to je na vyhazov) a nebo nad tím strávíš mládí/stáří, abys to napsal kvalitně a spolehlivě.

[Jary]

sqlite by asi mohlo být dobré řešení

[xkucf03]

Sorry, že do toho pořád rýpu, ale podle http://www.sqlite.org/faq.html#q5 mi to nepřijde jako optimální volba. Nějaké zamykání tam sice je, ale obával bych se problémům s výkonem při vícenásobném pokusu o zápis, AFAIK se vždycky zamkne celá DB. Raději bych zvolil nějaký dospělý C/S DBMS, třeba PostgreSQL

Ale stejně je to celé pakárna protože uživatel nemusí mít veřejnou IP a pak zpřístupníme službu více lidem než chceme.

[Jary]

Já jsem rád když mě někdo na něco upozorní, teda pokud to není úplná prkotina. To zamykání celé DB bych nehodnotil jako velmi významným problémem, protože těch přístupů pro zápis moc nebude. Co mi ale chybělo a mohlo by možná chybět i tu, je to, že sqlite neumí LIKE v SELECTu.