Příspěvky

241

Odkladiště / Re:Expirace u domény .eu

« kdy: 27. 05. 2018, 10:19:31 »

Já jsem ale moula. Omlouvám se... toho jsem si fakt nikdy předtím nevšiml, obvykle na EURid nechodívám. Tak jsem pátral a pátral... a vypadá to, že expiry date zobrazuje pouze registrátor, nikoliv správce domény.

Zřejmě nějaký (ne úplně logický) pokus o ochranu proti převzetí domény těsně po expiraci / karanténě... V tuhle chvíli mně nenapadá lepší důvod.

Pak tedy zkusit přes registrátora (ten je ve WHOIS EURidu zobrazen).

Ono to je ve skutečnosti tak, že domény .eu vlastně nikdy neexipirují – každý rok se automaticky prodlouží a registrátorovi se naúčtuje poplatek za prodloužení, bez ohledu na to, jestli držitel domény o prodloužení žádal nebo ne. Pokud tedy registrátor nemá mandát k prodloužení domény od jejího držitele, musí to být on, kdo v posledním dni před prodloužením zadá požadavek na odstranění domény z registru. Proto je logické, že datum expirace existuje jen u registrátora.

242

Server / Re:IPv6 adresa pro web

« kdy: 02. 05. 2018, 16:39:12 »

Není přístupný, už jen z toho důvodu, že v DNS je pouze A záznam, tedy pouze IPv4 adresa.

243

Software / Re:Jak spravne pouzivat sshfs

« kdy: 05. 04. 2018, 13:41:17 »

Asi hledáš uživatelský příkaz pro odpojení:

Kód: [Vybrat]

$ fusermount -u /path/to/mount

Svazek SSHFS bys stejně jako každý jiný síťový svazek měl odpojit ještě před tím, než se od sítě odpojíš. Během odpojování se vyprázdní veškeré buffery.

244

Sítě / Re:Zneužití otevřeného rekurzivního DNS

« kdy: 30. 03. 2018, 16:14:21 »

No zatial som sa nedozvedel nic. Z prednasky v anglictine totalne nic, lebo neovladam jazyk a z textu velmi malo. Skor hladam nieco v cz/sk.

Filip Jirsák ti poskytnul přesnou odpověď na tvůj dotaz v cs (žádný jazyk cz mimochodem neexistuje). Vzhledem k tomu, že jsi ji i odcitoval, tak soudím, že jsi ji i přečetl, tak kde je problém?

Dobre co som sa uz davnejsie docital, tak podla mna to funguje nejak takto.

Ne, nefunguje.

Obycajny klient, napisanim internetovej adresy do url web prehliadaca spusti proces, kde sa odosle paket (kde v lavicke su nejake data, cielova ip, port a zdrojova ip port + .... ine ) s  priznakom syn.

Takže znovu: DNS = UDP. UDP = žádný SYN - žádné takové příznaky tam nejsou, je to prostě jen jedna zpráva.

Paket ide najprv do lokalneho resolvera a ked adresu nenajde, tak posiela paket na korenovy DNS (autoritativny).

DNS paket z prohlížeče jde jen do lokálního resolveru. Je starostí lokálního resolveru najít na ten dotaz odpověď postupným dotazováním autoritativních serverů (proto se taky jmenuje resolver – resolve znamená anglicky vyřešit).

Korenovy DNS resolveru vrati paket len s dalsimi DNS servermi (o uroven nizsimi) a tym jeho uloha skoncila. Tak to postupuje az k poslednemu DNS serveru, na ktorom sa nachachadza aj internetova adresa, na ktoru sa klient dotazoval.

Ano, tak nějak probíhá práce resolveru.

Neviem ci len na posledny DNS (alebo na vsetky), resolver posiela paket s priznakom syn, kde DNS vracia paket s priznakom syn ack a klient to potvrdzuje paketom ack (neviem to presne). Cize ak nastane podanie ruk, spojenie sa vytvori a je vybavene.

Znovu, DNS = UDP, UDP = jednotlivé zprávy bez jakékoli návaznosti, žádný syn, žádný ack. Resolver pošle každému autoritativnímu serveru UDP zprávu a přijme UDP odpověď. Až se dobere k finální odpovědi, vyrobí UDP zprávu, kterou pošle původnímu tazateli.

Ako sa to da zneuzit ??

Přesně, jak psal Filip Jirsák výše.

Staci ze utocnik zasiela na DNS server pakety s falosnou IP adresou v hlavicke a DNS vracia odpoved na sfalsovanu IP adresu, ale kedze tato IP adresa nic neziadala, tak nemoze poslat potvrdzovaci paket.

Oběť nemusí nic posílat. Podstata útoku je v tom, že je oběť zahlcena nevyžádanými odpověďmi na dotazy které nepokládala.

DNS server tak v intervaloch zasiela paket, ale druha strana stale mlci.
Utocnik zasiela v jednom case desattisice falosnych paketov az vytazi DNS server, ked tak urobi viac utocniko, tak to nevydrzi linka a server spadne.
Co ma z toho utocnik ??
Len to ze DNS sa stane nedostupnym ??

Útočník chce především zahltit linku oběti. Takže bude posílat spoustu malých dotazů na spoustu otevřených resolverů po světě tak, aby všechny odpovídaly do jednoho místa.

245

Server / Re:Postfix s MySQL

« kdy: 23. 02. 2018, 20:11:37 »

Do tabulky vkladam uzivatelov s heslom.

Kód: [Vybrat]

INSERT INTO `mailserver`.`virtual_users`
  (`id`, `domain_id`, `password` , `email`)
VALUES
  ('1', '1', ENCRYPT('password', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email1@example.com'),
  ('2', '1', ENCRYPT('password', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'email2@example.com');

Moja otazka je, aky by bol rozdiel, keby to  vkladam sposobom
 

Kód: [Vybrat]

 ('1', '1', MD5('password'), 'email1@example.com')

Aky je v tom rozdiel?

V prvním případě se do databáze ukládá osolený SHA-512 hash, ve formátu funkce crypt(3). V druhém případě se heslo pouze hashuje MD5 bez soli, což je velmi špatný nápad. Taky to nejspíš nebude fungovat, pokud Postfix očekává záznam ve formátu crypt.

Popripade ak by mi mohol niekto povedat, co znamena/robi ENCRYPT('password', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16)))

• RAND() - vygeneruje náhodné číslo
• SHA(RAND()) - Spočítá SHA-1 náhodného čísla
• SUBSTRING(SHA(RAND()), -16) - Odřízne z výsledku posledních 16 číslic
• CONCAT('$6$', …) - Připojí na začátek řetězec $6$
• ENCRYPT('password', …) - Zavolá knihovní funkci crypt(3)

246

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 19. 02. 2018, 08:52:00 »

To je O2 xDSL? Tak v tom případě je asi nejlepší přepnout modem do režimu bridge a navazovat PPPoE spojení přímo z routeru. Pokud je tam ovšem víc LAN sítí, nepomůže ani tohle.

Naopak pomůže hlasování peněženkou. Stejnou službu je možné koupit buď od T-Mobile, nebo nově i od Metronet, kde by měla IPv6 rozumně fungovat.

247

Hardware / Re:Set-top-box pro DVB-T2 s podporou CEC

« kdy: 18. 02. 2018, 10:21:36 »

Něco od TechniSatu by byla jistota, třeba nejlevnější Digipal T2, který má HDMI CEC neboli TechniLink.

Po zkušenosti s (poměrně drahým) Technisat Digipal na DVB-T, který nezvládne dekódovat field-based MPEG2 kompresi a řešením je jedině nahradit ho nejlevnějším čínským šmejdem, který s tím problém nemá, mám o té značce trochu pochybnosti. Testování na shodu s normou by měl být základ každého slušného výrobku.

248

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 13. 02. 2018, 23:03:38 »

Tohle je hodně nekompletní prohlášení neboť jste zapomněl uvést předpoklady za kterých platí, dovolte mi je doplnit:

1) router zákazníka je schopen poslat DHCPv6 PD požadavek

Ještě si dovolím tento výčet doplnit o nutný požadavek, že router musí být řádně napájen elektrickým proudem

2) router zákazníka je schopen zpracovat DHCPv6 PD odpověď a to i v případě že není úplně podle jeho představ (např. má jiný než očekávaný rozsah, viděl jsem už bohužel routery které jiný rozsah než přesně /64 nezvládaly, a teoretickou záležitost s delegováním širšího rozsahu dalším routerům opět přes DHCPv6 PD jsem ještě neviděl fungovat nikdy)

Doporučuji vyzkoušet OpenWRT Barrier Breaker, nebo jakýkoli novější, včetně TurrisOS, tam popsané funguje naprosto rutinně. Stejně tak na jakémkoli Mikrotiku, tam je ale potřeba to nakonfigurovat.

3) zařízení za routerem zákazníka dokáží od routeru získat IPv6 adresy a to protokolem který ten router podporuje (včetně IP adres DNS serverů)

Znáte router, který na LAN straně nepodporuje SLAAC? Proč je tak důležité mít IPv6 adresy DNS serverů, když na LAN rozhraní je i IPv4?

Ano, nepochybně existují zařízení v různém stádiu rozbitosti, ale to je obecně platné na cokoli.

249

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 13. 02. 2018, 22:54:00 »

S IPv6 si netykám a tápu ve tvých otázkách, ale díky za ochotu.
Tak nějak mi bylo od ISP naznačeno, že prefix /56 by byl problém, proto jsem chtěl využít přidělený prefix /64, který jsem chtěl přes dvě rozhraní (WAN-LAN) dostat dovnitř sítě, s tím že bych využil DHCPv6 od ISP (u IPv4 bych stále NAToval).

Doporučuji na tom požadavku na delegovaný prefix /56 trvat. I ISP se to musí někde naučit jak se s IPv6 pracuje. A čím míň lidí je bude tlačit do správného a standardního řešení, tím víc se budou objevovat různé fušeřiny.

U OpenVPN jsem si udělal podsíť s prefixem /112 podle tohoto návodu. U tohodle IPv6 testu mám 19 bodů z 20 (akorát bez hostname). To mi teoreticky stačí, akorát nevyužiji plnou rychlost sítě díky tomu prehistorickému TAP adaptéru.

To je pěkný návod, díky za něj. Používá techniku Proxy NDP, o které jsem psal. Ta dokáže fungovat i s nativním IPv6 na ethernetu. Jediný rozdíl je, že u ProxyNDP v kernelu je nutné vyjmenovat všechny IPv6 adresy, které mají být viditelné na wan rozhraní. Uvedený návod to řeší post-up hookem, který pro každou novou VPNku založí patřičné mapování. To by měl zvládnout taky démon ndppd - sledujte také obrázky u projektu ndprbrd, který ukazují názorně konfigurace. Kromě tohoto pak asi bude potřeba ještě zprovoznit radvd, které bude ohlašovat stejný prefix z WAN strany na LAN straně.

250

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 12. 02. 2018, 23:29:03 »

Úplně tomu dotazu nerozumím, ale odpověď zní ano, lze, buď pomocí bridge, který bude brideovat jen rámce s IPv6 (což rozhodne třeba pomocí ebtables), nebo pomocí pseudobridge s Proxy NDP, kde bude pro router ISP emulováno, že má přímo dosažitelné kromě WAN rozhraní také všechna zařízení na LAN straně.

Oba přístupy jsou zhruba stejně špatné, ten správný a zároveň nejjednodušší spočívá v delegování prefixu routerem ISP na router zákazníka, ze kterého je tento prefix následně nabízen zařízením na LAN portu. Při použití DHCPv6 PD to ani nevyžaduje žádnou manuální konfiguraci na straně routeru zákazníka.

Víc adres neptřebuji, abych dostal např. přidělený prefix /56 a ten nějak routoval do LAN.

Právě, že potřebuješ. Jak jsi přišel na to, že nepotřebuješ?

Nyní řeším IPv6 protokol za LAN přes OpenVPN

Odkud kam vede ten OpenVPN tunel? Pokud končí na tvém routeru o kterém je řeč, pak není žádný důvod, aby stejně nemohlo fungovat i nativní IPv6. Pokud končí někde úplně jinde v tramtárii, pak to je ten mnohem zásadnější problém, než jestli TAP adaptér ve Windows zvládne 100 Mb/s.

251

Sítě / Re:Chrome / FF - vynucení IPv4 pro některé weby

« kdy: 09. 02. 2018, 12:10:05 »

Řeším problém, jak pro některé weby vynutit použití IPv4, žádný funkční doplněk jsem nenašel. IPv6 mám přes tunel, který ústí v USA a tím pádem problémy s geoloc...

Je možné někde na firewallu odchozí provoz na nevhodné IPv6 adresy blokovat s posláním ICMP zprávy. Prohlížeč pak ihned přejde na IPv4. Ale postihne to nejen prohlížeč.

252

Sítě / Re:Problém s IPv6

« kdy: 12. 01. 2018, 14:14:44 »

OK, momentálně to mám takhle a stejně to nefunguje... 

config host
        option mac 'bc:ae:c5:db:2b:69'
        option ip '172.16.0.2'
        option duid '35c5d17f67054800a99769934d30108e'
        option hostid '00000002'

Tohle vypadá dobře, jen ten DUID je nějaký podivný. Podle mě by měl začínat rozhodně třema nulama. Podívej se do přidělených adres v souboru /var/hosts/odhcpd, tam najdeš správný DUID svého počítače.

Jinak ve výchozím nastavení je LEDE v hybridním režimu, kdy funguje jak DHCPv6, tak SLAAC, takže na počítači budeš mít i další dlouhé a ošklivé IPv6 adresy. Což ale nemusí být na škodu. Pokud se jich chceš zbavit, můžeš SLAAC vypnout, ale to znamená zároveň, že se nepřipojíš se zařízeními, co neumí DHCPv6, tedy s Androidem.

253

Windows a jiné systémy / Re: xrandr --panning ve WIN?

« kdy: 04. 01. 2018, 13:37:44 »

Používám v  linuxu již léta příkaz

xrandr --output eDP-1 --panning 3840x0

To mi umožňuje vidět na obrazovce notebooku i to co promítám dataprojektorem na plochu, ke které jsem otočen zády.

Mám totiž FullHD monitor notebooku a vravo od toho FullHD dataprojektor. Ten panning způsobí to, že když jdu s kurzorem mimo plochu do prava, obraz se začne na notebooku plynule přesouvat na to co promítám na plátně a já se tak nemusím otáčet na plátno.

To je skvělý nápad! Už dlouho přemýšlím nad tím, jak dělat u prezentace s prezentátorským náhledem (použivám pdfpc) třeba praktické ukázky v terminálu nebo ve webovém prohlížeči. Hledal jsem způsob, jak bych na úrovni X serveru naklonoval nějaké okno dvakrát, ale tohle je mnohem elegantnější.

Na danou otázku ovšem odpověď neznám, ale pochybuju, že něco takového Windows umí.

254

Server / Re:Debian Stretch, Bind9 a automaticky DNSSEC - editace zony

« kdy: 01. 11. 2017, 15:16:34 »

Zona samotna take reloadnout nejde:

Kód: [Vybrat]

# rndc reload mojezona.cz
rndc: 'reload' failed: dynamic zone

Aha, vy tu zónu máte v dynamickém režimu. To jste asi nechtěl. Když vyhodíte z konfigurace update-policy, bude se to chovat jako klasický statický zónový soubor a reload bude normálně fungovat.

Příkazy rndc freeze a rndc thaw slouží pro dočasné zastavení dynamických aktualizací v momentě, kdy chcete soubor editovat ručně. Pokud dynamické aktualizace vůbec nehodláte používat, je asi zbytečné si to s nimi komplikovat.

255

Server / Re:Debian Stretch, Bind9 a automaticky DNSSEC - editace zony

« kdy: 31. 10. 2017, 12:31:20 »

Chová se to stejně jako bez DNSSECu, to jest po změně zónového souboru je třeba zavolat příkaz rndc reload který načte novou verzi zónového souboru.

Podrobněji v článku: https://www.root.cz/clanky/dnssec-s-bind-9-9-snadno-a-rychle/