biztonságos debian szerver

Debian GNU/Linux

Sziasztok!

Gondolom mar ezerszer kitargyaltatok ezeket a temakat, de par kerdes erejeig zaklatnalak Titeket.
Hamarosan egy debian szervert kene beuzemelnem es szeretnem relative biztonsagosra csinalni.
Tudom mondhatjatok, alkalmazzak inkabb igazi rendszergazdat de meg szeretnem tanulni sajat magam a dolgokat. Teljesen kezdo azert nem vagyok, de jopar dolog van ahol meg finomithatom a tudasomat, sot :)
Leirom kb. mit gondoltam es ha van otletetek hol lehetne meg ugyeskedni, biztonsagosabba tenni, akkor azt szivesen fogadom.

Tehat:

- alaprendszer etch
- apache2
- php5
- mysql
- postgresql
- postfix+courier mysql v. postgre authal
- pure-ftpd v. proftpd mysql v. postgre authal (meg nem neztem meg, hogy sftp-t tudnak ezek, de gondolom igen)
- squirrelmail v. roundcube vagy egyeb jo webmail klienes (itt szivbesen fogadok otleteket :)

Kb ennyirol szolna a dolog. Nem hoszting akarnek lenni, hanem csak a sajat oldalaimat szeretnem hosztolni, tehat webes adminok stb.-k nem letszugsegletek. Szerencsere fizikai userek se lesznek a gepen, minden (ftp,mail) virtal userekkel menne.

Ami lepeseket gondoltam:

- telepites a fenti csomagokkal
- inetd-bol kiszedni a folsoleget max a ftp-t benne hagyni, hogy ne kelljen demon modban futtatni, egyeb hasznalaton kivuli progik kigyepalasa
- tuzfal belovese csak a hasznalt szolgaltatasokhoz tartozo portok beengedese, kifele iranyulo kapcsolatokat is erdemes korlatozni?
- mysql, postgre korlatozasa localhostra
- ftp helyett esetleg sftp belovese
- pop es imap ssl moge rakasa
- anonymous ftp kilovese
- authentikalt smtp beuzemelese
- clamav es spamassissian belovese a levelezeshez ... brrrr ... szoktatok hasznalni a balck es az egyeb listakat a szurehez, vagy csak az egyeb heurisztikus, vagy hogy mondjak szurest hasznaljatok?

Amik felmerultek es varom tanacsaitokat:

- ha mar minden fent van gcc,cc es egyeb fordito progik torlese celszeru lehet gondolom (igaz elvileg nincsenek local userek csak en)
- apache-ot erdemes kezzel forgatni es jail-be rakni hogy ha van valami elkeffentett script akkor se lasson ki a sajat konyvtarstrukturajan kivulre vagy ha ugyis nem root-ken fut es a jogok nincsenek elbarmolva akkor nem fog hozzaferni olyan dolgokhoz amikhez nem kene? (gondolom elrontott php scriptel hozza lehet ferni az etc tartalmahoz esetleg ami nem tul celszeru :)
- ftp-t gondolom erdems ugy beallitani, hogy az user ne tudjon kimenni a sajat konyvtarabol

Most igy reggel felhulla fejjel ezek jutottak eszembe. Amennyiben van otletetek mit nezzek jobban at, hol forditsak nagyobb figyelmet es miket kene meg beallitani a minel nagyobb biztonsag elerese erdekeben, azt szivesen fogadom.

Nem akarok 100%-os biztonsagot elerni, de szeretnem, hogy az en kepessigeimmel, tudasommal a leheto legbiztonsagosabb rendszert osszehozni.

Tudom szet lehetne flame-elni a topicot, de szerintem masok is szivesen olvasnak kreativ hasznalhato otleteket a temaban.

Koszi elore is!

Bj

  • 7121 megtekintés

( Replaced | 2007. 05. 27., v – 08:58 )

vegul is pont ott kezdodik a biztonsag, hogy vegiggondolod pont ugy ahogy leirtad, szoval jo uton haladsz

"- tuzfal belovese csak a hasznalt szolgaltatasokhoz tartozo portok beengedese, kifele iranyulo kapcsolatokat is erdemes korlatozni?"

szerintem igen

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

Azért pl. érdemes engedélyezni a root DNS szerverekhez való kifele menő kéréseket engedélyezni, továbbá a biztonsági frissítéseket tartalmazó repository szerverhez való kifele menő kéréseket engedélyezni. A DNS -t is célszerű jail -be rakni.
Korábban én is virtual usereket használtam ftp és levélhez. A levélnél maradtak a virtual userek, de ftp -hez helyi felhasználókat használok -s /bin/false opcióval a létrehozásukkor. Így könnyen meg lehetett oldani, hogy a php scriptek az adott ftp user jogosultságaival fussanak. Ha futtatsz php -t, akkor azt rendesen be kell állítani, mert elég nagy sec. hole lehet egy rosszul belőtt php.ini. Ajánlom figyelmedbe a suhosin patch -et a php -hez. Apache helyett esetleg lighttpd -t.

--
http://laszlo.co.hu/

( Panther v | 2007. 05. 27., v – 09:03 )

Ami a gcc-t, stb. illeti, érdemes lehet elgondolkodni azon, hogy chroot-ban (jailben) futtatod a szervereket, amiben semmilyen felesleges program nincs, tehát gcc lehet fent - de csak a külső rendszeren.
--
hup.user.js

( rowcol | 2007. 05. 27., v – 09:52 )

Szia!

Nekem 3 db az általad leírthoz hasonló config megy. A legelső 6 éve. Gond nélkül. A különbség annyi, hogy nekem a mail (smtp/auth smtp/pop3) az teljesen qmail-re van alapozva. Ezzel nem akarom azt mondani, hogy bármelyik jobb vagy rosszabb lenne (az másik topic). Mindennek van pro és kontrája. CGI jail nálam annyi, hogy csak PHP-t adok és az safe_mode-ban megy open_basedir-rel és disable_function-el. Ez gyakorlatilag jail-ként fogható fel a PHP scripteknek. Ha egy-egy ügyfél feltétlenül igényel más CGI-t, akkor azt odafigyeléssel kezelem. De kb 4 éve nem kért senki PHP-n kívül mást.

És mai napig időnként googlizok olyan kulcsszavakra, hogy safe ez vagy az, elolvasok a találatok közül párat, mikndig tatlálva jópofa ötleteket.

Az egyik kedvencem pl (asszem ezt pont itt a HUP-on olvastam) SSH úgy van iptables-elve :) hogy az első kapcsolódást visszavágja, mint nem létező portot, de utána két percig fogadja a connection-t. A portscanner-es robotkok, scriptykid-ek, stb lépnek is tovább, mert másodszor nem jellemző, hogy újra lescannelik. Zseniális.

Row

Az nem kernel szinten támogatott port-knocking volt?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

Nem. Nem erre gondoltam. Ez valóban túl költséges. Amit láttam, az 2-3 iptables sor volt és csak annyit csinált, amit írtam. Gyakorlatilag 2x egymás után kell kapcsolódni mehatározott időn belül, ennyi a kulcs. Nem nyújt brutál védelmet, viszont kizárja szinte az összes automatikus portscanner backódását.

Row

( bj | 2007. 05. 27., v – 10:32 )

Koszi az eddigi otleteket!
Orulok, hogy annyira megsem vagyok kutyauto es voltak jo elkepzelesiem a dologrol :)
Ez az ssh-s ugy ez nagyon nagy otlet :)
Tovabbi otletekre is vevo vagyok :)

( bj | 2007. 05. 27., v – 11:16 )

Tenyleg ingyenes eszkozoket hasznalva spam es virusszuresre mit hasznaltok levelozrendszerekben?
Gondolom kell spamassassin,clamav,amavis.

Ami erdekelne, hogy a spamszureshez melyik technologiakat hasznaltok? Azaz black, gray listek vagy ez mar nem megy annyira is inkabb pyzor, razor es hasonlo progik.

Ha ebben tudnatok meg egy kis lokest adni, annak nagyon orulnek, mert a spamaktol felall a szor a hatamon :)

Pont így! :)

Pyzor, Razor2, DCC, SPF bekonfigolva spamassassin alá, bayes beállítva, clamav és spammassassin belőve amavis alá. Használok RBL listákat is, de csak ésszel,azaz a sorrend az, hogy ha az ügyfél authentikált SASL-el, akkor őt már nem ellenőrzi.

Arra figyelj, hogy a pyzor servers fájlban található IP debian alatt hibás. Cseréld "82.94.255.100:24441"-re.

Tűzfalbeállításokra figyelj oda, és ne felejtsd el felvenni a clamav felhasználót az amavis csoportba.

( rubasov | 2007. 05. 27., v – 13:37 )

Hi!

Meg par dolog:
- pure meg proftpd szerintem nem tud sftp-t, ehhez sshd-t kell hasznalni. Kulcsszo: rssh.
- chrootolt apache megoldhato egyszerubben is. Lasd: libapache2-mod-chroot.
- ha mar a pop es imap ssl folott megy, erdemes az SMTP-t is ugy hasznalni, legalabb amikor AUTH-nal user/password is elkuldesre kerul.
- webmail: amit meg en ismerek es egeszen hasznalhatoak: ilohamail, horde/imp
- az apache virtual hostingrol nemreg a weblabor.hu-n volt egy egesz jo leiras, erdemes elolvasni.
- aztan van ilyen is (angol): Securing Debian Howto

udv. rubasov

( airween v | 2007. 05. 27., v – 22:01 )

Hello,

- Debian-ban van egy progi: jailer, eléggé napra készen lehet vele tartani a jail-t is (apache2, MySQL, ...)
- a gcc és tsi. nincsenek feltelepítve; van egy image a gépen, amit debootstrap-el felhúztam, abban van gcc meg minden. Ha valamit kell forgatni, gyakorlatilag ugyanaz a rendszer ott van "homokozónak", felcsatolom, chroot, ha kész, lecsatolom.

( Rumczy | 2007. 06. 06., sze – 14:55 )

szia!
szerintem teljesen jó úton haladsz a biztonság felé... ftp szervernek a Pure-ftpd t ajánlom virtual userekkel, én is azt használom és nagyon jó. Webmail: ha a szépségre mész roundcube, ha biztonságra, squirrelmail :). Egyébként van egy firewallom ami IPTABLEST használja, ha szeretnéd irj egy mail cimet és elküldöm.
üdv

( Huncraft v | 2007. 06. 06., sze – 15:32 )

Huh.. Azok közül amit mondani akartam azért már jópár dolgot elmondtak elöttem hála égnek, így csak tényleg megemlítem őket:
debootstrap, fail2ban, portknocking,remote logging

Persze mindezek melett még vannak azok az alapok, hogy root-ot nem engedünk ssh-n keresztül bemenni, hanem inkább létrehoznék a helyedben 1 usert akinek csak su-ra van joga másra nem ( szal tmp-t se biztos, hogy tudnia kéne írni ), és onnan fel su-zni ), illetve magas portba rakni az ssh-t is, hogy az alap scannek ne találják meg és csak SSH2-es protokolt engedni ( SSH1-essel vannak kisebb gondok )
Ami viszont sztem kimaradt és sztem azért van értelme: forrásból felpakolt apache modsecurity patch-el, illetve kernel is grseccel megáldva.
Mindemellé jön még az is, hogy 1-2 monitorozó és log analizáló progit nem árt esetleg felrakni, illetve egy változáskvető rendszert ( tripwire esetleg, bár vannak újabbak is ). Ha nagyon elvetemült vagy akkor esetleg ZORP ingyenes verzióját is kipróbálhatod (szintén ~pilótavizsgás :)).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

bind9 - attól függ mire akarod használni
ntp-date még jöhet, mert szinkronizálni sose árt vmilyen ntp szerverrel, de hogy ntp-t is üzemeltess az sztem felesleges
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

regisztráltam a dyndns-en két doimaint xy.dyndns.com és yx.dyndns.com és azt szeretném hogy ha kérés érkezik ezekre a domainekre akkor az apache jelenitse meg a megfelelő domainhez való oldalt, ehhez szükséges-e bind-re, vagy csak az apache vhostban kell beállitani?
a kép adsl-en router mögött van.

( sibidiba | 2007. 11. 12., h – 22:28 )

Látom többen is ajánlották néhány service chrootolását.

NE TEDD!!!

Alapvetően a chroot - még a hardened sem - nem security megoldás. Pont néhány hete anyáztak az LKML-en, hogy néhányan ennek ellenáre folyamatosan erőltetik. Szépen hangzik, de valójában mindig ki lehet belőle törni, ugyanakkor vért fogsz izzadni nem csak mire működik, de később is, amikor valami apróságot akarnál csak még hozzárakni (pl. locales support apache-hoz).

Ha chroot-ra lenne mégis szükséges, az egyetlen valóban biztonságos és jól működő megoldás a virtualizáció.
(Pl. apache virtuális gépben fut, és NFS/AFS/SMBFS/SSHFS/FTPFS mountolva van a kiszolgálandó tartalom, az adatbázist meg TCP/IP-n éri el.)

--
The Net is indeed vast and infinite...
http://gablog.eu

"Szépen hangzik, de valójában mindig ki lehet belőle törni," - Ezt kifejtenéd? Merthogy téynleg érdekelne..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

( sibidiba | 2007. 11. 12., h – 22:34 )

Ami igencsak kritikus tud lenni, az a PHP!

Csakis php-cgi -vel indíts, különben minden php www-data -ként fog futni. De így is érdemes felhasználónként open_basedir korlátozni, valamint programfuttatást letiltani:

disable_functions = exec,shell_exec,system,proc_open,dl,passthru,pcntl_exec,popen,virtual,proc_close,proc_get_status,proc_termi
nate,pack

a safe_mode-ot pedig el kell felejteni:
; NOTE: this is considered a "broken" security measure.
; Applications relying on this feature will not recieve full
; support by the security team.

--
The Net is indeed vast and infinite...
http://gablog.eu

biztonság szempontjából az érdekelne melyik jobb program a tapasztalatok után AIDE, OSSEC, az utóbbinak van webui-ja is, nem tudom ez számit-e, az OSSEC-et csak forrásbol lehet telepienni letöltve a built-essential csomagot, nem tudom ezt a forditó csomagot utána el kell távolitanni vagy fentmaradhat a serveren, vagy célszerübb az AIDE-t használni??