P

o wykonaniu aktualizacji z Elasticsearch z 6.8.14 do 6.8.20 w pliku logu pojawia się ciągle powtarzająca się wiadomość: cannot compute used swap when total swap is 0 and free swap is 0. Dzieje się tak ze względu na tą zmianę. Jeśli na naszej maszynie wirtualnej / fizycznej wyłączony jest plik wymiany oraz włączony monitoring to, co 10 sekund będziemy mieli zapychane logi tym wpisem. W celu wyfiltrowania tego typu wiadomości, należy do pliku /etc/elasticsearch/log4j2.properties dołączyć następujące wpisy w sekcji appender.rolling:

appender.rolling.filter.regex.type = RegexFilter
appender.rolling.filter.regex.regex = cannot compute used swap.*
appender.rolling.filter.regex.onMatch = DENY
appender.rolling.filter.regex.onMismatch = NEUTRAL

Więcej informacji: Log4j RegexFilter

Zestaw danych projektu Sonar Rapid7 to niesamowite zasoby wiedzy. Są w nich zawarte wyniki skanowania internetu w skompresowanej i łatwej do pobrania formie. W tym wpisie skupimy się na dwóch rodzajach danych: Reverse DNS (RDNS) (czyli rekordy PTR) oraz Forward DNS (FDNS) (czyli rekordy: ANY, A, AAAA, TXT, MX oraz CNAME). Niestety praca z surowymi zestawami danych może być nieco wolniejsza, ponieważ pakiety rekordów RDNS oraz FDNS zawierają kilkanaście GB skompresowanego tekstu. Przeszukiwanie takich dużych plików może zajmować kilkanaście lub więcej minut dla pojedynczych kwerend. Możemy przyśpieszyć taką operację poprzez wykorzystanie wyszukiwania binarnego na odpowiednio posortowanych danych – lub wykorzystać do tego rodzaju operacji systemy wręcz stworzone do przechowywania i przeszukiwania tego rodzaju rekordów.
[ czytaj całość… ]

2

1 października został opublikowany eksploit wykorzystujący już załataną lukę w komponencie GUI do wizualizacji danych Elasticsearch o nazwie Kibana. Elasticsearch i Kibana są częściami popularnego stosu narzędzi o nazwie Elastic Stack (znanego również jako ELK Stack) – serii otwartych aplikacji służących do scentralizowanego zarządzania logami i nie tylko. CVE-2019-7609 to luka w zabezpieczeniach umożliwiająca wykonywanie dowolnego kodu w rozszerzeniu Kibany – Timelion. Luka została naprawiona w lutym 2019. Zgodnie z poradą firmy Elastic dotyczącą luki osoba atakująca, które ma dostęp do aplikacji Kibana oraz rozszerzenia Timelion “może wysłać żądanie, które spróbuje wykonać kod JavaScript”, co może spowodować, że zostanie wykonane dowolne polecenie na hoście o tych samych uprawnieniach, na których jest uruchomiony silnik nodejs Kibany.
[ czytaj całość… ]

Nasze maszyny posiadają następujące parametry: 64 GB RAM oraz 32 wątków CPU (z HT). Jest na nich uruchomiony ElasticSearch v5 z złotą zasadą 50% na heap oraz 50% na cache systemu plików. Oczywiście heap jest ustawiony tak, aby nie przekraczał trybu “zero-based”, czyli w tym przypadku 30720 MB:
[ czytaj całość… ]

W

poprzedniej części zebraliśmy i przygotowaliśmy do wstępnej obróbki zbiór danych pochodzący z skracarek URL. W tej części zajmiemy się jego umieszczeniem w silniku wyszukiwania, który umożliwi nam bardzo szybkie pozyskiwanie interesujących nas informacji. Jak wcześniej wspomnieliśmy na naszej maszynie wirtualnej uruchomiony jest system Ubuntu 18.04 LTS. Sama maszyna ma 2 CPU / 4 GB RAM oraz 100 GB dysku z czego 57 GB jest już zajęte przez ściągnięte, skompresowane dane. W tej części artykułu interesuje nas stworzenie następnego przepływu danych:

[/data/archive/*/*/*.txt] --> [logstash] --> [elasticsearch] --> [kibana]

[ czytaj całość… ]

J

eśli chcemy odbyć krótką rozmowę o wydajności producenta kafki (w kontekście: logstash → kafka ← logstash → elasticsearch) musimy porozmawiać o dwóch rzeczach. Po pierwsze: opóźnieniu – ile czasu upłynęło od czasu wywołania metody send(), dopóki komunikat nie pojawi się na brokerze. Po drugie: przepustowości – ile wiadomości może wysłać producent do brokera na sekundę. Dlaczego musimy obawiać się o te dwie wartości? Jeśli procesowanie wiadomości zajmuje nam 10 milisekund (opóźnienie) to wyraźnie przepustowość jest ograniczona do 100 wiadomości na sekundę. Patrząc na to w ten sposób można dojść do wniosku, że im wyższe opóźnienie tym większa przepustowość. Jednak związek między opóźnieniem, a przepustowością nie jest tak trywialny.
[ czytaj całość… ]

W

edług “Wprowadzenia do systemów rozproszonych” charakterystyczne opóźnienie pomiędzy węzłami ( serwerami / agentami / procesami / aktorami ) wynika z: operacji wewnątrz samych węzłów, które są “szybkie“; operacji pomiędzy węzłami, które są “wolne” – co jest szybkie, a co wolne zależne jest od tego, co wykonuje sam system. Za przykład posłuży nam klaster, który komplet danych utrzymuje po części na każdym węźle wchodzącym w jego skład. Czyli klient odpytując klaster o część interesujących go danych może odpytać o nie dowolny węzeł, ale musi poczekać aż jego odpowiedź zostanie złożona z danych zwróconych przez każdego uczestnika w klastrze. Tak na przykład działa shardowanie danych w Elasticsearch.
[ czytaj całość… ]

W

raz z użyciem w systemie Ubuntu 14.04 LTS jądra z dystrybucji 16.04, czyli Xenial (4.4.0) do obsługi procesorów z rodziny Intel (Sandy Bridge lub nowsze) używany jest sterownik intel_pstate. Na temat jego pracy istnieje wiele opracowań. Czasami wypada lepiej, a czasami gorzej. Wszystko zależy od bardzo wielu czynników np. konfiguracji sprzętu, wykorzystanego oprogramowania, charakterystyki obciążania maszyn zadaniami itd. Dlatego przed nadzieją na szybki zysk wydajności, jak zawsze należy wykonać testy na swoim środowisku zamiast ślepo ufać obcym opracowaniom. Na przykład dla serwerów ElasticSearch oraz PrestoDB bardziej opłacalnym wariantem okazało się trzymanie procesora na stałej częstotliwości (intel_pstate=disable) niż pozwalanie mu na wchodzenie na niższe wartości (zarówno wariant powersafe, jak i performance). Przełożyło się to na zmniejszenie czasów odpowiedzi (obrazek #1 – Elastic) oraz spadek obciążenia maszyn (obrazek #2 – Presto).

Więcej informacji: Intel CPUs: P-state, C-state, Turbo Boost, CPU frequency, Why does the CPU frequency fluctuate when using the performance governor?

W

2015 roku, dane 13 milionów użytkowników programu MacKeeper wyciekły, z powodu przechowywania ich w otwartej bazie MongoDB. Wówczas, sam autor wyszukiwarki shodan.io przeprowadził badanie i wykrył, że publicznie dostępnych jest około 600 TB danych. Po publikacji wyników badania w lipcu ubiegłego roku, już w grudniu okazało się, że ilość publicznie dostępnych baz NoSQL wzrosła o 5 tysięcy, a ilość danych osiągnęła wolumen 685 TB. Świat devopsów, zamiast wyciągnąć z zaistniałej sytuacji, jeszcze bardziej pogrążył się w koszmarze nieautoryzowanego dostępu do danych.
[ czytaj całość… ]