HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System

Ha nem létezne, akkor hozzunk létre egy DontDisplayLockedUserId nevű DWORD (duplaszó) bejegyzést. Ehhez csak kattintsunk a System kulcson jobb egérgombbal, majd válasszuk az Új menüpont alól a Duplaszó (32 bites) bejegyzést és írjuk be a nevet.

Új duplaszó létrehozása

Ezután kattintsunk rá kettőt, majd értéknek a következőket adhatjuk meg:

• 1 = Zárolt felhasználó nevének és felhasználói azonosítójának megjelenítése
• 2 = Zárolt felhasználó nevének megjelenítése
• 3 = Ne mutasson információkat a felhasználóról

Zárolt képernyő, felhasználónévvel

Zárolás feloldása, felhasználónév automatikus kitöltésével

Zárolt képernyő felhasználónév nélkül

Zárolás feloldása, felhasználónév kézi megadásával

A Windows Live Mail erre nyújt beépített eszközt, mellyel a leveleket, postafiókokat és címjegyzéket menthetjük el.

Hozzunk létre egy mappát a mentésnek. Célszerű külső meghajtóra (pendrive, merevlemez) közvetlenül menteni, vagy pedig helyi meghajtóra, de mentés után kiírni CD/DVD lemezre.

Indítsuk el a Windows Live Mailt, majd Fájl menüből (ha nem lenne, akkor nyomjuk le az ALT+F billentyűkombinációt) válasszuk az Exportálás és ezen belül az Üzenetek menüpontot.

Fájl menü

Levelek exportálása

A következő lépésben választhatjuk ki, hogy milyen formában szeretnénk exportálni. Válasszuk a listából a Microsoft Windows Live Mail formátumot, majd Tovább…

Exportálás formátumának kiválasztása

A következő lépésben kell kiválasztanunk, hogy hova szeretnénk menteni. Kattintsunk a Tallózás gombra, majd ttt böngésszük be és jelöljük ki a korábban létrehozott mappát.

Üzenetek mentési helye

Válasszuk ki, hogy mely levelezési mappákat szeretnénk menteni, vagy válasszuk az összes mentése rádiógombot.

Mentendő mappák kiválasztása

Ha sikeres az exportálás, kapunk erről egy üzenetet.

Sikeres exportálás

Levelek importálása

Visszaállítani úgy tudjuk a leveleket (másik gépen akár), hogy a fájl menüből kiválasztjuk az Importálást, majd ezen belőle az Üzeneteket.

Fájl menü, Importálás

A visszaállítandó formátum beállításánál válasszuk a Windows Live Mailt.

Milyen formában importálunk

Következő lépésben tallózzuk be a mentési mappát.

Mentett üzenetek helye

Válasszuk ki azokat a mappákat, amiket vissza akarunk importálni, vagy válasszuk ki az összeset az összes mappa rádiógombra való kattintással.

Importálandó levelezési mappa kiválasztása

Ha sikeres az importálás erről egy üzenetet kapunk.

Az importálás befejezve

Miért is jó ez? Elsősorban szervereken van nagy jelentősége, mivel így úgy lehet a kernelünk naprakész (biztonsági frissítések terén), hogy az nem veszélyezteti a rendelkezésre állást. Természetesen nem csak szervereken működik a dolog, hanem Ubuntu 9.04 desktop rendszer esetén is.

Telepítés

Töltsük le a program .deb formátumú telepítőjét: Ksplice Uptrack for Ubuntu 9.04 Jaunty

A program telepítése a szokásos módon zajlik. Letöltés után csak kattintsunk rá kettőt, mire megnyílik a GDebi és kattintsunk a Csomag telepítése gombra. Amennyiben szükséges, a GDebi telepíti a program függőségeit is.

ksplice telepítése grafikus felületen

El kell majd fogadnunk a program licenc feltételeit.

Csak pipáljuk be a Do you agree… jelölőnégyzetet, majd kattintsunk a tovább gombra.

Ksplice licence elfogadása

Vagy telepíthetjük Terminálból is:

letöltés:

wget http://hogyan.org/letoltes/Ksplice+Uptrack+for+Ubuntu+9.04+Jaunty

Telepítsük a letöltött csomagot, majd a függőségeit is:

sudo dpkg -i ksplice-uptrack.deb
sudo apt-get install -f -y

Tárolóból

A program rendelkezik saját tárolóval, onnét is telepíthetjük. Ehhez először egy kulcsot kell kérnünk, amit a program majd telepítéskor be fog kérni. Ezen a linken tudjuk ezt megtenni.

Szerezzük root jogú konzolt:

sudo -s

Adjuk hozzá a tárolót a rendszerünkhöz:

echo deb http://www.ksplice.com/apt jaunty ksplice > /etc/apt/sources.list.d/ksplice.list

Töltsük le és telepítsük a tároló kulcsát, majd frissítsük a csomaglistákat:

wget -N https://www.ksplice.com/apt/ksplice-archive.asc
apt-key add ksplice-archive.asc
aptitude update

Telepítsük a programot:

aptitude install uptrack

Ha grafikus felületet is szeretnénk, akkor még a következő csomagot telepítsük:

aptitude install uptrack-manager

Használat

Grafikus felületen

Telepítés után a program már rögtön elindul és amennyiben frissítéseket talál, kiírja a listáját azoknak. A programot máskülönben a tálcáról indíthatjuk, az értesítési területen. Ha frissítés érhető el a program ikonján egy piros háromszög figyelmeztet minket erre.

ksplice ikonja a tálcán

Csak kattintsunk rá az ikonra és elindul a program.

Itt láthatjuk egy listában, hogy milyen frissítések érhetőek el. A Check gombra kattintva tudjuk ellenőrizni az elérhető frissítéseket. Amelyik frissítés neve előtt piros pötty van az még nincs telepítve, amelyik előtt pedig zöld, az már telepítve van.

Ksplice frissítések érhetőek el

Telepítéshez csak kattintsunk az Install all updates gombra. Ha szükséges adjuk meg jelszavunkat.

Kernelfrissítések telepítése

Ha valamit nem tud telepíteni, akkor arról kapunk egy üzenetet.

Telepítés után zöldre váltottak a frissítések előtti pöttyök.

Egy elérhető és öt telepített frissítés

Terminálból

Terminálból (parancssori felületen) az alábbi parancsokat használhatjuk telepítés után (root jogokkal, tehát sudo kell elé):

Elérhető frissítések keresése (majd ha Y-t nyomunk, telepíti is azokat)

uptrack-upgrade

ID azonosítójú (sok betű és szám, [] között) frissítés telepítése

uptrack-install ID

Összes elérhető frissítés telepítése

uptrack-install --all

ID azonosítójú frissítés eltávolítása

uptrack-remove ID

Összes telepített frissítés eltávolítása

uptrack-remove --all

Telepített frissítések megtekintése

uptrack-show

Ehhez most az Ophcrack nevű, GPL licencű programot fogom használni. A programnak létezik telepíthető verziója, azonban most a Live CD-s verziót fogom bemutatni (tehát CD-ről indított rendszerből férünk hozzá a Windows telepítéshez).

Figyelem! Más számítógépén ilyet végrehajtani (a tulajdonos tudta és engedélye nélkül) bűncselekmény (BTK 300/C. §)!

Jelszó tárolásának módszere

Először nézzük is, hogy hogyan tárolja a Windows (és ezt a módszert nem csak a Windows használja, hanem jóformán minden modern rendszerben így történik a jelszó tárolása).

Amikor beírunk egy jelszót, a rendszer nem menti el egy-az-egyben a jelszót, hanem különböző algoritmusok alapján létrehoz egy úgynevezett hash-t, ami egy hosszú szám és betűsor képében realizálódik.

Ebből a hashból magát az eredeti jelszót nem lehet közvetlenül kinyerni, mivel csak egyirányú az út (gondoljunk csak pl. az MD5 hashra, mellyel egy állományt egyedileg lehet azonosítani, de magából az MD5 hashból nem lehet visszaállítani az eredeti fájlt). Amikor a rendszer bekéri jelszavunkat, úgy ellenőrzi, hogy az tényleg a jó jelszó, hogy ugyanazt az algoritmust lefuttatja a jelszón, majd összehasonlítja az eredményt. Ha ugyanaz, akkor jó jelszót írt be a felhasználó, ha nem ugyanaz, akkor rosszat.

A jelszó feltörése is, éppen ezért nem is feltörés, hanem próbálgatás. Tehát egy szótár (vagy generátor, stb.) alapján a program végigpróbál nagyon sok lehetséges jelszót, majd ahol egyezik a hash eredménye, az lesz a jó jelszó.

Az Ophcrack az úgynevezett szivárvány-tábla módszert használja (régebben ezt csak simán szótárnak hívták). Ami azt jelenti, hogy valakik már előre elkészítették nagyon-nagyon-nagyon sok jelszó hashét, így a programnak elég csak megnézni, hogy melyik hashel egyezik meg a rendszerben tárolt.

Éppen ezért fontos, hogy kellően hosszú és bonyolult jelszót válasszunk, mivel ha nem lenne ilyen adatbázisunk nagyon sokáig tartana az összes lehetséges jelszó-kombinációt végigpróbálgatni.

Fontos tudni, hogy ezzel a módszerrel csak akkor lehet megszerezni a jelszót, ha helyileg hozzáférnek a géphez, vagy ha valamilyen módon már megszerezték a rendszergazda jelszavát, és az ő jogaival távolról is elérhetik a gépet.

Természetesen a rendszerek jelszó tárolási algoritmusai is fejlődnek, sőt, alapesetben a Windows (otthoni környezetben) a kompatibilitás miatt inkább a régebbi, ámbár több mindennel kompatibilisabb módszer

Jelszót megszerzése

A Live CD futtatásához legalább 1 GiBájt RAM kell (mivel a jelszókat tartalmazó szivárvány-táblát be kell másolni a memóriába)

Két verzióban tölthető le a Live CD: külön XP-hez, és külön Vistához

• ophcrack XP LiveCD
• ophcrack Vista LiveCD

Írjuk ki lemezre a letöltött ISO állományt, majd indítsuk számítógépünket a CD/DVD meghajtóról.

Indításkor rögtön egy választó menübe jutunk, ahol választhatunk, hogy grafikusan (automatikusa, vagy kézzel), szövegesen indítsuk a Live CD-t. A legtöbb esetben a legfelső, grafikus mód automatikusan opció megfelelő lesz, így csak egy entert kell ütnünk (vagy várunk 10 másodpercig és magától így indul el).

ophcrack boot

Miután betöltött a rendszer, rögtön láthatjuk a Windows felhasználókat, valamint a jelszó hasheket és elkezdi betölteni a memóriába a szótárt.

Ophcrack elindulása

A jelszók megkeresése egy darabig eltart. Amennyiben az adott hash nem található meg a szivárvány-táblájában, akkor brute-force módszert használhatunk, ami azt jelenti, hogy a program próbálkozik különböző jelszavakkal.

A teszt jelszómat (EzMegAz) két és fél perc alatt találta meg (NT Pwd oszlop).

Megvan a jelszó

Fontos tudni, hogy a beépített szivárvány-tábla csak 14 karakteres jelszókig tartalmazza a hasheket (free small), de lehetőség van letölteni ennél nagyobb szótárakat is. A beépített szótár a következő karaktereket ismeri (XP esetén, Vistánál máshogy megy): 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

Minél több kombinációt, több karaktert ismer egy szótár, annál nagyobb (így annál több memória is kell hozzá).

Tehát a különböző programok hozzá tudnak férni a mappához vagy fájlhoz. Azonban ha elhagyjuk, vagy ellopják a háttértárat (vagy csak valami Live OS-t indítanak el) nem fognak tudni hozzáférni az adatokhoz. Jelenleg az adatok visszafejtése is reménytelen próbálkozás.

Fájl vagy mapp titkosítása

Fájlok, mappák titkosítása nagyon egyszerű. Kattintsunk jobb egérgombbal a titkosítandó fájlon vagy mappán, válasszuk a helyi menüből a Tulajdonságokat.

Egy fájl Helyi menüje

Majd itt az Attribútumok résznél lévő Speciális gombra kattintsunk.

Fájl tulajdonságai

A megnyíló Speciális attribútumok ablakban jelöljük be a Tartalom titkosítása jelölőnégyzetet.

Speciális attribútumok

Majd OK, ezután a fájl tulajdonságainál is OK. Ha egy fájlt szeretnénk titkosítani, akkor feltesz a Windows egykérdést, hogy csak a fájlt, vagy azt a mappát amiben a fájl van azt is szeretnénk e titkosítani.

Kiválaszthatjuk, hogy titkosítsa a szülő mappát is, vagy tényleg csak a fájlt titkosítsa. Ha bepipáljuk a mindig csak a fájl titkosítása opciót, akkor ezt nem kérdezi meg többet.

Titkosítási figyelmeztetés

Titkosítás után a fájl neve zöld betűkkel lesz kiírva

Titkosított fájl

Ha egy mappát titkosítottunk, akkor minden a mappába létrejövő (vagy bele másolt, áthelyezett) fájl is automatikusan titkosítva lesz.

Titkosítás feloldása

A titkosítást ugyanott tudjuk feloldani, ahol bekapcsoltuk. Jobb egérgomb a mappán vagy fájlon, Tulajdonságok, Speciális gomb, majd vegyük ki a pipát a Tartalom titkosítása opció elől.

Titkosítási kulcsuk mentése

Nagyon fontos a titkosításhoz használt kulcsok mentése, ugyanis ezek nélkül egy esetleges Windows újratelepítés után nem férnénk hozzá a titkosítot adatokhoz.

Futtatásba (Win+R) írjuk be a következő parancsot:

certmgr.msc

Majd a bal oldali oldalsávban navigáljunk el a Személyes mappába, és azon belül a Tanúsítványokba. Itt látjuk a saját telepített tanúsítványainkat.

Tanúsítványok kezelése

Keressük meg azt a tanúsítványt, mejnél a kívánt célok között az szerepel, hogy titkosított fájlrendszer. Ezen kattintsunk jobb egérgombbal, vaálsszuk a helyi menüből Az összes feladat menüt, és ezen belül az Exportálást.

Tanúsítványok

Elindul a tanúsítvány exportálási varázsló. Első lépésben kattintsunk a Tovább gombra. Második lépsében mikor megkérdezi, hogy szeretnénk e exportálni a titkos kulcsot, válasszuk, hogy igen.

Titkos kulcs exportálása

Következő lépsben az export fájlformátumát lehet beállítani. Legyen a formátum Személyes információcsere – PKCS #12, a jelölőnégyzeteket ne pipáljuk be.

Export fájlformátum

Következő lépésben adjunk meg egy erős jelszót. Ez majd akkor kell mikor vissza szeretnénk majd importálni a tanúsítványt.

Jelszó megadása

Majd tallózzuk be, hogy hova és milyen néven szeretnénk menteni a tanúsítványt.

Exportálandó fájl neve és helye

Majd a következő lépésben kattintsunk a Befejezés gombra. Ha sikeres az exportálás kapunk erről egy üzenete.

Ezután már csak helyezzük biztonságba a kiexportált tanúsítványt.

Tanúsítvány importálása

Ha újra telepítettük a rendszerünket, akkor be kell importálnunk a régi tanúsítványt. Ez nagyon egyszerű. tallózzuk be az elmentett tanúsítványt, majd kattintsunk rá kettőt.

Mikor kéri a varázsló, adjuk meg az exportáláskor megadott jelszót, minden másnál hagyjuk úgy ahogy a varázsló felkinálja.

Tanúsítvány importálása

És, hogy miért jó a titkosítás? Külső eszközeinket bármikor ellophatják vagy elhagyhatjuk (kicsi pendriveok esetén ez nagyon könnyen előfordulhat), azonban ha az adatok titkosítva vannak rajta, más nem fogja tudni olvasni a rajta lévő adatokat.

Természetesen ennek hátránya is van, ugyanis titkosított adatok esetén a beolvasás után dekódolni kell azokat, ami igénybe veszi a CPU-t, azonban mai gépekben rendelkezésre áll ekkora tartalék.

A Bitlocker titkosítás általában 10% teljesítmény többletet jelent a processzor számára.

Sajnos Windows Vista és XP alatt csak olvasni fogjuk tudni az adatainkat, írni nem.

Screencast

(a hangerő csúszka melletti négy kifelé mutató nyílra kattintva teljes képernyőn nézheted)
Letöltés (AVI, 1280×800, 24,59 MB)

Bitlocker To Go titkosítás bekapcsolása

Csatlakoztassuk a titkosítani kívánt külső eszközt, majd menjünk be a Számítógépbe és kattintsunk jobb egérgombbal az eszközön. A helyi menüből válasszuk a Bitlocker szolgáltatás bekapcsolása… menüpontot.

Külső merevlemez helyi menüje

Elindul egy varázsló, ahol ki kell választanunk a védelem módját. Választhatunk jelszavas védelmet, vagy smart kártya (intelligens kártya) alapú védelmet (amennyiben rendelkezünk ilyesmivel).

Általában a jelszó alapú védelem elég, azonban használjunk bonyolult jelszavakat!

Jelszó megadása titkosításhoz

A következő lépésben kinyomtathatjuk vagy elmenthetjük a helyreállítási kulcsot. Erre akkor lehet szükség, ha elfelejtjük a jelszót amit az előző lépésben beállítottunk, ugyanis a helyreállítási kulcs segítségével jelszó (vagy smart kártya) nélkül is visszafejthetőek az adatok.

Mindenképpen mentsük el vagy nyomtassunk ki a kulcsot, azonban ezt őrizzuk megfelelően biztonságos helyen!

Helyreállítási kulcs mentése, nyomtatása

A következő lépésben még egyszer rákérdez a Windows, hogy biztos titkosítjuk e a meghajtót. A Titkosítás indítása gombra kattintva indul el maga a titkosítás folyamata.

Titkosítás indítása

Maga a titkosítás a meghajtó sebességétől és a rajta lévő adatok méretétől függően nagyon sokáig eltarthat.

Titkosítás…

Kész a titkosítás

Titkosítás után ha megnézzük a Számítógépben, akkor a meghajtó ikonjánál egy lakat jelenik meg.

Lakat

Adatok elérése

Ha legközelebb csatlakoztatjuk megint a meghajtót, akkor automatikusan felbukkan egy ablak, ami a jelszó iránt érdeklődik. A használathoz meg kell adni azt.

Ha ezen a gépen nem szeretnénk mindig jelszót beírni (és az a meghajtó, melyen a Windows van, Bitlockerrel szintén titkosítva van), akkor pipáljuk be a Mostantól a zárolás automatikus feloldása opciót.

Jelszó megadása használathoz

Amíg nem írjuk be a jelszót, a Számítógépben is egy zárt lakat ikonja lesz a meghajtónak.

Lakat zárva

Ha elfelejtettük a jelszót, akkor kattintsunk az Elfelejtettem a jelszót linkre, majd tallózzuk be vagy írjuk be a helyreállítási kulcsot.

Jelszó megváltoztatása

A titkosítási jelszót megváltoztathatjuk, ha jobb egérgombbal kattintunk a meghajtóra és a helyi menüből a Bitlocker-alapú titkosítás kezelése… opciót választjuk.

Majd itt válasszuk ki a meghajtó feloldásához használt jelszó megváltoztatása menüpontot.

Titkosított meghajtó kezelése

Titkosítás feloldása

A titkosítás feloldásához menjünk a Vezérlőpultba, itt a Rendszer és biztonság részbe, majd ezen bekül BitLocker meghajtótitkosítás linkre kattintsunk.

Itt láthatjuk felsorolva meghajtókat. A titkosítás kikapcsolásához csak kattintsunk a megfelel meghajtó meletti Titkosítás kikapcsolása szövegre.

Bitlocker To Go kikapcsolása

Majd feljön egy figyelmeztető ablak, itt kattintsunk a Meghajtó visszafejtése gombra.

Bitlocker To Go kikapcsolása

Ezután visszafejti az adatokat a Windows, ami hasonlóan mint a titkosítás, sok ideig eltarthat.

Régebbi Windows esetén…

Ha csatlakoztatjuk a meghajtónkat egy Windows Vista vagy Windows XP SP3-at futtató számítógéphez, akkor láthatjuk, hogy nem látunk semmit a meghajtónk tartalmából, csak pár Bitlockerhez tartozó fájlt.

Ha magától nem indulna el semmi, akkor indítsuk el a meghajtóról a Bitlocker To Go.exe fájlt, ami feltelepíti a szolgáltatást korábbi Windowsokra, így már úgy tudjuk olvasni az adatokat mint Windows 7 esetén.

Screencast

Letöltés (WMV)
(a hangerő csúszka melletti négy kifelé mutató nyílra kattintva teljes képernyőn nézheted)

Figyelem! Az appcmd csak a kiszolgáló szintű beállításokat menti. Az alkalmazás szintű beállítások az alkalmazások mappáiban található web.config fájlokba kerülnek, ezek mentéséről saját magunknak kell gondoskodni!

Automatikus mentés

Amennyiben valami beállítást módosítottunk, akkor az IIS7 (hasonlóan mint az IIS6), automatikusan készít erről egy mentést. Ez a szolgáltatás a Config History, melyet az Application Host Helper Service futtatja. Alapértelmezett két percenként ellenőrzi, hogy történt e változás. Amennyiben igen, akkor készít egy másolatot a beállításokról a %systemdrive%\inetpubhistory mappába.

Ez a funkció azonban csak Windows Server 2008 és Windows Vista SP1 esetén van meg, Vista RTM esetén nincs.

Az automatikus mentésből egyszerűen tudunk visszaállítani. Csak menjünk be az inetpubhistorycfgHistory_NNNNNNNNNN (N-ek helyés sorszám) mappába, majd az applicationHost.config fájlt másoljuk a %windir%\sytem32\inetsrv\config mappába.

Mentés készítése

Mentéshez írjuk be a következő parancsot:

%windir%\system32\inetsrv\appcmd.exe add backup "Mentés neve"

Mentések megtekintése

Nézzük meg, hogy milyen mentések találhatóak a rendszerben:

%windir%\system32\inetsrv\appcmd.exe list backup

IIS7 mentések listája

Visszaállítás

Visszaállításhoz szükség van a mentés nevére, ugyanis azt fogja visszaállítani:

%windir%\system32\inetsrv\appcmd.exe restore backup "Mentés neve"

Mentés törlése

Ha már nincs szükségünk egy mentésre, törölhetjük is azt:

%windir%\system32\inetsrv\appcmd.exe delete backup "Mentés neve"

Először is lépjünk be a Live fiókunk oldalára ezen a linken. A link nagy valószínűséggel át fog irányítani https://login.live.com. oldalra.

Adjuk meg felhasználó nevünket és jelszavunkat, de csak akkor, ha a kapcsolat biztonságos vagyis tényleg a fent említett címen vagyunk.

Ha Magyarországról lépünk be, akkor a magyar felülettel találjuk szembe magunkat. Itt értelemszerűen kattintsunk az Új jelszó létrehozására szolgáló adatok alatt az első módosításra.

Írd be a régi jelszódat, majd alatta az új jelszódat. Tényleg új legyen, mert azzal sokat nem érsz el, ha a régit régire cseréled le. Ezután kattintsunk a Mentés gombra. Megjegyzés: A jelszó 72 naponta elévül kipipálásával azt éred el, hogy a jelszót 72 naponta kötelező megváltoztatnod.

Ezzel a jelszavunkat meg változtattuk, és ha betartjuk a bevezetőben leírtakat, akkor kicsi lesz a valószínűsége, hogy ez az idegesítő probléma megint előjöjjön.

Ha esetleg valaki tud még hasonló módszereket, amivel ezek a vírusos linkek terjednek írja meg nekem és frissítem vele a cikket.

Mik ezek a lépések? Milyen szempontokat kell figyelembe venni?

Egy rossz példa!

A rossz példa én leszek. Az első komolyabb tűzfalam előtt igyekeztem minél többet olvasni az iptables-ről, és próbáltam elsajátítani, hogy utána nagyon biztonságos tűzfalat építsek. Az első lépés a tervezés volt. Ez annyiból állt, hogy felírtam egy papírra kb a következőket:

• A szervernek milyen interfészei vannak
• Milyen szolgáltatásokat kell elérni bentről (belső hálózat, LAN)
• Milyen szolgáltatásokat kell elérni kintről (internet felől, INT)
• Milyen szolgáltatásokat érhetnek el a kliensek a szerveren keresztül

Ez nem volt rossz kezdés, de kimaradt pár lépés:

• Biztonsági lépések.Biztonsági hibák felderítése. Mert minden lánc csak annyira erős mint a leggyengébb láncszem. Hiába szűrök mindent, ha nincs a láncok végén egy DROP szabály, vagy a policy ACCEPT marad.
• Szabályok sorrendje, és spagetti kód. Fontos, hogy azok a szabályok előrébb legyenek amikre több csomag match-el (illeszkedik). Igaz, hogy ez több száz szabálynál és nagyobb terhelésnél jön elő, de tervezéskor sosem csak a jelenlegi igényeket vegyük szemügyre. És itt a következő pont.
• Előre tervezés. Nem árt ha használunk például ciklusokat, változókat és egyéb bash nyújtotta eszközöket, hogy a kódunk szép és átlátható legyen, valamint ha már nem mi fogjuk kezelni, akkor az új kolléga is hamar megismerje a kódot. Ehhez elengedhetetlen a helyes, ésszerű kommentezés. Ésszerű alatt azt értem, hogy nem feltétlenül kell egy szabály fölé 3-10 sor komment. Legyen rövid, és leíró. Változókkal segíthetjük, az interfészek dokumentálását, és változás esetén gyors felcserélését. Nem kell replace, sed és egyéb ?furmányos” eszközhöz nyúlni :).

Én elkövettem jó pár hibát, emiatt pár hónap múlva ránézve a kódomra, nehezen ismertem ki magam.

• Nem volt, vagy alig komment.
• Minden szabály egymás alatt, rendezetlenül, logikátlanul, és még csak alig több mint 50 sor volt ekkor
• ifconfig-al nézegettem, hogy melyik interfész mi is. ?Nah, megint elfelejtettem, melyik is az eth2?” Akkor megint ifconfig…
• …

Nem volt egyszerű, ezt komolyan mondom. És nem egyszerű az elejéről kezdeni mindent. A felhasználóknak nem szabad, hogy megszakadjanak a szolgáltatások, nem zavarhatjuk őket a munkában, a főnökről nem is beszélve. Tehát éjjel vagy hétvégén… Kell ez?!

Akkor szedjük össze, hogyan kezdjünk neki a tervezésnek.

• A szervernek milyen interfészei vannak
• Milyen szolgáltatásokat kell elérni bentről (belső hálózat, LAN)
• Milyen szolgáltatásokat kell elérni kintről (internet felől)
• Milyen szolgáltatásokat érhetnek el a kliensek a szerveren keresztül

• Biztonsági lépések.
• Szabályok sorrendje.
• Saját láncok használata.
• Ciklusok és változók használata.
• Fontosabb kernel paraméterek megismerése és helyes beállítása.
• Tesztelési terv felépítése, ne rögtönözzünk. Tervezzük meg a tesztelést is!

Nem írtam a tesztelésről, pedig fontos. Nem akartam kihagyni :) Ezt első alkalommal is elég jól, de rögtönözve végeztem. Szerencsém volt, ennyi.

A továbbiakban feltételezzünk egy kis irodai hálózatot. Mondjuk egy magán vállalkozás. Mindegy mi, de legyen mondjuk könyvelői iroda :)

Akkor menjünk sorba.

A szervernek milyen interfészei vannak?

Tegyük fel, hogy most csak két interfész van:

• eth0 a belső hálózat felé néz
• ppp0 egy ADSL kapcsolat.

Joggal feltételezhetjük, hogy ez a könyvelő iroda nőni fog, vagy költözni. Tök mindegy, nevezzük el az interfészeket, és kommentezzük fel őket:

# Belső hálózat
LAN="eth0"
 
# Internet
INT="ppp0"

Itt felmerül egy probléma. Lehet, hogy a későbbiek során kelleni fog a ppp0 ip címe. Viszont nem írhatjuk be fixen, mert tudjuk (mert tudjuk), hogy hacsak nem kértünk fix IP-t felárért, akkor ez dinamikus IP cím. Akkor alkalmazhatjuk a következő példát:

INT_IP=$(ifconfig ppp0 | grep "inet addr" | sed 's/:/ /g' | awk '{print $3}')

Biztos van ennél egyszerűbb megoldás is. Ez nem kötelező, lehet, hogy nem fog kelleni, a gondolkodás mód a lényeg. Ez a tervezés alatt kiderül majd, hogy fog e kelleni ehhez hasonló infomáció.

Ami fontos, hogy a továbbiakban az interfészekre $INT és $LAN-ként hivatkozzunk a tűzfal scriptben.

Milyen szolgáltatásokat kell elérni bentről (belső hálózat, LAN)

Ez alatt azt értem, hogy milyen szerver szolgáltatásokat? A könyvelői irodában legyen mondjuk egy

• Belső levelező szerver (mert minden utasításról szeretik van van e-mail, és a szerveren egy biztonsági másolat)
• Samba szerver (A munkákat ide lehet menteni, vagy fájlokat megosztani egymással)
• Könyvelő szoftver (Tegyük fel, hogy van egy szerver <-> kliens alapú szoftverük amivel dolgoznak.)

A szolgáltatásokat felírtuk, írjuk fel az ehhez szükséges portokat és protokollokat.

Belső levelező szerver (25 és 110). Erősen ajánlott titkosított SMTP és IMAP használata!!

Samba szerver:

netbios-ns	137/tcp				# NETBIOS Name Service
netbios-ns	137/udp
netbios-dgm	138/tcp				# NETBIOS Datagram Service
netbios-dgm	138/udp
netbios-ssn	139/tcp				# NETBIOS session service
netbios-ssn	139/udp
microsoft-ds	445/tcp				# Microsoft Naked CIFS
microsoft-ds	445/udp

Könyvelő szoftver. Ezt megtaláltuk a szoftver dokumentációjában. TCP 33555.

Pontosan meg kell határozni, – ami utánajárást, vagy kitesztelést igényel – hogy melyik portot milyen módon kell ki illetve beengedni. Nem szabad ész nélkül mindet kinyitni. Lehet, hogy működi fog, de nem ez a végleges cél. Hanem egy biztonságoz és használható tűzfal építése. Ennek a dokumentációnak pedig most nem feladata, hogy leírja, pontosan milyen portokat kell kinyitni sambahoz szerver oldalon. Én egyszer kiteszteltem, azóta jól megy. Nyitogattam megosztásokat, s közben figyeltem mit dob el a tűzfal, és azokat engedélyeztem. Kb 10 perc munka ha már kézreáll…

Milyen szolgáltatásokat kell elérni kintről (internet felől)

Talán semmit, talán egy VPN vagy/és egy FTP szervert esetleg. Minél kevesebbet. Itt is érvényes, hogy pontosan meg kell határozni, hogy milyen portot melyik irányba. Lesz több feltétel is a biztonság résznél részletezem.

Milyen szolgáltatásokat érhetnek el a kliensek a szerveren keresztül

Talán szükséges engedélyezni, hogy tudjanak külső SMTP szervert is használni, mert a vállalat hivatalos emailszervre egy szerverparkban van. Ekkor a TCP 25-ös portot át kell engedni a szerveren, ám ezt sem ész nélkül. Biztonság résznél lesz erről is szó.

Biztonsági lépések.

• Minden szabály végén legyen egy mindent loggol (naplóz) majd eldob szabály. Szokták mondani, hogy a policy is legyen DROP. De ha a láncok végi naplóz és eldob szabályok bent vannak, akkor felesleges a policy-t bántani.
• Egy szabály felépítésénél értelmes határokon belül próbáljuk meg minél jobban a célra formálni a feltételeket. Minél több feltétel meg van adva, annál biztonságosabb, és tökéletesebb a tűzfalunk. Nézzünk egy példát. A 25-ös port kiengedése. Egyre szigorúbban:

iptables -A FORWARD -p tcp --dport 25 -j ACCEPT
# bejövő és kimenő interfészek meghatározása
iptables -A FORWARD -i $LAN -o $INT -p tcp --dport 25 -j ACCEPT
# Forrás hálózati cím meghatározása
iptables -A FORWARD -i $LAN -o $INT -s 192.168.2.0/24 -p tcp --dport 25 -j ACCEPT
# SMTP szerver konkrét megadása
iptables -A FORWARD -i $LAN -o $INT -s 192.168.2.0/24 -d 11.22.33.44 -p tcp --dport 25 -j ACCEPT
# Csak az új csoamagokat engedjük ki
iptables -A FORWARD -i $LAN -o $INT -s 192.168.2.0/24 -d 11.22.33.44 -p tcp --dport 25
-m state --state NEW -j ACCEPT
(a kapcsolathoz tartozó csomagokról majd később gondoskodunk.)

Kezdetnek ez már nem lenne rossz. Én például anno minden felé kiengedtem a 25-ös portot hibásan. Egyszer emiatt kerültünk fekete listára, mert egy belső gép ami megfertőződött, több ezer levelet kezdett küldözgetni. Nem kellemes.

• Hamis forráscímek kiszűrése. Erre lehet találni példákat az interneten, de soha ne tegyünk be olyan szabályt a tűzfalunkba, amiről nem tudjuk pontosan, hogy mire való!
• Különböző támadások elleni védelmek: ping-flood, syn-flood, érvénytelen SYN csomagok, portscan….

Szabályok sorrendje.

A szabályok sorrendje azért fontos, mert a kernel szekvenciálisan megy végig a tűzfal szabályainkon. És ha van egy csomag ami a 34. helyen van beengedve, akkor az mire odaér 33 szabályra megpróbál illeszkedni. Ezért előrébb kell tenni azokat a szabályokat amikre sűrűbben érkezik csomag. Ezt ellenőrizni tudjuk a következő paranccsal (A filter táblában. Más tábla esetében meg kell adni a -t kapcsolóval a tábla nevét.):

iptables -L -vn

A fenti parancs kimenetében láthatjuk a csomag és byte számlálót, ami alapján helyesen optimalizálhatjuk a csomagok kiértékelésének sorrendjét.

Saját láncok használata.

Saját láncokat létrehozhatunk különböző feladatokra is mint pl.: naplózás vagy tcp csomagok ellenőrzése. Csinálhatunk olyan láncot amibe az összes TCP csomagot irányítjuk, majd ellenőrzéseket hajtunk végre rajtuk, majd ami helyes csomag az nem dobódott el, tehát a RETURN target-el visszadobjuk abba a láncba ahonnan jött, és majd match-el valahová. Ha nem, naplózzuk és eldobjuk :)

Vagy én például szoktam az ICMP csomagok kezelésére is egy külön láncot csinálni, mert elég sokféle icmp csomag létezik, és sok olyan van amit nem szabadna eldobni.

http://www.iana.org/assignments/icmp-parameters

Például amik szükségesek lehetnek:

• Echo Reply - ping válaszok. Igen fontos!

• Destination Unreachable

  - Ha a célállomás elérhetetlen. Ezt is kell tudnunk.

• Echo

  - vagy echo request, a pingelés kifelé. Ezt sem árt kiengedni. Befelé nem kell, ha azt akarjuk, hogy ne tudjanak pingelni minket.

A ?Destinatiob Unreachable"

sok fontos üzenetet tartalmazhat. Nagyon fontosakat, amikből kiderülhet számunkra, hogy miért elérhetetlen a célállomás. Például: hálótat, hoszt, port vagy protokoll az ami elérhetetlen, vagy túl nagyok a csomagok (nagyobb mint az MTU mérete).

Az ICMP szűrés nagyon fontos, gondosan kell eljárni, nem szabad mindent ész nélkül tiltani. Csak kárt és felesleges munkát okozhat a későbbiekben.

Ciklusok és változók használata.

Ha van 5-10 szabály, ami semmiben nem különbözik, csak a portszámokban például, akkor a következő példát alkalmazhatjuk:

# Kiengedni kívánt portok felsorolása.
FWD_TCP="20 21 25 465"
 
# TCP portok kiengedese. 465 = SMTP over SSL
if test -n "$OUT_TCP"; then
	for tport in $OUT_TCP; do
		$IPTABLES -A OUTPUT -p tcp --dport $tport -m state --state NEW -j ACCEPT
	done

Ez igazából 4 különálló szabályt generál, talán nem is célszerű 4 port esetében használni.

If-ek, elágazások segítségével okosíthatjuk tűzfalunkat. Ellenőrizhetjük bizonyos opciók meglétét melyek teljesülése esetén további szabályokat vezetünk be stb…

Fontosabb kernel paraméterek megismerése és helyes beállítása.

A sysctl parancsot használhatjuk a kernel paraméterek beállításához. Minden paraméter kiíratása

sysctl -a

Legfontosabb az ip forward beállítása. Lekérdezhetjük így:

sysctl net/ipv4/ip_forward

Ha ?0″ akkor nincs engedélyezve az IP csomagok továbbítása egyik interfészről a másik felé. Alapértelmezetten ez nincs engedélyezve. Engedélyezéséhez tegyük a következő sort a /etc/sysctl.conf fájlba, vagy ha benne van akkor vegyük ki előle a kommentet:

sysctl net.ipv4.ip_forward=1
# vagy
echo "0" > /proc/sys/net/ipv4/ip_forward

rp_filter – forráscím hamisítást figyeli és tiltja. Ez alapértelmezetten be van kapcsolva, viszont érdemes lehet kikapcsolni, és magunk végezni ezt a munkát. Jobb az ha látjuk mi történik. Persze naplózzunk is szorgosan.

Tesztelési terv felépítése, ne rögtönözzünk. Tervezzük meg a tesztelést is!

Minden szabályt le kell tesztelni! Be lehet vonni teszt felhasználókat ha van lehetőség, és pár napig őket az új tűzfalra tenni. Nem lehet olyan szabály amit nem teszteltünk. Ne sajnáljuk erre az időt.

Egyéb tanácsok:

1.) Minden scriptben használt parancsot érdemes a következő kép használni:

IPTABLES=$(which iptables)
SYSCTL=$(which sysctl)

2.) Használjuk az iptables-save és iptables-restore parancsokat a mentésre és betöltésre. Sokkal gyorsabb, ami főleg nagyobb script esetén érezhető.

Hibakereséshez:

• loggoltassunk
• tcpdump

Követelmények, feladatok:

• Egy nem biztonságos levelező szerver
• Amihez van SSH elérésünk
• Amihez van generált kulcsunk a “néma” csatlakozáshoz
• Titkosított kapcsolat létrehozása ehhez a levelező szerverhez a levelek küldésére/letöltésére

Alapvető fogalmak ismerete:

• SSH
• Port (kapu)
• RSA, DSA, Kulcs (key)
• Levelező protokollok: SMTP, POP3, IMAP

Nem biztonságos levelező szerver

Ez alatt azt értem, hogy van egy levelező szerver amit használunk, de csak sima SMTP, POP3 vagy IMAP -ot használ. Ez azért nem biztonságos, mert minden egyes kapcsolat felvételkor – legyen az levél küldés vagy fogadás – elküldjük a jelszavunkat plain text-ben (plain text == olvasható) a hálózaton keresztül. Ezt pedig (főleg ha WIFI-zünk) nagyon egyszerűen ellophatják, amire eszközöket nem mondanék, de van, és meglehetősen egyszerű a használatuk.

Ezt a kapcsolatot kell titkosítani amire többek közt a SSH port forward megoldást ad.

SSH elérés

A művelethez szükséges, hogy legyen SSH elérésünk a szerverre, hogy annak 25-ös és 143 (IMAP = TCP/143; POP3 = 110) portját forwardolhassuk a saját gépünkre (localhost).

Generált kulcs a ?néma” csatlakozáshoz

Szükséges még a kulcs alapú hitelesítés engedélyezése a célszerver SSH konfigurációjában, hogy ne kelljen minden egyes alkalommal a jelszót is beírni.

/etc/ssh/sshd_config-ban:

PubKeyAuthentication 			yes

Kulcs alapú SSH login:

budacsik@puby:~$ ssh-keygen
 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/budacsik/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/budacsik/.ssh/id_rsa.
Your public key has been saved in /home/budacsik/.ssh/id_rsa.pub.
The key fingerprint is:
59:fe:f0:3e:c1:0f:7a:cd:2a:8b:b1:d9:c6:84:2e:8e 			budacsik@puby

Az ssh-keygen -el legyártjuk a privát (marad a mi gépünkön, default: ~/.ssh/id.rsa) és publikus (ezt átmásoljuk a szerverre, default: ~/.ssh/id_rsa.pub) kulcsunkat.

~$ scp .ssh/id_rsa.pub budacsik@mailserver.domain.com:~/.ssh

Majd a ~/.ssh könyvtárba lépve a levelező szerveren adjuk ki a következő parancsot:

~$ cat id_rsa.pub >> authorized_keys

Ezzel bemásoljuk a publikus kulcsunkat a szerver által ismer kulcsok közé.

Itt (a levelező szerveren) ellenőrizzük, hogy engedélyezve van e az SSH konfigurációjában a port forwardolás.

~$ grep "AllowTcpForwarding" /etc/ssh/sshd_config
 
#AllowTcpForwarding 			yes

Teszt! Nekem működik ;)

Note: Enter passphrase (empty for no passphrase):

Ha itt megadunk jelszót, akkor a szerver a kulcs elfogadása előtt ezt kérni fogja.

Fontosabb kapcsolók:

-t Megadhatjuk, hogy RSA vagy DSA kulcsot hozunk létre. Alapértelmezett az RSA.

-c Csak RSA1 támogatja. Komment lehet a kulcshoz fűzni, például az e-mail címünk. A komment része lesz a kulcsnak és a titkosításhoz lesz használva.

-f Megadhatjuk a kulcs nevét útvonallal együtt is. Alapértelmezetten: id_rsa és id_rsa.pub.

Fájlok:

~/.ssh/id_rsa

Ez tartalmazza a privát kulcsunkat. Ennek nem szabad olvashatónak

lennie más felhasználók számára.

~/.ssh/id_rsa.pub

Ez a publikus kulcsunk. Ezt hozzá kell adni minden szerveren a

~/.ssh/authirized_keys fájlhoz ahová szeretnénk ezzel a kulccsal jelszó

nélkül belépni.

Titkosított kapcsolat létrehozása ehhez a levelező szerverhez a levelek küldésére/letöltésére

A titkosított kapcsolat létrehozása után már hiába sniffelik le a forgalmunkat, nem tudják elolvasni a jelszavunkat, és az egyéb adatainkat.

Igaz, hogy erre is vannak támadási lehetőségek, de nagyobb ?szakértelmet” igényel. Ami azért csökkenti annak a lehetőségét, hogy támadás áldozatává váljunk.

Parancs szintaxisa

~$ ssh -L sport:lohalhost:dport budacsik@mailserv@domain.com

Parancs (v. 1)

~$ ssh -L 3025:localhost:25 budacsik@mailserv.domain.com
~$ ssh -L 3143:localhost:143 budacsik@mailserv.domain.com

Ezután a levelező kliensünket is módosítani kell a következő képpen:

SMTP server host: localhost
SMTP server port: 3025
IMAP server host: localhost
IMAP server port: 3143

A parancs első verziója működik, de bele tehetnénk egy fájlba is, hogy ne kelljen mindig beírni. Ehhez két hasznos kapcsolót még bele kell tenni:

-f Használatával a háttérben fog futni, nem kell nyitva maradnia egykonzolnak.

-N Port forward-nál használatos parancs, ha lenne is nyitott terminál, ez nem engedi, hogy parancsot futtassunk rajta. Hasznos,ha ez a cél.

Plusz, hogy ne legyen olyan ?nagy” a szkript, egy sorra redukáljuk:

Parancs (v. 2)

ssh -f -N -L 3025:localhost:25  -L 3143:localhost:143 budacsik@mailserv.domain.com

Note: a ?\” karakter csak a sortörés miatt szerepel, a parancsban nincs szerepe.

A valóságban ez egy sor, csak itt most nem fért ki egy sorba.

Teszt!

netstat -ntap | grep ssh
tcp     0   0 127.0.0.1:3143     0.0.0.0:*     LISTEN     10266/ssh
tcp     0   0 127.0.0.1:3025     0.0.0.0:*     LISTEN     10266/ssh

Levelező kliens megfelelő beállítása, levelek küldése/fogadása

Ez a Mű a Creative Commons Nevezd meg!-Így add tovább! 2.5 Magyarország Licenc feltételeinek megfelelően szabadon felhasználható.

Elsősorban fontosnak tartom leírni, hogy a szabályokat egy fájlban fogjuk elhelyezni amit létrehozhatunk például a /usr/local/sbin/ könyvtárban firewall_start.sh néven (pl.).

iptables

Adminisztrációs eszköz az Ipv4 csomagszűréshez és NAT-oláshoz. (részlet az iptables manualból)
Az iptables a hálózati rétegben működik, vagyis IP csomagokkal dolgozik. Szabályokat (rules) lehet vele felállítani amiket táblákba szervez.

Három alapértelmezett (default) lánc (chain) létezik:

• INPUT: a kintről befelé érkező csomagokra match-el
• OUTPUT: a bentről kimenő csomagokra match-el
• FORWARD: az adott gépen átmenő csomagokra match-el

Megjegyzés: van még kettő (PREROUTING és POSTROUTING) de azok nem tartoznak bele ebbe a leírásba. Talán egy későbbiben.

Hozhatunk létre saját láncokat is. Lánc műveletek:

-N új lánc létrehozása
pl.: iptables -N in_attack
- létrehozza az in_attack láncot

-P lánc policy beállítása
pl.: iptables -P INPUT DROP
? ez a parancs beállítja az INPUT lánc policy-ját DROP-ra ami azt jelenti, hogy ha az INPUT láncban szereplő szabályok közül egyikre sem match-el egy csomag, akkor el lesz dobva

-F töröl minden szabályt
pl.: iptables -F
? minden létező szabályt töröl, de nem változtatja meg a láncok policy-jét!!

-L kilistázza a szabályokat, az egészet, vagy csak egy láncét
pl.: iptables -L INPUT
- kilistázza az INPUT lánc összes szabályát.

-X törli az üres láncokat
pl.: iptables -X
Ennyi elmélet kezdésnek, a többit gyakorlati példákkal mutatnám be.

Tűzfal szabályok

Először hozzuk létre a fájlt a tűzfal szabályoknak (terminálban) és tegyük futtathatóvá:
Senki ne másolja be az általam írt parancsot, mindenki vegye a fáradtságot és kézzel írja be.

sudo touch /usr/local/sbin/firewall_start.sh
sudo chmod +x /usr/local/sbin/firewall_start.sh

Ezután már az elejét meg tudjuk írni:

sudo mcedit /usr/local/sbin/firewall_start.sh

mcedit helyett bármi lehet (nano, gedit, vi, vim …)

A tartalma pedig egyelőre:

1
2
3
4
5
6

#!/bin/bash
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

A sorokat a magyarázás miatt számoztam be.

• 1.sor megadja az értelmező shellt
• 2.sor törli az összes szabályt a filter (alapértelmezett táblából.) Van a nat vagy mangle táblában is vannak szabályok akkor plusz be kell tenni a következőket is: “iptables -F -t nat” és “iptables -F -t mangle”. Ezen táblák lekérdezése: “iptables -L -vn -t nat” és “iptables -L -vn -t mangle”
• 3.sor törli az üres láncokat (-F miatt már mind üres)
• 4.5.6.sor beállítja a policy-ket DROP-ra. Én ezt ajánlom. először mindent tiltsunk, és csak azt engedélyezzük, amire szükség van. Van aki mindent engedélyez, és tiltja azokat amik tilosak. Kevesebb szabály van ha az első megoldást választjuk, és biztonságosabb is.

Az INPUT és az OUTPUT láncot is azzal célszerű kezdeni, hogy a lo (localhost) felé és felől engedünk mindent:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Az “iptables” a program neve. A “-A INPUT|OUTPUT” mondja meg, hogy melyik láncra érvényes a szabály. A “-i” és “-o” a bejövő és kimenő interfészt jelenti. Vagyis a “-i lo” = bejövő interfész a localhost.”-j ACCEPT” határozza meg a csomagok sorsát amik illeszkednek erre a szabályra. a sorsok lehetnek: ACCEPT; DROP.

Amit még fontos betenni minden tűzfal szabályok közé:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

A “-m state ?state ESTABLISHED,RELATED” a csomag állapotára utal. Vagyis azokra a csomagokra vonatkozik a szabály amik tőlünk indult csomagokra érkező válaszok. Tehát nem lehet köztük NEW (syn) csomag. Az állapotkövető szabályok egy táblázatot tartanak nyilván a kapcsolatok állapotárol, és onnan hozzák meg a döntéseiket.
Jó tanács, hogy kifelé sem engedünk minden NEW csomagot, hiszen egy jó tűzfalban szűrni kell az OUTPUT láncot is. Vannak akik ezzel nem értenek egyet. (szerintem meg ne ezen spóroljunk)

Tűzfal beállítása

Most mérjük fel az igényeket, mert ettől a ponttól egyedi esetek állhatnak fent. Most számoljunk azzal, hogy a szkriptet készítő felhasználó a következőket szeretné: internet (HTTP, HTTPS), msn, irc, levelezés és FTP.

Internet:

• 80(HTTP)/tcp
• 443(HTTPS)/tcp

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
# Későbbi részben szó lesz róla, de a következő forma az ajánlott:
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT

Ez egy egyszerű szabály ami kiengedi azokat a csomagokat amik TCP csomagok (-p tcp) és a célportjuk 80 és 443 (–dport 80|443). A 443-as port a HTTPS portja. Csakhogy ezzel még nem fok működni a böngészés, hiszen ezt a lépést megelőzi az IP cím felderítés (felodás [resolve]) DNS segítségével.

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

Így most már kiengedjük az 53-as célportú udp csomagokat is, amik a DNS szerverek felé mennek majd. A válasz befogadásáról nem kell külön gondoskodnunk, hiszen már van egy erre a célra írt szabályunk. (iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT, ezt a sort érdemes az OUTPUT lánc legelejére tenni (az lo lánc szabály után) mivel a legtöbb csomag valoszinűleg erre fog matchelni, s így nem kell áthladnia az összes többi láncon)

MSN:

• 1863/tcp

iptables -A OUTPUT -p tcp --dport 1863 -j ACCEPT

IRC:

• 6667/tcp

iptables -A OUTPUT -p tcp --dport 6667 -j ACCEPT

Levelezés:

• 25 (SMTP)/tcp
• 465(SMTPS)/tcp
• 143(IMAP)/tcp
• 993(IMAPS)/tcp
• 110(POP3)/tcp
• 995(POP3S)/tcp

1
2
3
4
5
6

iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 465 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 143 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 993 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 110 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 995 -j ACCEPT

FTP:

• 20 (FTP-ADAT)/tcp
• 21 (FTP)/tcp

iptables -A OUTPUT -p tcp --dport 20 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -j ACCEPT
modprobe ip_conntrack_ftp

A 3. sor egy FTP-hez szükséges modul betöltése. Pontosabban a passzív FTP működéséhez.
Itt nem téma az FTP részletes bemutatása, de talán megérne egy cikket. Mivel én is eltévesztettem,
ezért utána néztem, s azt láttam, hogy sok fórumban keverték a kettőt.
Tehát a modul betöltése nélkül csak aktív ftp fog működni, de a klienek általában a passzív módot támogatják, legalább is alapértelmezetten. Aktív kapcsolathoz elég a 20 és 21-es TCP port megnyitása, míg passzív kapcsolathoz a kliens kezdeményez egy új kapcsolatot egy véletlen portra (amit a szerver jelöl ki és küld el a kliens számára) a command csatornán(21)) 1024 felett.

Összefoglalás

Összefoglalva és egyszerűsítve:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#!/bin/bash
 
# modulok betolltese
modprobe ip_conntrack_ftp
 
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
 
# INPUT lanc
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state ?state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: "
iptables -A INPUT -j DROP
 
# OUTPUT lanc
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state ?state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dport 20,21,25,80,110,143,443,465,993,995,1863,6667 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT_DROP: "
iptables -A OUTPUT -j DROP

Lényegében ez egy nagyon egyszerű, de a semminél mégis lényegesen több tűzfal. Mind a két láncban van két utolsó “ismeretlen” szabály.
15. és 24. sor: sorsa LOG. Loggol minden csomagot ami nem illeszkedett egyetlen szabályra sem.
16. és 25. sor: Loggolás után eldob minden csomagot ami egyetlen előző szabálya sem illeszkedett. Igazából ez felesleges a default policy miatt, de hát a paranoia… :)

Tipp: A logot ki lehet kapcsolni, de én ezzel a módszerrel derítettem ki, hogy egyes alkalmazások milyen portokon szeretnének kommunikálni. A módszer:

tail -f /var/log/messages

Hagyni kell had fusson, majd elindítani a kérdéses alkalmazást és figyelni kell, milyen csomagokat dob el. A log-ban benne lesz, hogy milyen cél vagy forrás portot igényel és az tcp vagy udp -e.

Én szeretem bekapcsolva hagyni a logot, de hogy mégsem legyen sok felesleges log, van még pár szabály a tűzfalamban:

iptables -A INPUT -p tcp -m multiport  --dport 135,137,139,445,1026,1027,5900,6881 -j DROP
iptables -A INPUT -p udp -m multiport  --dport 135,137,139,445,1026,1027,5900 -j DROP

Ezeket a 14. sor elé tettem be. Így ezeket a csomagokat log nélkül eldobja, még mielőtt a kapcsolatállapot táblázatban kutakodna, értékes erőforrást pazarolva :)

• 135 /tcp – epmap, # Location Service
• 137 /tcp – netbios-ns, # NETBIOS Name Service
• 139 /tcp – netbios-ssn # NETBIOS session service
• 445 /tcp – microsoft-ds # Microsoft Naked CIFS
• 1026/tcp – nem szabványos port
• 1027/tcp – nem szabványos port
• 135 /udp – epmap,
• 137 /udp – netbios-ns,
• 139 /udp – netbios-ssn
• 445 /udp – microsoft-ds
• 1026/udp – nem szabványos port
• 1027/udp – nem szabványos port

Ezzel kész egy egyszerű tűzfal szkript ami a /usr/local/sbin/firewall_start.sh fájlban van.

Tűzfal automatikus indítása.
Elegánsabb megoldás, ha a tűzfal kézi inditása után kiadjuk a következő parancsot:

# Kimentéshez
sudo iptables-save > /etc/iptables.rules
 
# Visszatöltéshez
sudo iptables-restore < /etc/iptables.rules

Hol hasznos ez? Firewall szkriptünk /usr/local/sbin/firewall_start.sh utolsó sorába a következőt illesszük be:

# Ha létezik, töröljük.
if test -r /etc/iptables.rules; then
    rm -f /etc/iptables.rules
fi
 
#Tűzfal mentése
iptables-save -c > /etc/iptables.rules
if test -r /etc/iptables.rules; then
    echo "Tűzfal mentése sikeres!"
fi

Így nem az “iptables”-t kell hívogatni és a kimentett iptables.rules fájlt is lehet szerkeszteni. Sőtt, a fájlt megnézve hamar hozzá lehet szokni, és lehet eleve igy elkésziteni a szkriptet, de én ettől eltekintenék, ugyanis hátránya pl, hogy nehéz kommentezni, konnyen átláthatatlanná válik… Szerintem maradjon meg az eredeti fájl is amit szerkesztünk, majd futtatjuk, lementjuk es a továbbiakban azt töltjük vissza rendszerindításkor.

Visszatérve az automatikus indításhoz. A következőkben leírt megoldás azért is jó, mert nem kell kitallni az indulás idejét. Pontosan akkor fog felállni a tűzfal amikor az interfészek is felállnak.

sudo mcedit /etc/network/interfaces

tegyük a következő két sort a megfelelő interfészhez. pre-up iptables-restore < /etc/iptables.rules
post-down iptables-save -c > /etc/iptables.rules

Tehát a teljes konfig rész kb így néz ki:

auto eth0
iface eth0 inet static
      address 192.168.2.1
      network 255.255.255.0
      broadcast 192.168.2.255
      pre-up iptables-restore < /etc/iptables.rules
      post-down iptables-save -c > /etc/iptables.rules

Tipp: Az összess port listáját meg lehet nézni a /etc/services fájlban.

Minden esetben csak simán az "iptables" parancsot használtam. Sokan más formában írják meg, és talán igazuk van.
A szkript elején létrehozzák a parancsok változóit. Az iptables parancs helye: (which iptables) /sbin/iptables

Tehát a szkript eleje így néz ki:

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/bash
 
# valtozok deklaralasa
IPTABLES=$(which iptables)
# modulok betolltese
modprobe ip_conntrack_ftp
 
$IPTABLES -F
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

Jól látszik, hogy most már a $IPTABLES változóval hivatkozok a programra.

Végezetül, szükséges lehet egy szkript ami mindent visszaállít az eredeti állapotra:

echo "Tűzfal leállítása, és mindent engedélyezünk"
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Ez lehet pl a /root/fw.stop fájlban.

A fentiek alapján készítettem egy használható szkriptet, most ki is próbáltam.

http://pastebin.com/f1178aaad

Ellenőrzések

A szabályokat megnézhetjük a következő parancs segítségével:

iptables -L

# -L után megadható egy lánc neve is (iptables -L OUTPUT -vn)
iptables -L -vn
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[...]
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 state NEW
40 2400 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW

Azt látjuk ebben a kimenetben, hogy a tcp/80-as portot használom, már 40 csomag, azaz 2400 byte (2,3KByte) már kiment rajta.
Viszont nem használtam még a 25-ös portot. (Mert nincs bekapcsolva a levelezőm :))

Az naplózott csomagokat a messages logban figyelhetjük meg:

sudo tail -f /var/log/messages

Apr 18 04:20:53 budacsika-laptop kernel: [  107.953276] OUTPUT_DROP: IN= OUT=wlan0 SRC=192.168.2.100 DST=91.189.94.4 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=123 DPT=123 LEN=56
Apr 18 04:25:16 budacsika-laptop kernel: [  370.643450] INPUT_DROP: IN=wlan0 OUT= MAC=00:21:5d:55:a6:16:00:13:f7:1e:8f:8b:08:00 SRC=166.87.164.37 DST=192.168.2.100 LEN=46 TOS=0x00 PREC=0x00 TTL=103 ID=3816 PROTO=UDP SPT=49252 DPT=31323 LEN=26

Van egy eldobott NTP csomagom, amit azóta kiengedtem. A másk (bejövő) csomag valószínűleg jól van úgy, ha nem jön be. De ha tudni szeretnénk, hogy kicsoda, talán megtudhatjuk a következő módon:

host 166.87.164.37

Sajnos ez esetben nem :(

Vagy

whois 166.87.164.37

Amsterdam-i IP cím, mint kiderült. Viszont a whois-nak kell a TCP 43-as portot kiengedni.

Ne felejts le lapozni a folytatásért!

Windows Vista esetén ilyen beállítás már nincs, azonban kerülőúton, az árnyékmásolatok által elfoglalt hely beállításával beállítható ez az érték.

Alapesetben legalább 300 MiBájt üres terület kell a Rendszer-visszaállító működéséhez és a lemezterület 15% is elfoglalhatja.

Indítsunk el egy rendszergazdai jogú parancssort (ebben fogunk dolgozni).

Ehhez a Start menü keresőjébe írjuk be, hogy cmd, majd a találaton kattintsunk jobb egérgombbal és válasszuk a helyi menüből a Futtatás rendszergazdaként opciót.

Parancssor futtatása rendszergazdaként

Mennyi helyet foglalnak a rendszer-visszaállító pontok?

Legelőször nézzük meg, hogy mennyi területet foglalnak el jelenleg a rendszer-visszaállítási pontok.

Írjuk be a parancssorba a következő parancsot:

vssadmin list shadowstorage

Itt meghajtóra lebontva láthatjuk, hogy mennyi területet foglalnak le a visszaállítási pontok.

Árnyékmásolatok mérete

• Az árnyékmásolatok tárolására használt hely: Ennyit használnak a visszaállítási pontok
• Az árnyékmásolatok tárolására lefoglalt hely: Ennyi területet foglalt le előre a Windows a meghajtón
• Az árnyékmásolatok tárolására használható hely legfeljebb: Maximum ekkora területet foglalhat le

Maximális méret beállítása

A következő paranccsal tudjuk meghajtónként beállítani a területet:

vssadmin resize shadowstorage /on=[meghajto:] /for=[meghajto:] /maxsize=[méret]

Ahol a [meghajto:] az adott meghajtót jelenti, a [méret] pedig a maximálisan lefoglalható területet.

Egy példa, ahol a C: meghajtóra, maximálisan 2GiBájtra állítom be:

vssadmin resize shadowstorage /on=C: /for=C: /maxsize=2GB

Ha ezután kiadjuk a

vssadmin list shadowstorage

parancsot, láthatjuk, hogy a maximális érték az általunk beállított lett.

Rendszer-visszaállítás új maximális mérete

Adott volt egy probléma: egy ACER TravelMate 5330-as laptopon és -többek között- az ujjlenyomat-olvasó sem működött elsőre ubuntun. Sőt, sokadszorra sem…:)

Az

lsusb

ennyit írt róla:

Bus 003 Device 002: ID 147e:1000

Na ebből nem sok mindent tudtam meg, próbálkoztam az fprint-el és még a ThinkFinger-t is megpróbáltam, kevés sikerrel. Magát az eszközt nem ismerte fel.

Aztán rátaláltam a Fingerprint GUI-ra. Utolsó mentsvár -gondoltam. Hát igen, a letöltött (jelenleg 0.9-es) FingerprintGUI-t kivágjuk a folpakkból terminálban (mondjuk a $HOME-ba):

tar -zxvf ./fingerprintGUI-0.9.tar.gz

Innentől root-ként szaladgáljunk tovább a terminálban :)

gedit /etc/modules

Írjuk bele:

uinput

REBOOT.

Telepítés:

./install.sh --with-upek

//Itt lehet kidob majd egy hibát a terminálban (sőt szinte biztos), hogy hiányzik neki pár dolog (libfakekey0; libfprint0…) ezeket Synaptic-ból egyszerűen feltehetjük.
Innentől a leírás nagyrésze megegyezik a FingerprintGUI-0.9.tar.gz-ben található Install-step-by-step.pdf-el. Azonban személyes észrevételekkel kiegészítve:)
A telepített programnak már el kellene indulnia, persze még nem sok mindent tud csinálni.

Csináljunk egy másolatot a PAM beállításokról:

cp /etc/pam.d/common-auth /etc/pam.d/common-auth.fingerprint

Aztán szerkesszük, kap egy új sort, egy másikba pedig csak beleírunk, valahogy így:

auth sufficent libpam_fingerprint.so debug
auth [success=1 default=ignore] pam_unix.so try_first_pass nullok_secure

Itt válthatunk szintet (pl.: ctrl-alt-f2), hogy vissza tudjuk vonni, ha valami rosszul sülne el, de nekem nem volt semmilyen efféle problémám menet közben, azt kell csinálni ami le van írva, és úgy átmásolni ahogyan le van írva és nem lesz baj..:D
“Su” beállítása:

gedit /etc/pam.d/su

Itt “@include common-auth” helyett “@include common-auth.fingeprint” kell.
Ha beírod terminálba a su parancsot, akkor elvileg kijön ott, hogy Password: ÉS egy egy GUI widget, ahol kéri az ujjlenyomatodat. Ennyi lenne, és boldog ember vagy, csakhogy itt nem működött nekem. Több oka is volt nálam, nekem ezek oldották meg a problémákat (nem látta az eszközt, jogosultság gondok…):

Elvileg most már elindul a Rendszer > Beállításokból a FingerprintGUI és fel tudsz venni ujjlenyomatot. (Mondjuk nekem a root könyvtárba be kellett tennem a az én könyvtáramból a .fingeprints mappát cakkundpakk, mert valamiért hiányzott…

Használható ez belépési módszer loginnál is:
/etc/pam.d/login-ban @include common-auth cseréje @include common-auth.fingerprint-re;
Sudo-nál:
/etc/pam.d/sudo @include common-auth cseréje @include common-auth.fingerprint-re;
GDM-ben:
Először állítani kell rajta gdmsetup, és kapcsoljuk ki az automata bejelentkezést, az időzítettet és az arcböngészős megjelenést.
Azután a /etc/pam.d/gdm-ben @include common-auth helyett @include common-auth.fingeprint kell, és kommentezzük ki (#-el a sor elején) az auth requisite pam_nologin.so sort.

Nagyjából ennyi, bonyolultnak tűnik, de nem annyira az (most, hogy működik végre…:) Remélem segítettem ezzel valakinek és bocs ha kicsit nyersen írtam, de siettem.

Újvárosy Attila

Mint ígértem, igaz kicsit megkésve, de most volt időm megírni a jogosultságokról szóló cikket. :)

Akkor csapjunk is bele a lecsóba…

Tudjuk, hogy

• minden állománynak van tulajdonosa, csoportja és mindenki más
• mindezekhez tartozik olvasási (r), írási (w) és futtatási (x) jog
• a fájl(ok) futtatásához rx kell és a mappa megnyitáshoz is szintén rx kell

Ezek a betűk, pontosabban az rwx trió, mind mind egy-egy angol szónak a betűi, és mivel olvasásról, írásról és futtatásról beszélünk, így ezeknek a betűknek az angol megfelelője Read, Write, eXecute.

Nézzünk egy táblázatot erről, betűkkel (rwx):

Ha egy fájlnak a jogosultsága “-rw-r–r–” akkor a következőképpen értelmezzük:

Ezt az utolsó 9 karaktert “rw-r–r–” 3 részre oszthatjuk fel, pontosabban:

• a fájl tulajdonosa: rw-
• azok a felhasználók, akik abba a csoportba tartoznak amiben a fájl is van: r–
• és azok a felhasználók, akik se nem tulajdonosai a fájlnak és se nem tartoznak abba a csoportba amibe a fájl tartozik: r–

Láthatjuk, hogy

• a fájl tulajdonosa (rw-) olvashatja, írhatja, de nem futtathatja a fájl
• a fájl csoportjába tartozó felhasználók (r–) csak olvashatják a fájlt, írni és futtatni már nincs joguk
• az összes többi felhasználó (r–) akik nem a fájl tulajdonosai és nem is tartoznak a fájl csoportjába, azok is szintén csak olvashatják a fájlt

Nézzük meg ezt a táblázatot kicsit másképp, azaz most számokkal:

Most nézzük meg, hogy majdnem ugyanaz mint az előző táblázat, csak annyival másabb, hogy itt már nem betűkkel van jelölve a jogosultság, hanem számmal.
Nézzük meg megint, hogy ha egy állománynak 644 a jogosultsága, akkor az mit is takarhat.
Most meg fogunk lepődni, hiszen ha ránézünk a két táblázatra, ez ugyanazt jelenti mint az előbb említett rw-r–r–, azaz:

• a fájl tulajdonosa (4+2=6) olvashatja, írhatja, de nem futtathatja a fájl
• a fájl csoportjába tartozó felhasználók (4+0=4) csak olvashatják a fájlt, írni és futtatni már nincs joguk
• az összes többi felhasználó (4+0=4) akik nem a fájl tulajdonosai és nem is tartoznak a fájl csoportjába, azok is szintén csak olvashatják a fájlt

A jogosultságokat a “chmod” paranccsal tudjuk elvégezni.

A következőképpen tudjuk módosítani a fájlunk (pl.: gyakorlas.txt) jogosultságait:

chmod

• + # Hozzáad egy engedélyt.
• - # Elvesz egy engedélyt.
• = # Beállítja az engedélyt.
• r # Olvasási engedély hozzáadása.
• w # Írási engedély hozzáadása.
• x # Végrehajtási / Futtatási engedély hozzáadása.
• u # Engedélyek beállítása a fájl, könyvtár tulajdonosának.
• g # Engedélyek beállítása a csoport számára.
• o # Engedélyek beállítása mindenki más számára.
• a # Engedélyek beállítása minden felhasználó számára. (tulaj, csoport, mindenki más)
• -R # A fájlok jogosultságait az alkönyvtárban is módosítja (rekurzív módon).

Példák:

chmod u+x gyakorlas.txt # Futtatási jogosultságot ad a fájl tulajdonosának.

chmod go-rx gyakorlas.txt # Visszavonja az olvasási és futtatási jogosultságot a csoport tagjaitól és mindenki mástól.

chmod a=r gyakorlas.txt # A fájl jogosultságait csak olvashatóra állítja minden felhasználó számára.

chmod 444 gyakorlas.txt # A fájl jogosultságait csak olvashatóra állítja minden felhasználó számára.

A fájl tulajdonosának és csoportjának megváltoztatására alkalmas parancsok:

chown # A fájl tulajdonosát változtatja meg.

• -c # Azon állományok nevét jeleníti meg, melyeknek a tulajdonosa megváltozott.
• -f # Tiltja a hibaüzenetek megjelenítését.
• -R # A fájlok tulajdonosát az alkönyvtárakban is módosítja.
• -v # A módosításokról részletes listát készít.

Példák:

chown zsozso gyakorlas.txt # A fájl “zsozso” tulajdonába kerül.

chgrp felhasznalo gyakorlas.txt # A fájl a “felhasznalo” csoportba kerül.

chown zsozso:felhasznalo gyakorlas.txt # A fájl “zsozso” tulajdonába és a “felhasznalo” csoportba kerül.

Azt hiszem ennyi lenne a jogosultságokról szóló rész. :)

A következő cikkem egy meglepetés lesz, hiszen számomra is egy meglepetés volt mikor megismertem! :)

Meg szeretnék veletek osztani egy alap tűzfalat ami Ubuntu 8.10 -en biztosan megállja a helyét…

Ennek a dokumentációnak egy frissebb és részletesebb változatát itt éritek el:
Alap tűzfal otthoni pc-re (iptables)

Mindenek előtt lépjünk be terminálba és adjuk ki a következő utasítást:

sudo -s

Ezután kérni fogja a rendszergazda jelszót…, erre azért van szükség mert az alábbi műveletekhez root jogok kellenek és ugye nem akarjuk minden sor elé írni, hogy sudo

És most az iptables szabályzat:

#!/bin/bash
 
modprobe ip_conntrack_ftp
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
 
# INPUT
#######
iptables -A INPUT -i lo -j ACCEPT
# Nem hasznalatos portok tiltasa
iptables -A INPUT -p tcp -m multiport --dport 1026,1027,5900 -j DROP
iptables -A INPUT -p udp -m multiport --dport 1026,1027,5900 -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Alaprendszerhez szukseges portok
iptables -A INPUT -p udp -m multiport --dport 67,68,123,161,5353,1900 -j ACCEPT
# Messenger portok(MSN, others need to add)
iptables -A INPUT -p udp -m multiport --dport 6891:6900,6901 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dport 1863,6891:6900,6901 -j ACCEPT
# EXTRA Rendszerhez szukseges portok, Szerver portok
iptables -A INPUT -p tcp -m multiport --dport 20,21,80,139,445 -j ACCEPT
iptables -A INPUT -p udp -m multiport --dport 137,138 -j ACCEPT
# Log
iptables -A INPUT -j LOG --log-prefix ?INPUT_DROP:?
# Drop
iptables -A INPUT -j DROP
 
# OUTPUT
########
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Alaprendszerhez szukseges portok
iptables -A OUTPUT -p tcp -m multiport --dport 80,443,25,465,143,993,110,995 -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --dport 53,67,68,5353,123,161,1900 -j ACCEPT
# Messenger portok(MSN, others need to add)
iptables -A OUTPUT -p udp -m multiport --dport 6891:6900,6901 -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dport 1863,6891:6900,6901 -j ACCEPT
# EXTRA Rendszerhez szukseges portok, Szerver portok
iptables -A OUTPUT -p tcp -m multiport --dport 20,21,139,445 -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --dport 137,138 -j ACCEPT
# Log
iptables -A OUTPUT -j LOG --log-prefix ?OUTPUT_DROP:?
# Drop
iptables -A OUTPUT -j DROP

Ezt mentsd el így:

nano /usr/local/sbin/firewall_start.sh

Másold be a tűzfalat és nyomj ctrl+o, ctrl+x et.
Majd tedd futtathatóvá:

chmod +x /usr/local/sbin/firewall_start.sh

A tűzfal nem enged ki/be/át semmit csak ami be van állítva (amit “muszáj”)

Be vannak állítva az alap rendszerhez szükséges portok: internet, e-mail, stb…, és a MSN Protokollhoz szükséges portok, ha mást használunk csevegésre akkor hozzá kell adni azoknak is a portjait…illetve be vannak állítva az ftp és http szerverhez szükséges portok is…kivétel a http szerverhez az SSL (443) port mivel én nem használom… ha kell akkor csak add hozzá az INPUT listához az EXTRA portokhoz

Egyéb programok, szerverek esetén csak hozzá kell adni a ki/be menő portokat…pl.: torrent, p2p… stb. nekem ezek még nincsenek telepítve…

Ha van valami hiba, vagy egyéb észrevétel, kérdés.. nyugodtan bombázzatok.. én sem rég kezdtem szóval nyugodtan lehet javítgatni és jó tanácsokat adni…

Ja és el is felejtettem ez a firewall így a Logba írja is azokat amik nem feleltek meg a szabályoknak, vagyis amiket droppolt a tűzfal…ha ezt nem szeretnéd akkor csak vedd ki a # Log részt…

A logokat így tudod megnézni:

tail -f /var/log/messages

És íme az indító script is:

#!/bin/bash
 
firewall_start() {
echo "Enabling Firewall..."
/usr/local/sbin/firewall_start.sh
}
firewall_stop() {
echo "Disabling Firewall..."
/usr/local/sbin/firewall_stop.sh
}
firewall_restart() {
echo "Restarting Firewall Service..."
firewall_stop
sleep 1
firewall_start
}
 
case "$1" in
'start')
firewall_start
;;
'stop')
firewall_stop
;;
'restart')
firewall_restart
;;
*)
echo "usage $0 start|stop|restart"
esac

Ezt mentsd el így:

nano /etc/init.d/firewall.sh

most másold be a scriptet és aztán nyomj ctrl+o, majd ctrl+x -et.
majd tedd futtathatóvá:

chmod +x /etc/init.d/firewall.sh

És ha már a script tartalmaz stop részt is aza a tűzfalat lehet deaktiválni is… megosztom a tűzfalnak azt a részét is…

#!/bin/bash
 
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Ezt mentsd el igy:

nano /usr/local/sbin/firewall_stop.sh

most másold be a scriptet és nyomj ctrl+o, ctrl+x -et.
majd tedd ezt is futtathatóvá:

chmod +x /usr/local/sbin/firewall_stop.sh

Tehát manuálisan a következőkre van lehetőségünk:

/etc/init.d/firewall start
/etc/init.d/firewall stop
/etc/init.d/firewall restart

Azaz aktiválhatjuk, DEaktiválhatjuk és újraindíthatjuk a szolgáltatást… újraindításnak akkor lehet értelme ha éppen szerkesztgetjük a szabályokat és tesztelni szeretnénk őket…

Már majdnem minden meg is van csak ezzel egy a bibi…, hogy valamiért a rendszerindításkor nem akarja alkalmazni a tűzfal szabályokat… (ezt nem értem miért), de könnyen megoldhatjuk csak még egy parancsot kell kiadnunk…

ln -s /etc/init.d/firewall.sh /etc/rc2.d/S22firewall

Ez csinál egy symlinket az rc2.d mappába és így már a rendszer automatikusan alkalmazza az iptables szabályokat…

Ez az első Dokumentációm itt, szóval lehet nyugodtan kommentezni

Üdv. p3t1