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 fake@example.com?

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?

security email-server exchange-2013

— 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 „payroll@example.com”. 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

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 „mojafirma.sales@gmail.com” przesyła dalej do „sprzedaż@mojafirma.com”, a użytkownik „bob@mojafirma.com” wysyła na adres „mojafirma.sales@gmail.com”. 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 „foo-list@lists.apple.com” i wyśle wiadomość, otrzyma wiadomość przychodzącą wyglądającą mniej więcej tak: Od: bob@mycompany.com Do: foo-list@lists.apple. 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