Menu
About me Kontakt

The PROIDEA Events presentation provided a detailed insight into the challenges faced by the hosting company Mikrus. The owner shared his experiences with running hosting primarily targeted at developers, offering them space within a development environment. Rather than focusing on sales, Mikrus emphasizes effective and practical approaches to security, making this presentation incredibly valuable for anyone considering entering the hosting market. Many individuals look at their hosting operations from a return-on-investment perspective; however, responsive actions in light of various threats are critical. The core idea shared by the speaker is rooted in experience and knowledge derived from practice.

Another element emphasized was that Mikrus does not compete with the biggest players in the hosting market but instead better meets the basic needs of its clients. Mikrus is often utilized by users starting their journey with Linux, which presents a risk of inadequate security. For this reason, various protective measures for VPSs were discussed, including changing standard SSH ports and removing access from less trusted countries. Each proposed idea can be easily implemented, making them practical and useful in day-to-day administrative work.

Introducing additional security methods is not just about practical tips but also represents a significant step forward for potential new users, who might struggle with greater knowledge deficits regarding safety. Mikrus often comes under attack; therefore, a series of mechanisms aimed at identifying potential threats were also presented. Reports of hacking attempts received from users illustrate how serious security issues can become when managing hosting. This 'for every branch that grows, another little trick can be learned' approach in the hosting world is essential to ensuring safety for many users.

The security problem of hosting becomes more complicated when resource-sharing is involved. The speaker noted issues related to 'heavily hooded residents' who can also pose risks. Hence, Mikrus employs a variety of preventative measures to ensure that its clients remain out of trouble. Techniques such as cutting unnecessary traffic, detecting incorrect users, and enforcing complex passwords show that not only do these measures secure servers but they also assist users in better understanding the basic principles of security.

In conclusion, PROIDEA Events highlighted that security is an ongoing battle that requires dynamic adaptation to changing needs and challenges. The presentation statistics showing 4929 views and 247 likes at the time of writing indicate that the topic of hosting security is of significant interest. The knowledge gained from this presentation can assist both new and experienced users in effectively conducting activities in the digital world, enhancing both the quality and security of hosting services. The conclusions derived from this presentation encourage ongoing education in protection and server management, leading to a safer internet overall.

Toggle timeline summary

  • 00:00 Greeting and introduction.
  • 00:04 Starting the presentation.
  • 00:08 Introduction about the presenter and their hosting company.
  • 00:12 Discussing the nature of the hosting company.
  • 00:34 Mentioning the approach of sharing practical solutions for hosting.
  • 00:54 Emphasizing practical implementations for improving security.
  • 01:15 Explaining how hosting differs from competitors.
  • 02:14 Discussing VPS server awareness among users.
  • 02:45 Addressing server security measures.
  • 03:09 Explaining the challenges of securing multiple user environments.
  • 03:18 Identifying issues with weak user passwords.
  • 04:02 Stressing the importance of password security in hosting.
  • 04:42 Discussing the potential of automation in managing security.
  • 05:07 Highlighting the limitations and challenges of automated security.
  • 06:04 Encouraging users to follow best practices for security.
  • 06:46 Summarizing the key takeaways from the presentation.
  • 08:07 Closing remarks and invitation for questions.

Transcription

Dzień dobry. Cześć. Prezentacje widać, więc zaczynamy. Na początek, kim ja jestem. Z tych rzeczy, które powinny was zainteresować, to w zasadzie jest to, że, prowadzę firmę hostingową. Firma hostingowa o nazwie Miklus, jest dość specyficzna, dlaczego to powiem za chwilę. I gdy tak słuchacie pewnie, przyszedł gość, który ma firmę hostingową, będzie opowiadał o hostingu, no to prawdopodobnie będzie mówił głównie o swojej firmie. Nic z tych rzeczy. Będę mówił tylko o swojej firmie. Ale chodzi o to, że będzie to case study. Bo wiecie, można tak ogólnie opowiadać, na zasadzie gdzieś tam jakiś hosting istniał, miał jakąś wpadkę, coś się zdarzyło, albo hostingi ogólnie zabezpieczają się w taki, a nie inny sposób. A można pokazać siebie, jakiego takiego człowieka fejla. Na zasadzie, ja to zrobiłem, mi się zdarzyło z pierwszej ręki. Można powiedzieć, co u mnie działa. Chodzi o to, aby podzielić się praktycznymi rozwiązaniami, które u mnie działają i są dość trywialne, łatwe do prowadzenia. Nie chcę wchodzić w takie bardzo głębokie szczegóły techniczne, tylko coś takiego, gdy masz hosting, albo chcesz mieć hosting, albo chcesz świadczyć hosting na przykład dla znajomych, co by można było wprowadzić, żeby delikatnie podnieść to bezpieczeństwo niskim kosztem i małą ilością pracy. Dlaczego ten mikrus w ogóle jest taki dziwny? Bo wiecie, firm hostingowych na świecie jest dość sporo, a mikrus, można powiedzieć, no, nie za bardzo walczy z konkurencją. Chodzi o to, że jest to hosting, który sprowadza się do tego, że jest przeznaczony do środowisk deweloperskich. Czyli jak chcesz proda postawić, to nie do nas, okej? Tak naprawdę stoi tam mnóstwo aplikacji produkcyjnych. Jest tego naprawdę sporo. Przyjęliśmy ostatnio na przykład, nie wiem, czy kojarzycie, taki projekt Night Scout. Ktoś kojarzy? Nie bardzo. Night Scout jest to projekt, który jest aplikacją do monitorowania poziomu cukru u dzieci z cukrzycą. I użytkownicy tego systemu dawniej byli na takim hostingu, jak Heroku, Heroku to się nazywało, tylko problem jest taki, że zamknięto tam darmowy ten tier. No i teraz co robić, jak żyć? No, zaoferowaliśmy im, że weźmiemy ich wszystkich. Okazało się, że tego było trochę dużo. Kilkaset dzieci właśnie zostało przywróconych do mikrusa i tam zamiast deweloperskiego środowiska mamy produkcyjne środowisko dla dzieci z cukrzycą, więc trochę to jest takie wrażliwe. Jeśli chodzi o to, dlaczego to jest jeszcze takie specyficzne? Zwykle człowiek kupujący serwer VPS, to jest człowiek, który ma jakaś świadomość, to znaczy wie, co to jest Linux, jak to dokładnie działa. Ogólnie się w tym temacie interesuje. W przypadku mikrusa bardzo często jest to serwer, który jest pierwszym wejściem w świat linuxowy. Człowiek nigdy nie miał styczności z Linuxem i nagle bum, mikrus. Więc szansa, że to będzie dobrze zabezpieczone i szansa, że to będzie jako tako działać, jest naprawdę nikła. Nie mogę liczyć na to, że sam użytkownik zadba o siebie. Raczej zrobi sobie krzywdę. Jeśli chodzi o zabezpieczanie serwerów, to też nie jest jakiś taki rocket science na zasadzie, że strasznie trudna rzecz. Myślę, że przynajmniej część z Was ma swój serwer albo przynajmniej ma znajomego, który ma serwer i tutoriali zabezpieczających serwer jest po prostu potąd. Bierzesz wszystkie, instalujesz, fajnie, jest spoko i powstaje Ci taka twierdza. Ta twierdza charakteryzuje się tym, że ma mnóstwo zabezpieczeń, mnóstwo warstw zabezpieczeń. I zrobienie czegoś takiego, co jest tak zabezpieczone, że w zasadzie wejść się nie da, mało tego, tam się pracować nie da, to nie jest trudne. Problem się zaczyna, gdy zmieniamy podejście. Podejście polega na tym, że na przykład mówisz ludziom, okej, ale to nie będzie twierdza dla jednego użytkownika, tylko to będzie firma hostingowa dla wielu, wielu tysięcy użytkowników. Czyli w przypadku takiej analogii z tą naszą twierdzą wyglądałoby to tak, że szef mówi, fajnie, że mamy ten zwodzony most, grube mury, fosę i tam jakichś strzelców na wieżach, to jest wszystko bardzo fajne, tylko ja mam pomysł. Zrobimy sobie z tego Airbnb, okej? No i teraz chodzi o to, że wpuścimy ludzi. Ci ludzie mają mieć wygodnie, mają mieć fajnie, muszą się super bawić, więc wiecie, grube mury są spoko, okej, fosa, fosa nie bardzo, no bo wilgoć, komary, a w ogóle ta brama z kratą, facet tam pery nie przejedzie, nie? I tak wymieniamy, wymieniamy kolejne rzeczy i okazuje się, że trzeba ujmować tak naprawdę warstw zabezpieczeń. Coraz mniej, coraz mniej, coraz mniej i wtedy się lepiej sprzedaje. Problem jest taki, że lepiej się sprzedaje, no ale tworzy nam się z tego totalnie dziurawy hosting. I jeśli do tej pory w naszej twierdzy mieliśmy zaufany team, to znaczy każdy zna każdego, wiemy jakie aplikacje są, to dostosowanie się do nich jest dość proste. Ale gdy wpuszczasz tam na przykład, załóżmy, 5000 użytkowników, każdy ma inną aplikację, a ty musisz dostosować się tak, żeby każdemu to jakoś współgrało, to jest ekstremalnie trudne. Są ludzie, którzy twierdzą, że dobra, dałbym radę. Ja od wielu, wielu lat mówię na przykład ludziom, że pracowałem w branży hostingowej, więc mówię tak z doświadczenia ci powiem, prowadzenie własnego serwera nie hostingowego, a mailowego to jest po prostu tragedia, nie rób tego. I zawsze odpowiedź już mi, no ciekawe, prowadzę od 20 lat i nie mam żadnych problemów. Okej, ile milionów maili wysyłasz miesięcznie? Czego? Czujecie o co chodzi, nie? Chodzi o skalę. Gdy masz swój własny hosting taki domowy, na zasadzie wysyłasz sobie cztery maile, ta mama, tata i pies ma konto, to jest wszystko fajnie. Ale w momencie, jak tam wpuścisz dziesiątki tysięcy użytkowników, a oni sypią tymi mailami, praktycznie nie ma nic gorszego niż ten serwer mailowy. I podobnie jest z hostingiem. Jeden serwer jesteś w stanie zabezpieczyć, to jest całkiem fajna zabawa, ale dostosowanie tego do dużej ilości użytkowników, tragedia. Obumknę zagrożenia. W ogóle atak na takie serwery zaczyna się od tego, że ktoś szuka celu ataku, czyli najczęściej jakiś Azjata szuka sobie miejsca do strzyknięcia swojego kodu, czyli skanuje sieć, skanuje porty. I serwery Mikrusa są skanowane przynajmniej kilkaset, czasami w wakacje częściej, kilka tysięcy razy miesięcznie. I tak się składa, że skoro mamy na pokładzie takich Mikrusów samych początkujących użytkowników, to znalezienie aplikacji, która jest dziurawa, to jest 100%. Trzeba dostatecznie długo skanować, żeby znaleźć dziurawą aplikację. Szansa, że mu zhakują serwer, to jest prawdopodobieństwo idące do jedynki. Najczęściej kończy się to w ten sposób, że ja tylko chciałem postawić sobie serwer mailowy, no tak się zdarzyło, ale zdarzyło się. Wysłałem trochę więcej maili. Więc ideałem byłoby tak skonfigurować środowisko, że jeżeli użytkownik sam świadomie nie chce sobie strzelić w stopę, to nie strzeli. Ale jeżeli będzie chciał sobie strzelić w stopę, to strzeli optymalnie. I chodzi o to, że my dostarczamy właśnie takie środowisko, żeby tak to działało mniej więcej. Jak więc przeciwdziałać takiemu skanowaniu? Pierwsza idea, na jaką wpadliśmy, trywialna, śmieszna, blamerska. Zmieńmy standardowe numery portów. Użytkownicy z Semicrusa nie korzystają z portu typu 22 do SSK, tylko dostają takie dziwne porty typu 10123. Czujecie, o co chodzi, nie? Można powiedzieć, no dobra, security by obscurity, no gorzej upaść nie mogłeś. Ale to działa. Czujecie, o co chodzi? To działa, po prostu działa. Patrzysz na liczby, nie patrzysz na opinię ludzi, tylko patrzysz na liczby. Spada ci na przykład ilość skanów i udanych włamań, na przykład o 25%, 30%, to czemu by tego nie robić, nie? Kolejna rzecz, wycinamy nielubiane kraje. Czyli wszystkie jakieś Rosje, Indie, Chiny, Tajwan. No oczywiście ktoś powie, dobra, a co jeżeli twój użytkownik mieszka w Indiach? Ma problem. Nie znam żadnego użytkownika, który żyje, nazwijmy tam, w Indiach, Rosji i tak dalej, ale chodzi o to, że wycięcie przynajmniej ruchu na tych portach związanych z SSK dało nam całkiem niezłe tutaj efekty. Oczywiście dla tych osób, które jakimś cudem pojawiły się na filipinach, na wakacje przykładowo, i chciałyby się zalogować do takiego mikrusa, mamy web SSK, czyli mogą przez webowy panel się też zalogować, przejść tam odpowiednią weryfikację, captcha, rozwiązać i tak dalej i da się tam wejść. Więc to nie jest tak, że ojej, odcięliście Indię. Tak, odcięliśmy Indię. Kolejna rzecz, jeżeli chodzi o takie rzeczy, które potrafią hakerów trochę zatrzymać, serwery pułapki. Na każdym serwerze, takim dedykowanym, jest sporo VPS-ów. I zawsze tam jest co najmniej jeden serwer, który jest serwerem pułapką. Należą do mnie. Jeżeli ktokolwiek dotknie tego serwera, czyli odpali aplikację webową znajdującą się na nim albo próbuje się połączyć po SSK, to natychmiast jest trigger odpalany, jesteś hakerem, bum, nie macie. I w tym momencie znika z planszy, nie? Więc takie proste rzeczy też działają, czyli można powiedzieć taki honeypot wystawiony. Kolejna rzecz, fejkowe dedyki. Dedyki Mikrusa są numerowane kolejno, czyli 1, 2, 3, 4, 5, 6. No, może nie do końca kolejno. Raz na jakiś czas zdawa się fejkowy dedyk, który nie istnieje i który służy tylko temu, że jeżeli się do niego próbujesz połączyć, to cię wytnie na firewallu. I co zrobiliśmy? Celowo zrobiliśmy tak, żebyśmy byli zaindeksowani na pewno na szodanie, sensyjsie i tak dalej. Jak ktoś próbuje się do ciebie włamać i bada twoją infrastrukturę, tam są takie fajne dedyki o nazwie na przykład backup. Albo backup-backupu, nie? Czujecie, o co chodzi? Aż wkusi. Walnie włamać się, no. I teraz chodzi o to, że jeżeli dotkniesz tego serwera, automatycznie jest ruch zbierany z jakiegoś IP-ka i co się teraz dzieje? Jesteś wycinany na firewallu. Na czym polega ten haczyk? Firewall jest współdzielony. Jeżeli dotniesz jednego z naszych serwerów, jesteś wycięty z całej sieci. Jeżeli dotniesz jednego VPSa, jesteś wycięty z całej sieci. Więc bardzo, bardzo szybko wyłapujemy, no powiedzmy nie tylko Chińczyków, bo powiedzmy szczerze, skany automatyczne, no to głównie Chińczycy, Rosja i tak dalej, ale takie próby włamania realne, to są Polacy. I wtedy widzimy, że jakiś Polak próbuje tam właśnie infrastrukturę badać, bum, znika, nie ma go na przykład. Kolejna rzecz. Co ci ludzie na tych microsach stawiają? Najczęściej to są aplikacje webowe. I teraz, jak wygląda taki typowy scenariusz? Typowy scenariusz wygląda w ten sposób, że człowiek ma dokera, podnosi go, podpina domena i to ma działać. Na czym polega problem? W tym dokerze jest aplikacja, która jest na poziomie takim, jak te dziurawe aplikacje z OWASP-a. Czujecie na co chodzi, nie? Na zasadzie to jest stworzone by design, żeby się tam włamać. I teraz zastanowiliśmy się z teamem, co my możemy zrobić, żeby tak beznadziejnie napisany soft nie zagrażał użytkownikowi i hostingowi. I teraz jeszcze mało tego, żeby to rozwiązanie, które stworzymy, żeby ludzie chcieli korzystać z niego. To trzeba to zareklamować. Damy wam darmowe subdomeny. I teraz gdzie tu jest haczyk? No to jest taka magiczna subdomena. Chodzi o to, że użytkownik dostaje subdomenę, która prowadzi do jego deweloperskiego serwera, do jego dokera. Czyli normalnie workflow powinien wyglądać tak. Stawiasz dokera, stawiasz nginx-a, przerzucasz sobie na przykład jako reverse proxy na ten numer portu, podpinasz domenę przez jakiegoś klautlera, działa ci to. Albo jeden klik w panelu i działa. Wybierz sam. I teraz użytkownik wybiera, dobra, biorę z panelu. Tylko, że to jest magiczna domena. Magiczna domena polega na tym, że po pierwsze, jest tam domyślnie podpięty klautler. Od razu zbiera jakieś skany, od razu zbiera jakieś ataki DDoS-a i inne takie rzeczy, więc mamy tutaj z głowy. Kolejna rzecz, HTTPS by default. Nie istnieje żaden projekt na Mikrusie, który działa po HTTP nieszyfrowanym. Wszyscy jadą z HTTPS-a i nawet o tym nie wiedzą. Domyślnie jest HSTS wgrany, sam jest przerzucany na szyfrowanie, więc działa to sprytnie na jakiejś zasadzie. Bo może ktoś powiedzieć, dobra, a co jeśli się zdarzy tak, że człowiek stworzył aplikację, która działa po HTTP? A ty mu podepniesz HTTPS-a. Po drodze jest reverse proxy, który odwraca te protokoły. Więc masz HTTPS-a, koniec, masz mieć. Kolejna rzecz, Captcha dla nielubionych krajów. Polega to na tym, że jeżeli masz podpiętą naszą magiczną domenę, to Rosja, Chiny, Filipiny znikają. I nie znikają na zasadzie, że nie wejdziesz, tylko będą okaptczowane. Więc dzięki temu znacznie mniej tych skanów jest, znacznie mniej udanych włamań. Wykrywamy też skanery, to znaczy logi, wszystkie requesty, przechodzą przez nasz serwer pośredniczący. Jeżeli przechodzą przez serwer pośredniczący, to my widzimy, jakie to są requesty. Co zrobiliśmy? Odpaliliśmy sobie najpopularniejsze skanery z kali Linuxa, zobaczyliśmy, jakie są wzorce skanowania i następnie dostosowaliśmy system w taki sposób, ażeby blokował te wzorce. To prościej się nie da. Jakieś pytania? Nie, nie, nie. Tego nie robimy. Jeśli chodzi o też technologię, no jaka technologia tam może być? No wiadomo co, no PHP. Bardzo często spotykam się z tym, że jest na przykład takie stwierdzenie, ale moment, moment, bo PHP, kto z tego w ogóle korzysta? No tak się składa, że 70 parę procent świata webowego, jaki znamy, to jest WordPress. A co jest pod WordPressem? No to jest PHP. No więc to jest królująca technologia i teraz musimy się do tego dostosować. Ja jako właściciel hostingu nie mam powiedzieć, człowieku przepisz sobie to na, nie wiem, no uda. Ja mam powiedzieć witaj PHP i po prostu dostosować środowisko tak, aby to działało. No więc robimy. I teraz na czym polega kolejny problem? Micros ma kilka tych tierów, że tak powiem. Tam jest 1.0, 2.0, 3.0 i tak dalej. Najsłabszy możliwy zakup, jaki da się zrobić, to jest Micros 1.0. 35 złotych za rok. I teraz to jest coś takiego, to jest w ogóle cena taka, gdzie się dopłaca. Znaczy nie ma możliwości utrzymania hostingu z tego typu hostingu, cen w sensie, ale chodzi o to, że są ludzie, którzy zaczynają swoją przygodę, chcą mieć jakiś hosting, no więc sobie aktywują, czemu by nie, i rzucają tam mega ciężkie jakieś rzeczy typu, a sobie walnę tam Laravel. Na niecałych 400 megaramu. No i teraz, co się okazuje, działa to całkiem dobrze. Dlaczego? Jest jeszcze jedna rzecz, o której nie powiedziałem. Istnieje coś takiego, co nazywa się u nas Citrusem. Citrus to jest taka usługa dodatkowo płatna, która polega na tym, że przed twoim serwerem stoi wspólny, zawiązany Reverse Proxy. Jest to maszyna, która ma tam 12 core'ów, 128 gigaramu i ty kupiłeś tak naprawdę ten 400 megaramu, ale twój kod wykonywany jest na takiej fajnej bestii. I dalej płacił za to 35 złotych. Więc w ten sposób działa to szybciej. Tylko powoduje to nowe zagrożenia. Bo wiecie, wziąć cudzy kod, hostować to na swojej maszynie, niedostosowanej do jego potrzeb, no to schakują go. No nie da się prościej. Jakie są potencjalne zagrożenia? Pierwsza rzecz. Twój kod jest wykonywany na zewnętrznej maszynie. Jak jest wykonywany na zewnętrznej maszynie, to on musi opuścić twoją maszynę. Więc jeżeli ty jesteś adminem, który umie zabezpieczyć swój serwer, to my ci zabieramy ten kod i dajemy to na nie wiadomo gdzie. No nie brzmi to dobre, nie? Ja jestem kiepski z PR-u. Ale chodzi o to, że drugie zagrożenie jest takie. Wykonuje się twój kod aplikacji na centralnym serwerze. A to znaczy, że wykonuje się w tym samym miejscu, gdzie inne aplikacje. Jeżeli ty napiszesz aplikację świetnie działającą, a kolega napisze beznadziejnie działającą, no to najsłabsza ogniwo. Wiadomo, co się stanie. Kolejna rzecz. Możliwość podgronięcia cudzych projektów. Bo wiecie, to jest PHP. Wiecie, jak wygląda security w PHP, nie? Litera S w skrócie PHP jest od security. I teraz chodzi o to, że jeśli chodzi o izolację dwóch projektów od siebie, no to najczęściej stosuje się coś takiego, jak directory traversal. To znaczy kropka, kropka, slew, kropka, kropka, slew. Wychodzisz piętro wyżej, czytasz te projekty, no i tyle możesz zrobić, nie? Może zdawać się ucieczka z Cetrusa. Ucieczka z Cetrusa, czyli ktoś po prostu opuści nasze wirtualne środowisko, no i zaora nam cały serwis. No to się może zdawać, może zdawać, nie zdarzyło. Ale potencjalne rozwiązania, jakie są, i teraz tak. Pierwsza rzecz. Nie możemy eksportować całej zawartości twojego serwera na zewnętrzną maszynę, więc jest eksportowany tylko jeden katalog o nazwie Cetrus. A więc programista sam, świadomie może ustalić, które dane są wrażliwe, a które są niewrażliwe i powiedzieć, dobra, to jest zdatne do eksportu. Dajemy to. Następnie, kolejna rzecz, no na tym współdzielonym serwerze, jest coś takiego, jak open base dir. Programiści PHP wiedzą, co to jest. Chodzi o to, że nie da się wyjść ze swojego katalogu domowego. Nie da się zrobić tego standardowego kropka, kropka, slash, kropka, kropka, slash i tak dalej. Tylko programiści PHP wiedzą też jeszcze jedną rzecz. PHP umie wykonywać polecenia systemowe. Więc zawsze można dać sobie nie kropka, kropka, slash, tylko cat, etc, paswd i pozamytane. No więc wyłączyliśmy te standardowe polecenia, bo też użytkownicy starali się uciekać z Cetrusa i przez pewien czas mieliśmy mod security. A potem nie mamy tego. Dlaczego? Niektórzy kupują Mikrusa po to, żeby zainstalować tam aplikację dziurawą, typu dvwa na przykład, i hakować ją. I teraz, jak człowiek chce mieć dziurawą aplikację, to co mi do tego? Ja mu muszę tak naprawdę, nie na zasadzie, zainstalowałem dziurawą aplikację, Mrugalski naprawił. No nie, nie chciałem mieć dziurawą, za to płacę. Takie próby ucieczki Cetrusa zdawały się naprawdę bardzo często. Co kilka dni ktoś próbuje hakować tego. Znaczy, to są dwie rzeczy. Pierwsze, zdarzają się hakerzy, którzy chcą uciec i tak naprawdę zhakować coś i zdarzają się ludzie, którzy zachęceni przeze mnie, chcą to hakować. U nas jest taka zasada, że jak ktoś znajdzie dziurę na Mikrusie, to może dostać albo dożywotniego Mikrusa za free, albo na przykład rok, albo nawet za free. Więc ludzie po prostu hakują sobie i bardziej im się opłaca zgłosić mi to, niż na przykład powiedzieć, dobra, zhakowałem Mrugalskiego. Zależnie, czy chcesz PR, czy chcesz darmowy serwer. Dalej, musimy jakoś skonfigurować firewalla. Co i jak ustawiamy? Pierwsza rzecz, jest coś takiego jak model GeoIP i GeoIP pozwala wycinać konkretne kraje, bo dawniej była taka moda, że pod sieci się wycinało. Bierzesz pod sieć, która cię atakuje, sprawdzasz, chuji się, jaką tam pod sieć sobie kupili, wycinasz to z maską tam, nie wiem, slash 24, slash 16 albo coś takiego i to powinno działać. Wiecie, ile jest dostawców sieci komórkowych w Indiach? Jak chcesz ich wyciąć wszystkich, no to jak Reksio w taśmie, enter, enter, wytnij, wytnij, a oni się pojawiają cały czas z nowi. Więc w takim razie, prosta rzecz, jedna regułka, wytnij Indię. I ich nie ma na przykład. Więc taki GeoIP jak najbardziej sobie działa. GeoIP trzeba spiąć z czymś takim, jak dane z MaxMind'a. To są po prostu lokalizacje na zasadzie IP połączone z konkretnym krajem albo z konkretnym rejonem, można dzięki temu bardzo dokładnie wycinać zagrożenia. Kolejna rzecz, wpisujemy sobie wychodzące pakiety SYN, czyli kto, kiedy, o której godzinie, z jakim serwerem się próbował łączyć i teraz po co. No jak będzie jakiś tak zwany abus i przyjdą źli panowie w ciemnych garniturach i zapukają do pana Mrogarskiego, no to ja powiem, to nie ja, mam tutaj dowody. Więc te logi trzeba zbierać. Zbieramy więc informacje i niestety bardzo często z nich korzystamy. Udzielamy po prostu informacje, kto się łączył, kto atakował, o której godzinie, jak to działa. Czasami zdarzają się tacy ludzie, co chcą w niecnych celach kupić serwer. Raz dostałem zapytanie, z którego się śmiałem. Wysłał mi ktoś maila. Z trzema pytaniami. Pierwsze, czy mogę płacić bitcoinem? Drugie, czy współpracujecie z policją? Trzecie, czy dostanę fakturę? Robisz to źle. Zwykle mówię, że mikros będzie dla ciebie niestety za słaby i możesz szukać czegoś mocniejszego. Jest taki fajny serwis. AbuseIPDB się nazywa. Kto zna? Chodzi tylko o to, że jeżeli macie zainstalowanego fail to ban, to można podpiąć się do AbuseDB i teraz działa to na tej zasadzie, że jeżeli ty wykryjesz włamanie, to raportujesz do centralnej bazy danych, żeby było takie włamanie i w centralnej bazie danych się taki troll nazwijmy pojawi. Teraz ja jako użytkownik z drugiej strony mogę ściągnąć tą lista Tam jest oczywiście wersja bezpłatna, wersja suportowana i wersja płatna. Ja jestem z Krakowa, więc jej ostatnio nie używam, ale chodzi o to, że ta free działa całkiem nieźle. Tam jest 10 tysięcy najbardziej trollujących użytkowników z danej podsieci. Można sobie to zaimportować i ich wyciąć po prostu. To też czasami pomaga, bo często skany są z jakiegoś konkretnego dostawcy internetu w konkretnym czasie, więc to naprawdę fajnie działa. Jeszcze jedna rzecz. Poziomie serwerowni. Istnieją serwerownie, ja akurat się hostuję w Hetznerze, którzy mają firewall piętro wyżej, czyli nie na serwerze, tylko level wyżej. Ten firewall jest po pierwsze bezstanowy, więc trochę kiepsko, a po drugie ograniczony. Tam jest maksymalnie 10 regułek. Ale on pomaga w czym? Jak macie atak typu DDoS, mnóstwo tam jakichś hindusów was atakuje, to w tym momencie możecie odciąć to level wyżej, bo wasz serwer może nie wyrabiać z wycinaniem tego ruchu. Przenieść właśnie na trochę inny poziom. Jeżeli chodzi o wycinanie krajów konkretnych, no to tak to wygląda. Oczywiście tutaj młodsza część społeczności u nas powie, a dlaczego IPTables? Dlaczego nie NFTables? Ludzie, ja mam prawie 40 lat. Za moich czasów się używało IPTables. Jest IPTables, działa do dziś dnia. Jak nie bardziej. Chodzi o to, że trzeba to sprytnie zrobić, bo można zajechać swój serwer błędnym filtrowaniem pakietów. To znaczy, o co chodzi? Po pierwsze, zwróćcie uwagę, to jest podpięte do pre-routingu. Po drugie, na warstwie raw, czyli na tych surowych pakietach. I ostatnio są odrzucane metodą drop. Każdy programista powie, nie no, rejecta powinieneś dać. W momencie, jeżeli masz atak na serwer i dajesz rejecta, to produkujesz dodatkowe pakiety zwrotne. Więc jak najbardziej zapchasz sobie kontraka, zabijesz serwer. Co prawda odparłeś DDoS-a, ale nic nie działa. Taki sukces, pacjent nie żyje. Na tej zasadzie. Więc też trzeba to sprytnie zrobić. Kolejny aspekt, czyli w jaki sposób zbieramy informacje o tych połączeniach wychodzących. Połączenia wychodzące z VPS-ów to są po prostu forwardy. Podpinasz się do łańcucha forward i wszystko leci do logów. Na IPTables trzeba tylko zrobić sobie regułę, która będzie to zbierała. No i w ten sposób zbieramy cały ruch. Jeżeli chodzi o ten AbuseIPDB, to jest taka stronka, rejestrujecie się tam i ściągacie trollujący adres IP. Taka podpowiedź. Tak jak powiedziałem, są tutaj takie trzy tiery. Ten płatny, bezpłatny i ten pośredni. O co chodzi z tym pośrednim? Pośredni polega na tym, że na darmowym pakiecie macie 10 tysięcy trolli do ściągnięcia, a na tym supportowym macie chyba 20 tysięcy. Teraz co trzeba zrobić, żeby być na supportowym? Trzeba takiego badża na stronę umieścić. Jestem wspierany przez AbuseIPDB. No i wtedy dostajecie wyższy poziom, macie dwa razy więcej trollujących adbików do nakarmienia swojego firewalla. Tylko też trzeba sprytnie to nakarmić, no bo powiedzmy szczerze, 20 tysięcy dodatkowych reguł w firewallu nie brzmi dobrze. No to nam się tutaj kłania IPset. Tworzymy łańcuch IPseta, karmimy to. No i karmimy to na wchodzące i wychodzące. Można powiedzieć, ale dlaczego wychodzące? No bo to może się okazać, że użytkownik naszego VPS-a jest jakimś potentatem botnetu i próbuje sterować swoim botnetem, więc chce odciąć trolla przychodzącego i odciąć trolla wychodzącego. No i w ten sposób to będzie fajnie działać. Są jednak rzeczy, o których użytkownicy zapominają. Mamy użytkowników początkujących, tych, co sobie strzelają tam w stopę itd., ale mamy też takich naprawdę porządnie wyszkolonych ex-adminów na przykład albo pasjonatów Linuxa i oni tworzą sobie reguły i tak dalej, ale zapominają o jednej rzeczy. Na mikrusie masz IPv4 i IPv6. No i to zwykle tak wygląda. O tym IPv6 nikt nie pamięta. Odciąłem Chiny, odciąłem Rosję, odciąłem coś i połączyli mi się z Chin, z Rosji i czegoś. No a dlaczego? Bardzo wiele serwerów w sensie aplikacyjnych słucha domyślnie na wszystkich adresacjach i słucha ci jednocześnie na IPv6 i jednocześnie na IPv4. Pula adresowa, jeżeli chodzi o nasze serwery, jest łatwa do wyśledzenia, a więc znalezienie wszystkich tych aplikacji jest dziecinnie proste. Więc tutaj ważna taka rzecz, edukujcie ludzi, że istnieje coś takiego jak IPv6, jeżeli w ogóle u Was istnieje, i że tam też jest firewall, tam naprawdę jest jakieś życie i można to blokować. Czasami jest też tak, że użytkownik jest zagrożeniem. To nie jest tylko tak, że zagrożenie wchodzi z zewnątrz, że tam cała Azja, Afryka itd. mnie atakują, tylko czasami jest tak, że mamy złą osobę w środku, na pokładzie. I to jest osoba czasami, można powiedzieć, nieświadomie zła, to znaczy robi coś, ale rozwaliła serwer, ale czasami jest to po prostu troll, który, jego celem jest rozwalenie Mikrusa, po prostu. I z tym trzeba jakoś walczyć. Ale też trzeba rozróżnić jedną rzecz, bo jak mówimy o walce z użytkownikami, którzy coś robią złego, to nie zawsze wszystkie rzeczy klasyfikujemy jako złe. Na przykład nielegalne treści. Można powiedzieć, dobra no, exploity to jeszcze rozumiem, hakowanie to jeszcze rozumiem, no ale tak, nielegalne treści też ja muszę z tym walczyć. Dlaczego? Idzie to na moje konto. I ja najczęściej od serwerowni dostaję informacje, jakie nielegalne treści rozpowszechniam. Dostaję taki raport na zasadzie, że ktoś Torrenta odpalił na przykład, no i ściąga coś. Powiedzmy szczerze, 90 parę procent wszystkich Torrentów to są filmy dla dorosłych. No i serwerownia już trochę mnie tam zna. Panie Mrogalski, znowu porno. Pan się zajedzie. No i ja piszę, że nie, proszę. Nie, tylko piszą, tylko piszą. Takie raporty dostaję, więc znam dokładne preferencje seksualne wszystkich użytkowników Miklusa. No tych, kto się wydali, oczywiście tak, niektórzy z VPN-a korzystają, ale chodzi o to, że teraz trzeba się odezwać do tego użytkownika, powiedzieć mu, że wiem, że masz Torrenta, nie mam pojęcia, co ściągałeś. Musi tą standardową bajeszkę przejść hakerzy. Hakerzy na Miklusie zawsze się włamują i ściągają safę. To jest taki standard. Ale jedna rzecz. Ja nie mam karać użytkowników, ja nie mam sprawiać, że oni nie będą sobie ściągać ulubionych filmów, tylko ja mam sprawić, aby to nie było na moje konto. Aby na moich serwerach nie dało się tego zrobić. Więc prosta rzecz. Blokada standardowych portów trackera, tylko jest taki, wiecie, jaki problem. Niektóre trackery działają na porcie 80, a niektóre na 433. No to część trackerów torrentowych da się wyciąć, ale ogólnie to jest trudne. Ale na szczęście są ludzie, którzy na przykład na GitHubie robią takie kompilacje trackerów. No to co zrobić? Ściągasz wszystkie, karmisz IP seta, odcinasz całość, jest okej. Są też trackery, które działają na przykład na protokołach, które nie są szyfrowane, czyli nie lecą po HTTP, a jeśli lecą po HTTP. Tam jest problem prosty, dlatego że na przykład, znowu IP tables, ale w IP tables można zrobić matchowanie stringa w środku pakietu. Jeżeli nie jest szyfrowany, to szukasz na przykład ten element handshake'a. Możesz sobie zrobić handshake z trackerem, to go wycinasz automatycznie. I wtedy ktoś zgłasza etyketa, że nie działa mi pewna aplikacja. Ja mówię, pewnie torrent. Safa pozdrawia, tak? Ale to jest też ważne. Wiecie dlaczego to jest ważne? Serwerownie często dają 24 godziny na rozwiązanie problemu, a jak nie, no to się nie ma w serwerowni. I teraz mamy dużo, dużo, dużo serwerów i tysiące użytkowników i jeden gość może odciąć to wszystko. Więc muszę o to dbać. Czasami jest już tak, że użytkownik sam nie wie, co robi. To znaczy, no najczęściej zapętliło mu się coś. Użytkownik odpalił 30 tysięcy procesów. No tak się zdarza. I teraz co zrobić? No można edukować takiego człowieka, nie odpalaj proszę 30 tysięcy procesów, ale on to nie zrobił świadomie. Edukacja tutaj nic nie da. Więc najprostsza rzecz. Limit skąd? Limit skąd, wiecie co to jest, nie? Można ustawić limit procesów i inne takie rzeczy. Oczywiście ktoś powie, ale moment, użytkownik może to odpiąć sobie, w sensie zakomentować i będzie mógł tych 30 tysięcy procesów. Tylko zwróćcie jedną uwagę. Jeżeli ktoś wie, gdzie tego szukać, wie, do czego to służy i sobie to odkomentowuje, to to jest świadomy gość. Oni też czasami puszczają 30 tysięcy procesów, ale chodzi o to wywadziej. Więc nie mogę sprawić, żeby człowiek nie mógł wykonać swojej standardowej pracy, ale mogę na przykład dostosować domyślny system operacyjny, w sensie obraz systemu tak, żeby mógł stopę strzelić, a jednocześnie, żeby mój serwer to nie bolało. Kolejna rzecz. Miesięcznie przejmowanych było tak 7-8 VPS-ów, a w wakacje trochę więcej. I większość tych serwerów to po prostu słabe hasła. Nic więcej. Mieliśmy taką zabawę z adminami, że publikowaliśmy na Facebooku takie hasła, które zostały złamane. Oczywiście bez informacji, do kogo należały, ale to były najczęściej. Login root, hasło root. Jeżeli ktoś napisał fantazję, to napisał root w SPAC na przykład. Tego typu hasła to były. I nagle się okazuje, ojej, złamali mi tutaj hasła, włamali się i znowu ściągali zawsze. Więc trzeba coś z tym zrobić. Jak przeciwdziałamy takim rzeczom? Pierwsza rzecz. Wymuszenie mocniejszych haseł. Jak dostajesz serwer, to domyślnie nadane jest hasło, dość złożone, alfanumeryczne, to już na start serwer jest trochę bezpieczniejszy. Trzeba coś z tym zrobić. Druga rzecz, która jest. Mikros ma też coś takiego jak forever free serwery. I one były najczęściej hakowane. Bo wiesz, jak masz coś za darmo, to nie szanujesz. Prosta sprawa. I tam było wprowadzone rozwiązanie, mniej więcej rodem z AWS, czyli nie masz użytkownika root domyślnie do zalogowania, tylko masz użytkownika o nazwie frog, żaba. Okazuje się, że Chińczycy na żabę rzadko się głomują, więc w takim razie zadziałało. Śmieszne, dziwne, ale działa. Więc tutaj mamy coś takiego, że użytkownicy darmowych serwerów muszą wejść na użytkownika, zrobić sobie sudu i wtedy dopiero pracować dalej. Całkiem fajnie to zadziałało. Instalowaliśmy fail to bana. Nie róbcie tego. Nie idźcie tą drogą. To brzmi jak dobry pomysł. Ale jak zetknie w sobie fail to bana z początkującym użytkownikiem, to nie chcesz widzieć kolejki ticketowej. Nie działają te wasze serwery. Odcięło mnie. A ile razy próbowałeś się zalogować? 20-30 na tej zasadzie. Jak człowiek jest początkujący, ma często problemy jak się dostać. Tam są czasami ludzie, którzy mówią, ale dlaczego nie mogę się połączyć file zealom po FTP do mojego SSH? To są ludzie, którzy właśnie nie do końca rozumieją jak coś działa. I jedna rzecz, nie mówię tego, żeby się z tego śmiać, tylko chodzi o to, że to jest środowisko rozwojowe. Oni mają się nauczyć jak to działa. No to nie mogę ich nauczyć na początku dając im bana. Promowaliśmy też taką akcję używaj kluczy SSH, a nie haseł. Trochę to działa. Odrobinkę działa. Na czym polega ta promocja? W panelu informacja dodaj sobie klucz. Przy rejestracji mail powitalny użyj klucza. Potem jest taka kolejka automatyczna, co maile wysyła i tam takie tips and tricks. Nie wiem czy wiesz, ale możesz używać klucza. Skuteczność? Do 2%. Ale dobra, to jest 2% ponad poziom zerowy. Opłacało się, opłacało. Więc jak najbardziej można coś takiego wdrożyć. Gdy są użytkownicy bardziej techniczni, no to oni sami z siebie wiedzą, dobra, mam używać kluczy i to będzie okej. Ale wymuszenie logowania kluczami na takim środowisku niestety nie zadziała. Jest też wcześniej wspomniany firewall, czyli wszystkie te połączenia po SSH, które oni próbują robić, nie będą działać. Poza tym jeszcze robimy jedną rzecz. Czasami są ludzie oburzeni tym co robimy, ale według mnie to jest fajne. Polega to na tym, że łamiemy hasła użytkowników. Jest to wpisane w regulamin. W sensie, gdy zakładasz konto, to jest informacja, że regularnie będziemy próbować łamać twoje hasła, a automat powiadomi cię, gdy nam się to uda. No, sporo się takiego wylało, nazwijmy hejtów zresztą, ale dlaczego? Jak sobie ludzie wyobrażają łamanie haseł użytkowników? No nie, jak masz skonteneryzowaną wirtualkę, wyciągasz szadoła, rzucasz na maszynę do łamania. Nie boli to ani użytkownika, ani mnie nie boli. Oddzielna maszyna to łamie, więc tam dość szybko to działa. I to całkiem fajnie działało. O tym jeszcze opowiem. Ale jeszcze można było wzmocnić domyślny system operacyjny w taki sposób, aby użytkownik musiał ustawić trochę trudniejsze hasło. Są moduły PAM. Podpinamy sobie to jako PAM Authentication Module. I polega to na tym, dwa moduły jakie były używane. PAM PW Quality, czyli Password Quality, a drugi to był Cracklib. I Password Quality umożliwiał sprawienie, że jeżeli ktoś się loguje na serwer i wpisuje polecenie passwd, to pewne wymagania są co do tego hasła. Na przykład nie mógł ustawić hasła, które zawierało nazwę użytkownika w środku. Czyli jak masz login Basia, to nie możesz ustawić sobie Basia 1, albo Basia z dużej litery. Nie może być to powtarzalny ciąg znaków, czy nie możesz mieć hasła typu AA. Ale powiedzmy szczerze, użytkownicy mają sporo wyobraźni. Są zdolni. I ustawili sobie hasło typu Basia z dużej litery, A zmienione na czwórkę. No i dalej to jest beznadziejne hasło, ale już trochę trudniej jest to złamać. Więc coś to dało. Ale wtedy dorzuciliśmy Crackliba. Cracklib działa na tej zasadzie, znaczy on działa na wielu zasadach, ale wykorzystujemy to, żeby wrzucać na desk słowniki. I te słowniki będą sprawdzane podczas ustawienia hasła, czy przypadkiem ktoś nie ustawia hasła z listy zablokowanej w słowniku. I wtedy bierzemy sobie listę top milion haseł w języku polskim, wrzucamy tam na desku użytkownika i jeżeli ktoś wpisze hasło z tego top miliona, albo permutację tego hasła, to to hasło nie będzie zaakceptowane. Więc drastycznie to też podniosło złożoność tych haseł. Znowu, ja myślałem, że jak będzie tyle tych obostrzeń, tyle tych komunikatów, złe hasło czy coś, to w końcu się użytkownik wkurzy i pójdzie w klucze. Nie. Są twardzi. Ale jeżeli mówimy o tych łamaczach haseł, to jest ten moment, kiedy wchodzi Johnny, Johnny Rozpróbacz, i teraz chodzi o to, John Draper cały na biało oczywiście, i teraz on próbuje łamać te hasła. Dlaczego nie hashcat? No hashcat jest całkiem fajny, gdy masz GPU. A my mamy low budget, więc mamy CPU, John działa dobrze, a poza tym znowu zaszłość historyczna. Jeśli chodzi o słowniki, na cercie np. cert.pl przez hasła można sobie ściągnąć tutaj, jest ta baza polskich haseł i to importujemy jak najbardziej. I do tego całkiem fajnie z dystrybucji Kali Linux mamy np. Rakiu. I ten Rakiu też jest do przelecenia. Łamanie tych haseł jest bardzo, bardzo ciężkie pod względem obliczeniowym, ale do tego mamy oddzielną maszynę, jakoś nas to specjalnie boli. Kolejna rzecz, która jest też często robiona, jeżeli chodzi o Mikrusa, to nie są KVM, czyli pełna wirtualizacja, tylko to są konteneryzacja. Więc bez najmniejszego problemu, jednym poleceniem PS, jestem w stanie zobaczyć, co kto ma uruchomione. No to można napisać prostą pętelkę, która wykrywa interesujące procesy użytkowników. Wiemy, jakie procesy są odpalane przez malware np. po łamaniu. One mają zazwyczaj dość standardowe nazwy albo nazwy pasujące do pewnych regexpów i jeżeli coś takiego wykryjemy, to wtedy ten serwer automatycznie jest zatrzymywany, mail jest wysyłany do użytkownika i w tym panelu może powiedzieć, spoko, kontroluje sytuację, na przykład. Jest to zgodne z regulaminem, więc się godzą. Raczej się tutaj nie zdarza false positive. Inna rzecz. Wykrywanie interesujących kont użytkowników. Bo jeżeli dochodzi do łamania, to bardzo często w systemie zakładane jest pewne, jakby to powiedzieć, powtarzalne konta. Nagle ci się w systemie pojawia użytkownik Achmed, przykładowo. No i widzisz Achmeda Dajzbana. Tu się zdarzył false positive, napisał do mnie użytkownik. Nam nie zawsze mówili Achmed. Jaki problem masz? Napisaliśmy wyjątek dla jego serwera, ale pozostali, Achmed, dostają blokadę. Chodzi o to, że czasami się wystawia serwery, na przykład, po to, żeby faktycznie dało się na nie włamać, żeby zobaczyć w kontrolowanych warunkach, jak wygląda ten atak, jakie procesy będą odpalone, jakie konta zostaną założone. Czasami jest to tak, że użytkownik stara się rozwalić serwer od środka. Zupełnie świadomie, albo czasami nieświadomie. Różnie bywa. Na poziomie głównego hosta robi się coś takiego, jak limitowanie CPU, w sensie, ile maksymalnie mocy jest w stanie on tam przyjąć. To jest robione u nas dynamicznie. To znaczy, jak to powiedzieć? Często ludzie pytają, dobra, ile tego CPU dostaje użytkownik Mikrusa? To znaczy, chodzi o to, że jeżeli są takie testy, takie małe skrypciki testowe do odpalenia, który VPS jest lepszy? Czy na przykład Digital Ocean, czy Mikrus? Mikrus zawsze wygrywa. Tylko tam jest mały haczyk. Dlaczego wygrywa? Mikrus jest lepszy w pikach. Jakbyś jednostajnie chciał go obciążać przez taki czas, to tam automat cię przytnie. I każdy serwer będzie lepszy od Mikrusa. Ale na takich prostych testach po prostu wygrywamy. Nie chcę oszukać, tylko chodzi o to, że w normalnych… Proszę? Jak w Volkswagen. Ale powiem wam, jaki jest cel tego. Cel jest taki, że większość operacji, które wykonuje użytkownik, to są operacje krótkie, pikowe. Chcesz coś skompilować, trwa to 2-3 minuty i tyle. Nie potrzebujesz na przykład mieć CPU super mocnego na przykład 3 godziny najczęściej. Jeżeli potrzebujesz, to są inne serwery do tego. Dostajesz na przykład 50% mocy całego dydyka. Kompiluj. Jak zobaczymy, że trochę przesadzasz, to ci spadnie 25%, 10%. Po prostu dostajesz więcej niż płacisz, ale jak nie jest to taki fair play, to cię przytniemy. Dlatego nie ma tam gwarancji, ile dostajesz CPU. Dostajesz tyle, żeby było ci dobrze. A dobrze to jest bardzo subiektywne. Kolejna rzecz – IODysku. To samo. IODysku dostajesz limit, dyski SSD, NVMe. Całkiem fajnie to działa, ale znowu z limitami. Limitowanie. Tam jest technologia LXC. Jak sobie poszukacie w dokumentacji LXC, nie da się limitować IODysku. Ale LXC działa na C-grupach. Jak sobie poszukacie albo zapytacie chat GPT, jak przyciąć na C-grupach LXC IODysku, to wam poda taką długą, długą linijkę. Zrobicie kopię kopejstwa i będzie działało. Więc da się jak najbardziej coś takiego zlimitować. Ważna rzecz – wszystkie kontenery LXC nieuprzywilejowane. Unprivileged. Dlaczego? Jak będzie privileged, to szukacie innej pracy. Już nie pracujecie w hostingu. Chodzi o to, że wszystkie urządzenia blokowe, wszystko, co tam się da w dewie sobie utworzyć, użytkownik może wyskoczyć z takiego kontenera. Bez najmniejszego problemu zaoraci cały serwer. Na to trzeba ubawać. I jest jeszcze jedna rzecz, o której się zapomina. Bo projektując coś takiego, projektujemy taką osadę. Działa to w ten sposób, że mamy taką osadę. No i wiecie, to działa całkiem fajnie. To znaczy, na czym polega fajne działanie. No fajne działanie polega na tym, że mamy te domki, to są te VPS-y. One są otoczone takim fajnym warstwą zabezpieczającą. Tam nie wejdą Hindusi, inni tacy ludzie. Ale jest jeden problem. Każdy człowiek na świecie może wynająć absolutnie dowolny z tych domków. No i po co ci ten mur? Czujecie, o co chodzi? Wchodzi ktoś do środka, podpala, atakuje swoich kolegów. Więc też trzeba, projektując takie rozwiązania, dbać o to, aby ruch wewnętrzny był też filtrowany, ruch wewnętrzny był też w jakiś sposób monitorowany, co tam się dzieje, i żebyśmy byli w stanie to odciąć. Bo może się zdarzyć, mikrosy działają tak, że mają wewnętrzną adresację, czyli tam 192, 168 i tak dalej, i serwery się widzą nawzajem. I to nie jest bug, to jest feature. Chodzi o to, że często ludzie kupują kilka VPS-ów i chcą je spiąć w jakiś klaster, chcą je spiąć w coś, ale czy to może być używane do niecnych celów? No nie tyle może, co jest. Więc jak najbardziej tak. Jeśli chodzi o ogólnie temat hostingowy, to warto zapamiętać, że zabezpieczenie hostingu bardzo mocno różni się od zabezpieczenia jednego pojedynczego serwera. Nie jesteś w stanie najczęściej wdrożyć tych wszystkich porad, które znajdują się w internecie, tak aby nie zaszkodzić użytkownikom. A jednocześnie, próbując dostosować się do tych użytkowników, obniżasz poziom bezpieczeństwa. I teraz co trzeba zrobić? Znaleźć taki balans. Jest to taka pogoń w nieskończoność. To znaczy, to nie jest skończona konfiguracja Miklusa. Powiedzmy szczerze, że w 40 minut nie jestem w stanie Wam tego wszystkiego przedstawić, ale są to najprostsze rzeczy, jakie wdrożyliśmy, a które dały ciekawe efekty. Mam jeszcze dla Was taką prośbę. Poświęćcie proszę 5 sekund dosłownie na wypełnienie ankiety. Proszono mnie, żeby taki slajd zamieścić. Ale mamy jeszcze kilka minut na to, ażeby były jakieś pytania. Czy są jakieś pytania?