Dobry pomysł? Odmawiać przychodzących wiadomości e-mail z zakończeniem naszej własnej domeny? (ponieważ muszą być fałszywe)

33

Mam pytanie dotyczące naszego serwera Exchange: Czy uważasz, że dobrym pomysłem jest odrzucanie przychodzących zewnętrznych wiadomości e-mail, które mają naszą domenę na końcu?

Jak zewnętrzna wiadomość e-mail od [email protected]?

Ponieważ gdyby to był prawdziwy nadawca w naszej firmie, e-mail nigdy nie pochodziłby z zewnątrz?

Jeśli tak, jaki jest najlepszy sposób?

Steffen Maier
źródło
3
Czy masz obecnie jakieś rozwiązanie do filtrowania spamu?
ewwhite
14
Powinieneś dokładnie sprawdzić, czy nie masz żadnych dostawców aplikacji internetowych próbujących wysłać ze swojej domeny. Na przykład, jeśli masz system płac, który może wysyłać wiadomości e-mail do pracowników z „[email protected]”. Sprawdź także, czy dział marketingu lub HR może skorzystać z zewnętrznej usługi masowej poczty i czy pracownicy chcą otrzymywać te wiadomości. Zazwyczaj wiadomości te mają nadawcę lub przynajmniej adres zwrotny osoby w dziale marketingu lub HR. W takich sytuacjach zazwyczaj będziesz mógł umieścić serwery poczty e-mail w usłudze na liście dozwolonych i nadal blokować własne domeny przychodzące (to właśnie robimy).
Todd Wilcox,
6
@NeilMcGuigan Co by to miało znaczenie? Poczta powinna nadal pochodzić z wewnętrznego serwera pocztowego? Nie przyszedłby spoza sieci tylko dlatego, że nie jest fizycznie obecny.
Matt
@Matt Gotya, brainfart
Neil McGuigan,
1
Jeśli masz zautomatyzowane powiadomienia e-mail pochodzące z jednego z serwerów, na przykład nieudane powiadomienia o zadaniach cron lub próbę naruszenia IDS lub monitorowania zużycia zasobów i są one skonfigurowane tak, aby ich adres nadawcy był zgodny z nazwą Twojej domeny. Musisz zadbać o to, aby trasować te wiadomości e-mail przez wewnętrzny serwer pocztowy lub umieszczać te serwery na białej liście jako dozwolonych nadawców.
Lie Ryan

Odpowiedzi:

53

Tak, jeśli wiesz, że e-mail dla Twojej domeny powinien pochodzić tylko z twojego własnego serwera, powinieneś zablokować każdy e-mail dla tej domeny pochodzący z innego serwera. Nawet jeśli klient poczty e-mail nadawcy znajduje się na innym hoście, powinien logować się na serwerze (lub dowolnym innym serwerze e-mailowym), aby wysłać wiadomość e-mail.

Idąc o krok dalej, możesz skonfigurować serwer, aby sprawdzał rekordy SPF. Tak wielu hostów zapobiega tego rodzaju aktywności e-mail. Rekordy SPF to rekord DNS, rekord TXT, który określa reguły dotyczące serwerów, które mogą wysyłać wiadomości e-mail dla Twojej domeny. Jak włączyć sprawdzanie rekordów SPF, będzie zależeć od twojej usługi e-mail i wykracza poza zakres tego, co tu znajdziesz. Na szczęście większość środowisk hostingowych i oprogramowania będzie miała dokumentację do pracy z rekordami SPF. Możesz ogólnie dowiedzieć się więcej o SPF. Oto artykuł w Wikipedii: https://en.wikipedia.org/wiki/Sender_Policy_Framework

DKing
źródło
3
@Kurtovic dobrze skonfigurowany serwer e-mail powinien odesłać odrzucony e-mail, aby nadawca został powiadomiony.
Calimo,
8
@ Calimo Nie, gdy odrzuca wiadomość e-mail za spam. Takie postępowanie pozwoliłoby spamerowi kontynuować próbę, dopóki nie dowie się, na co pozwala Twój algorytm, a czego nie.
Jon Bentley,
27
@Calimo - nie. Akceptuj i odbijaj jest najgorszą możliwą rzeczą, przyczyniasz się do rozprzestrzeniania spamu i bardzo szybko zostaniesz na czarnej liście. po prostu odrzuć niechcianą pocztę - radzenie sobie z tym jest problemem hosta wysyłającego . Jeśli nie możesz tego zrobić, zaakceptuj, sprawdź i odrzuć spam lub złośliwe oprogramowanie. nigdy nie akceptuj i nie odbijaj się.
cas
2
@cas: Istnieje trzecia alternatywa: odrzucić w czasie akceptacji SMTP. Pozostawia to obowiązek wygenerowania odpowiedzi na błąd na wysyłającym serwerze SMTP, jeśli chce to zrobić, a tym samym pozwala wielu legalnym nadawcom sprawdzić, czy ich poczta została odrzucona, gwarantując, że sam nigdy nie wytworzysz spamu.
R ..
2
@R .. myślę, że przekonasz się, że to nie jest trzecia alternatywa, to parafraza tego, co powiedziałem „po prostu odrzuć niechcianą pocztę - radzenie sobie z tym jest problemem hosta wysyłającego”.
cas
31

Jest to już standard. To się nazywa DMARC . Wdrażasz go przy użyciu podpisu DKIM (co i tak jest dobrym pomysłem).

Przegląd ogólny polega na tym, że podpisujesz każdy e-mail opuszczający domenę nagłówkiem DKIM (co jest dobrą praktyką). Następnie konfigurujesz DMARC, aby odrzucał każdy e-mail, który trafia na twój serwer pocztowy, z domeny, którą posiadasz, która nie jest podpisana prawidłowym nagłówkiem DKIM.

Oznacza to, że nadal możesz mieć zewnętrzne usługi dostarczające pocztę e-mail do Twojej domeny (takie jak hostowane oprogramowanie pomocy technicznej itp.), Ale może blokować próby phishingu typu spear.

Inną wspaniałą rzeczą w DMARC jest to, że otrzymujesz raporty awarii, dzięki czemu możesz zarządzać obsługą wyjątków zgodnie z wymaganiami.

Wadą jest to, że musisz upewnić się, że wszystko zostało wcześniej dokładnie uporządkowane, w przeciwnym razie możesz zacząć upuszczać prawidłowe wiadomości e-mail.

Mark Henderson
źródło
3
Zdecydowanie zaleca się wdrożenie SPF oraz DKIM przed testowaniem DMARC.
Todd Wilcox
W jaki sposób DMARC może współpracować z wiadomościami e-mail pochodzącymi z innego serwera niż Twój, na przykład z usługami zewnętrznymi, skoro nie byłyby podpisywane przez Twój serwer?
jpaugh
1
@ jpaugh dodajesz klucz publiczny innych serwerów do swoich rekordów DMARC w swoim DNS. Będą mogli dać ci rekord do dodania.
Mark Henderson
Dałem +1 tej odpowiedzi, ponieważ jest technicznie poprawna - do tego właśnie służy DMARC i do czego służy - ale DMARC jest bardzo złym pomysłem, jeśli chcesz współpracować z takimi rzeczami, jak listy mailingowe, ponieważ narusza RFC i ogólnie źle się zachowują.
MadHatter obsługuje Monikę
11

Taki blok najprawdopodobniej zmniejszy spam i może utrudnić socjotechnikę, ale może również blokować legalną pocztę. Przykłady obejmują usługi przekazywania poczty, listy mailingowe, użytkowników ze źle skonfigurowanymi klientami pocztowymi, aplikacje internetowe, które wysyłają pocztę bezpośrednio z hosta bez angażowania głównego serwera pocztowego i tak dalej.

Dkim może w pewnym stopniu temu zaradzić, umożliwiając identyfikację wiadomości wysłanej z Twojej sieci, zapętlonej przez listę mailingową lub spedytora, a następnie otrzymanej na twoją pocztę, ale nie jest to idealne lekarstwo, niektóre listy mailingowe złamią podpisy dkim nadal masz problem ze śledzeniem wszystkich wiarygodnych punktów początkowych poczty i upewnianiem się, że przechodzą one przez osobę podpisującą dkim.

Stąpaj ostrożnie, zwłaszcza jeśli implementujesz to w istniejącej domenie.

Peter Green
źródło
3

Być może, ale są pewne przypadki, które należy rozważyć przed dokonaniem takiej zmiany.

1) Czy ktoś w Twojej firmie korzysta z jakiejkolwiek usługi zewnętrznej (na przykład Survey Monkey, Constant Contact itp.), Aby wysyłać wiadomości e-mail, które wydają się być „z” Twojej domeny? Nawet jeśli nie robią tego dzisiaj, czy mogliby to zrobić w przyszłości?

2) Czy są jakieś adresy zewnętrzne, które przekazują użytkownikom? Załóżmy na przykład, że konto gmail „[email protected]” przesyła dalej do „sprzedaż@mojafirma.com”, a użytkownik „[email protected]” wysyła na adres „[email protected]”. W takim przypadku wiadomość nadejdzie z „z zewnątrz”, ale z adresem „@ mojafirma.com” z adresu:.

3) Czy któryś z Twoich użytkowników subskrybuje zewnętrzne listy dystrybucyjne, które zachowują oryginalny adres „Od:” w wiadomościach na listę? Na przykład, jeśli Bob zasubskrybuje „[email protected]” i wyśle ​​wiadomość, otrzyma wiadomość przychodzącą wyglądającą mniej więcej tak: Od: [email protected] Do: [email protected]. com Nadawca:

Jeśli Twój serwer naiwnie patrzy na nagłówek „From:” (zamiast „Sender:”), może odrzucić tę wiadomość, ponieważ odbierasz ją z zewnątrz.

Ze względu na wszystkie powyższe, posiadanie ogólnej zasady „... od prawdziwego nadawcy w naszej firmie, e-mail nigdy nie nadejdzie z zewnątrz” nie zawsze jest wykonalne.

David Gelhar
źródło
2

Możesz to zrobić w PowerShell, aktualizując swoje uprawnienia do odbierania oprogramowania sprzęgającego, aby wykluczyć anonimowych użytkowników z wysyłania jako autorytatywnego nadawcy domeny:

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

Problem pojawia się jednak, gdy masz zdalne serwery aplikacji, które muszą wysyłać do Ciebie wiadomości e-mail o statusie, ponieważ zazwyczaj używają nazwy domeny pod adresem Od. Możliwe jest utworzenie dodatkowego złącza odbierającego dla ich określonych adresów IP, abyś ich nieumyślnie wykluczył.

Neil
źródło
1

GMail ma ustawienie, w którym pozwala wysyłać wiadomości e-mail z domeną inną niż GMail, pod warunkiem, że adres e-mail zostanie zweryfikowany jako pierwszy. Twoja decyzja zablokuje te e-maile.

To, czy masz użytkowników, którzy mogliby skorzystać z tej funkcji Gmaila, i czy warto się nimi zająć, zależy w dużej mierze od zachowania w Twojej firmie.

chrześcijanin
źródło
-1

SPF nie wyleczy tego, ponieważ koperta może mieć odpowiednie hasło SPF (tj. Spamerzy używający zainfekowanego serwera), podczas gdy sfałszują wiadomość e-mail wewnątrz koperty. Potrzebujesz bloku wiadomości e-mail z własnej domeny, który ma serwer pocztowy pochodzący z koperty, którego nie możesz zaakceptować.

Jim
źródło
„Potrzebny jest blok wiadomości e-mail z własnej domeny, na której nie ma akceptowalnego serwera pocztowego na kopercie” - dokładnie to robisz z SPF, stwórz listę legalnych serwerów pocztowych dla swojej domeny.
GAThrawn