Skocz do zawartości


 

Zdjęcie

Koty na WHT, Fakty i Mity + Poradnik

Koty na WHT, Fakty i Mity + Poradnik

  • Proszę się zalogować aby odpowiedzieć
67 odpowiedzi na ten temat

Koty na WHT, Fakty i Mity + Poradnik

#61 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 25 sierpień 2013 - 18:14

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ć ;).


  • 0

#62 Rolej

Rolej

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 616 postów
  • Skąd:Szczecinek
  • Firma:Profil prywatny
  • Imię:Przemek
  • Nazwisko:Jagielski

Napisany 25 sierpień 2013 - 18:29

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ś".


  • 0

#63 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 01 listopad 2014 - 14:28

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.githubus...el_v3.15 .patch

Moja łatka na kernele "grsec", czyli kernele vanilla spatchowane najnowszym grsecurity: https://raw.githubus...el_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.


Edytowany przez Archi, 01 listopad 2014 - 14:32.

  • 6

#64 Rolej

Rolej

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 616 postów
  • Skąd:Szczecinek
  • Firma:Profil prywatny
  • Imię:Przemek
  • Nazwisko:Jagielski

Napisany 24 lipiec 2015 - 17:17

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.?   


  • 0

#65 Pan Kot

Pan Kot

    Mrrr

  • Zbanowani
  • PipPipPipPipPipPipPipPip
  • 2819 postów

Napisany 26 lipiec 2015 - 14:00

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.


  • 1

#66 Rolej

Rolej

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 616 postów
  • Skąd:Szczecinek
  • Firma:Profil prywatny
  • Imię:Przemek
  • Nazwisko:Jagielski

Napisany 26 lipiec 2015 - 15:19

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ź ;)


  • 0

#67 blfr

blfr

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 1208 postów

Napisany 26 lipiec 2015 - 16:20

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

#68 Rolej

Rolej

    Weteran WHT

  • WHT Pro
  • PipPipPipPipPipPipPipPip
  • 616 postów
  • Skąd:Szczecinek
  • Firma:Profil prywatny
  • Imię:Przemek
  • Nazwisko:Jagielski

Napisany 26 lipiec 2015 - 16:49

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


  • 0





0 użytkowników czyta ten temat

0 użytkowników, 0 gości, 0 anonimowych użytkowników