Tag: android

Opublikowane w

Phishing w Polsce

Phishing w Polsce ma się dobrze. Niedawno na z3s.pl pojawił się opis kolejnej kampanii phishingowej. Tak się złożyło, że równolegle widziałem opis jednej z ofiar. No i zbiegło się to w czasie z wpisem na nfsec.pl o tworzeniu RPZ dla unbound. Przypomniałem sobie o inicjatywie CERT Polska, która w założeniu może pomóc zmniejszyć liczbę ofiar tego typu ataków. Powróciło pytanie, które chodziło mi od początku po głowie, odkąd usłyszałem o projekcie hole.cert.pl[1]. Kto z tego będzie korzystał?

Phishing a hole.cert.pl

Pomysł jest prosty. Ludzie zgłaszają domeny phishingowe, CERT Polska je weryfikuje i udostępnia publicznie do wykorzystania wszystkim zainteresowanym. Zainteresowani, czyli polscy ISP, przekierowują żądania do domen wykorzystywanych przy phishingu na serwery ostrzegające użytkownika o zagrożeniu.

Pewne kontrowersje budzi analogia do rozwiązania blokującego dostęp do serwisów w ramach „ustawy antyhazardowej”. Zgadza się, w obu projektach wykorzystywany jest ten sam mechanizm. Ale są to projekty niezależne. Wszystko rozbija się tak naprawdę o „wsad”, czyli to, jakie domeny są blokowane. Jak pisałem niedawno, to samo narzędzie (tu: mechanizm) może być wykorzystane do różnych celów.

Więc tak, dla purystów wolnościowych jest to cenzura, zło i naruszenie wolności. Ale praktycznie rzecz biorąc, jest to jedyny sposób by skutecznie blokować phishingi. Szczególnie na urządzeniach mobilnych, gdzie często nie można łatwo sprawdzić domeny przed kliknięciem. Albo nie jest ona dobrze, w całości, widoczna. O ile sam raczej łatwo nie nabiorę się na phishing na desktopie, bo go zauważę[2], to w przypadku telefonu nie mam do siebie takiego zaufania. Nawet po zwróceniu uwagi i zachowaniu ostrożności.

Więc ostatecznie IMO bardzo dobra inicjatywa. Nie wymaga żadnych działań po stronie użytkowników, czyli rozwiązanie jest dostępne dla użytkowników o dowolnym poziomie wiedzy o komputerach czy bezpieczeństwie. Skutecznie blokuje dostęp do zasobu systemom korzystających z serwera DNS z wdrożonym rozwiązaniem. Jest łatwe do wdrożenia przez ISP – mają już potrzebną infrastrukturę i korzystają z niej w analogicznym projekcie. Oczywiście nie eliminuje phishingu w Polsce w zupełności, ale zmniejsza jego skuteczność.

Pomysł

Wpadłem zatem na pomysł, żeby zebrać dane, czy ISP – poza wymienionymi w porozumieniu – korzystają z tego rozwiązania. Przy okazji trochę wzrośnie świadomość, że hole.cert.pl w ogóle istnieje. Szczególnie, jeśli portale piszące o bezpieczeństwie pokuszą się o interpretację danych.

Jednak przede wszystkim ludzie dostaną argument w rozmowach ze swoimi ISP, czemu ochrona nie jest włączona. Tym bardziej, że po stronie koszt ISP praktycznie żaden. I tak już utrzymują mechanizm w związku z ustawą antyhazardową, wystarczy dodać obsługę kolejnego źródła danych.

Po krótkim namyśle stwierdziłem, że dane powinny być zbierane publicznie. Tak, aby każdy mógł sprawdzić, skąd się wzięły i ew. samodzielnie zweryfikować ich poprawność. Zresztą nie mam ani dostępu do wszystkich ISP, ani czasu na ich samodzielne testowanie.

Szybko zrobiłem repo projektu badającego adopcję hole.cert.pl na GitHubie, w którym zapisuję dane. Plus prosty skrypt w bashu, który ma ułatwić zbieranie danych.

Trudności

Niestety, nawet znając adresy IP serwerów DNS polskich ISP nie da się samodzielnie sprawdzić jak resolvują daną domenę. Ze względu na ataki DDoS wykorzystujące open resolvery DNS do amplifikacji, większość serwerów limituje dostęp do usługi. Zresztą ISP nie mają obowiązku świadczenia usługi nie swoim abonentom, więc rozumiem. To akurat wziąłem pod uwagę od początku, stąd m.in. użycie GitHub i nadzieja na pomoc innych osób.

Kolejna sprawa: nawet jeśli ktoś korzysta z danego providera, to niekoniecznie korzysta z jego serwerów DNS. I niekoniecznie ma je podane bezpośrednio w konfiguracji komputera. Dlatego trzeba podawać je jawnie. A wcześniej ustalić. Nic trudnego, ale jest to ręczna robota – albo poszukanie na stronie ISP, albo wyciągnięcie z konfiguracji.

To co mnie zaskoczyło najbardziej: Android nie daje łatwej możliwości sprawdzenia aktualnie wykorzystywanych serwerów DNS. Szczególnie przy wykorzystaniu połączenia GSM nie znalazłem tej możliwości w ogóle. Dla WiFi są programy, które to podają[3].

W zasadzie należałoby nie tylko sprawdzać, czy ISP korzysta z tych danych, ale jak często je aktualizuje. Kampanie phishingowe są coraz bardziej dynamiczne, domeny żyją nawet tylko po kilka(naście) godzin. Czas reakcji jest więc kluczowy dla rozwiązania. Synchronizacja raz dziennie byłaby słaba… Niemniej, CERT również opiera się na ręcznie dostarczanych danych i podlegają one ręcznej weryfikacji, a to potrafi chwilę trwać[4]. Wymaga to trochę innego podejścia, w tym cyklicznego uruchamiania skryptu, więc na początek odpuszczam.

Co dalej?

Planuję zebrać dane samodzielnie i z pomocą znajomych dla największych polskich ISP, którzy z nich blokują phishing. Dopracować skrypty i metody zbierania danych, szczególnie dla urządzeń mobilnych. Ustalić docelowy format plików.

Jeśli pomysł „chwyci”, postaram się dorobić badanie opóźnienia między pojawieniem się domeny na hole.cert.pl, a propagacją danych do systemów DNS danego ISP. Jeśli ktoś jest zainteresowany, zachęcam do pomocy. Raczej na GitHub, niż w komentarzach, ale nie będę wybrzydzał.

UPDATE Dobrzy ludzie przypomnieli, że istnieje coś takiego jak RIPE Atlas probe i doładowali kredyty, używane przy requestach API. Wygląda, że nada się idealnie, więc nieco zmodyfikuję podejście. Tym bardziej, że będzie łatwa możliwość zrobienia samodzielnych, cyklicznych zapytań i mierzenia czasu propagacji.

UPDATE 2 Wygląda, że RIPE Atlas probe nie potrafi zwrócić pełnego wyniku resolvowania domeny (tu: rekordów A) z danej sondy, wykonanego z danej sondy na konkretnym serwerze DNS. Będę jeszcze badał temat czy nie można jakoś tego obejść, ale w API nie znalazłem. Dobrzy ludzie też nie, więc to nie moja ślepota.

UPDATE 3 Jednak zwraca, choć w mniej oczywisty sposób. Wyjaśnienie w kolejnym wpisie.

[1] Akurat ta domena nie była jeszcze blokowana na hole.cert.pl, została zgłoszona jako phishing i… nadal jej nie widzę w blokowanych. Zdarza się.

[2] Tak pewnie myśli każdy z niezerowym pojęciem o komputerach i bezpieczeństwie IT, prawda?

[3] Tylko co mi po nich, jeśli wtedy jest to IP routera, ew. ISP stacjonarnego?

[4] Nawet robiłem jakiś benchmark, ale próbka zdecydowanie za mała, żeby wyciągać wiążące wnioski. Nie było źle.

Opublikowane w

Bieganie i rower w 2019 – podsumowanie

Rok ma się ku końcowi, sezon rowerowo-biegowy bardziej skończony nie będzie, więc pora na małe podsumowanie.

Rower

Na początek rower. Zacząłem później, niż w zeszłym roku, chyba w maju. Po drodze małe zawirowania logistyczne ze sprzętem, koniec końców korzystałem z roweru głównie (tylko?) do dojazdów do pracy i głównie z Nextbike. Jeździć przestałem jakoś we wrześniu. Przekłada się to na wynik – tylko niecałe 400 km, czyli mniej niż w zeszłym roku. 24,5 godziny w ruchu. Not great, not terrible, poniżej planu.

Bieganie

Za to, jak pisałem w zeszłym roku, zacząłem trochę biegać. Spodobało mi się, kupiłem wtedy dedykowane ciuszki, co mocno uniezależniło mnie od pogody – znaczy może być chłodniej, tak do ok. 8-10 stopni. Ogólnie jak nie mam parcia na dedykowane rozwiązania i uważam, że można się ruszać w czymkolwiek, tak u mnie przy bardziej intensywnych aktywnościach fizycznych sprawdzają się syntetyki – odprowadzają pot, lepiej regulują temperaturę, szybko wysychają po praniu. Nie mam nic do bawełny, ale dedykowane lepsze.

Wystartowałem chyba już w lutym, biegam nadal (na pewno biegałem w listopadzie), choć nieco rzadziej. No właśnie. Jak zaczynałem, to biegałem raz w tygodniu, dystanse różne, raczej okolice 4 km. W tym roku doszedłem w pewnym momencie do 5 km, potem zwiększyłem częstotliwość do dwóch razy w tygodniu. Nieoptymalnie, bo dzień po dniu, ale znowu – logistyka. Teraz ze względu na pogodę biegam rzadziej – moja ulubiona trasa zbyt błotnista, butów na tego typu nawierzchnię nie mam (jeszcze!) i zwyczajnie się ślizgam. Zmieniłem trasę na inną i choć zdarzyło mi się biec w deszczu i nie było dramatu, to wolę jak jest sucho i nie jest przeraźliwie zimno. Czyli możliwe, że grudzień i styczeń bez biegania. A może kupię jeszcze jakieś ciepłe ciuchy? Zobaczymy.

Biegam po swojemu, mocno nieortodoksyjnie. Przede wszystkim, ma być fajnie i bez napinki. Lubię kontrolować czas i dystans, więc biegam ze smartfonem. W garści. Do tego co robię, zegarek sportowy z GPS itp. to overkill. Chociaż nie próbowałem, może by mi się spodobało? Biegam z przerwami na marsz. Kumpel uświadomił, że ma to fachową nazwę metoda Gallowaya. Ale niezupełnie, bo też robię to po swojemu – marsze nieco rzadsze i nieco dłuższe. Mierzone dystansem, nie czasem. Przerwy nie tyle planowane, co wynikające z trasy. Kontrola dystansu z GPS, bieganie z kontrolą prędkości i „na czuja”, nie na tętno. Rozważałem smartband, ale w tym miejscu mógłbym napisać wiele smutnych rzeczy na temat sytuacji w ekosystemie androidowym, jeśli chodzi o appki, smartbandy i ich integrację między sobą. Więc olewam ten temat, i po prostu biegam.

Statystyka: 22 godziny w ruchu, 228 km, 49 biegów. Średnio niemal jeden tygodniowo.

Opublikowane w

Lecton, Wędrowycz i kompresja audio

Jakiś czas temu[1], jeśli dobrze pamiętam w okolicach marca, InPost zrobił promocję dotyczącą paczkomatów. Wygrać można było nawet samochód, udział nie wiązał się z przekazaniem dodatkowych danych, więc wziąłem udział. Samochodu oczywiście nie wygrałem, za to wygrałem – jak wszyscy inni znani mi uczestnicy loterii – parę kodów dających dostęp do programu Lecton, czyli aplikacji Audioteka s.a pozwalającej na dostęp do audiobooków.

Lecton

Nieuchronnie będę porównywać z produktem Legimi, do którego dostęp uzyskałem wcześniej na podobnych zasadach. Są jednak różnice. Przede wszystkim Lecton rozlicza w postaci czasu dostępu do biblioteki, nie na sztuki. Także w promocji. Udało mi się w ten sposób poznać większą część cyklu o Jakubie Wędrowyczu.

Appka działała bez zarzutu. Być może kwestia niższych oczekiwań po kontakcie z Legimi, być może kwestia większej ilości miejsca na urządzeniu. W każdym razie słuchało się przyjemnie, intuicyjnie i bez walki z techologią. Oczywiście dostęp do książek jest tylko za pośrednictwem aplikacji, bez możliwości pobrania na urządzenia zewnętrzne, ale w modelu, gdzie płaci się za czas dostępu, nie za pozycje jest to zrozumiałe.

W ramach abonamentu korzystać można na jednym urządzeniu i jednym dodatkowym w trybie offline. Abonament to 20 zł/m-c (po prostu, bez promocji) Brak ebooków, tylko audiobooki, plus jakieś dodatki w stylu audycji cyklicznych itp. Mnie interesują tylko książki. Nadal – jest taniej, niż w przypadku Legimi, ale brak ebooków i mniejsza liczba urządzeń. Za Lecton ma prostsze warunki umowy – mniej wariantów i sumarycznie bardziej mi się podobał.

W Lecton drażni mnie tak naprawdę jedna rzecz – sposoby płatności. Nie ma klasycznego prepaid, trzeba podać albo kartę płatniczą, albo PayPala, żeby sobie pobierali opłatę abonament. Rozumiem, że subskrybcję można wyłączyć. Rozumiem, że tak jest prościej zaimplementować (i pewnie rozliczać), rozumiem, że tak jest korzystniej dla sklepu, bo klient nie może zapomnieć zapłacić, najwyżej zapomni wyłączyć subskrybcję. Wiem, że to coraz bardziej popularny model. Nadal drażni i finalnie doprowadziło do tego, że nie kupiłem abonamentu, wracając do książek tradycyjnych. Wiem, to nie jest dokładny odpowiednik, bo książki tradycyjnej nie posłucham w tramwaju.

Książki o Jakubie Wędrowyczu

Książki o Jakubie Wędrowyczu – wciągają. Znałem tylko pierwszy tom opowiadań, gdzie dominują krótkie utwory, w pozostałych tomach cyklu pojawiają się dłuższe. Jest niestety monotematycznie i z powtórzeniami, a żart opowiadany wielokrotnie przestaje bawić. Może kwestia dawki. Dodatkowo na przestrzeni cyklu pojawia się wiele niespójności, opowiadania są jakościowo różne. Niektóre naprawdę fajne koncepcyjnie, część to po prostu zgrabnie opowiedziane historyjki. IMO najsłabiej wypadają momenty, gdy zaczyna się politykowanie, często nachalne i znowu z powtórzeniami. Niemniej, warto. Całość jest ciekawa, zabawna, jako gawęda – zgrabna. Dodatkowo audiobooki są ładnie zaaranżowane i dobrze czytane. Chociaż tak w ogóle, po przeczytaniu opowiadań z 2586 kroków oraz Rzeźnika drzew mam wrażenie, że w utworach niewędrowyczowych Pilipiuk wypada lepiej.

Kompresja audio

Skoro przy audio jesteśmy – część techniczna, poniekąd będąca odpowiedzią na moje narzekania na zajmowane przez audiobooki miejsce. Audiobooki są duże, zapewne kompresowane do formatu MP3 lub zbliżonego. Tymczasem w przypadku mowy (audiobooki, podcasty itp.) nie potrzebujemy pełnego spektrum, więc można skorzystać z innych formatów, pozwalających na znacznie lepszą kompresję. Typowe MP3 to 128 kbps, tymczasem Speex pozwala na zejście do 4 kbps, lepiej wspierany na różnych playerach Opus na 7 kbps. Więcej opisane tutaj, a narzędzia są w repo. Prawdziwi hardcore’owcy mogą zejść nawet poniżej 1 kbps (dostępne sample).

[1] Kolejny wpis, który dość długo przeleżał w szkicach, a ostatecznie został opublikowany w niemal oryginalnej wersji.