Koty na WHT, Fakty i Mity + Poradnik

[Pan Kot 1535]

@kafi

"sarge" został użyty tylko i wyłącznie przez developerów Webmina, w rzeczywistości nie ma tam nic innego jak WYŁĄCZNIE zaktualizowany webmin, którego nie ma w oficjalnych repo. I m.in został tam właśnie użyty po to, żeby nie nadpisywać żadnego oficjalnego pakietu z repo, o ile taki zostanie wprowadzany. Więc w rzeczywistości dostajemy z tego "złego" sarge'a jeden plik .deb, który dodatkowo ma datę najczęściej nie starszą niż kilka tygodni .

 

Sprawdź to "złe" repo i sam zobaczysz. Nie ma absolutnie żadnego sposobu na jakiekolwiek błędy, nie sugeruj się nazwą . Oj chyba ktoś inny dostanie po łapkach .

 

A co do reszty postu się zgadzam, tyle że odnosiłem się tu do czystego sudo, a nie jego konfiguracji, bo o to pytał @mynod3 .

Edytowano Maj 1, 2013 przez Archi (zobacz historię edycji)

[t4t4v4 3]

Łukasz, było pytanie czy może się uszkodzić hard/software maszyny, więc odpowiedziałem, że nic się nie stanie..
Co do wzrostu użycia CPU to masz rację.

[Pan Kot 1535]

Łukasz, było pytanie czy może się uszkodzić hard/software maszyny, więc odpowiedziałem, że nic się nie stanie..

Co do wzrostu użycia CPU to masz rację.

 

 

 

czy np. dedyk po prostu się wyłącza czy ciągle zamula? Czy może się uszkodzić maszyna? system?

 

Ja bym rzekł, że o CPU też tu było pytanie no ale jak kto woli . Nie będę się kłócił.

[krzys21 0]

Archi,

Dzięki za tutorial. Mam dwa pytania:
1) Czy da się wyłączyć powiadomienia na email z fail2ban o usłudze (started/stopped)? W tej chwili restartuje codziennie serwer po 3-4 razy i za każdym razem dostaje serię maili dla każdej usługi z osobna. Nie chcę aby były blokowane maile dotyczące zdarzeń np. o zablokowanym adresie IP, tylko started/stopped.
2) Co sądzisz o honeypot'ach, ma to w ogóle jakikolwiek sens? Tak myślałem że skoro już korzystamy z niestandardowego portu SSH, to pod standardowy można ustawić honeypot'a, który będzie robić głupa z atakującego i tym samym go zniechęci do dłuższych zabaw.

[Pan Kot 1535]

Archi,

 

Dzięki za tutorial. Mam dwa pytania:

1) Czy da się wyłączyć powiadomienia na email z fail2ban o usłudze (started/stopped)? W tej chwili restartuje codziennie serwer po 3-4 razy i za każdym razem dostaje serię maili dla każdej usługi z osobna. Nie chcę aby były blokowane maile dotyczące zdarzeń np. o zablokowanym adresie IP, tylko started/stopped.

2) Co sądzisz o honeypot'ach, ma to w ogóle jakikolwiek sens? Tak myślałem że skoro już korzystamy z niestandardowego portu SSH, to pod standardowy można ustawić honeypot'a, który będzie robić głupa z atakującego i tym samym go zniechęci do dłuższych zabaw.

 

1. Sam chciałem się w to zagłębić i generalnie na pewno się da, ale wymaga to zaawansowanych modyfikacji i nie jest tak proste jak zmiana jednego configa. Wiem co czujesz bo sam dostaję lawinę przy każdym updacie CSF'a (mam tam restart fail2ban zaincludowany), ale chyba trzeba z tym żyć. Przynajmniej wiesz, że działa .

EWENTUALNIE jeśli aż tak bardzo chcesz to można zawsze to filtrować po stronie serwera lub serwera pocztowego, tak żeby nie wysyłał wiadomości o konkretnej treści. Czy gra warta świeczki? Tak samo jak edity kodu, jak się komuś nudzi to pewno, ale na ogół niezbyt.

 

2. Honeypoty są zbędne, przynajmniej dla mnie. Niepotrzebnie obciążają system i "bawią się" z potencjalnymi włamywaczami. Co Ci da informacja co bot robi z przejętym rootem na ssh? Pewno dołącza do jakiegoś botnetu, kradnie wszystko co znajdzie i ukrywa swoją obecność, nic więcej. Wg. mnie nie ma sensu bawić się w niepotrzebne honeypoty, które jedyne co robią to zajmują zasoby .

 

Oczywiście to tylko mój punkt widzenia, nie zdziwię się jak zaraz któryś z użytkowników wytłumaczy Ci dlaczego honeypoty są istotne, ale "to be honest" nie widzę praktycznego zastosowania ani potencjalnego zwiększenia security. Co najwyżej pośrednie zdezorientowanie potencjalnego hakera.

Edytowano Lipiec 6, 2013 przez Archi (zobacz historię edycji)

[Rolej 58]

Mówiłeś tutaj o izolowaniu aplikacji od reszty systemu. Mam przez to rozumieć, że każdą jedną aplikacje mam instalować na innym userze i ją jakoś zablokować, tak?

[Pan Kot 1535]

@Rolej

Otóż to. Przyjrzyj się chociażby takiemu nginxowi czy apache'owi. Master proces działa jako root, ale wszystkie swoje dzieci (workerów) forkuje z userem www-data, czyli de facto procesy obsługujące samego apache'a działają na userze www-data, a nie roocie. Na roocie działa tylko master proces, który odpowiada za forki.

 

Taką politykę ma większość aplikacji, proftpd który działa na userze ftp, bind9 który działa na userze bind, mysqld który działa na userze mysql i wiele innych.

 

 

 

 

Tak to chociażby wygląda u mnie. Nawet serwer TS'a i music bot jest oddzielony i działa na innym userze. Zauważ, że nawet interpretery php są u mnie oddzielone i każdy vhost ma swojego usera.

 

Dodatkowo jeśli to user serwisowy czyt. nikt nie musi się na niego logować via SSH to bardzo dobrym pomysłem jest mu zabronić logowania poprzez zmianę shella na /bin/false. W przeciwnym wypadku np. jeśli to user FTP to bardzo dobrym pomysłem jest użycie jaila sftp-internal, o którym napisałem w pierwszym poście. Jeśli obowiązkowo musi on mieć shella to dobrym pomysłem jest opcja GRSecurity Untrusted + Enforce przez co nie może on odpalać żadnych własnych binarek, a korzystać wyłącznie z tego co już jest w systemie. To czasem się przydaje np. jeśli chcesz użytkownikowi pozwolić tylko na bardzo podstawowe akcje na systemie, a ubezpieczyć się na ew. exploity - nie skompiluje i nie uruchomi niczego co sam wgra.

Edytowano Sierpień 25, 2013 przez Archi (zobacz historię edycji)

[Rolej 58]

I robiąc coś takiego wystarczy, że zablokuje typa w jego home np.:

adduser ts3 -home /home/ts3

i będzie gotowe?

[Pan Kot 1535]

Oczywiście, że nie. Generalnie taką komendą tylko dodajesz usera i wskazujesz mu home, który i tak jest przecież identyczny jak opcja bez parametru -home.

 

Poczytaj o chroot jak chcesz mieć pełną izolację. Jak się pobawisz to wrzucisz userowi shella + wymagane biblioteki dla TS'a. Ja się w chrooty nie bawię bo są zbyt problematyczne na dłuższą metę, zwykły user bez shella (/bin/false) + grsec untrusted i enforce mi wystarcza.

Edytowano Sierpień 25, 2013 przez Archi (zobacz historię edycji)

[Rolej 58]

No dobrze. To w takim razie mam jeszcze inne pytanie.

 

Jeżeli bym chciał to wykorzystać tworząc hosting stron WWW (np. ogólnodostępny, darmowy) - to takie rozwiązanie jak wskazałeś (jedna aplikacja na jednego usera) by dało coś do bezpieczeństwa hostingu?

[Pan Kot 1535]

Jeśli w ten sposób do tego podchodzisz "czy to by coś dało" to nie, nic nie da bo będzie milion innych dziur w samej aplikacji .

 

Security polega na łataniu niewielkich dziur, a wprowadzenie całości zmian dopiero daje zadowalający efekt. Jeśli nie rozumiesz jak to działa i po co to jest to nie klep na ślepo komend tylko poczekaj na sytuację, aż będziesz musiał zrozumieć .

[Rolej 58]

Póki co nic nie zakładam, ponieważ chce się dowiedzieć wszystkich interesujących mnie rzeczy Dopiero jak je zbiorę to połączę w całość i wyjdzie "coś".

[Pan Kot 1535]

Ostatnio znalazłem świetnego patcha na kernela, który dodaje zapomnianą z jakiegoś powodu przez developerow Linuxa flagę kompilacyjną -march=native.

 

-march pozwala sprecyzować na jaką architekturę, a konkretniej, na jaki procesor lub rodzinę procesorów kompilujemy kernela.

 

-march=native mówi GCC, że kompilujemy pod maszynę na której kompilujemy. Dzięki temu GCC zna m.in rozmiar cache'y L1/L2/L3, a także wspierane instrukcje (np. SSE, AVX), przez co kompilator jest w stanie wygenerować kod zoptymalizowany na "maksa" dla danego dedyka. To przekłada się na sporą poprawę wydajnościową, którą można podejrzeć np. tutaj.

 

Z racji, że ja osobiście kernela i tak rekompiluję po to, żeby dodać grseca, to zainteresowałem się bardziej tą łatką, skompilowałem kernela z -march=native i miło się zdziwiłem. Oczywiście musiałem nieco tą łatkę poprawić, żeby ładnie się aplikowała na kernele już spatchowane grseciem.

 

Ale do rzeczy.

 

Oryginalna łatka na kernele "vanilla", czyli nieruszane, pobrane bezpośrednio z kernel.org: https://raw.githubusercontent.com/graysky2/kernel_gcc_patch/master/enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v3.15+.patch

Moja łatka na kernele "grsec", czyli kernele vanilla spatchowane najnowszym grsecurity: https://raw.githubusercontent.com/JustArchi/kernel_gcc_patch/master/enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v3.15+.patch

 

Łatkę aplikujemy w ten sam sposób co każdą inną, czyli np. cd /path/do/kernela && patch -p1 <../latka.patch

 

Potem wystarczy skonfigurować config (make menuconfig) i upewnić się, że włączyliśmy:

CONFIG_MNATIVE=y

 

Polecam.

Edytowano Listopad 1, 2014 przez Archi (zobacz historię edycji)

[Rolej 58]

Daawno tutaj nikt się nie odzywał, to Ja powrócę do tematu, gdyż mam kilka wątpliwości a chce je rozwiać.

 

1) Chce korzystać ze środowisk w jailach. Jaile chce wykonać przy użyciu jailkita. Wszystkie potrzebne mi rzeczy w danym jailu dopisuje do jk_init.ini, nie ma z tym problemu jednak chce aby w obrębie tego danego jaila user mógł instalować pakiety na które poniekąd chce mu pozwolić (i z dpkg -i *.deb i apt-get install {name}). Jak mogę mu na to pozwolić? Co bym musiał udostępnić użytkownikowi by mógł instalować pakiety, które będą dostępne tylko w jego jailu?

2) Na swoim serwerze mam zainstalowany fail2ban. Pozmieniałem nieco wartości w jego configu by był nieco bardziej restrykcyjny, jednakże na serwerze będą znajdować się aplikacje, których nie ma w filtrach (e.g. TS3, SA:MP, MTA:SA etc.). Jak wygląda tworzenie filtrów do fail2bana? Czy mogę bez obaw o działanie jego samego tworzyć filtry w oparciu o podane już gotowce czy muszę o czymś szczególnym pamiętać?

3) Jako, że również korzystasz z OVH (oraz kimsufi) - powyższa łateczka jest już zaimpletowana w wersje kerneli by OVH?

a) Nieco odchodząc od security - ta łatka daje dość dużą optymalizacje przy instalowaniu serwerów gier, głosowców itp.?

[Pan Kot 1535]

Daawno tutaj nikt się nie odzywał, to Ja powrócę do tematu, gdyż mam kilka wątpliwości a chce je rozwiać.

 

1) Chce korzystać ze środowisk w jailach. Jaile chce wykonać przy użyciu jailkita. Wszystkie potrzebne mi rzeczy w danym jailu dopisuje do jk_init.ini, nie ma z tym problemu jednak chce aby w obrębie tego danego jaila user mógł instalować pakiety na które poniekąd chce mu pozwolić (i z dpkg -i *.deb i apt-get install {name}). Jak mogę mu na to pozwolić? Co bym musiał udostępnić użytkownikowi by mógł instalować pakiety, które będą dostępne tylko w jego jailu?

2) Na swoim serwerze mam zainstalowany fail2ban. Pozmieniałem nieco wartości w jego configu by był nieco bardziej restrykcyjny, jednakże na serwerze będą znajdować się aplikacje, których nie ma w filtrach (e.g. TS3, SA:MP, MTA:SA etc.). Jak wygląda tworzenie filtrów do fail2bana? Czy mogę bez obaw o działanie jego samego tworzyć filtry w oparciu o podane już gotowce czy muszę o czymś szczególnym pamiętać?

3) Jako, że również korzystasz z OVH (oraz kimsufi) - powyższa łateczka jest już zaimpletowana w wersje kerneli by OVH?

a) Nieco odchodząc od security - ta łatka daje dość dużą optymalizacje przy instalowaniu serwerów gier, głosowców itp.?

 

1. User nie zainstaluje żadnych pakietów bez dostępu do roota, a jeśli chrootujesz go z rootem to robisz coś potencjalnie bardzo szkodliwego i powinieneś się zastanowić czy w ogóle wiesz co robisz. Jailkit powinien służyć wyłącznie do chrootowania userów, czyli zamykania ich, i w żadnym wypadku zchrootowany user nie może być rootem, jeśli chcesz zamykać rooty to musisz się zainteresować wirtualizacją, a nie jailkitem.

2. Można dodawać własne filtry bez obaw, najwyższej fail2ban się wywali z błędem konfiguracyjnym jak coś będzie nie tak, ale od tego jest service fail2ban configtest, a jeśli on tego nie obsługuje to service fail2ban reload.

3. Oczywiście, że nie. Kernel OVH jedyne co w sobie może mieć poza configiem pod maszynę to grseca, o ile masz zamiar użyć kernela z wariantu grspax, bo zwykły wariant grseca od OVH nawet nie ma zaimplementowanego PAXa w trybie enforce, więc jest to wyłącznie pewna ilość łatek i nic więcej.

 

Optymalizacja jest wyczuwalna. Kernel jako taki nie ma zbyt dużego overheadu, bo robi tylko to co zlecają mu aplikacje wyżej, ale jest w stanie niektóre z tych operacji chociażby upakować ładnie w cache'u dzięki -march=native, co przekłada się na mniejsze ilości cache missów i potencjalnie większą wydajność chociażby w sprawie dostępu do pamięci.

[Rolej 58]

1. Żeby nie obecne ograniczenia Kimsufów na adresy IP to dawno bym zainwestował w wirtualizację. Czyli pozostaje mi nic innego jak instalowanie wszystkiego ręcznie i udostępnianie w jailach dla userów.

3. Używam wariantu z paxem, innej racjonalnej opcji od OVH nie widziałem. Czyli na obecną chwilę pozostaje mi zabawa z kompilacją jąder.

 

Dzięki wielkie za odpowiedź

[blfr 225]

Nie potrzebujesz oddzielnego, publicznego IP, żeby stworzyć wirtualne serwery. Możesz je z powodzeniem schować za NAT.

[Rolej 58]

Wiem o tym, jednakże nie chce podejmować się tego. NATowanie sieci chce sobie zostawić jako ostateczność.