Wyklikałem automat w N8N, który oszczędza mi ~5 minut w skali miesiąca oraz... oszczędza do 2 tygodni moim klientom.

Brzmi jak strata czasu? A jednak to jedna z bardziej potrzebnych mi automatyzacji, które zrobiłem 🧵 ↓

Problem był prosty: maile od użytkowników VPSów raz na jakiś czas wpadają do spamu (np. gdy user wrzuci do treści wiadomości pełne logi serwera).

Sprawdzam spam 1-2x na miesiąc i opróżniam folder.

Pewnego dnia dostałem wiadomość od klienta:
"Czekam na odpowiedź już 2 tygodnie, co się dzieje?"

Okazało się, że jego mail wpadł do spamu 🤦‍♂️

Nie pierwszy raz, nie ostatni. Problem w tym, że gdy użytkownik czeka wiele dni na odpowiedź, to bywa BARDZO niezadowolony.

I w pełni go rozumiem.

Stworzyłem więc automat w n8n, który robi kilka rzeczy:

1. Przegląda folder SPAM (codziennie rano)
2. Wyławia maile dotyczące mojego biznesu (zawierają nazwy produktów, marek, są pisane po polsku itp.)
3. Przerzuca je automatycznie do inboxa z flagą "WAŻNE"

Dodatkowo automat na dobre usuwa maile, które są na 100% spamem.

Np. kolejne podszywanie się pod Facebooka, Instagrama, fake notyfikacje, czy info, że jestem spadkobiercą fortuny po dziadku z Ameryki.

Mniej śmieci do przeglądania = oszczędność czasu.

Czy to oszczędza mi dużo czasu? 
Nie, dosłownie kilka minut miesięcznie.

Czy było warto?
Tak, bo zmniejszyło to liczbę zdenerwowanych klientów.

Czasami w automatyzacji nie chodzi o zaoszczędzony czas, a o rozwiązanie pewnego problemu.

Niestety, klikanie "to nie jest spam" przeważnie nie działa tak, jak powinno - maile od userów nadal wpadają do spamu.

Dodawanie filtrów pomaga, ale te 1-2x na miesiąc i tak prawdziwe zapytanie od klienta wyląduje w spamie, a filtry niekiedy sprawiają, że spam ląduje w inboxie.

Klasyfikator wykorzystuje AI (GPT-4.1) do zdecydowania, czy to ważna wiadomość, czy totalny spam oraz wykorzystuje "Data tables" do trzymania listy już przeanalizowanych wiadomości, aby nie przepalać niepotrzebnie tokenów.

Dodałem też akcję "NIC NIE RÓB", która jest wybierana, gdy LLM ma jakiekolwiek wątpliwości, co należy zrobić z daną wiadomością. Takie maile czekają wtedy na mnie - a ja zaglądam do folderu ze spamem nadal 1-2x na miesiąc.

Jak i po co automatyzować przeglądanie SPAM-u?

Ostatnio sporo eksperymentowałem z vibe codingiem. No nie idzie mi to zdecydowanie dobrze, czy tam mówiąc wprost - jestem w tym kiepski.

Czy 'zvajbowany' serwis posiadający zero użytkowników może stać się łakomym kąskiem dla hackerów? I to jak! 

Czytaj dalej 🧵 ↓

Celem było stworzenie od zera prostego landingu i panelu sterowania pod 'amerykańską' wersję Mikrusa (powoli takie coś powstaje). Narzędzie, którego chciałem się nauczyć był Cursor.

Potrafi on nie tylko ogarnąć kod, ale i podstawową konfigurację serwera.

Początek był piękny: hej Cursor, postaw mi 3 środowiska pod mój nowy projekt. Kilka minut i gotowe.

Z kodem nie było tak łatwo, ale po dziesiątkach godzin pracy i po licznych eksperymentach z różnymi modelami udało się ogarnąć kilka podstawowych funkcji.

✅ Landing działa - trochę generyczny, ale mi się podoba
✅ Panel klienta - biedny, ale można np. zrestartować i przeinstalować VPS-a. Dobre na początek.
✅ Płatności - po wrzuceniu dokumentacji pośrednika płatności, ogarnęło się "samo".

Po licznych testach stwierdziłem, że wszystko działa zgodnie z oczekiwaniami.

Czas dać to komuś do przeklikania. Konta dostało dwóch testerów. Nooo... oni byli mniej optymistyczni niż ja. Bugi zostały poprawione. A później kolejne i jeszcze następne.

Trzy dni temu dostałem maila od 'badacza security'. Pierwszy raz nie był to osobnik z Indii, a tym razem z Polski, więc się ucieszyłem. Za wcześnie.

Raport w mało wyszukanych słowach informował o znalezieniu buga w konfiguracji serwera. Pomijając język, to jednak responsible disclosure :)

Co konkretnie się stało? Domyślnie skonfigurowany Apache miał włączone listowania katalogów. No błąd jak błąd - jeden oleje, inny się przejmie. Tutaj jednak było gorzej. ZNACZNIE gorzej.

Serwer umożliwiał publiczny dostęp do katalogu ".git", a to już jest CRITICAL 😱

Szybkie sprawdzenie logów pokazało, że odwołań do wspomnianego katalogu trochę było (2700+ sztuk), ale tylko z dwóch IP z Polski. Czyli pewnie pentester + jakiś jego znajomy.

No OK, ale co włamywaczowi daje dostęp do katalogu .git?
Delikatnie mówiąc: daje mu dostęp do WSZYSTKIEGO.

Sądząc po liczbie requestów, pobrany został cały napisany przeze mnie kod  [taaa... przez Ciebie ~cursor]. Dodatkowo dostęp do konfiguracji umożliwił także wykonywanie zapytań SQL na bazie danych.

W systemie pojawił się nowy VPS o dość nietypowych parametrach: 8GB RAM + 69GB dysku. Oznacza to, że włamywacz (tutaj: pentester) był w stanie swobodnie manipulować bazą danych, a co za tym idzie, mógłby przejąć dowolne inne konto w systemie. No niefajnie.

Jak poważny był to włam tak w skali od zera do "OMG WTF"?
Zdecydowanie bliżej tego drugiego.

Trzeba z tego wyciągnąć pewne wnioski.

1) vibe-tool to nie DevOps. Coś, co każdy admin domyślnie ogarnia w konfiguracji, tutaj nie zostało zaaplikowane.
2) każda firma posiada środowisko developerskie. Niektóre mają także osobne środowisko produkcyjne - if you know what i mean.

[Ciąg dalszy nastąpi...]

Vibe Coding fuckup

Czy jeden drobny bug może być zagrożeniem dla dochodów całej firmy hostingowej? Niestety TAK.

Poznaj historię Mikrus (hosting VPS) vs Docker.

Czytaj dalej  🧵 ↓

W obecnych czasach większość usług stawianych w mojej firmie hostingowej przez użytkowników jest zdokeryzowana. Nawet najprostsze boty Discordowe, proste Wordpressy, czy Nginx są odpalane jako kontenery.

Nie ma w tym niczego złego - każdy robi, jak lubi.

5 listopada wyszła jednak nowa wersja Dockera (28.5.2), a wraz z nią aktualizacje dla ContainerD (zarządza cyklem życia kontenerów) oraz Runc (uruchamia realny kontener).

Po co ta aktualizacja? Aby załatać 3 krytyczne podatności, które umożliwiały ucieczkę z kontenera.

Bugfixy to ważna sprawa, więc powinniśmy się cieszyć - prawda?
No właśnie niekoniecznie. W aktualizacji dorzucono dodatkowe zabezpieczenie, które sprawia, że Docker stał się niekompatybilny z konteneryzacją LXC.

Mówiąc prościej: nie uruchomisz WCALE Dockera wewnątrz LXC.

Tak się składa, że cały Mikrus to tysiące kontenerów LXC z Dockerami w środku. Większość użytkowników niczego nie odczuła po tej zmianie, bo mieli już uruchomione swoje aplikacje.

Problem był z nowymi użytkownikami i tymi, którzy mieli włączony auto-update w systemie.

Tysiące zaktualizowanych Dockerów.

Szybko (w kilka godzin) ogarnęliśmy hotfixa polegającego na obniżeniu containerd do poprzedniej, działającej wersji. Działało super na Ubuntu 24.04, ale kiepsko na starych Debianach i Ubuntu 22.04,  bo tam upgrade pakietów był szerszy.

Główny problem pojawił się na styku Containerd z AppArmor (system bezpieczeństwa, coś jak SELinux, ale prostszy).

Oficjalna porada od developerów? "Wyłącz systemy Apparmor i po problemie!". Wyłączenie systemów bezpieczeństwa w celu umożliwienia działania patcha bezpieczeństwa... 🤔

Ostatecznie udało się namierzyć regułę (dosłownie jedną), która powodowała zgrzyt. Jej wyłączenie na LXC jest łatwe, ale na systemie Proxmox (platforma do zarządzania infrastrukturą) już niestety nie, więc powstał fix dla LXC i porada "jednak wyłącz Apparmor dla Proxmoxa" :D 

Nie podobało mi się to, więc na podstawie patcha dla LXC przygotowałem poprawkę do Proxmoxa. Ostatecznie udało się załatać wszystkie serwery i Docker działa jak dawniej.

Wspominałem na początku o dochodach. O co chodziło?
Zaczęły wpadać reklamacje i prośby o zwroty VPS-ów.

Ogromna część użytkowników Mikrusa to osoby skrajnie początkujące, które nie umieją zaaplikować patcha i jeśli tutorial nie działa, to proszą o zwrot pieniędzy, ponieważ "oszukano ich!!!!1111" (czasami prośba jest kulturalna, a czasami... 🫣)

Zwroty zostały zrealizowane.

Więcej o tym problemie możesz przeczytać tutaj:
https://github.com/opencontainers/runc/issues/4968

Gdzieś tam w wątku znajdziesz też mojego fixa dla Proxmoxa - przystosowany jest on do jednolitego środowiska.

Ostatecznie sytuacja została ogarnięta i wszystko działa poprawnie.

Mikrus vs Docker — o pewnym bugu słów kilka

Rok temu na Infoshare zaczepił mnie jeden z uczestników:

- to AI to bańka jest. Pęknie. Zobaczysz
- Mhm... — odpowiedziałem
- No to przekonaj mnie, że jest inaczej!
- dlaczego miałbym chcieć to robić? 🤔
- bo to leży w Twoim interesie!
- Ale ja się zgadzam 😃

Już wyjaśniam ⬇️

Nie wiem dlaczego, ale słowo "bańka" jest często stosowane jako zamiennik, gdy ktoś chce powiedzieć shit/badziewie/slop.

Bańka to sytuacja, gdy ceny aktywów lecą w kosmos ostro powyżej realnych ich wartości. Często takie zjawisko napędzają spekulacje, FOMO i hiperoptymizm.

Przy takiej definicji jak najbardziej wg mnie mamy bańkę. Topowe startupy AI mają kosmiczne wyceny. A zyski? Jakie zyski?! Często żyją dzięki kasie od inwestorów.

No ale... 🎶 Nic nie może przecież wiecznie trwać 🎶

Nie wiem, skąd to przekonanie, że jako współautor jednego ze szkoleń na temat AI, mam obowiązek zaklinać rzeczywistość i uspokajając wszystkich, że bańka nie istnieje — proszę się rozejść i kupować szkolenia! ;)

No niezupełnie tak to wygląda.

Myśląc o bańce, przychodzi mi na myśl coś, co znamy jako "bańkę dotcomową". Powstało o tym już tyle artykułów, filmów i książek, że temat jest znany chyba każdemu.

Tak, jesteśmy w bańce, ale to nic złego, bo z każdej bańki zostają fundamenty pod kolejną rewolucję.

Amazon, Yahoo, Ebay, Google, PayPal, Salesforce... to tylko niektóre ze znanych produktów "bańki".

W zależności od źródeł szacuje się, że 75-90% firm z bańki dotcomowej (lata 1995-2000) upadło. Ocalały głównie te, które miały sensowny model biznesowy i... generowały zyski.

Gdy zgadzam się z kimś, kto mówi, że "mamy bańkę", to zakładam, że mówimy o przeszacowanym rynku, który dąży do finału, jaki osiągnęły firmy z dot-com bubble — ocaleją rozwiązania AI mające sens biznesowy.

Czy to ma jakieś większe znaczenie dla przeciętnego Kowalskiego?
Moim zdaniem nie za bardzo. To tak jakby nagle startupy bazujące na JavaScript dostawały kosmiczne wyceny. JS jest spoko, ale wycenianie kogoś wysoko "bo używa JS" nie ma sensu.

Zalew rynku zbytecznymi produktami pisanymi w JavaScript z nadzieją, że zarobią miliony, bo przecież mają JS w nazwie, nie wróży sukcesu, ale jednocześnie nie powinno to implikować stwierdzenia "tyle teraz tego JS, że nie warto się go uczyć, bo te firmy i tak zbankrutują".

Tak - zbankrutują (a przynajmniej większość), a JS będzie sobie istniał dalej, bo to technologia niepowiązana z modelem biznesowym. Jest użyteczna dla ludzi sama w sobie i firmy dobrze ją wykorzystujące, z solidnymi fundamentami prawdopodobnie przetrwają.

Moim zdaniem, z AI jest podobnie. Te wszędobylskie startupy bazujące na GenAI po prostu się posypią, ale nie dlatego, że "AI to zło", tylko dlatego, że wiele z nich nie zaspokaja żadnej potrzeby rynkowej, a ich Twórcy nie mają sensownego modelu biznesowego.

Na czym to skończyliśmy? Aaa! no tak:

Nic się nie dzieje. It's fine! Proszę się rozejść i kupować moje szkolenia!

[No nie mogłem się powstrzymać 😉]

Czy mamy "bańkę AI"?

AI miało sprawdzać zadania domowe 24h/7 i dawać natychmiastowy feedback. Genialny pomysł... który zaczął kosztować ~$300 dziennie 😱

Co poszło niezgodnie z planem? 🧵 ↓

Gdy z Adamem Gospodarczykiem ruszaliśmy z pierwszą edycją szkolenia AI Devs, postawiliśmy na automatyczną weryfikację zadań przez LLM.

Kursanci natychmiast dostawali feedback, czy rozwiązanie jest ok.
Nie musieli czekać na człowieka.

To spoko działało przy ~1000 uczestnikach.

Przyszła druga edycja. Dołączył do nas Mateusz Chrobok, a liczba kursantów podskoczyła do prawie 3x. I tutaj zaczęły się schody.

Zadania domowe były naprawdę trudne. Większość osób nie rozwiązywała ich za pierwszym razem, a dopiero po 10-20 próbach.

Każda próba = 1-2 wywołania API od OpenAI (ówcześnie modele GPT-3.5 oraz GPT-4).

Koszty?
➤ Proste zadania: $10-20 dziennie
➤ Trudne zadania: do $300 dziennie

Przy takiej skali portfel zaczynał boleć...

Podjąłem decyzję projektową w AI_Devs 3:
Muszę ograniczyć użycie AI w automatach do minimum i wrócić do "klasyki".

↳ wyrażenia regularne
↳ proste instrukcje warunkowe
↳ klasyczne SQL-e

W 90% przypadków wystarczało to do weryfikacji zadań.

Poruszam ten temat, bo AI niesamowicie ułatwia budowanie systemów weryfikujących dane. Może więc kusić, aby pójść na skróty i skorzystać z prostego prompta.

Jednak przy odpowiednio dużej skali (np. dziesiątki tysięcy wywołań dziennie) koszty potrafią być już znaczące.

Dzięki zmianie metody weryfikacji zadań zaoszczędziliśmy prawdopodobnie tysiące dolarów.

Trzeba jednak pamiętać o kilku ograniczeniach przy takim podejściu do tematu.

Wybór LLM-ów jako weryfikatorów nie był zwykłą fanaberią i podążaniem za modą, a podyktowany był tym, że ogromna część zadań musiałaby być weryfikowana przez ludzi.

Tam, gdzie potrzebna jest ludzka inteligencja, tam możemy wepchnąć... tą sztuczną.

Nowe wersje zadań zostały więc zbudowane w sposób warstwowy, czyli odpowiedź udzielana przez kursanta przechodziła przez sito warunków, wyrażeń regularnych, które klasyfikowały, czy wszystko jest OK.

Dopiero na ostatnim etapie (o ile była taka potrzeba), angażowany był LLM.

Czy znacząco zwiększyło to ilość pracy programistycznej do wykonania?
No tak — zdecydowanie.

Plusem tego podejścia było jednak zwiększenie wydajności rozwiązania i zmniejszenie kosztów jego utrzymania.

Nie oznacza to jednak, że LLM-y nie nadają się do pracy przy dużej liczbie użytkowników.

Po pierwsze, czasami rezygnacja z modeli językowych oznacza po prostu zatrudnienie ludzi - wbrew temu, co mówią fanatycy RegExów, nie wszystko da się ogarnąć prostym wyrażeniem ;)

Po drugie, zamiast korzystać z metody "albo LLM, albo klasyczne metody" warto wykorzystać podejście "Why not both?!".

Tam, gdzie LLM się sprawdza - tam go używaj.
Tam, gdzie jest za drogi, obniż jego koszty metodami klasycznymi.

Po trzecie, jeśli rezygnacja z LLMów nie jest możliwa, a szybkość działania nie jest kluczowa, rozważ wykorzystywanie modeli lokalnych.

AI sprawdza zadania domowe - co poszło nie tak?

Gdybym był przybyszem z innej planety i przeczytałbym, co ludzie piszą w necie o samochodach marki Tesla, to uznałbym, że to jakieś szalone narzędzia posiadające tylko dwie funkcje: podpalanie kierowców oraz rozładowywanie baterii.

Trochę podobnie jest z tematem AI  🧵 ↓

Jak coś nie działa, to jest fajnie i zdobywa lajki, a jak jeszcze by ktoś przez to zginął, to wtedy będzie viral.

Wiadomość w stylu "miliony ludzi dojeżdża do pracy Teslami i wraca szczęśliwie do domu" to nuda. Przynajmniej by ktoś w drzewo walnął, to by się coś działo.

Ze sztuczną inteligencją jest bardzo podobnie.

Większość moich znajomych używa AI w pracy - jako element backendu, fragment logiki biznesowej, wspomaganie przy pracach programistycznych (Cursor, Claude Code), czy nawet jako asystent przy researchu informacji.

To po prostu działa i jest nudne jak flaki z olejem.

Spowszedniało to zupełnie dla tych, którzy wykorzystują to w codziennej pracy. To nie jest coś, czym warto się chwalić. To tak jakby kierowca Tesli powiedział "łoooo! dojechałem Teslą do pracy i nie spłonąłem! czadowo!" ;)

Jeśli jednak zdarzy się gdzieś na świecie jakikolwiek fackup, powstanie o tym kilkadziesiąt wpisów z analizami na LinkedIn, liczne artykuły, a telewizja wezwie ekspertów, zadając im pytanie "jak do tego doszło?!".

Eksperci popadną w 'tozależyzm' i jakoś to się będzie kręcić.

Problem polega na tym, że taka narracja wypacza rzeczywistość i szkodzi wszystkim.

Ludzie, którzy mogliby realnie skorzystać z AI w swojej pracy, boją się tego spróbować, bo "przecież to niebezpieczne i niepewne". Buduje się też narrację, że "AI zazwyczaj NIE działa".

To tak jakby powiedzieć, że Tesla domyślnie podpala kierowców, a 5 gwiazdek w testach zderzeniowych Euro NCAP zdobyła, bo padła jej bateria, zanim dojechała do ściany — no trochę nie tak wygląda rzeczywistość 😃

Generatywna sztuczna inteligencje jest rozwiązaniem niedeterministycznym i halucynującym z natury, ale to nie jest "fackup maker".

Wiadomo, że część firm wdraża ją "bo trzeba i konkurencja już to ma", ale te bardziej sprytne korporacje wdrażają to rozwiązanie, bo ono działa 🤷‍♂️

Jeśli chcesz kupić samochód Tesli, to pogadaj z... użytkownikiem takiego samochodu. Nie będzie hurra-optymistą, ale opowie Ci, co jest OK, a co jest w nim totalnym shitem.

Podobnie z AI → słuchaj ludzi, którzy to wdrażają, a nie do tych, którzy "mają zdanie na ten temat".

AI na obecnym poziomie to nie techno-apokalipsa ani zbawienie ludzkości. To po prostu narzędzie (jedno z wielu), które albo wykorzystasz, albo nie.

A Tesla? Może dojeżdżać do pracy. Codziennie. Bez fajerwerków.

Przed krytyką dowolnej technologii → przetestuj.

AI jest trochę jak samochody Tesla...

Jedna z domen developerskich Mikrusa została zablokowana przez Google.
Właśnie walczę o jej odblokowanie — powód blokady jest absurdalny 😃

Pośmiejmy się razem 🧵 ↓

Na moim hostingu użytkownicy mogą dodać dwoma kliknięciami do swojego projektu "roboczą subdomenę" (jedną z wielu). Skutkiem tego domeny developerskie mają przeważnie po kilka tysięcy subdomen, na których stoją testowe aplikacje użytkowników.

To bardzo wygodne.

Użytkownicy może i to lubią, ale Google jak widać, tak nie do końca.

Wczoraj w nocy dostałem informację o zablokowaniu domeny z powodu... zbyt dużej liczby ekranów logowania na domenie.

Kategoria: phishing/misleading.

No ja rozumiem, że posiadanie kilkuset różnych ekranów logowania na swojej domenie wygląda trochę mało legitnie, ale TAK MA BYĆ! :D 

Przeklikałem wszystkie URL-e oznaczone jako skrajnie niebezpieczne.
↳ logowanie od N8N.
↳ logowanie do Uptime Kuma.
↳ logowanie do Umami
↳ 😐

W oświadczeniu do Google trzeba zaznaczyć, że "usunąłem wszystkie problemy" nim prześle do nich wiadomość.

Problemem jest tutaj firma Google, a że nie mam władzy, aby ją usunąć, to skłamałem, że wszystko jest usunięte i napisałem w oświadczeniu, o co chodzi z tą domeną.

Domeny użytkowników co jakiś czas są blokowane (niekiedy słusznie!). 

Najbardziej lubię blokady od Cloudflare (to nie jest sarkazm), bo po pierwsze wysyłają oni sensowne raporty: co, gdzie i dlaczego zostało zablokowane, a po drugie: od 8+ lat nie trafił im się false positive.

W przypadku blokady od Google problemy są trzy:

• blokują Cię automaty, a nie ludzie
• AI raporty nijak nie są sprawdzane (N8N to phishing!!!!)
• reakcja na odwołanie to od kilkunastu godzin do kilku dni

Problem z "Google Safe Browsing" jest też taki, że domeny tam blokowane, są automatycznie blokowane u dziesiątek dostawców VPNów, dostawców internetu itp.

Zniknięcie z listy Google to dopiero początek wielkiej przygody z wysyłaniem maili do firm, które odcięły domenę.

Do namierzenia kto zablokował Twoją domenę bardzo przydaje się platforma VirusTotal, która automatycznie odpytuje 98 czarnych list z domenami (zakładka "URL") i szybko poinformuje Cię, do kogo warto napisać prośbę o odblokowanie strony.

Czy to pierwszy raz, gdy domeny developerskie są blokowane? Nie.
Czy przechodziłem już taką procedurę wcześniej? Tak

Czy przez ostatnie lata cokolwiek zmieniło się na lepsze w Google w temacie false positive? No zgadnij 😏

Czekam na odblokowanie domeny 🤷‍♂️

Blokada strony od Google - absurdalny powód.

Boty, które próbują włamać się na serwery to dla mnie codzienność, bo w końcu prowadzę hosting serwerów VPS 🤷‍♂️

Używam prostej metody, aby odsiać pewien promil internetowych agresorów 🧵 ↓

Środowisko Mikrusa (mikr.us) to ponad 10 tysięcy serwerów VPS.

Nie ma szans, aby admini platformy zabezpieczyli każdego z użytkowników, tym bardziej że każdy z nich ma prawa roota i może konfigurować serwer, jak zechce.

Chcemy jednak blokować intruzów.

Pierwsza linia obrony to klasyka, czyli wycięcie Rosji, Chin i Indii na portach TCP związanych z usługą SSH. To obniżyło liczbę udanych włamań o jakieś 80-90%.

Ale przecież nie tylko z tych krajów przychodzą ataki, a całego świata przecież nie wytniemy — choć można próbować ;)

Korzystam z dwóch czarnych list z adresami IP dokonującymi ataków. Pobieram je z poniższych platform.

↳ AbuseIPDB - darmowa/komercyjna baza abuserów
↳ SniffCat - publicznie dostępna baza abuserów

Każdy z serwisów oferuje API.
Przy pierwszym korzystam z planu darmowego.

Konto FREE na AbuseIPDB umożliwia pobranie bazy danych abuserów tylko 10x na dzień, a mając kilkadziesiąt serwerów, ten limit jest za mały.

Sniffcat ma jeszcze gorzej - limit 6x/dzień.

Rozwiązanie? Jeden, centralny serwer pobiera listę i wrzuca ją do wspólnego repozytorium.

Każdy z serwisów zwraca około 10 tysięcy topowych adresów IP abuserów do zablokowania. To łącznie daje 20k IPv4. Nie ma sensu tworzyć 20 tysięcy regułek firewalla - wystarczy jedna.

Tutaj z pomocą przychodzi "ipset".

W dużym uproszczeniu procedura karmienia ipseta i blokowanie ruchu w iptables wyglądają następująco:

ipset create blocklist hash:ip
cat lista.txt | xargs -n1 -I {} ipset add blocklist {}
iptables -A INPUT -m set --match-set blocklist src -j DROP

Oczywiście prawdziwy skrypt zawiera sprawdzanie, czy set istnieje, czyszczenie go ze starych wpisów, weryfikację istnienia reguły w iptables (aby jej nie dublować), a do tego używam łańcucha FORWARD, a nie INPUT, bo to serwery VPS wpięte do bridge.

Licznik użycia tej reguły na serwerach pokazuje od 200 tysięcy do 2 milionów zdropowanych pakietów ze złośliwych źródeł rocznie.

Czy to dużo? Moim zdaniem tak, a biorąc pod uwagę, że koszty wdrożenia tego zabezpieczenia są niemal zerowe, warto je dorzucić do serwera.

Oczywiście, zamiast odcinać 100% ruchu z podanych adresów IP, można odciąć jedynie ruch skierowany na konkretne usługi — np. SSH, czy porty serwera webowego.

To nie jest 'silver bullet' - to tylko kolejny, mały kamyczek do koszyka z zabezpieczeniami serwerów ;)

Czarna lista internetowych agresorów - jak ją wdrożyć?

Często, gdy dziele się w sieci tym, że korzystam z N8N do automatyzacji zadań, widzę komentarze w stylu: "Łoooo! ale to drogie! 😬😮"

Nie płacę za N8N - musimy sobie wyjaśnić kilka kwestii 🧵 ↓

Gdy ktoś pierwszy raz usłyszy o N8N, wpisuje nazwę tego softu w wyszukiwarkę, wchodzi na stronę producenta w zakładkę z cennikiem i jest przerażony. Najtańszy, malutki pakiet do automatyzacji to jakieś 85 zł miesięcznie, a taki sensowny to już ponad 2 stówy!  😱

"Tak, aleee..."

N8N dostępne jest w dwóch wersjach:

↳ Jako aplikacja SaaS, hostowana w chmurze producenta, gdzie rozliczasz się za liczbę wykonań scenariuszy

↳ Jako darmowe oprogramowanie open-source do samodzielnej instalacji "tam, gdzie chcesz".

Korzystam z tego drugiego.

Aplikację możesz uruchomić samodzielnie na domowym komputerze, na niektórych serwerach NAS (np. Synology z procesorem x86), na serwerach VPS itp.

Można instalować ją ze źródeł, ale to moim zdaniem strata czasu.
Dostępne są gotowe, oficjalne kontenery i z nich warto korzystać.

Prawdopodobnie najtańszym miejscem, gdzie można hostować N8N jest VPS Mikrus (nie licząc hostowania np. na komputerze pod biurkiem 😉).

Pod większością reklam Mikrusa (to moja firma) widzę komentarze:
"VPS tani, ale gość zapomniał wspomnieć o licencji €20/msc! 😆😆😆"

Niezależnie jaki hosting wybierzesz, tak długo, jak korzystasz z otwartoźródłowej wersji oprogramowania, tak długo NIE potrzebujesz kupować żadnej licencji, uiszczać opłat miesięcznych itp.

Wspomniane oprogramowanie jest darmowe.

Wiem, że dla większości wymiataczy z branży IT to o czym piszę to "oczywista oczywistość", ale nie ma tygodnia, w którym jako właściciel firmy hostingowej nie dostałbym pytania o kwestię kosztów licencji.

Jak więc widać, nie dla wszystkich jest to takie oczywiste.

Czasami pojawiają się też zarzuty, że Mikrus nie może oferować usługi N8N na swoich serwerach, bo stara licencja ("Fair Use Policy") oraz nowa ("Sustainable Use License") są bardzo restrykcyjne.

Mikrus od września 2022 roku jest oficjalnym resellerem N8N.

Jeśli chcesz pobawić się automatyzacją i nie chcesz, aby kosztowało to majątek, to na początek uruchom N8N na własnym komputerze np. w kontenerze Dockera.

Wyklikaj kilka automatów, a gdy uznasz, że to coś dla Ciebie, wtedy poszukaj taniego hostingu.

Automatyzacja zadań z N8N - ile to kosztuje?

Plik "llms.txt" na stronie ma teoretycznie chronić Twoje treści przed byciem pożywką dla robotów AI. Standard istnieje, a ludzie powoli go u siebie wdrażają.

Pytanie tylko, czy którykolwiek z automatów odwołuje się do tego pliku? 🤔

Zrobiłem małe testy 🧵 ↓

Jestem właścicielem firmy hostingowej (serwery VPS: Mikrus).

Analizowałem wczoraj logi współdzielonego serwera webowego, który obecnie obsługuje 5736 unikalnych nazw domen i subdomen (łącznie).

Uruchomiłem narzędzie "grep" na danych z ostatnich 50 dni.

We wspomnianym przedziale czasu plik "llms.txt" został pobrany 1096 razy, co wygląda na przyzwoity wynik — ktoś/coś z tego pliku naprawdę korzysta.

Jednak nie liczy się tylko, że "ktoś" plik pobiera, ale liczy się, kto to jest i czy ten plik jest respektowany.

Pewnie spodziewasz się, że na liście firm, które pobierają plik będzie OpenAI, Anthropic, Perplexity, Google... no to tutaj zaskoczenie, bo 55% ruchu (605 zapytań na 1096) pochodzi z platformy DataProvider, która scrapuje dane na potrzeby różnych produktów bazujących na AI.

No to przynajmniej te 45% to są ci wielcy gracze na rynku - tak?
No nie do końca. Bo 24% ruchu do pliku llms.txt pochodzi z platformy 
BuiltWith, która zbiera statystyki na temat stacku technologicznego stron internetowych.

Czyli obecnie mamy podział:
- 55% = DataProvider
- 24% = BuiltWith
- 21% = ???

Co stanowi brakujący kawałek tortu?

Około 18% zapytań przychodzi z dość normalnie wyglądającego user-agenta (Chrome), ale z dopiskiem "PTST" na końcu.

Wszelkie ejaje mówią mi, że to skrót od "Performance Testing Stress Tool", ale nie mogę tego wiarygodnie potwierdzić.

Przykład zapisu: PTST/250819.153741

Pozostałe zapytania przychodzą bez ustawionego pola user-agent.

Przez 50 dni moje serwery nie otrzymały ani jednego zapytania o plik llms.txt wprost od dużych graczy z rynku wyszukiwarek i botów AI.

To może te strony nie zostały odwiedzone przez OpenAI, Anthropica itp?

Oto liczba zapytań wygenerowana przez poszczególne mechanizmy AI do wspomnianych 5736 domen

↳ OpenAI = 521479
↳ Anthropic = 124872
↳ Gemini = 5674
↳ Huggingface = 180
↳ Mistral = 93
↳ Perplexity = 12

Statystyki pokazują, że o ile scrapowanie treści następuje codziennie, 24/h na dobę, to plik llms.txt jest pobierany nie częściej niż raz na 3 dni per domena.

Jeśli więc zabronisz indeksowania strony, to chwilę poczekasz, nim ktoś to zauważy.

Kto korzysta z danych dostarczanych przez platformę DataProvider? Nie jestem w stanie znaleźć jasnych powiązań tej platformy z OpenAI, Anthropic, czy Perplexity.

Mechanizm wykluczania treści przez pliki "llms.txt" faktycznie istnieje, ale liczba platform, które biorą ten plik pod uwagę, połączona z częstotliwością pobierania pliku wskazuje, że jest to raczej rozwiązanie eksperymentalne niż coś, co pozwala skutecznie zwalczyć roboty.