Forum Debian Users Gang

Jacekalex zawsze jest wieczny flejm grsec czy selinux, ja stawiam na grsec :)

Grsec bardzo mocno obcina (bez /etc/grsec/policy) działanie exploitów, jest dokładnie od tego zarówno sam grsec jak i pax.
Do tego ma ACL - do skonfigurowania w /etc/grsec/policy - dość trudne, automatyczna generacja raczej niezbyt skuteczna, ale można to sensownie zrobić.

W porównaniu z Selinux i Apparmor, jest to jedyny moduł zmniejszający ryzyko działania exploitów, wiele z funkcji grsec/paxa znalazło się w standardowych kernelach, ale grsec i pax są w tych technikach o trzy kroki do przodu, przed kernelami dystrybucyjnymi.
Jednak w ACL grsecurity jest trochę za malo opcji, jeśli chodzi o konfigurację pojedynczego programu, tutaj radziłbym puścić go wolno w ACL grsec,
a dopieścić Apparmorem lub Selinux bardziej szczegółowe uprawnienia, które w grsec trudno zdefiniować.
Sensowne np w odniesieniu do firefoxa u mnie, na serwerze takich kłopotów będzie znacznie mniej, bo i softu będzie znacznie mniej ;)

Jedna wada w Paxie i technologii ASLR - potrzebne jest PIE - w Gentoo możesz tak skompilować cały system, w innych Linuxach , bazujących na gotowych paczkach zależy od developerów, co będzie korzystało z ASLR, a co nie.
W Debianie na oko nieźle zabezpieczonych jest około 40% paczek serwerowych, np Apache tak, sshd tak, ale nginx i lighttpd już nie, kiedy ostatnio patrzyłem,  i około 20 - 25% paczek na desktop,  w Ubuntu jest trochę lepiej, bo wyraźnie wcześniej się za to zabrali.

Ale jak chcesz takie szczegóły, to poczytaj trochę dokumentacji Gentoo Hardened, Security handbooki Debiana i Ubuntu przejrzyj trochę forum i wiki grsec, np ten post: http://forums.grsecurity.net/viewtopic.php?f=3&t=2131

Z tego , co ma być na tym shellu, nie widzę niczego, co mogłoby nie działać, ale grsec i pax zmieniają system w coś podobnego bardziej lub mniej do czołgu, dlatego grsec/pax może narobić trochę kłopotu, zwłaszcza, jak się ktoś walnie w konfiguracji.
Co do Slackware, to kiedyś zamierzałem go postawić, ale jak poczytałem dokumentację, i zobaczyłem o nim conieco, to zdecydowałem się na Gentoo,
a Slackware mnie za bardzo nie obchodzi na razie.
Grsec i Pax możesz użyć na każdym Linuxie, i to równolegle z Selinux lub Apparmor, ale w odniesieniu do niektórych funkcji modułu Pax, zależy od sposobu kompilacji paczek w danej dystrybucji, i nie zawsze można z tego modułu wycisnąć max możliwości, a to pierwsza  linia obrony przed exploitami, które potrafią dostać się do systemu np przez serwer www, i zrobić małe boooom w pamięci RAM.
Standardowe jajo też jest na taką okoliczność nieźle zabezpieczone, ale grsec i pax to po prostu wyraźnie wyższa półka zabezpieczeń.

Ale żeby ją stosować, to trzeba trochę poczytać, trochę się  podszkolić z konfiguracji i użycia tego drobiazgu, i przygotować się na kłopoty, np ja na grsec Virtualboxa już 2 miechy próbuję odpalić, i w żaden sposób mi się nie udało (choć nie siedzę nad tym dzień i noc ;  ale nakombinowałem się już dość sporo.)

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2011-05-16 10:08:12)

Z patchami i konfiguracją?
To się raz poznaje, a potem już leci.
Początek strasznie jest trudny, zawsze są jakieś kłopoty, ale jak zaczniesz czaić bazę, i widzieć, o co w tym biega, to się robi proste jak p**********.

A takie drobiazgi jak Grsec, czy LXC, czy Selinux lepiej poznać, jak chcesz się uważać za fachowca od Linuxa, tak samo jak lepiej poznać OpenBSD, FreeBSD i NetBSD, jak chcesz się uważać, za fachowca od *BSD.

Jednak z każdym systemem jest jakaś robota, żaden nie jest gotowy do użytku, po 10 minutach instalacji.

Ja, jak zobaczylem (po 3 latach z Ubuntu), że mimo wszystko o prawdziwym Linuxie mam o wiele mniejsze pojęcie, niż myślalem, to wziąłem najtrudniejszego i najbardziej hardcorowego Linuxa, i teraz gram sobie w Quake na hardened z grsec/paxem i apparmorem, a znam dwóch informatyków, którzy potrafią postawić serwer WWW na Debianie, i tygodniami opowiadać, jaki to pancerny szybki i stabilny system, a jak się skrypciarze do takiego serwera zabiorą  atakiem slowloris, to ło matko, co teraz robić, bo nawet rev-proxy do Apacha nie postawili, bo po co, przecież taki wspaniały system postawili.

A przecież Debian jest dobrym systemem, też można go porządnie skonfigurować i zabezpieczyć, ale to też nie jest 15 minut i sprint po piwo.
I z systemami BSD jest dokładnie tak samo, z tym, że Open* częściej trafia na routery, na serwerach www podobno ma kłopoty z szybkością, słyszałem, nie sprawdzałem.

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2011-03-28 11:40:36)

Jacekalex napisał(-a):

1. Ściągasz stage hardened - najnowszy, i jest gotowy do pracy, na shellu Duga taki jest i chodzi. Kompilujesz do niego jajo, resztę programów możesz kompilować, lub skołować paczki.

2. Kilka programów z bibliotekami możesz ściągnąć z tinderboxa - link masz wyżej, zainteresuj się zmienną PORTAGE_BINHOST.

3. Na Celeronie niczego nie kompilujesz, kompilujesz na kompie P4 z flagami do Celerona, i opcją buildpkg w features, na Celerona wypakowujesz gotowe paczki.

Co do kompilacji na P4-2.8 - to o ile się nie mylę, Ilin na podobnym kompie skompilował Gentoo razem z Gnome, i nekrologu nie widziałem, więc chyba przeżył w dość dobrym stanie ;).
Na serwer poza tym, nie kompiluje się żadnej krowy w stylu Gnome czy KDE, Irssi czy podobne programy  konsolowe , są lekkie  i kompilują się dość szybko.

Radzę tylko trzymać się programów pisanych w C, a w miarę możliwości unikać pisanych w pythonie , perlu czy javie, (z wyjątkiem skryptów).
Takie programy są 2 razy szybsze, i wyraźnie stabilniejsze, poza tym przy aktualizacji np Pythona nie trzeba ich przebudowywać, co jest dużym ułatwieniem.

Gentoo działa z paczkami równie dobrze, jak  Debian.
Tylko że użyszkodnicy Gentoo robią sobie paczki samodzielnie, pod swój własny sprzęt.

Co do Selinuxa: Super Wsparcie w Debianie: http://pastebin.com/LbCJVrxi
i byle jakie , "prawie żadne" w Gentoo: http://pastebin.com/vS9Ejeqk

AFAIK najbardziej rozwiniętego Selinuxa ma Fedora, włącznie z sandboxem.
Najlepsze wsparcie dla Apparmora,  (który jest w mojej opinni prostszy w obsłudze i trochę lepszy do Selinuxa), ma Ubuntu.

Także w niczym nie jestem specjalnie zakochany, ale ten system (Gentoo), mi po prostu dopowiada, nie dlatego, że jest łatwy, ale dlatego, że w nim nie ma rzeczy niemożliwych.

To by było na tyle
;-)

Wiem że dla Ciebie gentoo jest łatwe dla mnie nie za bardzo. Po drugie nie chce się od nowa bawić z stawianiem systemu, tak jak to powiedział azhag:
"lepszy debian niż wszystkie inne jego klony".
Oczywiście nie mam nic przeciwko ubuntu ale dosyć często zrobią upgrade i potem mam niskie uptime.
Nie znalazłem u siebie w konifgu sshd opcji która odpowiadała by za chroot mam ją dodać?
No i co będzie z moim kontem "userowym" na które się loguje (oczywiście nie jako root ;-) ).
Będzie one logowało się do chroota czy jak? Grsec wystarczy chyba (plus ew. selinux).

bryn1u napisał(-a):

Systemy BSD same w sobie po instalacji sa mocno zabezpieczone. OpenBSD ma duzo mechanizmow zwiekszajacych bezpieczenstwo min. kryptografie i dlatego jest malo wydajne, ale za to cholernie bezpieczne. Cos za cos :P Czyli co mowisz, zeby brac Gentoo ? Bo sklonny jestem zaryzywkowac. Powiedzmi czy jedynym wyjsciem, zeby zainstalowac gentoo jest sciagniecie livecd ? Nie ma jakiegos odpowiednika netinstall z debiana ?

Jest instalator graficzny ale chyba nie wspierany, musisz sciągnąć sarge 3 rozpakować potem jak się nie mylę instalacja portage. Kiedyś też chciałem gentoo, ale na moim sprzęcie kompilacja trwa wieki. Jądra nie trzeba kompilować, genkernel, czy coś takiego.

Dokładnie, tak samo sądzę, ale wiesz przywykłem już do debiana i nie chce go raczej zmieniać.
Jeszcze parę łat na jądro bym nałożył, ale jakoś zawsze kompilacja mi nie wychodziła, popróbuje jutro albo może dziś.

OpenBSD bawiłem się dość dawno temu, system rzeczywiście bezpieczny, ale dość ciężki, natomiast firewall pf - to jest dla mnie na razie czarna magia.
Co do twierdzenia typu: Linux to tylko jądro i chaos, a *BSD to ład i ostoja, bo jeden spójny system, to zwykły PR-owski bełkot fanatyków *BSD.
Przecież czy bierzesz Debiana, czy Fedorę, czy Ubuntu, to 90% - 95% systemu jest przygotowane i przetestowane przez grupę developerów.

W Gentoo natomiast ebuildy piszą developerzy, a człowiek sam sobie wybiera,
z jakimi opcjami chce mieć dany program, i jakim kompilatorem (kompilator też ma różne flagi),  go kompilować.

Ryzyko błędu w kodzie  też jest zbliżone  we wszystkich systemach.
Łaty na błędy w programach też we wszystkich systemach otwartych powstają średnio w ciągu od 2 tygodni do 3 miesięcy od wykrycia błędu, choć zdarzają się wyjątki.

A jak ktoś chce tutaj twierdzić, że Linux, (czy konkretnie Gentoo), nie nadaje się na serwer z takiego czy innego powodu, to niech to udowodni na przykładzie serwera http://dug.net.pl/

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2011-03-29 11:03:26)

To jest dyskusja o systemie pod serwer shell, czy nowy flame na temat Linux kontra *BSD?

Każdy system ma wady i zalety, każdy ma błędy, każdy ma jakieś wady i zalety.
I każdy trzeba porządnie skonfigurować, żeby dobrze działał.

To wszystko w tej kwestii.

Flagi kompilatora  do make.conf są na necie.
Stage hardened ma gotowe flagi do zastosowania na serwerach, można w make conf dodać ssl, tls, mysql i static*, jak ktoś chce.
W domu na kompie odalam chroota z takim stage, i buduję wszystkie paczki, które chcę skompilować, na opisany w wątku serwer będzie około 4  o 20 sztuk.
Do tego źródła hardened-sources, na serwerze zrobić listę modułów skryptem ver_linux, z kernela dystrybucyjnego, ustawiam te moduły w konfigu kernela,
Następnie kompiluję kernel do paczki

 make tarbz2-pkg

Na serwerze rozpakowuję ten sam stage, wgrywam skompilowane w domu paczki,  wypakowuję jajo, konfiguracja gruba, firewalla i start.
Test czy działa, wrzucam przygotowane konfigi do demonów typu www, ftp, i inne, odpalam skrypty jailkit (trzeba do nich zrobić konfig)  - żeby porobić chrooty.
Na wirtualzację Celeron jest o wiele za słaby.
Włączam automatyczne generowanie polityki grsec.

Serwer trochę pochodzi, np 2 dni, kończę zapisywanie generowanej polityki grsec, i biorę ją do obróbki.
Instalacja - jakieś 1 godzina roboty, i spacer z psem, az się skompiluje, co ma się skompilować, postawienie sytemu na serwerze, jak każdy inny system, wgrać gotowe paczki, uruchomić, wrzucić konfigi.

Najtrudniejsza jest teoretycznie konfiguracja ACL grsecurity, ale na taki serwer wcale nie jest zbyt trudna. Trzeba tylko na wzór wziąść wygenerowaną automatycznie, żeby przejrzeć, co faktycznie działo się przez czas generowania.
Przy instalacji systemu jest może z godzina lub 2 konfigurowania i kombinowania, komputer ma trochę więcej czasu na kompilację.

Przy poprawianiu konfiguracji dla ACL jest trochę zachodu, ale da się to zrobić w 2 godziny, na necie przykładów nie brakuje.
Można też olać ACL z grsec lub dać tam kilka niezbędnych funkcji,  i włączyć równolegle Selinux, który ma gotowe profile, lub Apparmor,do którego też są gotowce, jednak czasami trzeba w nich trochę przerobić ścieżki do folderów.

90% roboty idzie tak samo, jak w każdym innym systemie, 10 procent, to robota specyficzna dla Gentoo, ACL się we wszystkich systemach konfiguruje jednakowo.

i gdzie tu jest coś niezwykłego?

Ostatnio edytowany przez Jacekalex (2011-03-29 12:45:04)

Wszystkie demony sieciowe, iptables, kernel, grsecurity i 95% badziewia konfiguruje się jednakowo we wszystkich Linuxach.
Inaczej działają instalatory, w Gentoo są flagi, w Debianie paczki.
Do tego może z 5 plików konfiguracyjnych wygląda inaczej, ale nie jest to jakaś magia, to głownie  sieć i lokalizacja, skrypty startowe? w Debianie kiedyś

update-rc.d.....

w Gentoo obecnie

rc-update add <program> default

praktycznie to samo.

A np konfig do Postfixa, Nginxa czy ssh może fruwać między FreeBSD, Slackiem, Gentoo, Debianem i Ubuntu, we wszystkich systemach Postfix  czy ssh działa tak samo, nieco inne są konfigi Apacha w Gentoo niż w Debianie, ale różnicę można ogarnąć w 10 minut, dotyczy ścieżek do folderów, Debian ma /var/www, w Gentoo jest /var/www/<domena>/htdocs,
dla cgi w Debianie /usr/lib/cgi-bin, w Gentoo  /var/www/<domena>/cgi-bin.

Także nie wiem, o czym jeszcze można tu dalej dyskutować.

to by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2011-03-29 13:29:01)

Zainteresuj się programem jailkit, on daje możliwość automatycznego tworzenia i aktualizowania chroota, w dość przystępny sposób.

Robienie jaila na piechotę do droga przez mękę, a poza tym i tak musisz czasem zaktualizować soft, będziesz rzeźbił chroota za każdym razem od nowa?

I na jakim systemie ostatecznie stawiasz tego chroota?

Ponadto możesz zrobić chroota makejailem (trzeba w nim stworzyć konfigi dla usług, które mają być chrootowane).

Możesz też zrobić to  najprostszym z możliwych sposobów, zajmuje więcej miejsca, ale działa ok.
np tworzę partycje, instaluję na niej minimalny system bazowy (np Ubuntu mini.iso),
potem potrzebne programy w tym systemie (apt-get), następnie przechodzę do systemu głównego, i mam tam gotowego chroota, z całym potrzebnym softem, potem tylko montuję lub tworzę w chroocie /dev/urandom /dev/random i /dev/null.
W konfigu rsyslog trzeba ustawić obsługę gniazda /dev/log - żeby tworzył je w chroocie, i gotowe.
Odpalanie normalnie:
z roota:

chroot /<folder> /usr/bin/nginx  <opcje>

Sposób wymaga fizycznego dostępu do maszyny, ale za to jest najprostszy do zrobienia, i w dodatku, jakby jakiś skrypciarz włamał się do takiego chroota, to chwila minie, zanim się zorientuje, że to chroot ;)

A jak potem chcesz zaktualizować takiego chroota, to odpalasz albo ten system przez kvm, albo bezpośrednio, i aktualizujesz.

W identyczny sposób działa LXC, bardzo podobnie OpenVZ.
Jednak instalując gotowy system jako bazę dla chroota, nie trzeba studiować żadnych specjalnych konfiguracji, ja tak mam postawiony Squeeze.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2011-03-29 15:12:04)

LXC nie polecam jest dosc specyficzny.
O wiele bardziej dojrzalym projektem jest OpenVZ, ktory spisuje sie naprawde znakomicie i posiada o wiele wieksze mozliwosci konfiguracji niz lxc.
Jest to bardzo szybka wirtualizacja z racji tego ze jest ona na poziomie OSu minusem tego jest to, ze kernel takiej wirtualnej maszyny jest wspolny z kernelem hosta.
Bardzo przyjemnie sie backupuje takie srodowiska w trybie live w polaczeniu z LVM.