Az OUTPUT láncból a DROP láncba irányítással csak óvatosan, kellemetlenül ki tudjuk zárni a külvilágot, ha óvatlanul küldözgetjük a csomagokat a DROP lánc felé. :-)

Javasolt, legegyszerűbb megoldás:

1. iptables -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

(ami kiment, az tudjon visszamenni)

Ez fűszerezhető az invalid sync bites csomagok kiszórásával, hogy a gonosz ember annak hamisításával ne tudjon bejönni: iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

2. INPUT láncokon ACCEPT láncra irányítások beállítása, ha szükséges.

Ha nagyon paranoidok vagyunk, letiltható még a pingelés is.

iptables -A INPUT -i ppp0 --proto icmp -j
DROP

3. FORWARD láncba irányítások megoldása, ha kell egyáltalán.

4. iptables -A INPUT -i ppp0 -j DROP

(magyarul, amit eddig nem küldtünk az ACCESS vagy a FORWARD láncokra, az mehet a levesbe)

5. iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

(magyarul, ami be tudott jönni, az ki is mehessen)

Természetesen, ha nem xDSL-en nyomul az illető, akkor a ppp0 helyett ethx kell, ahol az ethx a kábelhez/bérelt vonalhoz való csatlakozásra használt eth.

Kész.

Ha nem akarunk folyton scriptet futtatni, akkor az első futtatás után mentsük el konfba a láncok állapotát

#iptables-save > /etc/iptables.conf

(a fájl helye és neve persze opcionális)

és a megfelelő helyen (debian esetén célszerűen az adsl-start elé valahol a /etc/init.d megfelelő scriptjébe) a script futtatása helyére rakjuk azt, hogy

iptables-restore < /etc/iptables.conf

Aztán sózzuk, borsozzuk ízlés szerint, rottyantsuk meg egy kicsit, végül teszteljük.

Köszönöm mavo, ez nagyon nagy segítség volt.
Úgyis ezzel bírkózóm és nem vagyok egy nagy szakértő.
Ha majd erre jársz (bár megkérdezem más fórumokon is) az ilyen plusz/utólagos soroknak a helyét a szkriptben hogyan határozzam meg. Van erre módszer, vagy végig kell gondolni a logikai láncot és úgy kell meghatározni?
SP

A világ legegyszerűbb dolga ez.

Az iptables szépen sorra veszi az egyes láncokat.

Példa (mailszerver esetén érdekes beállítás, hogy tudjanak kívülről SMTP-t kezdeményezni)

iptables -A INPUT -i ppp0 -j DROP
iptables -A INPUT --proto tcp -i ppp0 --destination-port 25 -j ACCEPT

Nos, mivel a válogatás nélküli DROP-ra küldés korábban van, mint a 25-üs porton jövő csomag ACCEPT-re irányítása, ezért hatástalan, nem jön be a 25-ösön semmi.

tehát fordított sorrendben kell a két sort megadni, és akkor előbb megy az ACCEPT-re a 25-ös portra jövő csomag, mint hogy kidobná a válogatás bélküli DROP-ra küldés - egyszerűen oda már nem jut el.

Általános alapelv: mindig előbb engedélyezek és csak aztán tiltok, akkor biztosan nem fordul elő, hogy valami, amit be szeretnék engedni, korábban már a DROP láncba került, tehát az engedélyezést már nem éri meg.

Ja, és másik alapelvek, bár szerintem másik posztomból kiderült már:

1. az OUTPUT láncba a lehető legkevesebb tiltást tegyük, mert láttam én már olyat, hogy bejött kintről a csomag, de a válasz nem ment ki, mert valahol letiltott egy OUTPUTRA gyártott DROP-ra irányítás (szinte biztos, hogy valami válogatás nélküli), aztán a júzer csak nézett, miért nem megy a kommunikáció.

2. Az INPUT lánc végén, ha nem DROP az alapértelmezés, akkor legyen ott egy általános DROP, különben bejön válogatás nélkül minden.

"A világ legegyszerűbb dolga ez."

Majd az lesz! :-)

Figyu, hidd el, annyira primitív a lgikája, hogy fejedre fogsz csapni, ha rájössz. :-)

Amúgy gonolj bele. Van egy frankó láncod, ami nyílt, tehát nem kör.

Na, annak két vége van csak, amihez bármekkora kevergés után is biztos elérsz valamikor, sőt így belegondolva utólag, legfeljebb három lépés alatt egyik vég biztosan szembejön. Vagy a DROP, vagy az ACCESS.

Ha elérsz bármelyikhez, onnan kezdve bármilyen szabály következik, az rád már nem érvényes.

A logikáját értem, de még teljesen át kell rágnom a szabályokon. Melyik, mit csinál. És utána tudom felfűzni a lánc szemeit. Addig van az a módszer, hogy egy meglévő szabályt próbál az ember módosítani.