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 ... 268 269 [270] 271 272 ... 375
4036
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 13. 02. 2017, 09:52:51 »
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.

4037
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 12. 02. 2017, 09:25:57 »
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ě).

4038
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 17:40:50 »
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.

4039
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 16:20:39 »
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é.

4040
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 12:51:31 »
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), 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í).

4041
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 12:13:34 »
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.

4042
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 11:41:36 »
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.

4043
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 09:56:32 »
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.

4044
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 11. 02. 2017, 09:47:55 »
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.

4045
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 10. 02. 2017, 20:26:32 »
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.

4046
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 09. 02. 2017, 21:49:27 »
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í.

4047
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 09. 02. 2017, 07:19:31 »
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…

4048
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 08. 02. 2017, 21:36:35 »
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.

4049
Server / Re:IP adresy Gmailu jsou na blacklistu SORBS DNSBL
« kdy: 07. 02. 2017, 11:08:52 »
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ů.

4050
Server / Re:Hlavička „Received“ v e-mailové komunikaci
« kdy: 06. 02. 2017, 21:16:32 »
toto zabezpeci, ze na mojom serveri bude postfix nacuvat len na tychto ip adresach
Kód: [Vybrat]
inet_interfaces = VIRTUAL.IP.ADD.RESS, 127.0.0.1

a toto zabezpeci, ze postfix z mojho servera pri komunikacii s inym serverom bude komunikovat vyhradne z VIRTUAL.IP.ADD.RESS ip adresy
Kód: [Vybrat]
smtp_bind_address = VIRTUAL.IP.ADD.RESS

rozumiem tomu spravne?
Ano.

Stran: 1 ... 268 269 [270] 271 272 ... 375