Tag: skrypt

Opublikowane w

Linux i powiadomienia via Telegram – HOWTO

Czemu zdecydowałem się na wysyłanie powiadomień via Telegram? Kiedyś wysyłałem SMSy z powiadomieniami, nawet zrobiłem skrypt do wygodnej wysyłki SMSów z CLI. Czasy trochę się zmieniły, telefony zostały zastąpione smartfonami. Po co płacić za SMSy, kiedy można wysłać powiadomienie inaczej, w dodatku za darmo? Wybrałem powiadomienia wysyłane przez Telegram.

logo Telegram
Źródło: https://www.freepnglogos.com/images/telegram-logo-944.html

Oczywiście istnieją inne metody. Zawsze można było wysyłać maile, które są co prawda darmowe, ale z założenia miewają opóźnienia. No i niekoniecznie chcemy dostawać powiadomienie na telefonie o każdym mailu. Gdy rozpoznawałem temat obiecująco wyglądały natywne powiadomienia push na telefon, ale ich uruchomienie nie jest proste. I nie do końca są darmowe, jak widać.

Znajomi zachwalali Telegram i jego możliwości, jeśli chodzi o tworzenie botów. Nawet kiedyś podchodziłem do uruchomienia bota Telegram, ale wydało mi się to wtedy skomplikowane. I samo stworzenie bota, i sama interakcja. Czyli wysłanie komendy, by coś wykonał i odesłał wynik. Dodatkowo nie ma czegoś takiego jak prywatny bot, a uwierzytelnianie czy też sprawdzanie nadawcy trzeba robić samodzielnie. Przynajmniej tak wyczytałem w necie. Może jestem przewrażliwiony, ale za bardzo to wszystko pachniało mi RCE. No i w końcu stawianie bota, gdy zależy tylko na prostych powiadomieniach, to overkill.

Wczoraj odświeżyłem temat i… okazało się, że wysłanie powiadomienia przez Telegram jest proste. I w sumie nie potrzeba żadnych bibliotek, by wysłać powiadomienie – wystarczy tak naprawdę curl.

Przygotowanie wysyłki powiadomień przez Telegram

Aby wysyłać wiadomości, potrzebne są nam dwie rzeczy: TOKEN oraz CHATID.

  1. Korzystając z bota BotFather w Telegramie stwórz swojego bota[1] (/newbot)
  2. Zapisz otrzymany TOKEN (np. 1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12)
  3. Znajdź swojego bota, wpis /start
  4. Przejdź na https://api.telegram.org/bot<yourtoken>/getUpdates
    W naszym przypadku na https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/getUpdates
  5. Znajdź ciąg „id” dla „from” (np. „id”:723456789). Wartość jest szukanym CHATID.

Wysyłka powiadomień przez Telegram

Najprostszym wariantem wysłania powiadomienia jest wywołanie curl w postaci

curl "https://api.telegram.org/botTOKEN/sendMessage?chat_id=CHATID&parse_mode=Markdown&text=WIADOMOŚĆ"

Czyli na przykład, dla powyższych danych uzyskanych podczas konfiguracji

curl "https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/sendMessage?chat_id=723456789&parse_mode=Markdown&text=to jest test śćżń ĄŁĘĆ https://zakr.es/"

Po wydaniu tego polecenia powinniśmy otrzymać na w kliencie Telegram telefonie wiadomość. Dodatkowo z klikalnym linkiem.

Nieco bardziej eleganckie, użyteczne i tylko odrobinę bardziej skomplikowane jest wysyłanie przy pomocy Pythona i biblioteki requests. Zostało ono opisane opisane we wpisie How to create a telegram bot and send messages with Python, który był bezpośrednią inspiracją tego wpisu. Znajdziecie tam również dokładną, ilustrowaną instrukcję konfiguracji bota. A o samych botach Telegram może będzie innym razem.

[1] Owszem, miało być bez bota. Ale się nie da – bot musi być. Nie musi obsługiwać żadnych komend ani wdawać się w interakcje, ale ten twór jest tak naprawdę telegramowym botem.

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

Spam przez telefon

Witamy w XXI w., witamy w roku 2020! Tematem będzie telefoniczny spam. Przygoda z dziś, świeżutka. Zadzwonił telefon, służbowy. Już po numerze wiedziałem, że reklama[1], ale – mimo, że akurat miałem spotkanie w firmie – odebrałem posłuchać, cóż to za garnki czy inna prezentacja tym razem. Zresztą szybciej odebrać niż ma mi brzęczeć, albo zadzwonić za chwilę drugi raz.

Powitał mnie wyluzowany, optymistyczny i lekko entuzjastyczny głos telemarketera, który zaczął coś o wypoczynku. Ten typ, co to słysząc go wiesz, że ciężko będzie przerwać i powiedzieć, że nie jesteś zainteresowany.

Oczywiście nie byłem zainteresowany, ale fart chciał, że coś nam jakby przerwało, nim zdążyłem wyrazić brak zainteresowania. W słuchawce zrobiło się na moment głucho. Wystarczająco, by rozmówca to zauważył, powiedział, że chyba coś przerwało i wrócił. Chyba znowu przerwało, powiedziałem „halo?” i… rozmówca zaczął jakby od początku ostatniego zdania. Ten sam ton, ta sama treść.

No cóż, monotonna praca, wystudiowany układ, czyta ze skryptu. Aż przykro słuchać jak się człowiek marnuje odczytując spam. Tylko, że powiedziałem „halo?” raz jeszcze i… sytuacja się dokładnie powtórzyła. Znowu identyczny tekst, identyczna intonacja. Nabrałem podejrzeń, zacząłem mówić „halo?” i… po paru próbach miałem pewność. To nie człowiek, tylko automat.

Taki nietrywialny, z podpiętym rozpoznawaniem mowy i rozbudowanym skryptem. Słowo kluczowe „halo?” powodowało powrót na początek akapitu. Po dojściu do odpowiedniego momentu chciał potwierdzić, że chodzi o województwo wielkopolskie i ewidentnie czekał na input od użytkownika.

W każdym razie wygląda, że kolejny zawód, w tym przypadku telemarketera, przejmują komputery i sztuczna inteligencja. Zresztą, czytanie przez automaty staje się coraz popularniejsze. Ostatnio prezentację Piotra Koniecznego (tak, tego z niebezpiecznik.pl) na Infoshare także czytał syntezator i nawet nieźle to wychodziło, poza lekko irytującym akcentem. Może będzie o tym wpis, jak się pobawię.

Niemniej co innego synteza mowy z tekstu czyli text to speech, a co innego rozpoznawanie mowy osoby do której się dzwoni czyli speech recognition. Być może nie tylko z prostym skryptem, ale sztuczną inteligencją. W każdym razie następnym razem gdy zadzwoni do was telemarketer, polecam poświecenie chwili na zabawę i przeprowadzenie testu Turinga.

[1] Polecam poczytać opisy, także sąsiednich numerów. Zresztą cała numeracja zaczynająca się od tych sześciu cyfr jest znana i „lubiana”.

UPDATE W rozmowie z czytelnikiem otrzymałem link do wykopu, gdzie jest dokładnie ta sama rozmowa, tylko „czytana” przez „kobietę”. Co zabawne, nabijają się ze słabej inteligencji „telemarketera”. Ach, gdyby wiedzieli, że to nie człowiek…
Zresztą czytam komentarze i nawet już ktoś o tym pisał w komentarzach osiem miesięcy temu. Niestety, użytkownicy Wykopu nie uwierzyli.