Üdv!
Nekiálltam egy rendes tűzfal összerakásának, amiben igyekszek a legtöbb dolgot elkövetni, hogy megússzak néhány kellemetlen percet. A tűzfalnak a következő feladatai vannak: DoS védelem, portscan védelem, szükséges portok nyitása, a maradék átjutó "hibás" csomag szűrése, szükséges portok nyitása, minden egyéb elutasítása. Erre a feladatra állítottam össze ezt a scriptet. Ezzel kapcsolatban szeretném a tapasztaltabbak véleményét kikérni. Mi jó benne, mi rossz, mi kerülte el a figyelmemet, mit kellene másképp megoldani?
Ahogy teszteltem a dolgot, nagyjából jól is működik. Azonban a limit modul paraméterezése nem teljesen világos számomra így abban kérnék egy kis segítséget. Példának itt ez a sor:
$IPTABLES -A FINSCAN -m limit --limit 1/min --limit-burst 1 -j LOG --log-prefix "[Firewall] FIN scan: "
Itt úgy gondoltam, hogy percenként 1 sor(--limit 1/min) kerül majd a logba, de a burst opció többszöri utána olvasás ellenére sem teljesen világos. Ahogy megfigyeltem ez így ebben a formában nem is azt csinálja amit szeretnék, mivel csak egyetlen sor kerül a logba mikor elkezdek nmap-el garázdálkodni és utána akárhány percen át megy, több log bejegyzés nem születik.
Valamint a 30 perces tiltólista is esetenként furcsán működött, bár lehet ott más befolyásolta a dolgot. Az IP-k, akiknek kell fel is kerülnek a recent modul listájára, de 30 perc múlva nem mindig járt le a tiltás. Mivel a gépre, ahonnan nmap-eltem ssh-n keresztül jelentkeztem be a tűzfalas gépről, lehet hogy a félbeszakított ssh kapcsolat hosszabbította mindig meg a tiltás idejét...
Hu, ez így kicsit tömény lett, de remélem érthető... Tudom elég sok ilyen jellegű topik volt már, többek közt azokból is építkeztem.
Köszönöm!
- 8105 megtekintés
Hozzászólások
Van még mit tanulnod és főleg olvasnod... :D
-t raw
-t mangle
-t nat
-t filter
-P használata
Ami első körben lejött, hogy ha valamelyik port-ot kinyitod (akár TCP, akár UDP), akkor már nem is érdekes, hogy feketelistán van-e az adott IP...
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
A default policy direkte maradt ACCEPT-en, mert így icmp-unreacheable-t tudok visszadobni, egyébként meg DROP-nál semmi visszajelzés. Az említett dolgoknak utána nézek köszönöm.
Blacklist-port nyitás probléma javítva: append helyett insert, így a chain elejére kerül. Az említett táblákat megnéztem a man-ban, de egyelőre nem látom, hogy a filter táblán kívül melyikre lehetne még szükségem, illetve mi célból.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy alapvető dolgok nincsenek meg neked, tényleg olvasgass egy kicsit a témában előbb.
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
Én nem vagyok nagy iptables guru, de igyekszem.
Csak a drop szálhoz szólnék hozzá:
Szóval az Én meglátásom az, hogy ha biztonságos tűzfalat szeretnél a legelső lépés, hogy mindent DROP-olsz. Aztán ha Te úgy gondolod, h szeretnél különböző ICMP visszajelzéseket küldeni, akkor azt engedélyezed és slussz passz.
Másik tipp: Az olyan szabályokat amire várhatóan több match lesz jobb a scriptben előrébb tenni, így hamarabb kerül feldolgozásra.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a javaslatokat. Átalakítom ezen dolgok ismeretében a scriptet és természetesen törekszek minél többet olvasni a témában, ahogy eddig is. A limit paraméterezését ha valaki kicsit tudná részletezni azt megköszönném, mert sajnos továbbra sem teljesen egyértelmű a --limit és a --limit-burst közti különbség, illetve pontos működésük.
- A hozzászóláshoz be kell jelentkezni
Íme: http://tomicki.net/images/synattack.png
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
Ahogy én szoktam a tűzfalakat tervezni:
1. lo interfészre mindent engedni, conntrack-ot kikapcsolni hozzá...
2. raw táblában alacsonyszintű csomag ellenőrzést végezni... (Pl. MAC cím alapján dobálni, vagy akár protokoll alapján)
3. mangle táblában a sávszélesség menedzsmenthez szükséges csomagmegjelölés beállítása...
4. nat táblában a címfodításokat végeztetni... (Ez a tábla csak egyszer van meghívva egy kapcsolat alatt !!!)
5. filter táblában conntrack-ot aktiválni, és amit nem ismer fel, az vagy NEW, vagy INVALID... Ez alapján szűrni...
6. A szűrést érdemes szétszedni úgy, hogy minél kevesebb lépésből eldönthető legyen, mi lesz a sorsa a csomagnak...
7. Ha kell, akkor naplózni és eldobni a csomagot... (LOGDROP cél készítése.)
Ha kell, akkor privátban elküldöm a diplomám anyagát :D Egy modult fejlesztettem iptables alá... :D
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
miért csak PM-ben osztod meg. Nem GPL? :)
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Csak nehogy plágium legyen belőle! ;D
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
Ám legyen :D :D
--
Debian Linux rulez... :D
- A hozzászóláshoz be kell jelentkezni
Köszönöm az útmutatást és rts-nek a szemléltetést. Ezen dolgok ismeretében újra nekiülök az egésznek.
- A hozzászóláshoz be kell jelentkezni