Dotaz: Jak vyřešit TLSv1 na starém Postfixu v DMZ

[KoZis]

Zdravím vás, zkušenější správce linuxu a zvláště Postfixu, Mám jednu veřejnou IPv4 jakou firewall/router (IPFire). V DMZ privátní zóně pak stařičký Debian Etch jako poštovní server (Postfix + OpenSSL 0.9.8c + Dovecot). IPFire forwarduje všechny potřebné porty (25,465,587,993,995) do DMZ na ten Debian. Vše funguje OK už léta, samozřejmě pouze s TLSv1. To je tak nějak jasné, verze OpenSSL nevládne podporou TLS/SSL vyšších verzí. Nicméně v dnešní době už je z bezpečnostního hlediska takový tlak na TLSv1.1-3, že se stařičkou TLSv1 již defacto nelze provozovat MX server. Mám proto laický dotaz. Existuje nějaké řešení jako smtp proxy? Jakože představa je taková, že na firewallu/routeru poběží NĚCO, co odchytne spojení na portech 25,465,587 a bez jakýchkoliv úprav (kromě nezbytných) pošle na Postfix do té DMZ? V podstatě něco jako reverzní proxy u HTTP(S). V současné době (z mnoha důvodů) nelze daný poštovní server upgradovat (teď již spíše reinstalovat) na podporovanou verzi Debianu, kde by vše běželo na novějších verzích protokolů.

Děkuji za případné reakce KoZis

Odpovědi

[John]

Zameril bych na vyreseni pricin aby to slo preinstalovat misto vymysleni opicaren a strileni do vlastnich kolenou...

[X]

V současné době (z mnoha důvodů) nelze daný poštovní server upgradovat (teď již spíše reinstalovat) na podporovanou verzi Debianu..

Jakych? To bych opravdu rad slysel.

[Radek]

proxy je škrabání za pravým uchem levou rukou.

Ale řešení existuje. Spíš bych se ale zaměřil na upgrade serveru, nevím o žádném důvodu, proč by to nemělo jít.

https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/?_bt=573371260694&_bk=&_bm=&_bn=g&_bg=134448916960&gclid=Cj0KCQjw5-WRBhCKARIsAAId9FlXscVHb70OFE2d77K9H2evBrN96YSe2fU-1jP6ie6eaCcy9UjOn7MaAt_8EALw_wcB

https://www.proxmox.com/en/proxmox-mail-gateway

[Radek]

To proxmox řešení se mi jeví jako nejlepší, obvzlášť jestli tam máš něco starého, co ani nepodporuje spf, dkim, dmarc,...

[MP]

PMG resi komunikaci server-server, ale neresi pristup klientu na server. Jestli resi i toto, tak mu nezbyva nez i pouzit nejaky typ tcp proxy - haproxy, stunnel apod).

A vubec, pokud nema IP adresu ani pro blby mailserver, tak pokud je to firma, tak jeste hur. Tam toho bude smrdet problemy u vic veci.

[KoZis]

No, primárně jde o komunikaci MTA-MTA. Pravda je, že SMTP využívají i klienti z internetu na odesílání pošty z mailu spravované domény a to autentifikovaně. To se bude muset PMG asi drobet ohnout, aby tyto klienty ověřoval proti stávajícímu serveru.

[MP]

K cemu ohybat. Klienti budou overovat/odesilat pres mailserver, PMG s tim vubec nebude mit co do cineni, to bude slouzit pouze pro MTA-MTA komunikaci.

[KoZis]

Díky za tip. Toto se mi jeví snad jako rychlejší řešení, než reinstalace celého serveru. Zkusím to, snad to splní to, co očekávám.

A až bude i PMG outdated, dáš před něj prostě další server s novou verzí.

[KoZis]

Abych to tedy celé shrnul a tímto příspěvkem odpovím i na výše uvedené.

Starý server s Debian Etch běží ještě na vlastním železe (ne VM). Tento server jsem takto zdědil a mám k němu fyzicky velmi omezený přístup. Něco jako HW KVM konzole neexistuje. Pošta na něm je (údajně) důležitá v čase cca 6:00 ÷ 20:00/22:00, kdy je potřeba reagovat na maily do 30 minut. Server obsahuje i jiné jakési SW (i momo offiko balíčkovací systém) a scripty, jejichž důležitost a funkci se mi nepodařilo ještě rozklíčovat. V současné době to eskaluje tím, že je nedoručitelná pošta z Office365 (jen co vím), typicky doména .outlook.com, protože tyto vyžadují šifrování a nepodporují již TLSv1. Takže je pro mě jasné, že musím přeinstalovat Debian Etch na něco aktuálního a podporovaného.

Doručování pošty je důležité a potřebuji ji zprovoznit co nejdříve. Proto mě napadla tato myšlenka s předřazeným SMTP. Nový server samozřejmě JE nutnost, ale potřebuji získat čas. Nedokážu zprovoznit nový server s migrací všech dat za 1 den, protože:

1. Fyzický přístup k serveru omezen.

2. Offiko Dist Upgrade Debian Etch přes všechny předchozí verze až někde k Bullseye je sepuka. Navíc bez možnosti přístupu k HW, kdy je 99% šance, že se rozesere boot, atd.

3. Instalace nového Debian Bullseye již probíhá, ale migrace cca  150 GB dat (mailbox) něco času zabere. Navíc chci mailboxy přemigrovat z MBOX na MAILDIR.

4. Zatím neřeším vůbec ten ostatní bordel co tam běží, poběží prostě dál, než to rozklíčuju.

Snad jsem to smysluplně vysvětlil.

[Radek]

Můžeš migrovat postupně. Nahodit nový server a to, co nebude na tom serveru dorucitelne se bude přeposílat na ten starý. A takhle postupně premigrovat všechny účty. Do toho můžeš použít nějaký syncovaci nástroj. Sice je to drbacka, ale za den zvládneš i víc jak 10 uživatelů.

Druhé jednodušší řešení je na to poptat outsourcingovou firmu, která ti to nejhorší udělá a ty budeš jen obihat koncaky.

[Max]

150GB mailboxů zvládne přemigrovat během chvilky. Pokud chce měnit formáty i služby, co to obsluhují, tak imapsync a hotovo. Žádná věda, prostě rozdílový přenos emailů na úrovni imapu a je jedno, co je na pozadí za backend. Jen je potřeba znát hesla uživatelů. Teoreticky by to mělo jít i zmigrovat transparentně (=klient nepozná, že se backend změnil), ale už je to delší doba, co jsem tak migroval a nepamatuji si přesně chování. Každopádně otestovat si to na testovacím účtu a klientovi je asi to nejmenší.
Naposledy jsem dělal migraci z courier na dovecot, dělal jsem to lokálním skriptem přes ssh a vše plně ok, transparentní, klienti si ničeho nevšimli.
Zdar Max

[KoZis]

No, nejde ani tak o ten objem dat, 150GB je celkem nic. Ale starý MX server používá local uživatele z passwd, používá na "Doručenou poštu" kasický MBOX ve /var/mail, pak Dovecot má IMAP složky od každého usera v /home, prostě takový nehomogenní binec spojený s miliony aliases a pravidlech v .procmailrc. Ten, kdo to instaloval asi přemigruje rychle, já se v tom musím drobet zorientovat a to chce prostě čas.

Nový MX server již chci mít s virtuální doménou, uživateli v DB a všechny složky na jednom místě. Vše je řešitelné, ale jde mi to pomalu. K dispozici je jen jedna veřejná IPv4 adresa, takže i testování zvenku je docela problém.

Jde o cca 150 účtů, tak to chci nějak zautomatizovat, při nejhorším vše ručně, ale opět je to o čase.

[X]

Deset let na to nikdo nesahnul a ted to na migraci nepocka? To je nejaky vtip? Uplna parodie na spravcovstvi..

[j]

V souladu s RFC stejne musi ten tvul server komunikovat i zcela nesifrovane, takze je to uplne jedno, a typicky nastaveni je, ze mailserver krome toho nesifrovanyho spojeni dovoluje i libovolne deravy spojeni sifrovany.

A jinak se "proxy" dela tak, ze vystavis do internetu jinej mailserver, kterej pak interne ty maily predava/prebira na/od toho cilovyho. Naprosta klasika je to trebas s exchange.

Mimochodem, kdybys zakazal tls 1/1.1, tak se ti trebas z centra nikdo nedomailuje. A to neni zdaleka jedinej pripad.

Bezpecnost mailu se totiz odjakziva resi sifrovanim toho mailu, a ne komunikace. Coz pochopitelne trebas soudruzi v nukibu naprosto nechapou.

---

Dete s tim guuglem dopice!

[KoZis]

Můj server nabízí TLSv1 nebo nešifrovaně. Bohužel některé MTA odmítají zasílat nešifrovaně a poslední dobou (co mám z logu tak od 12.3.2022) tap např z Office365 již nedojde nic. Proste SSLv3 error a konec. Vyžadují šifrování, ale nepodporují už TLSv1.

[alkoholik]

Moje zkusenost rika, ze po SSLv3 erroru uz mail servery nedelaly fallback na plaintext. Workaround byl pridat do main.cf:

smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/discard_ehlo

A v /etc/postfix/discard_ehlo byl seznam subnetu, kterym se sifrovani vubec nenabidlo:

194.50.240.33/32	starttls,silent-discard
194.50.240.161/32	starttls,silent-discard
213.180.53.50/32	starttls,silent-discard

Dnes uz ti ale nepovim, jestli postfix z Etche smtpd_discard_ehlo_keyword_address_maps vubec zna.

[KoZis]

To už snad ani nebudu zjišťovat a zkoušet. Pokud MS servery odmítají plaintext, stejně nedoručí. Zkusím tu mail GW dočasně a nový server. Ať se nějak pohnu.

[Max]

Můžeš jako hotfix asap řešení nasadit mail gw před ten tvůj server. Každopádně fakt jen jako asap hotfix, protože dřív, nebo později, tě doženou další problémy spojené se zastaralými šiframi.
Každopádně Debian 4, to je fakt něco šíleně starýho, do toho se musí dostat každý druhý script kiddies.
Zdar Max

[X]

a rika si spravce..

[KoZis]

Ano, tak jsem to myslel. Pokud existuje rychlé řešení, zprovoznit a věnovat se v klidu novému stroji včetně migrace tak, aby vše klaplo co njlépe.

[Peter Golis]

Stavím sa že ku druhému kroku už nedôjde ak prvý krok plne pokryje požiadavky. Debian Etch bol vydaný 2007-04-08, a podpora mu skončila 2010-02-15. Dnes má tucet rokov po ukončení podpory.

[KoZis]

Ne. To není můj vlhký sen, provozovat starou nepodporovanou jebku. Jak jsem psal výše, tento jsem zdědil před měsícem, jako plně funkční, bez dokumentace a téměř žádného osvětlení, jen k čemu slouží. A jak se tak s ním prokousávám, co tam běží, co dělá, atd., tak před týdnem přestal přijímat maily od některých serverů.

Nový server Debian Bullseye už je v podstatě hotový. Zbývá dodělat a otestovat nové mail technologie (SPF,DMARC,DKIM, atp.) a hlavně nějak nascriptovat a udělat migraci. Nechci nic uspěchávat, abych něco nerozjebal, co by nefungovalo. Navíc vše testuju v noci, přes den jiná práce, poštovní servery nedělám obden, takže prostě je to pro mě fakt jen o čase.

[Peter Golis]

V tom prípade prajem veľa zdaru, a držím palce. Ak je ten server reálne dostupný z internetu, tak má za tú dobu od konca podpory peknú zbierku remote exploitov.

[KoZis]

No, tak na to mi skill nestačí, abych zjistil nějakou míru kompromitace. Ale tak běží v DMZ za NAT a má pouze forwardované poštovní porty. Je tam i shorewall jako fw, který všechny ostatní služby blokuje. Ale tak ano, bavíme se pořád o 15 let staré zombie.

[Jendа]

make the application listen to 127.0.0.1:4443 or something like this

socat -v openssl-listen:443,cert=/etc/ssl/our_key_cert.pem,verify=0,reuseaddr,fork ssl:127.0.0.1:4443,verify=0,method=ssl3

pro tebe ne ssl3 ale tls

nebude to fungovat se STARTTLS, na to možná je nějaký parametr socatu, ale spíš ne. Snad ti bude stačit varianta s přímým TLS, jinak by sis musel STARTTLS implementovat.