🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.mail.mta
Article #62806

Re: sendmail podkręcenie zabezpieczeń

#62806
From: LFC
Date: Fri, 03 Apr 2020 14:32
94 lines
5174 bytes
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
Technical Details
Message-ID: <41ujlg-pv9.ln1@mpwik1.mpwikzdw.com.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!.POSTED!mpwik1.mpwikzdw.com.pl!not-for-mail
References: <1gqdlg-b42.ln1@mpwik1.mpwikzdw.com.pl> <5e852467$0$17353$65785112@news.neostrada.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!.POSTED!mpwik1.mpwikzdw.com.pl!not-for-mail
From: LFC <longinf@mpwikzdw.com.pl>
Newsgroups: pl.comp.mail.mta
Subject: Re: sendmail podkręcenie zabezpieczeń
Date: Fri, 3 Apr 2020 16:32:34 +0200
Organization: ICM, Uniwersytet Warszawski
Lines: 100
Message-ID: <41ujlg-pv9.ln1@mpwik1.mpwikzdw.com.pl>
References: <1gqdlg-b42.ln1@mpwik1.mpwikzdw.com.pl> <5e852467$0$17353$65785112@news.neostrada.pl>
NNTP-Posting-Host: dns.mpwikzdw.com.pl
Mime-Version: 1.0
X-Trace: news.icm.edu.pl 1585924802 10411 194.150.251.249 (3 Apr 2020 14:40:02 GMT)
X-Complaints-To: usenet@news.icm.edu.pl
NNTP-Posting-Date: Fri, 3 Apr 2020 14:40:02 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
In-Reply-To: <5e852467$0$17353$65785112@news.neostrada.pl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit