C

zy ten plik to malware? Zależy jakiego silnika antywirusowego się spytasz. Podobnie jest w temacie znajdowania lokalizacji adresu IP, ponieważ powiązanie rzeczywistej lokalizacji z adresem IP jest prawie niemożliwe do pewnego poziomu dokładności (np. ulicy, miasta). Wiele osób od razu podniesie głos sprzeciwu odnosząc się do dostawców usług oferujących geolokalizację adresów IP. Tak, istnieją bazy zawierające informacje o lokalizacji geograficznej adresu IP. Niektóre nawet twierdzą, że mają bardzo dokładne informacje, ale czy są one wiarygodne? Rzućmy okiem na adres: 188.130.189.153. W tym celu skorzystamy z serwisów zawartych na stronie: resolve.rs, ponieważ uwzględnia ona bardzo dużo dostawców typu IP2GEO, z którymi możemy sprawdzić wspomniany adres IP. Przechodząc przez poszczególne serwisy i zadając im zapytanie o ten sam adres widzimy wiele różnic w wynikach. W momencie pisania tego wpisu wyniki były, co najmniej mylące nawet na poziomie kraju.
[ czytaj całość… ]

Po aktualizacji do systemu macOS Monterey (12.1) za każdym uruchomieniem komputera pojawia się komunikat: Komputer został wyłączony z powodu problemu. Naprawa polega na usunięciu plików z raportami diagnostycznymi: sudo su -; rm -dRfv /Library/Logs/DiagnosticReports/*.*.

Więcej informacji: You shut down your computer because of a problem upon every single boot

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

S

ysdiagnose to narzędzie, które znajduje się na większości urządzeń z systemem macOS i iOS. Służy ono do zbierania informacji diagnostycznych dotyczących całego systemu. Obecna wersja – 3.0 zbiera duże ilości danych z szerokiej gamy lokalizacji w systemie. Mogą one być przydatne w informatyce śledczej komputera prowadzonej na żywo. W przypadku poszukiwań złośliwego oprogramowania przechwycone dane mogą pomóc w zidentyfikowaniu zainfekowanego pliku binarnego; mechanizmu persystencji (gdy złośliwe oprogramowanie uzyska dostęp do systemu, często chce zostać tam przez długi czas opracowując metody pozwalające na jego powrót po restarcie systemu; jeśli mechanizm persystencji jest wystarczająco unikalny, może nawet służyć jako świetny sposób na określenie cechy charakterystycznej danego złośliwego oprogramowania) lub połączeń do C2 (serwery Command and Control – nazywane również C&C odnoszą się do sposobu, w jaki atakujący komunikują się i sprawują kontrolę nad zainfekowanym systemem; po zainfekowaniu systemu większość złośliwego oprogramowania komunikuje się z serwerem kontrolowanym przez atakującego, aby przyjmować polecenia, pobierać dodatkowe komponenty lub wykradać informacje).
[ 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ść… ]

0. Utworzenie pliku:

touch .findmehere

1. Lokalizacja obiektu w systemie plików:

ls -i .findmehere

15466911 .findmehere

2. Zakodowanie wiadomości:

while read -n1 char; do printf "%d " \'$char; done

C67 T84 F70 .46 f102 l108 a97 g103

3. Umieszczenie wiadomości w pliku:

sudo debugfs -w -R 'set_inode_field /home/ctf/.findmehere \
version 6784704610210897103' /dev/sda2

4. Sprawdzenie zapisu wiadomości:

sudo debugfs -R 'stat <15466911>' /dev/sda2

Inode: 15466911 Type: regular Mode: 0640   Flags: 0x80000
Generation: 1555060808 Version: 0x5e281ce5:65935ccf
User: 0 Group: 0 Project: 0 Size: 0
File ACL: 0
Links: 1 Blockcount: 0
Fragment:  Address: 0 Number: 0 Size: 0
 ctime: 0x5d8faaf2:5d64fd54 -- Sat Sep 28 20:48:18 2019
 atime: 0x5d8faaf2:5d64fd54 -- Sat Sep 28 20:48:18 2019
 mtime: 0x5d8faaf2:5d64fd54 -- Sat Sep 28 20:48:18 2019
crtime: 0x5d8faaf2:5d64fd54 -- Sat Sep 28 20:48:18 2019
Size of extra inode fields: 32
EXTENTS:

5. Weryfikacja wiadomości:

printf "%d\n" 0x5e281ce565935ccf

6784704610210897103

for i in `echo 67 84 70 46 102 108 97 103`; do echo -ne \\x$(printf %02x $i); done

CTF.flag

Więcej informacji: Ext4 Disk Layout, Czas utworzenia pliku w Linuksie

C

url może być pomocnym narzędziem przy debugowaniu. Gdy na rozpoznanie problemu składają się problemy z: siecią, DNS, serwerem lub wydajnością samej webaplikacji – możemy bez wahania po niego sięgnąć. W celu izolacji problemu możemy uruchomić curl’a w następujący sposób:

curl -w "$(date +%FT%T) dns: %{time_namelookup} connect: %{time_connect}\
 firstbyte: %{time_starttransfer} total: %{time_total} HTTP: %{http_code}\n"\
 -o /dev/null -s "https://apka.dev"

Polecenie takie puszczone w pętli da nam ładny podgląd na każde żądanie HTTP:
[ 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ść… ]

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