Dzień dobry. Piotr Ksieniewicz, firma Network Expert. Kontynuując nasz cykl poświęcony portfolio produktów security, czyli tak naprawdę temu, co można kupić i co można zastosować w zakresie produktów bezpieczeństwa teleinformatycznego – dział poświęcony ochronie dedykowanej konkretnej aplikacji, czyli tak naprawdę wąskiej specjalizacji tego, co możemy zastosować. O czym powiemy?

Powiemy o ochronie poczty, ochronie weba, ochronie kierowanej również na aplikację webowe, aczkolwiek w drugim kierunku, czyli Web Application Firewallach. Powiemy o systemach IPS, IDS, a także o systemach WIPS, powiemy o ochronie DNS.

Pierwszy temat: ochrona poczty.

Kiedy my tego tak naprawdę potrzebujemy?

W większości przypadków w tej chwili spotykamy się z tym, że serwery pocztowe jednak są hostowane przez operatorów telekomunikacyjnych, takich, którzy jakby zajmują się tym zasadniczo profesjonalnie. I oni zapewniają takie systemy – natywnie, inhousowo – z różną jakością. Jakość tych systemów na pewno należałoby przetestować. Natomiast w momencie, kiedy korzystamy z takiego operatora, który zapewnia cloudowo dobrą jakość ochrony poczty może nasz system nie jest niezbędny, nie jest priorytetowy w zakresie zakupów i planowania bezpieczeństwa naszej infrastruktury. Natomiast kiedy ten serwer stoi u nas – serwer pocztowy, czyli serwer SMTP odbierający połączenia z innych serwerów jest u nas – zdaje się to być kluczowe. Mamy przypadki klientów, którzy bez takiego zabezpieczenia po pierwsze walczą ze spamem, czyli z napływem informacji było nie było niechcianych, zaśmiecających pocztę, zajmujących czas pracownikom, administratorom, zajmujących zasoby, w sensie nawet dyskowe. Tak że taka ochrona pod kątem spamu jest niezbędna. Niezbędna jest ochrona pod kątem oczywiście również malware’u – złego, złośliwego oprogramowania a także pod kątem phishingu, czyli próby wyciągnięcia od nas najczęściej ostatnio haseł, czyli przekierowania nas do jakiejś strony, która w jakiś sposób będzie podszywała się pod inną stronę i próbowała od nas uzyskać hasło stosowne, czy to do banku, czy do jakiegoś innego systemu, który może mieć jakąś wartość, jakieś znaczenie. W ochronie przed phishingiem, jeśli mamy system bazujący na serwerach chmurowych, to wypadałoby zweryfikować, czy tak naprawdę chroni nas przed tymi zagrożeniami. My dysponujemy metodami weryfikacji, mechanizmami, które pozwolą ocenić, czy taki mechanizm chmurowy bazujący na serwerze poczty, który stoi gdzieś w chmurze, jest dobrze odporniony na mechanizmy związane z zagrożeniami. Natomiast wracając troszeczkę do tego Email Security Appliance’a, czyli do tego produktu i trochę potraktowawszy go jako coś, co może stanowić dla nas wzorzec, jak taka ochrona poczty jest zbudowana. W pierwszym etapie budowana jest na podstawie reputacji, czyli tak naprawdę bierzemy sobie taką listę serwerów pocztowych wraz z ich reputacją, czyli poziomem zaufania, jaki mamy do tejże konkretnej organizacji przesyłającej nam pocztę. I taką listę reputacyjną utrzymuje za nas procudent, bazując na swoim Cisco Talos, czyli na swoim Threat Intelligence. na tych 600-700 inżynierach, którzy siedzą i żmudnie analizują wszelkie zdarzenia związane z bezpieczeństwem i wiedzą, że jeżeli ktoś wysyła jakąś masową pocztę na temat wygranej w lotto czy też ewentualnie przedłużeniu swojego penisa, no to jest to prawdopodobnie serwer który należy zaklasyfikować jako serwer spamowy. Czyli pierwszy filtr, który blokuje jakby znakomitą większość, to reputacja, czyli po prostu lista, którą sporządza za nas Talos. Później mamy takie mechanizmy SPF, DKIM i DMARC. O nich za momencik powiemy sobie. Później mamy tak naprawdę taki mechanizm troszkę opierający się na sztucznej inteligencji. Później możemy mieć skanowanie plików, załączników pod kątem antywirusowym. Możemy pod kątem podpisu związanego z tym plikiem, czyli tak naprawdę bierzemy sobie plik i – trochę jak opowiadaliśmy w części poświęconej antywirusom – robimy na nim taką operację binarną, matematyczną, kryptologiczną, która tworzy podpis z tego pliku. I w znakomitej większości w ten sposób jesteśmy w stanie wyblokować zagrożenia, patrz na przykład wirus Total czyli taka strzałka, która publikuje wszem i wobec te podpisy SHA plików, które są zagrożeniami. Patrzymy, jak zachowuje się tenże plik w warunkach tak naprawdę sandboxa. Za pomocą wyrażeń regularnych odfiltrowujemy również zagrożenia związane z social marketingiem, tak zwanego graymaila. Możemy tworzyć również regułki biznesowe, czyli czy ten mail jest po przeczytaniu… Bo pamiętajmy [błąd dźwięku] ona tak naprawdę automatycznie czyta sobie wszystkie te maile, czy ten mail ma charakter biznesowy, czy też nie. No i wreszcie możemy popatrzeć na linki, które są w tych plikach, URL-e: czy one są związane z phishingiem, czy też nie. Co ciekawe, możemy analizować również obrazki, możemy rozszywać komunikaty zaszyfrowane. To dzieje się w kierunku wejściowym. Natomiast w kierunku wyjściowym? Z tego kierunku wyjściowego dla nas najważniejsze tak naprawdę zdaje się być… Oczywiście ważny jest antywirus, natomiast ważna jest ochrona informacji, które my tak naprawdę wysyłamy, czyli Data Link Protection, czyli ochrona przed wyprowadzeniem ważnych informacji z firmy.

I teraz uwaga. Zasadniczo większość tych systemów, z którymi się zetknąłem jednak w zakresie DLP wbudowanego w Email Security jest bardziej dedykowana rynkom amerykańskim. Są zdecydowanie filtry podefiniowane, na przykład Insurance Policy, Insurance Number – coś, co generalnie nie przystaje do rynku polskiego. Oczywiście tak naprawdę producenci dają mechanizmy, które pozwalają tworzyć własne regułki. I mamy takie regułki, natomiast należy pamiętać o tym, że te regułki grepowania, czyli przechwytywania tego tekstu i kontroli, co w tym tekście jest, należy potworzyć

odpowiednio na rynek polski tak żeby złapać ten tekst, który nas interesuje przy komunikacji wychodzącej z naszej poczty. No i oczywiście trzeba pamiętać że za tą naszą ESA, czyli Email Security Appliance, tak jak zwykle w przypadku produktów Cisco, stoi Cisco Talos, czyli generalnie bardzo, bardzo duża baza Threat Intelligence czyli zagrożeń, tej inteligencji związanej z tymi zagrożeniami, tłumacząc to w taki sposób bardzo dosłowny. Ale jest to po prostu olbrzymia baza, która gromadzi informacje z wszystkich produktów Cisco dedykowanych security i propaguje te wszystkie odkrycia, które dokonał często ktoś za nas w Singapurze na urządzenia innych użytkowników, tak żeby później podzielić się tą mądrością, która spłynęła do centrum Threat Intelligence Cisco.

A teraz pokrótce o tych mechanizmach, które są bardzo dedykowane. Dlaczego o nich mówię? Dlatego, że warto pamiętać, że ten mechanizm ochronny poczty w przypadku Email Security Appliance odbiera zasadniczo za nas tę pocztę. Trzeba pamiętać, że część vendorów, część producentów ten Email Security zaszywa w urządzeniach typu Next Generation Firewall. I nie jest w tym nic złego, natomiast należy się zawsze stanowić, czy one jakby posiadają wszystkie te metody, które dedykowany system ma, posiada. Czyli należy podejrzewać, że nie. Natomiast oczywiście nie będę posługiwał się przykładami. Znam mnóstwo takich systemów, które posiadają jakąś bazowąochronę poczty wbudowną w NGF-a, czyli Next Generation Firewalla. Ale zasadniczo jeżeli zerkniemy głębiej, no to już takich zaawansowanych mechanizmów, jak tutaj na slajdzie, nie ma. Dlatego te mechanizmy są fajne i zaawansowane? Jest na przykład Sender Policy Framework, czyli coś, co w waliduje, czy serwer mailowy, który przysyła nam maila, w zasadzie jest autoryzowany dla konkretnej domeny, z której mówi, że przesyła maila, do wysłania maila. Czyli taki sprytny mechanizm, który mówi „przesyłasz mi maila z domeny cisco.com albo z domeny networkexpert.pl, czy naprawdę możesz z tej domeny mi tego maila wysłać?”. Super sprawa, fajnie jakby pozwala nam na to pytanie odpowiedzieć.

Drugi, DKIM, czyli tak naprawdę protokół który pozwoli nam podpisać niejako za pomocą DKIM komunikację, czyli SPF w zasadzie bazuje na zwykłych rekordach tekstowych, a DKIM bazuje na podpisie cyfrowym, czyli podpisuje tę komunikację i możemy w ten sposób stwierdzić, czy rzeczywiście ten nadawca jest uprawniony do bycia nadawcą dla tej konkretnej domeny. Nad tym wszystkim jeszcze może stać sobie protokół DMARC, który jakby integruje w sobie DKIM-a i SPF-a, dodatkowo zapewniając im ekstra bezpieczeństwo. Tak że warto zerknąć, czy system ochrony poczty ma te wszystkie mechanizmy wbudowane. O antiphishingu troszeczkę już powiedzieliśmy, czyli Email Security w oczywisty sposób również zerka w tego maila i pod kątem analizy, ochrony phishingowej stwierdzam URL-e zawarte w moim linku, czyli jeżeli ktoś mi wysyła jakiś odnośnik, czy ten odnośnik jest bezpieczny do kliknięcia. Bo jeżeli nie jest, to wtedy możemy go usunąć.

No i tyle o poczcie. Poczta pamiętajmy, że jest takim systemem dodatkowym. Nie należy jej kupować od razu, od strzału, w pierwszym wypadku. Nie jest to priorytet, no chyba że mamy swoje serwery SMTP i one są utrzymywane u nas, na naszych zasobach z jakichś takich konkretnych względów, które na nas to wymuszają. Wtedy ten system ochrony poczty jest nam zdecydowanie potrzebny i radzę nie zastępować go NGF-em, czyli czymś, co jest do wszystkiego. Next Generation Firewall jest dobry, ale w momencie kiedy jest raczej do ruchu użytkowników, tak bym powiedział.

Systemy IPS/IDS. Troszeczkę gdzieś wchodzimy od poczty do sieci znowuż, bo IPSy, IDSy- to są systemy, które są aplikowane w sieci, czyli coś, co na podstawie ruchu sieciowego wsadzone niejako w sieć pozwoli wysłać informację o tym, że coś było zagrożeniem, czy też nie było. Jak to się aplikuje? Bardzo często po prostu aplikuje się na przykład w ścieżce ruchu, czyli jeżeli mamy przejście od jakiegoś VLAN-u użytkownikowego do datacenter, jest to połączenie między switchami, to możemy tam wstawić IPS-a i ten IPS, czyli Intrustion Prevention   jest systemem inline’owym, czyli wsadzamy niejako w ścieżkę, co powoduje, że ruch przechodzi przez ten system i można za pomocą IPS-a zablokować ruch. IDS natomiast, Intrusion Detection System, jest czymś, co dostaje kopie ruchu, tak jak tutaj widać na rysunku. Mamy IPS-a, który jest w ścieżce i IDS-a, który jest gdzieś z boku. IDS dostaje kopie ruchu i może w zasadzie ale prostować o tym, że widział coś niebezpiecznego. A co on widzi niebezpiecznego? No widzi niebezpiecznego w sytuacji, kiedy zobaczy na przykład jakiś atak na serwer webowy, na przykład cross-site scripting. O tym, co to jest cross-site scripting za chwilę sobie też oczywiście w bardzo dużym skrócie powiemy. I wtedy on podnosi alert, ewentualnie blokuje taki ruch. Są Network IDS-y, są Host IDS-y, czyli możemy takiego IDS-a postawić w zasadzie na konkretnym serwerze. Są Wireless IPS-y. O tym wszystkim troszeczkę, o Wireless IPS-ie za moment. Natomiast generalna konkluzja: kiedy te IPS-y były takim produktem rzeczywiście wolnostojącym, czyli było to często sprzedawane właśnie w miejscach, w których trzeba było oglądać wewnętrzny ruch sieciowy, tak to nazwijmy. Bo znowuż IPS jest bardzo często ostatnio częścią Next Generation Firewalla, czyli systemu, który gdzieś tam na brzegu naszej sieci siedzi czy też między jakimiś ważnymi fragmentami tej sieci, szczególnie między czymś, co jest jakoś strasznie solidnie chronione, na przykład jakieś zasoby serwerowe albo zasoby serwerowe o bardzo dużym znaczeniu. Natomiast tego IPS-a, IDS-a gdzieś tam się wstawiało wewnątrz, czyli tam, gdzie poza tym może innego filtrowania nie było, ale chcieliśmy wykrywać zdarzenia niebezpieczne. No i konkluzja taka, że kiedyś był to produkt często odseparowany. Teraz jakby sprzedaż samych IPS-ów, IDS-ów jest mniejsza zdecydowanie. Natomiast one dalej mają silną rolę i trzeba z nich korzystać w momencie, gdy chcemy przynajmniej mieć świadomość monitorowania bezpieczeństwa naszej sieci, wewnętrznej sieci. No i wtedy na pewno w ramach jakiegoś systemu SIEM-owego, SOK-owego, w zasadzie jako pożywka dla SIEM-a, będzie występował gdzieś Network IDS. Do tego on się nam na pewno przyda. Natomiast rzeczywiście na brzegu często zintegrowane z Next Generation Firewallem. Kiedy niezintegrowane? Wtedy, kiedy na przykład mamy problemy wydajnościowe, czyli chcemy, żeby url-filter zajmował się url-filtrowaniem, natomiast IPS zajmował się IPS-owaniem, no i zakładając, że będzie to po prostu separacja zdarzeń, spowoduje większą wydajność całego systemu.

No i ciekawy przykład – Wireless IPS.

I to w zasadzie fajny temat, który powinien mieć każdy. Dlaczego? Dlatego, że wszyscy mają sieci bezprzewodowe. Natomiast rzadko kto je monitoruje na taki poważny sposób. A z sieciami bezprzewodowymi związane jest sporo zagrożeń, naprawdę realnych, naprawdę prawdziwych, jak na przykład pojawianie się AP-ków, które próbują się podszywać pod naszą sieć po to, żeby zachęcić naszych użytkowników do połączenia, przedstawić im na przykład nieprawidłowe okno do zalogowania, poczekać, może któryś z nich wpisze hasło. Czyli taka możliwość jak najbardziej jest. Są ataki polegające na tym, że gdzieś będziemy próbowali naszych użytkowników deautentykować, będziemy podsłuchiwać jak oni się z powrotem uwierzytelniają, a później za pomocą na przykład metod kryptografii, w zasadzie pewnie kart graficznych, ich mocy obliczeniowych, będzie próba odzyskania tegoż hasła do naszej sieci WiFi na podstawie obliczeń, żmudnych obliczeń kryptograficznych. I właśnie ten WIPS to tak naprawdę jest taki IPS/IDS dedykowany sieci bezprzewodowej. u on, co ciekawe, nie ma dziesiątek, setek tysięcy sygnatur, tak jak w przypadku IPS-a, IDS-a, tylko ma tych sygnatur zazwyczaj koło kilkudziesięciu, dwustu. Bo to są sygnaturki dedykowane tylko systemom bezprzewodowym. To, co właśnie pojawia się… Tak jak mówiliśmy, może się pojawić ten AP-ek, który na przykład będzie się pod nas podszywał. Taki, który spróbuje od nas wyciągnąć hasło. Może się pojawić jakiś jammer, który będzie zakłócał naszą sieć. Może się pojawić coś, co będzie próbowało za pomocą podszywania się pod ramki kontrolne na przykład deautentykować użytkowników. I to wszystko IPS zobaczy. Co warto pamiętać? Warto pamiętać o tym, że trzeba oczywiście pamiętać o odpowiednim zaprojektowaniu naszej sieci bezprzewodowej, tak żeby ona miała widoczność tego, co w tej sieci bezprzewodowej się dzieje. Czyli żeby na przykład obserwowała czasami nieużywane przez nas kanały bezprzewodowe, ale o tym może powiem w osobnej sekcji – o całej sieci bezprzewodowej. Ochrona dedykowana webowi, czyli Web Proxy. Co to tak naprawdę jest i czy ja tego potrzebuję? Web Proxy to jest najczęściej teraz tak naprawdę element w zasadzie prawie, bo to nie do końca, jest to samo, ale bardzo zbliżony do tego, co znajduje się w Next Generation Firewallach. Next Generation Firewall nie jest serwerem proxy dla ruchu webowego. Natomiast może zobaczmy, czym ten serwer proxy jest. Znowu podobnie jak w tym temacie związanym z SMTP, czyli z pocztą, serwer proxy jest czymś, co pośredniczy w naszej komunikacji webowej. Czyli jeżeli ja mam klienta siedzącego gdzieś na swoim komputerze, to on wychodząc do internetu, oprócz tego że pewnie gdzieś będzie musiał przejść przez jakiś firewall, [błąd dźwięku] ten człowiek musi się połączyć tak naprawdę z serwerem proxy, który za niego zrobi dalej robotę. Czyli ten serwer proxy będzie się łączył już do konkretnego serwera w internecie, jak na to popatrzymy. Komputer w środku sieci nie łączy się bezpośrednio do internetu, tylko łączy się z użyciem serwera proxy. To oczywiście powoduje [niezrozumiałe], bo on ma inne regułki. Wystarczy wypuścić ten serwer proxy, a on dla nas staje się takim elementem bezpieczeństwa webowego, czyli może dla nas zrobić podobną operację jak robi Next Generation Firewall. Czyli może blokować bądź też zezwalać ruch na podstawie kategoryzacji URL-i, rozszywać SSL-a, zaglądać co tam w środku, przeględać czy przypadkiem w ramach jakiegoś ruchu webowego nie jest przesyłany jakiś plik z zagrożeniem. Czyli w zasadzie to samo, co dla NGF-a, ale ukierunkowuje nasz HTTP. I dodatkowo ukierunkowane na to, że ta komunikacja jest niejako dwupołączeniowa. Czyli z jednej strony mamy połączenie od serwera proxy do klienta, a drugie od proxy do serwera docelowego. Jest to całkiem fajne rozwiązanie. Jest to rzadziej spotykane obecnie, natomiast ono jest bardzo dobre, jeśli chodzi o wydajność, no bo jest to dedykowane tejże komunikacji webowej, zatem takie rozwiązanie Web Proxy może znacząco odciążyć nasz firewall, który może zajmować się dużą ilością innych zadań. Tak że kiedy ja tego potrzebuję? Potrzebuję tego wtedy, kiedy nie mam Next Generation Firewalla i chciałbym nie zmieniać samego firewalla, pozostawić go, natomiast chciałbym mieć funkcjonalność filtrowania URL-i, bezpieczeństwo komunikacji webowej od klienta do internetu. Ewentualnie wtedy, kiedy mam tego Next Generation Firewalla, ale on zaczyna niedomagać pod względem wydajności. No i może wtedy warto na przykład go nie wymieniać w całości, tylko zainteresować się takim systemem proxy, czyli odciążyć go troszeczkę od ruchu. I teraz trochę temat w inną stronę, czyli Web Application Firewall, czyli coś, co jest też ukierunkowane na ochronę webowego ruchu, natomiast jest to ruch przychodzący. Czyli chronimy teraz nasze serwery, czyli coś, co mamy w naszych zasobach. Zatem od razu nasuwa się: kiedy tego potrzebuję? Kiedy udostępniam jakieś istotne, ważne serwery webowe. I po co mi taki WAF? Tak na to można powiedzieć. Wtedy, kiedy chcę się ochronić przed atakami typu cross-site scripting, directory traversal, SQL Injection i tak dalej, i tak dalej. Całą listę tych ataków publikuje taki fajny projekt, który się nazywa OWASP. I ten OWASP ma nawet listę top ten, czyli w ostatnim roku które zagrożenia webowe były najbardziej popularne. Można sobie to przejrzeć, przeczytać i się nad tym dobrze zastanowić. Czyli ten WAF to jest z kolei ochrona trochę podobna IPS-owi, ale dedykowanemu dla weba przy ruchu przychodzącym. IPS oczywiście jest szerszy, bo IPS oprócz tego weba zadziała też dla baz danych, zadziała dla ataków związanych ze skanowaniem i tak dalej, i tak dalej, a WAF niekoniecznie. Natomiast co ten WAF może zrobić jeszcze? Oczywiście może zrobić taką funkcję, że jest on też serwerem pewnego rodzaju proxy, natomiast tym razem reverse proxy. On po prostu może dla nas odbierać, terminować ruch od klientów i na przykład rozrzucać go na różne serwery wewnętrzne. Czyli będzie tak naprawdę load-balansował. Może robić SSL ofloading, czyli ściągać szyfrowanie SSL-owe na poziomie reverse proxy. To też nie jest bez znaczenia bo może też ściągać jakby obciążenie z naszych serwerów. Tu dosłownie w dwóch słowach takie najpopularniejsze ataki, przed którymi ten WAF nas ochroni, czyli cross-site scripting. I cross-site scripting polega ni mniej ni więcej, jeżeli mamy błędnie zaprojektowaną i wykonaną stronę webową, która pozwala [błąd dźwięku, niezrozumiałe]. Kiedyś były modne takie fora internetowe, które, powiedzmy sobie, pozwalały użytkownikowi coś tam wpisać. I dopóki naród wszem i wobec, w postaci programistów, nie doszedł do tego, że jednak trzeba by było sprawdzać, co ten użytkownik tam wpisuje, to niektórzy pisali znacznik scirpt, domykali ten script. To co między, to już pozwalało im, jeżeli mieli jakąś znajomość programistyczną, wprowadzić tam w zasadzie wszystko, czyli teraz jak ktoś odwiedzał tę stronę, to automatycznie odpalał mu się skrypt, którego wcale nie zaszył tam administrator tej strony. No słabe, czyli pozwalało zrobić całkiem sporo. Oczywiście dzięki OWASP-owi już znakomita większość z tych stron, która miała taką podatność, jest wyeliminowana i absolutnie nie funkcjonuje. Natomiast jeżeli nie ufamy naszym deweloperom, postawmy sobie WAF, a on za was takie problemy rozwiąże. SQL Injection, czyli drugi rodzaj ataku – znowuż jeżeli czegoś wyszukujemy, czyli z bazy danych jakiegoś produktu i chcemy ten produkt sobie z tej bazy danych wyciągnąć, to jeżeli nie zrobimy walidacji tego, co wprowadza nasz użytkownik, to on może na przykład zadać nam takie zapytanie, które zamiast produktu 999 spróbuje zrobić wyrażenie regularne, które zawsze jest true i tym samym wyciągnie na przykład wszystkie produkty. Może też zakończyć na przykład zapytanie średniczkiem, dalej sobie cokolwiek wpisać. Jeżeli nie mamy zabezpieczonej naszej bazy SQL-owej, może nawet usunąć rekordy z naszej bazy chociażby. Czyli konkluzja: WAF traci, jak mamy ważne serwery i do końca nie wierzymy naszym programistom, chociaż nawet jak im wierzymy, to lepiej takiego WAF-a postawić, bo on za nas troszeczkę zrobi dobrej roboty. Oczywiście może również rozrzucać ruch, czyli load-balansować, zrobić ofloading SSL-a. Całkiem fajne rzeczy, jeżeli mamy dużo ruchu przychodzącego od klientów z internetu do naszego serwera webowego. I ciekawy temat, który bardzo często jest pomijany, czyli ochrona DNS-a. Trzeba powiedzieć, że DNS, czyli Domain Name System nie był projektowany z myślą o bezpieczeństwie. Jest to tekstowy w zasadzie sposób do zmiany czegoś, co użytkownikowi human being, czyli człowiekowi jest bliskie, czyli nazwy na adres IP, który bliski mu nie jest. Jeszcze w warstwie IPv4 on może być bliski komuś, kto siedzi w tej branży, ale w modelu IPv6 na pewno bliski już prędko nie będzie. Zatem zamiana nazwy na adres IP odbywa się w taki sposób, jak tu jest pokazane na rysuneczku, czyli ktoś pyta nam o stronę www.cisco.com. Nasz resolwer rekursywny pyta kolejne serwery, w zasadzie zaczynając od rootowego, czyli tego, który odpowiada za… Jest jakby górą drzewa DNS-owego, odpowiada za kierowanie dalej. On mówi, że domena .com znajduje się na takim serwerze. To on grzecznie pyta tego, który odpowiada za domenę .com, gdzie znajduje się www.cisco.com. Mówi nam: cisco to jest taki serwer. I na tym ostatnim serwerze w rezultacie znajduje prawdopodobnie odpowiedź na temat DNS-a. A co się stanie, jeżeli gdzieś ktoś będzie nas próbował oszukać? A możliwości oszukania jest całkiem sporo. Serwery te gdzieś tam pośrodku, czyli gdzieś w naszych na przykład ISP jeszcze jakiś czas temu jeszcze były nieodporne na cache poisoning. Czyli ktoś mógł sam zapytać o adres lub samemu podesłać adres, który był adresem błędnym. Serwery cache’owały go i odpowiadały wszystkim innym błędnie na takie zapytania. To zostało wyeliminowane w 2008 roku. Natomiast cały czas tu mówimy o komunikacji nieszyfrowanej. Jeżeli ktoś w jakiś sposób przechwyci nasz ruch, to może na przykład próbować podszyć się pod DNS-a, czyli odesłać odpowiedź, która będzie zupełnie błędna. I to spowoduje, że my wylądujemy na innej stronie niż byśmy tak naprawdę chcieli. A co to znaczy, jak my wylądujemy na tej innej stronie? Wtedy może to być strona, która na przykład udaje stronę naszego banku. Oczywiście do tego dochodzą certyfikaty, SSL-e, możemy to sprawdzić. Ale co, jeżeli tego nie sprawdzimy? Albo jeżeli ktoś to zrobił bardzo sprytnie i w nazwie zmienił tylko jedną literkę, która wygląda bardzo, bardzo podobnie i wszystko się zgadza, bo certyfikat też jest odpowiedni dla tejże jednej literki. Mamy ataki typu Denial of Service. Mamy ataki, w zasadzie nie ataki, tylko kwestie związane z prywatnością, związane z tym, że każdy może sobie obejrzeć to, co my wysyłamy w naszych zapytaniach DNS-owych. No właśnie, czyli mamy możliwość dokładnego spoofowania. Ktoś może, czy to lokalnie, za pomocą ataków na warstwę drugą, nam podesłać, czy też na nasz router. Nasze routerki też często są niezbyt zabezpieczone. Mamy w przypadku public resolverów cache poisoning. I mamy tu wszędzie na tym etapie widoczność, czyli można zbierać informacje o naszych zapytaniach DNS. No i te tematy ochrony DNS-owej adresują protokoły DNSSEC, DNS over TLS, DNS over HTTPS. Który wybrać, który jest najlepszy?

One są w zasadzie do czego innego, bo DNS over TLS i DNS over HTTPS to są protokły, które chronią tę ostatnią linę, czyli nasze zapytanie do pierwszego naszego serwera DNS-owego. Czyli powiedzmy sobie gdzieś do serwera, który jest sobie, nie wiem, w ISP albo jest naszym serwerem DNS-owym, w naszych zasobach. Czyli warto DNS over TLS bądź też DNS over HTTPS zaimplementować. Chyba wygląda, że będzie warto zaimplementować DNS over HTTPS, ale o tym za moment. I DNSSEC. Ten DNSSEC jest ciekawym rozwiązaniem, bo on również na podstawie kryptografii, czyli PKI, pozwala nam powiedzieć, kto może udzielić zapytania na temat konkretnej domeny. Czyli podpis PKI również jest jakby zawarty w odpowiedzi, co powoduje, że nie może nikt, kto podszywa się pod konkretną domenę, wysłać nam odpowiedzi, która będzie autorytatywna. Czyli odpowiedź jest integralna i pewna, poświadczona, że dotyczy tejże domeny, DNSSEC jest czymś, co bardziej powinni implementować użytkownicy czy właściwie administratorzy serwerów DNS-owych. Natomiast my w ramach naszej infrastruktury powinniśmy zaimplementować

czy to DNS over TLS. Jest to normalne mechanizm TLS-owy, który szyfruje nam komunikację DNS-ową. Czyli jesteśmy pewni wszystkiego: prywatności, integralności i poświadczenia, że komunikujemy się z odpowiednim serwerem. Natomiast adopcja na przykład na serwerach to stan z 2020, chyba nadal utrzymany. Na komputerach z systemem Windows nie jest ten produkt jeszcze cały czas dostępny. I DNS over HTTPS, czyli przesyłamy po prostu 443. Tak naprawdę generalnie zajmuje się tym przeglądarka. Czyli wypadałoby i fajnie przyjrzeć się ochronie DNS-owej w zakresie komunikacji.

I to tyle. Dzisiaj chciałem powiedzieć o takim zróżnicowanym temacie ochrony dedykowanej konkretnym aplikacjom.

Dziękuję. Do zobaczenia w kolejnych odcinkach.