Příspěvky

31

Server / Re: stejné reverzní DNS jméno pro víc IP , vysvětlení jedním strojem svíceIP

« kdy: 07. 01. 2022, 22:47:48 »

Teď mě to napadlo, hypoteticky, kdyby to byl jeden počítač (stroj, ne služba) co má více IP adres (klidně i na stejném rozhraní), tak by ta asimetrie více IP->jedno jméno asi  dávala smysl (i když to je jen jedna půlka problému-druhá je vrácení jedné IP pro to doménové jméno). "Prostě by měl jedno hostname v /etc/hostname" (velké zjednodušení!)

Ano, to je dobrý příklad – třeba router, který má přirozeně víc rozhraní a víc IP adres, přesto chci umět odkazovat jménem na celý router, aniž bych specifikoval, které přesně rozhraní. A pak je dobré mít pojmenovaná i jednotlivá rozhraní, takže tam by ideálně měly pro každou IP adresu existovat 2 PTR záznamy – jeden na jméno rozhraní a druhý na jméno celého routeru. Jména rozhraní by pak měla 1 A záznam vedoucí na IP adresu toho rozhraní, a jméno celého routeru by pak mělo několik A záznamů vedoucích na všechny IP adresy všech rozhraní. Ale to už záleží na politice pojmenovávání v konkrétní síti, zda je někdo hračička a pojmenuje vše takhle pečlivě.

32

Sítě / Re:Může PTR záznam X.Y.W.Z mířit na CNAME R.0/T.Y.X ? + bity v CIDR

« kdy: 07. 01. 2022, 22:25:25 »

_mbily, díky za vysvětlení, teď vidím, že to vlastně je smysluplné

Tomuto vubec nerozumim. Mozna jen reknu, ze 12.34.56.3/24 se pouziva jako oznaceni IP adresy a site zaroven (sit je 12.34.56.3 oktetovyAND s 255.255.255.0, takze na poslednim oktetu nezalezi)

No tím jsem chtěl říct,že samotné označení A.B.C.D/N může mít někdy různé(i neplatné interpretace, například 12.34.55.56/16 může být nevalidní nebo aspoň nikdy nematchující) a  plus že může znamenat víc věcí - tys přidal další - specifikaci vlastní adresy  stroje a sítě v jednom.

Ne, interpretace je vždy jedna a a vždy platná. N udává, kolik bitů (zleva) IP adresy tvoří označení sítě, zbytek pak rozlišuje konkrétní zařízení. Takže /16 vzdy označuje, že prvních 16 bitů je síť, tedy v tomto případě jde o síť 12.34.0.0 až 12.34.255.255. Zbytek rozlišuje konkrétní zařízení v síti. Lépe je to vidět v binárním zápisu:

Kód: [Vybrat]

      12.      34.      55.      56
00001100.00100010.00110111.00111000

Když zleva vezmete 16 bitů, je to:

Kód: [Vybrat]

00001100.00100010.xxxxxxxx.xxxxxxxx

x v tomhle případě znamená, že na konkrétní hodnotě (0/1) nezáleží – ať tam bude cokoli, pořád daná IP adresa patří do dané sítě.

Někdy se také maska sítě vypisuje jako čtyři bajty, pak v té masce jedničky znamenají, že příslušná hodnota označuje síť, nuly znamenají označení konkrétní IP adresy v síti. Takže maska /16 se dá také zapsat jako 255.255.0.0, tedy:

Kód: [Vybrat]

11111111.11111111.00000000.00000000

Tenhle zápis má tu výhodu, že když uděláte logické AND mezi IP adresou a maskou, a pak uděláte logické AND mezi jinou IP adresou a maskou, když vám vyjdou stejné hodnoty, jsou IP adresy ze stejné sítě, když různé hodnoty, jsou z různé sítě.

Mimochodem, to /16 udává, kolik jedniček zleva je v tomhle zápisu masky.

Tenhle zápis masky samozřejmě může mít i neplatné hodnoty, třeba tohle logicky nemůže být maska sítě:

Kód: [Vybrat]

11111111.00001111.00000000.00000000

33

Server / Re:neshody v PTR (N:1)

« kdy: 07. 01. 2022, 22:06:55 »

Našel jsem tedy jeden příklad:
{85.207.4.158+85.207.59.62} -PTR-> cnc2-smtp1.cncenter.cz -A-> 85.207.59.62 (-PTR-> cnc2-smtp1.cncenter.cz )

Takovéhle "smyčky" jsou povolené?  (že víc IP má stejné reverzní jméno, smyčka to není, ale trychtýř)? Zajímá mě to na víc úrovních (například nikdo nebrání providerovi v Brazílii nastavit stejné doménové jméno jeho zákazníkovi jako má zákazník v hostingu v japonsku). To ale není tento případ očividně, když se shodují na /16,/15,/14.... (a ostatně  v ASN blok je pro /16)

A nebo je tam chyba, že to vrací jen jednu IP adresu, ale mělo by (aspoň obě)?

Nebo je to situace naprosto v pořádku? Nebo může tato podivnost  pramenit, že neexistuje na světě jen RR typu A?

Je to trochu divné, popírá to smysl PTR – PTR by mělo ukazovat na jméno zařízení, které by z principu věci mělo být unikátní. Ale ničemu to nevadí – prostě A záznam vede na víc IP adres, tak se to jméno použilo i pro reverzní záznam. To, že by dva ISP v různých částech světa nastavili stejné doménové jméno do PTR ničemu nevadí.

To, že ten A záznam vrací jenom jednu IP adresu je proti doporučení pro PTR záznamy – pro ty by mělo (mělo, ale nemusí)  platit, že příslušný A záznam vede zase zpět (i) na původní IP adresu. Pokud by se třeba někdo pokoušel z té IP adresy 85.207.4.158 posílat e-maily, spousta serverů by to vyhodnotila jako spam, protože kontrolují, že je splněné to kolečko IP → PTR → název → A → IP. Ale pro 85.207.59.62 to nijak nevadí – i kdyby někdo zjistil (jako vy) že i pro 85.207.4.158 existuje PTR záznam vedoucí na stejné jméno, nemůže to použít pro žádnou kontrolu. To jméno cnc2-smtp1.cncenter.cz si můžu dát klidně ke své IP adrese jako reverzní záznam a majitel domény cncenter.cz nemá jak mi v tom zabránit.

A samozřejmě ta vámi popsaná situace může být jen dočasná – ať už kvůli probíhajícím změnám v DNS, nebo pro to, že se pro to doménové jméno cnc2-smtp1.cncenter.cz používá nějaké rozvažování a teď zrovna vám server vrátil jenom jednu IP adresu. Což je mimochodem důvod, proč by se neměly míchat technické názvy (které se objevují v PTR záznamech a měly by to být jednoznačné názvy zařízení) a názvy pro lidi. Tj. pro lidi mám www.example.com a to obsluhují čtyři servery alpha.example.com, beta.example.com, gama.example.com a delta.example.com. A reverzní záznamy IP adresy jednotlivých serverů povedou zase zpět na tu alphu až deltu. Na www.example.com nepovede žádný reverzní záznam, protože to není jméno žádného zařízení/serveru, ale jméno služby.

34

Server / Re:Odchozí pošta padá do spamu - vysvětlení co patří do EHLO,PTR,SPF

« kdy: 07. 01. 2022, 20:05:06 »

Jako chtěl jsem si to vypátrat sám, ale má to dva háčky: jednak množství subjektů, které to mají správně je jak zrnko v poušti (ostatně stačí se podívat po pravici ) a za druhé bych musel někde zchrastit "tcpdump" komunikace někde (pro přečtení EHLO). Dokonce i nepřímou komunikaci(myslím, že server MX dělá souběžný doménový lookup, RBL check...)

V tomhle ale neexistuje nic jako „správně“. Nejsou na to žádné standardy. Když někdo bude odmítat e-maily, kde bude  EHLO obahovat písmeno „a“, protože zjistí, že spousta spamu přišla ze spojení, kde v EHLO bylo „a“, bude prostě takové e-maily odmítat, a nic s tím neuděláte. Ale nedělal bych z toho pravidlo, že mít „a“ v EHLO je špatně.

* reverzní záznam na této IP,
* doména z reverzního záznamu musí být v EHLO hlavičce,

Přijímající SMTP server má otevřené spojení s klientem (který spojení inicioval), který chce přijímajícímu serveru doručit e-mail. Ten klient komunikuje z nějaké IP adresy, kterou server zná – a pomocí reverzního DNS záznamu si ji přeloží na DNS záznam. Server pak může dál vyhodnocovat tenhle DNS záznam – třeba jestli neobsahuje číslice. Nebo ho přeloží zpět na IP adresu a zkoumá, zda mezi přeloženými IP adresami je i ta původní IP adresa klienta. A nebo může ověřovat, zda doména z toho reverzního záznamu se objeví v EHLO hlavičce, kterou klient pošle. Asi protože pro spammera je hrozně obtížné zjistit si reverzí DNS záznam počítače, odkud zkouší spam odeslat – musel by udělat jeden DNS dotaz navíc…

A co se tedy má s čím rovnat?

Doména z MAIL FROM a SPF. Někdo porovnává EHLO a reverzní DNS záznam. Mezi MAIL FROM a EHLO nebo reverzním DNS záznamem není vůbec žádný vztah.

Jo a taky je mi divné, proč se uvádí pořád jako port (MSA-MTA/ MTA-MX) 25? Vždyť to snad nemůže být od roku 2016 pravda....

Snad všude funguje MSA pořád i na portu 25. Port 587 pro MSA se zaváděl proto, aby bylo možné v síti zablokovat odchozí komunikaci na port 25 a tím zabránit spamování z napadených počítačů. Když pak MSA naslouchá na portech 25 i 587, ničemu to nevadí – klienti, kteří mají zablokovaný port 25, se připojí na port 587, a případně nějaká důvěryhodná zařízení se starší konfigurací mohou dál používat pro předání e-mailu MSA dál port 25.

35

Hardware / Re:Flash disk se zabezpečením

« kdy: 05. 01. 2022, 19:46:53 »

Tady je článek odemčený: https://tech.hn.cz/c7-59201540-c8dj8-61d2bbf66ea9214

Michal Altair Valášek nedělal vlastí bezpečnostní analýzu. Ale některé kandidáty odfiltruje už to, že mají jen softwarové šifrování nebo známé bezpečnostní slabiny (o těch psal Michal myslím jinde, možná na svém blogu). A naopak pokud chcete něco opravdu bezpečného, jsou v přehledu i disky s FIPS certifikací.

Na key derivation funkci podle mne tolik nezáleží – pokud nebude vyloženě špatná a nebude snižovat entropii. Sebelepší funkce ale entropii nevyčaruje. Ta ochrana PINem je bezpečná samozřejmě jedině tehdy, pokud se klíč po několika neúspěšných pokusech nenávratně zničí.

Nicméně já jsem si flashku s hardwarovou klávesnicí nepořizoval kvůli obavě z keyloggerů nebo něčeho takového. Nýbrž z toho důvodu, že to nepotřebuje žádný obslužný software a funguje to tedy na jakémkoli zařízení, které je schopné pracovat s obecným flash diskem. Protože ten disk odemknete před připojením k počítači a v okamžiku připojení se to pro OS tváří jako úplně normální flashka. Můj přístup nebyl „1. hlavně ať se tam nikdo nedostane, 2. při splnění bodu 1 bude fajn, když se k datům aspoň někdy dostanu já“, ale opačný „1. ať se k datům vždy dostanu já, 2. bude fajn, když se při splnění bodu 1 k datům nedostane někdo, kdo tu flashku někde najde, až mi vypadne z kapsy“.

36

Server / Re:Gmail zahazuje maily?

« kdy: 04. 01. 2022, 19:28:34 »

V pripade preposilani mailu s SPF/DKIM na Gmail je naprosto nutne pridat ARC-Seal. A nejlepe podruhe podepsat vlastnim DKIM.

Třikrát sláva, už po 8 letech od standardizace DKIM a 19 let po představení konceptu SPF si někdo všiml, že se e-maily přeposílají. Každopádně díky za odkaz, já jsem čekání asi po 15 letech vzdal, takže ARC-Seal mi uniklo.

37

Server / Re:Gmail zahazuje maily?

« kdy: 03. 01. 2022, 19:27:55 »

Přesto mi google poštu vrátí. Co jsem udělal špatně?

Křišťálovou kouli mám zrovna v servisu. Možná kdybyste prozradil, s jakou chybovou vám Google e-mail odmítne, může vám někdo poradit.

38

Vývoj / Re:Odesílá php mail() přímo cílovému SMTP?

« kdy: 02. 01. 2022, 20:24:53 »

Ano, hledám řešení, které bude komunikovat  přímo s MX serverem pro danou doménu příjemce

Libovolný plnohodnotný poštovní server – Postfix, Exim, qmail, Sendmail, Microsoft Exchange. Už jsem to tu psal. Nějaké řešení jako naprogramovat si plnohodtného SMTP klienta s frontou a DKIM podepisováním je nesmysl.

No a tady vzniká spor: proč tedy mx server (ne smtp) těch domén po mě chtěl credentials, když posílám z jiné domény?

Protože ten server neobsluhuje doménu, na kterou e-mail posíláte. Server tedy usoudí, že po něm chcete, aby zařídil odeslání předávaného e-mailu – a to dělá jenom pro „své“ uživatele, kteří se autentizují jménem a heslem.

Je to rozdíl mezi MTA (Mail transfer agent) a MDA (Mail delivery agent). MDA naslouchá na portu 25 a doručuje e-maily pro konkrétní doménu (nebo domény) do schránek. MTA naproti tomu převezme e-mail od klienta (poštovní program jako Thunderbird nebo funkce mail() v PHP), zařadí jej do fronty a pak se jej pokouší předat cílovému MTA. MDA vyžaduje obvykle autentizaci jménem a heslem – musí vědět, že doručuje e-mail pro „své“ klienty. MDA naslouchá na portu 587. Dříve ale MDA také naslouchal na portu 25, obvykle to z důvodu zpětné kompatibility zůstává zachováno – takže v tom vašem případě jste se připojil právě k MDA.

No a tady vzniká spor: proč tedy mx server (ne smtp) těch domén po mě chtěl credentials, když posílám z jiné domény?

Chtěl je po vás proto, že jste komunikoval se serverem, který neobsluhuje schránky pro doménu, kam jste chtěl e-mail doručit. Nekomunikoval jste se serverem, který byste nalezl v DNS (pod MX nebo jako A/AAAA záznam). Pokud jste se k němu chtěl připojit, ale připojil jste se k jinému serveru, nejspíš váš ISP unáší provoz na portu 25 na svůj server.

A jde mi spíš o proof of concept

Pořád ale envím, co má být cílem. Naimplementovat plnohodnotný MTA v PHP?

39

Vývoj / Re:Odesílá php mail() přímo cílovému SMTP?

« kdy: 02. 01. 2022, 10:12:07 »

na win ale nic takoveho neni.. takze to nejspis MUSI komunikovat s cilovym MX

Ano, na Windows nic takového není. PHP mail() pak ale nekomunikuje přímo s cílovým serverem, ale s nějakým místním serverem, kterému předá e-mail k odeslání. Stejně, jako to dělá třeba Thunderbird nebo jakýkoli jiný poštovní klient.

Ten hlavní bude asi ten, že se nedá očekávat, že na všech cílových SMTP serverech budete mít Váš vlastní účet, kterým se na ně přihlásíte.

Tohle je nesmysl. Když někam posíláte e-mail, žádný účet na tom serveru samozřejmě nemáte.

Důvod, proč běžný klient (ať už funkce mail() nebo třeba Thunderbird) neposílá rovnou cílovému serveru, je ten, že  takové odesílání je docela komplikovaná věc, která zahrnuje např. udržování fronty zpráv k odeslání a opakované pokusy o odeslání e-mailů z té fronty. Je nesmyslné něco takového programovat v každém klientovi zvlášť, navíc PHP ani Thunderbird neběží trvale, takže by nemohly obsluhovat tu frontu zpráv k odeslání.

Asi by bylo lepší popsat svůj primární problém a na ten potom hledat řešení.

Souhlas.

40

Vývoj / Re:JS Promise

« kdy: 01. 01. 2022, 19:51:33 »

Tvoje "Čistší, jednodušší, průhlednější, kratší." riesenie exportuje internu implementaciu funkcie ktoru caller nema vobec so riesit.

Vy stále nevíte, co ten váš kód vlastně dělá a co má dělat. Caller neexportuje žádnou interní implementaci. Caller exportuje API, ve kterém je funkce, kterou se oznamuje, že už o data nemáte zájem.

Inak povedane, caller len doda funciu na spracovanie dat a "funkciu" na oznamenie ked uz o data nema zuajem.

Tak si tohle rozeberte pořádně. Kdo komu oznamuje (posílá zprávu), že o data nemá zájem? Konzument zpráv a nebo stream? A volání funkce znamená poslání zprávy nebo přijetí zprávy?

ta funkcia streamData je iba jedna z mnohych funkcii a patri do api kniznice kde sa pracuje s promismi(axios) takze musi mat totoznu logiku ako vsetky ostatne funkcie, ktore nemaju navratovu hodnotu. preto som nemohol/nechcel nic vratit.

Tohle jste ale v popisu problému nenapsal. Navíc ta vaše funkce nemá totožnou logiku jako něco jiného, vaše funkce nemá žádnou logiku. To, zda funkce má nebo nemá návratovou hodnotu, není věcí logiky, ale pouze návrhu API.

ano, hovorit o exportovani internej implementacie je prehnane kedze sme v javascripte, je to zvyk.

Ale JavaScript samozřejmě umí omezení platnosti proměnných, nové verze dokonce umí i privátní proměnné a metody.

Na začátku jste psal, že JavaScript není vaše doména. Použít v takovém případě nesmyslné řešení, kterému navíc nerozumíte, když máte k dispozici správné řešení, je dost hloupé. Ale je to váš (marný) boj, když trváte na tom, že to musíte mít špatně, mějte si to špatně. Já jenom doufám, že ten kód nikdy nepotkám, ani jako uživatel.

41

Vývoj / Re:JS Promise

« kdy: 01. 01. 2022, 09:34:07 »

neni to stejne https://stackoverflow.com/a/17308358

deferred umoznuje resolvovat a rejectovat manualne z vnejsku, ES6 promisy nemaji deferred interface.

Je to stejná implementace. Promise i defer/deferred je obecné označení pro objekt, který umožňuje volat kód „později“, při splnění nějaké podmínky. Případně se to někdy používá pro označení konkrétní části rozhraní – promise je ta část rozhraní, která umožňuje reagovat, defer/deferred je ta část rozhraní, která může aktivovat reakci. Ale implementace je stejná, protože aby to k něčemu bylo, potřebujete vždy obě dvě části – jak spouštěč, tak posluchač.

Váš kód umožňuje resolvovat Promise manuálně z vnějššku, takže to Promise evidentně umožňuje.

Promise je low level koncept, ktery jde prirozene pouzit v jakemkoliv kodu, ktery na neco ceka (v tazatelove pripade na ukonceni)

Ne, v tazatelově případu se nečeká na ukončení. Tazatel chce naopak ukončení ručně vyvolat. Ten směr je opačný – a asi to mate nejen tazetele, ale i vás.

42

Vývoj / Re:JS Promise

« kdy: 31. 12. 2021, 21:34:09 »

tazatel ma jasno, ale Jirsak a L. neodpovidaji na jeho otazku.

Ne, tazatel nemá jasno. Já a L.. jsme popsali správné řešení jeho problému (když jsme se konečně dozvěděli, jaký problém řeší). Zato vaše odpovědi jsou zmatené – tazatel se ptá, jak má použít Promise, a vy mu odpovíte, že má použít Defer/Deferred, což je jenom jiný název pro Promise. A použití Promise je v tazatelově případu nesmysl, protože Promise se používá v případech, kdy mám nějaký proces, který běží z pohledu mého kódu asynchronně na pozadí a já potřebuji být informován o jeho dokončení. Tady je to ale opačný případ, tazatel nechci být informován o dokončení, ale naopak chce asynchronní proces ukončit – směr té komunikace je opačný. Promise se tam dá vnutit, jak jsem psal hned v první odpovědi, ale je to matoucí. A matoucí kód je špatně, protože často nepoznáte, jestli v něm je nebo není chyba – a pokud to poznáte teď, nepoznáte to vy nebo někdo jiný později, až ten kód budete upravovat.

43

Vývoj / Re:JS Promise

« kdy: 31. 12. 2021, 16:50:44 »

on presne specifikoval, jake chce API.

Což nic nemění na tom, že je to nesmysl.

ja bych asi pouzil tohle https://www.npmjs.com/package/p-defer

Ano, zejména by bylo dobré se držet té tučné červené věty na začátku: „Don't use this unless you know what you're doing.“

44

Vývoj / Re:JS Promise

« kdy: 31. 12. 2021, 15:45:59 »

Kód: [Vybrat]

function Closer() {
    let r;
    const p = new Promise((resolve, reject) => {
        r = resolve
    });
    p.resolve = r;
    return p;
}

const closer = Closer();

toto som hladal, diky. zatial to funguje, ak to bude robit neskor problemy tak to prerobim. eventuelne mozno pouzijem websocket a budem to riesit uplne inak.

Když odstraníte to zbytečné Promise, dostanete kód, o kterém jsem psal já a L..

45

Odkladiště / Re:shodnost IP adres po zřetězeném resolvování ?-PTR-A-?

« kdy: 31. 12. 2021, 11:18:34 »

PTR záznamy spravuje ten, komu patří příslušný blok IP adres. Typicky tedy ISP, větší instituce mohou mít své vlastní bloky adres.