[sandman_hu]

Olvastam egy howto-t, amiben azt irtak a halozati dolgokkal kapcsolatban, hogy ha egy adott gepen van egy nyitott port es azon semminemu alkalmazas nem fut, akkor egy parancssal kivulrol shell-t lehet nyitni - meg akkor is, ha nincs belepesi engedelyunk a gepre. Ebbol mi igaz? Melyik parancs hajtja ezt vegre? Vedekezni gondolom ugy kell ellene, hogy a felesleges portokat le kell tiltani.

[giotto]

idézet:

---

Ezt írta sandman_hu:
Olvastam egy howto-t, amiben azt irtak a halozati dolgokkal kapcsolatban, hogy ha egy adott gepen van egy nyitott port es azon semminemu alkalmazas nem fut, akkor egy parancssal kivulrol shell-t lehet nyitni - meg akkor is, ha nincs belepesi engedelyunk a gepre. Ebbol mi igaz? Melyik parancs hajtja ezt vegre? Vedekezni gondolom ugy kell ellene, hogy a felesleges portokat le kell tiltani.[/quote]

hat igen, ez a legjobb vedekez, + letezik vmi progi, aminek most enm ju eszembe a neve ami azt csinalja, hogy ha letja, hogy scannelik vegig a portokat, hogy melyik van nyitva/zarva akkor bezarja az osszeset...

[Vendor]

idézet:

---

Ezt írta giotto, aki meg mindig melot keres:


hat igen, ez a legjobb vedekez, + letezik vmi progi, aminek most enm ju eszembe a neve ami azt csinalja, hogy ha letja, hogy scannelik vegig a portokat, hogy melyik van nyitva/zarva akkor bezarja az osszeset...[/quote]

portsentry?

[sandman_hu]

De nyitott porton keresztul, ahol nem fut alkalmazas, lehet nyitni shell-t?

[Nevergone]

idézet:

---

Ezt írta sandman_hu:
De nyitott porton keresztul, ahol nem fut alkalmazas, lehet nyitni shell-t?[/quote]

Javítsatok ki, ha tévednék, de szerintem egy port attól nyitott, hogy fut egy alkalmazás, ami magához kötötte, lásd szerver.

Szal, ha egy adott portot nem használ semmilyen alkalmazás sem, akkor arra nem lehet bejelentkezni, se semmit...

De persze egy jó tûzfal az igazi biztonság...

[sandman_hu]

En szvsz mar tapasztaltam hasonlot. SSH, nyitott volt a 22-es port, de a daemon nem futott - ergo ssh-val nem lehetett belepni. De a port nyitott volt. Ha Te nem erre gondoltal, akkor boccs, jol elbeszeltunk egymas mellett!

[marczi]

Ha egy port nyitott, attol meg egyaltalan nem biztos, hogy az a szolgaltas fut rajta, ami altalaban ott szokott futni. Nekem pl. van olyan, hogy VNC fut a 22-es porton.

Egyebkent szerintem nem lehet igy shellt inditani, en ezt eleg marhasagnak tartom, kivancsi lennek, merre olvastal rola!

[Nevergone]

idézet:

---

Ezt írta marczi:

Egyebkent szerintem nem lehet igy shellt inditani, en ezt eleg marhasagnak tartom, kivancsi lennek, merre olvastal rola! [/quote]

Szerintem [url="http://"http://www.microsoft.com/hun/default.mspx"]itt[/url]... na jó, ez elég szar vicc volt...

[sandman_hu]

Jol van na, csak erdeklodom. En sem tudom biztosan! De latom azert Ti sem...

[bean]

idézet:

---

Ezt írta sandman_hu:
Jol van na, csak erdeklodom. En sem tudom biztosan! De latom azert Ti sem... [/quote]

Jó. Akkor én felvállalom biztosra. Az, hogy egy portra érkezõ csomagokat nem hajítja el a gép (DROP) vagy nem küld vissza TCP RESET-et (REJECT, DENY) az még nem jelenti azt, hogy tudsz shellt indítani. Ahhoz hogy shellt tudj indítani azon a porton át, ahhoz kell egy program, ami az adott porton figyel, fogadja a byte-jaidat, elindít neked pl. egy shellt és visszaküldi neked, amit a shell kiírt.

[marczi]

Csatlakozom, en is vallalom, hogy shell-t inditani csak ugy nem lehet akarmilyen portrol!

[sandman_hu]

Jol van. Koszonom!

[rõt pajesz]

idézet:

---

Ezt írta giotto, aki meg mindig melot keres:


hat igen, ez a legjobb vedekez, + letezik vmi progi, aminek most enm ju eszembe a neve ami azt csinalja, hogy ha letja, hogy scannelik vegig a portokat, hogy melyik van nyitva/zarva akkor bezarja az osszeset...[/quote]

Bocs, de nem vagy te egy kissé diszleksziás?

[rõt pajesz]

idézet:

---

Ezt írta marczi:
Csatlakozom, en is vallalom, hogy shell-t inditani csak ugy nem lehet akarmilyen portrol! [/quote]

Elõre bocsájtom, nem igazán értek a pingvines rendszerek lelkivilágához, csak minimalista szinten:

de tsókolom; ha fut egy rendszer, akkor azon már ott fut a shell, nem kell elindítani, csak be kell jelentkezni rá, nem? Ha mindez emészthetetlenül fájdalmas valaki számára, kérem világosítson fel, hogy értsek hozzá én is egy picinyt legalább. Köszöntemszép'. :confused:

[j.cs.]

idézet:

---

Ezt írta rõt pajesz:


Elõre bocsájtom, nem igazán értek a pingvines rendszerek lelkivilágához, csak minimalista szinten:

de tsókolom; ha fut egy rendszer, akkor azon már ott fut a shell, nem kell elindítani, csak be kell jelentkezni rá, nem? Ha mindez emészthetetlenül fájdalmas valaki számára, kérem világosítson fel, hogy értsek hozzá én is egy picinyt legalább. Köszöntemszép'. :confused: [/quote]

Na, vilagositsunk...
Mindenfele UNIX rendszeren a kernel elindulasa utan elindul az un. init processz (processz id = 1, mivel ez az elso processz). Az init az un. initrc file-ban leirtak alapjan elkezdi elinditani az egyes szolgaltatasokat. Az egyik ilyen szolgaltatast ugy hivjak, hogy inetd, aminek egyetlen funkcioja van: figyel bizonyos TCP portokon, es az ezekre a portokra torteno kapcsolodas eseten a konfiguracios allomanyaban (/etc/inetd.conf) leirt parancsot futtatja le.

Ennek a mechanizmusnak a segitsegevel lehetseges a legegyszerubben demonokat (vagyis kiszolgalo feladatkoru, egy bizonyos halozati porton figyelo kliens-szerver szolgaltatasokat) implementalni, ugyanis az inetd altal elinditott programok sima I/O muveletekkel kezelik az adott halozati portot (vagyis amit a user tavolrol kuld a gepnek, az az adott futtatott program standard inputjara erkezik, a program outputjat pedig atkuldi a halozaton a masik oldalra).

Megjegyzes: mem inetd-t hasznalo halozati demonokat implementalni egy kicsit bonyolultabb (olyan lepeseket kell csinalni, mint: 2x forkolni, standard input/output-ot lezarni, tilos a kiiras, komplexen kell kezelni a halozati forgalmat (listen, accept, stb)).

Namost, egy UNIX rendszer gyonyoruen el tud futni mindenfele shell futtatasa nelkul, hiszen a shell nem mas, mint a felhasznalo parancsait ertelmezo program. Ha nincs belepve felhasznalo, akkor nem fut shell (eltekintve mondjuk egy eppen batch-ben futo shell scripttol, de annak semmi koze a halozathoz).

Hogyan lehet akkor egy tavoli geprol egy portra csatlakozva shellt kapni? Hat igen egyszeruen: be kell juttatni egy "trojai lovat" a gepre, ami figyel egy bizonyos porton, es az ejszaka leple alatt beengedi a varosba a gorog hoditokat. Ilyen trojai programok igazabol Windows alatt elnek dogivel, de azert a Linux es UNIX platformot sem kimelik a kedves rosszindulato terrorista programozo urak. Az egyik legegyszerubb ilyen trojai pl a kovetkezo sor az /etc/inetd.conf-ba:

6666 stream tcp nowait root /bin/bash

Ekkor a 6666 portra torteno csatlakozas eredmenyekent egy, a root felhasznalo neveben futo shell-t kapunk az adott gepen. Persze ehhez mar korabban be kellett torni az adott gepre, ahol letre kellett hozni ezt a sort megfelelo file-ban, amihez mar root jogosulsag kellett, igy mindennek csak akkor van ertelme, ha visszajaro lelkek vagyunk az adott gepen...

Amugy a gyakorlatban ennel joval rejtettebb backdoor-okat szoktak a gepeken hagyni a kedves terrorista urak.

A lenyeg az, hogy ettol sem kell jobban felni, mint attol, hogy egy vasarnap hajnalban valaki betor a lakasunkba...

Jelszo: patchelni, frissiteni, update-elni gyakran, gyakran, gyakran, hogy az elso betores eselyet csokkenteni tudjuk...

A tuzfalasdi pedig azert nem nyujt igazabol vedelmet ez ellen, mert ha mar bent van a tamado, es tud nyitni backdoort, akkor a tuzfalbeallitasunkat is at tudja irni. Tehat ekkor mar az eredeti tuzfalbeallitasokkal is gond volt.

Bocs, ha kihagytam valamit...

[rõt pajesz]

idézet:

---

Ezt írta j.cs.:


Na, vilagositsunk...
Bocs, ha kihagytam valamit...[/quote]

Én kérek elnézést tudatlanságomért és köszönöm szépen a hasznos információkat és a megértõ hangnemet. KCS
dU bIST üBERcOOL


[ 2004. január 27.: rõt pajesz szerkesztette a hozzászólást ]

[charlie]

szeretnem felhozni a témát.

hogyan lehet egy linux kiszolgalot biztonsagosra megcsinalni? kernel patchekkel? agyonkonfiguralt kernellel? stb?

[Sipi-]

Idézet: charlie - Dátum: 2007. nov. 23., péntek - 22:00

szeretnem felhozni a témát.

hogyan lehet egy linux kiszolgalot biztonsagosra megcsinalni? kernel patchekkel? agyonkonfiguralt kernellel? stb?

Szerintem alapvetõen két csapásirány létezik:
1. saját magad fordított kernel és kernel patchek (pl. debian, gentoo, stb.)

2. "gyári" kernelek és sûrû frissítések (redhat, suse, centos (ez gyakorlatilag ingyenes redhat))

Ugye mindkettõnek megvan az elõnye és a hátránya is.
A saját magad fordított kernelnél a gépedre lesz optimailizálva a kernel, kernel patchek felrakva, gyors, csak a szükséges kódot tartalmazza a kernel és a csak a szükséges modulok vannak meg. Hátránya, hogy lehet vele szívni szépen, ha nem vagy benne rutinos.
A "gyári" kernelek ezzel szemben tartalmaznak mindenféle modult, opciókat, ezért lehet, hogy lassabbak a sajátnál. Cserébe viszont letesztelt és könnyen reprodukálható rendszert lehet belõle építeni és kevesebb a szívás vele. Az újabba kernelre való áttérés is zökkenõmentesebb.


"Biztonságossá tenni". Ez alatt mit értessz? Nem mindegy, hogy csak "kívülrõl" várhatók támadások (hálózaton keresztül), vagy "bentrõl" is. Az utóbbi abban az esetben fordulhat elõ, ha több login van a gépen, más userek is használják.
A szerver biztonsága nagyban függ a rajta futó szolgáltatásoktól is, bár azok biztonsági réseit részben ki lehet védeni erõs security beállításokkal.

És végül, de nem utolsósorban a fizikai védelem is fontos. Sokra mész a hiperszuper tûzfallal, szabályokkal, ha megfogják a gépet, bevágják a kocsiba és úgy lopják el az adatokat.

Szerkesztette: Sipi- 2007. 11. 23. 23:52 -kor

[mocsi]

Idézet: charlie - Dátum: 2007. nov. 23., péntek - 22:00

szeretnem felhozni a témát.

hogyan lehet egy linux kiszolgalot biztonsagosra megcsinalni? kernel patchekkel? agyonkonfiguralt kernellel? stb?

A leggyakrabban elofordulo kompromitalasok tavolrol tortennek, ezert
1. a legfontosabb hogy csak azok a szolgaltatasok mukodjenek, amik valoban kellenek, es ezeket is rendszeresek kell figyelni/frissitgetni.
2. Megfeleloen kialakitott tuzfal szabalyzat (ki, honnan mit mikor, hogyan erhet el)
3. Mas altal irt tavolrol elerheto programok (pl. php) mar valamilyen RBAC  dologgal jol lekorlatozni
4. Log audit rendszeresen
5. Monitorozas
6. valamilyen rootkit hunter, esetleg virus killer.

Ez a legfontosabb szerintem, a masodik mar a helyi login jogosultsagos normalis felmeres utani  atgondolt kialakitasa/beallitasa, meg a CVS problemak/frissitesek figyelese

[charlie]

most tekintsunk el a fogják a gépet és viszik, valamint a belso tamadasoktol!

ha mondjuk van egy tuzfall (mittomén, valami normalisabb, cisco, stb.)) már maga a gép elõtt (plusz ugye az iptables magan a gepen), az mennyit segit? vagy nem sok értelmuk van?

vegyunk mondjuk egy példát, mondjuk webszervert (meg hozza php-mysql koritest, mondjuk azt, hogy leveleo az egy másik gépen van, igy az nincs)

log auditon konkretabban mit ertesz (rendszeresen nezni?)?
érdemes a rendszer logot egy másik gépre kuldeni? (meg ugy a tobbi logot is)?

valamint melyik disztrot érdemes publikus szerver feladatokra, vagy melyik disztro milyen kernelet? gondolom én, hogy a sima desktop célra szánt kiadásokban inkabb a hasznalhatosagra mennek ra, mint a biztonsagra. van olyan disztribucio, ami csak szerver célra megy rá?

érdemes az apacsot (meg a mysql, php, ftp) sajat magamnak forditani, vagy amit tárolokbol fel lehet tenni (pl. debian) az megfelelo?