SAFE mód és az optimalizálás

Érdemes eljátszani a gondolattal, mi lett volna, ha nem tudunk layer2 segítségével hozzáférni a routerhez, mert mondjuk az a világ másik felén van. Nem tudunk gyorsan odarepülni, rádugni egy Ethernet kábelt módosítandó az elrontott tűzfalszabályt. De erre is van megoldás! Amint beléptünk, irány vissza a tűzfalszabályokhoz. A változatosság kedvéért, most a menükbe navigálás helyett adjunk ki minden utasítást a gyökérből.

ip firewall filter print

Látjuk, visszaállt az eredetileg létrehozott állapot a meglévő 6 szabályunkkal. Ismételjük meg az előbb végrehajtott badarságot, némi biztosítás beüzemelése után. CTRL-X kombinációt leütve, alábbi választ kapjuk

[admin@MikroTik] >
[Safe Mode taken]
[admin@MikroTik] <SAFE>

A kombináció megnyomásának pillanatában eltárolásra kerül az aktuális konfiguráció. Minden utasítás, amit innentől kezdve kiadunk, bár végrehajtásra kerül, de ha megszakad a kapcsolat a routerrel, visszaállnak a beállítások a rögzített állapotból. Itt az idő újra bátornak lenni és végrehajtatni az alábbi utasítást, és utána azonnal váltsunk vissza WinBoxba.

ip firewall filter move 5 destination=0

WinBox-ból követni tudjuk, hogy áthelyeződik a szabályunk, és pár másodperc elteltével visszavonásra kerül az utasítás. Minden további művelet nélkül vissza tudunk lépni a parancssoros felületre. Fontos: ha valami miatt biztonsági mód alatt módosítjuk a routerünk beállításait, ne felejtsük el a biztonsági módot deaktiválni a CTRL-X ismételt megnyomásával! Miért? Különben ha csak kilépünk, az sajnos annak minősül, hogy a safe token nyitva marad, és minden beállítás ami egyébként jól hajtottunk végre, elvész amikor kilépünk. Ez pedig nettó bosszúság, amint később rádöbben az ember.

Most, hogy tudjuk, milyen szerepe van a szabályok sorrendjének és van három engedélyező szabályunk, egy segédszabályunk, valamint két tiltó szabályunk. Kezdjük az elején: minek három engedélyező szabály? Hiszen internet volt a most hozzáadott kettő nélkül is! Na igen, de akkor nem volt egy szabály mindenek után, ami eldobálta volna a csomagokat! Ennek a hiánya vezetett ahhoz, hogy a logban SSH kísérleteknek nyomát fedeztük fel. Igen, minden, amire nincs szabály, az engedélyezett forgalom!

Emiatt fordult elő, hogy a meglévő két engedélyező szabály nélkül is volt internet. De ha minden, amire nincs szabály, az engedélyezett forgalom, akkor miért kellett első körben a 0. sorszámú szabály hozzáadása? A válasz: nem kellett, funkcionálisan nem adott akkor hozzá semmit, épp ellenkezőleg. Mivel aktív szabály volt életben haszon nélkül, csak lassította a rendszert. Igaz, ennek mértéke még a marginálist se érte el. Viszont ha optimális teljesítményre törekszem, eltávolítottam volna.

Optimalizáljunk a szabályokon úgy, hogy közben odafigyelünk a kiskapuk bezárására, a nem kívánt csomagok kizárására.

Foglaljuk össze még egyszer, milyen elgondolás alapján működik tűzfalunk.
- Szeretnénk mindent engedélyezni, ami LAN oldalról került kezdeményezésre. Ezt a célt szolgálja 0. számú szabály.
- Amint LAN oldalról kijutottak a csomagok, az 1-2. számú szabállyal jutnak vissza a routeren át a számítógépünkről kezdeményezett csomagok válaszai (related & established connection-state)
- 3. szabály csak információéhségünket csillapítja.
- 4. szabály, ami eldobja a nem megfelelő csomagokat, amiknek nincs nyoma a kapcsolatok közt.
- A lista legvégén továbbra is eldobunk minden csomagot (5. szabály)

Aki a 4. számú szabály törlésére gondolt, jól tippelt. Ugyanis minek külön törölni egy adott csomagtípust, ha egyébként is eldobnánk utána mindent? Ezzel hamarabb véget ér a lista, gyorsult a feldolgozás.
Deaktiváljuk a szabályt.

ip firewall filter disable numbers=4

Mit tehetünk még? Van három engedélyező szabályunk. A végeredmény szempontjából lényegtelen, ezek milyen sorrendben vannak, hiszen mindegyik különböző állapotot ellenőriz, nincs átfedés köztük. Mégis, célszerű beállítani ezek sorrendjét oly módon, hogy amelyikre legtöbbször illeszkedik egy csomag, az legyen legelöl. Ellenőrizzük ezt le.

[admin@MikroTik] > ip firewall filter print stats
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 input accept 24 010 941 280 713
1 input accept 4 231 973 33 143
2 input accept 2 143 17
3 input log 14 784 329
4 X input drop 4 540 110
5 input drop 2 679 495 57 160

A meglévő sorrend a már optimális eredményt hozza. Amire figyelni kell, az a csomagok monoton csökkenő sorrendje. Jelenleg további optimalizálásra nincs szükségünk.

A cikk még nem ért véget, kérlek, lapozz!