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.
DNS server neví, co uživatel hledá na nějakém tiktoku. DNS server tak maximálně ví, že uživatel chce na tiktok.duchovic ale nechtěl vědět, co uživatel hledá na TikToku. Chce zablokovat přístup na TikTok.
A opet tu mame jirsaka a opet vubec netusi o cem zvani. Jirsaku, email klidne podepsany byt muze, klient klidne muze tvrdit ze je vse OK, protoze jedine co tak overi, ze podpis je od nejake CA a presto to nic nevypovida o tom, kdo ho odeslal. A ucetni vazne nebude overovat, jestli CA ktere ten podpis vydala je ta spravna.OK, dělám si u vás čárku, že ani elektronickým podpisům nerozumíte.
Zase předvádíte svoji natvrdlost. Pokud ve firmě nepoužívají podepisování a oni to nepoužívají, protože to v normálním obchodním styku nepoužívá nikdo, kdo nemusí, tak to žádná jediná možnost není.To, jestli vy něco používáte nebo nepoužíváte, nemá žádný vliv na to, zda to existuje nebo neexistuje. Když napíšu, že z Evropy do Austrálie se můžete dostat lodí nebo letadlem, nic na tom nemění fakt, že jste v Austrálii nikdy nebyl – i tak ta možnost dostat se tam z Evropy lodí nebo letadlem zůstává.
Například se používá ověření separátním kanálem - hovor, telefon, teams a podobně.Což ale není ověření e-mailu, nýbrž výměna informací jiným kanálem. Teda pokud si po telefonu nediktujete hash e-mailu…
Snažím se sdělit, že vaše domněnka o používání podpisu je mylná, v obyčejných korporátech a firmách (nebankovních) se el. podepisování emailů nepoužívá a ani nevyžaduje, proto se o tom neškolí, tudíž poznámka o tom že nějaký podpis pomůže nějaké hypotetické účetní rozpoznat fake email je mimo.Dobře, pokusím se vám to vysvětlit ještě jednou, třeba to napodruhé pochopíte.
Stejně jako vaše představa, že když účetní přijde email od vrchního šéfa s fakturou, tak si sedne na zadek a hned posílá miliony na kajmany.Jak jsem psal, útočníci dovedou být přesvědčiví. Vůbec to nemusí být na Kajmany, klidně to může být účet u české banky. Takovéhle útoky se dějí, občas se to objeví i v médiích. Tu falešná faktura; tu někdo vybral statisíce z účtu a ládoval je do bitcoinmatu; tu se někdo domněle přihlašoval ke státnímu webu a při tom potvrdil převod peněz z účtu; tu někdo prodává na bazaru a údajnému kupujícímu pošle údaje o své platební kartě… Vy tvrdíte, že se to neděje, ale opak je pravdou.
V normální firmě jsou na platby procesy a musí se dodržovat. Jednak musí k té faktuře najít příslušnou objednávku a druhak musí najít potvrzení, že byla plněna, a třeťak takovýto podezřelý email zcela jistě ověří minimálně telefonátem. Krom toho ověří dodavatele v databázi, kde je také uvedený dohodnutý účet kam se posílá. Z toho všeho musí i imbecil poznat, že je něco v nepořádku. A el. podepsání emailu v tom procesu nehraje žádnou roli.Útočníci dovedou být přesvědčiví. Oni se „živí“ tím, aby dotyčného přesvědčili, že to je opravdu urgentní a na standardní procesy se má dotyčný vykašlat, protože tohle fakt spěchá a je důležité, aby se to udělalo co nejdřív. A neotravujte mne telefonováním, protože jsem teď na důležitém jednání, telefon nevezmu a očekávám, že až to jednání skončí, peníze už budou převedené.
Takže žádná osvěta a školení ani neexistuje, tudíž poznámka o vzdělávání v tomto je mimo mísu.Pokud by šlo jen o ten e-mail, je to maximálně na 10 minut povídání, na to nepotřebujete žádné extra školení. Jinak je to součástí školení o kyberbezpečnosti, které podle mne mají mnohé subjekty povinné. Nebo třeba CZ.NIC má různá vzdělávací videa.
Email je v současné době braný jako alternativní forma komunikace - něco jako archaický wacap nebo týms.A jak by měl být braný jinak, když to je forma komunikace? U papírových dopisů nebo telefonů se lidé také naučili, jak je používat, není důvod, proč by se to nenaučili s e-mailem.
Takže pokud by nějaká účetní proplatila něco na fejk fakturu, tak má v účetnictví a pravděpodobně i ve firmě bordel a špatně nastavená pravidla a procesy. Tam by školení bylo na místě.Podvodníci umí být dost vynalézaví a přesvědčiví. Pokud účetní přijde e-mail „od šéfa“, že je nějaká faktura neuhrazená, že tím firmě hrozí škoda v milionech a že jestli to okamžitě neuhradí, dostane okamžitou výpověď a ty miliony po ní bude vymáhat, půjdou zaběhané procesy stranou. Právě proto má ta účetní (a nejen ona) projít školením, aby věděla, že ten e-mail nemusí být od šéfa, i když se tak tváří, a věděla, že se toho problému nejspíš může velice rychle zbavit tak, že si ověří, zda ten e-mail opravdu je od šéfa (a zjistí, že není).
[/quote]... Když pak přijde e-mail s odesílatelem z vaší domény, ale bez podpisu, je jasné, že je ten e-mail podvržený...Pardon, ale toto neplatí. S použitím čistě jen DKIMu nemá přijímající strana jak zjistit, že mail měl být podepsán. Příjemce kontrolou případného existujícího podpisu pouze ověřuje, zda tělo mailu a vybrané hlavičky nebyly při transportu nějak změněny.
Magistrat blokuje pristup z privatnich IP u sluzby, ktera je otevrena do Internetu? (porty tcp_80,443)Ano, má to logiku. Pokud má ISP správně nastavenou svou síť, privátní adresy se nemají jak na firewall magistrátu dostat. A pokud má ISP svou sít nakonfigurovanou špatně, má si konfiguraci opravit.
Vazne ma tohle nejakou logiku?
Magistrat blokuje pristup z privatnich IPMagistrát se privátních subnetů bát nemusí. Ale je to provoz, který nemá v internetu co dělat a pokud se tam vyskytne, je to chyba.
takze Magistrat se boji Privatnich Subnetu, ale uz se vlastne vubec neboji celeho verejneho IPv4 adresniho rozsahu, kde hrozi to opravdove nebezpeci?
Muj nazor je, ze tomu borci z Magistratu vubec nerozumi a misto toho, aby to vyresili na svem firewallu vymlouvaji se na ISP....za me dosti prasarna a idiotismus....a jediny kdo to odsere jsou obyvatele mesta Noveho Jicina, vcetne me.....Evidentně tomu nerozumíte vy. To není výmluva na ISP – pokud je to tak, jak se tu o tom diskutovalo, je to chyba ISP. Privátní IP rozsahy jsou privátní proto, že nejsou routovatelné ve veřejném internetu, tudíž je ISP vůbec nemá do veřejného internetu pouštět.
Zkusim jim napsat otevreny dopis a klidne to dam do novin, protoze jako obcan mam snad alespon nejake pravo se dostat na stranky mesta (obecne info, odpady, oteviraci doba atd atd..)Než se budete veřejně ztrapňovat v novinách, zkuste pochopit, že je to problém ISP. A asi bude lepší napsat nejprve na podporu ISP než ho rovnou vláčet v novinách.
ja si vazne nemyslim, ze je chyba na strane ISP, protoze uplne stejny model, kdy mam v siti centralni NATy, pouzivam ve sve siti a menit to vazne nehodlam....design je jednoduchy a funkcni...To, že něco používáte a nehodláte to měnit, neříká nic o tom, jestli je to správně nebo ne.
A hlavne to pravidlo, ktere to blokuje je na strane Magistratu Noveho Jicina, muj ISP nic neblokuje ;-)Váš ISP špatně překládá adresy.
Kdyby tam nekdo alespon vedel co jsou to iptables, tak si tam nastavi vyjimku a vsichni jsou spokojeni, jenze.....Firewall nejsou jen iptables. Podstatné je ale to, aby to konfiguroval někdo, kdo rozumí sítím. To samé platí i u ISP, tam snad ještě víc. U vás je to něco jiného – to, že nerozumíte sítím, je v zásaě jen váš problém, maximálně se ztrapníte v diskusi na Rootu nebo v novinách. Ale ISP má mít svou síť nakonfigurovanou správně a na veřejné IP adresy svých zákazníků neposílat pakety s privátními IP adresami. A mezi privátními IP adresami svých zákazníků nemá dovolit komunikaci vůbec.
Nepropálení FQDN bez TLSK čemu to má být dobré?
Klient sám zahájí komunikaci příkazem EHLO, takže to, co server podporuje nebo omezuje, uvidí. Jen tu komunikaci klient vede na port 587 (submit) s povinnou autentizací a šifrováním - STARTTLS. Klient může použít i porty 25/STARTTLS nebo 465/SSL, ale server to nemusí akceptovat.Myslím, že to bylo myšleno tak, že klient odesílá e-mail „svému“ serveru (přes Message submission) a tam nějaké omezení velikosti v komunikaci není až tak zajímavé, protože často bude řešené jiným způsobem (např. Outlook asi nebude nakonfigurován tak, aby povoloval odeslat větší e-mail, než kolik dovoluje „jeho“ Exchange). Omezení na velikost je zajímavé u vzdáleného serveru, takže při komunikaci MTA–MTA. A tohle omezení ten původní odesílající klient nevidí, takže se otmu nemůže přizpůsobit. Ve chvíli, když se odesílající MTA dozví, že cílový MTA přijme max. 10 MB e-mail, má už doručení e-mailu na svých bedrech a jediné, co může udělat, je poslat klientovi bounce. (Nebo taky může e-mail zahodit, ale tvařme se, že jsme v ideálním světě, kde se e-maily nezahazují.)
Komunikace sama o sobě je ale stejnými příkazy protokolu SMTP.
Exchange to udělá stejně, když klient není Outlook.
Zmátlo mne to špatné odsazení.CitaceTen současný kód máte udělaný tak, že se serverem může komunikovat vždy jen jeden klient.Toto není pravda i když to tak na první pohled vypadá.
funkceNe, není to omezující. Takhle fungují servery na unixech desítky let. Server poslouchá na portu, čeká na nové příchozí spojení (čeká = blokuje). Když přijde spojení od klienta, proces se forkne, fork zpracovává příchozí spojení a původní proces se vrátí k čekání. Takhle vypadá typický unixový server už asi tak půl století. Případně místo forkování se může vytvořit nové vlákno, což se používá třeba na Windows, kde vytvoření nového procesu není tak levná záležitost, jako na linuxu. Neblokující volání je módní výstřelek posledních pár desetiletí, ale to blokující volání není nic, co by vám v něčem bránilo.Citacessh_bind_accept(sshbind, session)je pro mě blokující. Jakmile jí tedy zavolám tak neskončí dokud se žádnej klient nepokusí navázat spojení. To je pokud chcete komunikovat s více zařízeními dost omezující nemyslíte?
Nevím jak to dělá někdo kdo to umí ale já to řeším tak, že celý příjem SSH spojení běží ve vlastním vlákně. Jakmile je spojení přijato, předávám přes mutex deskriptor navázaného spojení hlavnímu vláknu. Jakmile je deskriptor předaný tak se vracím opět kNo a jste si jist, že tohle všechno máte správně? Nemůže tam někde dojít k deadlocku? Předáváte si správně data mezi vlákny? Nemůže dojít k blokování v tom pracovním vlákně?Citacessh_bind_accept(sshbind, session)a čekám na další spojení. Vlákno tedy jen čeká v blokující funkci a jakmile vrátí příjem, předá ukazatel a opakuje se. Veškeré odbavení spojení jako příjem, odeslání a ukončení je už řešeno jako neblokující v jiném vlákně. Tenhle princip mi funguje a zkoušel jsem i takové experimenty, že jsem si na úplně jiném počítači vytvořil tisíce SSH klientů, které se trvale jen připojovali a odpojovali. Veškeré mé pokusy a omyly vždy vedly ke stejnému závěru. Tím je právě ta blokující funkce, takže se furt točím dokola.
Ceho chces dosahnout?mikesznovu obvykle chce nějaký nesmysl a místo, aby si to zjistil sám, zaměstnává tím lidi na fóru. Je to past na lidi, kteří se snaží pomoci.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.