NFsec Logo

tcp_killer – wycinanie połączeń TCP w systemie

Wczoraj w Administracja Możliwość komentowania tcp_killer – wycinanie połączeń TCP w systemie została wyłączona

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

TCP BBR – nowy algorytm kontroli przeciążenia od Google

23/07/2017 (4 tygodnie temu) w Administracja Brak komentarzy.

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ść… ]

Zbyt szerokie uprawnienia w MongoDB 3.4.X

17/07/2017 (5 tygodni temu) w Administracja, Bezpieczeństwo Brak komentarzy.

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

Zarządzanie logami dla dedykowanych i prywatnych serwerów

12/06/2017 w Administracja Brak komentarzy.

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.

Retransmisje TCP

19/05/2017 w Administracja Brak komentarzy.

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ść… ]

Pupilki vs bydło

03/04/2017 w Administracja Brak komentarzy.

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

Ustawienie zmiennej środowiskowej TZ oszczędza tysiące wywołań systemowych

26/02/2017 w Administracja, Debug Brak komentarzy.

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ść… ]

Ubuntu 14.04, 16.04 LTS i błąd out of memory (oom) killer

29/01/2017 w Administracja, Debug Brak komentarzy.

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

OpenSCAP – hartowanie systemów CentOS 7 oraz RedHat 7 do PCI DSS

06/11/2016 w Administracja, Bezpieczeństwo Brak komentarzy.

O

penSCAP jest implementacją open source protokołu Security Content Automation Protocol, czyli SCAP, który analizuje system pod kątem zgodności ze standardami bezpieczeństwa. Przestrzeganie wytycznych i wskazówek w tym protokole umożliwia infrastrukturze opartej o system Linux spełnienie standardów przeznaczonych dla systemów klasy Enterprise oraz tych przewidzianych w PCI DSS. Do dyspozycji mamy narzędzie GUI (scap-workbench) lub dla linii poleceń (openscap-scanner), które umożliwiają nam przeskanowanie systemu pod względem zgodności z wybraną wcześniej polityką. Jeśli chcemy na poważnie potraktować wszystkie zalecenia, z którymi będziemy mogli zapoznać się w końcowym raporcie najlepiej od razu użyć wtyczki do anakondy – pozwoli ona na przeprowadzenie analizy bezpieczeństwa już podczas procesu instalacji systemu. W ten sposób nie będziemy musieli się martwić np. o jego przepartycjonowanie. Jeśli nasza dystrybucja różni się od rodziny Red Hat zawsze możemy przestudiować Przewodnik Bezpieczeństwa SCAP.

Więcej informacji: Make a RHEL7 server compliant with PCI-DSS, Security Harden CentOS 7, Contributing to SCAP Security Guide

Szybka analiza php.ini

05/10/2016 w Administracja, Bezpieczeństwo Brak komentarzy.

D

la każdego początkującego administratora / developera / devops’a przychodzi moment, gdy następuje faza skonfigurowania PHP po stronie serwera. W procesie tym zazwyczaj ustawiane są podstawowe opcje, które mają na celu jak najszybsze doprowadzenie do stanu: działa. Nie zawsze idzie to w parze: działa bezpiecznie. W tym celu powstało narzędzie iniscan mające na uwadze wprowadzenie najlepszych praktyk konfiguracji PHP, aby zminimalizować ryzyko przedostania się do serwera WWW szkodliwego kodu lub nawet uzyskania do niego pełnego dostępu.
[ czytaj całość… ]

Strona 1 z 1512345...1015...Ostatnia »