ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Szerver biztonságossá tételeHali! Tegyük fel, hogy kezdő Linux rendszergizda vagyok. Ezenkívül még Szakmailag kb. akkor leszek sikeres, ha az általam telepített/üzemeltetett szerverek Mivel "howto"-kat fordítani lassú és időigényes, (és még el is avulnak :) ) Szóval az én listám, ami most így hirtelen eszembe jut: Érdemes ismerni: [Szerk 2012-02-27]
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 7% Összes szavazat: 565
Új felhasználók
InformációKövess minket!Partnerünk |
http://www.debian.org/doc/manuals/securing-debian-howto/
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise
+1
<= Powered By Ubuntu & Gentoo Linux =>
'Software is like sex: It's better when it's free!'
By Linus Torvalds
subs
--
FBK
+1
+1
+1
+1
Tudnatok egy linket adni, hogy ez micsoda? Koszi!
feliratkozás :)
Najo, de hova? :) Es ez miben javitja a szerverem biztonsagat? :)
Az altalad hasznalt szoftverek security feedjere. :)
Koszi! :)
subs
-+-+-+
Dropbox tarhely
Cave Canem
+-+-+-
+1
+1
+1
+1
+1
+1
subidubi
+1
+
--
zsebHUP-ot használok!
+1
+1
+1
+1
+
ModSecurity
szábsz
Legtobbszor a szerverek szintjen alapveto hianyossagok vannak:
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)?
Igen, minden website sajat user alatt futhat es a PHP kodbol nem tudsz az Apache szalaknak term signalt kuldeni.
- 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/
"- A logwatch rossz ötlet..."
Valaki (akár te, Kayapo) meg tudna győzni erről?
erre én is kíváncsi lennék, hogy miért is
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.
"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.
Mi sok ido rajta? Ha sok geped van tuti ,hogy nem manulisan fogod a configokat szerkeszgetni hanem template rendszert fogsz hasznalni.
--
1 leszel vagy 0 élő vagy hulla!
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
+1
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.
Köszönöm, hogy megfogalmaztad emberi nyelven. :)
Morin
CEH / ECSA / ABC / NBC / FBI / KGB / NSA / STB
SELinux:
http://en.wikipedia.org/wiki/Selinux
--
http://csuhai.hu
Ha valaki tud egy quick start guide -ot az SELinuxhoz az bepostolhatná
----
올드보이
http://molnaristvan.eu/
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_Notebook_Volume_1_The_Foundations.pdf
Wiki (angol):
http://selinuxproject.org/page/Main_Page
--
http://csuhai.hu
+1
RedHat / CentOS / SL alatt:
getsebool -a | grep httpd..és itt mindent kikapcsolni, ami nem kell (gyakorlatilag mindent), akkor mindegy milyen user alatt futnak meg mit engednek a Unix jogok, nem tudnak semmit csinálni a webes szálak.
setsebool -P szabaly offsubsc
=> Ubuntu User <=
Igencsak régi (sajnos), de kellemes olvasmány:
http://www.openna.com/pdfs/Securing-Optimizing-Linux-The-Hacking-Solution-v3.0.pdf
.
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.
Hali!
Ezek jó ötletnek hangzanak...
Tudsz erről (vserver+haproxy) vmi howtot? (Persze van dokumentáció, és ajánlott is végigolvasni, de ha van howto, akkor egyszerűbb azzal kezdeni)
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.
Igaz. Az okok, ami miatt kedvelem: stunnel.conf kitanulása 1 dolog. 25 különféle szerviz ssl rétegének kitanulása 25 dolog... Ha meg ssl hibát kell keresni stunnel-en 1féle, nélküle 25 féle... ;)
Ott a pont. Szerintem...
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.
HaProxy, X-Forwarded-For stunnel patch -> http://haproxy.1wt.eu/download/patches/stunnel-4.32-xforwarded-for.diff
stunnel.conf:
"...
xforwardedfor = yes
..."
Az ilyet karbantartani, brr... :-)
Gondolom azért Te is használsz pár custom szkriptet... ;) Ez kb. azzal összevethető bonyolultságú mutatvány.
Mondjuk biztos perverznek tartasz, de kernelt is forgatok a dobozaimra. (Nem /doboz, hanem globál.) Sőt, patchelt kernelt! :DDD
Jól értelmezem, hogy ez csak HTTP(S)-re jó? Az ember azért szeretne időnként más szolgáltatást is üzemeltetni. Sőt, szerintem a szolgáltatásaim többsége nem HTTP alapú. :)
Igen, jól érted. És természetesen igazad van, ez csak egy KIS könnyítés. (HTTP/SMTP)
fel
--
"'The time has come,' the Walrus said"
http://www.gentoo.org/proj/en/hardened/primer.xml
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Én meg ezt ajánlom:
http://linuxakademia.com/treningek-2012-tavasz-biztonsagoswebszerver?li=7g4b5b8r7f6t5z7c
Legalábbis engem érdekel és remélem el is tudok menni rá!
subscribe
* Én egy indián vagyok. Minden indián hazudik.
"MONITOROZZ MONITOROZZ MONITOROZZ" ( Kayapo )
81.169.167.148 resolves to liebigschule-giessen.de
hát akkor legyen (pl.)
/home/user/httpd/htdocs/myadmin/index.php:
... ha már ennyire érdekli a dolog.
ha valaki netrol elerheto szerveren hasznal phpmyadmin vagy egyeb webes admin toolt, akkor mindenkeppen tegyen ele valami + authentikaciot (legalabb egy basic authot).
Tyrael
subs
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)
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.
Az utóbbi lehetőség esete áll fent, és php-fpm pool-al kezeltem le. Ezekszerint ez elég. Köszönöm a válaszod!
http://en.gentoo-wiki.com/wiki/Syslog-ng
portknocking
+1
feliratkozom
[Feliratkozás]
feliratkozás "biztonságos szerver"
+1
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!
Ha jól láttam ez még nem volt:
http://benchmarks.cisecurity.org/en-us/?route=default
Oldal jobb oldalán Security Resources dobozban lehet válogatni. Hasznos, jól összeszedett.
Üdv,
Morin
CEH / ECSA / ABC / NBC / FBI / KGB / NSA / STB
+
.
sub
---
In a world without frontiers, who needs Gates and Windows?