🚀 go-pugleaf

W dniu 2020-04-01 o 08:55, LFC pisze:
> Serwer w mojej firmie służył do poczty korporacyjnej, więc działał sobie na porcie 25 i jako tako to funkcjonowało.
> Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby mógł odbierać i wysyłać również pocztę w domu.
> Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie była możliwa ponieważ niektórzy ISP blokują port 25, a sieci dynamicznego IP są w dnsbl.
> W związku z tym aktywowałem sendmailowi port 587
I dobrze, wysyłanie przez MSA z obligatoryjnym szyfrowaniem i uwierzytelnieniem to w zasadzie jedyne sensowne rozwiązanie.

> i dodałem opcję `delay_checks', `friend', a do access dopisałem:
> Spam:adres1@domena.com.pl
> ...
> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla demona przy obu portach to i tak zaczęły mi włazić hosty ipv6. 
A potrzebujesz wogóle dostępu do usług po IPv6?
Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy wyłączyć?

> Zablokowałem INPUT dla ipv6,
Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?

> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to ukrócić?
> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
> Jakies sugestie?
>
Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w konfiguracji tego nie umożliwisz!
relay_based_on_MX to właśnie taka furtka.


O ile kojarzę, to masz już milter-regex?
Żeby zabezpieczyć swój serwer, spróbuj:

ME = ( helo /^10\.10\.10\.10$/ or helo /^localhost$/ or helo /^poczta\.example\.com$/ or helo /^mail\.example\.com$/ )
REALLY_ME = ( connect /localhost/ /127\.0\.0\.1/ or connect /^poczta\.example\.com$/ /10\.10\.\10\.10/ )
discard
$ME and not $REALLY_ME

Zastosowane w przykładzie dane serwera SMTP:
poczta.example.com to podstawowa, a mail.example.com to dodatkowa nazwa FQDN serwera - jeżeli jest skonfigurowana
10.10.10.10 to adres IP ustawiony w rekordzie A dla poczta.example.com (zwykle adres publiczny serwera SMTP)
Ustaw to na początku konfiga, zaraz po wyjątkach na zaufane lub uwierzytelnione hosty.

Żeby umożliwić weryfikację dla innych serwerów przeczytaj
https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam
i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie) oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail

> LFC
>

W dniu 2020-04-02 o 01:31, Piotr Lechowicz pisze:

>> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla 
>> demona przy obu portach to i tak zaczęły mi włazić hosty ipv6. 
> A potrzebujesz wogóle dostępu do usług po IPv6?
> Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy 
> wyłączyć?

I to mnie właśnie zdziwiło,bo mam zdisablowane ipv6.
>> Zablokowałem INPUT dla ipv6,
> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera 
> do serwera SMTP?

Po blokadzie ip6tables problem ustał, ale i tak jestem zdumiony, bo 
sendmail był ustawiony w konfigu dla Family=inet, a więc ipv4, a mimo to 
z opcją delay_checks przyjmował również ipv6.

> 
>> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy 
>> przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to 
>> ukrócić?
>> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który 
>> sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
>> Jakies sugestie?
>>
> Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w 
> konfiguracji tego nie umożliwisz!


Cyrk się zaczął dziać, jak ustawiłem sendmailowi w konfigu opcję 
`delay_checks', która jeżeli dobrze zrozumiałem ma opóźniać testy 
sendmaila do momentu autoryzacji, po poprawnej autoryzacji usera nie 
powinny być robione. Efekt był taki, że nie dośc, że pakowały się hosty 
po ipv6, to jeszcze różne ruskie i ukraińskie spam serwery przedstawiały 
się jako moja domena i pakowały spam rzekomo od usera@domena.com.pl i to 
fikcyjnego usera na adresy ze świata.

Potrzebowałem tego żeby umożliwić faktycznym userom z naszej domeny 
wysyłanie poczty ze swoich domowych internetów, bo bez tego sendmail z 
pomocą rbl spamhausa pokazywał im fucka DSN 550 5.7.1 relaying denied

Musi być jakiś sposób, skoro serwery publiczne jakoś funkcjonują
> 
> Żeby umożliwić weryfikację dla innych serwerów przeczytaj
> https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam 
> 
> i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie) 
> oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Mail
> 

poczytam,, bo słabo to wygląda, a nie mogę znaleźć rozwiązania. Móglbym 
wyłączyć sprawdzanie w dnsbl, ale po tym, co widzę w logu byłby to 
strzał samobójczy, bo na jeden użyteczny link przypada mniej więcej 3, 4 
albo więcej spamhaus.

Wytrułem wczoraj błąd w konfiguracji, zła ścieżka do pliku key przez co 
certyfikat sendmaila nie byl używny. Do tej pory nie miało to większego 
znaczenia, bo w obrębie firmy poczta działała po porcie 25 z autoryzacją 
bez szyfrowania otwartym tekstem. Przez to musiałem dziś pojechać do 
firmy i poustawiać userom starttls w autoryzacji serwera poczty 
wychodzącej, ale nie zmieniło to nic w relayingu z adresów domowych 
(dynamicznych), dalej DSN 550 na każdym porcie  - 25, 465, 587
Aż się boję spróbować ponownie delay_checks gdy serwer używa starttls.

LFC

W dniu 2020-04-02 o 01:31, Piotr Lechowicz pisze:
> W dniu 2020-04-01 o 08:55, LFC pisze:
>> Serwer w mojej firmie służył do poczty korporacyjnej, więc działał 
>> sobie na porcie 25 i jako tako to funkcjonowało.
>> Teraz w związku z akcją "siedź w domu" zarząd sobie zażyczył, żeby 
>> mógł odbierać i wysyłać również pocztę w domu.
>> Z odbiorem nie ma problemu bo port 995, natomiast wysyłka na ogół nie 
>> była możliwa ponieważ niektórzy ISP blokują port 25, a sieci 
>> dynamicznego IP są w dnsbl.
>> W związku z tym aktywowałem sendmailowi port 587
> I dobrze, wysyłanie przez MSA z obligatoryjnym szyfrowaniem i 
> uwierzytelnieniem to w zasadzie jedyne sensowne rozwiązanie.
> 
>> i dodałem opcję `delay_checks', `friend', a do access dopisałem:
>> Spam:adres1@domena.com.pl
>> ...
>> I działa, ale widzę, że choć w sendmail.mc dałem Family=inet dla 
>> demona przy obu portach to i tak zaczęły mi włazić hosty ipv6. 
> A potrzebujesz wogóle dostępu do usług po IPv6?
> Na interfejsie publicznym serwera masz włączone IPv6? Może wystarczy 
> wyłączyć?
> 
>> Zablokowałem INPUT dla ipv6,
> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera 
> do serwera SMTP?
> 
>> ale widzę w mquee i w logach jakieś hosty ze świata np z Ukrainy 
>> przedstawiają się jako nasza domena i pakuja spam aż miło. Jak to 
>> ukrócić?
>> Myślałem o opcji rela based_on_MX, ale wtedy każdy cwaniak, który 
>> sobie wpisze w domenę nasz serwer jako MX bedzie mógł relayowac do woli.
>> Jakies sugestie?
>>
> Żaden cwaniak nie ma szans "relayować" przez twój serwer, o ile mu w 
> konfiguracji tego nie umożliwisz!
> relay_based_on_MX to właśnie taka furtka.
> 
> 
> O ile kojarzę, to masz już milter-regex?
> Żeby zabezpieczyć swój serwer, spróbuj:
> 
> ME = ( helo /^10\.10\.10\.10$/ or helo /^localhost$/ or helo 
> /^poczta\.example\.com$/ or helo /^mail\.example\.com$/ )
> REALLY_ME = ( connect /localhost/ /127\.0\.0\.1/ or connect 
> /^poczta\.example\.com$/ /10\.10\.\10\.10/ )
> discard
> $ME and not $REALLY_ME
> 
> Zastosowane w przykładzie dane serwera SMTP:
> poczta.example.com to podstawowa, a mail.example.com to dodatkowa nazwa 
> FQDN serwera - jeżeli jest skonfigurowana
> 10.10.10.10 to adres IP ustawiony w rekordzie A dla poczta.example.com 
> (zwykle adres publiczny serwera SMTP)
> Ustaw to na początku konfiga, zaraz po wyjątkach na zaufane lub 
> uwierzytelnione hosty.
> 
> Żeby umożliwić weryfikację dla innych serwerów przeczytaj
> https://serverfault.com/questions/415533/how-to-stop-people-from-using-my-domain-to-send-spam 
> 
> i zainteresuj się tematem SPF http://www.openspf.org/ (chociaż pasywnie) 
> oraz DKIM https://pl.wikipedia.org/wiki/DomainKeys_Identified_Maildo
> 

Zapis SPF mam wprowadzony do strefy DNS, ale w róznych artykułach zdania 
były podzielone. jedni doradzali inni odradzali

Zapis jest taki
@ IN TXT "v=spf1 a ip4:IP_mojego_serwera -all"

W opisie spf dla centosa znalazłem:

@ IN TXT "v=spf1 a mx ip4:IP_mojego_serwera -all"

Nie mam doświadczenia w SPF i wlazłem na stronę generatora rekordów SPF, 
który uznał że zapis jest OK, ale po dodaniu informacji, o tym, że maile 
sa wysyłane z tego serwera który jest w zapisie mx domeny zasugerował 
ten drugi zapis.
Tyle, że mam 2 widoki w dns zewnetrzny i wewnętrzny W wewnętrznym mam 
tak samo, tylko 3 zapisy ip4 - dla dwóch sieci 192.168.2.0/24, 
192.168.0.0/24 i serwera 192.168.0.1.
zatem sa pytania:
- Czy zmieniać w obu widokach?
- Czy spowoduje to jakieś zmiany w sieci wewnętrznej(nie chciałbym, bo 
mam dośc po starttls - na ogól poszło gładko, ale znalazło się parę 
przypadków, gdzie nie odpaliło się okno zatwierdzenia wyjątku 
certyfikatu samopodpisanego sendmaila, albo okazało się, że hasło, które 
pamięta user nie chce jakoś być akceptowane)?
- Czy będzie to mialo znaczenie dla wysyłki poczty z domowych internetów 
po porcie 587, albo 465?

W opisie twierdzą, że oprócz tego zapisu w strefie dns nie trzeba nic 
więcej konfigurować. Byłoby miło.

LFC

W dniu 2020-04-03 o 16:32, LFC pisze:

>>
>>> Zablokowałem INPUT dla ipv6,
>> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera 
>> do serwera SMTP?
>>
Nie zrozumieliśmy się.
W sysctl.conf od dawna mam wpisane:

net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1

Chyba, że nie zrozumiałem zasady, ale 1 oznacza enabled, czyli jak dla 
mnie reguła ma być aktywna, czyli wyłączyć ipv6.

Gdyby to oznaczało jednak, że jest włączone to tłumaczyło by czemu 
właziły hosty po ipv6, ale i tak mi to skrzeczy, ponieważ 
skonfigurowałem w sendmail.mc demony dla Family=inet, wiec nie powinny
słuchać po ipv6.
Dopiero REJECT na INPUCIE w ip6tables zatrzymał ten proceder.

Oprócz tego pakowały się hosty po ipv4 przedstawiając się jako domena. 
Wszystko to się działo z opcją (`delay_checks', `friend') w sendmail.mc
która jak zrozumiałem miała wstrzymywać test dla określonych userów 
wpisanych do acces z opisem Spam:adres@email FRIEND, którzy dokonaja 
autoryzacji, a puszczała do relayowania również spamerskie hosty, które 
przedstawiły się jako z domeny.
Po wywaleniu tej opcji wszystko wraca do normy, jest spokój ale nie da 
się wysłać poczty z domowego internetu obojętne czy z portu 25, 587 czy 
465, o ile nie jest to adres statyczny bo sendmail przy pomocy dnsbl 
spamhaus wysyła hosta na drzewo jeszcze przed autoryzacją.

LFC

W dniu 2020-04-04 o 13:02, LFC pisze:
> 
> W dniu 2020-04-03 o 16:32, LFC pisze:
> 
>>>
>>>> Zablokowałem INPUT dla ipv6,
>>> Jeżeli wyciąłeś ruch IPv6 na firewallu, to jaki cudem ten ruch dociera do serwera SMTP?
>>>
> Nie zrozumieliśmy się.
> W sysctl.conf od dawna mam wpisane:
> 
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.all.disable_ipv6 = 1
> 
> Chyba, że nie zrozumiałem zasady, ale 1 oznacza enabled, czyli jak dla mnie reguła ma być aktywna, czyli wyłączyć ipv6.

Tak jest OK i taka konfiguracja wyłącza IPv6.
> 
> Gdyby to oznaczało jednak, że jest włączone to tłumaczyło by czemu właziły hosty po ipv6, ale i tak mi to skrzeczy, ponieważ skonfigurowałem w sendmail.mc demony dla Family=inet, wiec nie powinny
> słuchać po ipv6.
> Dopiero REJECT na INPUCIE w ip6tables zatrzymał ten proceder.

Jak chcesz wiarygodnej analizy to pokaż logi.

> 
> Oprócz tego pakowały się hosty po ipv4 przedstawiając się jako domena. Wszystko to się działo z opcją (`delay_checks', `friend') w sendmail.mc
> która jak zrozumiałem miała wstrzymywać test dla określonych userów wpisanych do acces z opisem Spam:adres@email FRIEND, którzy dokonaja autoryzacji, a puszczała do relayowania również spamerskie hosty, które przedstawiły się jako z domeny.
> Po wywaleniu tej opcji wszystko wraca do normy, jest spokój ale nie da się wysłać poczty z domowego internetu obojętne czy z portu 25, 587 czy 465, o ile nie jest to adres statyczny bo sendmail przy pomocy dnsbl spamhaus wysyła hosta na drzewo jeszcze przed autoryzacją.

Ustawienie nasłuchu na porcie 587 z relay wyłącznie dla klientów po uwierzytelnieniu jest proste:

Sprawdź config SASLa:

[root]# cat /etc/sasl2/Sendmail.conf
pwcheck_method:saslauthd

i ustaw w sendmail.mc

dnl # The following allows relaying if the user authenticates, and disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
define(`confAUTH_OPTIONS', `A p')dnl
dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl

oraz zostaw delay_checks bez kombinacji:

FEATURE(`delay_checks')dnl

a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:

To:twoja.domena.pl	RELAY

oraz powyłączaj do testów wszystkie wpisy Spam:...

W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
W kliencie ustawiasz port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla Thunderbird: "normalne hasło").

> 
> LFC

W dniu 2020-04-05 o 23:31, Piotr Lechowicz pisze:

> Sprawdź config SASLa:
> 
> [root]# cat /etc/sasl2/Sendmail.conf
> pwcheck_method:saslauthd
> 
> i ustaw w sendmail.mc
> 
> dnl # The following allows relaying if the user authenticates, and 
> disallows plaintext authentication (PLAIN/LOGIN) on non-TLS links
> define(`confAUTH_OPTIONS', `A p')dnl
> dnl # w 2 poniższych mechanizmy możesz ustawić w/g uznania
> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
> define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
> 
> FEATURE(`no_default_msa')dnl
> DAEMON_OPTIONS(`port=587, Name=MSA, M=Ea')dnl
> 
> oraz zostaw delay_checks bez kombinacji:
> 
> FEATURE(`delay_checks')dnl
> 
> a w access wyłącz wszystkie zbędne wpisy dotyczące relay poza:
> 
> To:twoja.domena.pl    RELAY
> 
> oraz powyłączaj do testów wszystkie wpisy Spam:...
> 
> W takiej konfiguracji delay_checks przesuwa kontrolę dnsbl do momentu 
> rcpt, a poprawne uwierzytelnienie klienta wyłącza ją wogóle.
> Powyższe ustawienia zakładają, że masz już w sendmailu uruchomione 
> szyfrowanie i ehlo na porcie 587 pokazuje 250-STARTTLS.
> W kliencie ustawiasz 
> port:587/szyfrowanie:StartTLS/uwierzytelnianie:włączone (w Mozilla 
> Thunderbird: "normalne hasło").
> 

Wszystko jest tak, jak piszesz, z wyjatkiem (obecnie) opcji delay_checks 
i w acces - To:twoja.domena.pl    RELAY

Najpierw włączyłem opcję delay_checks bez opcji i po mniej wiecej jednym 
dniu miałem sajgon.
Dodałem wtedy w opcji `friend' i w acces dopisałem adresy, ktore miały 
być delayowane, jako friend - efekt ten sam.

Gwoli sprawiedliwości musze dodać, że błąd w scieżce do pliku klucza 
certyfikatu znalazłem po tym, ale nie spróbowałem ponownie, bo siedzę w 
domu na zdalnym, a zmiany w konfiguracji poczty wywołują u userów znany 
odruch - "poczta mi nie działa!" i zaraz są afery typu Muszę pilnie 
wyslać pocztę, a nie mogę, etc.
Zrobiłem nawet takie howto z obrazkami, jak sobie z tym poradzić w 
thunderbirdzie, ale i tak większość je olała / nie zrozumiała i 
zawracała mi dupę.
Nie bardzo rozumiem proponowany wpis do access
Jeżeli dobrze rozumiem to oznacza, że sendmail umożliwi każdemu wysłanie 
maila na adres z domeny. Nie jest to proszenie się o spam i nie lepiej 
dać tam OK?

LFC