Nem tartom valószínűnek, hogy a host XP portjait láttad, én inkább a routerre gyanakszom, az ok elég egyszerű, én otthon nem host XP alól futtatom, hanem natívan, és látszólag mégis vannak nyitott portjaim a tűzfalon.

Ha van „kidobni” való (mondjuk) 15-20, de maximum 30 ezer kis HUF a kasszádban, érdemes lenne otthonra egy kis linuxos tűzfalat összeeszkábálni, nagyon megéri a pénzét, kiválóan lehet tesztelgetni, ugyanakkor a router beépített tűzfalát kacagva veri és sokkal jobban konfolható is. Szerintem fontold meg ... :-)

Vissza a tárgyhoz, megjegyzések.

Az INVALID state-es sor a portscanner oldalak dolgában irreleváns, azok nem küldenek fake csomagokat, a gyakorlatban mégsem butaság. Ellenben látom, kimaradt a hamisított state-es csomagok szűrése, pedig az _alap_.

A loggolásal vigyázni, vigyázni, vigyázni.

Főleg, ha valaki nem csinál külön /var paríciót. Megjegyzem, én extra kocka vagyok, ezért külön /var és külön /var/log partíciót is csinálok, hadd hízzon a /etc/fstab, az a dolga, és egyébként is, nincs jobb, mint nézni, ahogy a /dev/md7 megjelenik a mount listájában. :-)

Mindenesetre a partícionálás fontos móka, asszem, fogok is egyet róla postolni, épp ma láttam három elég bután partícionált szerverről dokumentációt

Továbbá: ha minden szirszar pingelés, érdektelen porton mókoló vicek-vacak csomag miatt új sort rakatunk a /var/log/syslogba, az mihamar fel fog duzzadni (2 GB a határ, most szólok), vagy ha a logrotate be van üzemelve, akkor a /var/log/syslog.n szándékainkkal ellentétben nem az x hetes vagy hónapos, hanem a tegnapi logokat fogja tartalmazni, és a tegnapelőtti valóban fontos logbejegyzés már rég a /dev/null ösvényein jár.

Abszolút nem mellesleg a loggolás, ha „ügyesen” csináljuk, kőkeményen leterheli a vasat, és lehet csodálkozni, a rákért lassult le az Internet-kapcsolatunk, holott nem töltünk le semmit, és a szolgáltatónál sincs gond.

Nincs routerem... :-) itthon csak egy kábelmodem pöfög.
Kis linuxos tűzfal? Hogyan gondolod? Egy kiszuperált géppel?
Hamisított state-es csomagok szűrése? Utánanézek.
Ez log kérdés foglalkoztat, de amíg a tűzfal össze nem áll (bár már működik), addig nem indítok új témát erről.
:-)
Köszönöm a segítséged, mavo!
SP

Hamisított state-es csomagra vonatkozó sort nem találok, nem is emlékszem rá. Kezdek meghülyülni?
mavo segíthetnél. Hol volt ilyen? Ha volt, akkor nem tudatosan maradt ki, mert nem emlékszem rá.
SP

Vagy nem volt de kéne? Na, jó mégis utánanézek. :-)
Addig ne segíts4 :-|
SP

Mire jó a külön /var és /var/log partíció?

Hát, eddig csak hamisított IP-s anyagot találtam, de az már megvó't.
Még talán a fragmented szűrés hiányzik, de még keresgélek hozzá leírást, lehet, hogy nem kell... Amit még keresek, az pedig az, hogy a hálózat felépülése és a tűzfal szabályunk érvényesülése előtt hogyan lehet védeni a gépet (egyáltalán mi marad a rendszerben, ha leállunk). Egy háttéranyag arról ír, hogy érdemes a boot idejére egy másik szkriptet betöltetni, ami mindent tilt és azután az induló szkriptünk majd törli (iptables -F). Én inkább azon gondolkodom, hogy a leálláskor hogyan lehetne törölni a mi szabályunkat, mert ugye az alap policy DROP és ha ez marad addig, amíg a miénk elindul, akkor kb. ugyanezt értük el. Ha jól gondolom... De most ezen is elrágódhatok egy kicsit.
SP

iptables -A INPUT -f -i eth0 -j DROP
Talán ez...

„Egy háttéranyag arról ír, hogy érdemes a boot idejére egy másik szkriptet betöltetni, ami mindent tilt és azután az induló szkriptünk majd törli (iptables -F).”

Minek? Egyszerűen előbb kell lefutnia a tűzfalscriptnek, mint az eth felélesztésének, vagy azonna utána, és kész. Kevés debianos emlékemre szorítkozom, de valahol a /etc/init.d/inet1.confban van valahol egy if-up szekció, oda köll beírni, hogy /eleresi/ut/tuzfalscript, annak elméletileg mennie köll.

Salak esetén ez sokkal egyszerűbb, ott a /etc/rc.d/rc.firewall-ba kell belerakni a tűzfal script elérési útját, aztán chmod +x és kész.

Én pont azon gondolkodom, hogy mi van akkor, ha a .service file-ban futási sorrendnek 08-at adok meg? Vagyis ezt: Sequence=08
A DHCP kliens 09, a Hálózatkezelő 10.
Ez így nem működik?

Pardon, egy kérdésre nem adtam választ.

„Mire jó a külön /var és /var/log partíció?”

Szerverek esetén (ne felejtse senki, a logrotate nem feltétlenül jó megoldás) a /var/log nagyon meg tud szaladni, és ha emiatt nem megy valami például a crontabban, az gáz tud lenni. De megérne egy misét, mi minden van a /var partíción, ami ha megdöglik, akkor a dolgok átmennek kevésbé happybe ...

Aha, és ez a többi partícióval együtt csatolódik fel? aut?
Ennek az a lényege, hogy ez a partíció nem sérül, ha bármi lenne az oprendszerrel, igaz?
Most kezdek elmerülni a logok rejtelmeiben, mert az iptables témában tovább kéne lépni. Működik a tűzfal és úgy tűnik, hogy rendben, de azért még csiszolgatnám egy kicsit. Ezért áttérek a logok elemzésére, amiben teljesen sötét vagyok. De hát a többivel is valahonnan innen indultam. Na és perzse már előkészületben van a kernel fordítás is. :-) Ez lesz a log téma után 8vagy vele párhuzamosan, még nem tudom...)
Most nézek utána a log és kernel linkeknek.
Üdv:
SP

„ez a többi partícióval együtt csatolódik fel? aut?”

—> /etc/fstab

„Ennek az a lényege, hogy ez a partíció nem sérül, ha bármi lenne az oprendszerrel, igaz?”

Nem egészen. Igazából tárhely problémák megelőzésére szolgál, jómagam küszködtem egyszer fél napig olyan szerverrel, amin „mindössze” szabad területet kellett csinálnom, csak hát, mert ugye a /var/log nem volt külön, folyton lefagyott közben a rendszer.

—> /etc/fstab
Hát értettem én! Felesleges kérdés volt. :-)

/var/log/
Nem látom az összefüggést. Mitől fagy le a rendszer egy helycsinálástól? Új, üres partíciót csináltál?
SP

„Mitől fagy le a rendszer egy helycsinálástól?”

Nem, nem attól. A konkrét esetben a pppoe döglött meg, és mivel folyamatosan szemetelt a /var/log/messagesbe és a /var/log/syslogba, megtömte a /var partciót és rendszer hanyattesett. De megoldottam, lekaptam a pppoe-t, és leirtottam, amit kellett. :-)

Ez tényleg "kimerítő" válasz volt... :-)

Nem tudsz valami log analyzer progit, amit könnyű telepíteni és beállítani? Amit eddig találtam, az elég bonyolultnak tűnik nekem,,,
:-(
SP

Hosszú távon nem log analyzer kell, hanem rendszermonitor. Kocka emberektől a negios nevű cuccot kaptam tippnek, legnagyobb előnye, hogy tetszőlegesen pluginelhető: ami lin és alkalmazásai alatt elfut, és megfelel a paraméterezésnek az lehet plug-in. :-)

Nagios. Hááát. Egy standalone gépre? Ágyúval verébre?
:-)