Tűzfalszabályok managelése

Szerintem mire ezeknek a rendszereknek megtanulod a logikáját, addigra lemódosítod a firewall.sh-t :)
Én eddig nekifutottam a shorewall-nak ennek a Firewall Builder-nek, meg még valaminek amire nem emlékszem, de mindig arra jutottam, hogy a tanulásukkal töltött mondjuk max egy óra alatt velük semmire nem jutottam, a sima script-el már rég készen lennék.

[nosztalgia]
Én az ilyet (>10 évvel ezelőtt) nem kézzel szerkesztettem, hanem generáltattam. Volt egy tömör, magas szintű szöveges leírásom, amiből egy perl szkript PIX config-ot gyártott.
[/nosztalgia]

Nekem a Cisco ASA "security level" filozófia tetszett meg anno, de sajnos készen nem találtam ilyen elven működő iptables wrappert, írtam hát sajátot. A korábbi iptables scriptek méretet kb 1/10-edére csökkentette. Nálunk nagyon bevált ez a megközelítés, szeretjük.

Kimásolom az rdoc doksinkat, hátha merítessz belőle ötletet. A scriptet fel tudom tolni githubra, de alapesetben nem vesződök vele, szólj ha érdekel.

# == Ladders
#
# A Ladders egy security level alapu tuzfalscript iptables-hez
#
# A security level koncepcioja egyszeru: a halozaton minden szereplohoz rendelheto egy
# biztonsagi szint es kapcsolatot csak az kezdemenyezhet, akinek a biztonsagi szintje
# magasabb vagy azonos a celpontjaval. A biztonsagi szintek csak a szervezeten belul
# szamitanak, szervezetek kozti atjarast nem biztosit.
#
# 3 fele szereplo lehet a szervezetben:
# * src - Szervezeten kivuli kliens; lehet egy masik szervezet tagja, vagy 3. szemely.
# Security level rendelheto hozza.
# * dst - Szervezeten beluli szerver, ami klienskent soha nem lep fel; a legtobb passziv
# szolgaltatas ilyen, pl egy sql szerver. A security level itt az elvart minimalis
# security level ami szukseges az eleresehez.
# * net - Szervezeten beluli kliens es szerver; ez vegeredmenyben az src es a dst
# osszevonasa egy sorban. Altalaban IP cimekkel vagy device nevvel hasznaljuk.
#
# A tuzfal mindent tilt, ami nincs kifejezetten engedve. Csakis a szervezeten beluli
# szereploket vedi (dst es net).
#
# Egy szerver tobb szervezetnek is tagja lehet.
#
# Hogy pontosan mi legyen egy szervezet, azt nem lehet altalanossagban megfogalmazni.
# Olyan ez a kerdes mint az, hogy OOP-ben mi legyen egy objektum: nos, ra kell erezni. :)
#
# === Konfig szintaxis
#
# PROTECT_LOCALHOST={yes|no}
#
# org
# {{dst|src|net} {security_level}|brk} [.cimke] {szereplo1} [szereplo2] [...]
#
# A PROTECT_LOCALHOST magatol ertetodik, magat a tuzfalat vedjek-e a szabalyok.
#
# A security level egy 32 bites bitmaszk, a sor igy nez ki: 1..3..7..f..1f..3f..7f..ff..stb
# (Az iptables korlatja miatt csak igy mukodhet, ugyanis a 'mark' modul nem ismeri
# a '>=' osszehasonlitast.)
#
# A 0-as security levelnek dst/net eseten specialis jelentese van: mindent beenged.
# Src-re nem erdemes kirendelni, ugyanis ez az alapertelmezett.
#
# Egy szereplo lehet IP vagy eszkoz ('d:eth+') vagy IP/mask vagy IP/mask^protokoll vagy
# IP/mask^protokoll^port1:port2,port3. Magyaran:
# [^protokoll[^port[:port][,port]]] - az 'any' IP cim a '0/0'.
#
# A 'brk' egy rendhagyo szabaly: kivetel a szervezet dst es net szabalyai alol. Altalaban
# 0/0-as dst es net szabalyok melle hasznaljuk. A konfig fajlban kapott pozicioja nem
# szamit, mindig elsokent kerul kiertekelesre a szervezetben.
#
# A konfig bash script, igy hasznalhatoak valtozok es egyeb bash trukkok is.
#
# Ha a szabalynak cimket adsz, akkor a kesobbiekben hivatkozhatsz a szereplokre igy:
# ${org_neve[cimke_neve]}
# A cimke_neve itt mar a '.' nelkul kezdodjon. Egyebkent ez is mukodik:
# ${org_neve[*]}
# (Mivel ez egy bash associative array.)
#
# A ladders minden iptables hiban elakad es hibaval ter vissza. Ha esetleg olyan domain
# neveket sorolsz fel, amik eszrevetlenul megszunhetnek, erdemes kikapcsolni ezt a
# viselkedest az erroff sorral, majd visszakapcsolni az erron sorral.
# A ket sor kozott az iptables hibak figyelmen kivul lesznek hagyva, igy nem all le a
# tuzfal betoltodese.
# Altalanossagban nem ajanlott ezt hasznalni a teljes konfigra, mivel tobb rejtett hibat
# okozhat ha bizonyos sorok nem toltodnek be, mikozben a tuzfal statusza azt mutatja,
# hogy rendben betoltodott.
#
# === Halado trukk: atfedo tartomanyok (0/0)
#
# Alapesetben minden szervezethez fel kellene venni egy src sorral a superadminokat, de
# ez egy egyszerubb trukkel is megoldhato:
#
# org ITGODS
# src 10 supercowz bela jeno
# dst 10 everything 0/0
# org DMZ
# ...
# org INTERNET
# brk private 10.0.0.0/8 192.168.0.0/16
# dst 10 everything d:eth0
# src 10 allowed $FONOKSEG/24
#
# Az ITGODS szervezet magaban foglalja (atfedi) az osszes tobbit a dst 0/0 miatt. Ha a
# kliens teljesiti a 10-es szintet, akkor azonnal beengedi mindenfele a szervezeten belul
# es mivel ez a szervezet mindent magaba foglal, mindenhova beengedi - igy lesznek a
# superadminok. Amennyiben nem eri el a 10-es szintet, megy vegig a tobbi szervezeten.
#
# Az INTERNET szabaly hasonloan mukodik, ezert azt legutolsokent tedd a konfigba.
# Ott azert nem a 0/0-at hasznaljuk a dst-ben, mert akkor a szervezetbol tevedesbol
# kimaradt vedendo szervert is elerne az, akinek internet hozzaferest adunk. Ha pontosan
# tudod, hogy milyen tartomanyok a vedendoek, akkor brk-val is megteheted a kivetelt
# rajuk es mehet a 0/0 a dst-be.
#
# === Hianyossagok
#
# Az egyszeruseg kedveert kifejezetten tilto szabaly nincs. Ha pl a Facebookot akarod
# blokkolni, akkor fel kell venni egy FACEBOOK-ot mint szervezetet (org), dst-vel megadni
# az IP tartomanyait 1-es biztonsagi szinttel es kesz - a szervezetben src sor nelkul
# senki nem szerezheti meg ezt a szintet, kvazi az oldal blokkolva van. Masik megoldas,
# az INTERNET szervezetben egy 'brk' soros kivetelt tenni a Facebook tartomanyokra,
# de ez esetben nem tudsz kivetelt tenni a tiltasban.
#
# Frappans megoldas lenne egy specialis security levellel azonnal blokkolni a
# szereplot (src vagy dst), hogy csokkentsuk a log meretet.
#
# A tuzfalrol kimeno csomagokat nem szuri.
#
# === Pelda
#
# org IOFFICE; declare -A IOFFICE
# net 01 .wifi 10.10.4.0/24
# net 03 .mgmt 192.168.2.0/24
# net 07 .lan 192.168.130.0/23 192.168.16.0/24
# net 07 .vpn 10.8.0.0/22 10.8.16.0/24 10.8.4.0/24
# dst 0f .switches 10.3.1.0/24
# src 0f .mgmt_for_switches 192.168.2.102
# net 1f .itstaff 192.168.5.0/24
# src 1f .itstaffvpn 10.8.0.225 10.8.1.61 10.8.0.209 10.8.1.21
#
# org INTERNET
# brk .private 10.0.0.0/8
# dst 01 .internet d:tunl+ d:media+
# src 01 .ioffice ${IOFFICE[wifi]} ${IOFFICE[lan]} ${IOFFICE[itstaff]} ${IOFFICE[vpn]}
# src 01 .ioffice_mgmt ${IOFFICE[mgmt]}
# src 01 .vpn 10.8.0.134 10.8.0.213 10.8.0.10 # admin1 admin2 admin3

Nézd meg a ShoreWall-t
http://hup.hu/node/127852#comment-1661014
--
Légy derűs, tégy mindent örömmel!

Hi!

A válasz a kérdésre első közelítésben igen, vagyis lehet telepíteni Debianra.

http://packages.ubuntu.com/precise/zorp
http://packages.debian.org/wheezy/zorp
http://asylum.madhouse-project.org/projects/debian/

Másrészről a Zorp konfigurálásában voltak komolyabb változások, egyszerűsítések, viszont ezek használatához egy kernel modul (KZorp) szükségeltetik. Egy átfogó leírás és néhány egyszerűbb példa itt olvasható:

http://www.scribd.com/doc/123114941/Zorp-GPL-Tutorial

Ha emellett döntesz, akkor a további kérdésekre itt tudsz a legegyszerűbben választ kapni:

https://lists.balabit.hu/mailman/listinfo/zorp-hu

en hasznaltam firewallbuilder-t, teljes megelegedessel. erteni kell hozza az iptables mukodeset, de eleg jo vizualis reprezentaciot ad. amivel problemank volt az a verziok kozotti valtasnal a koverzio: na az nem mukodott. ujra fel kellett epiteni a tuzfalat azuj verzioban. ez mondjuk nem hatrany mert eleg sokat tud karcsusodni adott esetben :)
tud tobb tuzfalat is kezelni, ill. tobb platofrmra 'forditani' szkriptet: iptables mellett a pix remlik, de mar 2 eve volt hogy hasznaltam. szerintem kb 30-40 szabaly felett erdemes ilyen gui-s dolgokkal foglalkozni.