Dotaz: firemni mail server, certifikat a vpn...

[ehmmm]

Mala firma o sesti lidech ma svuj server "brana.firma.cz" s verejnou pevnou IP adresou, je zaroven i router, www server (apache, v DNS u Webglobe je pro stejnou IP adresu nastaveno i "www.firma.cz" a "firma.cz"), mail server (smtp pres exim, pop3/imap pres dovecot) a openvpn server. Pro lokalni sit funguje i jako dns+dhcp server. Rekneme, ze v lokalni siti ma ip adresu 192.168.1.1 a bind/named v lokalni siti hlasi, ze "brana.firma.cz" je 192.168.1.1.

Lidi maji na svych pocitacich ve firme v Thundebirdu nastaveno, ze postu maji stahovat z "brana.firma.cz", port 110, starttls, jmeno/heslo. Analogicky pro odesialni "brana.firma.cz", port 25, starttls, overeni jmenem/heslem. Port 110 je v iptables povolen jen v LAN, port 25 je logicky otevren i do sveta.

V ramci let's-encryptoveho nadseni, kdy se mi podarilo na apachi rozchodit https s let's-encryptovym certifikatem pro domenu "www.firma.cz", jsem dostal napad, ze let's encrypt vygeneruje i certifikat pro "brana.firma.cz", tenhle certifikat jsem symlinkama nastavill v dovecotu i v eximu a svet je ruzovy. (Doted tam byl od byvaleho kolegy nejaky roky propadly self-signed certifikat. Lidi v Thunderbirdu schvalili vyjimku, ja nemel ve svem Thunderbirdu starttls zapnute vubec. Ucim se.)

Problem nastane, kdyz se lidi pripoji z domu pres (open)vpn. Thunderbird hleda "brana.firma.cz", z verejneho DNS se dozvi venkovni pevnou ip adresu. Odesilani funguje, protoze smtp port 25 je povolen i zvenci. Ale prijem ne, protoze pop3 port 110 mame radsi zvenku zavreny. Takze uzivatel si doma prenastavi Thunderbirda na 192.168.1.1, vyskoci na nej schvaleni vyjimky, ze server je "192.168.1.1" ale certifikat je na "brana.firma.cz", on to schvali a jsme tam, kde jsme byli.

Ma to nejake rozumne reseni?

Zatim nemam odvahu povolovat pop3 i zvenku (ty lidi tam maji nastaveny fakt trapny hesla). Na druhou stranu smtp je otevrene do sveta a taky zijeme.

Premyslel jsem, ze bych v openvpn nastavil, ze by po otevreni tunelu uzivateli nahlasilo, ze na "brana.firma.cz" se musi tunelem, to by bylo nejlepsi. Ale moc nevim jak, navic "brana.firma.cz" je vlastni openvpn server a tim padem nejspis neni spravne menit cestu pod rukama. (?)

Takze dalsi napad: zavest nazev "mail.firma.cz", ten nastavit v Thunderbirdu a nejak zonglovat s dns. V lokalni siti by lokalni dns server vracel lokalni adresu, v internetu by vebglobe vracel verejnou adresu (aby let's encrypt videl) a po otevrei tunelu by u uzivatele nejak vyhralo to lokalni dns a na "mail.firma.cz" by se slo vnitrkem.

A ma to vubec smysl? V ramci lokalni site ve firme asi neni sifrovani potreba. A pri pripojovani z domu, vzhledem k tomu, z kdokoliv schvali jakoukoliv vyjimku, tak to stejne prijde vnivec.

Odpovědi

[Max]

A pushuješ přes VPN lokální dns servery? Protože pokud ne, tak bude vždy problém. Musíš OpenVPN klientovi pushnout, aby po připojení používal lokální dns server ve firmě.
Zdar Max

[ehmmm]

Nedelam to, ale muzu. To byl jeden z tech napadu.

Ceho tim dosahnu? Ze se na "brana.firma.cz" pujde tunelem? A jak potom bude vlastne fungovat ten tunel?

[Max]

Pokud máš jeden server, který se jmenuje "brana.firma.cz" a přes toto jediné DNS voláš služby, tak to děláš samozřejmě špatně. Skoro pro každou službu by jsi měl mí vlastní dns záznam. Ulehčuje to pak práci se službami, jejich směrování, migrace atd.
Měl by jsi mít tedy pro vpn sólo dns záznam:
vpn.brana.firma.cz = veřejný dns záznam s veřejnou IP pro připojení VPN
Zdar Max

[ehmmm]

Ok, dik za smer, zkusim, ale ne dnes.

Dnes se snazim pochopit dkim a spf. Pouziva se to? Zahazuje nekdo emaily, ktere nemaji dkim a spf v poradku? Da se let's encrypt skloubit i s timhle?

[Max]

dkim i spf používám, v režimu striktního nastavení. Let's encrypt nemá s DKIM ani SPF nic společného. Pro dkim sice generuješ klíč, ale ten si generuješ vlastní a jeho platnost se ověřuje přes záznam v dns. Let's encrypt použiješ jen pro služby pro klienty jako smtps/imaps/pop3s/https apod.
Zdar Max

[j]

Guugl ti dost pravdepodobne odmitne maily dorucovat, pokud to nebudes mit nastaveny. A miliony ostatnich ti prihodi nejaky ten bod nebo dva do spam score.

Pokud to pak mas dokonce blbe, tak se s tebou hromada mta odmitne bavit uplne.

---

Dete s tim guuglem dopice!

[Rocky]

Přesně tak, je lepší mít SPF a DKIM nenastavený, než ho mít blbě. Setkávám se s tím takřka denně. Třeba s gfi.com (docela paradox dle toho, čím se firma zabývá) = SPF error.

Jinak samozřejmě platí = SPF + DKIM + DMARC "must have", pokud to s maily myslíš vážně

[Josef Kufner]

Tvoje DNS resolvne tvoje interní DNS záznamy na interní adresy ve VPN či LAN za VPN a ostatní adresy resolvne na běžné veřejné. Takže interní věci pak půjdou na VPN a vše ostatní mimo. Pokud klient chce, tak si nastaví, aby se na tvůj DNS server ptal jen na určitou doménu, tedy např. *.firma.cz. Je potřeba mít vše ve VPN v jednom DNS podstromu, aby toto dobře šlo. (S reverzními DNS to funguje stejně, jen su nastavíš vhodnou subdoménu v in-addr.arpa). Pokud si to klient nenastaví, tak bude firemní DNS server otravovat všema dotazama, což nijak moc nevadí.

Tunel jako takový funguje pořád stejně.

[Jendа]

Bohužel běžné OS neumí pushnout "resolvuj přes mě jen *.firma.cz", a vnutit uživatelům svoje DNS na všechno trvale (mailový klient asi běží trvale) bych moc nechtěl…

[trekker.dk]

Proč ne? Myslíte, že firemní rekurzivní resolver je v něčem horší než rekurzivní resolver náhodného ISP, přes kterého je ten počítač zrovna připojen?

[Jendа]

Máte pravdu, že to asi nebude tak hrozné. Drobná latence kvůli routování přes další hop a pocit admina „mhm tečou přes mě data o tom co uživatelé překládají za domény“, ale jinak asi nic.

[Max]

A jak asi fungují firemní vpn? Musíš uživateli pushnout svůj interní recursor, aby dokázal přeložit všechny služby, co běží v interní síti.
Tj. klient po připojení na vpn používá tvá dns.
Zdar Max

[alkoholik]

Nevim, co jsou u tebe bezne OS, ale Windows, Linux i macOS to (split DNS) umi.
BTW: pushuje VPN server.

[Jendа]

Na Linuxu to nejde s libcčkovým resolverem, ale musí se pustit nějaký lokální resolver, třeba systemd-resolved, a toho se to pak ptá. Na ostatních OS nevím, ale ze zběžného zagooglení pro Windows mi to nepřišlo.

[alkoholik]

Viscosity to dela samo, defaut klient si musi nastavit NRPT pres PowerShell skripty.

[MP]

Vykaslete se na tyhle ohybaky, zvlast v takhle male firme.

Na prvnim miste bych se zbavil pop3.

Na druhem miste bych misto pop3 vsude pouzil imap (s ukladanim lokalni kopie na klientovi).

Na tretim miste bych vsechny donutil k zmene hesla, idealne pokud lze nastavit aspon nejakou minimalni delku hesla v dovecotu (ci v cem to administrujete).

Na ctvrtem miste bych pro pripojeni na mail pouzival public domenu/ip. Tim odpadne rozdil ve firme/na vpn.

Na patem miste bych nasadil klidne fail2ban na loginy.

Na sestem miste zapnul bych sifrovani. Je to nutnost i v lokalni siti.

Problem solved. Na vsech urovnich vcetne stredne blizke budoucnosti.

[j]

Ty dovolujes odesilat maily bez autorizace (=provozujes open relay)? Nebo ti ty jak sam rikas smesny hesla posilaji na ten port 25 ... kam navic vubec nepatri, a to jeste idealne nesifrovane?

Mel by ses toho hodne naucit ... (nebo si na to nekoho najmout)

Pro klientsky odesilani se nepouziva port 25, ale port 587. Mimo jiny proto, ze na tom portu pochopitelne vynutis sifrovani, coz na 25 nemuzes (jinak si nezamailujes).

A na cteni mailu se nepouzva uz asi tak 150 let pop, ale imap. Specielne u firemnich mailu prece nechces, aby si ty maily lidi stahovali, ale chces aby zustaly na serveru.

vpn do toho vubec netahej, to je uplne zbytecna vec. Navic si se 100% jistotou nabijes hubu na tom, ze nekdo bude doma pouzivat stejne rozsah IPcek jaky pouzivas ve firme.

V lokalni siti samozrejme sifrovani potreba je, protoze pokud chces aby byla bezpecna, musis se k ni chovat jako by byla verejne pristupna. Protoze realne ... je.

BTW: Hesla se resi politikou(vynucenim) a aktualne se za nejkratsi bezpecny heslo povazuje 14 znaku (samo, typicky se do toho jeste vlozej pravidla, ze nesmi obsahovat jmeno dotycneho, musi obsahovat ruzny znaky jako maly/velky/cisla/...).

BTW2: To copise max, se se kazdy sluzbe dava extra dns je samo taky pravda, protoze kdyz to pak chces nekam presunout, tak proste jen zmenis IPcko a nemusis rekonfigurovat klidne i tisicovky zarizeni.

---

Dete s tim guuglem dopice!

[ehmmm]

Ach jo, to zas bude flame.

Podle Wikipedie se pred 150 lety narodil Roald Amundsen.

Zazil jsem dobu, kdy byl jenom pop3, u smtp nebyly potreba zadny jmena a hesla a taky to fungovalo.

Filozoficky, k cemu je na jednom portu vynucovat sifrovani, kdyz na druhem portu sifrovat z principu nelze?

Kdyz jsem kdysi pri studiich zkousel ve svem postovnim programu nastavit imap, tak mi to smazalo vsechny maily. Od te doby imapu neduveruju, ale to je muj osobni pocit, ostatni ho pouzivaji.

Nevim proc bych nemel chtit, aby si lide maily stahovali. V terenu jim jsou na serveru k nicemu.

VPN je v nasem pripade nezbytna pro spoustu dalsich veci, tak proto jsem se te myslenky drzel.

Ze ma nekdo doma stejne adresy jako v praci, to se fakt stalo. Souhlasim, je to pakarna.

Komunikovat ve firme sifrovane s postovnim serverem, ktery je ve vedlejsi mistnosti, je zajimave, zabavne (aspon zatim me to bavi zkoumat) a jiste moderni, ale osobne to nepovazuji za nezbytne. Z hotelu to uz je jina.

Opakuji, firma o sesti lidech, my to tu mame na pohodu, 14znakova hesla si davej nekam do fabriky/korporatu.

Jestli se tady neceho z pohledu IT bojime, tak to je zavleceni ransomwaru, ale zrovna sifrovani/podepisovani mailu to asi moc neresi.

S bezpecnosti se to nesmi prehanet. Zrovna pred chvili jeden zakaznik chtel, abych mu poslal zdrojaky k PLC. Bohuzel zip mu nelze mailem poslat, protoze maji paranoidni IT. Tak jsem mu to dal do uschovny a rozhodne jsem ten zip nezaheslovaval. At zije bezpecnost.

[j]

OK, je videt, ze ses jeste vetsi blbec nez to vypadalo ...

Na port 25 se klient jednoduse nepripoji, protoze tam neni dovoleno se pripojit, to je zaklad jakyhokoli nastaveni. A tudiz se klient donuti k tomu ty hesla (a veskerou dalsi komunikaci) sifrovat. Kapis?

Maily jsou na serveru proto, aby se zalohovaly. Fakt by me zajimalo, jak zalohujes maily na nejakym domacim pc. Jo aha, ty nevis ze by se melo neco zalohovat ... lol. Kazdej imapovej klient si typicky bydefaul drzi lokalni cache, jejiz velikost/historie se da nastavit a to i na vsechno.

Lidi v terenu maji telefon ... s datama. Ale chapu, ze sou firmy, ktery si 300Kc mesicne nemuzou dovolit ... lol.

Kdy ze mam prijit na kafe? Pripojim si telefon na vasi wifi ju? A stahnu si jak veskery data, tak odchytim veskery hesla. Hodinka bude bohate stacit. Proc by se melo neco sifrovat, je to zbytecny ....

Podotykam, ze na to tema existuje nekolik trestnych cinu, ktery se prave TY jako spravce dopoustis. Protoze firmy maji nekolik zakonych povinosti, ktere jim ukladaji data chranit dostupnymi prostredky. Specielne hesla pak patri mezi obzvlaste citlive udaje. Ale nejen to, na firemnich discich se zcela jiste vali minimalne osobni udaje zamestnancu, a vetsinou i pekny radky zakazniku. Mas ze zakona povinost ta data zabezpecit, mas povinost dotycne informovat, pokud dojde k jejich kompromitaci atd atd.

A pochopitelne, mezi to zabezpeceni patri i pouzvani bezpecnych hesel - a je opet tvoji povinosti ze zakona, to zajistit.

---

Dete s tim guuglem dopice!

[trekker.dk]

Zazil jsem dobu...

... a ta doba je za námi. Pokud to vašim uživatelům stačí, budiž. Pokud to jako správci těch služeb stačí vám, nejste dobrý správce, protože nenabízíte to nejlepší, co lze stejně snadno nabídnout. (Což vám samozřejmě nemusí vadit, to je skutečně jen na vás a na tom, jak moc si ceníte pocitu dobře odvedené práce.)

Nevim proc bych nemel chtit, aby si lide maily stahovali. V terenu jim jsou na serveru k nicemu.

Nemáte jediného uživatele, který by chtěl mít přístup k poště na telefonu i stolním počítači? Notebooku i počítači? Co znamená, že jsou v terénu na serveru k ničemu - není to náhodou, že neumíte nastavit poštovní klient, aby poštu synchronizoval na lokální úložiště?

[ehmmm]

Vazeni, inspirace jsem dostal dost, spoustu jsem se dozvedel a dekuji vam za to.

Jenom si tady furt nerozumime. Ja nejsem zadny spravce ani IT, chran Buh. Jsem prosty inzenyr-programator-elektrikar, ktery dostal od sefa za ukol preinstalovat server. Par dni me to bavilo, dnes uz musim delat neco jineho. Jinak se IT vyhybam, jak to jen jde. Postu v telefonu necteme, dva z nas maji dokonce jeste tlacitkovy telefon. Osobne ani nevidim duvod, proc bych si mel doma tahat firemni postu na domaci pocitac, ale jeden kolega to tak dela. Ti, co maji stolni pocitac, nemaji notebook a naopak, opet az na jednu vyjimku. Zijeme. Dobre odvedena prace je pro nas neco uplne jineho.

Svetu mir.

[KR]

Jak moc mají elektrikáři rádi, když si lidé sami zapojí doma elektriku? Asi to často nemají tak docela správně... Tady reálně hrozí, že Vy podobně přistupujete k instalaci serveru. Stejně jako ta elektrika, není to žádná raketová věda, ale ignorovat dobře míněné rady lidí, co tomu přeci jen rozumí poněkud lépe, není zrovna moudré a může se to časem vymstít.

[j]

"Jsem prosty inzenyr-programator-elektrikar" ...

... "ja za to nemuzu, ze to zabradli sviti, ja prece nejsem elektrikar, to sef po me chtel, abych ty draty prepojil ..."

---

Dete s tim guuglem dopice!

[Jendа]

Analogicky pro odesialni "brana.firma.cz", port 25

To je špatně, pro odesílání se používá SMTP submission, porty 465 a 587 (dle TLS/STARTTLS). Port 25 bývá pro uživatele často blokovaný, protože přes něj lze posílat spam napřímo do serveru příjemce. (ale s problémem to nesouvisí)

Takze uzivatel si doma prenastavi Thunderbirda na 192.168.1.1, vyskoci na nej schvaleni vyjimky, ze server je "192.168.1.1" ale certifikat je na "brana.firma.cz", on to schvali a jsme tam, kde jsme byli.

Ma to nejake rozumne reseni?

Ne. Můžeš mít zvlášť smtp.firma.cz a pop.firma.cz, přičemž to druhé bude mít 192.168.1.1. Thunderbird má úplně zvlášť přijímací a posílací server, takže pohoda. Ale to nefunguje pokud uživatelovo DNS dělá rebinding protection - což dělá OpenWRT v defaultu. (certifikát na doménu s 192.168.1.1 si vystavíš… no, asi přes DNS ověření u letsencrypt)

Zatim nemam odvahu povolovat pop3 i zvenku (ty lidi tam maji nastaveny fakt trapny hesla). Na druhou stranu smtp je otevrene do sveta a taky zijeme.

Osobně si myslím že na SMTP se útočí mnohem víc, minimálně necílené útoky - protože to jde zneužívat pro spamy. Na pop se útočí cíleně, pokud chceš ukrást firemní knowhow (a nebo ho zašifrovat a chtít ransom, ale lidi ty maily asi budou mít stažené u sebe)

Jinak doporučuju implementovat limit počtu mailů na jednoho uživatele. Existuje na to postfwd, ale bylo to příšerné. Ale jde to snad snadno naskriptovat úplně from scratch:

dáš do konfigurace postfixu
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040

na ten port ti pak s každým mailem přijde 

sender=owner-postfix-users@postfix.org
client_name=english-breakfast.cloud9.net
client_address=168.100.1.7
sasl_username=xx
(a další údaje)
<prázdný řádek>

ty na to odpovíš

action=DUNNO

resp. ACCEPT/DENY/REJECT(?)

a počítáš kolik kdo poslal mailů - spammer → tisíce za hodinu. A pak odpovídáš REJECT a pošleš mail adminovi ať to řeší

[Jendа]

Ještě mě napadlo, že bys mohl mít dvoje hesla - jedno silné pro přístup z klienta (kde ho uživatelům třeba zadáš, nebo si ho tam zkopírují, a uloží do vestavěného password manageru), a jedno slabé které používají k kdo ví čemu - ne, fakt, jak vlastně můžou mít slabé heslo? To ho někam zadávají? Do webmailu? Pokud ne, tak jim prostě vygeneruj silné a bye. Rozumné poštovní servery umí nastavit autentizaci různými způsoby (custom SQL dotaz, PAM, LDAP pokud jsi labužník…), takže dvoje hesla nebudou problém.

Jinak jak nahoře lidi hejtí pop - osobně ho také pořád používám, a to zejména kvůli tomu, že mi ve starších Thunderbirdech přišlo u IMAPu velmi ne-zřejmé zjistit jestli je email stažený nebo je jenom na server a při nedostupnosti serveru o něj přijdu. Uznávám, že to je jenom UX konkrétního klienta nebo moje neschopnost a jako protokol je IMAP lepší.

[Andrej]

• Open„VPN“ není VPN. Je to ubohá jednovláknová dětská hračka v userspace, která nikdy pořádně nefunguje a přináší všeho všudy „výběr“ problémů, které skutečná VPN už asi 20 let nemá. Open„VPN“ byla technologie poplatná 90. letům, kdy podstatná většina operačních systémů neměla nativní podporu pro VPN. Dnes ji všechny operační systémy mají, jmenuje se IPSec. Open„VPN“ nedává ani náznakem smysl.
• Co je to 192.168.1.1? To byla taková ta telefonní čísla ze 70. let, která měla sloužit jako jakési primitivní internetové adresy? (A která byla v konfliktu s milióny jiných, protože tam existovaly „neveřejné“ rozsahy a podobné kraviny?) To už se dnes nepoužívá. Vně VPN samozřejmě může být podpora pro IPv4, kdyby náhodou někdo z připojovaných kolegů skončil na zaostalé síti bez podpory skutečného Internetu (IPv6). Nicméně uvnitř VPN má být vždy jen a pouze IPv6, samozřejmě s veřejnými adresami — jakými jinými. Pak není třeba tolik řešit, kterou adresu má vracet DNS.
• Pokud je cílem povinný přístup k mailovým schránkám skrz VPN, IPSec dokáže zařídit přesně to, co je potřeba: routovat do vybraných rozsahů adres (veřejných, samozřejmě!) pouze skrz šifrovaný tunel a nikoliv přímo skrz veřejný Internet. Router tedy může být nastavený tak, aby do příslušného (veřejného!) rozsahu, ve kterém je mail server, pustil provoz jedině skrz IPSec, zatímco skrz veřejný Internet se tam doroutovat nedá.
• VPN (tedy IPSec) každopádně není náhradou za zabezpečení serveru samotného. Samotný server musí nutně mít veřejně platný certifikát (od toho je LetsEncrypt!) plus k tomu DNSSEC+DANE+TLSA, povinně šifrovaná spojení a ideálně taky autentifikaci klientskými certifikáty (což Thunderbird umí, tak proč toho nevyužít?), aby například lámání „hesel“ nebylo myslitelné. Nedává žádný smysl schovávat polovičatě nastavený mail server do VPN (tedy IPSec) a myslet si, že se tím cosi vyřeší. Bezpečnost je jako cibule a má mít mnoho slupek, nemá nikdy spoléhat na jedinou slupku a/nebo ukrývat prohnilou slupku do méně prohnilé.
• Jak tak čtu celé líčení o šílené amatérské pseudosprávě sítě: Nebylo by mnohem lepší se na to vybodnout a zaplatit si u některého z poskytovatelů cloudových služeb taky mailové služby na vlastní doméně? Tím by všechny zmíněné nesmyslné problémy (zjevně způsobené neznalostí někoho, kdo se na správu systémů nespecializuje a snaží se cosi bastlit hlava nehlava) jedním rázem zmizely.
• Má ten mail server v pořádku DKIM? Má v pořádku TLSA/DANE a DNSSEC celkově? Rotace všech klíčů (DKIM, DNSSEC, TLS pro spojení) je automatická? Jakpak je na tom s ADSP a DMARC? Dostane v testu internet.nl (dnes už v podstatě povinných) 100%? Pokud je na něco z toho odpověď ne, doporučuji vybodnout se na to a objednat mailové služby od někoho, kdo se takovými službami zabývá profesionálně.
• POP3 je nesmysl z 90. let. Už 20 let se používá IMAP, pokud jde o přístup k mailu, protože ve srovnání s POP3 má až příliš mnoho výhod.

[trekker.dk]

Jenom info pro původního tazatele - Andrej je tady taková figurka, co žije v alternativní realitě a občas přijde do té naší o tom lhát. Teda kromě případů, kdy se tu někdo ptá na to, jak vyřešit nějaký skutečný problém s IPv6 a IPsec, to pak z nějakého důvodu nepřijde.

[Radek]

neštetekrát jsem zažil nefunkční ipsec, openvpn v 99% projde a když ne, tak neprojde žádná jiná vpn snad krom sstp, ale ta zas má hodně bad perfomance .

[ehmmm]

V podstate jedina zajimava informace v tvem prispevku je ten odkaz na internet.nl. Mam 81%. Nemam IPv6, DMARC mam nastaveno volne, potom oranzovy vykricnik u TLS 1.0/1.1, druhy oranzovy vykricnik za podporu sifry AES256-GCM-SHA384, vubec nemam DANE/DNSSEC (to si jeste zkusim nastudovat).

Kdyz se podivam, jakym autem jezdim, tak tohle mi prijde jeste v pohode. Mimochodem, zapnul jsem si zobrazovani platnosti DKIM v Thunderbirdu a ani nektere nadnarodni korporace s hodne paranoidnim IT to nemaji v poradku.

Co se tyka ipsec a ipv6, tak to jsou temata, na kterych se neshodneme.

[ehmmm]

Sorry, to mela byt reakce na Andreje.

[ehmmm]

Koukam na DANE/DNSSEC a asi to uz mam OK. Neuvedl jsem v DNS zaznamu TLSA svuj let's encryptovy certifikat, protoze ten za chvili vyprsi, ale ten prvni certifikat let's encryptu. (Respektive ten posledni v /etc/letsencrypt/.../fullchain.pem) Nicmene i ten za par let vyprsi a bude treba ho aktualizovat. To mi prijde jako opruz.

Kdyz jsem koukal na internet.nl, tak Andrejovych temer povinnych 100% tam ma kazda priblizne petadvacata (slovy: 25.) domena.

[Andrej]

Certifikáty se mají aktualizovat zcela automtaicky, každé cca 2 měsíce. (LetsEncrypt je obvykle vydává na 3 měsíce, takže 2 měsíce jsou tak akorát s nějakým prostorem pro řešení neobvyklých situací, nastanou-li zpočátku nějaké.)

1. Vyžádá se nový certifikát od LetsEncrypt.
2. Nový certifikát od LetsEncrypt se publikuje v DNS (TLSA), ale zároveň se tam ponechá i ten starý a na mail serveru se také zatím ponechá starý.
3. Asi tak za týden se na mail serveru začne používat nový certifikát.
4. Za další týden se odstraní starý certifikát z DNS (TLSA).
5. Pak se nějakých 8 týdnů nic neděje a vše je stabilní, než to začne nanovo.

Tohle^^^ všechno samozřejmě musí být zcela automatizované, jinak je to děsivý opruz, na který bude správce soustavně zapomínat. Nejjednodušší implementace je třeba nějaký systemd timer, který se každý den podívá, jestli by se „stavový stroj“ pro rotaci klíčů nedal posunout o kousek dál. Například: Tady máme už týden publikovaný nový klíč v TLSA, pojďme nasadit nový klíč na serveru. Tuhle zase máme už týden nový klíč na serveru, pojďme odstranit starý klíč z TLSA. A onde zase máme už 8 týdnů stabilně stejný certifikát, pojďme si od LetsEncrypt vyžádat nový. Atd. atp.

Další podobný mechanismus rotace by měl být taky pro DKIM klíče a DKIM záznamy. Obvykle se DKIM záznamy číslují (a můžou se jmenovat libovolně, protože odkaz na DKIM záznam je v mailech samotných) a nechávají se v DNS tak čtyři — jeden budoucí, jeden současný a dva minulé. (Další rozdíl oproti TLS + TLSA je ten, že u DKIM neexistuje důvod používat klíče související s LetsEncrypt certifikáty; klíče můžou být zcela libovolně lokálně vygenerované.)

[Andrej]

Vzhledem k tomu, že testy na internet.nl prověřují spíš nutné než postačující nastavení serveru, pod 100% bych já osobně asi nešel. Ano, je pravda, že spousty veřejně známých mailových domén tam 100% nemají, nicméně jejich správci většinou vedou v patrnosti, proč jim ten či onen nedostatek projde. Nedostatky velkého poskytovatele mailu jsou leckdy ostatními velkými poskytovateli tolerované, aby se maily příliš neztrácely. Menší a soukromě provozovaný mail server takový luxus a vliv nemá a měl by být nastavený v co nejlepším souladu s „best practices“ (které se pochopitelně pomalu mění, takže 100% dnes nezaručuje 100% za rok; pořád je tam nějaká práce).

Co se tyka ipsec a ipv6, tak to jsou temata, na kterych se neshodneme.

Tohle není věc názoru a/nebo shody. Zkrátka, IPv6 je internet, zatímco IPv4 je paskvilozmetek z roku 1975, který byl jakýmsi nepodařeným experimentem a nebylo vůbec zamýšleno, že se bude globálně a veřejně používat s takovými adresami, jakými později nechvalně proslul. Nemít IPv6 v podstatě znamená nemít server připojený k internetu.

Nemluvě o tom, že IPSec a IPv6 zajistí bezproblémové routování do jakékoliv sítě, ať už soukromé a dostupné jen skrz VPN nebo zcela veřejné, a nedojde nikdy ke konfliktu adres. Různé zoufalé VPN servery, které klientům přidělí telefonní číslo 192.168.1.x/24, které ovšem mají někteří i na domácím routeru a pak jim nic nefunguje, by měly být věcí minulosti. VPN s IPv6 a s unikátním veřejným (jakým jiným!) rozsahem adres bude fungovat vždy a všude, bez ohledu na to, jaký IPv6 rozsah má uživatel doma. (A tunel s IPv6 může vést i skrz IPv4, čímž navíc odpadne (pořád ještě sporadicky existující) problém typu „nemám internet“ (== „nemám IPv6“).)

[Jendа]

Tohle není věc názoru a/nebo shody.

Ano, navíc v tomto případě mu IPv6 řeší problém -- zatímco RFC1918 adresu nemůže do veřejného DNS dát, protože bývají filtrovány některými resolvery, tak u IPv6 AFAIK žádný takový problém není. Takže mu stačí dát tu adresu do DNS, nastavit aby se routovala přes VPN a vyřešeno.

[ehmmm]

Odpovim na vic veci najednou.

Naposledy k IPv6: Bezne pracujeme se zarizenimi, ktera IPv6 proste nemaji. Ani nasi zakaznici nebo kolegove/konkurence to ve fabrikach nemaji. Proste neexistuje.

Automatizovane aktualizovat TLSA zaznamy u Webglobe nebudu. Maji na to sice nejake API, ale tohle vzdavam. Moc usili na moc maly zisk.

U dkim ma Andrej nepresnost, kterou drive vysvetloval Max. Tam se nic aktualizovat nemusi. U sebe mam tajny klic, v dns mam verejny a tak to bude na veky veku. U dim zadne datumy nebo autority nejsou.

Vcera jsem v dovecotu zapnul povinne starttls a nikdo si nestezuje, takze to vypada, ze vsichni ve firme maji starttls v Thunderbirdu nastaveny. (Neresme pop3/imap, evidentne to je u nas ve firme vec vkusu.) Tim padem bych mohl pop3 na serveru otevrit i zvenku. Trapna hesla budou chodit sifrovane a...

... a zkusmo jsem nainstaloval fail2ban. Nejak to funguje.

Pak zde byla diskuze o (ne)sifrovani na portu 25. Chvili odposlouchavam provoz zvenci a prijde mi to, ze vsichni slusni po EHLO vzdy prejdou na STARTTLS. Ale spis me zajimaji ti neslusni, vzdy to vypada takhle (zestrucneno):

(pripoji se exoticky klient k serveru)
S: 220 brana.firma.cz ...
C: EHLO User (doslova)
S: 250-brana.firma.cz (vycet vcetne STARTTLS)
C: RSET
S: 250 Reset OK
C: AUTH LOGIN
S: 503 AUTH command used when not advertised
C: QUIT
S: 221 ... (+ TCP FIN)

Vypada to, ze exim v debianu to ma asi nejak poreseno.

[trekker.dk]

Tam se nic aktualizovat nemusi. U sebe mam tajny klic, v dns mam verejny a tak to bude na veky veku.

Mám zato, že v tomto se mýlíte. Respektive samozřejmě to tak můžete udělat, ale pokud vím, teorie je taková, že čím víc dat s tím klíčem podepíše, tím větší šance je prolomit ten klíč. A jestli si dobře pamatuju, tak Google někdy někde psal, že budou vyžadovat pravidelné obměny toho klíče - respektive k mailům, které jsou podepsány pořád tím samým, se budou chovat, jako by to DKIM podpis nemělo.

Jak ty se sem vůbec dostaneš, když máš internet?

[Peter Golis]

Nič v zlom. Ale keď sa s tým toľko trápiš, nebolo by lepšie outsourcovať mailserver priamo nejakému poskytovateľovi cloudu alebo priamo poskytovateľovi internetovej prípojky? Predpokladám že sa jedná o Biznis prípojku, najlacnejšie domáce prípojky zvyknú mať verejnú IP z rozsahu ktorý je blokovaný na príjem pošty. Tí poskytovatelia sa v tom obvykle vyznajú, keďže je to súčasť ich zárobkovej činnosti. A takéto SOHO riešenia dosť často zlyhávajú ak človek nenastaví napríklad spomenutá email podľa toho, ako si práve zmyslí napríklad Google.

[Host]

Možné řešení je oddělit SMTP a POP3/IMAP na routeru. SMTP (exim) by naslouchal na všech rozhraních (WAN,LAN) a POP3/IMAP (dovecot) by naslouchal pouze na rozhraní LAN (192.168.1.1). Klienti v síti LAN by měli nastaven záznam v DNS brana.firma.cz = 192.168.1.1. OpenVPN server nastavit pro push "dhcp-option DNS x.x.x.x", ovpn klienti dostanou adresu pošty z LAN rozhraní, SMTP a POP/IMAP jim potom funguje přes ovpn tunel.