Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 59 60 [61] 62 63 ... 375
901
Server / Re:Mail u sebe doma
« kdy: 30. 10. 2021, 11:11:14 »
Tak nějak jsem si to myslel, že to je buď problém, který se může objevit kdekoli a je na providerovi nezávislý a nebo jde o vyloženě okrajové záležitosti, ke kterým při nějakém rozumném setupu nedojde.
Aha, takže problémy, které podle zdjších komentářů neexistují, se najednou mohou objevit kdekoli. Zajímavé. Ano, uvedené problémy se mohou objevit kdekoli – ale u provozovatele, který spravuje velké množství schránek, už se ty problémy projevily a on má vybudované mechanismy, jak je co nejdřív rozpoznat a zablokovat. Stejně tak je pravda, že je potřeba mít poštovní server a jeho prostředí rozumně nastavené. Ale to já tady tvrdím celou dobu, zatímco oponenti tvrdí, že poštovní server prakticky nejde nastavit špatně, že stačí postupovat podle návodu a tím pádem server nebude open relay, takže je všechno v pořádku.


Ono obecně jste si půlku reakce mohl odpustit, protože dostat se do webmailu neznamená dostat se mimo prostor webového serveru, natož měnit nějaká serverová nastavení.
Jenom je škoda, že jsem o webmailu ve skutečnosti napsal jenom to, že i v něm může být chyba.

Pak ta zmínka o vylepšení konfigurace je jen takové plácnutí do vody, protože fakt nevidím, jak by k ní ve vámi vyjmenovaných případech mohlo dojít.
No to je právě ten problém, že tu o konfiguraci poštovního serveru píšou lidé, kteří nevědí, co by mohlo být špatně. Tak třeba bude chtít tazatel posílat e-maily z nějakých IoT zařízení, která neumí autentizaci nebo je její konfigurace pracná Tak povolí odesílat e-maily z lokální sítě bez autentizace. Nebo to povolí pro lokální počítač, protože bude chtít odesílat e-maily skriptem nebo z lokální aplikace. A už se ten server pomalu otevírá…

Sice se tu snažíte všem vysvětlit, jak nezvládnou provozovat poštovní server, ale sám nedokážete napsat konkrétní scénář, který by ukázal proč. A nemusíte se o to snažit, protože cokoli, co si vycucáte z prstu, už je něco, co musíte odargumentovat a to vám teda nejde.
Problém je v tom, že nejde o pár konkrétních scénářů. Jde o to chápat celek a umět posoudit, jak nebezpečné jsou které oblasti toho celku. Jinak konkrétní scénáře jsem uváděl a reakce na to jsou „no a proč by zrovna tenhle konkrétní scénář měl nastat“.

902
Server / Re:Mail u sebe doma
« kdy: 30. 10. 2021, 10:53:12 »
Vsechny vyjmenovane vektory utoku jsou zcela ortogonalni k existenci instance MTA instalovane a spravovane tazatelem a muzou nastat zcela se stejnou pravdepodobnosti ve spojitosti s vnejsi instalaci a spravovanim od kohokoliv jineho.
Aha, to jste mne špatně pochopil. Já jsem nikdy netvrdil, že problém je v uživateli WIFT. Problém je ve znalostech a zkušenostech, které má správce serveru, a také v času, který správě serveru věnuje. Kdyby měl WIFT znalosti a zkušenosti provozovatelů komerčních řešení, tak se tady takhle neptá. A čas chce také asi trávit i něčím jiným, než správou poštovního serveru.


Nebylo by jednodussi pane Jirsaku, doporucovat vsem uzivatelum roota zcela generickou a vsespasnou radu, aby pocitac vubec nepouzivali, nezapojovali do site, ani do te elektricke, vubec nezapinali, hlavne ani nevlastnili a nedejboze aby se na ne dovolili vubec podivati v obchodech a behem rodinnych navstev?
Já jsem ale nepsal, že WIFT domácí server nemá provozovat. Já jsem jenom popsal, co to znamená provozovat poštovní server – a je na WIFTovi, aby zvážil, jestli to chce dělat nebo ne.

903
Server / Re:Mail u sebe doma
« kdy: 29. 10. 2021, 23:30:52 »
Pořád tu melete něco o rozesílání spamu. Tak mi řekněte, nastavím si svůj email pomocí iRedMail, budu ho používat třeba jen já a moje žena. Ven půjde jen SMTP port, IMAP a webmail. Jak tenhle setup může ohrozit konzistenci emailových služeb celého světa? Open relay z toho není by default, jen stěží nám utečou přihlašovací údaje, přímý útok na webmail je spíš ze světa SciFi, zvlášť, když to je aktualizovaná instance a útok přes samotné zprávy je ještě vzácnější. O všech tu prohlašujete, že tomu nerozumí, tak mi prosím nadhoďte pár příkladů, jak takovýto emailový server může začít rozesílat spam a ohrožovat tím své okolí? Ta šance u takhle malých instancí je úplně mizivá. I na serveru s tisícovkou uživatelů jsme takovéto incidenty řešili jen párkrát do roka.
Největší problém je to, že máte utkvělou představu, že server musí být open relay, aby přes něj někdo rozesílal spam. Na tom serveru můžete mít jinou děravou webovou aplikaci (nebo jinou aplikaci), můžete mít špatně nakonfigurované posílání nedoručenek, díru ve webmailu bych rozhodně nepovažoval za sci-fi. Vy nebo vaše žena můžete mít napadený počítač. No a že to není open relay by default, to neznamená, že nebude někdo vylepšovat konfiguraci a server neotevře, třeba jen trochu. Zejména když se na fóru dočte, že to přece nic není a nemůže se nic stát.

904
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 29. 10. 2021, 17:30:20 »
Někteří tu tvrdili, že fabuluju. No, tak po měsíci se nám tu urodil dotaz, kde se ukázalo, že ISP přesně tohle dělá – unáší DNS provoz na svůj resolver. Aby to bylo ještě lepší, neunáší veškerý DNS provoz, ale jenom provoz směrovaný na vybrané otevřené DNS resolvery. Z výpisů je tam i vidět, o kterého ISP se jedná, tak se zdejší hrdinové mohou ISP zeptat, proč to dělá.

905
Server / Re:BIND nepřekládá některé domény
« kdy: 29. 10. 2021, 17:21:53 »
Chapu to spravne, ze ISP mi teda unasi dns provoz, kdyz se chci ptat googlu nebo quad9?
Ano, předpokládám, že váš ISP unáší DNS provoz směrovaný původně na vybrané otevřené DNS resolvery. Je možné, že je dříve nastavoval klientům, a nebo to prostě dělá preventivně. Čtyři jedničky jsou mladšího data, takže je možná do seznamu unášených adres ještě nepřidali.

To vysvětluje, proč se při použití resolveru od Google nebo IBM chová stejně chybně, jako když použijete DNS vašeho ISP. Nicméně to pořád nevysvětluje, proč dostáváte ty chybné odpovědi. Vypadá to ale na chybu DNS resolveru vašeho ISP – tipoval bych to na nějaký problém s validací DNSSEC. Když použijete „obyčejného“ DNS klienta, ten DNSSEC validaci nevyžaduje a vše projde. Když použijete Bind, ten si DNSSEC validaci vyžádá, DNS resolver vašeho ISP něco pokazí a vrátí odpověď, že doména neexistuje.

Nabízelo by se vypnou v Bindu DNSSEC validaci, čemuž bych se ale snažil vyhnout, zejména když váš ISP do DNS provozu zasahuje a kazí ho. Nechal bych tam teď nastavené ty čtyři jedničky, a souběžně s tím to bude chtít řešit s vaším ISP, protože chyba je s největší pravděpodobností u něj.

906
Server / Re:BIND nepřekládá některé domény
« kdy: 29. 10. 2021, 13:21:09 »
Zkuste přes uvedené resolvery a také přes resolver vašeho ISP přeložit adresu ze seznamu nepovolených internetových her, třeba thelotter.com. Všechny otevřené resolvery by to měly překládat na jejich opravdové IP adresy, tj. 107.154.132.27 a 107.154.133.27. Váš ISP by to měl přeložit na jinou adresu, kde zobrazí stránku se zákazem přístupu. Takhle si snad vyzkoušíme, zda váš ISP neunáší DNS provoz i pro jiné servery. Je totiž zvláštní, že dostáváte odpověď NXDOMAIN pro existující jméno od různých serverů. Chápal bych, kdyby odpověď vůbec nedorazila, byl problém s fragmentací nebo něčím takovým. To by ukazovalo na problém někde u vás. Ale když dostanete odpověď NXDOMAIN, musí vám tu odpověď někdo poslat. A servery Google i IBM na ten název san.ev11958.ikea.com.edgekey.net normálně odpovídají.

907
Server / Re:Mail u sebe doma
« kdy: 28. 10. 2021, 19:17:17 »
Tohle pravidlo mi smysl dává, jelikož znám také pravidlo, které dle mě i najdeš v RFC, že když někdo vrátí temporary error s určitým stavovým kódem, máš to zkoušet dál.

To jaké kroky směřují k "pouhému" temporary erroru, mě tak nějak nezajímají, když se tak nebude dít u naprosto každé zprávy co pošlu v průběhu času.
Zkuste nad tím ještě chvíli přemýšlet. Chápu, je to pro vás komplikované, jsou tam dvě věci – ale když se budete soustředit, tak to rozlišíte. Jedna věc je pravidlo, druhá věc je činnost po nesplnění toho pravidla. Znovu připomínám, že já kritizuju pravidlo, o té činnosti jsem nenapsal ani čárku.

Princip toho, že neznámé servery na prvním připojení odpálkuješ stavovým kódem, který říká ať to zkousíš znovu, je právě greylisting. Pletu se?
Pletete se v tom, že tohle pravidlo vyhledává neznámé servery. To pravdilo testuje něco jiného.

908
Server / Re:Mail u sebe doma
« kdy: 28. 10. 2021, 19:13:39 »
Muzete s tim nesouhlasit, ale to je tak vsechno. Pravidla sveho serveru si urcuji ja
Já jsem ale nepsal, že s tím nesouhlasil. Já jsem pouze konstatoval, že je to jeden z důkazů, že fungování e-mailu nerozumíte. A upozorňoval jsem tazatele, že jste důkaz mého tvrzení, že poštovní servery občas spravují lidé, kteří tomu nerozumí – a on se s takovými servery bude muset při provozu svého serveru potýkat.

Ve vedlejší diskusi se řešilo, jaká jsou pravidla pro správnou konfiguraci poštovního serveru. Podobní „správci“ jako vy tvrdili, že je to pár pravidel, podle kterých stačí server nakonfigurovat (přičemž ta pravidla nedokázali sepsat…) Vy jste perfektní ukázka toho, že to není pravda. Někdo může mít server nakonfigurovaný bezchybně, a vy ho stejně za konfiguraci penalizujete a pošlete na greylist. Kdyby konfiguraci rozbil, budete spokojen a greylistu se asi vyhne. No a podobní „experti“ jako vy v podobných případech nepoužívají greylisting, ale třeba přidají za tuhle správnou konfiguraci pár negativních bodů do spam skóre, nebo e-mail rovnou odmítnou.


Toto pradavne pravidlo (mit existujici MX zaznam i pro odchozi emailovou branu) pochazi z doby pred SPF pro otagovani hosta privilegovaneho k odesilani emailu (skrze jiny kanal - DNS) a jeho rozliseni od ostatnich hostu pod danou domenou, ktere k odesilani mailu urceny opravdu nejsou. Spravci emailu tohle pouzivali a jedna se o jedno z mnoha nepsanych pravidel co nemaj RFC, ktere muzete nasadit pro boj se spamem. Ze to nemuzete nasadit jako striktni deny, je snad jasny z podstaty veci.
Ne, takovéhle pravidlo se nikdy nějak masivněji nepoužívalo. Navíc kdyby někdo přizpůsobil nastavení serveru tomu vašemu pravidlu, rozbije tím jinou kontrolu, která dává daleko větší smysl – totiž kontrolu, zda pro doménu odesílatele je kam doručovat e-maily, např. odpovědi nebo chybové zprávy. Vy ovšem chcete provozovatele jiný serverů donutit, aby nastavili MX záznamy i pro domény, kde žádné schránky nejsou, takže uvedená kontrola se stane neúčinnou.

Nuz, RDa je velice spokojenej se svym serverem a hromadou vlastnich custom scriptu, ktere odpinknou jakehokoliv hosta, ktery se jim kvuli necemu nelibi. At uz je to cizokrajni TLD, vysoka entropie jmena schranky, nebo cokoliv jinak podivneho. Je to valka (se spamem) a mit obranu zakazany neni. Navic kazde reseni, ktere neni sablonovite okopirovane, je k prospechu veci - protoze obejit ruzne divna pravidla se spammerum nevyplati - kdezto veci jako SPF a DKIM uz maj davno v malicku.
Ještě napište, kolik procent spamu zastavíte, a bude to vypadat, že vaše komentáře píšu já, abych potvrdil, že takoví „správci“ opravdu existují.

Pokud to zhrnu, tak jste do tohoto vlakna neprispel nicim konstruktivnim. Proc sem prispivate, kdyz nic nespravujete a ani se nepodelite o to, co jsou ty vase teoreticke good-practices z oblasti SMTP ?
Dotaz byl, jaké máme zkušenosti s provozem poštovního serveru a jaký s tím bude voser. Na to já jsem odpověděl a pak jsem vás donutil se odkopat, aby tazatel viděl, že si nevymýšlím.

909
Server / Re:Mail u sebe doma
« kdy: 28. 10. 2021, 18:38:09 »
Dopytle, co by měl řešit, vždyť server RDa vrátil temporary error a při dalších pokusech to pustí..  :o
Třeba to, že RDa nerozumí tomu, k čemu slouží MX záznamy, a chce poučovat ostatní, jak mají konfigurovat poštovní server. To, že po nesmyslné kontrole vrací temporary error, není omluva. Problém není v návratovém kódu, problém je v nesmyslné kontrole.

Greylisting je běžně užívaná a účinná praktika, jak bojovat se stroji, co jen posílají jeden bordel za druhým a nedrží maily v queue pro pozdější doručení.
Kritizoval jsem snad něco na greylistingu?

S takovym pristupem by nikdy nevznikl zadny program, vyrobek ani sluzba.
Já jsem snad někde psal, že nikdo nemá stavět nový poštovní server? Já jsem jenom psal, že provoz poštovního serveru není tak jednoduchý, jak to na první pohled vypadá. Že může člověk snadno skončit jako RDa, který si myslí, jak tomu rozumí, myslí si, že je mistr světa a může poučovat správce serverů, které za den doručí víc e-mailů, než jeho server za celý život – a přitom ani nechápe, jak fungují MX záznamy.

A vira, ze v korparatu tomu rozumeji vic je usmevna.
Psal jsem snad něco o korporátu?

910
Server / Re:Mail u sebe doma
« kdy: 28. 10. 2021, 15:40:37 »
Ucastnim se teto diskuze, protoze provozuji vlastni server pro par domen.
Což bohužel nezaručuje, že problematice rozumíte.

Na rozdil od vas, kdyz vy nejste schopen ani sledovat trendy, natoz neco nakonfigurovat a provozovat!
Kecy.

Mam za to, ze ani jedna z techto adres nepatri regulernimu MTA, natoz aby to byl nejaky IP pool cloudoveho providera - podle vasich predstav.
Takze veskere snahy o teoretizovani nad tim, ze odesilajici a prijimaci server jsou ruzne a nelze je identifikovat jsou totalne mimo misu.
Kde tam  máte jaké MX záznamy? Možná provozujete vlastní server, ale nerozumíte tomu, co se tam doopravdy děje. Tvrdíte nesmysl, pak předložíte výpis, který nic takového (logicky) nedokazuje.

Takova je realita dnesniho mailoveho spamu - jsou to vyhradne botnety - bezici at uz na deravych win, nebo IOT zarizenich.
Nejsou to výhradně botnety. Sám z toho logu vidíte, že jsou to známé IP adresy, které už jsou na blocklistu. Ty blokujete, takže by vám neměl chodit žádný spam. Což se ale neděje, že…

protoze odesilatel pouziva randomizovanou skoro-spamovaci adresu
Byly tady dotazy, jaká šílená pravidla používají různí „takysprávci“ pro blokaci „spamu“. Když jsem psal, že jsou to třeba pravidla založená na názvu serveru, někteří se tu ohrazovali, že je to nesmysl. No, tak tady máme jeden konkrétní případ. Sice ty e-maily rovnou neblokuje, ale za znak spamu to považuje.

Recipient address rejected: No MX exists for your server (web01.groups.io), fix it for faster delivery or just try again later
A tady máme další příklad. Proč by měl mít DNS název, pod kterým neexistují žádné e-mailové adresy, MX záznam?

Kdyby pouzivali jednoznacnou emailovou adresu, tak nebudou spozdeni na kazdem pokusu, ale jenom na prvnim pro kazdou IP ze sveho poolu. Na tomto nesou tedy svoji vinu ale ve vysledku je mira kompromisu akceptovatelna - nejedna se o casove kriticky provoz - na to email nikdy staven nebyl - ani teoreticky ani prakticky.
Takže RDa, který nerozumí ani tomu, jak fungují MX záznamy, tady tvrdí, že správci poštovních serverů eBay nebo LinkedIn problematice nerozumí, zatímco RDa tomu rozumí lépe. Aha.

Takže to je odpověď pro WIFTa – představte si, že budete přes váš server potřebovat doručit e-mail na server, který spravuje RDa. Chcete něco takového řešit?

911
Server / Re:BIND nepřekládá některé domény
« kdy: 28. 10. 2021, 15:03:57 »
Vidím tam akorát rozdíl, že Bind dostává odpověď s DNSSEC, zatímco ten dotaz z vaší sítě dostává odpověď bez DNSSEC. Ale rozdíl v dotazu tam žádný nevidím, možná by bylo něco vidět v nějakém podrobnějším výpise.

Každopádně mi ale připadá divné to chování serveru unhfree.czf. Nevidím tam žádný důvod, proč by měl pro to dlouhé jméno vrátit NXDOMAIN. Zkuste ten Bind nasměrovat na jiný server – 8.8.8.8, 9.9.9.9, 1.1.1.1 nebo ODVR CZ NICu.

912
Server / Re:BIND nepřekládá některé domény
« kdy: 28. 10. 2021, 14:33:03 »
Tohle je ale jiná komunikace. Zeptejte se na ten název san.ev11958.ikea.com.edgekey.net, na který se ptá Bind.

913
Server / Re:BIND nepřekládá některé domény
« kdy: 28. 10. 2021, 14:06:48 »
Kód: [Vybrat]
13:32:09.268401 IP ns.unhfree.czf.domain > ktk.unhfree.czf.38279: 47353 NXDomain* 0/0/1 (61)
Tohle je divné, ten server unhfree.czf vám vrací, že záznam neexistuje. Zkuste pomocí dig dotaz přímo na ten server ns.unhfree.czf, jestli dostanete stejnou odpověď.

914
Server / Re:Mail u sebe doma
« kdy: 28. 10. 2021, 13:52:28 »
Drtivou vetsinu spamu neposilaji spravne nakonfigurovane emailove servery (lze to poznat napr. podle toho, ze tam neni MX, zadny ID serveru, atd). Kdyby jste provozoval MTA, tak by jste to vedel. Nechapu proc se ucastnite diskuze, kdyz o dnesni realite nemate jakekoliv tuseni. Jste pouhy teoretik, a to jeste velice spatnej.
Počítač, který odesílá e-mail z nějaké domény, nemusí být ten samý, který e-maily přijímá. DNS server vám nemusí vracet všechny možné MX záznamy, takže i když ten počítač může e-maily pro danou doménu přijímat, nemusíte to podle MX záznamů poznat. Nechápu, proč se účastníte diskuze, když o e-mailových protokolech nevíte vůbec nic.

Mimochodem, správně nakonfigurovaný poštovní server samozřejmě spam nerozesílá (pokud to není pár zpráv, které pošle   oprávněný uživatel). Jenže tady se právě bavíme o tom, jak ten server nakonfigurovat a provozovat správně.

915
Server / Re:BIND nepřekládá některé domény
« kdy: 28. 10. 2021, 13:02:10 »
Ten Bind je nakonfigurovaný, aby dotazy vyřizoval sám, nebo je přeposílá na nějaký nadřazený DNS resolver, třeba ten od ISP? Jaké dotazy Bind skutečně odešle a jaké odpovědi dostane? Odchytil bych dotazy a odpovědi na vnějším rozhraní tcpdumpem, ať víme, jaká komunikace tam doopravdy probíhá.

Stran: 1 ... 59 60 [61] 62 63 ... 375