Biztonság a köbön

Rootkit programok ellen hogan lehet védekezni? Imseritek az "eliteazazel" elnevezésű programot? Van tapasztalatotok arról, hogy ha a wwwrun felhasználóval végzi egy betörő a szemétségeit, akkor mi lehet a konkrét biztonsági rés? Hogyan mászhat be valaki egyáltalán wwwrun-nal? Ha a shellt-false-ra állítom, az jó megoldás?

Köszönöm!

[quote:88fcda1491="norcrys"]Az OpenBSD jail jobb, mint a linuxos chroot

Erre vanik rsbac jail...

Azért ez a hallgatás, mert ismerős a történet? :evil:

[quote:795f214cc7="Lestat"]Azert OpenBSD-t tuzfalnak, mert ha jol emlekszek 8 ev alatt csupan egy tavolrol kihasznalhato hibat talaltak benne...

A default installban. Ez mondjuk nem mindegy, habár a kernelt jellemzi, hisz az mindig benne van alapban :). Persze nem tudom, hogy a Linux kernelben mennyi távolról kihasználható hiba volt az elmúlt időben.
Az OBSD bizonyos dolgokban nagyon jó kis rendszer, a biztonsági policyje is sokkal jobb az átlagnál. Tetszik, hogy Theo ennyire ragaszkodik hozzá (meg a licenchez is) amivel persze elég sok kellemetlenséget tud szerezni magának is meg másoknak is, de legalább következetes. Ezért jó tűzfalnak (is). Persze elég sok dologban meglehetősen gyatra, de persze kinek mire van szüksége.

[quote:aba8440e39="Willow"]
Amit még változtatnom kellett, hogy a protokolnál meg kellett hagynom az 1-t is, mert különben connection refuesd küldött vissza.
Mi a hiba?

Hali! Erről olvastam valahol... Ott az ssh-host-config és/vagy az ssh-user-config futtatásának elmulasztását emlegették a hiba forrásaként. :)

Csak egy ötlet...

[quote:6ccd8946a6="szucs_t"]Rootkit programok ellen hogan lehet védekezni? Imseritek az "eliteazazel" elnevezésű programot? Van tapasztalatotok arról, hogy ha a wwwrun felhasználóval végzi egy betörő a szemétségeit, akkor mi lehet a konkrét biztonsági rés? Hogyan mászhat be valaki egyáltalán wwwrun-nal? Ha a shellt-false-ra állítom, az jó megoldás?

Köszönöm!

Neha egy checkrootkit es PHP eseten Safe Mode On es openbasedir, azt probalkozzon. Ha CGI van akkor pedig csak olyan scriptre szaad futasi jogot adni, amit nagyjabol lattal. Bemaszni egyebkent apache hibaval tud vagy PHP-val. Egyebkent milyen oprencer ez?

[quote:1aac4899c0="Sea-you"][quote:1aac4899c0="szucs_t"]Rootkit programok ellen hogan lehet védekezni? Imseritek az "eliteazazel" elnevezésű programot? Van tapasztalatotok arról, hogy ha a wwwrun felhasználóval végzi egy betörő a szemétségeit, akkor mi lehet a konkrét biztonsági rés? Hogyan mászhat be valaki egyáltalán wwwrun-nal? Ha a shellt-false-ra állítom, az jó megoldás?

Köszönöm!

Rootkit ellenorzesre szerintem hasznalj rkhuntert, nagyon aktivan fejlesztik, merfoldekkel jobb mint a chkrootkit. Amugy a wwwrun felhasznalonev arra utal, hogy apache bug vagy az egyik rajta futtatott site-on keresztul, vagy a php egyik hibaja,stb stb stb utjan jutott be valaki. Tehat minden webszolgaltashoz hasznalt programot nezz at a rendszereden es talald meg melyikben van bug. Nezd vegig az apache access es error logjait, sztem talalsz benne valamit hacsak a cracker ki nem mutotte a bejutas modjat vagy le nem torolte a filet. Nagy idopontugrasok gyanusak :) Legalabbis en igy kezdenem a kutatast. :wink:

http://www.rkhunter.org/

Köszi, az rkhunter egész jónak tűnik. Hogyan lehet frissíteni az apache-ot? a pacth-csel már a feltelepítettet is lehet peccselni? Ha igen, melyik fájlokat?

[quote:dadb9f14b5="Luckyboy"]
Chroot-olt ssh-t nézegettem, olvastam a hup-os topicokat is erről, de igazán nem tudtam kiszűrni egy igazán jó megoldást. Erre vmi javaslat, pl te mit használsz?

http://members.chello.hu/sallaia/chroot.html

[quote:04e7bda264="szucs_t"][quote:04e7bda264="LiRul"][quote:04e7bda264="szucs_t"]Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

Javaslom nezegesd kicsit a php.ini fileodat...

És mit fogok benne találni?

Amit hianyoltal: safe_mode open_basedir es tarsai.

[quote:c862f7e97c="LiRul"][quote:c862f7e97c="szucs_t"][quote:c862f7e97c="LiRul"][quote:c862f7e97c="szucs_t"]Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

Javaslom nezegesd kicsit a php.ini fileodat...

És mit fogok benne találni?

Amit hianyoltal: safe_mode open_basedir es tarsai.

A safe mód be van állítva, de az open_basedir nem tudom, mi a manó.

[quote:ab76262ff7="szucs_t"][quote:ab76262ff7="LiRul"][quote:ab76262ff7="szucs_t"][quote:ab76262ff7="LiRul"][quote:ab76262ff7="szucs_t"]Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

Javaslom nezegesd kicsit a php.ini fileodat...

És mit fogok benne találni?

Amit hianyoltal: safe_mode open_basedir es tarsai.

A safe mód be van állítva, de az open_basedir nem tudom, mi a manó.

Ezen a php.net user manual olvasgatasa segithet. http://www.php.net/manual/hu/features.safe-mode.php

kiprobáltam, amit irtatok, de problémák merültek fel.Openssh van a kiszolgálón.
kiprobáltam azt a beállítást amit itt megadtatok, de ott följön az ablak és kéri a login nevet.ha megadom egyszerűen becsukódik.
Amit még változtatnom kellett, hogy a protokolnál meg kellett hagynom az 1-t is, mert különben connection refuesd küldött vissza.
Mi a hiba?
a kulcs ssh2 rsa 1024 bites kulcs, úgy tettem ahogy irtátok, nincs jelszóval kódolva.

Kösz LiRul!

Jól értem, ha a honlapom mondjuk a "/var/local/httpd/htdocs"-ban van, akkor ezt írjam be: "open_basedir = /var/local/httpd/htdocs"? Alapban mi mást használna? Az egész partíciót?

[quote:d8c4ee40ca="global77"]Non-commercial ssh2 -t használj openssh helyett, mondják a nagyok.

Wahaha, miért is? Arra talán kevesebb exploit jött ki? :lol:

[quote:ef2df777bc="szucs_t"]Alapban mi mást használna? Az egész partíciót?

Az is le van oda irva, hogy igen.
RTFM

[quote:055839e6f9="gsimon"]Egy regebbi kerdesre, miszerint miert jo, ha kulon gepen van a tuzfal, mint a szerver:

Tfh. a szerveren vmi rootkent futo cucc bugjat kihasznalva root-kent elindit vmi kodot a betoro.

Ha ez a gep ugyanaz, mint a tuzfal, akkor innentol a teljes (eddig) vedett belso halo nyitva van kifele, es meg a logokat is lezuzhatja maga utan.

Ha kulon gepen vannak, akkor:

- a halo kintrol tovabbra is zart, bar mar van egy gepe belul, de az sem biztos, hogy mindent lat belul

- bent ugyan fut a kodja, de shellje meg nincs, azt meg at kell hackelnie a tuzfalon

- a tuzfal-logod megmarad, es megnezheted, hogy hogy is jott be

- a tuzfal bentrol kifele is szur

Pelda: a szerveren van proxy meg smtp meg pop3s, a rendszer:

szerver ----------+

belso halo ---- tuzfal ---- vilag

A csomagszuro:

vilag->szerver: smtp, pop3s

belso halo->szerver: proxy, smtp, pop3s

vilag->belso, belso->vilag: semmi

szerver->vilag: proxy, http[s], smtp

szerver->belso halo: _semmi_

Ha bejutott vki a szerverre, es szeretne pl. kinyitni egy portot, ahol bejohet, hat nem fog menni. Ha a szerverrol kapcsolodna 'haza', na az sem:).

Persze ha otthon felhuz egy httptunnel-t, es megy haza http-n, akkor kijut, de ez azert macerasabb, mint nyitni egy socketet es inditani ra egy shellt.

Aztan persze az igazan paranoidok meg a tuzfal logjat is egyiranyu soros kabelen kuldik kulon gepre :)

Sziasztok.

Engem ennek a szövegnek a vége érdekelne. Kifejtené, nekem valaki, hogy mit értett azon, hogy nyit egy socket-et, és inditani rá egy shellt?
(Lehet hogy rosszul értelmeztem, de egyebkent tűzfal mögül (csak a 80-as port engedélyezett) szeretnék elérni webhelyeket, amik nem a 80-as porton vannak.) Ha tudna valaki adni tippet, hogy mihez kezdjek, az jó lenne.

Köszönöm

[quote:f01cb72e25="LiRul"][quote:f01cb72e25="szucs_t"]Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

Javaslom nezegesd kicsit a php.ini fileodat...

És mit fogok benne találni?

[quote:dfcd85d722="szucs_t"]Rootkit programok ellen hogan lehet védekezni? Imseritek az "eliteazazel" elnevezésű programot? Van tapasztalatotok arról, hogy ha a wwwrun felhasználóval végzi egy betörő a szemétségeit, akkor mi lehet a konkrét biztonsági rés? Hogyan mászhat be valaki egyáltalán wwwrun-nal? Ha a shellt-false-ra állítom, az jó megoldás?

Köszönöm!

Rootkit ellenorzesre szerintem hasznalj rkhuntert, nagyon aktivan fejlesztik, merfoldekkel jobb mint a chkrootkit. Amugy a wwwrun felhasznalonev arra utal, hogy apache bug vagy az egyik rajta futtatott site-on keresztul, vagy a php egyik hibaja,stb stb stb utjan jutott be valaki. Tehat minden webszolgaltashoz hasznalt programot nezz at a rendszereden es talald meg melyikben van bug. Nezd vegig az apache access es error logjait, sztem talalsz benne valamit hacsak a cracker ki nem mutotte a bejutas modjat vagy le nem torolte a filet. Nagy idopontugrasok gyanusak :) Legalabbis en igy kezdenem a kutatast. :wink:

http://www.rkhunter.org/

Az ssh port kinyitása és beengedése mennyire biztonságos?
Hogy lehet ezt igazán biztonságossá tenni?

[quote:f8fe2448e6="Willow"]Az ssh port kinyitása és beengedése mennyire biztonságos?
Hogy lehet ezt igazán biztonságossá tenni?

Non-commercial ssh2 -t használj openssh helyett, mondják a nagyok.
ftp.ssh.com/pub/ssh
+ a root ne ssh-zhasson!

[quote:cf8cb3c0c2="global77"][quote:cf8cb3c0c2="Willow"]Az ssh port kinyitása és beengedése mennyire biztonságos?
Hogy lehet ezt igazán biztonságossá tenni?

Non-commercial ssh2 -t használj openssh helyett, mondják a nagyok.
ftp.ssh.com/pub/ssh
+ a root ne ssh-zhasson!

openssh eseteben

pl

Port 4121
PermitEmptyPasswords no
AllowUsers usernev
Protocol 2
PasswordAuthentication no
RhostsRSAAuthentication no
IgnoreRhosts yes
RSAAuthentication yes
RhostsAuthentication no
X11Forwarding no
KeepAlive yes
PrintMotd no
ListenAddress x.x.x.x
HostKey /etc/ssh/ssh_host_key
HostbasedAuthentication no
IgnoreUserKnownHosts yes
StrictModes yes
SyslogFacility AUTH
ServerKeyBits 1024
LogLevel INFO
LoginGraceTime 600
KeyRegenerationInterval 3600
UsePrivilegeSeparation yes
PAMAuthenticationViaKbdInt no
ChallengeResponseAuthentication no

erdemes hasznalni a publikkulcsos azonositast, ezenkivul

iptables -A INPUT -i $IFACE -p tcp --sport 4121 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $IFACE -p tcp --dport 4121 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o $IFACE -p tcp --sport 4121 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -s tartomany -m state --state NEW,ESTABLISHED -p tcp --dport 4121 -j ACCEPT

nagy vonalakban :)

Az már okés, hogy érdemes külön gépre tenni a tűzfalat.
(Gondolom csak azért, hogy a kiszolgálónak több
ideje jusson más feladatokra, de ha tévedek,
akkor javítsatok ki.)

Az viszont még mindig homályos, hogy miért javasoltok
OpenBSD-t tűzfalnak. Miért érdemes váltani?
Miben mások a lehetőségei, mint az iptables-nek?
(Ráadásul ehhez ott van a Firewall Builder is,
amivel pikk-pakk össze lehet rakni a szabályokat,
és még az iptables "nyelvét" sem kell megtanulni...)

ssh kliensként a putty-t használom. Mivel kell kulcsot generálnom a putty keygen-jével v. az ssh-éval? Probáltam már de mintha nem tudnák olvasni egymáséit.
Pontosan mhova kéne másolni a kiszolgálon a kulcs fáljt ill felsorolni azokat a kulcsfáljokat akik bejöhetnek.
Ezeket nem tudják megszerezni?

Nem akartam új topikot nyitni, csak egy kicsit csavarok rajta...

Tegyük fel hogy a rendszerbe betörtek, az óvintézkedések ellenére. :cry:
A betöréseket mivel lehet érzékelni, (azon kívül hogy nem megy a gép stb.). milyen csapdákat lehet
felállítani erre az esetre? Automatikus dolgokra gondolok, egyáltalán léteznek ilyen progik?

Megelőzésre/érzékelésle pl portscan figyelő démon érzékel valahonnan scannelést azt az ipt
automatikusan droppolja...

Üdv: badur

[quote:e99d1e0c57="Willow"]ssh kliensként a putty-t használom. Mivel kell kulcsot generálnom a putty keygen-jével v. az ssh-éval?

puttygen

[quote:e99d1e0c57="Willow"]
Probáltam már de mintha nem tudnák olvasni egymáséit.

generálás után kapsz vmi ilyesmi formátumot:
[code:1:e99d1e0c57]
PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: airween keys on xp
Public-Lines: 4
A..blabla
...blabla
...blabla
...9H0=
[/code:1:e99d1e0c57]

ebbol kimasolod a publikus kulcsot (itt az A-tol kezodooen a 9H0=-ig), egy sorba írod, kiegészíted így:

[code:1:e99d1e0c57]
ssh-rsa A.....9H0= user@host
[/code:1:e99d1e0c57]
ahol a hosztnév az a gép, ahonnan be fogsz jelentkezni

[quote:e99d1e0c57="Willow"]
Pontosan mhova kéne másolni a kiszolgálon a kulcs fáljt ill felsorolni azokat a kulcsfáljokat akik bejöhetnek.

ezt felmásolod a szerverre a $HOME/.ssh/authorized_keys fájba, ha van már ilyen, nem felülírod, hanem belemásolod.

[quote:e99d1e0c57="Willow"]
Ezeket nem tudják megszerezni?

mit? kicsoda?

a.

[quote:4760ecb28d="Luckyboy"]Szóval szerverre kellene nekem log analyzer, ami syslog meg auth logból kiszűri a gyanús, szokatlan bejegyzéseket, és mondjuk napi 1-2 alkalommal összesítve elküldni nekem mailben.

Én valami logcheck nevu programot (csomagot) használok. Defaultban ismer háromféle szintű szűrést, amik közül telepítéskor választani kell, és utána még mindegyik finomhangolható, hogy mire vagy kiváncsi.
Én a paranoiddal indultam, és onnan dobáltam ki olyan "riasztásokat", amik nem érdekeltek. :wink:
D.

a portsentry a te barátod

Azert OpenBSD-t tuzfalnak, mert ha jol emlekszek 8 ev alatt csupan egy tavolrol kihasznalhato hibat talaltak benne...

És mi van, ha OpenBSD-Linux helyett egy DSL routert használok erre a célra? Tud valaki negatívumot evvel kapcsolatban?

OFF
Mellesleg 8 óra 55 lenne a pontos idő?
Meg úgy tünik a hozzászólások száma sem növekszik...

Meg a tiger.

[quote:ff21590128="badur"]
Tegyük fel hogy a rendszerbe betörtek, az óvintézkedések ellenére. :cry:
A betöréseket mivel lehet érzékelni, (azon kívül hogy nem megy a gép stb.).

Jol konfigolt rendszernel a tavoli szerverre kuldott logokbol ;-)
Ha kivancsi vagy, hogy mi tortent, akkor tobb lehetoseged is van, az idodtol fugg, hogy mit erdemes tenni. Komolyabb vizgalodasnal vinyo kiszerel, image keszit, aztan johetnek a 'nagyagyuk', mint pl a Coroner's Toolkit. Ha nem lehet leallitani a gepet, akkor is erdemes vegignezni legalabb valami rootkit keresovel, meg figyelni a halozati forgalmat egy masik geprol.

[quote:ff21590128="badur"]milyen csapdákat lehet
felállítani erre az esetre? Automatikus dolgokra gondolok, egyáltalán léteznek ilyen progik?

Ezt felejtsd el. Ha van egy altalanos celu pl. webszervered, akkor ott ne allits csapdakat, ne trukkozz, hanem vedd annyira szorosra a vedelmet, amennyire az alkalmazasod engedi, patch-eld a gepet rendesen, es figyeld a logokat, szoval a szokasos.
A 'csapdaallitashoz' nagyon esznel kell lenni, dedikalt geppel, a tobbitol elszeparalt halozattal, stb. Ezzel az foglalkozzon, akit ezert fizetnek vagy ez a hobbija.

[quote:ff21590128="badur"]Megelőzésre/érzékelésle pl portscan figyelő démon érzékel valahonnan scannelést azt az ipt
automatikusan droppolja...

Persze, csak akkor van gond, ha a tamado unalombol hamisitott IP-krol szivatja a geped. Mondjuk az eppen aktualis otthoni IP-drol.

netchan

Szia!

[quote:7b102b2ecf="badur"]
Tegyük fel hogy a rendszerbe betörtek, az óvintézkedések ellenére. :cry:
A betöréseket mivel lehet érzékelni, (azon kívül hogy nem megy a gép stb.).

Aki jól csinálja a betörést az legtöbbször csak a háttérben figyel és ugró deszkának használja a gépet.

[quote:7b102b2ecf="badur"]
Automatikus dolgokra gondolok, egyáltalán léteznek ilyen progik?

Javaslom megtekintésre a
tripwire programot (A file and directory integrity checker)
Ha bejutott akkor valamilyen módon szeretne újra vissza jönni és ekkor rak fel különböző hátsó kapukat. Ezeket egész jól ki lehet szűrni a fenti programmal.

Üdv
kagy

Most otthoni gépekről volt szó, BIXben álldogáló kiszolgálókról, vagy is-is?
Valaki esetleg leírná, nem feltétlenül részletesen, inkább csak az elv érdekel, hogy hogyan tudnak betörni egy gépre? Nekem itthon van egy kis linuxos tűzfalam, mögötte egy webszerver, hogyan tudnak bejönni? Először szétszedik a tűzfalat, vagy csak a nyitott portokon nyúlkálnak ki/be?
Nemértem... :(

Egy regebbi kerdesre, miszerint miert jo, ha kulon gepen van a tuzfal, mint a szerver:
Tfh. a szerveren vmi rootkent futo cucc bugjat kihasznalva root-kent elindit vmi kodot a betoro.
Ha ez a gep ugyanaz, mint a tuzfal, akkor innentol a teljes (eddig) vedett belso halo nyitva van kifele, es meg a logokat is lezuzhatja maga utan.
Ha kulon gepen vannak, akkor:
- a halo kintrol tovabbra is zart, bar mar van egy gepe belul, de az sem biztos, hogy mindent lat belul
- bent ugyan fut a kodja, de shellje meg nincs, azt meg at kell hackelnie a tuzfalon
- a tuzfal-logod megmarad, es megnezheted, hogy hogy is jott be
- a tuzfal bentrol kifele is szur

Pelda: a szerveren van proxy meg smtp meg pop3s, a rendszer:

szerver ----------+
belso halo ---- tuzfal ---- vilag

A csomagszuro:
vilag->szerver: smtp, pop3s
belso halo->szerver: proxy, smtp, pop3s
vilag->belso, belso->vilag: semmi
szerver->vilag: proxy, http[s], smtp
szerver->belso halo: _semmi_
Ha bejutott vki a szerverre, es szeretne pl. kinyitni egy portot, ahol bejohet, hat nem fog menni. Ha a szerverrol kapcsolodna 'haza', na az sem:).
Persze ha otthon felhuz egy httptunnel-t, es megy haza http-n, akkor kijut, de ez azert macerasabb, mint nyitni egy socketet es inditani ra egy shellt.
Aztan persze az igazan paranoidok meg a tuzfal logjat is egyiranyu soros kabelen kuldik kulon gepre :)

[quote:5f2f10e96e="gsimon"]Aztan persze az igazan paranoidok meg a tuzfal logjat is egyiranyu soros kabelen kuldik kulon gepre :)

Az etherenet kabel is egyiranyusithato. Azt nem tudom, hogy a syslog atmegy-e rajta, de detektalhatatlan sniffert/IDS-t lehet igy telepiteni.

Meg a kulon tuzfal / szerver temaban: Nalunk ugy allitottam be a cuccokat, hogy alapbol minden service (a tuzfalon az ssh is) csak a 127.0.0.1-re bindol. Ezekre es a tuzfal mogotti gepek szervizeire is a tuzfal konfigoban elhelyezett redirect-eken keresztul jut el a csomag. Ennek az a kovetkezmenye, hogyha a tuzfal valamilyen okbol kifolyolag leall, akkor sem ot, sem a mogotte levo gepeket nem lehet halozaton keresztul elerni. Direkt betarcsazas, illetve soros port jatszik be ilyenkor.

Persze merlegelni kell, a fenti setup nyilvan nem jo egy olyan kornyezetbe, ahol a folyamatos mukodes fontosabb, mint az adatok vedelme vagy ugy van megoldva a dolog, hogy az adatokhoz a root sem tud hozzaferni, stb.

Hy!

Ezt az 'rkhuntert' hol találom meg honnan tudom leszedni mert google csak a hozzászólásaitokat dobja ki ha rákeresek a rkhuntert szóra.

A másik meg azlenne he netálntán talált valai MAgyar leírást az uml-hez és megosztáná velem megköszönném.

BYe

[quote:63a1c77ee0="andrej_"][quote:63a1c77ee0="szucs_t"]Rootkit programok ellen hogan lehet védekezni? Imseritek az "eliteazazel" elnevezésű programot? Van tapasztalatotok arról, hogy ha a wwwrun felhasználóval végzi egy betörő a szemétségeit, akkor mi lehet a konkrét biztonsági rés? Hogyan mászhat be valaki egyáltalán wwwrun-nal? Ha a shellt-false-ra állítom, az jó megoldás?

Köszönöm!

Neha egy checkrootkit es PHP eseten Safe Mode On es openbasedir, azt probalkozzon. Ha CGI van akkor pedig csak olyan scriptre szaad futasi jogot adni, amit nagyjabol lattal. Bemaszni egyebkent apache hibaval tud vagy PHP-val. Egyebkent milyen oprencer ez?

Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

[quote:bd1bc18135="asd"][quote:bd1bc18135="szucs_t"]Alapban mi mást használna? Az egész partíciót?

Az is le van oda irva, hogy igen.
RTFM

Kösz!

[quote:54f572b156="norbert79"][quote:54f572b156="norbert79"]Sziasztok!

Szeretném a rendszerem kicsit biztonságosabbá tenni, illetve egy két más gépet is, amivel én dolgozom, ezért nemrég kicsit utánajártam a biztonsági kérdéseknek (s rájöttem ez is egy akkora téma, hogy évek kellenének, hogy elegendő tudást szedjek össze ahhoz, hogy közepes szintű tudásnak büszkélkedhetnék), s kutatásom közben találtam egy PHLAK-nak nevezett disztribúciót, ami egy komplett CD-nyi anyag különböző eszközökből összerakva: scanner, sniffer, program ellenőrző, stb.
Első pillantásra egész komolynak tűnik, s remélem nem az a fajta kezdő-cracker gyerekek eszközének készült, bár még nem sok időm volt alaposabban utánaolvasni. Ezért is fordulok a kérdéssel felétek:
- Ki ismeri ezt a eszközt?
- Ki használta már?
- Kinek milyen tapasztalata van vele?
- Mennyire segít egy saját gép biztonságosabbá tételéhez (mert erre kellene)?
- Mennyire megbízható az eszköz? (Úgy értve tényleg csak én használom, s más nem jön be kívülről, nincsen benne e Rootkit, vagy hasonló...)

Látom nem sokakat mozgatott meg a téma. Tényleg senki nem ismeri?

Hogy írtad, letöltöttem a CD-t. Nekem igazából csak a rajta lévő dokumentumok keltették fel a figyelmemet.

[quote:47d9ad8232="m4ki"]Hy!

Ezt az 'rkhuntert' hol találom meg honnan tudom leszedni mert google csak a hozzászólásaitokat dobja ki ha rákeresek a rkhuntert szóra.

A másik meg azlenne he netálntán talált valai MAgyar leírást az uml-hez és megosztáná velem megköszönném.

BYe

Hi!

Rootkit Hunter project leírása és letöltés (legalul):

http://www.rootkit.nl/projects/rootkit_hunter.html

[quote:d5b97a0330="szucs_t"]Linux oprendszer, 1.3.12-es Apache-csal, és PHP 5-tel. Mi az a "Safe Mode On" és az "openbasedir"?

Javaslom nezegesd kicsit a php.ini fileodat...

[quote:eafceb0cbf="norcrys"]
A tűzfalat elsősorban azért kell külön gépre tenni az én látásmódom szerint, mert a funkciókat el kell szeparálni. Ha egy gépen van a webkiszolgáló és a tűzfal, az nem tűnik egy túl biztonságos rendszernek. Legyen egy "belőtt" gép, amin semmilyen szolgáltatás nem fut, csak szűrést és átirányítást végez.

Van egy webkiszolgáló, amin alapból mindent tiltunk, csak
az ssh-t és a http-t engedélyezzük (iptables).
Miért lesz biztonságosabb, ha elé betszünk egy OpenBSD tűzfalat,
amin ugyanezeket engedjük csak át?

Tudsz mondani rá példát, hogy milyen esetekben nyújt
ez plusz védelmet?
(Gondolkodtam rajta, és oda jutottam, hogy akár a http szerver,
akár az ssh lyukas, mindenképpen hozzáférnek a kiszolgálóhoz,
hiszen a tűzfalnak ezeket át kell engednie...)

[quote:ddca35abda="norcrys"]Mintha keveseket érdekelne ez a téma... Kár, mert látok itt egynéhány olyan embert, akitől lehet tanulni.

Ha önző lennék, most azt mondhatnám, hogy így legalább
több türelmük lesz a hozzám hasonló kezdőkhöz... :D

De persze nem vagyok önző... :D

Jut még eszembe... Ha vkit kicsit jobban érdekel, hogy mi is folyik a szervere portjain valójában, az vessen egy pillantást az IPTraf-ra:

http://freshmeat.net/projects/iptraf/

Ez a progi sokféle realtime monitorozást és logolást is lehetővé tesz, rengeteg féle szűrést, statisztikázást és analízist ismer, amelyeket nagyon sok helyen lehet hasznosítani.

Szerintem egy szervergépen ez must-have, de nem árt desktopra sem...

[quote:1dd54e3172="norcrys"]...A csomagszűrés pedig nem 100%-os megoldás, mégha az iptables képes állapotkövetésre is.

Mégha ???
Annélkül nem is megy!!!

Ajánlott videó:
http://vod.niif.hu/ipszilon1/

Egyébként 49,5%
A másik 49,5% a tartalomszűrés

Csak akkor, ha van rendszeres frissítés.

RKHunterrel kapcsolatban jótanács:

Ha olyan disztrót használsz, amiben az alkalmazások verziószámát pl. automatikus update idején nem szokták változtatni, hanem a javításokat SK fordítják bele a progikba (pl. Mandrake) akkor az RKHunter gyakran jelez olyan MD5 eltéréseket, amelyek valójában nem veszélyesek, hanem a patch részei. Ilyenkor küldjetek nyugodtan visszajelzést a készítőnek és általában 24 órán belül megjelenik az update az RKHUnterhez.

Még valami: Ugyancsak a sajátos frissítési módokból (verziók nem változnak) adódóan Mandrake alatt rendszeresen Vulnerable-nek jelez egyébként felpatchelt service-eket is, pl. Proftpd, stb. Ez egyelőre nem tekintendő hibának a programban, és a fejlesztő srác megígérte, hogy hamarosan számításba fogja tudni venni ezt a helyzetet is a progi.

En csak egy lelkes amator vagyok, ha hulyeseget irok kerlek nezzetek el es javitsatok ki, nekem is van mit tanulnom.

Szerintem a grsec-sem rosz, igaz nem fog meg mindent de sokat er (van benne pax is ami szinten er valamit de nem minden) http://grsecurity.net
Ami fontos az a biztonsagi figyelmeztetesek alapos attekintese, erintett-e a geped.
Debian-bol peldaul erdemes stable-t hasznalni es rendszeresen frissiteni.
Szerintem a kiszolgalogepre erdemes tuzfalat rakni, meg akkor is ha van elotte egy csak csomag es tartalomszurest vegzo szerver. Mert mi van akkor ha van 20 szervered? Mindegyik ele raksz egy tuzfalat, vagy csinalsz egy DMZ-t, es ha a tuzfaladat megnyomtak (mondjuk egy kernel bug miatt) akkor az osszes kiszolgalo teljesen vettelen (persze ha agepeken is ugyanaz a kernel es tuzfal fut akkor semmit sem er az egesz). Linux alatt szerintem nem egyenlore nem celszeru 2.6.x-es kernel hasznalni (es ha igazak a hirek, hogy nem lesz fejlesztoi fa egydarabig, hanem a stabil agba esnek be az uj patch-ek, akkor nem is szabad valtani). 2.4-es teljesen jol mukodik, csak mindig a legfrissebbet kell feltenni (kis rahagyassal ha az elozoben nem volt kritikus hiba)
Valmi ACL kezelo moka es CHROOT mindenkeppen jo, es az, hogy az egyseguserek ne tudjak olvasni es/vagy listazni azokat a fajlokat amihez kozuk sincs.
Valamint van lehetoseg "hazudozni" a futtatott OS-t illetoen, ez sem rosz mert ha a gepedrol azt hiszik, hogy Winfos, vagy BSD de kozben Linux, akkor az azokhoz keszult mokakkal probalkoznak eloszor es van idod.
Ja es meg valami: azokat a szolgaltatasokat amiket nem hasznalsz mindenkeppel el kell tavolitani vagy legalabb leallitani, semmi olyan ne legyen a szerveren ami nem kell a mukodeshez (GCC-se kell elvegre lehet mashol is kernelt forditani, de foleg a setuid-es programok a gazosak).
Amugy apache is futhat root jog nelkul 1024-es port felett, legfeljebb iptables-sel at kell zavarni a forgalmat oda

Ha abszolute biztonsagra torekszel akkor a gepet a kertedben egy 100 meter melyyen elasva 20 meter vastag betonba egyazva aram es halozat nelkul tartod. Ez az abszolut (na jo ez is csak 99.9%) biztonsag!

Amugy az otthoni tuzfalam egy grsec-es kernel futtat, es egy trivialis tuzfal van rajta megse nyomtak fel (pedig lehetne).

Udv, Zsalab!

[quote:3e0148c532="Lestat"]Azert OpenBSD-t tuzfalnak, mert ha jol emlekszek 8 ev alatt csupan egy tavolrol kihasznalhato hibat talaltak benne...

1. A tűzfal nálam egy végletekig lecsupaszított rendszer packetfilterrel és proxyval.
2. A szerver nálam az szükséges adminisztratív és szerverfunkciókra korlátozott rendszer jóval több futó programmal, mint egy tűzfal.

quote+1.+2. ----> a kevés kihasználható hiba a szervernél jóval többet jelent mint a tűzfalnál, persze tűzfalnál is előnyös, de szervernél előnyösebb!

rsbac kernel a debian serveren minden szolgáltatás külön jailben, iptables rendesen belőve, usereknek nincs shell, csak ftp-n tölthetik fel a cuccot, a rendszer elé pedig egy openbsd tűzfal. Ezzel elertem a minnimum biztonsagot....

Bocsanat az elozo nagyon hosszu lett, de kimaradt az otthoni gepemmel kapcsolatban, az hogy van egy fontos tenyezo (egy tanult baratomtol tudom):
A biztonsagnak, a hasznalhatosagnak, es a raforditott eroforrasoknak egyensulyban kell lennie egymassal es a vedett adatok ertekevel.

[quote:4c8ab65819="Darkfish"]És mi van, ha OpenBSD-Linux helyett egy DSL routert használok erre a célra? Tud valaki negatívumot evvel kapcsolatban?

Igen, cisco forráskódok szivárogtak ki.
Open source rendszerek hibáit jóval hamarabb javítják,
mint az ilyen kvázi opensource rendszerekét.

[quote:392e7322ae="Dwarf"][quote:392e7322ae="norcrys"]
A tűzfalat elsősorban azért kell külön gépre tenni az én látásmódom szerint, mert a funkciókat el kell szeparálni. Ha egy gépen van a webkiszolgáló és a tűzfal, az nem tűnik egy túl biztonságos rendszernek. Legyen egy "belőtt" gép, amin semmilyen szolgáltatás nem fut, csak szűrést és átirányítást végez.

Van egy webkiszolgáló, amin alapból mindent tiltunk, csak
az ssh-t és a http-t engedélyezzük (iptables).
Miért lesz biztonságosabb, ha elé betszünk egy OpenBSD tűzfalat,
amin ugyanezeket engedjük csak át?

Tudsz mondani rá példát, hogy milyen esetekben nyújt
ez plusz védelmet?
(Gondolkodtam rajta, és oda jutottam, hogy akár a http szerver,
akár az ssh lyukas, mindenképpen hozzáférnek a kiszolgálóhoz,
hiszen a tűzfalnak ezeket át kell engednie...)

"...hiszen a tűzfalnak ezeket át kell engednie..."
Nem, egy tűzfal akkor igazán tűzfal, ha proxy is üzemel rajt, különben csupán csomagszűrő. A proxyval viszont tartalomszűrő is lehet.

Ha jól van konfigurálva egy proxy / packetfilter az esetleges még nem ismert lyukak kihasználása ellen is védelmet nyújthat a tartalomszűrés által, az állapotkövetéssel DOS ellen mindenkép.

Ha az iptables rendesen be van lőve, akkor
miért kell elé OpenBSD tűzfal?

Ti mit értetek az alatt hogy "az iptables rendesen be van lőve"?
Hogy minden ki/bemenő csomagot eldobtok, vagy egy kicsit lazább azért?

[quote:912bc64089="ishida"][quote:912bc64089="Lestat"]Azert OpenBSD-t tuzfalnak, mert ha jol emlekszek 8 ev alatt csupan egy tavolrol kihasznalhato hibat talaltak benne...

A default installban. Ez mondjuk nem mindegy, habár a kernelt jellemzi, hisz az mindig benne van alapban :). Persze nem tudom, hogy a Linux kernelben mennyi távolról kihasználható hiba volt az elmúlt időben.
Az OBSD bizonyos dolgokban nagyon jó kis rendszer, a biztonsági policyje is sokkal jobb az átlagnál. Tetszik, hogy Theo ennyire ragaszkodik hozzá (meg a licenchez is) amivel persze elég sok kellemetlenséget tud szerezni magának is meg másoknak is, de legalább következetes. Ezért jó tűzfalnak (is). Persze elég sok dologban meglehetősen gyatra, de persze kinek mire van szüksége.

Attól, mert a kernel benne van a default install-ban, nem őt jellemzi a fenti sor, hanem még az általuk átírt apache-ot is többek között.

Miben gyatra, neked mik az igényeid?
Ha nem az a célja egy distribnek,
mint az iránta érdeklődő felhasználónak, attól még nem a distrib a gyatra.

[quote:f5e15cba0b="badur"]Nem akartam új topikot nyitni, csak egy kicsit csavarok rajta...

Tegyük fel hogy a rendszerbe betörtek, az óvintézkedések ellenére. :cry:
A betöréseket mivel lehet érzékelni, (azon kívül hogy nem megy a gép stb.). milyen csapdákat lehet
felállítani erre az esetre? Automatikus dolgokra gondolok, egyáltalán léteznek ilyen progik?

Megelőzésre/érzékelésle pl portscan figyelő démon érzékel valahonnan scannelést azt az ipt
automatikusan droppolja...

Üdv: badur

Offsite log (syslog-ng) nagyon hatásos tud lenni,
pláne LPT mátrix nyomtatón,
de vannak akik sms-küldenek maguknak
kritikus folyamatoknál pl. root bejelentkezik

Kicsit visszakanyarodnék az eredeti kérdéshez, az általános biztonsághoz. A kérdésem alapja az, hogy beüzemeltünk egy szervert egy szolgáltatónál, amolyan általános mindenes gépet, fut rajta http, mail, ftp és pár egyéb cucc. A gépet ssh-n át is többen használják. Szeretnék valami jobb biztonsági szintet elérni a gépen (de azért nem paranoid szintet), hogy ne kelljen félni attól, hogy akár egy kissrác is 5 perc alatt megtöri, mert van a gépen több fontos adat is. Eddig annyit tettem, hogy raktam egy 2.6.7-et grsec-el, jelenleg low security levellel, illetve a tűzfalat beállítottam a legjobb tudásom szerint (bár nem jelenti azt, hogy tökéletes lett :wink: ). Ja, a rendszer egy Debian Sarge.
Szóval a kérdés az, mit érdemes még megcsinálni, hogy kintről védve legyen a gép, illetve a kedves local userek se tudjanak könnyen kárt tenni a rendszerben. Chroot-ról linkek és tanácsok jöhetnek! Köszi!

Amugy az otthoni tuzfalam egy grsec-es kernel futtat, es egy trivialis tuzfal van rajta megse nyomtak fel (pedig lehetne).

Akkor minek a grsec? Hiába van jó security patch, a leggyengébb láncszem a probléma. És honnan tudod, hogy nem járt senki nálad? Csendben?

Es ebben az esetbe mi a gyenge lancszem? Gondolom a trivialis tuzfalra gondolsz, ami nem azt jelenti, hogy iptables -F.

Amugy mindig toltok egy kis idot a gepen, hogy informalodjak mi a helyzet.
Abban igazad van, hogy nem tudhatom biztosan fel lett-e torve, de igazabol nem is erdekel!!! Ugyanis semmi nincs a gepen, ha meg valahova betornek a gepemrol es kiderul, akkor majd megtalaljak, hogy az is fel lett torve.

Policy-ba foglaljuk, hogy minket nem hekkelnek meg :D
http://www.netacademia.net/blogspace/petert/#001499

Kicsit felhozom újra a topicot, illetve egy korábbi kérdésem. Szóval szerverre kellene nekem log analyzer, ami syslog meg auth logból kiszűri a gyanús, szokatlan bejegyzéseket, és mondjuk napi 1-2 alkalommal összesítve elküldni nekem mailben.
Másik kérdés a chroot köré kapcsolódik, hogy kellenének leírások különböző programok (elsősorban bind, apache 1.3, mysql) chrootolásáról. Neten találtam többet is, de egyikkel sem sikerült rendesen megcsinálni. A rendszer debian sarge.

[quote:34d6b54700="netchan"]Policy-ba foglaljuk, hogy minket nem hekkelnek meg :D
http://www.netacademia.net/blogspace/petert/#001499

:lol: Süt, mint a turbólézer... :lol:

[quote:354b477297="norcrys"].../boot, /bin, /usr read-only-ként való befűzése...

Yes, Yes.

A /boot-ot nem is kell felfűzni az fstabban, mivel csak a boot-kor kell.
Meg aztán nem kell elfelejteni a noexec, dodev kapcsolókat sem.

Legfőképpen a /var/www -n, mert azt is külön kell szedni :-)
A /var/mail -el vagy a /var/spool al együtt.

[quote:c634f25aab="norcrys"][quote:c634f25aab="Luckyboy"]Kicsit visszakanyarodnék az eredeti kérdéshez, az általános biztonsághoz. A kérdésem alapja az, hogy beüzemeltünk egy szervert egy szolgáltatónál, amolyan általános mindenes gépet, fut rajta http, mail, ftp és pár egyéb cucc. A gépet ssh-n át is többen használják. Szeretnék valami jobb biztonsági szintet elérni a gépen (de azért nem paranoid szintet), hogy ne kelljen félni attól, hogy akár egy kissrác is 5 perc alatt megtöri, mert van a gépen több fontos adat is. Eddig annyit tettem, hogy raktam egy 2.6.7-et grsec-el, jelenleg low security levellel, illetve a tűzfalat beállítottam a legjobb tudásom szerint (bár nem jelenti azt, hogy tökéletes lett :wink: ). Ja, a rendszer egy Debian Sarge.
Szóval a kérdés az, mit érdemes még megcsinálni, hogy kintről védve legyen a gép, illetve a kedves local userek se tudjanak könnyen kárt tenni a rendszerben. Chroot-ról linkek és tanácsok jöhetnek! Köszi!

A proxy configra kellene még ügyelni, illetve hogy egyáltalán fusson a csomagszűrés mellett proxy is. A felhasználók chroot-olt környezetbe érkezennek ssh-val. Minden egyéb usernek /bin/false megadása. Integritás ellenőrzés. Root-ként való bejelentkezés tiltása. /boot, /bin, /usr read-only-ként való befűzése. FTP, mail letiltása, ha kell, akkor ezeket belső hálóra tedd nagyon komoly védelem mellett. CGI könyvtár rendszeres ellenőrzése. Log analizáló progi.

A root tiltása megvan, /bin/false szintén. Viszont azt hiszem te úgy gondolod, hogy a szerver egy háló előtt van. Szóval pontosítok, ez a gép egy serverhostingos cégnél van, és ő kell hogy kiszolgáljon pár local usert, és a remote usereket is (local user = van shellje). Sajnos mail-t meg ftp-t nem tudom tiltani, de ssl-es ftp-n gondolkodom.
Chroot-olt ssh-t nézegettem, olvastam a hup-os topicokat is erről, de igazán nem tudtam kiszűrni egy igazán jó megoldást. Erre vmi javaslat, pl te mit használsz?
Integritás ellenőrzésre, illetve log analizálásra szintén várok javaslatokat, kinek mi jött eddig be. Log analizálásra olyan lenne a jó, ami mailben mondjuk naponta küld egy reportot.
Apache-ot igyekeszem a lehető legjobban beszabályozni, php-vel egyetemben. Valakinek volt szerencséje használni 1.3-as apachehoz a chroot modult?

[quote:cf44ff88b9="Dwarf"]Ha az iptables rendesen be van lőve, akkor
miért kell elé OpenBSD tűzfal?

Tudod az üldözési mániám :D
Mondjuk még nem csináltam meg, de most készülök :)
Az szerintem nem baj, ha két helyen is van csomagszűrés, mondjuk ha megcsinálom, akkor lehet hogy majd más véleményem lesz róla.... :)

- W^X
- ProPolice
- systrace
- privilege separation
- chroot
- Es ami a legfontosabb, igényes software használata. Jó és megbítható kód. ha ez nincs
ejlen akkor auditálás.

Ezt nagyon érdemes elolvasnotok,
ha számítógépes biztonsággal akartok foglalkozni:
Nekem még nem sikerült a végére érni annyira eszenciális összefoglaló:

http://www.zpok.hu/biztkomm/

Maholnap csinálok ebből egy részletesebbet is,
de itt van egykét főbb irányelv,
amit itt a HUP-on meg az említett doksiban szedtem össze:

1. Fizikai védelem
2. Többszintű, rendezett, védeni való adatstruktúra
3. Biztonságos rendszer:
a) Bizt. distrib v. ( (kernel patch & UML,...) v. Jail,...) +
b) Firewall & proxy +
c) Töbszintű, biztonságos jelszavak.
d) Bizt. kapcsolatok (SSL, SSH, ...) & Bizt. fájlok (PGP, GPG, ...)
e) Offsite backup & Offsite log
f) Interaktivitás: Cron – hour update & Alert manager

Kérem javítsatok ki, ha nincs igazam!

Integritas ellenorzesere en egy Integrit nevu progit hasznalok, ahol az adatbazis egy kulon gepen van amit Coda segitsegevel erek el, igy ha a gepet megtorik nem tudjak letorolni v. modositani az adatbazist ergo konnyebb kideriteni a behatolas mikentjet.

[quote:85d5784b6e="norcrys"]Az "átjut" azért elég tág fogalom. Ha a root jogosultságot szerzi meg, akkor csak egy rsbac szintű védelem segít. nem feltétlen erről van szó, hanem pl. olyan csomagokat kapsz be, amiktől kissé elszáll a szervered vagy kihasználják a rosszul beállított jogosultsági rendszert az ftp-n (pl. tudnak futtatni), és még hibás szoftver sem kell.

Kicsit még mindig homályos...
Hiába van az ftp jól vagy rosszul konfigurálva, azt ugyanúgy át kell engedni előtte a tűzfalon, ha használni is akarják,
tehát megint mintha ott se lenne az a plusz egy gép előtte.

Olyan csomagok alatt pedig mit értesz, amitől elszáll a szerver?

[quote:1e2adfdbfb="zsalab"]akkor majd megtalaljak, hogy az is fel lett torve.

Ezzel csak az a gond, hogy ha tiédről törlik a logokat, vagy a logból a bejegyzéseket... Akkor kapásból te vagy a gyanusított.

[quote:9700caf75c="Dwarf"]

Tudsz mondani rá példát, hogy milyen esetekben nyújt
ez plusz védelmet?
(Gondolkodtam rajta, és oda jutottam, hogy akár a http szerver,
akár az ssh lyukas, mindenképpen hozzáférnek a kiszolgálóhoz,
hiszen a tűzfalnak ezeket át kell engednie...)

Pl ha a két (vagy több) gépet több ember adminolja. Van egy security officer, õ tekergeti a tûzfalat, stb., egy másik csapat meg mondjuk telepít egy webszervert. A tûzfalas arc nem akarja, hogy a (mondjuk nem teljesen expert) webszerveres fiúk mindenféle szolgáltatásokat nyissanak, ezért õ ezt explicite tudja tiltani. Vagyis õ az erõsebb. Ha még a webszerverben (pl apache) sem bízik, akkor elé tesz valami proxy-t, etc.