Szerver biztonságossá tétele

Linux-kezdő

Hali!

Tegyük fel, hogy kezdő Linux rendszergizda vagyok. Ezenkívül még
valamennyire értelmes is, meg még angolul is tudok, de kezdő.

Szakmailag kb. akkor leszek sikeres, ha az általam telepített/üzemeltetett szerverek
-nem pusztulnak meg a terhelés alatt, legalábbis nehezen
(a hw-ból kihozom a maximumot, tehát úgy állítom be, hogy a hw legyen a
szűk keresztmetszet, ne a szoftveres konfiguráció, és amennyire lehet,
elkerülöm a túlterhelés lehetőségét)
-nehezen törhetőek fel.
(a nehezen kb. ezt akarja jelenteni: feltételezve, hogy a gép fizikailag
biztonságban van, a gép "ellenáll" az elterjedt automatikus támadásoknak,
és nem egy script kiddie fogja felnyomni a gépet)

Mivel "howto"-kat fordítani lassú és időigényes, (és még el is avulnak :) )
ezért kéne egy "must read" linklistát összerakni, ami megmondaná,
hogy milyen projektekkel kell feltétlenül megismerkednie egy kezdőnek. (pl. nekem. :) )
Meg talán nem kezdő embereknek is hasznos lehet.

Szóval az én listám, ami most így hirtelen eszembe jut:
http://www.fail2ban.org/
http://grsecurity.net/
http://www.gentoo.org/proj/en/hardened/
http://rkhunter.sourceforge.net/
http://en.wikipedia.org/wiki/Chkrootkit
http://sourceforge.net/projects/tripwire/

Érdemes ismerni:
http://en.wikipedia.org/wiki/FastCGI
http://www.snort.org/
http://www.splunk.com/
http://debian-handbook.info/

[Szerk 2012-02-27]
Még néhány link. (zárójelben a júzer, aki ajánlotta)
http://www.debian.org/doc/manuals/securing-debian-howto/ (neutrino)
http://www.modsecurity.org/ (asci)
http://www.linuxjournal.com/article/4751 (Kayapo - portsentry)
http://sourceforge.net/projects/snoopylogger/ (Kayapo)
http://en.wikipedia.org/wiki/Selinux (csuhi)
http://sys-admin.hu/cikkek/20070617/vedd_magad_az_selinux_1 (csuhi)
http://sys-admin.hu/cikkek/20070617/vedd_magad_az_selinux_2 (csuhi)
http://www.freetechbooks.com/efiles/selinuxnotebook/The_SELinux_Noteboo… (csuhi)
http://www.openna.com/pdfs/Securing-Optimizing-Linux-The-Hacking-Soluti… (zeller)
http://haproxy.1wt.eu/ (tbs)
http://www.stunnel.org/ (tbs)
http://linux-vserver.org/ (tbs)
http://www.gentoo.org/proj/en/hardened/primer.xml (Dwokfur)

  • 32069 megtekintés

( janoszen v | 2012. 02. 22., sze – 09:35 )

Legtobbszor a szerverek szintjen alapveto hianyossagok vannak:

  • Minden szolgaltatas csak azokon az IP cimen figyeljen, amin feltetlenul kell.
  • Minden alkalmazas fusson sajat usernev alatt.
  • Ha webes szarokat uzemeltetsz, minden alkalmazas fusson sajat usernev alatt.
  • Ellenorizd a permissionoket a fajlokon, kulonosen azokon, amik erzekeny adatokat tartalmaznak.
  • Implementalj kulcsos belepest SSH-n, opcionalisan a jelszavas melle. Tedd at az SSH-t masik portra.
  • Ha lehet, PHP-hoz hasznalj FastCGI-t, ne mod_php-val uzemeltesd.
  • Konfiguralj tuzfalat, ha egy mod van ra, akkor userenkent korlatozd a kapcsolatokat. Ha nem ertesz a tuzfalakhoz, hasznalj keszen megirtat.
  • Ha van a gepen IPv6-os modul a kernelben, legyel szives IPv6-os tuzfalat confolni! Nem tudhatod, hogy mikor kapcsolja be a szerverkozpont az IPv6-ot es akkor jol nezel ki.

Akinek meg eszebe jut valami, egeszitse ki.

A FastCGI nyújt bármilyen plusz biztonságot, ha a gépen csak egyetlen site-ot tartok, és az interface-re, amin az Apache hallgat, egy fizikailag is külön gépen futó tűzfal csak a 80-as és 443-as portokat engedi át (kifelé pedig a netfilter a válaszokon kívül semmit)?

- Ha mást is muszáj beengedned a severre, lehetőleg kapcsold ki a jelszavas belépést ssh -n keresztül, használj csak kulcsot (ez persze megérdemelne egy hitvitát).
- Ne tedd az sshd -t másik portra, portscanel úgy is kideríthető, mi figyel ott (na ez is megérdemel egy hitvitát)
- Janoszen elfelejtette a portsentry -t, gondold meg az alkalmazását, na és ha használod akkor lehet érdemes bűvészkedni az ssh portal.
- Ha mást is be kell engedni a gépre ssh-n, használj snoopiloggert és az sftpd -t is debug módban futtasd.
- Az auth és a tűzfal logjaidat tartsd titkosított formában (syslog-ng)
- Központosítsd a logjaidat.
- Ha egy - két gépet üzemeltetsz, nem érdemes, de kb. fél tucattól, használj IDS-t (pl.: snort)
- A logwatch rossz ötlet...
- MONITOROZZ MONITOROZZ MONITOROZZ
- Irtsd ki a fals pozitív riasztásokat a monitoring rendszeredből
- Legyen a serverekben táv management modul (az ipkonzol, nem táv management modul!!!)
Na a failtoban is megérne egy hitvitát

----
올드보이
http://molnaristvan.eu/

Szerintem, emögött emberi tényező bújik meg. Ha kapsz naponta egy halom levelet, hogy mi történt a logokban, azt mérsékelten szokta átnézni az ember. Legfőképpen azért, mert repetitív meló és egy rakás olyan szoftver van, aminek az istennek nem lehet megmondani, mit logoljon és mit ne. Innentől kezdve pedig elég aprólékos akár a logwatchot, akár a syslogot belőni, hogy azt kapjad, ami tényleg fontos.

A másik tényező pedig az, hogy a fontos eventekről legtöbb esetben nem egy nap múlva akarsz tudni, hanem lehetőleg hamarost méghozzá valami olyan dashboardon, ahol be tudod szerezni a géphez tartozó többi infót is.

Régi téma, de ha már feljött:
- logcheck szűrői jól konfolhatók, ignorálhatja, ami nem kell, ergo máris nincs egy valag levél
- az első pofon a legnagyobb, azaz az első futást követően már nem irdatlan gépzabálás, ha 5 percenként lefut. Relatíve gyorsan értesülhet hibákról ezáltal

Én használom normális monitoring mellett is, naponta 1-2 levél jön be max. Volt már olyan, hogy ezáltal értesültem olyan hibáról, ami ugyan nem eget rengető, kiszolgálást nem érintő, de hosszútávon azzá válhatott volna, így időben tudtam cselekedni.
Szóval ésszel és átgondoltan nem feltétlen elvetendő eszköz.

Figyelni kell arra, hogy ne fusson egymásra a két egymás utáni logcheck, mert abból ordenáré szívás kerekedhet. Hel bőven kell neki, úgyhogy azt is illik figyelni.
Ha új eszköz, vagy szoftver kerül a rendszerbe, illetve ha valaminek a naplózási beállításai változik (pl. loglevel), akkor tud meglepetést okozni. Anno pl. egy PIX-ASA csere után jelentkezett "némileg" több szűrt log...

A sec-et is érdemes megnézni, ha a naplók szemmel tartása a célunk.

Ha nincs sok log, akkor gyorsan végez. Ha valami para, vagy szándékos változás van, és emiatt megugrik a log mennyisége, akkor lehetnek cifra dolgok - saját tapasztalat: PIX-et cseréltek ASA-ra, és a tűzifa logja is a központi logszerverre ment... És persze a PIX-re gyúrt regexpek sz@rt sem értek az ASA logjánál. Elég "vicces" volt levél törzsébe belerottyantva többtíz megányi log.

+1
Én például ebből jöttem rá egy alkalommal, hogy egy egyébként is gyanúsan viselkedő üzemeltető kolléga végrehajtotta a chmod 0000 ~/.bash_history parancsot egy szép napon. Az ilyet nem fogod monitoringgal észrevenni, vagy legalábbis a szokásos rutinnal kevésbé. A többi mellékhatásával együtt lehet élni, csak meg kell érte dolgozni. Napi egy ilyen levelet szoktam beállítani magamnak.

Ezt nem érdemes a monitoringgal összekeverni, mert nem azonos a célja. A monitoring nagyjából realtime szól a beállított dolgokról. A logcheck/logwatch az általad beállított időközönként - ez lehet heti vagy havi egy alkalom is - összefoglalót küld a logokban található érdekességekről.

Linuxscripting

"Ne tedd az sshd -t másik portra, portscanel úgy is kideríthető, mi figyel ott (na ez is megérdemel egy hitvitát)"
Na, ezzel vitába szállnék.
Próbáld ki, hogy fent hagysz egy honeypot-ot default porton figyelő sshd-vel.
Néhány órán belül ráugranak a bot-ok, és elkezdenek szótárazni.
Ha csak annyit csinálsz, hogy az sshd-t átrakod egy high portra, gyakorlatilag a kutya sem fog rajta bepróbálkozni.
Természetesen ez nem biztonsági megoldás, de annak egy része mindenképpen. Főleg, hogy 2 sort kell módosítani mindössze hozzá a konfigban.

+1
celzott tamado ellen nyilvan nem ved, o ugyis meg fog probalni minden portot, de az automatizalt tamadasok, kiddie-k ellen hatekony, ok inkabb vegigscannelnek sokkal nagyobb tartomanyon nehany portot, mint ugyanannyi eroforrasbol 1 gepen minden portot.
ide kivankozik meg az, hogy amennyiben megteheted, erdemes tuzfalbol korlatozni, hogy honnan elerheto az ssh, illetve a http://en.wikipedia.org/wiki/Port_knocking is jo szolgalatot tud tenni az ssh brute-force elleni kuzdelemben, valamint ahogy mar fentebb irtak http://www.fail2ban.org

Tyrael

"Minden szolgaltatas csak azokon az IP cimen figyeljen, amin feltetlenul kell."

Ez feleslegesen sok adminisztrációt jelent és nem jelent biztonsági pluszt. Sok helyen erőltetik, de eléggé felesleges a dolog.

"Minden alkalmazas fusson sajat usernev alatt."

Ehhez egy jó ötlet a "dehát azt nem lehet, 1024 alatti portot használ" probléma kiváltására egy egyszerű NAT szabály iptables segítségével.

"Implementalj kulcsos belepest SSH-n, opcionalisan a jelszavas melle. Tedd at az SSH-t masik portra."

Az ssh áttétele más portra marhaság, semmivel nem lesz biztonságosabb tőle a szerver.

Az SSH-t azért szokták áttenni más portra, mert, amennyiben az a net felé elérhető, sokszor válhat brute force támadás áldozatául automata eszközök által. Ezek ugye alapvetően azt csinálják, hogy mennek végig az IP-ken és a 22-es, ha van 22-es port nyitva (és nem kulcs alapú auth), akkor nekilátnak bruteforce-olni. Persze megfelelően erős jelszavak mellett (és a root user ssh-n történő bejelentkezésének tiltása mellett) kevésbé kellemetlen, de telefossa a logot.
SSH témával kapcsolatban említeném azért a legutóbbi OpenSSL sebezhetőséget is. Mélyen nem mentem bele a dologba, de azt írták, hogy ssh (is) érintett, pubkey auth esetén. Akkor +1, hogy miért jó néha más portra tenni az ssh-t, mert, ha megint valami script pásztázni kezdi a netet és a 22-es portoknak elkezd exploitot tolni, lehet, hogy épp megmenekülsz, legalább addig, míg látod az advisory-t és gyorsan frissítesz.

A minden szolgáltatás csak azon az ip-n figyeljen, amin kell pedig szintén nem hülyeség. Egy dolog egy tűzfal appliance, megint másik egy iptables, de mindkettőnél el lehet cseszni véletlenül a konfigot. Ez csak egy példa és olyan helyen állja meg a helyét, ahol tényleg több interfész van, pl. 1 standard és 1 a managementnek, ahol pl. az ssh kizárólag management hálózaton figyel.

Azt kellene megérteni lassan, hogy az IT biztonság nem abból ál, hogy belőssz 2 programot, meg beteszel négy kütyüt a hálózatba, ami tutira megoldja a problémát. Ilyen nincs. Azt szoktam mondani, hogy a biztonság az layer-ekből épül fel és, mivel tökéletes biztonság nincs, ezért minden egyes lépéssel törekedünk arra, hogy a támadó dolgát megnehezítsük.

Morin
CEH / ECSA / ABC / NBC / FBI / KGB / NSA / STB

A dolgot úgy hívják, hogy több szintű védelem. Ergó nem egyetlen egy komponensre hagyatkozol, ha biztonságról van szó. Ha véletlenül emberi hiba folytán a tűzfal nem töltődik be, akkor se legyen tárva-nyitva a géped a világ fele. Mondhat akárki akármit, előfordul és erre az esetre jobb felkészülni.

"Az ssh áttétele más portra marhaság, semmivel nem lesz biztonságosabb tőle a szerver."
Ez nem állja meg a helyét. A legegyszerűbb szkript kiddie-k dolgát megnehezíted vele. Nem akadályozod meg, csak a legegyszerűbb szkriptek, melyek nincsenek felkészítve a portszkennelésre el fognak bukni rajta.

Linuxscripting

... össze kell gányolni egy olyan rendszert, ami épp tud egy ssh-t meg egy terminált. A lehető legkevesebb védelemmel, az sshd-t 22-es prtra beállítani, és chroot környezetben lefuttatni. 2 perc alatt belép a támadó, és max egy ls parancsot tud kiadni egy kamu rendszeren. Ha nagyon akarja, akár tönkre is vághatja, hadd szórakozzon :D
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Bejön, nem talál semmi érdemlegeset, továbbáll... Olyan jelszavakat és felhasználóneveket kell megadni, amiket a jelszókeresők minél hamarább megtalálnak, minél kevesebb hálózati forgalmat generáljanak a betolakodók/próbálkozók. A syslog ezt úgysem logolja, hacsak nem teszel még egy külön syslogot a kamu környezetnek.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Na de nem épp az a lényeg, hogy NE is tudjon bejönni? HA meg kukázós rendszert hagyok az SSH-n hogy tudom használni azt azon gépen amin kell? Ok, tovább SSH-zással megoldható, de az elég idegesítő, ha hirtelen kell valami. Vagy itt most nem is volt feltétel, hogy haszna is legyen?

--
openSUSE 12.2 x86_64

Ehh, kezdem érteni a lényeget. Ahogy zeller írja, ha nem talál adott IP-n érdekest, akkor elmegy. és talán békén hagyja a valódi cuccot. nahát... Kérdés az, hogy vajon bevenné-e?.. Ezek után én tuti nem venném be, ha a támadó helyében lennék.

--
openSUSE 12.2 x86_64

Két rövidebb, magyar nyelvű leírás:

Védd magad! - Az SELinux 1.
http://sys-admin.hu/cikkek/20070617/vedd_magad_az_selinux_1

Védd magad! - Az SELinux 2.
http://sys-admin.hu/cikkek/20070624/vedd_magad_az_selinux_2

Egy könyv angolul:
http://www.freetechbooks.com/efiles/selinuxnotebook/The_SELinux_Noteboo…

Wiki (angol):
http://selinuxproject.org/page/Main_Page
--
http://csuhai.hu

( tbs v | 2012. 02. 23., cs – 16:14 )

Sshd kivételével minden szerverszolgáltatás haproxy-n keresztül mehet. Sőt, ssl layert is stunnel-lel húznék a dolgokra, ha kell. Egyébként TLS mindenhol, ahol authigény mutatkozik. (smtp, pop, imap, ftps stb.) Portsentry honeypot okosság, bár kerek tűzfallal hasonló megoldható. Szolgáltatáslogokat rendszeresen átnézni, oszt a fiktív tömeges bombázókat alhálóval együtt tűzfalazni. (Nálam komplett ázsiai szolgáltatók vannak feketelistán - hál isten nem kell arrafelé szolgáltatni. :DDD )

Jah, majd elfeljtettem: érdemes vmi könnyűsúlyú virtualizációba rakni a szolgáltatásokat - külön-külön. Vserver és tsai-ra gondolok. GRSec-el pl. jól együttmozog az említett. Megvéd az egyszeri elszabadult júzertől - ha netán elbacnék vmit nagyon.

Sajna nem, de igazából nem is kerestem. Még csak nem is kőbalták - szakócák ezek.

Közben még tomoyo, ami ügyeske. (Van itt hup-on jó kis szabálygyártás-segítő.) Mármint ha a selinux/grsec/apparmor triumvir komlpexitása riasztó. Mondjuk a grsec/pax-é ha riaszt vkit, akkor inkább ne szőrözzön semmivel. :DDD (A Tomoyo vserver-rel kisebb szopás, de nem reménytelen.)

Az SSL layer-t stunnellel megoldani kb. olyan, mint sajtreszelővel...

Ha van mondjuk egy IMAP szervered, szeretnél elé SSL-t, akkor ne stunnel-t rakj elé, hanem konfigold be ezt a szervereden. A hozzáadott stunnel növeli a komplexitást, ami hosszú távon veszélyesebb, mint magát a service-t átkonfigurálni.

Meg ugye akkor csak az stunnel fér hozzá az SSL certhez, maga az (esetleg vulnos) alkalmazás nem. Én is reverse proxyzok így egy szolgáltatásnak.

Ellene szól viszont, hogy így az alkalmazás logjában nem lesz benne a kapcsolódó fél IP címe, ami legjobb esetben is megnehezíti a debuggolást, legrosszabb esetben nehézzé teszi az esetleges támadások beazonosítását.

( mr shadow v | 2012. 02. 23., cs – 16:18 )

fel
--
"'The time has come,' the Walrus said"

( tovis v | 2012. 02. 27., h – 16:42 )

subscribe

* Én egy indián vagyok. Minden indián hazudik.

( bitvadasz | 2012. 02. 28., k – 13:37 )

"MONITOROZZ MONITOROZZ MONITOROZZ" ( Kayapo ) 


[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/phpMyAdmin
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/phpmyadmin
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/pma
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/admin
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/dbadmin
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/mysql
[Tue Feb 28 10:56:14 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/myadmin
[Tue Feb 28 10:56:15 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/php
[Tue Feb 28 10:56:15 2012] [error] [client 81.169.167.148] File does not exist: /home/user/httpd/htdocs/phpmyadmin2

81.169.167.148 resolves to liebigschule-giessen.de

hát akkor legyen (pl.)
/home/user/httpd/htdocs/myadmin/index.php: 


<?php echo "<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 3.2//EN'><html><head>
<meta http-equiv='refresh' content='0; url=http://www.google.hu/search?aq=f&sourceid=chrome&ie=UTF-8&q=myadmin'>
</head><body  oncontextmenu='return false'></body></html>"; ?>

... ha már ennyire érdekli a dolog.

Én éles szerverre nem teszek pma-t. Van a gépemen egy szükség esetére. De a legfontosabbakat amúgy is megtanultam cli-ből megcsinálni. és ezt a tudást folyamatosan fejlesztem is, mert cseppet gyorsabbnak találom a cli működését. Igaz, kattintgatás helyett be kell pötyögni, de a parancsot pikk-pakk végrehajtja.

--
openSUSE 12.2 x86_64

( talisker | 2012. 02. 28., k – 14:05 )

subs
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( Hyperion | 2012. 04. 21., szo – 10:48 )

Sziasztok!

Már az apache-t is érdemes egyéb userrel futtatni www-data helyett, vagy csak a virtualhostot ruházzuk fel más userrel?

Attól függ, mit üzemeltetsz. Ha webhostingot, akkor az egy egészen önálló problémakör ami egy komplett előadást is megérne, mert nagyon sok mindent meg kell oldanod. Ha saját alkalmazásokat, akkor elég lehet mondjuk PHP-FPM-ből egy-egy saját user alkalmazásonként.

( uid_4656 v | 2012. 04. 22., v – 17:14 )

Amit én hozzátennék, az nem kimondottan biztonsági megoldás.

Szerintem a legtöbbet akkor tudod tenni a rendszereidért (ideértve a biztonságosságukat is), ha szépen, rendezetten, áttekinthetően tartod őket. Szerintem pl. célszerű:

- ugyanazt a disztribúciót használni egy rendszer összes gépén
- kihasználni a disztribúció nyújtotta lehetőségeket és megoldásokat (pl. majdnem minden disztribnél különbözőképpen van megoldva az apache vhostok kezelése, mindegyik jó megoldás, szerintem érdemes ahhoz ragaszkodni, amit a disztrib ajánl)
- frissen kell tartani a rendszert, nincs olyan, hogy "jajj, ne frissíts, mert hátha elromlik tőle az XY alkalmazás" - ha elromlik, akkor általában az alkalmazás a szar, nem a disztrib (ebben vannak kivételek, de ritkák)
- nem használni a disztribúción kívüli csomagokat (ideértve a külső repository-kat és a saját fordítású dolgokat is - ezek több kockázatot hoznak, mint amennyit elhárítanak)
- ragaszkodni az architekturális felépítés tisztaságához (pl. nem rakni még egy adatbázist a webszerverre, mert éppen olyan kedve van valakinek, meg nem felmountolni a webszerver 1-2 könyvtárát NFS-en át az adatbáziszerverre csak azért, mert valamire éppen kell - ha ilyesmi gányolás kell, akkor ott valahol mélyebben van a hiba)

Szerintem ezek a dolgok hosszú távon többet segítenek, mint egyszer hozzáértés nélkül felrakni egy grsec-et, aztán nem frissíteni rendszeresen és várni, hogy majd biztonságos lesz a dolog.

Ezek ilyen altalnos dolgok amik a valo eletben nem mukodnek vagy csak kis rendszerekre vonatkoznak.

1. homogen rendszer ez ok.
2. Ez az tok mindegy sok gep eseten ugy is egy helyrol fogja kapni ezeket szoval biztosan egyseges lesz. Meg amugy is van ceges policy erre vonatkozoan.
3. De van mivel az alkalamzas nem tamogatja az ujabb verziora valo frissitest pl. php 5.2 -> php 5.3 akkor sajnos az 5.2-t cippelni kell maggadal de mellete frissitesni a rendszert. Jozsika BT-nel ez tuti mukodik kozep es nagy vallaltoknal nem. Igen az alkalmazas szar de attol meg penzt termel es az uzleti erdek felul fogja biralni az uzemeltetes erdekeit.
4. Ezt nem teheted meg, erre van az csinalj magad sajat repo-t es gyartsal csomagokat a sajat rendszeredhez. Vannak extra dolog amibol neked ujabb kell de a distro nem tamogatja.
5. Nah ez netto hulyeseg, alt. Frontendeken nincs mysql, ennek az NFS-s peldanak nem sok ertelmet lattom.

--
1 leszel vagy 0 élő vagy hulla!

2. Itt bevallom, nem is értem, hogy mit írsz. Mi lesz egységes mindenképpen? :-)

3. Na, azt nem mondtam, hogy ezt egyszerű megcsinálni, de nem is lehetetlen az esetek többségében, csak nem kell feladni a dolgokat. PHP esetében pl. nemtudommelyik verzióváltáskor megváltoztatták valamelyik XML kezelő modul metódusainak szignatúráját (paramétersorrend, ilyesmik) - erre a megoldás nem az, hogy akkor maradunk a régi PHP-nél, hanem a konkrét esetben pl. készült pár wrapper függvény, ami az eredeti API-t emulálta az új függvényekkel. Szerintem ez jobb megoldás, mint cipelni a régi PHP-t.

4. Ha csak lehet, kerüld. A csomagokat karban kell tartanod, ha szaporodnak, akkor sok csomagot kell karbantartanod, amit felelősséggel és biztonságosra megcsinálni nem könnyű. Az meg hogy újabb kell? Tudsz mondani konkrét példát?

5. Pedig szoktak kérni ilyen marhaságokat, nem is keveset. Ellen kell állni :-)

Egyébként ezeknek a lényege: a felhasználók szeretnek jönni azzal, hogy mit csinálj meg nekik, mert az az aktuális égető problémájukra megoldást jelent. Ilyen esetekben a rendszergazda (szerintem) akkor jár el helyesen, ha nem vakon végrehajtja a kéréseket, hanem megvizsgálja, hogy _miért_ szeretnék az adott változtatást a felhasználók, és nyújt egy, a rendszerbe illeszkedő megoldást a problémájukra.

2. cfengine, puppet ...stb
3. Ez van 10G+ kodbazisnal lehetetlen es rengetek fejlesztesi munka nem csak XML valtozott...
4. Nem kerulom :), nem akkora melo karbantartani es nem egyedul kell szerencsere, pl. ipvsadm,nodejs,nginx,syslog-ng,kernel...stb

Nalunk nincsenek kulsos ugyfelek :).

--
1 leszel vagy 0 élő vagy hulla!

- nem használni a disztribúción kívüli csomagokat (ideértve a külső repository-kat és a saját fordítású dolgokat is - ezek több kockázatot hoznak, mint amennyit elhárítanak)

na de mi van akkor, ha a szervered valami custom funkciot lat el, amire nincs csomag a linuxodban, vagy ha van is az adott feladatra valamilyen megoldas, akkor az nem eleg jo? Konkret pelda: emaileket akarsz archivalni egy gepen. Na megnezem, milyen disztribucion beluli dologgal oldod meg. Masik: spamszures. Onmagamon valo eroszak lenne, ha a default spamassassint kene hasznalnom. Ezekben az esetekben bizony marad a kezzel forgatas, sajat repo, whatever...

Diktatorok kezikonyve

Nyilván. Ha olyan szolgáltatást akarsz nyújtani, amit a disztibúciód nem biztosít, akkor megoldod máshogyan - ennek ellenére szerintem célszerű törekedni arra, hogy amikor lehet, a disztribúciód keretein belül maradj.

Pl. a spamassassin esetében szerintem érdemes megfontolni a disztribúció által szállítottat, mégha kényelmetlenebb is annál, mint amit kézzel felraksz. Hasonló dologgal szenvedtem pár hónapja: chroot-os SFTP szervert kellett volna csinálnom RHEL6-on. _EEEEkkora_ szívás volt úgy összekalapálni, hogy az illeszkedjen az OS-be és ne kelljenek hozzá külső csomagok - de szerintem megérte, mivel így soha az életben(*) nem kell ránéznem többet, pl. ha kiderül, hogy az OpenSSL hibás mögötte, azt úgyis javítja majd a disztribúció.

(*) nyilván egyszer lejár a RHEL6 supportja is...

Érdemes vajon RHEL-en chroot-tal bajlódni SELinux mellett? Régebben olvastam (itt is) olyan véleményeket, hogy a chroot-ból talán könnyebb kijönni, vagy legalábbis az esély nagyobb rá (ha van pl. setuid-ot bináris vagy a bind mount-ok miatt vagy egyéb). Ahelyett nem praktikusabb és biztonságosabb inkább csökkenteni a SELinux kapcsolók által megengedett dolgokat? Meg vonatkoznak-e az általad kialakított rendszerben a chroot környezetre SELinux szabályok? Vagy azt is kézzel kellett hack-elned? Vagy nincs? Akkor meg már nem inkább egy szigorú SELinux?

Meg ugye a SELinux a 0 day-es sebezhetőségtől függetlenül szándékozik keretek közé szorítani a jogosultságokat, míg már egy alap rendszer esetén is ki tudja hogy a chroot-on belüli sok szükséges lib meg futtatható binárisnál milyen lehetőségek nyílnak a trükközésre. Chroot-ból hozzáfér a bind mount-okon belüli rendszer fájlokhoz is (ha van), a kernelhez is, illetve IPC-n keresztül az összes futó szolgáltatáshoz - ami már önmagában probléma.

SELinux esetén ugye nincs /proc meg egyébhez hozzáférés, csak amihez a szabályok alapján az adott folyamat elérhet. Ráadásul hálózati szinten is korlátozva, nem csak FS. Nagy a különbség szerintem egy MAC megoldás kontra sima chroot között.

chroot-on belul mount bind? Es ezt igy hogy? A chroot-nak, nekem igy mondtak, pont az a lenyege, hogy csak a legszuksegesebb dolgok (par device, nehany lib, meg 1-2 binaris) van beleteve. De pl. /proc es egyeb nyalanksagok nem. Arrol nem nyilatkoztam, hogy a chroot ill. selinux mennyiben lonek ugyanazokra a feladatokra.

Diktatorok kezikonyve

Nem chroot-on belül a bind, hanem kívülről mount.bind a chroot-on belüli proc dev mappára, ha egy szolgáltatásnak vagy programnak kell. Persze nem mindennek kellhet, csak arra akartam rámutatni, hogy van olyan program, amit hiába chroot-olunk, a futáshoz olyan dolgok kellenek, amelyek miatt maga a chroot veszti célját.

"Arrol nem nyilatkoztam, hogy a chroot ill. selinux mennyiben lonek ugyanazokra a feladatokra."

Valóban, ezt én magyaráztam bele.

Ha igazán biztonságra törekszel, akkor selinuxot ÉS chroot-ot is implementálsz a gépen. A biztonsági területen általában nem értékelik túlkapásként, ha több rétegnyi biztonsági megoldást is alkalmazol.

Egyébként meg másra jó a selinux meg a chroot - én azt (is) szerettem volna, ha úgy tűnne a felhasználónak, mintha egy konkrét könyvtár lenne az ő root könyvtára. Ezt selinux-szal önmagában nem lehet megcsinálni, erről valahol az sshd-nek kell tudnia.

( baloo | 2012. 04. 24., k – 17:14 )

sub

---
In a world without frontiers, who needs Gates and Windows?

( zitev v | 2013. 01. 05., szo – 15:20 )

eltéve okosba'..

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség