Tag: social media

Opublikowane w

Prywatność przeciw bezpieczeństwu

Zaczęło się od historii związanej z cyberbezpieczeństwem. Użytkownik zauważył włamanie na swoje konto LinkedIn. Zapytał w social media, co się mogło wydarzyć, czy możliwe przejęcie dostępu do skrzynki pocztowej bo tam przyszedł mail z kodem potwierdzającym logowanie[1]. I czy dobrym pomysłem jest zapytanie dostawcy poczty o logi z ostatnich logowań. Informacje – jak zwykle w takich przypadkach – niepełne. Bo i nie wiadomo, co dokładnie jest potrzebne, istotne, i nikt nie napisze wszystkiego publicznie w social media. Akurat miałem chwilę, więc zaproponowałem telefon. Użytkownik nie chciał podać numeru, gdyż prywatność. Trochę rozumiem. Trochę nie. No nic, spróbujemy poczatować.

Skrzynka email była u dostawcy poczty z „no log policy”, więc nie wróżyłem sukcesów. Zasugerowałem w pierwszej kolejności zmianę hasła do poczty, ustawienie tam 2FA (nie było). Konto LinkedIn zostało zablokowane, chcą weryfikacji dokumentem. Użytkownik ma opory przed przesłaniem go do firmy trzeciej. Trochę rozumiem, trochę nie.

Nie znam charakterystyki wykorzystania komputera, ani nawyków. Te sama hasła w różnych miejscach? Raczej wyciek czy raczej stealer? Użytkownik zrobił jakieś skany antywirusem (nic wyraźnego nie znalazło), zmienił hasła w innych usługach[2] i ustawiał 2FA (dobry pomysł).

Timeline ataku:

  • 12:58 – pierwszy mail z kodem,
  • 13:00 – zmiana hasła do konta LinkedIn,
  • 13:02 – drugi mail z kodem (zapewne atakujący loguje się nowymi danymi),
  • 13:05, 13:08, 13:10 – dodane własne maile przez atakującego (czemu aż 3?).

LinkedIn wysyła sześcioznakowy kod na maila w celu potwierdzenia logowania. Nie wygląda na łatwe do brute force, kod był generowany tylko jeden za każdym razem. Czyli wszystko wskazuje na to, że atakujący miał dostęp do skrzynki. Ba, może nawet w ogóle najpierw uzyskał dostęp do skrzynki, zobaczył, że powiązana z kontem LinkedIn i je zaatakował? Dość długie odstępy pomiędzy kolejnymi krokami. Czyżby ręczne działanie?

W każdym razie pożar ugaszony. Pozostało obserwować, czy coś dziwnego się nie dzieje i ewentualnie odzyskać konto LinkedIn.

Jednak użytkownik jest niezadowolony. Narzeka, że LinkedIn nie rozpoznał ataku, a przecież IP było nietypowe, z innego kraju. Działania nietypowe. Narzeka, że chcą dokumentów. Trochę rozumiem, trochę nie.

Bo przecież z punktu widzenia użytkownika wszystko było w oczywisty sposób nietypowe. A z punktu widzenia LinkedIn? I ich skali?

Z perspektywy LinkedIn było to prawdopodobnie „czyste” logowanie. Prawidłowe hasło podane za pierwszym razem. Kod został wysłany na maila i potwierdzony. Zapewne także od razu. IP z innego kraju? To od lat bardzo słaba wskazówka. Masa ludzi korzysta teraz z VPNów, wielu urządzeń, wielu ludzi po prostu podróżuje.

Wyobraźmy sobie, że jesteśmy na urlopie w dalekim kraju, dostajemy sygnał od znajomych, że dziwne rzeczy dzieją się z naszym kontem w jakimś serwisie. Logujemy się, potwierdzamy kod z maila, chcemy zmienić hasło do serwisu. A skoro atakujący potwierdzali kod, to może problem jest ze skrzynką email? Chcemy zmienić inną, zaufaną, tam, gdzie mamy 2FA i wiemy, że wszystko jest OK. No i co, serwis miałby nie pozwolić? Kazać weryfikować się dokumentem? Nie wyobrażam sobie tego – ludzie by ich zjedli.

Blokada konta do czasu weryfikacji dokumentu jest jakby standardem. Nie jest idealna, ale działa dla wszystkich[3], niezależnie czy ktoś płacił, czy zmieniał telefon, adres itp. Prosta procedura, bez wyjątków i warunków, to dobra procedura. Atakujący nie przekona pracownika, żeby sprawdził akurat coś, nad czym akurat ma kontrolę.

Uważam, że część winy ponosi tu ślepe zachwalanie prywatności. Obrońcy prywatności krzyczą, że fingerprinting urządzeń zły[4], że trzeba się bronić. AI złe bo przetwarza dane nie wiadomo jak, trzeba się nie zgodzić. No log policy ma świadczyć o poszanowaniu prywatności, a VPN „zwiększa prywatność i bezpieczeństwo”. Ludzie może nie do końca rozumieją o czym mowa i dlaczego, ale wierzą. Wierzą reklamom, wierzą autorytetom. O tym, że nie wszystko jest dobre dla każdego, łatwo zapomnieć i mało kto to podkreśla. Wierzę, że agitatorzy prywatności nie mają złych intencji. Ale zapominają o poziomie wiedzy odbiorców i zakładają, że użytkownik jest w stanie sam skutecznie zadbać o bezpieczeństwo. Tymczasem niekoniecznie.

Czy gdyby fingerprinting był możliwy i powszechny, ludzie nie korzystaliby z VPNów tylko z „normalnych” IP, to serwisy lepiej chroniłyby użytkowników, lepiej rozpoznawały anomalie i byłoby bezpieczniej? Niekoniecznie. I raczej się tego nie dowiemy. Bo zabezpieczenia to koszt, czym innym jest profilowanie użytkownika dla większego zysku z reklam, a czym innym dla poprawy bezpieczeństwa. Za to wiemy, że teraz po prostu nie mają możliwości tego robić. Nie sensownie[5], nie w dużej skali.

[1] Dlatego maile czy SMSy nie są dobrym 2FA. Oczywiście lepszy rydz, niż nic, ale 2FA powinno być na innym urządzeniu i niemożliwe przechwycenia.
[2] Niekoniecznie dobry pomysł, bo jeśli to stealer, to skrajnie może doprowadzić do pogorszenia sytuacji poprzez wycieku danych logowania do większej ilości serwisów.
[3] Żeby zrozumieć pewne rzeczy, potrzeba czasu, bo przecież sam narzekałem kiedyś na procedurę w Allegro. No, ale tam chodziło jednak trochę o coś innego, nie o sam fakt żądania dokumentu.
[4] Wystarczy przypomnieć ostatnią aferę, choć tam nie do końca o fingerprinting szło, a sprawy poszły za daleko.
[5] Dla jasności, systemy wykrywające anomalie nadal istnieją i działają. Skuteczność jest… różna. I jednak czym innym jest oznaczenie zdarzenia jako podejrzanego, a czym innym automatyczna blokada.

Opublikowane w

Sfederowany problem

Mamy trzy główne topologie czy też modele działania usług w sieci: scentralizowany, sfederowany[1] i rozproszony. Każdy z nich ma swoje wady, zalety i… problemy. W tym wpisie będzie o tym, czemu federacja nie zawsze jest dobrym pomysłem, jaki problem wprowadził z powodu wyboru sfederowanego modelu Mastodon. I co można z tym zrobić.

Wstęp

Na początek dla przypomnienia – albo dla kontekstu – Mastodon to serwer social media, w założeniu mający być – mniej więcej – alternatywą dla Twittera. Działaja w oparciu o protokół ActivityPub. Zamiast jednego, centralnego serwera, działającego pod jedną domeną[2] istnieje wiele serwerów. Każdy z nich ma swoją odrębną domenę, swojego administratora, swoją moderację i swoich użytkowników. A pod spodem – swoją własną bazę danych. Jednak przy tych wszystkich odrębnościach, w przeciwieństwie do sieci scentralizwoanych, serwery wymieniają się między sobą danymi, jeśli zachodzi taka potrzeba. Czyli na Bluesky nie polubimy tweeta, natomiast w przypadku wpisu na Mastodonie (toot) nie ma przeszkód by użytkownik jednego serwera polubił wpis z innego[3].

Typowo za przykład sieci zdecentralizowanej podawane są serwery popularnej usługi, jaką jest poczta elektroniczna (email). Niezależnie, czy „skrzynkę”[4] mamy na Gmail, Outlook, Onecie, Protonie czy własnym serwerze, możemy wysłać mail i za – pośrednictwem protokołu SMTP – dotrze on na serwer odbiorcy.

Osobiście uważam, że lepszym, bliższym przykładem usługi sfederowanej, do której można porównać Mastodona, są grupy dyskusyjne, działające w oparciu o protokół NNTP. Niestety, usługa nie jest już powszechnie używana czy znana, więc jako przykład przybliżający ideę słabo się nadaje. Jednak wydaje mi się lepsza, bo zachodziła interakcja między wieloma użytkownikami, którzy mogli swobodnie wchodzić w interakcję z treściami zamieszczonymi przez innych użytkowników. Nie było określonego przez nadawcę odbiorcy.

Technicznie działało to tak, że administrator uruchamiał serwer NNTP, ustalał z jakimi serwerami wymienia się treściami, jakie grupy, czyli treści będzie utrzymywał na swoim serwerze. I jacy użytkownicy mogą z jego serwera korzystać, czyli pobierać i zamieszczać treści. Z punktu widzenia użytkownika wyglądało to tak, że łączy się do jednego serwera, odbiera wiadomości z wybranych grup dyskusyjnych napisane przez różnych użytkowników. A jeśli coś napisze, to trafia to na wszystkie serwery, na których obsługiwana jest dana grupa.

Problem

Tyle tytułem wstępu, pora przejść do problemu. Serwer Mastodona może postawić każdy. Obecnie działa blisko 10 tys. serwerów Mastodon[5]. Gdy któryś z użytkowników zamieści toot z linkiem do strony WWW, to wszystkie serwery, na których na których znajdują się jego followers (obserwujący), generują podgląd strony. W tym celu każdy z serwerów wysyła żądanie do docelowego serwera WWW w celu pobrania strony? Gdzie problem? Ano w tym, że w przypadku kont z większą liczbą obserwujących, tych serwerów potrafi być wiele. I wysyłają te żądania w zbliżonym czasie. Z punktu widzenia ofiary, czyli serwera WWW do którego link zamieszczono to coś w rodzaju DDoS.

Temat nie jest nowy, był dokładnie opisany w 2022, z wykresami, schematem działania i ilością żądań. Gorąco polecam lekturę, szczególnie jeśli w moim opisie jest coś niejasnego. Jest tam też trochę o zasadności nazywania tego działania DDoSem. Oryginalne zgłoszenie na GitHub jest jeszcze starsze i pochodzi z roku 2017. Sam schemat „ataku” w pewnym sensie przypomina botnet, przy czym kontrolującym byłaby tu dowolna osoba zamieszczająca link w treści toota, a boty wykonują tylko jedno żądanie.

Tyle, że to wystarcza do zakłócenia działania zewnętrznych usług. O tym, że problem nie jest jedynie teoretyczny, świadczą niedawne przykłady z kraju:

Czy linki dodawane na fedi obciążają serwery www? Obciążają, bo po dodaniu linku, każdy sfederowany serwer zaciąga sobie jego podgląd.
[…]
Spotkałem się już z głosami, że to coraz poważniejszy problem, porównywalny z małym atakiem DDOS. Nie wiem na ile wpływa to na obciążenie mojej strony, ale na pewno jest zauważalne. Dlatego będę pamiętał, aby dodawać link nieco wcześniej lub później niż w innych mediach.
Źródło: https://101010.pl/@rdrozd/113668863306405283

To jest problem, który mnie dotknął (blog na WP z wtyczką ActivityPub), po przeprowadzce na mniejszy serwer.
Mimo tego, że śledzących na fedi mam raptem niecałe cztery dychy, to pierwsza publikacja nowego wpisu zamuliła mi stronę na jakieś pół godziny, może dłużej, a logi były pełne błędów 500 i 503 (w tysiącach).
Dzięki pomocy @m0bi ustaliłem co bardziej obciążające wtyczki, wywaliłem je i trochę innych, zostawiając pewnie z połowę. Do tego czyszczenie instalacji i takie tam, a i tak pomogło dopiero zwiększenie limitów serwera. Dzięki temu przydycha po publikacji „tylko” na 5-10 minut :/
Myślałem o rezygnacji z wtyczki AP, ale widzę, że musiałbym też odpuścić wrzucanie odnośników do wpisów na fedi.

To właściwie uniemożliwia funkcjonowanie w fediświecie malutkim amatorskim blogom bez wsparcia dużych platform.
Źródło: https://pol.social/@LukaszHorodecki/113685265406284436

Jeśli chodzi o mnie i ten blog, to z zupełnie innej okazji mam nieco stuningowaną konfigurację, relatywnie mało obserwujących, a serwer uruchomiony na dedykowanym VPSie. Więc jedyne co zauważam – poza wpisami w logach – to kilkusekundowa mniejsza responsywność serwera[6].

Dlaczego problem dotyczy Mastodona, a nie innych wspomnianych wcześniej sfederowanych usług? Powody są dwa. Po pierwsze, poczta elektroniczne czy grupy dyskusyjne działają wyłącznie same ze sobą, nie wchodząc w automatyczne, masowe interakcje z zewnętrznymi usługami. Po drugie, zjawisko popularny serwis linkuje do mniejszego i ten nie daje rady obsłużyć ruchu jest znane od dawna pod nazwą Slashdot effect. Tyle, że w tamtym przypadku ruch inicjowany był przez ludzi, a nie automatycznie. Czyli problem wynika z architektury rozwiązania i implementacji.

Rozwiązanie

Możliwych rozwiązań jest kilka. Pierwsze, najprostsze, to usunięcie interakcji z zewnętrznymi usługami w ogólności, a funkcjonalności generowania podglądu w szczególności. Tyle, że to obecnie trochę standard w social media i Mastodon wyglądałby ubogo.

Kolejne rozwiązanie to wprowadzenie jakiegoś rozwiązania typu cache, działającego w obrębie całej sieci. Czy to w stylu: serwer, którego użytkownik zamieszcza link, jego serwer generuje podgląd i rozsyła go razem z tootem. Czy też w postaci zewnętrznego, wspólnego dla wielu instancji Mastodon, serwisu służącego do generowania podglądu. Wreszcie można wyznaczyć główne serwery, które będą generować podgląd, a pozostałe będą polegać na ich danych. Tyle, że wszystkie te rozwiązania – może pierwsze najmniej – podważają niezależność działania poszczególnych serwerów.

Innym rozwiązaniem jest zmniejszenie ilości serwerów, czyli większa koncentracja użytkowników. Jednak nie zanosi się na to i trudno w praktyce na to liczyć.

Konsekwencje

Z jednej strony trudno posądzać autorów rozwiązania o celowe stworzenie takiej architektury, by powodowała problemy zewnętrznych serwisów, Z drugiej strony jeśli coś wygląda jak kaczka, chodzi jak kaczka i kwacze jak kaczka... Problem jest znany twórcom Mastodona od blisko dekady i… jest uparcie ignorowany.

Piszę o tym, bo co jakiś czas wraca temat wykorzystywania scentralizowanych platform social media (Facebook, X/Twitter) przez instytucje publicznie. I pojawia się pomysł/propozycja wykorzystania Mastodona jako alternatywy. Według mnie, przy obecnym stanie rzeczy, jest to pomysł niepoważny. Trudno oczekiwać, by instytucje państwowe czy samorządowe wykorzystywały narzędzia, o których wiadomo, że mogą być szkodliwe dla innych usług w sieci.

Mnie osobiście ten stan rzeczy zniechęca do korzystania z platformy. Nie czuję się komfortowo z tym, że mój błahy wpis może powodować problem u jakiejś strony trzeciej. Może nie na tyle, by przestać zupełnie z niej korzystać, ale na tyle, by ograniczyć aktywność. Staram się linkować tylko do swoich stron i nie podbijać (boost) wpisów z linkami.

UPDATE. Jeszcze – zanim nastąpi rotacja logów – ilość żądań GET do wpisu. Pierwsze odwołanie 16:44:36, następnie, per minuta:
16:44 – 67
16:45 – 201
16:46 – 3
16:47 – 42
16:48 – 22
16:49 – 5
Praktycznie wszystkie pochodzą od botów (zawierają słowo Bot).
Łączna ilość GET w dniu 06.03.2026 – 516, z czego 431 zawierało słowo Bot.

[1] Znany też jako zdecentralizowany.
[2] Uproszczenie, w praktyce scentralizowane serwisy mają wiele serwerów, ale dla łączącego z zewnątrz użytkownika jest to niezauważalne.
[3] Uproszczenie, serwery muszą dopuszczać federację między sobą, użytkownicy nie mogą się blokować. Jednak stan domyślny i wyjściowy jest taki, że mogą.
[4] Czyli adres email.
[5] Źródło, Marzec 2026, tylko serwery działające w oparciu o oprogramowanie Mastodon. W praktyce jest więcej kompatybilnego oprogramowania o podobnym schemacie działania.
[6] Dla pamięci: load average 9,95, 3,51, 1,25 w po kilkudziesięciu sekundach od zamieszczenia tego wpisu. Możliwe, że zasługa popularnych tagów, nie ilości obserwujących. Typowo jest load average: 0,17, 0,36, 0,18.

Opublikowane w

Mastodon a blokowanie

Mastodon chwali się, że daje możliwość kontroli widoczności. Na poziomie użytkownika posiada do tego celu dwie zbliżone opcje. Pierwsza z nich to mute, czyli wyciszenie, które, cytując komunikaty pojawiające się przy blokowaniu:

They won’t know they’ve been muted.
They can still see your posts, but you won’t see theirs.
You won’t see posts that mention them.
They can mention and follow you, but you won’t see them.

Druga z nich to block, która jest opisana jako:

They can see that they’re blocked.
They can’t see your posts and you won’t see theirs.
You won’t see posts that mention them.
They can’t mention or follow you.

Czyli w obu przypadkach nie widzimy postów w których jest wymieniane (mention) dane konto. Ma to nieco sensu, ale wykorzystując którąkolwiek z możliwości, zepsujemy sobie dostęp do treści. I to nie tylko pisanych przez zablokowane konto, ale także znikną nam wszystkie wiadomości w wątkach, w których jest wymienione to konto, niezależnie od tego, kto je napisał. Dość inwazyjne, zwłaszcza, że ludzie często zostawiają w wątkach wszystkie dotychczas wywołane osoby.

Jeśli chodzi o block, to osoba zablokowana widzi, że jest zablokowana. Przynajmniej teoretycznie, bo co prawda taka informacja jest dostępna (w API), ale nie ma żadnego miejsca, gdzie możemy sprawdzić jakie konta nas zablokowały. Nie dostajemy też informacji o blokowaniu. Co w praktyce możemy zauważyć? Zepsute wątki, zwłaszcza brakujące wiadomości. Choć wtedy może to wynikać także z wyciszenia przez nas innej wywołanej osoby, poprzez mute. Najlepszą metodą bez sięgania po API jest sprawdzenie, czy mamy możliwość obserwacji danego konta. Brak możliwości włączenia obserwacji danego konta – opcja niekatywna – oznacza, że zostaliśmy zablokowani.

Jeśli chodzi o they can’t mention to… nie działa. Jak najbardziej można zamieścić toot zawierający oznaczenie konta, które nas blokuje. Serwer podpowiada nicka i obsługuje go normalniew toocie. Zapewne wywołana osoba nie dowie się, że została oznaczona, ale to nie znaczy, że oznaczenie nie została. Co więcej, wszyscy inni użytkownicy będą widzieli to oznaczenie. Nie wiem jaki był zamysł autorów, ale wygląda na obietnicę bez pokrycia. Podobnie jak they can see that they’re blocked. Niby można się dokopać, ale czy widać? Polemizowałbym.

Jeśli chodzi o they can’t see your posts, to nie do końca jest to dowiezione. Zadziała tylko, jeśli mamy ograniczoną widoczność własnych tootów do zalogowanych kont. Co raczej nie jest popularnym ustawieniem. W przeciwnym razie wystarczy, że oni skorzystają z okna przeglądarki w trybie prywatnym.

Podsumowując, mam wrażenie, że z poziomu użytkownika blokowanie/wyciszanie na Mastodonie zrobione jest słabo. Skomplikowane (dwie różne metody), nie do końca działające zgodnie z opisem, za to bardzo inwazyjne. Wygląda, jakby ktoś projektując rozwiązanie mocno skupił się na aspektach technicznych, zapominając o „dużym obrazie” i skutkach. W efekcie użytkownicy nie dostają więcej niż na innych platformach, za to cierpi używalność platformy.

Wpis przeleżał nieco w szkicach, więc nadeszła pora na publikację…