A

naliza wydajności często jest ograniczona przez brak widoczności różnych zjawisk zachodzących w systemie. Obserwacja tych zjawisk pozwala inżynierom systemów łatwo identyfikować elementy, które zawierają ograniczenia i mogą być szybsze. “Najnowszym” narzędziem do obserwacji systemu operacyjnego Linux jest BPF (ang. Berkeley Packet Filter). Został on opracowany w 1992 roku, aby zapewnić sposób filtrowania pakietów sieciowych oraz uniknięcia ich bezużytecznego kopiowania z przestrzeni jądra do użytkownika. Początkowo składał się z prostego kodu bajtowego, który był wstrzykiwany z przestrzeni użytkownika do jądra. Tam był sprawdzany przez weryfikator – w celu uniknięcia krachu jądra lub problemów z bezpieczeństwem – i dołączany do gniazda, a następnie uruchamiany na każdym odebranym pakiecie.
[ czytaj całość… ]

P

otężny administrator systemu postanowił stworzyć bramę do ukrytego wymiaru. Dla niepoznaki zrobił to w katalogu domowym zwykłego użytkownika. By chronić portal przed różnymi daemonami rzucił na niego zaklęcie zdejmujące wszystkie prawa dostępu:

:~# bash -c "echo 'Niedostrzegalne barwy - czarne wodospady' > \
/home/agresor/ukryty_wymiar"
:~# chmod 0000 /home/agresor/ukryty_wymiar

Podczas powrotu do swojego katalogu ($HOME) użytkownik zauważył dziwne wrota:

agresor@darkstar:~$ ls -lah ukryty_wymiar
---------- 1 root root 39 Aug 24 21:01 ukryty_wymiar

Dookoła nich krążyły już Kerberos, Sphinx oraz sam Dracula. Widząc to, w użytkowniku wezbrał niepohamowany gniew, który przekształcił w ukrytą moc zniszczenia. Użytkownik wiedział, że bez księgi sudo nie jest w stanie zniszczyć portalu potężnego administratora, ale postanowił chociaż spróbować:
[ czytaj całość… ]

J

ason Geffer z Google stworzył mały skrypt w języku Python, który jest podobny do cuttera. Potrafi zerwać połączenie TCP w systemach Linux oraz MacOS. Wystarczy skopiować lokalny oraz zdalny adres z polecenia netstat -lanW :

apt install python-pip
pip install frida
wget https://raw.githubusercontent.com/google/tcp_killer/master/tcp_killer.py
chmod +x tcp_killer.py
python tcp_killer.py 127.0.0.1:12345 127.0.0.1:48882

Więcej informacji: tcp_killer

B

ottleneck Bandwidth and RTT, czyli BBR jest nowym algorytmem kontroli przeciążenia TCP od firmy Google. Został on przetestowany w jego centrach danych, jak i frontowych serwerach takich stron jak: Google.com oraz YouTube.com. Dąży on do optymalizacji zarówno przepustowości, jak i opóźnienia – RTT. Jak wspomina samo Google po wprowadzeniu tego mechanizmu do swojej usługi publicznej chmury obliczeniowej, uzyskał średnio od 4% – 14% większą przepustowość sieciową. Pierwsze publiczne wydanie BBR nastąpiło we wrześniu 2016 roku. Do jego użycia wymagane jest posiadanie jądra w wersji 4.9 lub wyższej, w przeciwnym wypadku wymagane jest nałożenie łatki i rekompilacja jądra.
[ czytaj całość… ]

J

eśli zainstalujemy natywną paczkę MongoDB w dystrybucji Ubuntu 16.04 LTS w wersji 2.6.10 i po jej uruchomieniu przejdziemy do katalogu, gdzie są przechowywane metadane i bazy – wówczas prawa dostępu do plików i katalogów będą wyglądać tak. Niestety jeśli podążymy drogą oficjalnej instrukcji instalacji dla wersji 3.4 (tutaj 3.4.6) to już prawa dostępu będą wyglądać tak. Od razu widać, że uprawnienia te są zbyt szerokie i każdy użytkownik posiadający konto na serwerze jest w stanie wykonać pełną kopie wszystkich danych z tego katalogu (np. za pomocą programu tar). Okazuje się, że błąd ten jest znany od 2015 roku. Stanowić to może poważny problem bezpieczeństwa dla hostingu oraz usług współdzielonych oferujących tego typu bazę. Każdy użytkownik jest w stanie pozyskać dane “sąsiadów” i nie musi nawet posiadać konta z aktywną powłoką – zawsze może uruchomić zadanie cron, które skopiuje mu dane do jego katalogu przewidzianego dla strony www, później pobierając je przy pomocy HTTP, czy FTP. Rozwiązaniem tego błędu jest przywrócenie poprawnych praw dostępu do katalogu /var/lib/mongodb:

chmod o-rx /var/lib/mongodb

oraz modyfikacji umask dla użytkownika mongodb.

Więcej informacji: MongoDB at shared hosting: security surprises

J

eśli jesteśmy szczęśliwymi właścicielami dedykowanego lub prywatnego serwera na własne potrzeby – ze względu na bezpieczeństwo (zapasowe źródło zdarzeń, jakie zaszły na serwerze w przypadku incydentu bezpieczeństwa) oraz możliwości dynamicznej analizy danych – warto pomyśleć nad wysyłaniem wszystkich logów systemowych oraz aktywności dedykowanych aplikacji do dodatkowego, zdalnego źródła. Oczywiście nie mowa tutaj o drugim serwerze, z którym wiążą się dodatkowe koszty utrzymania, ale serwisach, które za darmo umożliwią nam taki proces:

• papertail – przechowywanie: 7 dni wstecz; ilość: 100MB/miesiąc; okno wyszukiwania: 48 godzin.
• logentries – przechowywanie: 7 dni wstecz; ilość: 5GB/miesiąc; okno wyszukiwania: 7 dni.
• loggly – przechowywanie: 7 dni wstecz; ilość: 200MB/dzień; okno wyszukiwania: 7 dni.
• sematext – przechowywanie: 7 dni wstecz; ilość: 500MB/dzień; okno wyszukiwania: 7 dni.
• sumologic – przechowywanie: 7 dni wstecz; ilość: 500MB/dzień; okno wyszukiwania: 7 dni.
• logz – przechowywanie: 3 dni wstecz; ilość: 1GB/dzień; okno wyszukiwania: 3 dni.
• xpolog – przechowywanie: 5 dni wstecz; ilość: 1GB/dzień; okno wyszukiwania: 5 dni.

Jedyną wadą tego rozwiązania jest krótki czas retencji zdalnego archiwum, ale zakładam, że raczej nikt nie przewiduje dłuższego czasu wykrycia / zauważenia anomalii w działaniu swojego serwera niż kilka godzin.

C

o się może złego dziać, jeśli czasy połączeń i odpowiedzi pomiędzy daemonami lub aplikacjami umieszczonymi na różnych serwerach losowo wahają się dochodząc nawet do wartości sekund? W dodatku liczba pakietów opuszczających serwer na wyjściu jest zauważalnie większa niż otrzymuje on do przetworzenia na wejściu. Wykluczając problemy wydajnościowe dotyczące utylizacji zasobów serwera, do którego się łączymy – pozostaje tylko jedno – sieć.
[ czytaj całość… ]

P

upilki – na początku nadajesz im nazwę. Później na tych serwerach instalujesz serwisy. Jeśli któryś zostaje zepsuty lub pojedynczy komponent zawodzi musimy go naprawić. Wymienić dysk twardy, odbudować uszkodzony system pliku i tak długo kontynuować opiekę aż wróci do zdrowia. Później pozostaje standardowe dbanie o pupilka – aktualizacje i nakładanie poprawek. Niektóre aplikacje do dzisiaj potrzebują takich pupilków, ale wiele stworzonych w tej dekadzie już nie! Dzisiaj wszystko się zmieniło. Za pomocą RESTowego API możemy stworzyć infrastrukturę i zbudować ją od zera aż do pełnej gotowości w ciągu kilku minut.

Bydło – w dobie chmur obliczeniowych jesteśmy w stanie robić bardziej dynamiczne rzeczy. Możemy łatwo zbudować szablon maszyny wirtualnej (tzw. “golden image“) wraz z uruchomioną aplikacją (od podstaw lub za pomocą migawki) i użyć jej w autoskalowalnym środowisku. Przy użyciu takich narzędzi, jak Ansible, Puppet, Salt oraz Chef możemy zbudować wcześniej przetestowaną infrastrukturę i ją odpalić w dowolnym momencie. 100 serwerów uruchomionych jednym poleceniem. Zamiast nazw operuje się liczbami. Wszystkie te serwery są zasadniczo identyczne. Jeśli jeden umiera wystarczy parę wywołań API (lub nawet nie – jeśli używamy automatycznego skalowania) i następuje zastąpienie wadliwej sztuki. Jeśli krowa jest poważnie chora lub konająca – zabijasz ją i kupujesz kolejną.

Więcej informacji: Pets vs Cattle

A

by zaoszczędzić dodatkowych wywołań systemowych na serwerze przez chodzący proces – wystarczy ustawić zmienną środowiskową TZ na wartość: :/etc/localtime. Spowoduje to, że glibc nie będzie wykonywać zbędnych, dodatkowych wywołań systemowych. Szczególnie sprawdza się to w systemach, w których ustawienie strefy czasowej nie jest cyklicznie przestawiane – lub istnieje możliwość restartu danego procesu, kiedy to występuje (w większości przypadków taka zmiana występuje tylko raz – zazwyczaj w polskich realiach jest to przestawienie z UTC na CET).
[ czytaj całość… ]

Jeśli podczas łatania np. DirtyCow na naszym serwerze wyposażonym w Ubuntu Trusty lub Xenial zainstalowane zostało jądro w wersji 4.4.0-59-generic i nagle wcześniej działające bez problemu aplikacje oraz daemony zaczęły zaliczać błędy typu: out of memory (brak pamięci) jest wielce prawdopodobne, że jest to spowodowane błędem, który wkradł się podczas rozwoju wersji. Tymczasowym rozwiązaniem do czasu aż zostanie wydany kolejny patchset naprawiający to zachowanie jest cofnięcie się do wersji: 4.4.0-57.

Więcej informacji: mm, oom: prevent premature OOM killer invocation for high order request