I. Wstęp
Pierwszy na świecie e-mail został wysłany w 1971 roku. Jak dostarcza EarthWeb -- w dzisiejszych czasach, codziennie ludzie wysyłają do siebie około 333.2 miliarda e-maili. W skali światowej daje to 3,5 miliona e-maili na sekundę. Przez te 51 lat poczta elektroniczna przeszła naprawdę wiele zmian, reform i przekształceń.
Czy istnieje możliwość potwierdzenia, że e-mail, który otrzymaliśmy, nie został sfałszowany oraz że jego prawdziwy nadawca jest tym, za kogo się podaje?
O tym w dzisiejszym poradniku!
II. Zasady działania poczty
Wykorzystując protokół SMTP (Simple Mail Transfer Protocol), możemy zarówno wysyłać, jak i odbierać elektroniczną pocztę. Jak to jednak wygląda pod spodem?
Załóżmy, że mamy dwóch użytkowników i dwa serwery pocztowe.
- Damian, który korzysta z serwera mail1.local
- Asię, która korzysta z serwera mail2.local
Jeżeli Damian chce wysłać do Asi wiadomość o następującej treści:
- Co robi żartowniś przy studni? - Nabiera wodę.
- Otwiera swojego klienta pocztowego (załóżmy, że to Thunderbird)
- Klient pocztowy otwiera połączenie TCP do serwera, z którego korzysta Damian.
- Połączenie TCP charakteryzuje się 3-way-handshakiem, więc połączenie jest zestawiane i na tym etapie możliwe jest wykonanie uwierzytelnienia użytkownika.
- Damian uwierzytelnia się swoimi poświadczeniami do swojego serwera (login: damian@mail1.local, hasło: damian)
- Damian pisze swoją wybitną wiadomość w polu tekstowym, wpisuje adres e-mail Asi i klika "Wyślij".
- Pod spodem klient Damian wysyła do serwera Damiana komendę
MAIL FROMwraz z adresem swojej skrzynki pocztowej. - Serwer Damiana sprawdza, czy taki e-mail istnieje. Jeżeli tak to zwraca odpowiedź
250 OK. - Następnie klient wysyła do serwera komendę
RCPT TOwraz z adresem odbiorcy. W tym wypadku jest to asia@mail2.local - Klient Damiana wysyła komendę
DATA, wraz z treścią wiadomości, a potem komendęQUITi kończy połączenie.
Co teraz robią serwery e-mailowe?
- Serwer Damiana otwiera połączenie TCP do serwera Asi (mail2.local).
- Przechodzi przez 3-way-handshake, żeby zestawić połączenie.
- Używa komendy
EHLOdo inicjowania połączenia. - Za pomocą protokołu SMTP, przesyła w postaci komend nadawcę (
MAIL FROM), treść wiadomości (DATA), adresata (RCPT TO) (i wiele więcej). - Zamyka połączenie przy użyciu komendy
QUIT. - Serwer Asi odbiera dane i wrzuca je do skrzynki adresata (Asi).
Jeżeli wszystko pójdzie zgodnie z planem -- wiadomość zostanie doręczona.
III. Co może pójść nie tak?
Zgodnie z klasycznymi Prawami Murphy'ego:
Jeśli coś może pójść źle, to pójdzie. (ang. Anything that can go wrong will go wrong.)
A więc, co może pójść nie tak?
Otóż można ze swojego komputera (lub nieswojego) ręcznie zestawić połączenie TCP z serwerem e-mailowym Asi (mail2.local), wysłać komendy wysyłane przy połączeniu serwer-serwer i Asia w ten sposób otrzyma wiadomość tak, jakby została wysłana z faktycznego serwera e-mail.
IV. Rekord SPF (Sender Policy Framework)
Duże mózgi wymyśliły, że ten typ ataku można ograniczać za pomocą rekordów DNS. W jaki sposób to miałoby działać?
Damian dodaje sobie do DNS nowy rekord TXT: _spf.mail1.local wraz z wartością v=spf1 ip4:1.2.3.4, gdzie 1.2.3.4 to adres serwera Damiana.
Serwer Asi otrzymując wiadomość, sprawdza rekordy TXT serwera, który został podany przy połączeniu. Szuka rekordu SPF, w którym zawarte są adresy IP upoważnione do wysyłki e-maili z danej domeny.
- Adres IP osoby, która samodzielnie otwiera połączenie do serwera -- nie znajduje się na tej liście -- dlatego wiadomość zostaje odrzucona.
- Adres IP serwera Damiana znajduje się na tej liście, dlatego wiadomość zostaje zaakceptowana przez serwer Asi.
V. Protokół DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) to kolejny protokół, który daje właścicielowi możliwość chronienia domeny poprzez włączenie weryfikacji autentyczności wiadomości (np. wyżej wspomniane SPF) oraz przede wszystkim umożliwia monitoring (w postaci raportów e-mail) nadużyć domeny do niecnych celów (spoofing wysyłany z jego domeny).
Aby zastosować to, Damian tworzy rekord TXT w swojej domenie mail1.local:
_dmarc.mail1.local o wartości v=DMARC1; p=none; rua=mailto:damian@mail1.local; adkim=s; aspf=s;
Od teraz SPF jest wymuszane niezależnie, czy Asia tego chce, czy nie, rekord musi zostać sprawdzony.
VI. Nie wysyłam, ani nie odbieram e-maili ze swojej domeny. Po cholerę mi to?
Pomimo tego, że nie używasz swojej domeny do e-maili -- nadal można nadużyć ją poprzez spoofing.
Przykład #1: Prowadzisz małą, jednoosobową firmę. Masz swoją witrynę internetową, ale do kontaktu z klientami korzystasz z popularnej usługi pocztowej oferowanej przez gigantyczny koncern technologiczny, którego nazwa zaczyna się na literę "G". W wypadku, gdy z Twojej firmowej domeny ktoś rozpocznie spoofing e-maili, broń Boże akurat do Twoich adresatów -- możesz mieć spore kłopoty. Nie tylko wizerunkowe, ale też prawne, w zależności, będzie akurat spoofowane.
Przykład #2: Masz domenę, nie wysyłasz e-maili. Ktoś zauważył, że nie masz zabezpieczonej domeny, dlatego rozpoczyna kampanię phishingową z Twojej domeny. Domena automatycznie leci do spam-list utrudniając, wręcz uniemożliwiając Ci w przyszłości postawienie tam serwera e-mailowego.
VII. Nie umiem w DNS, jak to zrobić?
Istnieją gotowe generatory reguł SPF i DMARC ;)
https://www.google.com/search?q=spf+txt+generator https://www.google.com/search?q=dmarc+txt+generator
VII. Podsumowanie
Mam nadzieję, że jeżeli dotychczas nie stosowałeś/aś SPF i DMARC -- powyższy tekst zmieni Twoje spojrzenie na tę część technologii e-mail.
Tekst ma wiele uogólnień, ale mam nadzieję, że to nie przeszkadza w przekazaniu merytorycznej części poradnika. Jeżeli znalazłeś w poradniku jakiś błąd, literówkę lub nie zgadzasz się co do treści -- poproszę o komentarz :)
Tyle ode mnie, bajo ❤️
