Article View: pl.comp.mail.mta
Article #62806Re: sendmail podkręcenie zabezpieczeń
From: LFC
Date: Fri, 03 Apr 2020 14:32
Date: Fri, 03 Apr 2020 14:32
94 lines
5174 bytes
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-mailReferences:
<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