Egy betörés tanulságai.

Esetleg figyelni, hogy mit csinál az, aki már belépett? Tegyük fel, hogy pistuka belépett rendesen vagy brute-force-val lényegtelen, de nem egyből basht kap, hanem valami fake shellt, azzal nagyon szépen el tud játszani, de ha sokáig nem írja be/sokszor elrontja a "parancsot", ami indítja a rendes bash-t, akkor az IP megy blacklistre xyz percre.

http://mbsd.msk.ru/stas/pam_af.html

This PAM module is intended to prevent brute-force attacks on services like SSH or telnet. It maintains internal counters, and can execute pre-configured actions when failed attempt's count exeeds limit.

[quote:ed56a6c508="1aca"][quote:ed56a6c508="muszashi"]Ja és az alapokat majdnem elfelejtettem, ilyenek például:

/usr /bin /sbin /etc -ro

Hat ez sokat nem er, mert ha nem egybol root, akkor ugysem tud oda irogatni... Remelhetoleg ;) Ha pedig egybol root, akkor ugyis mindegy...
[quote:ed56a6c508="muszashi"]
/home /var/log -noexec

Na ez igen... De a tmp is bekerulhetne...
[quote:ed56a6c508="muszashi"]
Szóval egy jó fstab fájl, már fél siker.
Üdv: M.

Egyetertek :)

Persze a tmp is, ez csak példa volt, azért volt ott a stb ...
..és ugye lehetne itt még a kedvenc további kapcsolóim is nodev, nosuid

[quote:ffc35032d4="meditor"]Apafej, egy ugrókódos kommunikációba az hallgat bele aki akar, akkor
sem tud egy ilyen csatornán bejönni, ha bitről bitre megismétli azt
az adást, amit előzőleg én nyomtam. Másfelöl meg nem az oroszlánnál
akarok gyorsabban futni, hanem a fehérembernél. Az általam írt
megoldás az ssh ellen induló támadások döntő többségét kizárja.

Látom továbbra sem sikerült megérteni a lényeget. Ugrókódozzál csak, az autótolvajok is jól mulatnak az ilyen autóriasztókon.

[quote:b45406bec3="spymorass"][quote:b45406bec3="muszashi"]A mezei userek számára ahol szükség van scp,sftp-re, ott nekik csak ez van, de csak chroot-ba (rssh-val), akinek meg shell kell, azok is csak chroot-ba érkeznek.

Az rssh és az scponly között valami lényeges különbség van? Ahogy nézegettem az rssh oldalát, mindkettő ugyanarra a dologra hivatott.

Szerintem nincsen, de én csak az rssh-t használom, így ez nem biztos.
Amit tud: külön (akár userenként) lehet szabályozni, hogy csak scp vagy sftp vagy mindkettő, vagy minden, ráadásul chroot-ba lehet a fentieket csukni.

Sziasztok!

Én mint kezdő linuxos úgy gondolom, hogy aki shellt kap abban vagy bízik az ember vagy nem. Olyan azért nincs hogy senkiben sem, mert feltételezem aki be tud ssh znia serverre abban megbízik az ember, míg az ellenkezője be nem bizonyosodik. :x Nálunk a serveren a root jelszó jól ki van találva ezt próbálták megtörni nem tudták, az ssh- scannel ugyan próbálkozások voltak de még időben észrevettük, lényegében szerintem az a fontos hogy figyeljünk a serverre. A serverre roottal közvetlen nem lehet be ssh ni, és a portok is eléggé zártak csak ami muszáj van nyítva, de próbálkozások így is vannak és szerintem lesznek is. A rendszergazda feladata az hogy kiszűrje az ilyen tevékenységeket, mert ha nem lennének ilyenek valószínű rendszergazdára sem nagyon lenne szükség. :roll: A védelmet persze erősíteni kell.

nálam /etc/hosts.deny:
sshd: all

allow-ban meg annak az ipje akit beengedek.

[quote:ba0e7a957c="csillagocska"]Sziasztok!

Én mint kezdő linuxos úgy gondolom, hogy aki shellt kap abban vagy bízik az ember vagy nem. Olyan azért nincs hogy senkiben sem, mert feltételezem aki be tud ssh znia serverre abban megbízik az ember, míg az ellenkezője be nem bizonyosodik. :x Nálunk a serveren a root jelszó jól ki van találva ezt próbálták megtörni nem tudták, az ssh- scannel ugyan próbálkozások voltak de még időben észrevettük, lényegében szerintem az a fontos hogy figyeljünk a serverre. A serverre roottal közvetlen nem lehet be ssh ni, és a portok is eléggé zártak csak ami muszáj van nyítva, de próbálkozások így is vannak és szerintem lesznek is. A rendszergazda feladata az hogy kiszűrje az ilyen tevékenységeket, mert ha nem lennének ilyenek valószínű rendszergazdára sem nagyon lenne szükség. :roll: A védelmet persze erősíteni kell.

ahahaha leccives ezt legkozelebb a fun kategoriaba mert eppen ittam es felrenyeltem

Az nem lep be. Hasznaljon erre a celra olyan gepet aminek van fix IP-je (tovabb SSH-zas). Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:34e30a7791="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

[quote:360537e45d="trey"]Az nem lep be. Hasznaljon erre a celra olyan gepet aminek van fix IP-je (tovabb SSH-zas). Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:360537e45d="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Igen talál egy fix ip-s gépet amiről be tudna lépni, de ott is lekorlátozzák, hogy csak fix ip-ről léphet be. Nyalom a sót :-D

[quote:795cece639="trey"]Az nem lep be. Hasznaljon erre a celra egy bouncer gepet, aminek van fix IP-je. Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:795cece639="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Köszi, akkor nyalom. Az usereim meg forduljanak fel, ha gondjuk van. :) ..mondjuk ettől függetlenül tényleg. :) ...ma úgyis erős a napfolttevékenység.
Na szórok egy kis vasreszeléket a monitorba.

Üdv: M.

[quote:fb7a3953a7="meditor"][quote:fb7a3953a7="zaphodb"]nálam /etc/hosts.deny:
sshd: all

allow-ban meg annak az ipje akit beengedek.

És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

:-) az van, szóval ez csak az otthoni gépem
szóval akinek nincs szép biztonságos ip range-e az nem lép be:)

[quote:c2fda28144="meditor"]
Apafej, egy ugrókódos kommunikációba az hallgat bele aki akar, akkor
sem tud egy ilyen csatornán bejönni, ha bitről bitre megismétli azt
az adást, amit előzőleg én nyomtam. Másfelöl meg nem az oroszlánnál
akarok gyorsabban futni, hanem a fehérembernél. Az általam írt
megoldás az ssh ellen induló támadások döntő többségét kizárja.

Nem ertem, miert kell elbonyolitani... Az ssh ellen iranyulo tamadasok donto tobbseget a pubkey auth is megoldja, sokkal egyszerubben es biztonsagosabban.

erre talaltak fel a knockd -t mondjuk!
Ja + nem ssh porton figyel stb..

[quote:959a1fa199="hunger"][quote:959a1fa199="meditor"]Apafej, egy ugrókódos kommunikációba az hallgat bele aki akar, akkor
sem tud egy ilyen csatornán bejönni, ha bitről bitre megismétli azt
az adást, amit előzőleg én nyomtam. Másfelöl meg nem az oroszlánnál
akarok gyorsabban futni, hanem a fehérembernél. Az általam írt
megoldás az ssh ellen induló támadások döntő többségét kizárja.

Látom továbbra sem sikerült megérteni a lényeget. Ugrókódozzál csak, az autótolvajok is jól mulatnak az ilyen autóriasztókon.

Ha jól látom ezek itt ötletek. Fikázni mindenki tudd. Ha tudsz olyan megoldást, ami "megtörhetetlen", akkor mond, de olyat amitől a rendszer használható marad és nem egy lebetonozott pincében ücsörög a Rendzergazda, minden hálózattól elzárcva.

Elmondom mire gondolok:

Sok helyen csinaljak azt, hogy van egy masik gep az eles gep elott. Az viszonylag szabadabban konfiguralt, azaz elfogad ssh kapcsolatot barhonnan, kulccsal vagy jelszoval. Persze ez a gep semmit sem csinal, van rajta egy ures chroot vagy jail, aztan kesz. Mogotte privat halon van az eles gep, amire at lehet SSH-zni a kulso geprol. Igy ket helyrol lehet elerni az eles gepet. Vagy egy masik szuro gepen keresztul, vagy az internetrol, de csak fix IP-rol. A biztonsagnak ara van.

Mondjuk nem tiszta, hogy egy fontos gepen miert van local user az adminon kivul akinek el kell erni a gepet? Jatszos gepen (free shell, irc, stb.) meg fel kell keszulni arra, hogy szoftver hiba miatt felpattintjak. Ott csak okor tarol fontos adatot.

[quote:4aa1387479="muszashi"][quote:4aa1387479="trey"]Az nem lep be. Hasznaljon erre a celra egy bouncer gepet, aminek van fix IP-je. Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:4aa1387479="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Köszi, akkor nyalom. Az usereim meg forduljanak fel, ha gondjuk van. :) ..mondjuk ettől függetlenül tényleg. :) ...ma úgyis erős a napfolttevékenység.
Na szórok egy kis vasreszeléket a monitorba.

Üdv: M.

[quote:c7ef4f1e10="snowflake"][quote:c7ef4f1e10="WatchDog"]A sok hasznos hozzaszolason kivul esetleg lehetne olyat is csinalni iptables-el, hogy egy adott iprol egy adott idointervallumon belul hanyszor csatlakozhat vki. Esetleg vmi szkript, ami sok probalkozas utan tempban-ra teszi az illetot, amit aztan egy bizonyos ido elteltevel leszedi...vagy otthagyja, es majd kezzel kell kiszedni a blacklist-bol.

Én otthon ezt használom a próbálkozók ellen:
http://denyhosts.sourceforge.net/

lehet, hogy én nem értek valamit, de ennek a denyhost purge funkciójának a leírása nem hülyeség egy kicsit?
lévén azt írja, hogy ha legalább egy elem nem lett átmozdítva a .purge.tmp -be, akkor nem csinál semmit, ha pedig mindegyik át lett mozgatva akkor visszacsinálja :)) ennek mi értelme???
hülyeség a fakuban

[quote:edd4578fff="csillagocska"]Sziasztok!

Én mint kezdő linuxos úgy gondolom, hogy aki shellt kap abban vagy bízik az ember vagy nem. Olyan azért nincs hogy senkiben sem, mert feltételezem aki be tud ssh znia serverre abban megbízik az ember, míg az ellenkezője be nem bizonyosodik. :x

Kár hogy hasonlatokat nem hoztál. Pl.: csak azzal fexel le gumi nélkül akiben megbízol és hasonlók. :P

[quote:edd4578fff="csillagocska"]Nálunk a serveren a root jelszó jól ki van találva ezt próbálták megtörni nem tudták

Nemsemmi... gondolom iszonyat brainstorming lehetett jól kitalálni egy root jelszót. :lol:

[quote:edd4578fff="csillagocska"]A rendszergazda feladata az hogy kiszűrje az ilyen tevékenységeket, mert ha nem lennének ilyenek valószínű rendszergazdára sem nagyon lenne szükség. :roll:

És akkor aztán már végképp a villanyszerelő nagypapa és a hűtőgépszerelő józsi tervezné és telepítené a rendszert a bankoknál is.

[quote:edd4578fff="csillagocska"]A védelmet persze erősíteni kell.

Hú, hát a szívemből beszélsz! :D

A "port kopogtatás" lehet egy megoldás a biztonságos SSH kapcsolatra.
Egy Linuxvilágban olvastam róla. A lényege a következő, már amennyire emlékszem rá:A kliens kopogtat egy megadott porton előre beállított számú kopogtatással, majd vár egy szintén előre megadott ideig és újra kopogtat. Ekkor a szerver amennyiben szabályos kopogtatást érzékel indítja az adott szolgáltatást és ha bizonyos időn belül nem jön létre a kapcsolat, akkor ismét leállítja. A szabályos kapcsaolat bontása után szintén leállítja az adott szolgáltatást.
No ez a problámám, hogy most sem találom, hogy melyik Linuxvilágban volt. Pedig én is hasonló cipőben járok és a logjaim is tele vannak módszeres és intenzív próbálkozásokkal.

Hoppá! Nem is a Linuxvilágban volt!
http://blog.linuxforge.hu/?page_id=12
És itt a HUP-on volt hír 2005. Szeptember 14.-én: http://www.hup.hu/modules.php?name=News&file=article&sid=9670&mode=nested

[quote:727c99489b="dirobi"]Ha jól látom ezek itt ötletek. Fikázni mindenki tudd. Ha tudsz olyan megoldást, ami "megtörhetetlen", akkor mond, de olyat amitől a rendszer használható marad és nem egy lebetonozott pincében ücsörög a Rendzergazda, minden hálózattól elzárcva.

Már elmondtam, csak ezek szerint te sem figyelsz...
Az ilyen barkács megoldásoknak semmi értelme. Amelyik gépen előfordulhat proba user proba jelszóval ott nincs megfelelő policy. Először ezen kellene elgondolkozni, nem pedig sufni megoldásokat kitalálni. Biztos nagyon jó védelem, hogy az sshd csak akkor fut, amikor be akar jelentkezni rá valaki, de vegyük észre, hogy ez is csak az idler szervereken működik. Ahol van néhány user akik naponta többször bejelentkeznek ott állandóan futnia kell és semmi sem garantálja, hogy legközelebb nem egy másik szolgáltatáson mennek be. Hiába van rács az ajtó előtt, ha nyitva van a pinceablak. A statisztikák alapján egyébként sem ssh-n történik a legtöbb betörés.

[quote:bc5e512fea="trey"]Elmondom mire gondolok:

Sok helyen csinaljak azt, hogy van egy masik gep az eles gep elott. Az viszonylag szabadabban konfiguralt, azaz elfogad ssh kapcsolatot barhonnan, kulccsal vagy jelszoval. Persze ez a gep semmit sem csinal, van rajta egy ures chroot vagy jail, aztan kesz. Mogotte privat halon van az eles gep, amire at lehet SSH-zni a kulso geprol. Igy ket helyrol lehet elerni az eles gepet. Vagy egy masik szuro gepen keresztul, vagy az internetrol, de csak fix IP-rol. A biztonsagnak ara van.

Mondjuk nem tiszta, hogy egy fontos gepen miert van local user az adminon kivul akinek el kell erni a gepet? Jatszos gepen (free shell, irc, stb.) meg fel kell keszulni arra, hogy szoftver hiba miatt felpattintjak. Ott csak okor tarol fontos adatot.

[quote:bc5e512fea="muszashi"][quote:bc5e512fea="trey"]Az nem lep be. Hasznaljon erre a celra egy bouncer gepet, aminek van fix IP-je. Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:bc5e512fea="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Köszi, akkor nyalom. Az usereim meg forduljanak fel, ha gondjuk van. :) ..mondjuk ettől függetlenül tényleg. :) ...ma úgyis erős a napfolttevékenység.
Na szórok egy kis vasreszeléket a monitorba.
Üdv: M.

Hát mert pl. a tárhelyüket el kell érniük távolról, stb. Persze nem a NASA, de azért vannak fontos cuccok. Itt ennyi volt, ebből kellett kihozni a maximot. Végül is szerintem a ssh kulcsok használata elégséges kompromisszum a használhatóság és a biztonság között. Na még a -oPort=54421 is belefér a konfortos használatba. Én inkább arra használtam a gépet, amit eléraktam, hogy tűzfal legyen, mert a routert a beépített csomagszűréssel kevésnek találtam. (de pl a routert csak a szerver felől lehet elérni, tehát bemegyek a továbbított porton a szerverre ssh-val a routeren és a tűzfalon át és onnan tudok csak bejelentkezni a routerre. Így a routert állítgatni csak kulcs és jelszó ismeretében lehet. -meg a tűzfalat is persze)

De egyébként egyetértek elméletben, de ez van gyakorlatban. A kulcsomat meg mindig viszem magammal pendrivével (+knoppix CD), mivel azt könnyebb hordozni, mint egy fix IP-t!

Üdv: M.

Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

http://blinkeye.ch/mediawiki/index.php/SSH_Blocking
itt ni :)

honnan?
korod?
F/L?
képed van?

:P

[quote:450673a09d="suti"]ehhez az ssh töréshez lenne egy kérdésem! sokat tapasztaltam auth.log -ban, hogy tetszőleges ipkről próbálkoznak belépéssel a gépre, több usert, több jelszóval, majd továbbállnak! nem tud valaki olyan ssh configot, ami 3 sikertelen belépés után letiltja az ipt egy percig? vagy akármi hasonló is érdekelne!

örülök, hogy elolvastad a hozzászólásod felelett kb 10 üzivel feljebb levő hozzászólásomat...

Jajj drastik és hunger akkor arcotok van, ha elmentek az 5cm-es tévém előtt már akkor is lemaradok 2 sorozatról 8)

Egyébként meg itt arról van szó, hogy hogyan lehet úgy biztonságosság tenni egy rendszert, hogy az ne menjen a használhatóság rovására. Vazz nem óhajtok minden egyes belépés előtt sms-t küldeni, portot kopogtatni ssh tunneleken keresztül a 20-ik proxy szerveren keresztül áthatolni, hogy egy ps parancsot ki tudjak adni a szerveren.

Valahogy kompromisszumokat keresünk a totális biztonság és használhatóság között.

Ha fikázást akarok akkor a flame rovatban nyitok topicot. Ha nincs értelmes hozzászólás akkor lehet alapba állítani a szájakat és ujjakat.

előre: nem olvastam végig az egészet.

Az ssh-s próbálgatásra viszont van ellenszer még akkor is, ha bárhonnan lehetségesnek kell lennie a csatlakozásnak:
http://tuxworld.homelinux.org:81/blacklist/

Az oldalon cron-script kezeli az auth.log-ot és a "csűnya" címeket adatbázisba rakja, ami blacklist is egyben. Ha egyszer be is tudott jelentkezni valaki sokszoros próbálkozásra, akkor is bekerül a címe/tartománya a blacklistre.

[quote:3f08fbdc26="csillagocska"]Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

A rendszergazda szerinted hogy tudja "figyelni a rendszert"? Ezt fejtsed ki légyszives, különös tekintettel arra, hogy napi 24 órában állandóan és _bármilyen_ megtörési kisérletet azonnal észrevegyen. Mondjuk amíg megebédelsz bedarálják a gépet egy rossz beállítás miatt (amiről csak később derül ki, hogy rossz persze). Ilyenkor mivan? Nem szűrted ki, mert lame vagy? Publikus webszerveren ennél is jobb a helyzet, mert a juzerek mindent szeretnének, ami azzal jár, hogy a phpBB és pl. mambo exploitok is lefuthatnak. Legszebb, hogy nem is biztos, hogy észreveszed a néhány száz processben azt aki épp lappang.

A rossz shellbe írt "su -" -t pedig már szerintem sokan elkövettük és még mindíg élünk.

[quote:3879eca281="hunger"]Már elmondtam, csak ezek szerint te sem figyelsz...
Az ilyen barkács megoldásoknak semmi értelme. Amelyik gépen előfordulhat proba user proba jelszóval ott nincs megfelelő policy. Először ezen kellene elgondolkozni, nem pedig sufni megoldásokat kitalálni. ...

Először is bocs, a kirohanásomért, de valahogy morcos voltam tegnap és mivel inkább fikáztál (főleg drastik kolléga) ezért írtam amit írtam... Na mindegy fátylat rá, ha lehet.

Tehát a biztonság alapjai:

1. Alapból mindent tiltunk amit nem engedünk meg, tehát elejét vesszük, hogy bármi is be/ki kommunikáljon.
2. A rendszergazdán kivül lokális júzer csak is nagyon indokolt esetben van, és az is jól elszeparálva (chroot, jail etc)
3. SSH ha lehetséges nem ismert porton fut és publikus kulcs hozzáféréssel érhető csak el.
4. A fontos és futó szolgáltatások nem root joggal futnak és állandóan up-to-date állapotban vannak biztonsági szempontból
5. A security értesítők folyamatos figyelése (lehetséges hibák kiszűrése céljából)
6. Állandó mentés a fontos adatokról.
7. A rendszer folyamatos követése és a változásokról azonnali értesítés, gondolok itt arról, hogy valaki belépett a rendszerbe kiadott egy su parancsot etc..
8...???

Nagyjából ennyi ami az alapokat érinti és ezt lehet még a végtelenségig fokozni???

[quote:7171a9a4fc="hunger"]honnan?
korod?
F/L?
képed van?

:P

arcod?
van képed hozzá?
:lol:

[quote:d2706578fe="bitumen"]előre: nem olvastam végig az egészet.

Az ssh-s próbálgatásra viszont van ellenszer még akkor is, ha bárhonnan lehetségesnek kell lennie a csatlakozásnak:
http://tuxworld.homelinux.org:81/blacklist/

Az oldalon cron-script kezeli az auth.log-ot és a "csűnya" címeket adatbázisba rakja, ami blacklist is egyben. Ha egyszer be is tudott jelentkezni valaki sokszoros próbálkozásra, akkor is bekerül a címe/tartománya a blacklistre.

...aztán, ha legközelebb Te kapsz onnan IP-t , akkor meg nyalod a sót. :)

Pl, én monornetes vagyok, és itt is van sok idióta a hálózatban. (Küldtem is párszor próbálkozó IP időpont párosokat a szolgáltatónak, nem érdekelte, még csak nem is válaszolt. -bűnpártolás?) Ha ilyesmit alkalmaznék a szerveren könnyen lehet, hogy holnap én kapnám meg a címet, amiről tegnap a barom próbálkozott. ...és akkor nyalhatnék. :)

Üdv: M.

[quote:0e96552037="andrej_"][quote:0e96552037="csillagocska"]Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

A rendszergazda szerinted hogy tudja "figyelni a rendszert"? Ezt fejtsed ki légyszives, különös tekintettel arra, hogy napi 24 órában állandóan és _bármilyen_ megtörési kisérletet azonnal észrevegyen. Mondjuk amíg megebédelsz bedarálják a gépet egy rossz beállítás miatt (amiről csak később derül ki, hogy rossz persze). Ilyenkor mivan? Nem szűrted ki, mert lame vagy? Publikus webszerveren ennél is jobb a helyzet, mert a juzerek mindent szeretnének, ami azzal jár, hogy a phpBB és pl. mambo exploitok is lefuthatnak. Legszebb, hogy nem is biztos, hogy észreveszed a néhány száz processben azt aki épp lappang.

A rossz shellbe írt "su -" -t pedig már szerintem sokan elkövettük és még mindíg élünk.

A figyelést szerintem nem szó szerint kell érteni, hogy állandóan azt nézem, hogy milyen processzek indulnak és állnak le... SZVSZ

azt nem lehet megcsinálni, hogy a sshzó ip-t összevetem egy dyndns host-al? ha egyezik (a feloldása), akkor kb ugyanott vagyunk, mintha csak a fix ip-t engednéd be.

[quote:d8c0f01a72="_Polesz_"]Valahogy kompromisszumokat keresünk a totális biztonság és használhatóság között.

Erről pedig tudod hogy nem létezik. Keresni mondjuk lehet ettől még. Vagy magasfokú biztonság vagy jó használhatóság van. A kettő együtt általában nem vagy nagyon erős kompromisszumokkal megy (ami már csökkent használhatóságot és biztonságot jelent).

Egy adott rendszer védelménél mérlegelni kell a fontosságát és értékét, illetve hogy a védelmére fordított energia összhangban van-e az első kettővel. Ez alapján lehet (és kell) az arra megfelelő védelmet kitalálni és megvalósítani.

A shelluserezésről meg annyit, hogy vannak olyan "haveri gépek" általában mindenkinek a látókörében, amire "bennfentesek" kapnak shellt. Igazán éles gépekre pedig senki olyan akinek nem létkérdés nem kaphat a szükségesnél tobb jogot, beleértve a fölösleges accountokat.

@muszashi

Igen, ebben van igazság. A megoldás egy whitelist (amiben természetesen localhost is benne van). Nálam már jó ideje működik a dolog és egyre kevesebb próbálkozás van.
2 év alatt egyszer volt olyan, hogy egy user nem tudott csatlakozni, mert tiltott volt a tartomány. Ekkor ment a címe a whitelistbe... (ami ugye akár dinamikus is lehet...)

[quote:4b5a769f59="wlaszi"]azt nem lehet megcsinálni, hogy a sshzó ip-t összevetem egy dyndns host-al? ha egyezik (a feloldása), akkor kb ugyanott vagyunk, mintha csak a fix ip-t engednéd be.

Erre én is kiváncsi lennék.

Na, hogy kicsit komolyabb irányba visszatereljük a szót, nálam például E-mailek jönnek a szerverektől. Nem sok, ert azt nem olvasnám, de ami biztosan jön minden nap:

* napi mentésről egy eredmény, alap esetben egy idő+dátum+ellenörző összeg OK, ha nem így lenne, akkor részletes napló. (ez tuóbbi fájlba mindig elkészül) Ez hajnali 1-2 felé jön, leghamarabb reggel nézem. ..hacsak nem szuttyogok az éjjszaka.

* rendszer integritás állapotáról naponta 6:25-kor. (Ez az összes fontos fájl változását figyeli és küldi az eredményt. Mely fájlok, mikor módosultak. .persze nem /var/log meg /home :)

Áramszünet esetén jön a mail, ha visszajött az áram, akkor is.

Ennyi jön. Ezen kívül minden nap 1X be SSH-zok a szerverekre, szúrópróbaszerűen megnézek 1-2 naplót, nézek egy apt-get update -t, ilyesmit. Tehát kicsit élvezem az üzemeltetést. Ennél többször csak akkor lépek be, ha kell valamit csinálni, vagy nem jön meg valamelyik usernek mail és meg kell nézni a naplóban, hogy miért. (utána meg
telefonálnom kell, hogy mit állítson be a küldő a szerverén, vagy a DNS-én :)

Üdv: M.

[quote:216f5a3640="_Polesz_"][quote:216f5a3640="andrej_"][quote:216f5a3640="csillagocska"]Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

A rendszergazda szerinted hogy tudja "figyelni a rendszert"? Ezt fejtsed ki légyszives, különös tekintettel arra, hogy napi 24 órában állandóan és _bármilyen_ megtörési kisérletet azonnal észrevegyen. Mondjuk amíg megebédelsz bedarálják a gépet egy rossz beállítás miatt (amiről csak később derül ki, hogy rossz persze). Ilyenkor mivan? Nem szűrted ki, mert lame vagy? Publikus webszerveren ennél is jobb a helyzet, mert a juzerek mindent szeretnének, ami azzal jár, hogy a phpBB és pl. mambo exploitok is lefuthatnak. Legszebb, hogy nem is biztos, hogy észreveszed a néhány száz processben azt aki épp lappang.

A rossz shellbe írt "su -" -t pedig már szerintem sokan elkövettük és még mindíg élünk.

A figyelést szerintem nem szó szerint kell érteni, hogy állandóan azt nézem, hogy milyen processzek indulnak és állnak le... SZVSZ

Nyilván, viszont akkor nemtudod figyelni, lásd a fenti félórás példát.

[quote:0e361976c2="_Polesz_"]Jajj drastik és hunger akkor arcotok van, ha elmentek az 5cm-es tévém előtt már akkor is lemaradok 2 sorozatról 8)

Egyébként meg itt arról van szó, hogy hogyan lehet úgy biztonságosság tenni egy rendszert, hogy az ne menjen a használhatóság rovására. Vazz nem óhajtok minden egyes belépés előtt sms-t küldeni, portot kopogtatni ssh tunneleken keresztül a 20-ik proxy szerveren keresztül áthatolni, hogy egy ps parancsot ki tudjak adni a szerveren.

Valahogy kompromisszumokat keresünk a totális biztonság és használhatóság között.

Ha fikázást akarok akkor a flame rovatban nyitok topicot. Ha nincs értelmes hozzászólás akkor lehet alapba állítani a szájakat és ujjakat.

jajj, itt már mindenki ismeri az ilyen drasztikus kollégákat, a rutinos fórumozó egyszerűen csak skippeli az írását ... ;)

[quote:bdfd6e4dc5="wlaszi"]azt nem lehet megcsinálni, hogy a sshzó ip-t összevetem egy dyndns host-al? ha egyezik (a feloldása), akkor kb ugyanott vagyunk, mintha csak a fix ip-t engednéd be.

Kb 1 éve próbáltunk ilyet, de "nem ment" és nem ástuk be magunkat a témába...

[Off]Aztán az érzékeny adatokat kiviszik papíron. :lol:[/Off]

Hmm, az ssh-s belépési kísérleteket 'altatni' 10-15 másodpercig? Egyszerű usernél nem sokat számít, a szótáras törést viszont egy-két nagyságrenddel lassítja, az meg már elég, ha nem fél nap kell hozzá, hanem másfél hónap, mert addig úgyis rá fogsz nézni a naplókra, és még arra is van időd, hogy megkeresd és félbehajtsd a derék próbálkozót.

[quote:99b45aa14d="meditor"][quote:99b45aa14d="hunger"] A statisztikák alapján egyébként sem ssh-n történik a legtöbb betörés.

Hanem hol?

Webes script hibákat kihasználva (php/asp/cgi/perl/python, stb.), de ezek jórészét script kiddiek csinálják, azért _script_ kiddiek. :) Amíg ezek ellen sincsenek jórészt védve az interneten lévő gépek, addig nincs miről beszélni. ssh elé mindenféle bűvös dolgot tenni, teljesen felesleges. Egy script kiddie ilyen irányú próbálkozásai ellen az is elég, ha nincsenek könnyen kitalálható jelszavak. Amelyik jelszót meg lehet fejteni szótár alapú támadással az nem sokat ér.

[quote:9595527017="trey"]Az nem lep be. Hasznaljon erre a celra olyan gepet aminek van fix IP-je (tovabb SSH-zas). Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:9595527017="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Na ez tipikusan az a rendszergazda aki istennek kepzeli magat, a userek meg dogoljenek meg. A szerver nem azert van, hogy a rendszergazda adminisztralgasson meg mentegessen, hanem azert hogy a felhasznalok felhasznaljanak szvsz. Az hogy a felhasznalo meg nem tud fix iprol belepni, az az isp-k szolgaltatasainak koszonhetoek. Valoszinu, hogy ez utobbiak nem fognak valtoztatni az uzletpolitikajukon, tehat a rendszergazdaknak kell alkalmazkodniuk. A port kopogtatas jo otlet, de pl mobiltelefonos megoldas is szoba johet. A user sms-ben elkuld egy nyilt kulcsot + ip cimet es kap 1,2,x oras belepesi lehetoseget. Ezt a nyilt kulcsot lehet hetente 1x szinkronizalni bent a cegnel. Ceges elofizetes eseten meg az sms ara sem folrengeto osszeg. Kis rutinnal eleg jo policyt lehet beallitani hozza.

Udv Zoli

Nos andrej_ oké ez gond, de én nem erre értettem, és leírtam olyan nincs hogy újabb bugokat ne találnának vagy réseket amiket esetleg ki lehet használni, mindenre nem tudsz odafigyelni, de attól még hogy mindet elzársz a userektől mert az biztonságos, nem biztos hogy az a célravezető, itt erre értettem. És nem napi 24 órában gondoltam, az lehetetlen. Ebbe lehet nem gondoltam bele annyira, akkor elnézést.

[quote:d1ff1335db="colos"][quote:d1ff1335db="trey"]Az nem lep be. Hasznaljon erre a celra olyan gepet aminek van fix IP-je (tovabb SSH-zas). Ha ilyen sincs neki, akkor nyaljon sot. :-)

[quote:d1ff1335db="meditor"]És mit csinálsz azzal, aki nem fix ipről kell, hogy belépjen?

Na ez tipikusan az a rendszergazda aki istennek kepzeli magat, a userek meg dogoljenek meg. A szerver nem azert van, hogy a rendszergazda adminisztralgasson meg mentegessen, hanem azert hogy a felhasznalok felhasznaljanak szvsz. Az hogy a felhasznalo meg nem tud fix iprol belepni, az az isp-k szolgaltatasainak koszonhetoek. Valoszinu, hogy ez utobbiak nem fognak valtoztatni az uzletpolitikajukon, tehat a rendszergazdaknak kell alkalmazkodniuk. A port kopogtatas jo otlet, de pl mobiltelefonos megoldas is szoba johet. A user sms-ben elkuld egy nyilt kulcsot + ip cimet es kap 1,2,x oras belepesi lehetoseget. Ezt a nyilt kulcsot lehet hetente 1x szinkronizalni bent a cegnel. Ceges elofizetes eseten meg az sms ara sem folrengeto osszeg. Kis rutinnal eleg jo policyt lehet beallitani hozza.

Udv Zoli

...de attól még az userek megdögölhetnek. :) Mi is a felhasználóneved? klaty..klatyi. klatty :)

A port kopogtatas jo otlet, de pl mobiltelefonos megoldas is szoba johet. A user sms-ben elkuld egy nyilt kulcsot + ip cimet es kap 1,2,x oras belepesi lehetoseget. Ezt a nyilt kulcsot lehet hetente 1x szinkronizalni bent a cegnel. Ceges elofizetes eseten meg az sms ara sem folrengeto osszeg. Kis rutinnal eleg jo policyt lehet beallitani hozza.

És ezt miért nem lehet webes felületen megcsinálni? User kinyitja a cég ssl-es oldalát, a szervernek már meg is van az ip-cím, user beírja a jelszót és már rajta is van a whitelisten...

[quote:f9b08ce4dc="bitumen"]

A port kopogtatas jo otlet, de pl mobiltelefonos megoldas is szoba johet. A user sms-ben elkuld egy nyilt kulcsot + ip cimet es kap 1,2,x oras belepesi lehetoseget. Ezt a nyilt kulcsot lehet hetente 1x szinkronizalni bent a cegnel. Ceges elofizetes eseten meg az sms ara sem folrengeto osszeg. Kis rutinnal eleg jo policyt lehet beallitani hozza.

És ezt miért nem lehet webes felületen megcsinálni? User kinyitja a cég ssl-es oldalát, a szervernek már meg is van az ip-cím, user beírja a jelszót és már rajta is van a whitelisten...

Jelenleg jobban torhetoek a webszerverek mint a mobiltelefonok tudomasom szerint

[quote:055c9d3c19="_Polesz_"]Először is bocs, a kirohanásomért, de valahogy morcos voltam tegnap és mivel inkább fikáztál (főleg drastik kolléga) ezért írtam amit írtam... Na mindegy fátylat rá, ha lehet.

Tehát a biztonság alapjai:

1. Alapból mindent tiltunk amit nem engedünk meg, tehát elejét vesszük, hogy bármi is be/ki kommunikáljon.
2. A rendszergazdán kivül lokális júzer csak is nagyon indokolt esetben van, és az is jól elszeparálva (chroot, jail etc)
3. SSH ha lehetséges nem ismert porton fut és publikus kulcs hozzáféréssel érhető csak el.
4. A fontos és futó szolgáltatások nem root joggal futnak és állandóan up-to-date állapotban vannak biztonsági szempontból
5. A security értesítők folyamatos figyelése (lehetséges hibák kiszűrése céljából)
6. Állandó mentés a fontos adatokról.
7. A rendszer folyamatos követése és a változásokról azonnali értesítés, gondolok itt arról, hogy valaki belépett a rendszerbe kiadott egy su parancsot etc..
8...???

Nagyjából ennyi ami az alapokat érinti és ezt lehet még a végtelenségig fokozni???

Security témakörben a legelső kérdés amelyen el kell gondolkozni, hogy ki ellen akarod megvédeni a rendszeredet? Ha erre meg van a válasz, akkor lehet utána tovább menni.

Jelenleg jobban torhetoek a webszerverek mint a mobiltelefonok tudomasom szerint

jogos.

Elsősorban az SSH v1 törhető meg... Általában elég a védelemhez egy v1 tiltás + erős jelszó.

[quote:9fcd46726a="szaszg"]Te sose voltal meg ugy besszivva, hogy hulyesegeket irtal????

Ha lettem volna, akkor sem írnám nyilvános fórumba :roll:

[quote:2fe6590b46="Frantique"]Elsősorban az SSH v1 törhető meg... Általában elég a védelemhez egy v1 tiltás + erős jelszó.

altalaban igen, de a betegesen paranoiasoknak nem :wink:

[quote:5eaae699e4="bitumen"][quote:5eaae699e4="szaszg"]Te sose voltal meg ugy besszivva, hogy hulyesegeket irtal????

Ha lettem volna, akkor sem írnám nyilvános fórumba :roll:

Azt már megfigyeltem hogy vannak olyanok akik "egyéb külső" körülményre hárítják a hibáikat... :)
Ilyenek pl.
[:5eaae699e4]
* nem aludtam 63454 órája
* be voltam rúgva
* nem is én voltam hanem a kisöcsém
* stb...
[/:u:5eaae699e4]
Nem lenne egyszerűbb elfogadni a kritikát? :)

[/]

[quote:c8aaf3e8a7="csillagocska"]Nos andrej_ oké ez gond, de én nem erre értettem, és leírtam olyan nincs hogy újabb bugokat ne találnának vagy réseket amiket esetleg ki lehet használni, mindenre nem tudsz odafigyelni, de attól még hogy mindet elzársz a userektől mert az biztonságos, nem biztos hogy az a célravezető, itt erre értettem. És nem napi 24 órában gondoltam, az lehetetlen. Ebbe lehet nem gondoltam bele annyira, akkor elnézést.

Pedig bele kell gondolni, no offense. Az újabb bugok ellen pedig nem tudsz vagy esetleg csak minták alapján lehet védekezni. A juzernek pedig miért kell olyanhoz hozzáférnie, amihez nincs joga/köze vagy nem szükséges neki?

Koncepció: Tegyük fel hozzáfér sokmindenhez, ami jó dolog meg kényelmes.

Jön egy hiba valamiben (amivel root szerezhető), amihez hozzáférhet, de sosem használja és nem is kell neki. Ha valahogy bejutnak a gépre (mondjuk publikus szolgáltatásban shell szerezhető) és rögtön ezt keresik akkor azonnal szeeeevuuuusz (hogy idézzek egy klasszikust) van. Mindezt egy olyan hiba miatt, amit _csak_ azért használhattak ki, mert az amúgy érdektelen (juzernek) dologhoz hozzáfértek.

Ez a két hiba egyébként annyira klasszikus, hogy nagyon.

[quote:413143eba4="andrej_"][quote:413143eba4="csillagocska"]Nos andrej_ oké ez gond, de én nem erre értettem, és leírtam olyan nincs hogy újabb bugokat ne találnának vagy réseket amiket esetleg ki lehet használni, mindenre nem tudsz odafigyelni, de attól még hogy mindet elzársz a userektől mert az biztonságos, nem biztos hogy az a célravezető, itt erre értettem. És nem napi 24 órában gondoltam, az lehetetlen. Ebbe lehet nem gondoltam bele annyira, akkor elnézést.

Pedig bele kell gondolni, no offense. Az újabb bugok ellen pedig nem tudsz vagy esetleg csak minták alapján lehet védekezni. A juzernek pedig miért kell olyanhoz hozzáférnie, amihez nincs joga/köze vagy nem szükséges neki?

Koncepció: Tegyük fel hozzáfér sokmindenhez, ami jó dolog meg kényelmes.

Jön egy hiba valamiben (amivel root szerezhető), amihez hozzáférhet, de sosem használja és nem is kell neki. Ha valahogy bejutnak a gépre (mondjuk publikus szolgáltatásban shell szerezhető) és rögtön ezt keresik akkor azonnal szeeeevuuuusz (hogy idézzek egy klasszikust) van. Mindezt egy olyan hiba miatt, amit _csak_ azért használhattak ki, mert az amúgy érdektelen (juzernek) dologhoz hozzáfértek.

Ez a két hiba egyébként annyira klasszikus, hogy nagyon.

Végülis totál igazad van, korlátozni kell a júzereket amennyire lehetséges és az adott szituáció megköveteli. Fokozni a biztonságot ameddig nem megy a használhatóság rovására (ahogy már kifejtették figyelembe véve a szerver funkcióit is). Kb ez lenne a biztonságos védekezés egyik mérföldköve egy publikus de nem létfontosságú szerveren?

[quote:af974e938b="hunger"][quote:af974e938b="csillagocska"]Sziasztok!

Én mint kezdő linuxos úgy gondolom, hogy aki shellt kap abban vagy bízik az ember vagy nem. Olyan azért nincs hogy senkiben sem, mert feltételezem aki be tud ssh znia serverre abban megbízik az ember, míg az ellenkezője be nem bizonyosodik. :x

Kár hogy hasonlatokat nem hoztál. Pl.: csak azzal fexel le gumi nélkül akiben megbízol és hasonlók. :P

[quote:af974e938b="csillagocska"]Nálunk a serveren a root jelszó jól ki van találva ezt próbálták megtörni nem tudták

Nemsemmi... gondolom iszonyat brainstorming lehetett jól kitalálni egy root jelszót. :lol:

[quote:af974e938b="csillagocska"]A rendszergazda feladata az hogy kiszűrje az ilyen tevékenységeket, mert ha nem lennének ilyenek valószínű rendszergazdára sem nagyon lenne szükség. :roll:

És akkor aztán már végképp a villanyszerelő nagypapa és a hűtőgépszerelő józsi tervezné és telepítené a rendszert a bankoknál is.

[quote:af974e938b="csillagocska"]A védelmet persze erősíteni kell.

Hú, hát a szívemből beszélsz! :D

Banki telepítést nem válalok csakk a klimát esetleg a spájz hűtését meg a szerverterem hűtését.

Most találtam véletlenül:
http://magenta.linuxforum.hu/index.php?q=node/778/1818#comment-1818

[quote:6ea942031b="andrej_"][quote:6ea942031b="csillagocska"]Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

A rendszergazda szerinted hogy tudja "figyelni a rendszert"? Ezt fejtsed ki légyszives, különös tekintettel arra, hogy napi 24 órában állandóan és _bármilyen_ megtörési kisérletet azonnal észrevegyen. Mondjuk amíg megebédelsz bedarálják a gépet egy rossz beállítás miatt (amiről csak később derül ki, hogy rossz persze). Ilyenkor mivan? Nem szűrted ki, mert lame vagy? Publikus webszerveren ennél is jobb a helyzet, mert a juzerek mindent szeretnének, ami azzal jár, hogy a phpBB és pl. mambo exploitok is lefuthatnak. Legszebb, hogy nem is biztos, hogy észreveszed a néhány száz processben azt aki épp lappang.

A rossz shellbe írt "su -" -t pedig már szerintem sokan elkövettük és még mindíg élünk.

Hűtéstechnikában van hállózati monitoros munkatárs. Na ebből van általában 6 személy aki csak a hállózati hűtőket sasolja az internetten. Egyszere 40-50 hállózatot. Ja , hogy ö nem a helyi rendszergazda hanem a táv felűgyelő csoport. :)

[quote:44959a6024="_Polesz_"][quote:44959a6024="andrej_"][quote:44959a6024="csillagocska"]Nos andrej_ oké ez gond, de én nem erre értettem, és leírtam olyan nincs hogy újabb bugokat ne találnának vagy réseket amiket esetleg ki lehet használni, mindenre nem tudsz odafigyelni, de attól még hogy mindet elzársz a userektől mert az biztonságos, nem biztos hogy az a célravezető, itt erre értettem. És nem napi 24 órában gondoltam, az lehetetlen. Ebbe lehet nem gondoltam bele annyira, akkor elnézést.

Pedig bele kell gondolni, no offense. Az újabb bugok ellen pedig nem tudsz vagy esetleg csak minták alapján lehet védekezni. A juzernek pedig miért kell olyanhoz hozzáférnie, amihez nincs joga/köze vagy nem szükséges neki?

Koncepció: Tegyük fel hozzáfér sokmindenhez, ami jó dolog meg kényelmes.

Jön egy hiba valamiben (amivel root szerezhető), amihez hozzáférhet, de sosem használja és nem is kell neki. Ha valahogy bejutnak a gépre (mondjuk publikus szolgáltatásban shell szerezhető) és rögtön ezt keresik akkor azonnal szeeeevuuuusz (hogy idézzek egy klasszikust) van. Mindezt egy olyan hiba miatt, amit _csak_ azért használhattak ki, mert az amúgy érdektelen (juzernek) dologhoz hozzáfértek.

Ez a két hiba egyébként annyira klasszikus, hogy nagyon.

Végülis totál igazad van, korlátozni kell a júzereket amennyire lehetséges és az adott szituáció megköveteli. Fokozni a biztonságot ameddig nem megy a használhatóság rovására (ahogy már kifejtették figyelembe véve a szerver funkcióit is). Kb ez lenne a biztonságos védekezés egyik mérföldköve egy publikus de nem létfontosságú szerveren?

Alapvetően bármilyen gépen fontos. Példa: a libjpg-ben vagy miben felfedezett puffertulcsordulás. Aki windowson "rootkent" valahogy egy ilyen kepet megnezett ott simán elég nagy bajok lehettek. Ugyanezt ha normálisan csak sima juzerként (bármilyen megfelelő OS-en) tette valaki, akkor max. a saját cuccait érhette kár. Ez utóbbi persze szintén nem jó, de még mindíg jobb, mintha a teljes rendszer kompromitálható így.

Azt ugye nem kell mondani, hogy mennyire nagy divatja van az x-ezer gépes zombihálózatoknak?

Azt hittem itt lehet tanulni de ebben a formában nem kérek belőle. :) Lehet a másikat totálisan lenullázni, mert nincs tisztában dolgokkal, de nem fogom kitenni magam megjegyzéseknek csak azért mert, megpróbálok a magam szintjén írni mégha az nem is mindig korrekt és pontos, de lehet csak nem tudom pontosan megfogalmazni amit szeretnék.

Tényleg leht itt tanulni. Hűtőgépészként itt tanultam meg beállitani a saját informatikai rndszeremet. Illetve még a linuxforum segitségével. (Nem egy webb szervere kel gondolni , hanem az othoni íroda és játékra hsznált gépre.)

Igen vannak akiktől lehet kérdezni de vannak akik másokat totálisan lenéznek. És miért kell nekem midne egyes lenéző megjegyzést elnéznem csupán csak azért mert próbálok a magam tudása szerint hozzászólnia témához? ebből is tanultam, jobb ha inkább le sem írom csak olvasok, de kérdezni nem fogok.

Ilyenek pl.

* nem aludtam 63454 órája
* be voltam rúgva
* nem is én voltam hanem a kisöcsém
* PP vagyok
* stb...

;)

[quote:68630aad92="csillagocska"]ebből is tanultam, jobb ha inkább le sem írom csak olvasok, de kérdezni nem fogok.

bahh...
ez itt a valo vilag:P

[quote:c3216c2293="muszashi"]Na, hogy kicsit komolyabb irányba visszatereljük a szót, nálam például E-mailek jönnek a szerverektől. Nem sok, ert azt nem olvasnám, de ami biztosan jön minden nap:

* napi mentésről egy eredmény, alap esetben egy idő+dátum+ellenörző összeg OK, ha nem így lenne, akkor részletes napló. (ez tuóbbi fájlba mindig elkészül) Ez hajnali 1-2 felé jön, leghamarabb reggel nézem. ..hacsak nem szuttyogok az éjjszaka.

* rendszer integritás állapotáról naponta 6:25-kor. (Ez az összes fontos fájl változását figyeli és küldi az eredményt. Mely fájlok, mikor módosultak. .persze nem /var/log meg /home :)

Áramszünet esetén jön a mail, ha visszajött az áram, akkor is.

Ennyi jön. Ezen kívül minden nap 1X be SSH-zok a szerverekre, szúrópróbaszerűen megnézek 1-2 naplót, nézek egy apt-get update -t, ilyesmit. Tehát kicsit élvezem az üzemeltetést. Ennél többször csak akkor lépek be, ha kell valamit csinálni, vagy nem jön meg valamelyik usernek mail és meg kell nézni a naplóban, hogy miért. (utána meg
telefonálnom kell, hogy mit állítson be a küldő a szerverén, vagy a DNS-én :)

Üdv: M.

- Muszashi engem erdekelnenek ezek a szkriptek, mind a harom, eltudnad kuldeni? Privatba is johet, koszonom.

ltn

[quote:1680a44616="csillagocska"]Igen vannak akiktől lehet kérdezni de vannak akik másokat totálisan lenéznek. És miért kell nekem midne egyes lenéző megjegyzést elnéznem csupán csak azért mert próbálok a magam tudása szerint hozzászólnia témához? ebből is tanultam, jobb ha inkább le sem írom csak olvasok, de kérdezni nem fogok.

Általában a rejtet kisebségikomlexusal rendelkezők szokták erősíteni leszolásal a picike kis egójukat.
Na ezért szoktam röhögni rajtuk.

Meditor ez a hozzászolás nagyon tetszet.

És végül: nem abszolút jót kell csinálni, hanem a gyenge átlagnál jobbat. Hogy legyen nálad könnyebb préda. Erről egy vicc: Megy a néger, meg a fehér a sivatagban. Jön az oroszlán. Leveszi a néger a hátizsákját és kivesz egy szöges cipőt. Aszondja a fehér: Mivan? Te gyorsabban akarsz futni az oroszlánnál? Mire a néger: Nem, én nálad akarok gyorsabban futni.

Ha valaki be akar jutni egy ilyen rendszerbe (pl személyes okból), akkor be is jut. A x az szivatni akarja az y-t, akkor mindegy, hogy a z-nek milyen rendszere van...
Script kiddiek ellen persze véd az "átlagosnál jobb" rendszer.
szvsz.

[quote:c80e34dda3="meditor"]Erről egy vicc: Megy a néger, meg a
fehér a sivatagban. Jön az oroszlán.

Ezt nem a SONY vezére mondta?

[quote:834494d1c6="gsimon"]A /tmp-t is noexec-re

agyon is vagtal minden progit, aki shell script-et akar futtatni (pl.: mc)

Zsiraf

p.s.: legyszi ne gyere a vim-mel, az mc csak egy pl.

[quote:9dc25ecee3="_Polesz_"]
Először is bocs, a kirohanásomért, de valahogy morcos voltam tegnap és mivel inkább fikáztál (főleg drastik kolléga) ezért írtam amit írtam... Na mindegy fátylat rá, ha lehet.

semmibaj
:)

[quote:b837a378ec="andrej_"]
Gondolom Kínából, Észak-Kórából és a Fidzsi szigetekről is be kell tudnod lépni. Azt vegyük már észre, hogy néhány hazai szolgáltató tartományára néhány /16-os ACCEPT vagy pass in rule-al talán még lehet élni és őrülten nagy karbantartást sem igényel. Ha olyan gép ami bármilyen okból publikus shellt ad, akkor tessék megoldani hogy chrootban legyen valami jailszerű (FreeBSD-vel pl. egészen kellemesen megoldható és még login classok meg MAC framework is van by default). Egyéb esetben, pedig a legkevesebb szükségesnél nem kell több shelljuzert kiadni.

Ezek a portknocking és más hasonló álmegoldások szerintem csak simán növelik a biztonsági kockázatot, amit pedig csökkenteni kéne. Ez a küldök egy SMS-t dolog is eléggé meredeken hangzik. Egyáltalán miért kell "bárhonnan" elérni egy gépet és ha ennyire fontos a biztonság, akkor miért nincs egy kevéssé publikus adminszerver, ahonnan lehet nyomulni?

Termeszetesen az egesz internet szukitheto egy vagy nehany cimtartomanyra. Csak azt nem ertem, hogy a portknocking hogyan noveli a biztonsagi kockazatot? Masreszt, ha van egy gateway szerverem ami sms-ben jelzi a fo szerverek mentesenek lefutasat, akkor visszafele miert nem mukodhet a dolog?

Udv Zoli

[quote:bb9b85c197="szaszg"][quote:bb9b85c197="gsimon"]A /tmp-t is noexec-re

agyon is vagtal minden progit, aki shell script-et akar futtatni (pl.: mc)

Ezt nem értem. Igaz, hogy próbaképp csak egy file-on lévő ext2-t mountoltam rá loop device-szal (mount -o loop,noexec tmp.img /tmp)
[code:1:bb9b85c197]
/dev/loop/1 on /tmp type ext2 (rw,noexec)
[/code:1:bb9b85c197]
de shell és perl scriptek működtek simán és midnight-ból is, a cgi-bin-ből az apache is tudott futtatni mindent. Egyrészt ez a noexec csak binárisokra áll, mert a scriptet az értelmezője egyszerűen olvasásra nyitja, másrészt meg nem a tmp-ből futtattam volna őket, hanem pl. a home-omból.

huh, jó ez a topic. megint könnyesre röhögtem magam...

[quote:e82f5b947e="8192Joco"][quote:e82f5b947e="csillagocska"]Igen vannak akiktől lehet kérdezni de vannak akik másokat totálisan lenéznek. És miért kell nekem midne egyes lenéző megjegyzést elnéznem csupán csak azért mert próbálok a magam tudása szerint hozzászólnia témához? ebből is tanultam, jobb ha inkább le sem írom csak olvasok, de kérdezni nem fogok.

Általában a rejtet kisebségikomlexusal rendelkezők szokták erősíteni leszolásal a picike kis egójukat.
Na ezért szoktam röhögni rajtuk.

Azokrol az adatbazis/szoftver/hardver rendszergazdakrol most ne beszeljunk akik a munkahelyuk vedelme erdekeben nem irnak dokumentaciot az altaluk karbantartott rendszerrol, igy akarjak azt elhitetni az oriasi egojukkal, hogy oket nem merik kirugni a cegtol. Masreszt pont emiatt kell hozzaferest biztositani kivulrol az adatbazisos kolleganak, mert mast nem enged kozel az sql tablaihoz es a lekerdezeseihez.

Udv Zoli

[quote:bdbdd6de57="hunger"]huh, jó ez a topic. megint könnyesre röhögtem magam...

?????????

[quote:c4b312b490="colos"][quote:c4b312b490="8192Joco"][quote:c4b312b490="csillagocska"]Igen vannak akiktől lehet kérdezni de vannak akik másokat totálisan lenéznek. És miért kell nekem midne egyes lenéző megjegyzést elnéznem csupán csak azért mert próbálok a magam tudása szerint hozzászólnia témához? ebből is tanultam, jobb ha inkább le sem írom csak olvasok, de kérdezni nem fogok.

Általában a rejtet kisebségikomlexusal rendelkezők szokták erősíteni leszolásal a picike kis egójukat.
Na ezért szoktam röhögni rajtuk.

Azokrol az adatbazis/szoftver/hardver rendszergazdakrol most ne beszeljunk akik a munkahelyuk vedelme erdekeben nem irnak dokumentaciot az altaluk karbantartott rendszerrol, igy akarjak azt elhitetni az oriasi egojukkal, hogy oket nem merik kirugni a cegtol. Masreszt pont emiatt kell hozzaferest biztositani kivulrol az adatbazisos kolleganak, mert mast nem enged kozel az sql tablaihoz es a lekerdezeseihez.

Udv Zoli

Egy rendes helyen és főleg ahol sok gép van admin szerver, ahova és csak oda lehet kivülről belépni és onnan tovább. Szintén léteznek mindenféle VPN-es megoldások ha az kell. Node ezt Mr. Trey már írta itten.

colos, sms: szerintem egesz mas dolog egy allapotjelentes es egeszen mas egy parancskiadas a szervernek

Csak azt nem ertem, hogy a portknocking hogyan noveli a biztonsagi kockazatot?

Ezt en sem. Szerintem kimondottan csokkenti, mivel egy lepessel bonyolultabba teszi a rendszered feltoreset, ergo egy csomo mas szerver valik nalad konnyebb predava.

En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

muszashi: én is szívesen látnám a scripteket... okulni és ötleteket gyűjteni mindenképp jó

[quote:fa5ef2cfa4="1aca"]En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

:lol: we are proud to announce: hup-dick-measuring-contest 2006...

Szerintem amúgy az sms-es parancsküldés nem nagy kockázat: A "gonosznak" ki kell találni a titkos telefon számot, amelyik a szerveremhez tartozik és még a speciális sms szintakszisát is.

[quote:a396d41fdd="tomyellow"][quote:a396d41fdd="meditor"]Az nmap is egy port-scan. Ezt is lehetne detektálni, szerintem. Nem üzemszerű, ha valaki másodpercenként tucatszor portot vált.

Nézd meg a portsentry-t! http://linux.cudeso.be/linuxdoc/portsentry.php

Üdv.: Tomyellow

remek kis eszkoz igazan
foleg hogy bugos es ezzel is meglehet tolni a geped

[quote:46c58230e0="1aca"]En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

Mindenkeppen az aki a topik hatasara uj modszereket/eljarasokat ismer meg es megtanulja azokat alkalmazni, igy nem tornek be hozza :wink:

[quote:46c58230e0="andrej_"] colos, sms: szerintem egesz mas dolog egy allapotjelentes es egeszen mas egy parancskiadas a szervernek

Nem olyan jellegu parancsra gondolok mint pl: dd if=/dev/zero of=/dev/hda, hanem egy nyilt kulcsra es egy parancskodra ami altal a fogado script nyit a tuzfalon egy portot amin keresztul mar be lehet sshra lepni

Udv Zoli

[quote:22a5a990d9="hunger"]huh, jó ez a topic. megint könnyesre röhögtem magam...

a sracok nagy szekuriti expertek

topicnyitonak:

btw.

1. miert a 22 es porton fut az sshd
2. miertnem jailben futnak a szolgaltatasok(vagy uml)
3. miert lehet sshzni barhonnan a gepre
4. ha mar linux akkor miertnem pax
5. miert passwd es miertnem kulcs
6. hogyhogy az osszes user su-zhat rootra

ez aki megtorte a gepedet egy luzer
egy profit eszre sem vennel

[quote:ed559e14cd="coder"]muszashi: én is szívesen látnám a scripteket... okulni és ötleteket gyűjteni mindenképp jó

Az hogy mi változott a fájlrendszeren:
apt-get install integrit

Sarge alatt. Egész hasznos.

[quote:5617df3b32="lacika"][quote:5617df3b32="coder"]muszashi: én is szívesen látnám a scripteket... okulni és ötleteket gyűjteni mindenképp jó

Az hogy mi változott a fájlrendszeren:
apt-get install integrit

Sarge alatt. Egész hasznos.

...vagy tripwire...

[quote:497b80f3ff="bitumen"][quote:497b80f3ff="lacika"][quote:497b80f3ff="coder"]muszashi: én is szívesen látnám a scripteket... okulni és ötleteket gyűjteni mindenképp jó

Az hogy mi változott a fájlrendszeren:
apt-get install integrit

Sarge alatt. Egész hasznos.

...vagy tripwire...

Igen, ez sem rossz, csak én az integrit -et ismertem meg elsőnek és bejött, de az általad írt is nagyon jó.

Semmi extrák, ahogy fent már írták a kollégák:

*integrit (a fájlok figyelésére, csak be kell konfigolni, azt csinálja a dolgát)

* apcupsd (a szünetmentes figyelésére, csak be kell konfigolni, azt csinálja a dolgát)

* egyedül a mentésre írtam scriptet, de az se egy nagy csattanás, mivel kb 3,6 Gb adat van, csak napközben használják (8-22) így minden nap teljes mentés megy DVD +RW-re hajnalban, amikor nem kell a gép.

Annyival egyszerüsítettem csak az életem, hogy a /home alatt van a profiles könyvtár is, az összes samba megosztás, meg a Maildir könyvtárak, így a /home mentésével minden mentve van. (Persze a sambába be kellett állítani, hogy az user home-ja alatt ne jelenjen meg a Maildir könyvtár, különben az user még letörölné:)

[code:1:feba070eb0]
muszashi@mail:/etc/init.d$ cat mentes
#!/bin/bash

export naplo=/var/log/archivalas.log

echo " ">>$naplo
echo "------------------------KEZDETE ">>$naplo
echo " ">>$naplo
echo "Archiválási procedúra kezdete: $(date) ">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo "****** LÉPÉS 0: Babér mentésének becsatolása a helyi fájlrendszerbe és másolása... ">>$naplo
mount -t smbfs -o username=****,password=**** //berszerver/automentes /home/baber/felcsatolt >>$naplo 2>&1
cp /home/baber/felcsatolt/* /home/baber >>$naplo 2>&1
umount /home/baber/felcsatolt >>$naplo 2>&1
echo " ">>$naplo
echo "***** LÉPÉS 1: Helyi fájlszerver leállítása... ">>$naplo
echo " ">>$naplo
/etc/init.d/samba stop >>$naplo 2>&1
echo " ">>$naplo
echo "***** LÉPÉS 2: MySQL dumpolása és a tömörített állomány létrehozása kezdődik...: ">>$naplo
echo " ">>$naplo

mysqldump -u **** --password=**** egroupware >/home/egroupware.sql 2>>$naplo
cd /mentesek 2>>$naplo
export aktualis=$(date +%F"-"%X) 2>>$naplo
tar -czf $aktualis.tar.gz /home >>$naplo 2>&1

echo " ">>$naplo
echo "A tömörítés véget ért: $(date)">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo "A mentések könyvtár jelenlegi tartalma: ">>$naplo
echo " ">>$naplo
ls -1>>$naplo
echo " ">>$naplo
echo "Az akutális állomány az $aktualis.tar.gz">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo "***** LÉPÉS 3: Ellenörző összeg készítése... ">>$naplo
echo " ">>$naplo

md5sum $aktualis.tar.gz>$aktualis.tar.gz.sum 2>>$naplo

echo " ">>$naplo
echo "***** LÉPÉS 4: Az állomány DVD-re írása kezdődik: $(date)">>$naplo
echo " ">>$naplo

growisofs -Z /dev/hdd -R -J $aktualis.tar.gz >>$naplo 2>&1 < /dev/tty5

echo " ">>$naplo
echo "A DVD-re írás véget ért: $(date)">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo " ">>$naplo

mount /media/cdrom1 2>>$naplo
cd /media/cdrom1 2>>$naplo

echo "A DVD jelenlegi tartalma: ">>$naplo
echo " ">>$naplo
ls -1>>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo "**** LÉPÉS 5: Ellenörző összeg lefuttatása és az EREDMÉNYE: ">>$naplo
echo " ">>$naplo
md5sum -cv /mentesek/$aktualis.tar.gz.sum >/var/log/eredmeny 2>&1
cat /var/log/eredmeny >>$naplo 2>&1
cimzettneve="root@ceg.hu"
mail -s CEG_mentesi_ertesito $cimzettneve </var/log/eredmeny
rm /var/log/eredmeny
echo " ">>$naplo
echo " ">>$naplo
echo " ">>$naplo
echo "***** LÉPÉS 6: Babér átmeneti állományok törlése a Helyi fájlrendszerből... ">>$naplo
rm /home/baber/* >>$naplo 2>&1
echo " ">>$naplo
echo "***** LÉPÉS 7: Helyi fájlszerver elindítása... ">>$naplo
echo " ">>$naplo
/etc/init.d/samba start >>$naplo 2>&1
echo " ">>$naplo
echo " ">>$naplo
echo "Az archiválási procedúra véget ért! $(date)">>$naplo
echo " ">>$naplo
echo " ">>$naplo

cd / 2>>$naplo
umount /media/cdrom1 2>>$naplo
eject /dev/hdd 2>>$naplo

echo "------------------------VÉGE ">>$naplo

[/code:1:feba070eb0]

Aztán vasárnap lefut egy script ami törli a /mentesek partíció tartalmát. (ez egy külön disk) A lemezt minden reggel kiveszi a titkárnő, berakja a pakk tetejére és berak a gépbe egy másikat. 30 nap múlva a lemez újra sorrakerül.

Szóval nem kell nagy dolgokra gondolni, ahogy András barátommal szoktuk fogalmazni, ilyen botcsinálta rendszergazdák vagyunk. (Mondjuk van egy másik hely, ahol növekményes mentés van, xfs freez, meg pár extra, de végül is az már csak ennek a fűszerezése)

Üdv: M.

Nekem fenntartásaim vannak ezzel a scripttel kapcsolatban. Gyakorlatilag feltételezi, hogy "offline" történik a mentés, ráadásul 5-10 ezer felhasználó esetén aligha járható út: túl lassú.

[quote:f59ef0ca63="colos"]Nem olyan jellegu parancsra gondolok mint pl: dd if=/dev/zero of=/dev/hda, hanem egy nyilt kulcsra es egy parancskodra ami altal a fogado script nyit a tuzfalon egy portot amin keresztul mar be lehet sshra lepni

De ha a parancs csak akkor fut le, ha pl az smsben ^runme szöveg van, akkor miért ne lehetne dd-zni ill. miért lenne biztonsági rés? :roll:

Nem neztem pontosan vegig, de a tippem latatlanban:

- brute force ssh tamadassal felnyomtak a proba usert (gondolom proba volt a jelszo :-)
- mivel a rendszer regi local root exploittal felnyomtak (tipp: root.tar.gz)
- jelszocserek
- irc szerver / bot / stb. letolt konfigural (bewareircd-linux.tar.gz)
- tovabbi potencialis ssh aldozatok kereses (ssh-scan, TurboB)
- stb.

szokasos eljaras

Javaslat: a rendszer ujratelepitese utan SSH-t csak publikus kulccsal es csak ismert IP cimekrol engedjunk. Ez egy kicsi, de fontos lepes a biztonsag fele.

[quote:7690348011="drastik"][quote:7690348011="hunger"]huh, jó ez a topic. megint könnyesre röhögtem magam...

a sracok nagy szekuriti expertek

topicnyitonak:

btw.

1. miert a 22 es porton fut az sshd
2. miertnem jailben futnak a szolgaltatasok(vagy uml)
3. miert lehet sshzni barhonnan a gepre
4. ha mar linux akkor miertnem pax
5. miert passwd es miertnem kulcs
6. hogyhogy az osszes user su-zhat rootra

ez aki megtorte a gepedet egy luzer
egy profit eszre sem vennel

Szerintem ezeket nagyjából végig beszéltük és a fentiek elhangzottak, vagy tévedek?
(amellett, hogy a 3-ast továbbra sem tartom elfogadható megoldásnak a számomra, mivel bárhonnan bármikor be kellhet lépnem tehát knoppix CD és privát kulcs hordozása áll fenn, a többi OK.)

[quote:7e93a6e356="drastik"][quote:7e93a6e356="hunger"]huh, jó ez a topic. megint könnyesre röhögtem magam...

a sracok nagy szekuriti expertek

topicnyitonak:

btw.

1. miert a 22 es porton fut az sshd
2. miertnem jailben futnak a szolgaltatasok(vagy uml)
3. miert lehet sshzni barhonnan a gepre
4. ha mar linux akkor miertnem pax
5. miert passwd es miertnem kulcs
6. hogyhogy az osszes user su-zhat rootra

ez aki megtorte a gepedet egy luzer
egy profit eszre sem vennel

egy dolog felsorolni a megoldasokat, mas dolog telepiteni es karbantartani a dolgokat. aki nem csinalt meg ilyet az sem tudja, hogyan tesztelje le, hogy egyaltalan megfeleloen muxik. azert kell sshzni mert dolgozni kell az embernek, nem pedig szorakozasbol sztem.

udv zoli

lehet, hogy láma vagyok, vagyis tudom, h. az vagyok, de egy proba nevű user szárnyait eléggé szokás visszanyírni, hogy "röpképtelen" legyen

Ha már a bárhonnan SSH-ról van szó. Nem tudja valaki a magyarországi szolgáltatók ip címtartományát?

Szerintem nem szabad semmi felesleges portot nyitva hagyni, minden irányba.

Alapnak kell lennie, hogy az ssh kizárólag pár ipről van beengedve, például, csak arról a 3-ról, ahonnan be fog lépni a szerver üzemben tartója, nem pedig az egész világ számára.

A kulcsos azonosítás is sokat segíthet, ha már így adminisztrálja az ember.

[quote:216a89f537="csiga"]Szerintem nem szabad semmi felesleges portot nyitva hagyni, minden irányba.

Alapnak kell lennie, hogy az ssh kizárólag pár ipről van beengedve, például, csak arról a 3-ról, ahonnan be fog lépni a szerver üzemben tartója, nem pedig az egész világ számára.

A kulcsos azonosítás is sokat segíthet, ha már így adminisztrálja az ember.

És mi van abban az esetben, ha több felhasználód van és megbízol bennük és mégis nekiállnak a szerveren "játszani".

Hogy lehetne pl ssh-scan meg egyéb programok futtatását tiltani?

A proba user accountjan keresztul egy local root exploittal root jogokat elehet szerezni. Hiaba nyirod vissza a szarnyait a user-nek, ha maga a kernel sebezheto. Ilyenkor jol johet meg a Grsec + PaX meg minden olyan patch ami a stack es heap manipulalas ellen ved vagy csokkenti a puffer tulcsordulas es az egyeb mas tamadasok (ret-to-libc) eselyeit. Persze az a legfontosabb, hogy a tamado ne jusson be sehogy...

[quote:237204686e="lzrd"]lehet, hogy láma vagyok, vagyis tudom, h. az vagyok, de egy proba nevű user szárnyait eléggé szokás visszanyírni, hogy "röpképtelen" legyen

[quote:25d98d5419="samuf"]Ha már a bárhonnan SSH-ról van szó. Nem tudja valaki a magyarországi szolgáltatók ip címtartományát?

ilyesmire gondolsz: GEO IP ?

[quote:1234d68c6b="dirobi"]
Ha jól látom ezek itt ötletek. Fikázni mindenki tudd. Ha tudsz olyan megoldást, ami "megtörhetetlen", akkor mond, de olyat amitől a rendszer használható marad és nem egy lebetonozott pincében ücsörög a Rendzergazda, minden hálózattól elzárcva.

rosszul latod ezek itt baromsagok
de nyugodtan hasznald azokat

[quote:df7f7e1c6c="_Polesz_"][quote:df7f7e1c6c="csiga"]Szerintem nem szabad semmi felesleges portot nyitva hagyni, minden irányba.

Alapnak kell lennie, hogy az ssh kizárólag pár ipről van beengedve, például, csak arról a 3-ról, ahonnan be fog lépni a szerver üzemben tartója, nem pedig az egész világ számára.

A kulcsos azonosítás is sokat segíthet, ha már így adminisztrálja az ember.

És mi van abban az esetben, ha több felhasználód van és megbízol bennük és mégis nekiállnak a szerveren "játszani".

Hogy lehetne pl ssh-scan meg egyéb programok futtatását tiltani?

Szerintem iszonyatos hiba bárkiben is megbízni, hogy ott rohangáljon egy gépen.
Legyen annyi adminisztrátora amennyi minimum szükséges, az is kollega legyen, akit számon lehet kérni és az is csak megadott ipről csatlakozzon.

Ez nem játék.

A másik ami eszembe jutott, ami általános hiba szokot lenni, hogy az a gyakorlat, hogy az ipfilter szabályokat úgy állítjákbe, hogy be nem jöhet semmi aztán kivételt tesznek, kifelé meg mehet bármi.

Ezzel sem értek egyet.

Szerintem befele ne jöjjön, semmi és kifelese menjen semmi aztán a kivételek.
DNS mehet ki, http vagy ftp ha kell az updatéhez az is csak a proxy felé.
Persze előfordulhat, hogy ezt nem lehet megvalósítani, mondjuk egy squid vagy valami hasolsó miat, de akkor is minimumra kell szorítani a kifelé komunnikáló lehetőségeket.

Nem azt mondom, hogy ez a kifelé semmi megvédte volna meditor-t mert mert ugye itt nem ezzel volt a probléma, de nagyban csökkenti a támadások jó részének a sikerét.

Példásul több webszerver is járt úgy, hogy valami gagyi php- portált kihasználva feltöltötek egy-egy cuccot, ami ha kifelé tudott volna beszálni, akkor igen nagy gáz lett volna.

Meg még az jutott eszembe, hogy a grsecurity access listjeivel megmondhatod, hogy melyik program futhat le melyik nem.

[quote:a6051ab649="Panther"]Nekem fenntartásaim vannak ezzel a scripttel kapcsolatban. Gyakorlatilag feltételezi, hogy "offline" történik a mentés, ráadásul 5-10 ezer felhasználó esetén aligha járható út: túl lassú.

Ez nem is arra való. 20 felhasználó van, aki 01-kor már tutira nem dolgozik.
De egy hasonló van 100 felhasználós rendszeren is. Van egy xfs freez -es LVM snapshot-os egy ezeknél kicsit nagyobb helyen is.
Azt gondolom, hogy az adott igényekhez szükséges lehető legegyszerűbb megoldásokat kell alkalmazni. Ez a példaként írt helyeken (kivéve, ahol az LVM-el játszom elégséges megoldás), természetesen ha mások lennének a követelmények más megoldást alkalmaznék.

Ez az ssh brute force. Altalaban szotarbol probalkoznak. A vedelemre mar feljebb mondtam valamit. Csak bizonyos IP-rol engedsz a 22-es portra csatlakozni. Ha igazan jot akarsz, akkor a jelszavas authot is letiltod, es publikus kulcsos auth-ot hasznalsz.

[quote:19306fe223="meditor"]Én azt látom, hogy a betörési próbálkozások többnyire az ssh 22-es portja
ellen mennek és szisztematikusan néhány tized másodpercenként
egy új felhasználónévvel, vagy egy új jelszóval próbálkoznak - rendszerint
ugyanarról at ipcímről. Szerintem többé-kevésbé ez az egyetlen egy
dolog, ami megkülönbözteti az üzemszerű állapottól, ezzel kéne
csinálni valamit!

[quote:4e3214de91="Oregon"]muszashi: kliensekrol nem mentesz?

Nem, hiszen a kliensen nincs semmi. Roaming profiles a szerveren van (/home/samba/profiles), a 6 db különböző jogokkal bírő közös mappa a szerveren van (/home/samba/megosztás1-6), a felhasználó saját könyvtára a szerveren van (/home/$user), a levelezés a IMAP, könyvtára az /home/$user/Maildir, tehát a kliensen nincs semmi, csak a csupasz rendszer.

Amit lehet mindig központosítok. (Lusta fajta vagyok.)

Üdv:M.

[quote:46f147a7fa="drastik"][quote:46f147a7fa="dirobi"]
Ha jól látom ezek itt ötletek. Fikázni mindenki tudd. Ha tudsz olyan megoldást, ami "megtörhetetlen", akkor mond, de olyat amitől a rendszer használható marad és nem egy lebetonozott pincében ücsörög a Rendzergazda, minden hálózattól elzárcva.

rosszul latod ezek itt baromsagok
de nyugodtan hasznald azokat

őszintén irigyellek, hogy Neked már ennyire megy Mester

Sokat nem ersz vele, mert van olyan script, amelyik nmap-pal kezd. :-) Ahol nyitott portot talal, oda probalkozik be.

[quote:8ab565fb6f="meditor"]Egyelőre átpakoltam a szolgáltatás portját. Figyelni fogom, hogy így mennyi a próbálkozás.

[quote:e149a7cb83="trey"]Ez az ssh brute force. Altalaban szotarbol probalkoznak. A vedelemre mar feljebb mondtam valamit. Csak bizonyos IP-rol engedsz a 22-es portra csatlakozni. Ha igazan jot akarsz, akkor a jelszavas authot is letiltod, es publikus kulcsos auth-ot hasznalsz.

[quote:e149a7cb83="meditor"]Én azt látom, hogy a betörési próbálkozások többnyire az ssh 22-es portja
ellen mennek és szisztematikusan néhány tized másodpercenként
egy új felhasználónévvel, vagy egy új jelszóval próbálkoznak - rendszerint
ugyanarról at ipcímről. Szerintem többé-kevésbé ez az egyetlen egy
dolog, ami megkülönbözteti az üzemszerű állapottól, ezzel kéne
csinálni valamit!

Hát igen ez jó lenne, de például nekem itthon dinamikus címem, van, szóval sajnos IP-re nem tudok korlátozni. (bár az IP végül is könnyen hamisítható)
Szóval ezért (na nem csak ezért, sok egyéb miatt) választottam én is a jelszavas auth tiltását, csak kulcsok használatát. (a kulcsom meg jelszóval védem, így ha az itthoni gépet nyomnák fel, lopnák el, stb, akkor sem tudnának belépni a szerverre, a jelszó pedig egy többszörösen összetett mondat)
A mezei userek számára ahol szükség van scp,sftp-re, ott nekik csak ez van, de csak chroot-ba (rssh-val), akinek meg shell kell, azok is csak chroot-ba érkeznek. (persze ők is csak kulccsal) A tűzfal tervezésem hasonló a kolléga által említetthez. INPUT,OUTPUT,FORWARD=DROP , aztán a kivételek. Az ssh szerver pedig nem a 22-es porton figyel, hanem 5xxxx porton.

Szóval egyetértünk.

Üdv:M.

[quote:30b3f4cc0b="csillagocska"]Egészségedre ha ittál, és remélem nagyon nem csúszott félre. 8) Én csupán azt írtam le amit tapasztaltam és a véleményem a témához. Te biztos jóval okosabb és ügyesebb vagy mint más. 8) Én nem szégyellek másoktól tanulni, és kérdezni.

johat szivesen beszelgetnek veled egy kv melett szekuritirol barmikor
:)

[quote:2547102c3f="1aca"]En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

en arra lennek kivancsi hogy a sok "deninyan leenugz a kiraly" wanabe rendszergazda mikor tanulja mar meg hogy a szekurity nem az apt-get update

[quote:0c193571d8="drastik"][quote:0c193571d8="1aca"]En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

en arra lennek kivancsi hogy a sok "deninyan leenugz a kiraly" wanabe rendszergazda mikor tanulja mar meg hogy a szekurity nem az apt-get update

Pedig ott kezdődik!

Biztos lehetne. De az nmap fel van szerelve gyarilag olyan technikakkal, ami lehetove teszi szamara, hogy nehezebben legyen felfedezheto. Van olyan modja, amikor a teljes kapcsolat fel sem epul (SYN scan), vagy ami meg jobb a NULL, FIN, XMAS scan. Mondjuk ezeket egy modern IDS rendszer detektalja, de egy csupasz egyszeru gep nem biztos.

[quote:5466e6a57e="meditor"]Az nmap is egy port-scan. Ezt is lehetne detektálni, szerintem. Nem üzemszerű, ha valaki másodpercenként tucatszor portot vált.

dyndns-es restrict, valaki kerdezte:
[code:1:2df5c84c4d]/etc/hosts.allow:
sshd: enhostom.no-ip.com[/code:1:2df5c84c4d]
ofcos libwrap support kell sshd-be jol.

[quote:b8cdbc39bb="trey"]Hiaba nyirod vissza a szarnyait a user-nek, ha maga a kernel sebezheto.

Esetleg egy TPE bekapcs segithet, mert gagyiuser ne tudjon mar sajat maga altal feltoltott filet futtatni.

azert kezdetnek ez se rossz, ha nem tudsz ip-cimre korlatozni
[code:1:41b9237966]iptables -A INPUT -i ! lo -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
iptables -A INPUT -i ! lo -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j DROP[/code:1:41b9237966]

Ja és az alapokat majdnem elfelejtettem, ilyenek például:

/usr /bin /sbin /etc -ro

/home /var/log -noexec

stb . stb ......

Szóval egy jó fstab fájl, már fél siker.

Üdv: M.

A /tmp-t is noexec-re, valamint ha ext2/3 van fenn, akkor ami readonly, arra még immutable flag is (chattr +i). Hátránya persze, hogy ezek után egy rendszerfrissítés eléggé nehézkesen megy...

[quote:6c721c4f2e="muszashi"]Ja és az alapokat majdnem elfelejtettem, ilyenek például:

/usr /bin /sbin /etc -ro

Hat ez sokat nem er, mert ha nem egybol root, akkor ugysem tud oda irogatni... Remelhetoleg ;) Ha pedig egybol root, akkor ugyis mindegy...
[quote:6c721c4f2e="muszashi"]
/home /var/log -noexec

Na ez igen... De a tmp is bekerulhetne...
[quote:6c721c4f2e="muszashi"]
Szóval egy jó fstab fájl, már fél siker.
Üdv: M.

Egyetertek :)

Egy szerver félrendszergazdája vagyok ahol kb 8 júzernek van ssh hozzáférése a szerverhez. Ezek ugye "nem megbízható" emberek a rendszergazdán kivül. Egy júzer volt olyan kedves és ssh-scan futtatot a /tmp/akarmi és /var/tmp/akarmi könyvtárakból. Mivel pont rendszerkarbantartást végeztem tűnt fel, hogy lassú a rendszer, és ekkor tudtam kiszűrni ezt a fajta tevékenységet. A júzer ssh hozzáférése ment a /bin/false-ra és a /tmp könyvtár tmpfs-ben noexec, nosuid jogokat kapott a /var/tmp szintén.

Van még mit tanulni biztonság terén :-(

A sok hasznos hozzaszolason kivul esetleg lehetne olyat is csinalni iptables-el, hogy egy adott iprol egy adott idointervallumon belul hanyszor csatlakozhat vki. Esetleg vmi szkript, ami sok probalkozas utan tempban-ra teszi az illetot, amit aztan egy bizonyos ido elteltevel leszedi...vagy otthagyja, es majd kezzel kell kiszedni a blacklist-bol.

Meditor, esetleg portkopogtatas?
itt 'http://www.hup.hu/modules.php?name=News&file=article&sid=9670' mar volt rola szo.

[quote:c27593f946="muszashi"]A mezei userek számára ahol szükség van scp,sftp-re, ott nekik csak ez van, de csak chroot-ba (rssh-val), akinek meg shell kell, azok is csak chroot-ba érkeznek.

Az rssh és az scponly között valami lényeges különbség van? Ahogy nézegettem az rssh oldalát, mindkettő ugyanarra a dologra hivatott.

[quote:2f4b7a84fa="gsimon"][quote:2f4b7a84fa="szaszg"][quote:2f4b7a84fa="gsimon"]A /tmp-t is noexec-re

agyon is vagtal minden progit, aki shell script-et akar futtatni (pl.: mc)

Ezt nem értem. Igaz, hogy próbaképp csak egy file-on lévő ext2-t mountoltam rá loop device-szal (mount -o loop,noexec tmp.img /tmp)
[code:1:2f4b7a84fa]
/dev/loop/1 on /tmp type ext2 (rw,noexec)
[/code:1:2f4b7a84fa]
de shell és perl scriptek működtek simán és midnight-ból is, a cgi-bin-ből az apache is tudott futtatni mindent. Egyrészt ez a noexec csak binárisokra áll, mert a scriptet az értelmezője egyszerűen olvasásra nyitja, másrészt meg nem a tmp-ből futtattam volna őket, hanem pl. a home-omból.

Jovaan naaa, en is lehettem magamon kivul egyszer... mit kell ugy felhanytorgatni... :-)

Zsiraf

Te sose voltal meg ugy besszivva, hogy hulyesegeket irtal????

[quote:cac0f4ce28="drastik"][quote:cac0f4ce28="1aca"]En csak arra vagyok kivancsi, hogy ki nyer ebben a "dick-measuring-contest"-ben, avagy ki lesz a hup legfobb onkinevezesu biztonsagi szakertoje... get a life! (akinek nem inge, ne vegye magara)

en arra lennek kivancsi hogy a sok "deninyan leenugz a kiraly" wanabe rendszergazda mikor tanulja mar meg hogy a szekurity nem az apt-get update

Igy van, korrekt.

[quote:3160891fff="muszashi"][quote:3160891fff="drastik"]
en arra lennek kivancsi hogy a sok "deninyan leenugz a kiraly" wanabe rendszergazda mikor tanulja mar meg hogy a szekurity nem az apt-get update

Pedig ott kezdődik!

Szvsz. sokkal biztonsagosabb egy jol bekonfigolt, nem teljesen up-to-date rendszer mint egy teljesen up-to-date, de nem jol bekonfigolt. Az apt-get update utan is marad eleg buffer overflow stb... Ha valaki nagyon be akar menni, be is fog. A kerdes, mit talal ott? Mihez fer hozza? Es hasonlok....

[quote:c78789def0="WatchDog"]A sok hasznos hozzaszolason kivul esetleg lehetne olyat is csinalni iptables-el, hogy egy adott iprol egy adott idointervallumon belul hanyszor csatlakozhat vki. Esetleg vmi szkript, ami sok probalkozas utan tempban-ra teszi az illetot, amit aztan egy bizonyos ido elteltevel leszedi...vagy otthagyja, es majd kezzel kell kiszedni a blacklist-bol.

Én otthon ezt használom a próbálkozók ellen:
http://denyhosts.sourceforge.net/

[quote:9c115055b0="meditor"]Az nmap is egy port-scan. Ezt is lehetne detektálni, szerintem. Nem üzemszerű, ha valaki másodpercenként tucatszor portot vált.

Nézd meg a portsentry-t! http://linux.cudeso.be/linuxdoc/portsentry.php

Üdv.: Tomyellow

[quote:31158cd0c2="szaszg"]Jovaan naaa, en is lehettem magamon kivul egyszer... mit kell ugy felhanytorgatni... :-)Te sose voltal meg ugy besszivva, hogy hulyesegeket irtal????

Én? Ki van zárva. Csak azt nem értettem soha, hogy N+5 sör után a világ miért nem hajlandó a királyabbnál királyabb ötleteim szerint működni :). Pedig még a root jelszavak is eszembe jutottak :(...

ehhez az ssh töréshez lenne egy kérdésem! sokat tapasztaltam auth.log -ban, hogy tetszőleges ipkről próbálkoznak belépéssel a gépre, több usert, több jelszóval, majd továbbállnak! nem tud valaki olyan ssh configot, ami 3 sikertelen belépés után letiltja az ipt egy percig? vagy akármi hasonló is érdekelne!

Otletek:

Védekezés az ssh brute force támadások ellen

[quote:6b2ac36651="suti"]ehhez az ssh töréshez lenne egy kérdésem! sokat tapasztaltam auth.log -ban, hogy tetszőleges ipkről próbálkoznak belépéssel a gépre, több usert, több jelszóval, majd továbbállnak! nem tud valaki olyan ssh configot, ami 3 sikertelen belépés után letiltja az ipt egy percig? vagy akármi hasonló is érdekelne!

Bárcsak azt mondja meg valaki, hogy ajánljátok a sok-sok jó kis blokkoló dolgokat, de! ezek ugye együtt nem futnak, mert akkor egymás ütik vagy a szabálylánc lesz olyan, hogy a jóisten se igazodik ki rajta. Végülis akkor mit csináljon az egyszeri rendszergizda? :-)

[quote:7ea4d14028="_Polesz_"]Jajj drastik és hunger akkor arcotok van, ha elmentek az 5cm-es tévém előtt már akkor is lemaradok 2 sorozatról 8)

Vagy az is lehet, hogy nem az arcunk nagy, hanem egyszerűen sírva röhögünk azokon a security megoldásokon amiket egyesek itt elképzelnek. :wink:

[quote:7ea4d14028="_Polesz_"]Egyébként meg itt arról van szó, hogy hogyan lehet úgy biztonságosság tenni egy rendszert, hogy az ne menjen a használhatóság rovására. Vazz nem óhajtok minden egyes belépés előtt sms-t küldeni, portot kopogtatni ssh tunneleken keresztül a 20-ik proxy szerveren keresztül áthatolni, hogy egy ps parancsot ki tudjak adni a szerveren.

Nem is kell. Szerinted mi miért röhögünk veszettül ezen?

[quote:7ea4d14028="_Polesz_"]Valahogy kompromisszumokat keresünk a totális biztonság és használhatóság között.

Csak rossz irányba megy a tapogatózás.

[quote:7ea4d14028="_Polesz_"]Ha fikázást akarok akkor a flame rovatban nyitok topicot. Ha nincs értelmes hozzászólás akkor lehet alapba állítani a szájakat és ujjakat.

Tudtommal nem te nyitottad a topicot.

[quote:900e05eff1="_Polesz_"]Bárcsak azt mondja meg valaki, hogy ajánljátok a sok-sok jó kis blokkoló dolgokat, de! ezek ugye együtt nem futnak, mert akkor egymás ütik vagy a szabálylánc lesz olyan, hogy a jóisten se igazodik ki rajta. Végülis akkor mit csináljon az egyszeri rendszergizda? :-)

Miért ütnék egymást? A grsec/pax önmagában is sokmindent megfog, ahogy trey írta. Ezen felül lehet erősen ACL-ezni vele. A rendesen belőtt iptables szintén előnyös lehet. A grsec-nek vannak chroot erősítő módszerei, amivel erősen növelhető a chrootolt dolgok biztonsága. Az SSH-t pedig tessék legalább AllowUsers-el és megfelelő tartományokra való korlátozással védeni.

Alapvetően az elmondható szerintem hogy törhetetlen gép nincs, de olyan van, amit nem az első ssh-scan fog megzúzni és olyan is, aminél gondolom nem éri meg a fáradtságot a törögetés. Akinek pedig olyan gépe van, ami bármiért igencsak kitett támadásoknak, az a végletekig növeli a biztonságot.

[quote:7167af4261="andrej_"][quote:7167af4261="_Polesz_"]Bárcsak azt mondja meg valaki, hogy ajánljátok a sok-sok jó kis blokkoló dolgokat, de! ezek ugye együtt nem futnak, mert akkor egymás ütik vagy a szabálylánc lesz olyan, hogy a jóisten se igazodik ki rajta. Végülis akkor mit csináljon az egyszeri rendszergizda? :-)

Miért ütnék egymást? A grsec/pax önmagában is sokmindent megfog, ahogy trey írta. Ezen felül lehet erősen ACL-ezni vele. A rendesen belőtt iptables szintén előnyös lehet. A grsec-nek vannak chroot erősítő módszerei, amivel erősen növelhető a chrootolt dolgok biztonsága. Az SSH-t pedig tessék legalább AllowUsers-el és megfelelő tartományokra való korlátozással védeni.

Alapvetően az elmondható szerintem hogy törhetetlen gép nincs, de olyan van, amit nem az első ssh-scan fog megzúzni és olyan is, aminél gondolom nem éri meg a fáradtságot a törögetés. Akinek pedig olyan gépe van, ami bármiért igencsak kitett támadásoknak, az a végletekig növeli a biztonságot.

Értem én amit írsz, csak itt a sok iptables alapú megoldásra gondoltam mint egymást ütő cuccokra.

[quote:d9b3287186="colos"]
egy dolog felsorolni a megoldasokat, mas dolog telepiteni es karbantartani a dolgokat. aki nem csinalt meg ilyet az sem tudja, hogyan tesztelje le, hogy egyaltalan megfeleloen muxik. azert kell sshzni mert dolgozni kell az embernek, nem pedig szorakozasbol sztem.

udv zoli

erdekes h nalam megis bevalt es mukodik
biztos csak veletlenul

[quote:9f3bbf182b="suti"][quote:9f3bbf182b="samuf"]Ha már a bárhonnan SSH-ról van szó. Nem tudja valaki a magyarországi szolgáltatók ip címtartományát?

ilyesmire gondolsz: GEO IP ?

IP 10.0.0.5 belongs to a block consisting of the following:

nagyon okos :)))

[quote:31bdb2c978="meditor"]Van egy progi, nevezzük MrPort-nak. Ennek van egy szerver és egy kliens
oldala. A piszkálni kívánt gépen fut a szerver, ahol Te vagy, ott a kliens.
MrPort 2 porton figyel. a 22-esen és egy másikon, legyen ez a 10000-es.
A kliens oldal úgy tud kapcsolatba kerülni a szerver oldallal, hogy a
kliens küld egy hosszabb stringet és annak egyeznie kell a szerver oldali
ellenörző stringgel (a string konfigból állítható). Amikor a kapcsolat
létrejött a kliensen keresztül kiadsz egy parancsot, amitől az sshd
aktiválódik. Ettől kezdve lehet ssh-zni, de nem a 22-es porton, hanem
valamelyik másikon. Ha befejezted a munkát, akkor MrPort-cliensen
keresztül deaktiválod az ssht. MrPort 22-es portját pedig ragadós portnak
használod, ha valaki rákapcsolódik, akkor a nyitott csatornán szép lassan
adatokat csöpögtetsz neki, higyje csak, hogy ebből lesz valami, csak
rossz a vonal. Közben megnmap-pelheted, információkat szerezhetsz
róla, stb. A végén nem szabályosan lezárod a csatornát, maradjon csak
nyitva félig az ő oldalán, Te meg várod a következő támadást.

Ebben a megoldásban igyekeztem összesűríteni azokat a megoldásokat
amelyeket a korábbi hozzászólásokban többen is jónak tartottak.
Várom a véleményeket. Vegyétek észre, hogy az ssh ebben a
megoldásban csak akkor fut, amikor Te is akarod, tehát amikor Te nem
vagy jelen a az ssh-n való behatolás esélye 0(nulla) (Ja, plusz a shell
leszedése a mezei júzerekről.)

Az egész mutatvány ott bukik meg ahol a port kopogtatós megoldás is. Nem veszed figyelembe, hogy a hálózati forgalmat lelehet hallgatni és az egész bejelentkezési rituálét lelehet utánozni. Vagy úgy gondoltad, hogy majd a MrPort nevű csodaprogramod is titkosított csatornát hoz létre, mint az ssh? Akkor viszont jóval bonyolultabb program lesz, ergo több lesz benne a biztonsági hiba. Ugyan ott vagy ahonnan kiindultál, csak még bonyolítottad a saját helyzetedet plussz egy programmal és csökkentetted a szervered biztonságát, mert még egy felesleges szolgáltatás fut. Miért nem inkább azon gondolkozol el, hogy megfelelő policy kellene és annak betartásával elkerülhető, hogy proba user legyen a szervereden proba jelszóval...

MrPort-rol... Eloszor is egyetertek hunger velemenyevel. De meg megjegyeznek egy dolgok a nmappal meg az informacioszerzessel kapcsolatban.
Elfelejted, hogy a "tamadas" 99,999999%-al egy zombi geprol erkezik. Tehat egyebet nem ersz el, mint egy - az ignoranciajan kivul - artatlan emberket molesztalsz. Sot, ha jol tudom, az, hogy egy geprol tamadas van ellened, meg nem jogosit fel teged arra, hogy portscannel-d ot. Meg a vegen a kormodre koppintanak...

[quote:8dfd11c0f1="1aca"][quote:8dfd11c0f1="muszashi"][quote:8dfd11c0f1="drastik"]
en arra lennek kivancsi hogy a sok "deninyan leenugz a kiraly" wanabe rendszergazda mikor tanulja mar meg hogy a szekurity nem az apt-get update

Pedig ott kezdődik!

Szvsz. sokkal biztonsagosabb egy jol bekonfigolt, nem teljesen up-to-date rendszer mint egy teljesen up-to-date, de nem jol bekonfigolt. Az apt-get update utan is marad eleg buffer overflow stb... Ha valaki nagyon be akar menni, be is fog. A kerdes, mit talal ott? Mihez fer hozza? Es hasonlok....

Ez nem is kérdés, írtam is példákat korábban a hogyanra. Viszont szerintem az up-to-date állapot is igen fontos. A script kiddie-k ugyanis igen gyakran tök régi sechole-okat használnak ki, ergo, ha az illető frissítené a rendszerét nem tudnának bemenni. (most nem a topicnyito ssh jelszókitílálósra gondoltam, mert arra többen is írtuk pl a kulcsok használata+magas portszámot+megfelelő csatolási opciók+chroot+kutyafüle) Tehát azt gondolom, hogy nem elég egyszer bekonfigolni valamit, azt naprakészen is kell tartani. Aki nem frissíti a rendszerét folyamatosan, az nem érdemli meg, hogy fizetést kapjon! ...és még ugye így sem garantált, hogy nem nyomnak fel, szóval a rendszeres mentést is el kell végezni a fizetésért! (vagy végeztetni cronból és értesítőt kapni az eredményről, amit el is olvasol.)

M.

[quote:91e4be318f="meditor"]Hu, de sok jó ötlet!

Aztán mire sikerül megvalósítani a "tökéletes" biztonságot minden API megváltozik :-)

[quote:136b1c84ad="colos"][quote:136b1c84ad="drastik"][quote:136b1c84ad="hunger"]huh, jó ez a topic. megint könnyesre röhögtem magam...

a sracok nagy szekuriti expertek

topicnyitonak:

btw.

1. miert a 22 es porton fut az sshd
2. miertnem jailben futnak a szolgaltatasok(vagy uml)
3. miert lehet sshzni barhonnan a gepre
4. ha mar linux akkor miertnem pax
5. miert passwd es miertnem kulcs
6. hogyhogy az osszes user su-zhat rootra

ez aki megtorte a gepedet egy luzer
egy profit eszre sem vennel

egy dolog felsorolni a megoldasokat, mas dolog telepiteni es karbantartani a dolgokat. aki nem csinalt meg ilyet az sem tudja, hogyan tesztelje le, hogy egyaltalan megfeleloen muxik. azert kell sshzni mert dolgozni kell az embernek, nem pedig szorakozasbol sztem.

udv zoli

Gondolom Kínából, Észak-Kórából és a Fidzsi szigetekről is be kell tudnod lépni. Azt vegyük már észre, hogy néhány hazai szolgáltató tartományára néhány /16-os ACCEPT vagy pass in rule-al talán még lehet élni és őrülten nagy karbantartást sem igényel. Ha olyan gép ami bármilyen okból publikus shellt ad, akkor tessék megoldani hogy chrootban legyen valami jailszerű (FreeBSD-vel pl. egészen kellemesen megoldható és még login classok meg MAC framework is van by default). Egyéb esetben, pedig a legkevesebb szükségesnél nem kell több shelljuzert kiadni.

Ezek a portknocking és más hasonló álmegoldások szerintem csak simán növelik a biztonsági kockázatot, amit pedig csökkenteni kéne. Ez a küldök egy SMS-t dolog is eléggé meredeken hangzik. Egyáltalán miért kell "bárhonnan" elérni egy gépet és ha ennyire fontos a biztonság, akkor miért nincs egy kevéssé publikus adminszerver, ahonnan lehet nyomulni?

[quote:c9151c380d="1aca"]MrPort-rol... Eloszor is egyetertek hunger velemenyevel. De meg megjegyeznek egy dolgok a nmappal meg az informacioszerzessel kapcsolatban.
Elfelejted, hogy a "tamadas" 99,999999%-al egy zombi geprol erkezik. Tehat egyebet nem ersz el, mint egy - az ignoranciajan kivul - artatlan emberket molesztalsz. Sot, ha jol tudom, az, hogy egy geprol tamadas van ellened, meg nem jogosit fel teged arra, hogy portscannel-d ot. Meg a vegen a kormodre koppintanak...

Jah, hát erre az nmapos, visszatámados, jólmegnézős, információszerzős gondolatra már nem is akartam reagálni. A Testa nevű emberke irogatott annakidején hasonló megoldásairól, akkor is jól szórakoztunk. :lol:

gondoltam ezért nem nyitok új topikot, ide is belefér... véleményeket és ötleteket szeretnék tőletek.

a következő a helyzet: adott egy dedikált szerver amin szükségszerűen az ügyfél összehányt php kódját és egyéb hasonló dolgokat meg kell tűrni. ebből korábban már volt gond, mert ezen keresztűl húzták már meg a szervert...

az üzemeltetést átvettem, újrahúztam, a lehető legjobban megpróbáltam bebiztosítani, kapott mod-security -t, javíttattam jó pár dolgot a php kódokban, de se safe_mode nem kapcsolható se register_globals ki, + a kód miatt egy csomó egyébként általam nem preferált fv is kell (system és a többiek)... összegezve egy hatalmas gány az egész és átvizsgálhatatlan az php-s "portál" kódja...

a helyzet most:
-ezerrel jönnek vissza az egyik alap címre levelek (ami a feladó volt) a legkülönfélébb helyről, h nem lehetett kézbesíteni...
-a levelet nyilván senki sem küldte, spam...
-a visszakapott levelekben az elküldött levél fejléce is benne van amiből egyértelműen kiderül, h valóban a szerverről ment ki!
-a logokból semmi nem látszik, de tényleg!
-ps semmi különös
-netstat semmi különös
-levél küldés távolról csak auth után megy, helyből a permit_mynetwroks (127.0.0.0/8) (webmail ezen keresztül)
-webmailnak két cucc egymás mellett, squirrelmail és ilohamail, mindkettő külön linken, a linkek nem szerepelnek sehol

chkrootkit és rootkithunter semmit sem talál, persze ha vmi vhogy teljesen betúrta magát kernel szinten akkor ez nem feltétlenül csoda... sehogy nem látom és nem tudom visszakövetni, h mi és mikor küldi ki a levelet...

szóval itt jön a nagy kérdés, h mit és hogyan néznétek tovább, mit használnátok felderítésre?

rendszer: debian 3.1, rendszeresen frissítve, apache2, php4, mysql4.1, postfix/courier virtual userekkel(sql), + egyéb szűrések postfix alá de az ide lényegtelen...

Az is egy lehetoseg, hogy irsz egy szkriptet, ami logtail-el nezegeti a logjaidat es ha megtalalja azt a patternt, ami egy ssh bruteforce vagy dictionary attackra utal, vagy csak szimplan portscanre, akkor kiad egy iptables -I INPUT -s IP -j DROP -ot.
Ezzel ha nincs iptables-save-restore megvalositas, rebootig ejtve van minden csomag a tamado cimtol. Ha van, akkor vegleg bannra tetted.
(Erdemes egy fix ip-t kivetelkent kezelni, nehogy spoofolt ip-rol kizarjanak teged is a hostrol, mert akkor mehetsz be konzolhoz:)

Portscanre pedig ez utal: sshd: Did not received identification string from X.Y.Z.W
altalaban ez utan jonnek a ssh belepesi kiserletek ugyanarrol a cimrol.