Fórum Root.cz
Hlavní témata => Server => Téma založeno: Tomáš Smutný 03. 02. 2017, 16:45:57
-
Ahoj rooťáci :D
Mám dotaz jestli nevíte jak google, popřípadě jestli řeší, či jestli někdo komunikoval s podporou u placené služby ( což nemám ) ohledně ležících ip v SORGS DB , jelikož máme dost problém s doručování z ip adress Gmail. Dost jich leží v DB spamerů a tím pádem všechno padá do spamu nebo vrací a podobně a zdá s emi ýt dost nesystémové že říct co je z googlu spam není. Ať si to vyřeší.
Dopředu dík za reakce
Dík a pokud dotaz byl na tolik trapný, že tu nemá co dělat tak se za něj omlouvám :D
-
Jestli to chápu správně, řešíte problém, že správce nějakého poštovního serveru používá nějaký blacklist pro tvrdé odmítání e-mailů, a vaše e-maily se nedoručují adresátům toho poštovního serveru. A shodou okolností se vám nedoručují ani e-maily poslané přes GMail, protože i servery GMailu jsou na tom blacklistu.
Jediné, co s tím můžete dělat, je poslat e-mail dotyčnému správci a nějak slušně se mu pokusit vysvětlit, že to, co dělá, je nebetyčná hloupost, protože na těchhle seznamech je směs všech možných adres, včetně velkých hráčů jako GMail, Seznam nebo MailChimp (a pokud na nějakém seznamu nejsou zrovna teď, byly na něm v minulosti a budou v budoucnosti). Takže tím blokováním pouze přichází o legitimní poštu. Provoz těch blacklistů je většinou akorát byznys, kdy si provozovatel nechává platit za rychlé odstranění z blacklistu.
Případně pokud je to nějaký server, kde mají uživatelé na výběr (freemail, e-mail ISP), doporučte adresátům, ať přejdou k jinému provozovateli e-mailového serveru, freemailů je k dispozici dost.
-
Tak on to není nějaký blacklist, ale je to SORBS, který je široce používaný. Řešili jsme podobný problém a obesílat (v našem případě) jen v Německu stovky administrátorů mi nepřijde jako dobré řešení :) Jak z toho nevím...
-
Tak on to není nějaký blacklist, ale je to SORBS, který je široce používaný.
Pokud někdo používá podobně debilní blacklist (a to ještě ke všemu k tomu, aby poštu natvrdo odmítal), tak holt nebude poštu dostávat. Nevím, co na tom řešíte.
-
používám sorbs, ale mám natvrdo whitelist s asi 70položkami, na kterém jsou krom velkých hráčů (google, mailchimp, seznam..) i různé jiné, které jsme provozem identifikovali jakožto "velcí", kteří by na sorbs neměli být. Funguje to velice hezky. Na ty tedy neaplikujeme reject, když na seznamu jsou, ale pouštíme na ně zbytek testů
-
Tak on to není nějaký blacklist, ale je to SORBS, který je široce používaný.
Ano, to je přesně jeden z těch blacklistů, o kterých jsem psal. Pokud ho někdo používá, asi nechce dostávat e-maily. Jeden takový exemplář máte o příspěvek výše.
Řešili jsme podobný problém a obesílat (v našem případě) jen v Německu stovky administrátorů mi nepřijde jako dobré řešení :) Jak z toho nevím...
Na straně odesílatele nijak. Jediné řešení by bylo vybudovat blacklist těch, kteří na příjmu tyhle blacklisty používají – a pak by se musela najít dostatečná masa serverů, které by na servery na tomhle blacklistu vůbec nedoručovaly. Když e-maily nechtějí, tak je nechtějí. Jenže to je nereálné, protože velké hráče to netrápí – ty mají tihle „správci“ na whitelistu (a nedojde jim, že je na tom blacklistu asi něco špatně, když musí tyhle servery whitelistovat).
-
Tak on to není nějaký blacklist, ale je to SORBS, který je široce používaný.
Pokud někdo používá podobně debilní blacklist (a to ještě ke všemu k tomu, aby poštu natvrdo odmítal), tak holt nebude poštu dostávat. Nevím, co na tom řešíte.
Nevím, co řešíte Vy. Není to nějaký obskurní blacklist, který využívají 4 servery v Ugandě, ale je široce používaný po celém světě. Můžu si o jeho fungování myslet, co chci, ale když pak nechodí maily na půlku německých domén, tak mě prostě zákazník nepochválí a je mu jedno, že skoro všichni administrátoři v Německu jsou "debilové"...
-
Není to nějaký obskurní blacklist, který využívají 4 servery v Ugandě, ale je široce používaný po celém světě.
Je to obskurní blacklist široce používaný po celém světě.
Můžu si o jeho fungování myslet, co chci, ale když pak nechodí maily na půlku německých domén, tak mě prostě zákazník nepochválí a je mu jedno, že skoro všichni administrátoři v Německu jsou "debilové"...
Vy nemůžete ovlivnit, jestli vaše IP adresy na tom blacklistu budou nebo nebudou. Můžete nabídnout prémiovou službu, že budete udržovat dostatečně velký pool IP adres z různých sítí po celém světě, abyste zvýšil pravděpodobnost, že některá z těch adres na blacklistu nebude. Ať si zákazník vybere, zda se mu vyplatí posílat e-maily i těm, kteří je nechtějí.
-
Tak on to není nějaký blacklist, ale je to SORBS, který je široce používaný.
Pokud někdo používá podobně debilní blacklist (a to ještě ke všemu k tomu, aby poštu natvrdo odmítal), tak holt nebude poštu dostávat. Nevím, co na tom řešíte.
Nevím, co řešíte Vy. Není to nějaký obskurní blacklist, který využívají 4 servery v Ugandě, ale je široce používaný po celém světě. Můžu si o jeho fungování myslet, co chci, ale když pak nechodí maily na půlku německých domén, tak mě prostě zákazník nepochválí a je mu jedno, že skoro všichni administrátoři v Německu jsou "debilové"...
Emailové služby nejsou z principu věci spolehlivé, to je třeba chápat. A pak je nutné pochopit a zákazník musí pochopit, že odesílat firemní komunikaci k free emalu nějakého google je prostě konina která nikdy nebude fungovat, nemůže spolehlivě fungovat a nedá se vyřešit. Když odesíláš emaily z té samé adresy jako dalších tisíc spamerů tak se prostě objeví na black listu.
To se stává všem veřejným emailům a neni to chyba blacklistu ani toho příjemce co ho používá - je to chyba odesílatele který nechápe nutnost vlastního emailového řešení.
Jediné řešení je používat vlastní emailový server s vlastní adresou a ohlídat si aby se na blacklistech neobjevila.
-
Jediné řešení je používat vlastní emailový server s vlastní adresou
Jeden server s jedinou IP adresou bude na blacklistování mnohem náchylnější, než velký freemail s větším množstvím serverů
ohlídat si aby se na blacklistech neobjevila.
To by mne zajímalo, jak si to chcete ohlídat. Provozovatel blacklistu vás na něj může zařadit bez ohledu na to, co si to tom myslíte, zda o blacklistu vůbec víte nebo co děláte. Pravidla pro zařazení na takové blacklisty jsou velmi obskurní a zahrnují věci, které nemůžete ovlivnit. Podívejte se třeba na ten SORBS, jaké tam mají databáze – a když už je nějaký administrátor používá pro odmítání e-mailů, určitě použije rovnou dnsbl.sorbs.net.
-
Mám dotaz jestli nevíte jak google, popřípadě jestli řeší, či jestli někdo komunikoval s podporou u placené služby ( což nemám ) ohledně ležících ip v SORGS DB , jelikož máme dost problém s doručování z ip adress Gmail.
Zrovna řeším to samé, ale řešení přes podporu Googlu má nulový význam.
SORBS is a third-party database of IP addresses which some domains use to identify and block spam email from reaching their users. From time to time in the past, SORBS has blacklisted Google's IPs in its databases, causing recipients at domains using SORBS to block messages sent by our Enterprise Google Mail customers. After investigating further, I have confirmed that there is a range of Google IP addresses that SORBS has blacklisted and has not yet agreed to remove, despite our attempts at negotiating with them to do so.
To move forward, I recommend that you contact the recipient and request them not to block Gmail IP addresses based upon SORBS. They can use SORBS to filter mail into a spam folder, but blocking SMTP traffic at the network level due to SORBS can cause the issues you have encountered, impossible to overcome from the sender’s side.
As you will not be sending out mail from the same IP address each time and as a limited number of recipients use SORBS, it is unlikely that this issue will crop up often in the future. However, note that we have no control over SORBS blocks of domain IPs or G Suite server IPs. For more information about this issue, please see the Google Help Center article at https://support.google.com/mail/answer/26904
Moc řešení této situace není, pokud se nedomluvíte se správcem serveru, který SORBS používá k odmítání emailů, pak prostě maily těm adresátům chodit nebudou. Jen to musíte nějak vysvětlit tomu od koho email mířil.
-
Jediné řešení je používat vlastní emailový server s vlastní adresou
Jeden server s jedinou IP adresou bude na blacklistování mnohem náchylnější, než velký freemail s větším množstvím serverů
A zase Jirsákův teoretický žvást! V praxi to mám ověřené přesně naopak - pokud ze serveru chodí méně mailů je mnohem méně náchylný na zařazení na reálné blacklisty. Pokud z něj mají povoleno odesílat maily pouze zodpovědní uživatelé tak ta pravděpodobnost dále klesá, v praxi limitně k nule pokud se navíc omezí počet povolených odeslaných mailů od každého uživatele denně (to kvůli případnému napadení jejich počítačů spamovacím malware).
-
pokud ze serveru chodí méně mailů je mnohem méně náchylný na zařazení na reálné blacklisty
Jak přesně počet odeslaných e-mailů ovlivňuje to, zda bude IP adresa zařazena na blacklist např. podle svého jména dle reverzního DNS záznamu?
-
pokud ze serveru chodí méně mailů je mnohem méně náchylný na zařazení na reálné blacklisty
Jak přesně počet odeslaných e-mailů ovlivňuje to, zda bude IP adresa zařazena na blacklist např. podle svého jména dle reverzního DNS záznamu?
Menší počet odeslaných mailů znamená menší pravděpodobnost že si jich všimne provozovatel nějakého blacklistu a následně IP adresu odesílajícího SMTP serveru označí jako blokovanou protože ty maily nějakým svým algoritmem vyhodnotí jako spam. Vazba tohoto faktu na reverzní DNS není žádná.
-
Menší počet odeslaných mailů znamená menší pravděpodobnost že si jich všimne provozovatel nějakého blacklistu a následně IP adresu odesílajícího SMTP serveru označí jako blokovanou protože ty maily nějakým svým algoritmem vyhodnotí jako spam. Vazba tohoto faktu na reverzní DNS není žádná.
Takže počet odeslaných e-mailů nemá vliv na to, že vás provozovatel blacklistu zařadí do databáze na základě toho, že se mu nelíbí jméno v reverzním záznamu vaší IP adresy a nějakým svým algoritmem vyhodnotí, že to jméno svědčí o dynamicky přidělované IP adrese. Myslím, že to už jsem psal, ne?
Jinak větší počet odesílajících serverů znamená, že i když se některý z nich dostane na blacklist, ostatní pořád mohou doručovat. A větší počet odesílaných e-mailů znamená, že správce cílového serveru bude mít průšvih a přidá alespoň ten velký server na whitelist. Vždyť to tady jeden „správce“ poštovního serveru na začátku psal – na whitelist dává servery, které odesílají hodně e-mailů, ne ty, které jich odesílají málo nebo ty, které mají lepší opatření proti spamu.
-
ohlídat si aby se na blacklistech neobjevila.
To by mne zajímalo, jak si to chcete ohlídat. Provozovatel blacklistu vás na něj může zařadit bez ohledu na to, co si to tom myslíte, zda o blacklistu vůbec víte nebo co děláte. Pravidla pro zařazení na takové blacklisty jsou velmi obskurní a zahrnují věci, které nemůžete ovlivnit. Podívejte se třeba na ten SORBS, jaké tam mají databáze – a když už je nějaký administrátor používá pro odmítání e-mailů, určitě použije rovnou dnsbl.sorbs.net.
Toto je hlavne problém gmail, hotmail, a podobných služieb - zaradia Vás na nejaký svoj interný obskúrny blacklist a to nielen IP, ale kľudne celú doménu a potom nie je ako sa z toho blacklistu dostať. Navážate sa tu do SORBS a ďalších verejných blacklistov, ale väčšinou aspoň majú popísané pravidlá ako (za čo) sa na blacklist dostať, ako sa dostať z neho preč, ako overiť či na blackliste som a hlavne je použitie týchto blacklistov dobrovoľné. Tieto súkromné špehovacie rádoby-zadarmo maily ako gmail a spol. majú zverejnené len všeobecné žvásty a bežný admin sa s nimi musí nedobrovoľne potýkať či chce alebo nechce, pretože tieto služby sú príliš veľké aby sa dali ignorovať.
-
Toto je hlavne problém gmail, hotmail, a podobných služieb - zaradia Vás na nejaký svoj interný obskúrny blacklist a to nielen IP, ale kľudne celú doménu a potom nie je ako sa z toho blacklistu dostať.
Měl byste nějaký konkrétnější příklad? Já jsem neslyšel o žádném takovém příkladu, že by někdo byl na takovémhle blacklistu. Znám případy, kdy byly jednotlivé e-maily vyhodnocovány jako spam, ale to není blacklist.
väčšinou aspoň majú popísané pravidlá ako (za čo) sa na blacklist dostať
Jo, například „generic reverse DNS naming is the most important criterion“. To vám hodně pomůže, takovýhle popis.
ako sa dostať z neho preč
Což je postavené na hlavu. O vymazání by se měl postarat ten, kdo tam tu adresu přidal.
hlavne je použitie týchto blacklistov dobrovoľné
Proto jsem psal, že jediné skutečné řešení, které je ovšem velmi zdlouhavé, je vysvětlit správci cílového serveru, že používat takovýhle blacklist pro odmítání e-mailů je nesmysl. A že nejlepší by bylo, kdyby se dostatečné množství odesílatelů dohodlo, že na servery používající tyhle blacklisty prostě doručovat nebudou – když jejich správci e-maily přijímat nechtějí, tak jim je přece nebudeme nutit.
pretože tieto služby sú príliš veľké aby sa dali ignorovať.
Čemuž přispívají i ti uživatelé blacklistů, protože tyhle velké služby whitelistují, takže je často jednodušší použít takovouhle velkou službu než řešit problémy s nějakým správcem používajícím blacklist.
-
Menší počet odeslaných mailů znamená menší pravděpodobnost že si jich všimne provozovatel nějakého blacklistu a následně IP adresu odesílajícího SMTP serveru označí jako blokovanou protože ty maily nějakým svým algoritmem vyhodnotí jako spam. Vazba tohoto faktu na reverzní DNS není žádná.
Takže počet odeslaných e-mailů nemá vliv na to, že vás provozovatel blacklistu zařadí do databáze na základě toho, že se mu nelíbí jméno v reverzním záznamu vaší IP adresy a nějakým svým algoritmem vyhodnotí, že to jméno svědčí o dynamicky přidělované IP adrese.
Co to je zase za nesmyslnou konstrukci? SMTP server kterému má rozumně fungovat odesílání mailů přímo na cílové SMTP servery v internetu přeci dnes musí používat pouze statické IP adresy s rozumně nastavenými reverzními záznamy v DNS! Uvažovat o dynamicky přidělovaných IP adresách s pofidérními reverzními DNS záznamy může jen tragický teoretik jako například Jirsák.
Jinak větší počet odesílajících serverů znamená, že i když se některý z nich dostane na blacklist, ostatní pořád mohou doručovat. A větší počet odesílaných e-mailů znamená, že správce cílového serveru bude mít průšvih a přidá alespoň ten velký server na whitelist. Vždyť to tady jeden „správce“ poštovního serveru na začátku psal – na whitelist dává servery, které odesílají hodně e-mailů, ne ty, které jich odesílají málo nebo ty, které mají lepší opatření proti spamu.
Takže místo toho aby došlo k odstranění příčiny proč se IP adresy SMTP serverů na blacklisty dostávají (což je téměř vždy nevhodná konfigurace těch SMTP serverů která umožňuje odesílání spamu) tak se budou tvořit takovéhle komplikované teoretické myšlenkové konstrukce které stejně v praxi nefungují? Autora tohoto příspěvku bych spolehlivě poznal i kdyby se root.cz rozhodl příspěvky anonymizovat!
A ponaučení na závěr: reverzní DNS záznamy IP adres odesílajících SMTP serverů nejsou pro blacklisty důležité, protože blacklisty fungují přímo nad IP adresami (ty jsou totiž na rozdíl od reverzního DNS pro spammery mnohem hůř měnitelné).
-
Co to je zase za nesmyslnou konstrukci?
Co kdybyste se radši nejdřív dovzdělal, než se začnete takhle hloupě ptát?
SMTP server kterému má rozumně fungovat odesílání mailů přímo na cílové SMTP servery v internetu přeci dnes musí používat pouze statické IP adresy
Proč? Kvůli hloupým blacklistům? Navíc to, co jsem psal já, se týká i klientů (předpokládám, že jste se jen přepsal) se statickou IP adresou.
s rozumně nastavenými reverzními záznamy v DNS!
Co to je „rozumně nastavený reverzní záznam“? Ve kterém RFC je definován?
Uvažovat o dynamicky přidělovaných IP adresách s pofidérními reverzními DNS záznamy může jen tragický teoretik jako například Jirsák.
Kde jsem psal o dynamicky přidělovaných IP adresách s pofidérními reverzními DNS záznamy? Aha, nikde, to si jen „Admyn“ vymýšlí.
Takže místo toho aby došlo k odstranění příčiny proč se IP adresy SMTP serverů na blacklisty dostávají (což je téměř vždy nevhodná konfigurace těch SMTP serverů která umožňuje odesílání spamu)
Příčina je ta, že se někdo rozhodne a prostě nějakou IP adresu na ten seznam přidá. Se SMTP klientem (zase překlep, že) to často nemá vůbec nic společného, na té IP adrese ani nikdy nemusel být žádný SMTP klient provozován. Dokonce si vlastně nevzpomínám, že by mezi adresami, které jsem odstraňoval, někdy byla nějaká na blacklistu kvůli nevhodné konfiguraci SMTP klienta nebo kvůli tomu, že by se z té adresy rozesílal spam.
tak se budou tvořit takovéhle komplikované teoretické myšlenkové konstrukce které stejně v praxi nefungují? Autora tohoto příspěvku bych spolehlivě poznal i kdyby se root.cz rozhodl příspěvky anonymizovat!
A ponaučení na závěr: reverzní DNS záznamy IP adres odesílajících SMTP serverů nejsou pro blacklisty důležité, protože blacklisty fungují přímo nad IP adresami (ty jsou totiž na rozdíl od reverzního DNS pro spammery mnohem hůř měnitelné).
Několikrát tu byl zmíněn SORBS. Myslím, že není tak těžké dohledat si odkaz na jejich stránky. Myslím, že není tak těžké si na jejich stránkách najít seznam jejich databází (http://www.sorbs.net/general/using.shtml). Myslím, že není tak těžké zjistit si, že z 15 základních databází se jich pouze 4 týkají IP adres SMTP klientů.
A ponaučení na závěr: nepoučujte o věcech, o kterých vůbec nic nevíte.
-
Jediné řešení je používat vlastní emailový server s vlastní adresou
Jeden server s jedinou IP adresou bude na blacklistování mnohem náchylnější, než velký freemail s větším množstvím serverů
ohlídat si aby se na blacklistech neobjevila.
To by mne zajímalo, jak si to chcete ohlídat.
Tvojí odpověď beru jen jako trolling. Ale dobře, možná ses vrátil z Měsíce?
Začnu od konce dotazu. Pochopitelně, vždy je možné spadnout na spam list. Ale pokud je na IP adrese smtp server ze kterého odesílají poštu jen ověření uživatelé které znám, odesílají regulérní emaily a ne spam a pro jistotu limituji počet odeslaných emailů (firemní email) tak nebývá problém a případně je možné adresu z black listu vymazat.
A proč by byl server pod kontrolou výc náchylný ke spadnutí do blacklistu než veřejný smtp ze kterého odesílá kdovíkdo kdoví co to nevim.
-
Ale pokud je na IP adrese smtp server
Příště si raději přečtěte příspěvek, na který reagujete. Nebo o jakém SMTP serveru (asi jste myslel klienta) píšete, když je IP adresa na blacklistu kvůli reverznímu názvu v DNS nebo kvůli HTTP proxy?
-
Ja uz jsem skoro otviral sapansky, ze konecne tu zrudu nekdo zablokoval a ono nic =(
Si to clovek musi zablokovat sam.
https://github.com/StevenBlack/hosts
http://www.malwaredomainlist.com/mdl.php
-
Když už tak kritizujete blacklisty, tak může mi někdo z vás racionálně vysvětlit, proč z tak vámi oblíbených mail serverů odesíláte takové ... obtěžující jako třeba toto z centrum.cz?
Google, seznam pak nevyjímaje
http://www.spamcannibal.org/cannibal.cgi?page=lookup&lookup=46.255.225.252
rozklikněte Lookup a dostanete se k opravdu duchaplnému emailu, kterými po statisících zaplavujete z freemailů ostatní.
Proč k firemní komunikaci chcete používat něco, co je nekvalitní a nespolehlivé? Nedivím se, že vás ostatní blokují a hážou vás do spamu.
-
Na obranu sorbs, používám ten listing už dlouho a musím říct že je dost přesný a hlavně pro určení stavu velkých providerů a různých aktuálních útoků. I přestože jsem investigoval útoky speněžními škodamy a informoval o nich přesně několik velkých providerů, z nichž cca 50% ani neodpovědělo a 20% zůstávají infikováni léta a neřeší to, byl sorbs přesný a zalistoval je v aktuální čas provaru. Pokud má někdo nepořádek v síti tak prostě není hoden firemní komunikace, takže pro některé sítě je klidně akuální banovat to rovnou dle blacklistu. Jmenovitě třeba mout.kundenserver.de je naprosto tragický a za poslední 4 roky jsme od nich nepřijaly jediný email, i přes snahu o komunikaci a řešení z naší strany. Sorbs dost dobře předpověděl i problém s ukradenými účty na yahoo v aktuálí čas a ne až to přiznaly po X letech.
-
Na obranu sorbs, používám ten listing už dlouho a musím říct že je dost přesný a hlavně pro určení stavu velkých providerů a různých aktuálních útoků. I přestože jsem investigoval útoky speněžními škodamy a informoval o nich přesně několik velkých providerů, z nichž cca 50% ani neodpovědělo a 20% zůstávají infikováni léta a neřeší to, byl sorbs přesný a zalistoval je v aktuální čas provaru. Pokud má někdo nepořádek v síti tak prostě není hoden firemní komunikace, takže pro některé sítě je klidně akuální banovat to rovnou dle blacklistu. Jmenovitě třeba mout.kundenserver.de je naprosto tragický a za poslední 4 roky jsme od nich nepřijaly jediný email, i přes snahu o komunikaci a řešení z naší strany. Sorbs dost dobře předpověděl i problém s ukradenými účty na yahoo v aktuálí čas a ne až to přiznaly po X letech.
Děláte klasickou chybu – řešíte jenom jenom správně odfiltrovaný spam, ale vůbec neřešíte, o kolik legitimních e-mailů jste přišel. Pokud máte kritéria nastavená opravdu takhle a chcete zastavit spam za každou cenu, je nejlepší řešení vypnutí e-mailového serveru – tím zastavíte 100 % spamu.
Je trochu zvláštní, že tuhle chybu v uvažování dělají všichni obhájci blacklistů, které jsem potkal. Jako-by k využívání blacklistů vedla jenom neschopnost uvědomit si podmínky, které chci nastavit pro příjem e-mailů.
-
Je to chyba i nechyba, chyba je že se zablokuje i regulerní pošta. Nechyba je to, že útoky jdou od konkrétních providerů z konkrétních účtů, příjemce nemá jak jinak rozlišit, jestli za účtem stojí majitel nebo útočník. To ví pouze provider, ten má přístup do svých logů a umí komunikovat se svým zákazníkem. Proto blokace podle blacklistu je sice krutější, ale účinnější a nutí providery a uživatele řešit chyby. Taky je problém, že pokud to scoruje antispam a jede to podle hodnocení, tak se často nevygeneruje chybová zpráva odesílately a ten se ani nedozví že to nebylo doručeno.
-
blokace podle blacklistu je sice krutější, ale účinnější a nutí providery a uživatele řešit chyby.
No, já ti opravdu nic řešit nebudu. Pokud budeš mít poštu u podobného debila, tak ti řeknu, ať si zřídíš funkční email jinde nebo ať neočekáváš, že ti budou emaily chodit. (Již léta provozujeme, pokud si někdo stěžuje, že mu nechodí emaily na Yahoo nebo tam, kde provozují tuto hrůznou parodii na antispam (http://virusfree.cz/) (např. Centrum.cz (https://webtrh.cz/259832-centrum-experimentuje-maily).)
Řešit to možná budou tvoji uživatelé, přemístěním mailů k menšímu debilovi.
-
blokace podle blacklistu je sice krutější, ale účinnější a nutí providery a uživatele řešit chyby.
No, já ti opravdu nic řešit nebudu. Pokud budeš mít poštu u podobného debila, tak ti řeknu, ať si zřídíš funkční email jinde nebo ať neočekáváš, že ti budou emaily chodit. (Již léta provozujeme, pokud si někdo stěžuje, že mu nechodí emaily na Yahoo nebo tam, kde provozují tuto hrůznou parodii na antispam (http://virusfree.cz/) (např. Centrum.cz (https://webtrh.cz/259832-centrum-experimentuje-maily).)
Řešit to možná budou tvoji uživatelé, přemístěním mailů k menšímu debilovi.
Ak chce niekto poskytovat verejne sluzby, mal by sa starat aj o hladky a bezproblemovy chod serverov, nie len nasadit SPF / DKIM alebo DMARC a buzerovat ostatnych ze co vsetko musia moje servery pri komunikacii splnat aby ich servery na druhej strane vobec pustili ku slovu ale starat sa aj o to aby ich servery neobtazovali ludi.
Osobne by som kvoli nim ustupky nerobil, oni by si kvoli mojim serverom tiez neprevrtavali ich nastavenia aby moje maily boli k nim dorucene. Na druhu stranu musim podotknut ze ked som par krat nahlasil problem, sice mi nie stale odpovedali ale problemy sa vacsinou do par dni vyriesili.
Osobne tiez mam na jednom serveri blacklisty - presnejsie mam ich za sebou 10 (SORBS, UCEPROTECT, SPAMRATS a i.) a aj ku mne dojdu mesacne asi tri - styri spamove spravy. Pokial ma klient problem snazim sa mu pomoct a kontaktovat poskytovatela jeho mailovych sluzieb a byt napomocny pri rieseni problemu ale ak na mna z vysoka kadia (skusenost s madarskymi providermi), nech si to riesi odosielatel nedorucenej spravy, ak si za nieco zaplatil tak nech sa staraju alebo nech prejde ku niekomu kde systemaci vedia na zverenych serveroch udrziavat poriadok.
-
Osobne tiez mam na jednom serveri blacklisty - presnejsie mam ich za sebou 10 (SORBS, UCEPROTECT, SPAMRATS a i.) a aj ku mne dojdu mesacne asi tri - styri spamove spravy.
Tak jistě. Co na tom, že zmizí polovina emailů, které nejsou spamy. Jak psal Jirsák, se kterým výjimečně musím souhlasit - rovnou ten mailserver vypni.
-
Ale pokud je na IP adrese smtp server
Příště si raději přečtěte příspěvek, na který reagujete. Nebo o jakém SMTP serveru (asi jste myslel klienta) píšete, když je IP adresa na blacklistu kvůli reverznímu názvu v DNS nebo kvůli HTTP proxy?
Cist bys mel spis ty protoze vubec nechapes o cem se tu mluvi ... .
-
Tak jistě. Co na tom, že zmizí polovina emailů, které nejsou spamy. Jak psal Jirsák, se kterým výjimečně musím souhlasit - rovnou ten mailserver vypni.
Před dávnými a dávnými lety, ještě ve zlaté éře SpamAssassinu jsem se (anti)spamem docela zabýval. Dokonce jsem dělal i nějakou rozsáhlejší statistiku a vyšlo mi, že antispam založený na blacklistech sice zachytí asi polovinu spamů, ale rovněž odmítne čtyři procenta legitimních mailů. Takže polovina to není, ale i 4% jsou docela dost - je to každý 25 mail. Napsal jsem o tom článek a publikoval ho na Lupě, ještě by mohl být k dohledání.
Dnes čísla budou možná o něco jiná, ale nepředpokládám, že by se procento false positives nějak výrazně zlepšilo.
-
Cist bys mel spis ty protoze vubec nechapes o cem se tu mluvi ... .
Já to chápu. A vám by to možná došlo, kdybyste si kliknul na ten odkaz, který jsem uváděl, a podíval se, jaké jsou tam blacklisty. Je dost smutné, že ty blacklisty používají „správci“, kteří ani nevědí, co v nich je.
-
blokace podle blacklistu je sice krutější, ale účinnější a nutí providery a uživatele řešit chyby.
No, já ti opravdu nic řešit nebudu. Pokud budeš mít poštu u podobného debila, tak ti řeknu, ať si zřídíš funkční email jinde nebo ať neočekáváš, že ti budou emaily chodit. (Již léta provozujeme, pokud si někdo stěžuje, že mu nechodí emaily na Yahoo nebo tam, kde provozují tuto hrůznou parodii na antispam (např. Centrum.cz.)
Řešit to možná budou tvoji uživatelé, přemístěním mailů k menšímu debilovi.
Ok pak existuje druhá možnost, za potvrzený provar od providera v případě neochoty řešit své problémy je permaban jeho smtp, někteří si o to koledují, to by bylo asi pro ně horší než blacklist, kde si můžou přečíst co mají za problém. Blokaci dle sezonních problémů měním z new.spam.sorbs na recent.spam.sorbs, což jsou 48H a 30D blokace, samozdřejmě kdo tam dá celý dnsbl nemůže se pak divit. Můžu dokázat přímou korelaci mezi použitím filtrovaného scoringu a přímé blokace dle blacklistů. Druhý případ dokazatelně snižuje napadení našich klientů kvartálně z X desítek případů na max 5 případů, vše otestováno na 6 letém provozu. To je dost velký rozdíl. Navíc pokud má někdo napadený server, je vysoká šance, že regulérní pošta se je pouze pseudoregulérní a je to ukradený účet a nikdo kromě odesilatelova providera to není schopen prověřit.
Každý půlrok je zveřejněný únik milionů účtů od XY providera, jak dlouho si myslíš že trvá recover a změna hesel po takovém úniku.... Klidně i 2 roky se ještě velká část z těch účtů zneužívá a nikdo totálně nikdo to neřeší. Takový provider tedy nemá v globální komunikaci co dělat min po dobu problému.
-
Ok pak existuje druhá možnost, za potvrzený provar od providera v případě neochoty řešit své problémy je permaban jeho smtp
To asi neusnu. Prostě ten mailserver vypni, jeho uživatelé to určitě po zásluze ocení, počet napadení se určitě sníží na nulu a navrch se nebudou zdržovat čtením emailů od zákazníků.
;D ::)
-
jestli se konecne podari SJW utokem na sorbs odrovnat google, tak jim snad i za tenhle jeden jedinecny vykon podekuju.
-
Můžu dokázat přímou korelaci…
Tak dokazujte.
Snad se při tom dokazování dozvíme, proč je váš komentář tak zmatený a důsledně v něm spojujete věci, které spolu nijak nesouvisí. Blokace SMTP klientů dle IP adres a počty napadení asi klientských stanic, úniky účtů (asi úniky hesel u různých služeb – e-shopy, seznamky, fóra) a e-mailová komunikace…
-
Tak osobne si myslim, ze automaticku blokovat maily, ktore su na nejakom blackliste je kolosalna blbost.
Ak mozem poradit, tak nam sa v praxi osvedcilo toto:
1. Automaticky zahadzovat pripojenie na mailservry od ip adries, ktore nesplnaju podmienky SPF, DKIM alebo DMARC. Respektujete totiz to, co si zela majitel domeny, z ktorej prichadza email.
2. Vsetko ostatne ma mailserver prijat a poslat na antispamovy filter. Posta bude bud dorucena do schranky,alebo do slozky Spam. Nic sa automaticky nemaze. Uzivatelia si musia sami spamovu slozku mazat, su to ich spamy. Vo velkych firmach, kde by to mohlo sposobovat problemy je mozne nastavit, ze sa v spamovej slozke budu mazat emaily strarsie cca 2 mesiace.
Co sa tyka blacklistov,tak by mali mat iba poradny charakter. To znamena emailu priradit nejake body. Ale ak email neprekroci nejaku nastavenu hranicu bodov, od ktorej je povazovany za spam, tak dorucit do dorucenej posty.
-
Ok pak existuje druhá možnost, za potvrzený provar od providera v případě neochoty řešit své problémy je permaban jeho smtp
To asi neusnu. Prostě ten mailserver vypni, jeho uživatelé to určitě po zásluze ocení, počet napadení se určitě sníží na nulu a navrch se nebudou zdržovat čtením emailů od zákazníků.
;D ::)
Jasně klidně to vypnu, tolik desítek tiisíc firemních domén vesměs komunikuje mezi sebou a a provoz ven a z venku je max 50%, to se dá určitě překousnout.
-
Můžu dokázat přímou korelaci…
Tak dokazujte.
Snad se při tom dokazování dozvíme, proč je váš komentář tak zmatený a důsledně v něm spojujete věci, které spolu nijak nesouvisí. Blokace SMTP klientů dle IP adres a počty napadení asi klientských stanic, úniky účtů (asi úniky hesel u různých služeb – e-shopy, seznamky, fóra) a e-mailová komunikace…
Je to jednoduché, klient komunikuje s kompromitovaným účtem, dostane zpět z něj zpět exploit v externím odkazu většinou přes kompromitovaný web té firmy, který vyzradí heslo z jeho outlooku, útočník se připojí do schránky, nastavý přesměrování příchozí pošty na externí účet, vytvoří pravidla pro mazání příchozí pošty z kompromitované firmy, aby příjemce nedostával originální zprávy a pouze se přeposílaly, útočník chvíli sleduje komunikaci a pak pošle fakturu na služby s pozměněným číslem účtu nebo provádí jakoukoliv jinou průmyslovou špionáž dle zaměření. Má to jedno společné, časové otisky vždy sedí s listingy na sorbsu takže ty smtp jsou v ten čas již zalistované. Patrně sorbs má dobré sondy po světě a správné vzorky a umí to rozpoznat. Sorbs používá i spoustu úřadů, takže dat o provozu mají zdá se dost. Nevylučuji false pozitive listingy, ale pro tyto útoky časové značky vždy sedí. Content blockerem máte většinou smůlu, protože odkazy se tváří v pořádku a pokud se pouze scoruje tak dostamou pouze za sorbs blacklist a zpráva s odkazem projde. Pokud se blokuje natvrdo, tak to neprojde a útok se nepovede, to je ten jediný rozdíl. Korelace je tam jasná a dokázána na 5 letém zkoumání. Nedivím se že je aktuálně gmail na sorbsu, protože poslední 3 měsíce se v exploitnutých schránkám v 80% používají přeposílání na gmail účty. Předtím to byl yahoo, t-online apod. stále se to střídá technika stejná sorbs vždy odhalí. kundenserver.de to byl před 3 lety a ještě se z toho nevyhrabaly. Každý rok dělám kontrolní měsíc, kdy vypnu IP blokaci a zapnu scoring a v tom daném měsíci se objeví 5 případů těchto útoků. Náhoda ? Ne. S operátory se dá dohodnout většinou a kompromitované schránky se rychle odhalí, kundenserver, gmail, yahoo nekomunikuje, no tak mají smůlu...
-
Je to jednoduché
(https://i.imgsafe.org/cc29f2bdb6.jpg)
-
To je text generovaný AI? Věty jsou sestavené správně, použitá slova se týkají společného tématu, akorát generátor toho textu evidentně nechápe význam těch slov.
klient komunikuje s kompromitovaným účtem, dostane zpět z něj zpět exploit v externím odkazu většinou přes kompromitovaný web té firmy
„Kompromitovaný účet“ znamená uživatelský účet, do kterého se dostal i někdo jiný, než oprávněný majitel – třeba protože zjistil heslo uživatele. Na tom, že se k účtu přihlásí jeho oprávněný uživatel, není nic divného – naopak kompromitace spočívá v tom, že se k účtu přihlásí někdo jiný. Dejme tomu, že ten kompromitovaný účet bude třeba u nějakého e-shopu – pak útočník může vidět kontaktní údaje uživatele, může vidět, co si dotyčný dříve objednal, může jeho jménem učinit novou objednávku. Ale to je vše, nemůže způsobit, že uživatel „dostane z něj zpět exploit v externím odkazu“. To by útočník mohl způsobit, pokud by napadl systém e-shopu a dokázal do něj vkládat své odkazy – ale nijak to nesouvisí s kompromitací uživatelského účtu.
outlooku, útočník se připojí do schránky, nastavý přesměrování příchozí pošty na externí účet, vytvoří pravidla pro mazání příchozí pošty z kompromitované firmy, aby příjemce nedostával originální zprávy a pouze se přeposílaly
Kde se tam vedle kompromitovaného účtu vzala ještě kompromitovaná firma? Jaký by mělo smysl mazat nějaké příchozí zprávy – aby uživatel dřív zjistil, že něco není v pořádku?
pak pošle fakturu na služby s pozměněným číslem účtu
Proč celé to složité kompromitování uživatelského účtu, instalace exploitu, získání hesla k e-mailu, kompromitace firmy a přesměrování e-mailů, když mohl útočník rovnou poslat fakturu s pozměněným číslem účtu? Navíc v tom případě by uživateli alespoň dorazila, ve vašem případě ji ten filtr přepošle útočníkovi a smaže…
časové otisky vždy sedí s listingy na sorbsu takže ty smtp jsou v ten čas již zalistované
Jediné nezvyklé e-maily vtom, co jste popsal, jsou ty přesměrované na server útočníka. To není nic, co by SORBS zajímalo – a jediný způsob, jak by se to tom SORBS mohl dozvědět, je že by útočník ty e-maily, které si nechává přeposílat, SORBSu naprášil jako spam. To by udělal jedině v případě, že byste mu k útoku napsal návod.
A takhle to pokračuje dál, co věta, to nesmysl. Sice to jen tak nahazujete a nepouštíte se do žádných detailů, ale i tak se pozná, že nevíte, co ty pojmy ve skutečnosti znamenají.
-
To je text generovaný AI? Věty jsou sestavené správně, použitá slova se týkají společného tématu, akorát generátor toho textu evidentně nechápe význam těch slov.
klient komunikuje s kompromitovaným účtem, dostane zpět z něj zpět exploit v externím odkazu většinou přes kompromitovaný web té firmy
„Kompromitovaný účet“ znamená uživatelský účet, do kterého se dostal i někdo jiný, než oprávněný majitel – třeba protože zjistil heslo uživatele. Na tom, že se k účtu přihlásí jeho oprávněný uživatel, není nic divného – naopak kompromitace spočívá v tom, že se k účtu přihlásí někdo jiný. Dejme tomu, že ten kompromitovaný účet bude třeba u nějakého e-shopu – pak útočník může vidět kontaktní údaje uživatele, může vidět, co si dotyčný dříve objednal, může jeho jménem učinit novou objednávku. Ale to je vše, nemůže způsobit, že uživatel „dostane z něj zpět exploit v externím odkazu“. To by útočník mohl způsobit, pokud by napadl systém e-shopu a dokázal do něj vkládat své odkazy – ale nijak to nesouvisí s kompromitací uživatelského účtu.
outlooku, útočník se připojí do schránky, nastavý přesměrování příchozí pošty na externí účet, vytvoří pravidla pro mazání příchozí pošty z kompromitované firmy, aby příjemce nedostával originální zprávy a pouze se přeposílaly
Kde se tam vedle kompromitovaného účtu vzala ještě kompromitovaná firma? Jaký by mělo smysl mazat nějaké příchozí zprávy – aby uživatel dřív zjistil, že něco není v pořádku?
pak pošle fakturu na služby s pozměněným číslem účtu
Proč celé to složité kompromitování uživatelského účtu, instalace exploitu, získání hesla k e-mailu, kompromitace firmy a přesměrování e-mailů, když mohl útočník rovnou poslat fakturu s pozměněným číslem účtu? Navíc v tom případě by uživateli alespoň dorazila, ve vašem případě ji ten filtr přepošle útočníkovi a smaže…
časové otisky vždy sedí s listingy na sorbsu takže ty smtp jsou v ten čas již zalistované
Jediné nezvyklé e-maily vtom, co jste popsal, jsou ty přesměrované na server útočníka. To není nic, co by SORBS zajímalo – a jediný způsob, jak by se to tom SORBS mohl dozvědět, je že by útočník ty e-maily, které si nechává přeposílat, SORBSu naprášil jako spam. To by udělal jedině v případě, že byste mu k útoku napsal návod.
A takhle to pokračuje dál, co věta, to nesmysl. Sice to jen tak nahazujete a nepouštíte se do žádných detailů, ale i tak se pozná, že nevíte, co ty pojmy ve skutečnosti znamenají.
Ok jak myslíte, vydím že diskuzy můžeme ukončit, protože jste evidentně nidky žádný útok neřešil. Jen doplním že sorbs opravdu ty přeposlané emaily umí odchytit a označit, know how sorbsu vám nebudu sdělovat jak na to přijdou. Tohle nejsou útoky za 5000 tohle jsou útoky s milionovými úniky. Nikdy jste patrně nejednal s operátory sorbsu a nerozkrýval s policií organizovaný zločin tohoto typu. Nikdy jste také patrně nezpracovával schema útoku s časovými značkami a neporovnával je s daty ze sond. Nevadí, třeba se k tomu časem dostanete. Samozdřejmě se nemůžu vyjadřovat v textu do detailu, proto jsem pouze nastínil co všechno je k takovému podvodu potřeba a proč ho konkrétně v tom případě IP blokace zastaví. Ale klidně shazujte ostatní lidi dál, třeba s tím v životě někam dojdete a uspějete :)
-
jste evidentně nidky žádný útok neřešil.
Á, obhajovat svůj text nechcete, tak aspoň zkoušíte útočit. Jenže těžko můžete blafovat, když pořád ukazujete, že v rukou nic nemáte,
Jen doplním že sorbs opravdu ty přeposlané emaily umí odchytit a označit
Víte co je SORBS? Je to databáze IP adres poskytovaná přes DNS. Jak může databáze IP adres „odchytit a označit e-maily“? Tváříte se jako expert, tak snad dokážete takhle jednoduchou otázku zodpovědět.
know how sorbsu vám nebudu sdělovat
O tom nepochybuju.
vydím že diskuzy můžeme ukončit […] Nevadí, třeba se k tomu časem dostanete.
Vyjmenovaná slova se berou pokud vím ve třetí třídě a tu už mám nějaký ten pátek za sebou. Pokud je pro vás takový problém proniknout do tajů vyjmenovaných slov, proč bych si měl myslet, že bezpečnosti počítačových sítí rozumíte výrazně lépe?
Samozdřejmě se nemůžu vyjadřovat v textu do detailu
Detaily po vás nikdo nechce. Stačilo by, kdyby váš text dával nějaký smysl.
proto jsem pouze nastínil co všechno je k takovému podvodu potřeba a proč ho konkrétně v tom případě IP blokace zastaví.
Zatím to vypadá, že je k takovému podvodu potřeba hlavně velká fantazie. Ale tak třeba zvládnete odpovědět na jednoduchou otázku – píšete, že podvod zastaví „IP blokace“. Předpokládám, že myslíte blokace příchozího spojení na SMTP server podle IP adresy klienta, který navazuje spojení. Kde k té blokaci dochází? V tom vašem schématu vystupovaly jenom dva SMTP servery, a to server zprostředkující odesílání e-mailů pro napadeného uživatele (psal jste o uživateli používajícím Outlook), a dále server, na který si útočník nechává posílat přeposlané e-maily – jako příklad jste uváděl Google. Tu blokaci dle IP adresy tedy provádí jeden z těchto dvou serverů? Který? Nebo ještě nějaký jiný? A která IP adresa je zablokována?
Ale klidně shazujte ostatní lidi dál, třeba s tím v životě někam dojdete a uspějete :)
Když se tváříte jako expert, přitom nejste schopen napsat text, který by dával nějaký smysl, tak se nedivte. Mohl jste mé připomínky rozcupovat a ukázat, že jste sice používal vágní termíny, ale přitom jste velice dobře znal podstatu věci a z fleku to popíšete přesněji. Místo toho jste nasypal na hromadu spoustu dalších vágních termínů a tváříte se u toho jak mistr světa.
-
know how sorbsu vám nebudu sdělovat jak na to přijdou. tohle jsou útoky s milionovými úniky. Nikdy jste patrně nejednal s operátory sorbsu a nerozkrýval s policií organizovaný zločin tohoto typu.
(https://i.imgsafe.org/e144400a76.jpg)
-
Jen doplním že sorbs opravdu ty přeposlané emaily umí odchytit a označit
Víte co je SORBS? Je to databáze IP adres poskytovaná přes DNS. Jak může databáze IP adres „odchytit a označit e-maily“? Tváříte se jako expert, tak snad dokážete takhle jednoduchou otázku zodpovědět.
proto jsem pouze nastínil co všechno je k takovému podvodu potřeba a proč ho konkrétně v tom případě IP blokace zastaví.
Zatím to vypadá, že je k takovému podvodu potřeba hlavně velká fantazie. Ale tak třeba zvládnete odpovědět na jednoduchou otázku – píšete, že podvod zastaví „IP blokace“. Předpokládám, že myslíte blokace příchozího spojení na SMTP server podle IP adresy klienta, který navazuje spojení. Kde k té blokaci dochází? V tom vašem schématu vystupovaly jenom dva SMTP servery, a to server zprostředkující odesílání e-mailů pro napadeného uživatele (psal jste o uživateli používajícím Outlook), a dále server, na který si útočník nechává posílat přeposlané e-maily – jako příklad jste uváděl Google. Tu blokaci dle IP adresy tedy provádí jeden z těchto dvou serverů? Který? Nebo ještě nějaký jiný? A která IP adresa je zablokována?
Nepíši články, nemusím tudíž být expert na vyjmenovaná slova, vy jste začal napadat můj text první a vaše komentáře neměli konstruktivní smysl, proto z toho vzniklo to co vzniklo. Část posledního co jste napsal zní vcelku normálně tak vám na něj odpovím, k dalšímu se již nebudu vyjadřovat. V diskuzi se řešila blokace skorovacím filtrem versus IP blokací. Snažil jsem se nastínit proč IP blokace zamezí určitému typu útoků a je tedy lepší po stránce zmaření útoku za cenu nepřijetí ostatní pošty ze zdroje v čase, kdy je na blacklistech. A je externí napadený účet u providera B je neinfikovaný účet s oménou používající sorbs. A je útočníkem prostudováno a současně je kompromitován web firmy A. Vytipuje cíl B. Začne komunikaci s cílem B a sleduje (pokud tak již nebylo učiněno z předchozí analýzy komunikace MUA od B) v komunikaci otisky MUA B účtu. A pošle poté B url link s odkazem na exploit specificky pro jeho MUA, který je nahrán u A na webu. Formát emailu je klasická komunikace, čili nic zvláštního, většinou je to přidáno do běžné komunikace, když spolu A a B čili skuteční klienti běžně komunikují. Pokud se to povede B je napaden. Pak již probíhá napadení infrastruktury firmy B a vlastní útok buď s podvrženou fakturou apod. Kdy pokud to míra napadení umožňuje snaží se to kombinovat i s nějakým útokem na infrastrukturu A i B (hlavně na účetní systémy apod. ) tak aby byla nesrovnalost a útok odhalen co nejpozději.
Rozdíl scoring filtru vůči IP blokaci je ten, že ten exploit email od A když projde scoringem dostane např. +1 za sorbs a normálně přijde B, protože to score nestačí. Pokud jde o IP blokaci email B nepřijde, a desilatel A je notifikován o problému a může se hned začít řešit... Při správné investigaci se napadení hned odhalí a nedojde ke škodám.
A ta finta speciálně se sorbsem, který jako jeden z mála sleduje i tuto síť útočníků je odhalí dřív a zalistuje smtp na blacklist než přijde email s exploitem od A k B.
Ohledně vaší námitky jak může databáze ip adres odchytit a označit emaily : Ta úvaha je špatná já se bavil o procesu listace smtp na blacklist ne o blokaci na smtp, který sorbs používá.
Ta finta sorbsu je právě v použití sond na správných místech současně s technikou odhalení toho napadeného účtu, umožňuje to právě již přeposílání těch emailů napadeného účtu A na sledovací email útočníka. Je k tomu použita statistika, trasování ze sond a dobrá infiltrace, kterou ještě stále ti stejní útočníci neodhalili, popř. útočníci, kteří jejich mechaniky převzali. Nemůžu bohužel prozradit více.
-
Jen doplním že sorbs opravdu ty přeposlané emaily umí odchytit a označit
Víte co je SORBS? Je to databáze IP adres poskytovaná přes DNS. Jak může databáze IP adres „odchytit a označit e-maily“? Tváříte se jako expert, tak snad dokážete takhle jednoduchou otázku zodpovědět.
Co je to SORBS si může kdokoliv nastudovat na http://www.sorbs.net kde je jasně vidět že to zdaleka není jen databáze, ale hlavně projekt který tu databázi plní a dělá to přesně tak jak píše foldy. Databáze IP adres SMTP serverů které rozesílají spam je pouze výstupem tohoto projektu. Jirsák se jako již tradičně projevuje jako člověk který se vyjadřuje k věcem kterým vůbec nerozumí.
-
Nepíši články, nemusím tudíž být expert na vyjmenovaná slova
Nikdo po vás nechce, abyste byl expert na vyjmenovaná slova. Vyjmenovaná slova nejsou žádná expertní látka, kterou by se učili novináři na vysoké. Je to látka třetího ročníku základní školy. Navíc vám ta špatně napsaná slova prohlížeč podtrhuje červenou vlnkovanou čárou. Já bych tu gramatiku normálně přešel, jenže ve vašem případě je obsahová stránka textu ještě lajdáčtější než jeho formální stránka. Ve výsledku vůbec není jasné, co se vlastně snažíte napsat, a to, co jste napsal, nedává žádný smysl (respektive všechny možné varianty toho, co by to mohlo znamenat, jsou v rozporu s realitou).
vy jste začal napadat můj text první a vaše komentáře neměli konstruktivní smysl, proto z toho vzniklo to co vzniklo.
Nikoli. To, co vzniklo, vzniklo tím, že píšete lajdácké a zmatené texty, a snažíte se to zamaskovat vystupováním, jako byste byl nějaký expert. Přitom nedokážete popsat ani tak banální věc, jako že například „útočník napadl webový server např. e-shopu, získal databázi přihlašovacích údajů včetně e-mailů a hesel v otevřeném tvaru, a webový server ovládá i nadále a má možnost vkládat na jeho webové stránky svůj vlastní kód“.
A je externí napadený účet u providera
Předpokládám, že to souvětí má být rozdělené takhle, chybí vám tam čárka.
O jakého providera a jaký napadený účet se jedná? Je to e-shop a uživatelský účet na e-shopu? Je to webmail a účet u něj? Je „provider“ zaměstnavatel a napadený účet je firemní účet zaměstnance (typicky z Active Directory), který umožňuje přihlášení na firemní počítače, k firemnímu souborovému serveru, k firemnímu poštovnímu serveru?
B je neinfikovaný účet s oménou používající sorbs
Předpokládám,že jste myslel „doménou“ a „SORBS“. SORBS je databáze IP adres, blacklist. „Doména“ je (v této diskusi) název zapsaný v DNS, případně celá hierarchie (DNS zóna). „Doména používající SORBS“ je nesmysl, to slovní spojení nemá žádný význam. SORBS nejčastěji využívá nějaký server, obvykle SMTP server.
A pošle poté B url link s odkazem na exploit specificky pro jeho MUA, který je nahrán u A na webu.
„URL link s odkazem“ asi mělo znamenat „URL“. Že by byl exploit schován v URL s protokolem mailto je hodně nepravděpodobné, asi to bude spíš URL s protokolem http nebo https. MUA je poštovní klient. Pokud nejde o webmail, ke kterému se přistupuje přes webový prohlížeč, ale o nějakého samostatného klienta (MS Outlook, Mozilla Thunderbird apod.), neotvírá ten klient odkazy protokolu http nebo https neotvírá, používá k tomu webový prohlížeč. Onen exploit tedy musí být zaměřen na používaný webový prohlížeč, nikoli na poštovního klienta. Z analýzy komunikace s MUA ale útočník obvykle nepozná, jaký webový prohlížeč používá dotyčný uživatel. Naopak to obvykle pozná při prvním požadavku na webový server, protože prohlížeč se sám identifikuje. Mimochodem, ke zjištění, že uživatel B používá webmail, není potřeba žádný sofistikovaný útok – obvykle stačí podívat se na doménu, a pokud je tam třeba gmail.com nebo seznam.cz, je dost pravděpodobné, že dotyčný používá webmail.
Takže ve výsledku by celý ten útok na B vypadal tak, že by útočník poslal uživateli B e-mail s odkazem na stránku s exploitem. Pokud vás překvapuje, že v popisu toho útoku nikde nevidíte uživatelský účet A, je to správně, protože ten je ve vašem popisu útoku zcela zbytečný.
Pak již probíhá napadení infrastruktury firmy B a vlastní útok buď s podvrženou fakturou apod.
Pro provedení útoku s podvrženou fakturou není vůbec nutné napadat infrastrukturu firmy B, prostě stačí uživateli B poslat e-mail s podvrženou fakturou. Celé to závisí jenom na tom, zda jsou faktury elektronicky podepisovány a uživatel B podpis ověřuje. Pokud nejsou, opět stačí jen poslat e-mail uživateli B, není k tomu potřeba ani napadený účet A ani napadená infrastruktura firmy B.
Pokud jde o IP blokaci email B nepřijde
Nepřijde mu e-mail s pravou fakturou od pravého A. Místo toho mu přijde e-mail poslaný útočníkem z jiné IP adresy s falešnou fakturou. Díky zablokování toho pravého e-mailu přijde B jenom jedna faktura a ne dvě, což by samozřejmě vyvolalo podezření. Gratuluju, právě jste svou blokací významně přispěl k úspěchu útočníka.
desilatel A je notifikován o problému
Klidně je možné, že e-mail od A k B byl doručován přes několik serverů, na některém serveru se nepodařilo ověřit identitu odesílatele, takže zprávu o nedoručení nebude doručovat zpět, protože se s největší pravděpodobností jedná jen o reakci na spam, tedy falešnou zprávu o nedoručení. A i kdyby se e-mail o nedoručení dostal až ke schránce A, tu přece ovládá útočník, takže pro něj není žádný problém tu zprávu o nedoručení smazat. „A“ tedy o žádném problému notifikován není.
A ta finta speciálně se sorbsem, který jako jeden z mála sleduje i tuto síť útočníků je odhalí dřív
Myslel jste: „A ta finta speciálně se SORBSem, který jako jeden z mála sleduje i tuto síť útočníků, je odhalí dřív“? O jakou „tuto síť útočníků“ se jedná? O ničem takovém jste doteď nepsal. Jak SORBS „tuto síť útočníků“ sleduje?
zalistuje smtp na blacklist než přijde email s exploitem od A k B.
Na blacklistu bude server, přes který odesílá uživatel A. Útočník ovšem bude e-mail posílat přes úplně jiný server, takže ten e-mail s exploitem blacklist nezastaví.
Ohledně vaší námitky jak může databáze ip adres odchytit a označit emaily : Ta úvaha je špatná
Ano, ta úvaha je špatná, konečně se v něčem shodneme. Bohužel je to vaše úvaha, já jsem to, že „SORBS odchytí a označí e-maily“ pouze citoval z vašeho komentáře.
Nemůžu bohužel prozradit více.
K nějakému prozrazování jsme se ani zdaleka nedostali. Zatím pořád řešíme jenom to, aby vaše vyjádření byla v souladu s tím, co je SORBS, co a jak používá blacklist IP adres, co je to doména, jak funguje doručování e-mailů, jestli se webové stránky otevírají ve webovém prohlížeči nebo v poštovním klientovi a další úplně základní věci.
-
Co je to SORBS si může kdokoliv nastudovat na http://www.sorbs.net kde je jasně vidět že to zdaleka není jen databáze, ale hlavně projekt který tu databázi plní a dělá to přesně tak jak píše foldy. Databáze IP adres SMTP serverů které rozesílají spam je pouze výstupem tohoto projektu. Jirsák se jako již tradičně projevuje jako člověk který se vyjadřuje k věcem kterým vůbec nerozumí.
Takže co je pro administrátora SMTP serveru SORBS, jakou službu nebo výstup mu může SORBS poskytnout? Ano, správně, databázi IP adres, nic jiného. Umí SORBS pro správce SMTP serveru „odchytit a označit přeposlané e-maily“, jak psal Foldy? Neumí. Psal někde Foldy o tom, jak SORBS plní databázi IP adres? Nepsal, psal jenom o tom, jak je to hrozně tajné know-how. Místo ad hominem jste měl napsat jeden jediný výstup ze SORBS jiný než je databáze IP adres. Takhle to vypadá, že žádný argument na podporu svého tvrzení nemáte.
-
Nemůžu bohužel prozradit více.
K nějakému prozrazování jsme se ani zdaleka nedostali. Zatím pořád řešíme jenom to, aby vaše vyjádření byla v souladu s tím, co je SORBS, co a jak používá blacklist IP adres, co je to doména, jak funguje doručování e-mailů, jestli se webové stránky otevírají ve webovém prohlížeči nebo v poštovním klientovi a další úplně základní věci.
Hele jestli jsi po mém vysvětlení s A a B nic nepochopil, pak už nemá cenu utrácet za tebe energii. V tvé verzi je totiž útočník evidentně totální trotl a widlař a naprosto nechápe SPF s DKIM a tak pošle falešnou fakturu třeba z domu po vypití elixíru štěstí se mu podaří podvrhnout IP, packety kouzelně projdou až do sítě B a privátní DKIM klíč ? Ten si předce odhadne z rozsypaného rohlíku u snídaně. Říkám pokračuj jak umíš v tom co děláš. Třeba s tím někam dojdeš.
-
Ježíšmarjá, to snad není možný, tohle. Ty vole, podle SPF bude filtrovat maily jen naprostej dement, protože jedinej, kdo SPF používá, jsou spammeři. Pro filtrování, natož odmítání emailů to je absolutně nepoužitelné, krom toho je ta věc rozbitá by design, protože přeposílání mailů. To sice vůbec nevadí spammerům, ale zato normálním uživatelům ano. SPF se dá použít asi jako desátý pomocný kritérium, pokud ho budu párovat s konkrétníma doménama, o nichž skutečně vím na 130%, že odnikud jinud legitimní maily z té domény nechodí. Na takovej voser se můžu víš co asi tak.
Ale především vůbec nevím, proč by se někdo obtěžoval s podvrhováním nějaké domény, když to je naprosto k ničemu, protože typický poštovní klient MS Utlouk adresátori zobrazí přesně to, co si napíšu do From:
P.S. Pochopitelně, když blbec tvého kalibru masově zahazuje legitimní poštu a před uživatelema se ještě navrch tváří jako agent 007, tak je celá tahle debata zbytečná, ale normálně lidi mají email k tomu, aby mohli komunikovat, ne, aby jim ty zprávy vymaštěný pseudosprávce hrající si na agenta zahazoval.
-
Hele jestli jsi po mém vysvětlení s A a B nic nepochopil, pak už nemá cenu utrácet za tebe energii.
Po vašem vysvětlení jsem nepochopil nic nového – že moc nevíte, o čem píšete, jsem pochopil už z vašich prvních příspěvků.
Ptal jsem se na dost konkrétní dotazy, a ne poprvé, a vy jste na ně ani jednou neodpověděl. Místo toho se pokaždé začnete vymlouvat.
Proč jednoduše nenapíšete, jaký typ služby poskytuje ten provider uživatele A? Proč nepřiznáte, že „doména používající SORBS“ je nesmysl a nenapíšete, která strana a jak tedy ve vašem příkladu SORBS používá?
V tvé verzi je totiž útočník evidentně totální trotl a widlař a naprosto nechápe SPF s DKIM a tak pošle falešnou fakturu třeba z domu po vypití elixíru štěstí se mu podaří podvrhnout IP, packety kouzelně projdou až do sítě B a privátní DKIM klíč ? Ten si předce odhadne z rozsypaného rohlíku u snídaně.
O SPF a DKIM nebyla ve vašem příkladu řeč. Navíc SPF i DKIM ověřují jen identitu odesílajícího serveru, ne konkrétního uživatele. Pokud B proplácí fakturu, kterou vystavil vrátný ve firmě A, bude mít problém tak jako tak. A je zbytečné, aby se útočník pachtil se síťovým útokem na firmu A, když může jednoduše k odeslání té faktury přimět toho vrátného.
-
A pošle poté B url link s odkazem na exploit specificky pro jeho MUA, který je nahrán u A na webu.
„URL link s odkazem“ asi mělo znamenat „URL“. Že by byl exploit schován v URL s protokolem mailto je hodně nepravděpodobné, asi to bude spíš URL s protokolem http nebo https. MUA je poštovní klient. Pokud nejde o webmail, ke kterému se přistupuje přes webový prohlížeč, ale o nějakého samostatného klienta (MS Outlook, Mozilla Thunderbird apod.), neotvírá ten klient odkazy protokolu http nebo https neotvírá, používá k tomu webový prohlížeč. Onen exploit tedy musí být zaměřen na používaný webový prohlížeč, nikoli na poštovního klienta. Z analýzy komunikace s MUA ale útočník obvykle nepozná, jaký webový prohlížeč používá dotyčný uživatel. Naopak to obvykle pozná při prvním požadavku na webový server, protože prohlížeč se sám identifikuje. Mimochodem, ke zjištění, že uživatel B používá webmail, není potřeba žádný sofistikovaný útok – obvykle stačí podívat se na doménu, a pokud je tam třeba gmail.com nebo seznam.cz, je dost pravděpodobné, že dotyčný používá webmail.
Takže ve výsledku by celý ten útok na B vypadal tak, že by útočník poslal uživateli B e-mail s odkazem na stránku s exploitem. Pokud vás překvapuje, že v popisu toho útoku nikde nevidíte uživatelský účet A, je to správně, protože ten je ve vašem popisu útoku zcela zbytečný.
Hele no vidíš, já si si myslel že ty budeš chytrej a znalej a přijdeš si na to sám. Jestlipak jsi si četl a snažil se pochopit co jsem ti napsal. Pročpak bych ti jinak psal že je potřeba nahrát obsah na web infikovaného odesílatele A hm ? Já chápu že tvoje verze útočníka ( už víme že je to widlař a totální trotl, který vypil elixír štěstí) se bude snažit psát nějaké exploity do prohlížeče. No a rozdíl mezí tvou verzí omezeného útočníka a úspešným útokem je v detailu, který jsi naprosto ignoroval a je potřeba k úspěšné kompromitaci MUA potřeba. Schválně jestli na něj přijdeš sám, jaký je v tom rozdíl,napovídat nebudu.
-
Hele no vidíš, já si si myslel že ty budeš chytrej a znalej a přijdeš si na to sám.
Zase jen výmluvy. Když vám píšu, že píšete vágně a váš text je ve výsledku nesmyslný, není řešením, že budete dál psát vágně a doufat, že si něco domyslím – řešením je jedině začít psát přesně.
Jestlipak jsi si četl a snažil se pochopit co jsem ti napsal.
Samozřejmě, že jsem to četl a snažil se to pochopit. Vyšlo mi z toho, že moc netušíte, o čem je řeč, tak se snažíte alespoň fabulovat. Chtěl jsem vám ještě dát šanci, abyste předvedl, že jenom neobratně píšete, ale věci rozumíte. Proto jsem se zeptal na konkrétní věci. Odpovědi jsem se nedočkal.
Pročpak bych ti jinak psal že je potřeba nahrát obsah na web infikovaného odesílatele A hm ?
Protože jste si to vymyslel, hm? Zatím jste ani nedokázal napsat, kdo je to vlastně ten A a jaké služby mu poskytuje jeho provider. Když A odesílá faktury, je to asi účetní nějaké firmy. Provider té účetní – no dobře, asi jste tím myslel firemní IT. Napadením účtu účetní získá útočník zároveň možnost upravovat web – aha, takže účetní dělá zároveň na půl úvazku webmastera. Máte to fakt dobře promyšlené.
Já chápu že tvoje verze útočníka se bude snažit psát nějaké exploity do prohlížeče.
To vychází z vašeho tvrzení „pošle url link s odkazem na exploit“. Takže jste asi nemyslel exploit na webový prohlížeč. OK, takže útočník „pošle URL link s odkazem na exploit“, přičemž to URL se nebude otvírat ve webovém prohlížeči. V jakém programu se tedy to URL otevře? A když se to URL nebude otvírat ve webovém prohlížeči, k čemu je tedy dobré nahrávat exploit na webový server?
No a rozdíl mezí tvou verzí omezeného útočníka a úspešným útokem je v detailu, který jsi naprosto ignoroval a je potřeba k úspěšné kompromitaci MUA potřeba.
Ve vašem příkladu už útočník (neřešme jak) získal možnost posílat jménem uživatele A e-maily a přenastavit mu poštovní filtry. Co by získal ještě větší kompromitací MUA?
Schválně jestli na něj přijdeš sám, jaký je v tom rozdíl,napovídat nebudu.
Zase další úhybné manévry. Co kdybyste místo vymýšlení chytaček odpověděl na ty otázky, které jsem vám napsal já? Už se jich sešla celá řada a vy jste neodpověděl ani na jednu. Jestlipak jste ty otázky četl a pochopil, na co se v nich ptám.
-
Ježíšmarjá, to snad není možný, tohle. Ty vole, podle SPF bude filtrovat maily jen naprostej dement, protože jedinej, kdo SPF používá, jsou spammeři. Pro filtrování, natož odmítání emailů to je absolutně nepoužitelné, krom toho je ta věc rozbitá by design, protože přeposílání mailů. To sice vůbec nevadí spammerům, ale zato normálním uživatelům ano. SPF se dá použít asi jako desátý pomocný kritérium, pokud ho budu párovat s konkrétníma doménama, o nichž skutečně vím na 130%, že odnikud jinud legitimní maily z té domény nechodí. Na takovej voser se můžu víš co asi tak.
Ale především vůbec nevím, proč by se někdo obtěžoval s podvrhováním nějaké domény, když to je naprosto k ničemu, protože typický poštovní klient MS Utlouk adresátori zobrazí přesně to, co si napíšu do From:
P.S. Pochopitelně, když blbec tvého kalibru masově zahazuje legitimní poštu a před uživatelema se ještě navrch tváří jako agent 007, tak je celá tahle debata zbytečná, ale normálně lidi mají email k tomu, aby mohli komunikovat, ne, aby jim ty zprávy vymaštěný pseudosprávce hrající si na agenta zahazoval.
:D:D No tak předně tam máš problém s tím přeposíláním, který neexistuje :) Ze schránky obsahující SPF samozdřejmě email přepošleš protože zdrojový server je té schránky že ano... navíc jestli víš jak funguje SPF a jak funguje FWD, tak by jsi měl vědět,že i email, který někam přepošleš a ten je dál FWD jinam, tak projde i do cílového mailboxu protože "výjimka ve FWD", měl by jsi si nejdřív přečíst RFC.
Nevím sice na co ti v útoku bude podvrhování From: , když chybí zbytek té podstaty aby se to povedlo ale nevadí. Samozdřejmě že se nebavíme o správě emailú nějakých uživatelů a zelinářů z těch těžko vytáhnete platby milionových faktur. Tohle to jsou vektory útoků na firmy (které jsou dostatečně velké na to aby mohly zaplatit velkou částku, případně byl útok jinak zpeněžitelný), ve firemní komunikaci, kdy musí komunikovat s těmito malými zelináři zvenku, ale navíc se musí chránit co nejefektivněji útokům zvenku. Tam jsou nároky na bezpečnost o dost jiné.
Jinak jako kolega taky nevíš jak se hackuje MUA a proč je k tomu potřeba web A. Takže chápu, že ti připadá podvrhování a napadení webu A jako zbytečné že ..
-
Ano, vidím, že debatu bude nejlépe ukončit. S agentem s teplou vodou, který zjevně namemoroval s vypětím sil nějaké odborné termity, o kterých nemá ani tušení, co znamenají, je opravdu zbytečné se bavit. Problém, zdokumentovaný (neb jim nic nezbylo) a autory návrhu toho paskvilu (viz http://www.openspf.org/FAQ/Forwarding nebo http://www.openspf.org/Best_Practices/Forwarding) neexistuje. A "schránky obsahující SPF" to opravdu dorazily.
Čau, agente.
-
navíc jestli víš jak funguje SPF a jak funguje FWD, tak by jsi měl vědět,že i email, který někam přepošleš a ten je dál FWD jinam, tak projde i do cílového mailboxu protože "výjimka ve FWD", měl by jsi si nejdřív přečíst RFC.
Zase jste nějak zapomněl napsat číslo RFC a také „jak funguje FWD“. Když předpokládáte, že všichni okolo jsou hlupáci, jenom vy jste expert, musíte být konkrétní. Ne jen nadhodit „přečíst RFC“, ale napsat přesně které RFC a které jeho ustanovení. Jinak si my hlupáci budeme myslet, že zase jen bohapustě plácáte.
Mimochodem, žádná „výjimka ve FWD“, asi myslíte výjimku při ověřování SPF při přeposílání, v žádném RFC definována není. Ona by totiž taková výjimka celé SPF pohřbila. Spammer by se jednoduše tvářil, že svůj e-mail přeposílá, a bylo by vymalováno.
Ale že jste to vy, já vám to vysvětlím. V e-mailové komunikaci se používají dva druhy adres. Jedna sada adres jsou ty, které jsou uvedené přímo v e-mailu, ty zobrazuje poštovní klient. A pak je druhá sada adres, která je uvedena jakoby na obálce dopravovaného e-mailu, a těmito adresami se řídí poštovní servery. A ty adresy na obálce nemusí být shodné s adresou v samotném e-mailu. Díky tomu může fungovat přesměrování – odesílatel pošle e-mail na adresu třeba foldy@example.com, ta adresa je uvedena v e-mailu i na obálce. Server obsluhující poštu pro doménu example.com e-mail přijme a rozhodne se přeposlat ho na adresu foldy@example.net. Adresa adresáta v e-mailu se nezmění, pořád je to foldy@example.com – ale v obálce použije jako adresu příjemce foldy@example.net, tudíž se e-mail doručí serveru obsluhujícímu doménu example.net.
SPF řeší naopak adresu odesílatele, ta je také uvedena dvakrát, v e-mailu i na obálce. Ta adresa odesílatele na obálce je určená pro případ, kdy se něco děje s doručením e-mailu (obvykle když není možné e-mail z nějakého důvodu doručit) – na adresu obálkového odesílatele se pak pošle zpráva o (dočasném nebo trvalém) problému s doručováním. Na obálce by tedy měl být jako odesílatel uveden ten, kdo je za daný e-mail zodpovědný. Kvůli jednoduchosti se tam při doručování běžných e-mailů dříve dával původní odesílatel. Což je špatně, protože při přeposlání zprávy se za doručení té přeposlané zprávy stává zodpovědný ten přeposílající server, a případné chyby mají být hlášeny tam. Běžně to takhle funguje v poštovních konferencích, kdy jsou chyby při doručování někomu z konference hlášeny správci konference, nikoli původnímu odesílateli. Při doručování běžných e-mailů to bohužel zatím není příliš obvyklé a spíš se do přeposlaného e-mailu pořád cpe původní odesílatel. V takovém případě nebude SPF souhlasit a přijímající server může přeposlaný e-mail odmítnout. Pokud přeposílající server správně uveden vlastní adresu v adrese obálkového odesílatele, SPF funguje správně (ověřuje se doména přeposílajícího serveru). Dokonce pro to přepisování adres v obálce existuje doporučení SRS (Sender Rewriting Scheme (https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme)), které popisuje, jak obálkovou adresu přepsat tak, aby patřila do domény přeposílajícího serveru, ale aby z ní zároveň bylo možné odvodit předchozího odesílatele (bez vytváření nějaké databáze mapování).
-
A zase Jirsákův teoretický žvást! V praxi to mám ověřené přesně naopak - pokud ze serveru chodí méně mailů je mnohem méně náchylný na zařazení na reálné blacklisty. Pokud z něj mají povoleno odesílat maily pouze zodpovědní uživatelé tak ta pravděpodobnost dále klesá, v praxi limitně k nule pokud se navíc omezí počet povolených odeslaných mailů od každého uživatele denně (to kvůli případnému napadení jejich počítačů spamovacím malware).
Ha ha. Zrovna předevčírem jsem řešil, že se dostalo na blacklist celé Forpsi (tedy i můj server, který nikdy spam neodesílal), protože u nich prý bylo 17 spamujících strojů, a ten blacklist se rozhodl, že na základě toho bude blokovat celé /22.
Pak jsem zažil přidání na blacklist na základě toho, že vedle v /24 běží Tor exit (ačkoli exity mají zakázaný port 25 a spam tak posílat nemůžou!!!) a na základě toho, že moje adresa je „rezidentní“ (UPC poskytující připojení domácnostem) a tak se neočekává, že by z ní někdo posílal poštu a pravděpodobně to bude zavirovaný počítač.
-
...SPF...
Na tomhle mi nikdy nebylo jasné, proč si spammer, který se snaží zfalšovat adresu odesílatele, nemůže do obálkového odesílatele dát nějakou adresu, která mu projde, a do From: dát tu, co chce zfalšovat. 99,9 % uživatelů si toho nevšimne (obálková adresa se maximálně přilepí do nějaké hlavičky, a hlavičky skoro nikdo nečte) a spammer tím SPF obešel a SPF tak nepomohlo. Takže SPF mi pomůže proti „backscatteru“ (kdy chudákovi, jehož adresa byla zfalšována, začnou chodit stovky zpráv o nedoručení), ale před zfalšováním From: hlavičky ne.
-
navíc jestli víš jak funguje SPF a jak funguje FWD, tak by jsi měl vědět,že i email, který někam přepošleš a ten je dál FWD jinam, tak projde i do cílového mailboxu protože "výjimka ve FWD", měl by jsi si nejdřív přečíst RFC.
Zase jste nějak zapomněl napsat číslo RFC a také „jak funguje FWD“. Když předpokládáte, že všichni okolo jsou hlupáci, jenom vy jste expert, musíte být konkrétní. Ne jen nadhodit „přečíst RFC“, ale napsat přesně které RFC a které jeho ustanovení. Jinak si my hlupáci budeme myslet, že zase jen bohapustě plácáte.
Mimochodem, žádná „výjimka ve FWD“, asi myslíte výjimku při ověřování SPF při přeposílání, v žádném RFC definována není. Ona by totiž taková výjimka celé SPF pohřbila. Spammer by se jednoduše tvářil, že svůj e-mail přeposílá, a bylo by vymalováno.
Ale že jste to vy, já vám to vysvětlím. V e-mailové komunikaci se používají dva druhy adres. Jedna sada adres jsou ty, které jsou uvedené přímo v e-mailu, ty zobrazuje poštovní klient. A pak je druhá sada adres, která je uvedena jakoby na obálce dopravovaného e-mailu, a těmito adresami se řídí poštovní servery. A ty adresy na obálce nemusí být shodné s adresou v samotném e-mailu. Díky tomu může fungovat přesměrování – odesílatel pošle e-mail na adresu třeba foldy@example.com, ta adresa je uvedena v e-mailu i na obálce. Server obsluhující poštu pro doménu example.com e-mail přijme a rozhodne se přeposlat ho na adresu foldy@example.net. Adresa adresáta v e-mailu se nezmění, pořád je to foldy@example.com – ale v obálce použije jako adresu příjemce foldy@example.net, tudíž se e-mail doručí serveru obsluhujícímu doménu example.net.
SPF řeší naopak adresu odesílatele, ta je také uvedena dvakrát, v e-mailu i na obálce. Ta adresa odesílatele na obálce je určená pro případ, kdy se něco děje s doručením e-mailu (obvykle když není možné e-mail z nějakého důvodu doručit) – na adresu obálkového odesílatele se pak pošle zpráva o (dočasném nebo trvalém) problému s doručováním. Na obálce by tedy měl být jako odesílatel uveden ten, kdo je za daný e-mail zodpovědný. Kvůli jednoduchosti se tam při doručování běžných e-mailů dříve dával původní odesílatel. Což je špatně, protože při přeposlání zprávy se za doručení té přeposlané zprávy stává zodpovědný ten přeposílající server, a případné chyby mají být hlášeny tam. Běžně to takhle funguje v poštovních konferencích, kdy jsou chyby při doručování někomu z konference hlášeny správci konference, nikoli původnímu odesílateli. Při doručování běžných e-mailů to bohužel zatím není příliš obvyklé a spíš se do přeposlaného e-mailu pořád cpe původní odesílatel. V takovém případě nebude SPF souhlasit a přijímající server může přeposlaný e-mail odmítnout. Pokud přeposílající server správně uveden vlastní adresu v adrese obálkového odesílatele, SPF funguje správně (ověřuje se doména přeposílajícího serveru). Dokonce pro to přepisování adres v obálce existuje doporučení SRS (Sender Rewriting Scheme (https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme)), které popisuje, jak obálkovou adresu přepsat tak, aby patřila do domény přeposílajícího serveru, ale aby z ní zároveň bylo možné odvodit předchozího odesílatele (bez vytváření nějaké databáze mapování).
No vidíte že jste se konečně rozhoupal. Nemusíte mi to vysvětlovat já to znám. Takže už to jen dorazíme poslední sadou odpovědí a je to.
-
Na tomhle mi nikdy nebylo jasné, proč si spammer, který se snaží zfalšovat adresu odesílatele, nemůže do obálkového odesílatele dát nějakou adresu, která mu projde, a do From: dát tu, co chce zfalšovat. 99,9 % uživatelů si toho nevšimne (obálková adresa se maximálně přilepí do nějaké hlavičky, a hlavičky skoro nikdo nečte) a spammer tím SPF obešel a SPF tak nepomohlo. Takže SPF mi pomůže proti „backscatteru“ (kdy chudákovi, jehož adresa byla zfalšována, začnou chodit stovky zpráv o nedoručení), ale před zfalšováním From: hlavičky ne.
SPF (ani DKIM) nikdy nebylo navržené k tomu, aby pomohlo i těm, kteří ho nepoužívají. Obě technologie cílí na to, že je (nebo aspoň jednu z nich) budou používat všichni „hodní“. Když pak spammer nic z toho nepoužije, bude rovnou sprostý podezřelý. Bohužel se mezitím z doručování e-mailů stala taková džungle, že není šance, že by se tyhle technologie rychle prosadily, a je vůbec otázka, zda se stihnou prosadit dřív, než e-mail kvůli spamu zanikne. Zvlášť když jim „konkurují“ takové sofistikované metody boje proti spamu jako blacklisty typu SORBS, které umí použít každý pologramot.
Jinak SPF i DKIM předpokládá použití blacklistů domén – akorát nevím o tom, že by nějaký takový existoval. V tomto případě ale má blacklist domén význam, protože příslušný server se přihlásil k odpovědnosti za daný e-mail. DKIM je v tomto lepší, protože tam server e-mail skutečně podepisuje a jeho správce by tedy měl mít pod plnou kontrolou, co odesílá. Navíc je možné snadno důkaz předat třetí straně – blacklistu. V případě SPF je to pořád jen moje tvrzení, z jaké IP adresy ten e-mail přišel, což je zneužitelné.
-
Pročpak bych ti jinak psal že je potřeba nahrát obsah na web infikovaného odesílatele A hm ?
Protože jste si to vymyslel, hm? Zatím jste ani nedokázal napsat, kdo je to vlastně ten A a jaké služby mu poskytuje jeho provider. Když A odesílá faktury, je to asi účetní nějaké firmy. Provider té účetní – no dobře, asi jste tím myslel firemní IT. Napadením účtu účetní získá útočník zároveň možnost upravovat web – aha, takže účetní dělá zároveň na půl úvazku webmastera. Máte to fakt dobře promyšlené.
Já chápu že tvoje verze útočníka se bude snažit psát nějaké exploity do prohlížeče.
To vychází z vašeho tvrzení „pošle url link s odkazem na exploit“. Takže jste asi nemyslel exploit na webový prohlížeč. OK, takže útočník „pošle URL link s odkazem na exploit“, přičemž to URL se nebude otvírat ve webovém prohlížeči. V jakém programu se tedy to URL otevře? A když se to URL nebude otvírat ve webovém prohlížeči, k čemu je tedy dobré nahrávat exploit na webový server?
No a rozdíl mezí tvou verzí omezeného útočníka a úspešným útokem je v detailu, který jsi naprosto ignoroval a je potřeba k úspěšné kompromitaci MUA potřeba.
Ve vašem příkladu už útočník (neřešme jak) získal možnost posílat jménem uživatele A e-maily a přenastavit mu poštovní filtry. Co by získal ještě větší kompromitací MUA?
A je již ukradený účet dejme tomu třeba zelinář na t-online.de, B v jejichž struktuře je neinfikovaný uživatel používající konkrétní verzi outlooku na konkrétních widlích se kterým A komunikuje a je u jiného providera. Na webu A je nahrán skript připravený pro ten konkrétní email, protože zelináři mají super top zabezpečené weby že ano... A pošle email B, který obsahuje ten link, no a věřte nebo ne, nemusí nikdo nic otvírat a zjistíte hash toho hesla... Rozšifrovat konkrétní hash případně rovnou heslo. Hash samozdřejmě není nerálné rozlousknout, zvláště konkrétní typy že ano... Podmínkou je to aby ten připravený skript ležel na doméně odesílatele. Kompromitací MUA B získáte hlavně heslo a to nejkratší možnou cestou na jeden email a jeden request. Čili úspěšný útok na sledování druhé schránky většinou vyžaduje 1 email a jeden IP přístup pro nastavení těch pravidel na mailserveru providera. To je dost malá stopa a smyslem je co nejmenší šance na odhalení. Zbytek je většinou už nudný, často bývají takto sledovány 3-4 schránky z domény A i B po dlouhou dobu, při jedné investigaci jsem viděl i půl roku. Pak se pošle nějaká faktura nebo serie faktur, počká se až se zaplatí a v závislosti na infiltraci do obou firem se na ně provede nějaký krycí útok, kterého si všimnou a řeší ho a současně s ním je celkem běžné že zaheslují účetní systémy, mažou zálohy z NASů apod. Než to nějací admini obnovíí z pásek a zprovozní a dojde k nějaké kontrole u A i B tak uběhnou 2 měsíce, prachy fuč, účty zrušené a prachy vyprané. Zelinář (A) o nic nepřišel B má velký problém. Zelinář nic moc u sebe nezmění a neřeší to, protože o nic nepřišel a za pár let je použit k jinému útoku, už jsem viděl konkrétně u t-onlinu, pak jsou provideři, kterým když předáte všechny data a sdělíte problém s návrhem konkrétního řešení tak ani neodpoví a jejich klient také nic neřeší protože u něj škoda nevznikla. Takový provider je pak na permaban u nás, viz kundenserver.de, ale i mnoho dalších.
Proč tomu zamezí v počáteční fázy IP blokace sorbsu jsem již psal. Do větších detailů se nepouštím schválně, jednak takové kvantum dat není pro forum a jednak se takovéto informace nepouštějí do veřejného internetu, aby jsme samozdřejmě někoho nenaváděli a nedávaly mu zdarma návody aby nás příště obešel...
Tenhle stav trvá již stabilně 6 let. Nikdo to neřeší a v DE za poslední rok vyčíslily škody na podobných útocích na 200mil eur za rok 2015. Jen za leden identifikovaných 5 takových pokusů na našich 40tis doménách.
-
Do větších detailů se nepouštím schválně, jednak takové kvantum dat není pro forum a jednak se takovéto informace nepouštějí do veřejného internetu, aby jsme samozdřejmě někoho nenaváděli a nedávaly mu zdarma návody aby nás příště obešel...
(https://i.imgsafe.org/f389f25bdc.jpg)
-
A je již ukradený účet dejme tomu třeba zelinář na t-online.de […] Na webu A je nahrán skript připravený pro ten konkrétní email, protože zelináři mají super top zabezpečené weby že ano...
Takže osoba A má u jednoho poskytovatele e-mailový účet, někde jinde hostuje webové stránky, které si spravuje nejspíš sama, takže zabezpečení nic moc. Dejme tomu, že ten e-mailový účet je zelinář@gmail.com, web provozuje na zelinář.webnode.cz. Útočník nějak (neřešme jak) zjistí heslo k e-mailu zelinář@gmail.com, a dotyčný uživatel A má v tom e-mailu uložené aktuální heslo do administrace webu, takže se útočník dostane i tam. GMail je velký poskytovatel a podepisuje e-mail DKIM, takže jsou tak podepsané i e-maily A. OK, tohle zatím dává smysl.
B v jejichž struktuře je neinfikovaný uživatel používající konkrétní verzi outlooku na konkrétních widlích se kterým A komunikuje a je u jiného providera.
B je tedy asi nějaká firma, která má nějaké zaměstnance, používají Windows a Outlook. S některým zaměstnancem firmy B běžně komunikuje osoba A.
A pošle email B, který obsahuje ten link, no a věřte nebo ne, nemusí nikdo nic otvírat a zjistíte hash toho hesla...
„Hash toho hesla“? Jakého hesla? „Toho“ je zájmeno, zájmena se používají místo (podstatných) jmen („za jméno“), tedy odkazují na něco, co bylo již dříve zmíněno. O žádném hashi hesla nebyla řeč. Jediné heslo, o kterém byla řeč, bylo heslo uživatele A. A to už útočník zná – pokud mermomocí chce znát jeho hash, může si ho spočítat.
Pokud útočník poslal jenom odkaz v e-mailu, na ten odkaz (webovou stránku) nikdo nepřistoupí do té doby, než na ten odkaz někdo neklikne a odkaz neotevře ve webovém prohlížeči. Takže žádné „nikdo nemusí nic otvírat“. Jediné, co by se mohlo v poštovním klientovi otevřít z webu „samo“, by byl například obrázek vložený do e-mailu (což pořád vyžaduje alespoň otevření toho e-mailu, ale to není pro útočníka překážka). To pak ale ten e-mail neobsahuje link, ale obrázek vložený odkazem, což je něco jiného. A hlavně je v takovém případě zbytečné, aby se útočník crcal s napadáním webového serveru, když může ten obrázek normálně vložit přímo do e-mailu.
Ano, je možné, že například knihovna pro zobrazení obrázků měla chybu, která umožňovala spuštění kódu (v tomto případě v kontextu poštovního klienta) a firma B měla neaktualizované verze Outlooku.
Rozšifrovat konkrétní hash
Víte, co je hash? Hash je jednocestná funkce, která množinu nekonečně mnoha vstupů mapuje na konečnou množinu výstupů. Jednoduchá hashovací funkce (ne kryptografická) je například taková, která z textu vezme jen poslední písmeno. Takže mapuje „a“ → „a“, „ab“ → „b“, „aba“ → „a“ atd. Když budete mít hash „a“, jak ho chcete „rozšifrovat“? Jak zjistíte, zda na vstupu bylo „a“, „aa“, „aba“, „abrakadabra“ nebo cokoli jiného končícího na „a“? Hash nemůžete rozšifrovat. Můžete nanejvýš najít nějaký vstup, který vede na konkrétní hash.
Hash samozdřejmě není nerálné rozlousknout, zvláště konkrétní typy že ano...
I jen hloupé osolené SHA-1 nerozlousknete, pokud nejste NSA nebo pokud uživatel neměl slabé heslo.
Podmínkou je to aby ten připravený skript ležel na doméně odesílatele.
Doména odesílatele je v tomto případě gmail.com, a o tom, že by na webu (pokud jste tím „skript ležel na doméně“ myslel web) gmail.com měl útočník nějaký svůj skript nebyla řeč. Navíc jste nenapsal, proč by to mělo být podmínkou. Jestli to měla být podmínka toho, aby se obrázek v e-mailu zobrazil, pak je to dost nepravděpodobné – zobrazení obrázků v poštovním klientovi se buď kompletně vypíná nebo zapíná, zobrazení obrázků pouze z webu se shodnou doménou, jako je doména adresy odesílatele, se nepoužívá. Protože to vypínání obrázků neslouží jako obrana přes exploity v obrázcích, ale jako obrana před sledováním přečtení e-mailu. A jak už jsem napsal, pokud potřebujete do poštovního klienta dostat ten správný obrázek, je nejjednodušší vložit ho přímo do e-mailu, a nemusíte řešit žádné web servery ani domény.
Kompromitací MUA B získáte hlavně heslo
Tím, že jste spustil kód v Outlooku, jste ani zdaleka nezískal heslo uživatele. Zase tak hloupé ty programy nejsou, že by si jen tak pro nic za nic držely heslo uživatele v paměti.
Čili úspěšný útok na sledování druhé schránky
K úspěšnému útoku na sledování e-mailové schránky ve firmě B máte ještě daleko, zatím jste jenom spustil svůj kód v kontextu Outlooku. Ale dobře, dejme tomu že ten kód nastavil pravidla pro přesměrování e-mailů.
Zbytek je většinou už nudný
Hlavně jste ale popsal jiný útok, než dříve, a hlavně k tomu útoku nebyl potřeba kompromitovaný účet uživatele A a útoku by nijak nezabránilo, pokud by firma B používala na svém poštovním serveru blacklist. Potřeba k tomu bylo jediné – nezáplatovaný Outlook a poslat uživateli z firmy B e-mail se správným obrázkem. Všimněte si, že účet uživatele A k tomu vůbec nebyl potřeba – útočník mohl uživateli z firmy B poslat e-mail přímo. Šlo jen o to, aby se uživateli zobrazil alespoň náhled.
Zatím jsme se tedy dostali k tomu, že na uživatele firmy byl proveden úspěšný útok, kterému by firma B předešla, pokud by místo hloupostí typu SORBS aktualizovala Outlook.
Pak se pošle nějaká faktura nebo serie faktur
Tím se vracíte ke svému prvnímu popisu útoku, nicméně to nijak nenavazuje na tento váš popis útoku. Leda že by se útočník vykašlal na exploitování firmy B, konečně by využil to, že má přístupové údaje k poštovnímu účtu uživatele A, a pokud A pravidelně posílá firmě B faktury, poslal by útočník svou upravenou fakturu. Pokud by se ve firmě B spoléhali na to, že faktura je pravá, když přišla ze správného e-mailu, měli by problém. Ovšem SORBS by tomuhle útoku taky nijak nezabránil. A pro útočníka by bylo jednodušší najít si nějakého dodavatele, který nepoužívá DKIM ani SPF a poslat fakturu přímo. Pokud ve firmě B důvěřují e-mailu bez elektronického podpisu, nebudou rozlišovat, jestli byl server ověřen přes DKIM nebo SPF (zvlášť když Outlook tu informaci ani nezobrazuje).
když předáte všechny data a sdělíte problém s návrhem konkrétního řešení tak ani neodpoví
Jestli jste jim psal stejným stylem, jako píšete tady, tak to vyhodnotili jako nigerijský spam.
Proč tomu zamezí v počáteční fázy IP blokace sorbsu jsem již psal.
Tomu, co jste popsal, SORBS nijak nezamezí. Zamezilo by tomu, kdybyste používali aktualizovaný Outlook.
Do větších detailů se nepouštím schválně, jednak takové kvantum dat není pro forum a jednak se takovéto informace nepouštějí do veřejného internetu, aby jsme samozdřejmě někoho nenaváděli a nedávaly mu zdarma návody aby nás příště obešel...
Vy se nepouštíte ani do menších detailů. Tentokrát jste alespoň popsal osoby a obsazení, to je pokrok. Ale proveditelný útok jste zase nepopsal, protože si různě protiřečíte a píšete nesmysly jako „rozšifrovat hash“, přičemž žádný hash nemáte a hash nejde rozšifrovat.
Rozhodně se nemusíte bát, že by vás někdo obešel, protože zatím jste žádný použitelný útok nepopsal.
-
když předáte všechny data a sdělíte problém s návrhem konkrétního řešení tak ani neodpoví
Jestli jste jim psal stejným stylem, jako píšete tady, tak to vyhodnotili jako nigerijský spam.
;D ;D ;D ;D ;D ;D :D :D :D :D :D :D
-
Filip Jirsák :
Jak jsem psal to byl poslední komentář dále se mi s vámi už nechce ztrácet čas. Vše bylo vysvětleno, to že se bavím o hash a vy o salt hash , které ty mailové klienty nepoužívají je prostě přesně váš styl překrucovat překrucovat, napadat ok. Snad s tím daleko dojdete, ale beze mě :D
-
to že se bavím o hash a vy o salt hash
Děkuji za definitivní důkaz, že sice používáte odborné termíny, ale vůbec netušíte, co znamenají. U vašich předchozích komentářů bylo potřeba přeci jen nějakých znalostí, aby to člověk odhalil, ale co je hash snad ví každý v téhle diskusi (až na vás, samozřejmě).
-
to že se bavím o hash a vy o salt hash
Děkuji za definitivní důkaz, že sice používáte odborné termíny, ale vůbec netušíte, co znamenají. U vašich předchozích komentářů bylo potřeba přeci jen nějakých znalostí, aby to člověk odhalil, ale co je hash snad ví každý v téhle diskusi (až na vás, samozřejmě).
Důkaz :D jako vám? Jste si vědom toho že vám nemusím nic dokazovat a vzhledem k vašemu stylu komunikce ani strácet s vámi čas ? No a já volím nestrácet. Bavte se.
-
vzhledem k vašemu stylu komunikce
(https://i.imgsafe.org/0eebe38840.jpg)
-
Me by jen zajimalo, jak cela tahle diskuse pomohla zodpovedet otazku tazatele. Rekl bych, ze z 90% nijak. Hadata se o nesmyslech, pisete nesmysly a chovate se jako banda fracku. A toz tak.
-
Me by jen zajimalo, jak cela tahle diskuse pomohla zodpovedet otazku tazatele. Rekl bych, ze z 90% nijak. Hadata se o nesmyslech, pisete nesmysly a chovate se jako banda fracku. A toz tak.
Otázka žadatele byla zodpovězena hned v první odpovědi. Google má dost serverů, takže když příjemce jednou odmítne komunikaci kvůli IP adrese klienta, příště vyjde odesílání na nějaký jiný server a ten e-mail doručí. Každopádně problém je na straně příjemce, takže jediné možné řešení je řešit to s příjemcem.
-
Me by jen zajimalo, jak cela tahle diskuse pomohla zodpovedet otazku tazatele. Rekl bych, ze z 90% nijak. Hadata se o nesmyslech, pisete nesmysly a chovate se jako banda fracku. A toz tak.
Ostatne jako jakakoliv jina diskuze na root. Zbyva jen doplnit, ze dobry programator vydelal prez 100k a pracuje v homeoffice aby mohl tvorit. A ze lopata dela za 50k.