Hosting

Přihlášení

@ IN SOA domény.dns.enum.mojeid.internet. nic.cz.
Aktualizace: 31 min 15 sek zpět

Hezké a klidné svátky a vše dobré v novém roce

Pá, 12/22/2023 - 11:00

Vážení čtenáři našeho blogu, děkujeme vám za vaši přízeň a přejeme vám krásné Vánoce a šťastný nový rok. Těšíme se na viděnou v roce 2024.

Kategorie:

Safer Internet Forum pohledem českých zástupců

Pá, 12/22/2023 - 09:35

Na sklonku letošního roku se v Bruselu uskutečnil další ročník Safer Internet Fora (SIF), tentokrát zaměřený na digitální dovednosti mladých lidí. Do mezinárodní konference, která se konala v hybridním režimu, se aktivně zapojilo 41 mladých lidí z 22 evropských zemí. Přičemž Českou republiku zde reprezentovali hned tři zástupci. Za BIK Youth Panel spolu s ostatními členy vystoupil Viktor Adámek, student Gymnázia Ústí nad Orlicí. Mezi členy SIF Youth Advisory Board, kteří celou akci spolumoderovali, byla Selma Kaymakci, studentka francouzské univerzity Sciences Po. A v neposlední řadě zde vystoupila i Tereza Kráčmarová, zakladatelka spolku Fakeskape. Konferenci dohromady sledovalo více než 850 lidí z celého světa, což je obrovský úspěch.

Letošní Safer Internet Forum dalo nebývalý prostor právě mladým lidem, což může potvrdit i Selma, která se účastnila taktéž předešlých dvou ročníků jako členka BIK Youth Panelu a může tak nabídnout zajímavé srovnání: „Oproti minulému roku se moje role poněkud lišila. Jako členka Youth Advisory Boardu jsem měla i poradní funkci, což spočívalo v navrhování pozvaných řečníků, oficiálního názvu konference a samozřejmě moderování během celé konference SIF.  Byla jsem ráda, že se mi podařilo prosadit pozvání Terezy Kráčmarové z Facescape, která poskytla cenné zkušenosti z realizace tohoto unikátního projektu.“

Tereza ve svém vstupu mj. zmínila, že influenceři jsou důležitými vzory pro mladé lidi, proto by si měli uvědomovat svůj vliv a zajistit, aby prostřednictvím svého obsahu sdíleli spolehlivé informace. Dále zdůraznila důležitost role rodičů a vychovatelů ve vztahu k šíření nepravdivých informací, protože právě oni by měli dětem vysvětlovat, jak k těmto dezinformacím přistupovat, a zároveň je nesoudit za to, když někdy uvěří příspěvku, který není pravdivý.

Jako nejzajímavější zkušenost z letošního ročníku Selma uvedla možnost moderování jednoho z panelů a taktéž závěrečný proslov k divákům. „Vrcholem pro mě bylo moderování panelu spolu s mojí kolegyní a kamarádkou z Norska. Naše diskuse se soustředila na zákon o digitálních službách (DSA) a jeho dopady na digitální dovednosti, které se dotýkají různých zúčastněných stran. Kromě toho jsem měla tu čest vystupovat v závěrečném panelu s názvem „Next Steps“, kde jsem shrnula zásadní body z celodenních diskusí.“

Selma dále vyzdvihla zajímavost tzv. „deep dive sessions“, kde zazněly různé názory na to, zda by do vzdělávacího sektoru měla být více začleněna digitalizace. Uvedla, že se zde objevil jeden zajímavý postřeh: „Ačkoli se preference lišily v závislosti na regionech a digitální propasti, mladí lidé vyjadřovali touhu po tzv. soft skills nežli po tzv. hard skills, jako je třeba kódování. Tento názor zazněl i v hlavním projevu profesorky Amandy Third z australské univerzity v Sydney, která také zdůraznila důležitost rozvoje kritického myšlení a dalších podobných dovedností. Vzhledem k tomu, že se české školství soustředí právě na hard skills, je evidentní, že je třeba naléhavě přehodnotit a rozšířit výukové metody a obsah ve prospěch komplexnějšího přístupu ke vzdělání pro digitální éru.“

Z mnoha rozhovorů si Selma odnáší dva klíčové poznatky: „Za prvé je nutné soustředit úsilí na podporu digitálních dovedností, zejména u dětí ve věku do 14 let. Klesající věk používání digitálních technologií to jen potvrzuje, přičemž v oslovování této mladší věkové skupiny je stále znatelná mezera. Za druhé existuje nedostatečná komunikace médií směrem k široké veřejnosti ohledně proběhlých změn v aktuální legislativě zaměřené na technologické aspekty. Tato komunikační mezera pak vyvolává u veřejnosti strach a formuje negativní vnímání digitálních technologií u starší generace, což má dopad právě na vzdělávání mladých lidí.“

Těší nás, že generace Z dostává svůj prostor pro vyjádření názorů i na konferencích mezinárodního významu, protože ne nadarmo se jí říká internetová generace. Selmo, Viktore, Terezo, děkujeme za skvělou reprezentaci!

Kategorie:

Co přinesla a ještě přinese nová verze FREDa?

Čt, 12/21/2023 - 09:30

Na začátku prosince 2023 jsme uvolnili novou verzi systému FRED, tedy námi vyvíjeného systému pro správu domén, který využíváme pro provoz české národní domény .CZ. Systém FRED ale slouží ke stejnému účelu v dalších deseti zemích. Využíván je pro správu domény Argentiny (.AR), Bosny a Hercegoviny (.BA), Kostariky (.CR), Albánie (.AL), Severní Makedonie (.MK), Tanzanie (.TZ), Angoly (.IT.AO a .CO.AO), Malawi (.MW), Lesotha (.LS) a Macaa (.MO). Nová verze FREDa je poskládána z většího množství dílčích změn vyvinutých za posledních více jak 12 měsíců, které jsme, až na výjimky, průběžně nasazovali do provozu u nás. Celá řada úprav byla významně provázána, nebylo tedy možné zveřejnit dílčí verze systému, protože by se na ně zahraničním registrům obtížně přecházelo. FRED ve verzi 2.48 je naopak verzí, na kterou doporučujeme přejít.

Kompletní výčet změn od poslední verze je dostupný v naší rozsáhlé dokumentaci, respektive v sekci záznamy o změnách. Protože jsme ale část změn potřebovali dostat do provozu dříve, a dokázali jsme to díky úzké interní spolupráci mezi vývojáři, testery a administrátory efektivně zařídit, nejsou informace o změnách v následujícím odstavci pro uživatele instalace FREDa pro .CZ doménu žádnou novinkou.

O zvýšení bezpečnosti transferů domén (objektů v registru obecně) jsem psal již loni. Heslo pro transfer, tzv. Authinfo, je nově ukládáno v zahashované podobě a navíc s časově omezenou platností. V případě .CZ domény je to 14 dní, ale je to nastavitelný parametr. Letos v létě jsme začali v provozu využívat také nového systému verifikací kontaktů, který pomáhá a bude pomáhat udržovat v registru aktuální a ověřená data o držitelích domén. Aktuálně probíhá ověřování zejména takových kontaktů, u kterých máme podezření na jejich nesprávnost, ale protože jsou procesy kontrol automatizovány, budeme moct prověřovat kontaktů více.

Například s využitím dat z Registru územní identifikace, adres a nemovitostí (RÚIAN) nebo z Administrativního registru ekonomických subjektů (ARES). Interakce s držiteli domén probíhá přes Verifikační portál a všechny informace o stavu ověření kontaktů a k nim potřebné nástroje, jsou k dispozici operátorům našeho helpdesku ve webovém rozhraní pro administraci FREDa, který nazýváme FERDA (nástupce dožívajícího systému Daphné).

FERDA doznal v letošním roce celé řady změn. Kromě přibývajících funkcí, kterým vévodí již zmíněné Verifikace, správa registrátorů (včetně certifikátů) nebo správa agendy veřejných žádostí jsme také vylepšili vyhledávání objektů v registru, a to jak z pohledu využitých API, tak z pohledu operátora helpdesku. A když jsem u těch zvenku méně viditelných změn, tak jednou z těch velmi významných byl kompletní přepis starého systému na odesílání zpráv (e-mailů, SMS a dopisů) na zcela nový modul, tzv. Messenger. Právě tato novinka byla největším důvodem odkladu zveřejnění nové verze FREDa, protože jsme s ní chtěli jít ven až v okamžiku, kdy nebude FRED nikde využívat původní systém na odesílání zpráv. Poslední změnou, kterou zmíním v sekci „pro .CZ doménu je již v produkci“ v části zvenku „neviditelných“ změn, je postupný přechod od CORBA ke gRPC při vzdáleném volání procedur. Moderní gRPC využíváme u všech nově vyvíjených funkcí, ale využili jsme jej i při vývoji inovovaného modulu pro logování, tzv. Loggeru, který nově využíváme pro všechny komponenty FREDa.

FRED ve verzi 2.48 obsahuje ale i novinky, které jsme dosud do produkce nenasadili, ale připravujeme jejich zveřejnění na veřejně dostupném testovacím prostředí, které slouží zejména registrátorům. Zavedeme minimální počet znaků Authinfa na 8, budeme umět napovídat registrátorům, na jaký e-mail bylo Authinfo zasláno (e-mail nápověda ve tvaru: a*****@b*****.*) a znemožníme zakládání objektů pomocí příkazu create, pokud bude obsahovat authinfo. Dále ukončíme technickou kontrolu nameserverů a to tak, že možnost volat kontrolu přes EPP nebude již implementována (nebylo využíváno), automatické kontroly nahradíme novým nástrojem v příštím roce (aktuální systém byl nestabilní a jeho údržba příliš nákladná). Obecně se verze FREDa 2.48 nese v duchu vyčištění od nepoužívaného zastaralého kódu, ale přináší i novinky, na kterých budeme do budoucna stavět. A tou nejvýznamnější je implementace podpory pro aukce domén, která si dává za cíl zpřístupnit domény, které jsou po expiraci uvolňovány k volné registraci, širšímu okruhu zájemců. O tomto tématu se ale rozepíšu až v době, kdy dokončíme vývoj a testování rozhraní pro dražitele a podpůrných rozšíření do FERDy. Ale to bude už v roce následujícím.

V příštím roce bychom také rádi doplnili letos zveřejněný instalační skript na DEMO FREDa o návod, jak přejít ze starších verzí FREDa na nyní aktuální verzi 2.48 a pokusíme se také nabídnout podporu těm registrům, které by ji při upgradu nebo obecně při správě, potřebovali.

Kategorie:

Novinky v Knot Resolver 6.x

Pá, 12/15/2023 - 07:30

V tomto příspěvku bych rád představil nadcházející hlavní verzi projektu Knot Resolver, která je v tuto chvíli ve fázi testování a ladění a proto velmi oceníme, když si ji vyzkoušíte a poskytnete nám k ní jakoukoliv zpětnou vazbu.

Architektura

Knot Resolver se od ostatních open-source implementací DNS resolverů liší převážně svou modularitou, a to v několika aspektech. Kompletní Knot Resolver je tvořen několika komponentami: kresd (samostatný resolvující daemon), cache databáze s DNS záznamy a cache garbage collector (proces starající se o periodické čištění záznamů v cache). Resolvující daemon je navíc jednovláknový proces, což znamená, že je velmi jednoduchý a přímočarý, pokud ale chceme plně využít zdroje procesoru, musí být spuštěno více jeho samostatných instancí. Jejich počet zpravidla odpovídá počtu jader procesoru.

Jednotlivé základní i doplňující funkce resolvujícího daemona (kresd) jsou zajišťovány samostatnými moduly, které je možné připojovat a odpojovat a mít tak „štíhlý“ resolver přizpůsobený vlastním potřebám bez nadbytečných funkcí. Další neobvyklostí byla až dosud konfigurace, která se píše v plnohodnotném programovacím jazyce Lua. Společně s možností psaní vlastních modulů v C nebo Lua to přináší takřka neomezené možnosti, jak Knot Resolver a jeho funkce doplňovat nebo konfigurovat.

S tím, jakou má Knot Resolver architekturu, se váže hned několik problémů:

  • Jednovláknové procesy neumožňují tak jednoduchou škálovatelnost na vícejádrových strojích. Musí se spustit více procesů, o které je pak třeba se jednotlivě starat. K tomu je zpravidla využíváno systemd, které ale není možné nasadit v Docker kontejnerech nebo některých distribucích Linuxu (např. Turris OS a OpenWrt).
  • Jednotlivé moduly je před použitím třeba manuálně načíst, jinak jejich funkce nebudou dostupné. U některých modulů je také potřeba zajistit správné pořadí jejich načtení.
  • Konfigurace v jazyce Lua neumožňuje jakýmkoli způsobem ověřit její správnost před spuštěním v resolveru. V lepším případě se chyba projeví hned při spuštění, v horším případě může resolver běžet bez problému a chyba se projeví až při pokusu o aplikaci špatné konfigurace nebo spuštění chybného kódu.

V nové nadcházející verzi vše zmíněné zůstává, ale přibývá nová komponenta zvaná manažer (manager), která se snaží nevýhody tohoto přístupu zredukovat a usnadnit interakci uživatele s Knot Resolverem.

Manažer a řízení procesů

Manažer je nová komponenta napsána v Pythonu, která spravuje zbylé části resolveru na základě konfigurace:

  • Dává pokyn ke spuštění nebo zastavení ostatních procesů. K tomu používá supervisord, který funguje i v Docker kontejneru a Linux distribucích nepodporujících systemd. Díky manažerovi je tedy mnohem snadnější spravovat procesy resolveru na systémech s absencí systemd.
  • Používá deklarativní formu konfigurace v YAML formátu, která je výrazně přehlednější než Lua. Navíc je možné ji validovat a odchytit tak chyby v konfiguraci ještě před spuštěním resolveru. Na pozadí se pak postará o správné načtení potřebných modulů v případě použití jejich funkcí.
  • Poskytuje HTTP API, které umožňuje změnu konfigurace za běhu nebo načtení agregovaných metrik ze všech kresd procesů.

V Knot Resolveru existují dvě různé řídící struktury, viz následující diagram. Sémanticky manažer řídí všechny zbylé části resolveru. Manažer však zároveň není kořenem procesní hierarchie, tím je supervisord, který je na vrcholu procesního stromu a řídí všechny procesy.

Procesní hierarchie lehce komplikuje proceduru spuštění resolveru. Je možné si toho všimnout i při náhledu do logů hned po spuštění.

Co se děje v při studeném startu:

  1. Spustí se manažer a přečte si deklarativní konfiguraci. Pokud je konfigurace validní, tak vygeneruje konfiguraci pro supervisord.
  2. Poté se spustí supervisord a dojde k nahrazení běžícího procesu manažera novým supervisord procesem.
  3. Supervisord načte svou konfiguraci a spustí novou instanci manažera. Nově spuštěný manažer běží jako podřízený proces pod supervisord, což je žádoucí stav.
  4. Manažer si znovu načte konfigurační soubor a na základě toho vytvoří konfiguraci pro zbylé procesy resolveru.
  5. Nakonec vydá manažer pokyn pro supervisord, aby spustil vyžadovaný počet procesů, které si následně načtou pro ně vytvořenou konfiguraci.

Díky tomu, že procesy řídí supervisord, je možné vyřešit selhání jednotlivých procesů resolveru bez zásahu uživatele. Vše mimo supervisord se při selhání automaticky restartuje. Pokud se ze selhání není možné zotavit automaticky, procesy se zastaví a nezanechají za sebou žádné smetí.

Zpracování konfigurace

Následující diagram detailněji popisuje průběh načtení konfiguračního souboru při studeném startu nebo při konfiguraci resolveru za běhu pomocí HTTP API. K jednodušší komunikaci s HTTP API je možné použít CLI nástroj kresctl. Konfigurační soubor je jediný autoritativní zdroj konfigurace a na rozdíl od konfigurování prostřednictvím HTTP API je perzistentní napříč restarty resolveru nebo i celého stroje. Omezením konfigurace přes HTTP API je také to, že z ní není možné generovat konfiguraci pro supervisord, která se sestavuje pouze při studeném startu. HTTP API proto neumožňuje konfigurovat naprosto vše co umí  konfigurační soubor.

Po načtení ze souboru nebo přijetí přes HTTP API je konfigurace naparsována z YAML nebo JSON řetězce do jednotného slovníkového formátu. Následně proběhne validace dat oproti vzorovému schématu a jejich normalizace. Dojde například k přiřazení defaultních hodnot nebo přiřazení hodnot na základě kontextu v konfiguračních datech. Je to možné díky vrstvení vzorového schématu konfigurace, které mezi jednotlivými vrstvami umožňuje transformace na základě kontextu z vrstvy předchozí nebo získání nové hodnoty ze systému. Tím vzniknou nová konfigurační data, která jsou validována oproti vrstvě následující. Uživatel tedy pracuje s lehce odlišnou strukturou konfigurace než resolver interně po validaci.

Po úspěšné validaci dojde při studeném startu k vygenerování konfigurace pro supervisord, v ostatních případech mimo studený start dojde pouze k vytvoření konfigurace pro jednotlivé procesy resolveru.

Instalace

Kompletní dokumentaci k testovací verzi lze nalézt na https://knot.pages.nic.cz/knot-resolver. Jak nainstalovat testovací verzi pro vybrané linuxové distribuce je popsané v kapitole Getting Started.

Spuštění

Naše upstream balíčky pro jednotlivé linuxové distribuce jsou standardně dodávány se systemd integrací. V nové verzi již není nutné spouštět jednotlivé instance kresd (kresd@1, kresd@2, …), stačí pouze spustit manažera pomocí nové systemd služby.

$ systemctl start knot-resolver # stop, reload, restart

Počet kresd instancí, kterým má manažer zajistit spuštění, se určuje číselnou hodnotou v konfiguračním souboru pod novým názvem workers. Hodnotu je také možné nastavit na auto, kdy manažer nastaví počet workerů automaticky na základě počtu jader procesoru.

# /etc/knot-resolver/config.yaml workers: 4

Knot Resolver standardně využívá logování přes systemd, kam je možné se podívat pomocí systemd-journald služby, například při neúspěšném startu resolveru.

$ journalctl -eu knot-resolver Konfigurace

Konfigurace je nově deklarativní ve formátu YAML nebo JSON (pro HTTP API). Je možné ji před použitím validovat a zachytit tak případné chyby ještě před spuštěním Knot Resolveru.

Validace

Validace konfigurace vždy probíhá automaticky při spuštění Knot Resolveru. V případě vadné konfigurace skončí jeho spuštění chybou.

Konfiguraci je možné validovat nezávisle na spuštění resolveru pomocí CLI nástroje kresctl.

kresctl validate /etc/knot-resolver/config.yaml

Pokud validace selže, objeví se detailní chybová hláška s informacemi, kde a co je špatně. Stejný výpis se objeví v logu Knot Resolveru, pokud selže validace konfigurace při startu.

Configuration validation errors detected: [/network/listen[0]/port] value 65536 is higher than the maximum 65535 [/logging/level] degugg does not match any of the expected values (crit, ..., debug) Dynamická změna konfigurace

Změnit konfiguraci resolveru za běhu je možné dvěma způsoby.
Knot Resolver je schopný dynamicky změnit vlastní konfiguraci znovunačtením konfiguračního souboru nebo prostřednictvím HTTP API.

Po úpravě konfiguračního souboru stačí následně zavolat reload systemd služby.

$ systemctl reload knot-resolver

K zaslání nové konfigurace na HTTP API je opět možné využít CLI nástroje kresctl nebo například standardní nástroj curl.

$ kresctl config set /workers 8

Při standardním použití si kresctl sám zjistí konfiguraci HTTP API z konfiguračního souboru. Mimo operace s konfigurací je možné prostřednictvím HTTP API získat metriky resolveru nebo kompletní JSON schéma konfigurace. Vše je detailněji popsáno v management sekci dokumentace.

HTTP API je ve výchozím nastavení nakonfigurované, aby poslouchalo na unixovém socketu. API je také možné nakonfigurovat na jedno ze síťových rozhraní a port.

# /etc/knot-resolver/config.yaml management: interface: 127.0.0.1@5000 # nebo použijte místo rozhraní unix-socket # unix-socket: /my/new/socket.sock

Obdobná změna konfigurace s pomocí curl nástroje bude vypadat následovně.

$ curl -H 'Content-Type: application/json' \ -X PUT -d '8' http://127.0.0.1:5000/v1/config/workers

Rekonfigurace probíhá následujícím způsobem:

  1. Nová konfigurace získaná ze souboru nebo přes HTTP API je validována.
  2. Manažer zkontroluje, zda v nové konfiguraci nejsou nastavení, která by vyžadovala kompletní restart resolveru včetně manažera a vytvoření nové supervisord konfigurace. Pokud změny v konfiguraci nevyhovují, operace tímto končí chybovou hláškou a změnu konfigurace je potřeba provést pomocí restartu celého resolveru pomocí systemd.
  3. Manažer vytvoří novou konfiguraci pro jednotlivé procesy a s touto konfigurací spustí takzvaný “canary” proces, díky kterému se zjistí případné chyby.
  4. Pokud v “canary” procesu vše funguje jak má, následuje spuštění vyžadovaného počtu procesů s novou konfigurací.
  5. Nově spuštěné procesy v daný moment nahradí původní již běžící a tím je rekonfigurace dokončena bez výpadku služby.
Příklady konfigurace

První věc, kterou budete pravděpodobně chtít nakonfigurovat, jsou síťová rozhraní pro poslech. Následující příklad instruuje resolver, aby přijímal standardní nezašifrované DNS dotazy na localhost adresách. Zabezpečené DNS lze nastavit pomocí protokolů DNS-over-TLS nebo DNS-over-HTTPS. Nastavení nestandardního portu pro protokol je možné explicitně určit pomocí parametru port.

YAML také umožňuje vytvářet proměnné (&interfaces) a obsah následně replikovat v dalších částech konfigurace (*interfaces). Díky tomu není v příkladu třeba opakovaně vypisovat síťová rozhraní.

# /etc/knot-resolver/config.yaml network: listen: # Nezabezpečené DNS na portu 53 (default). - interface: &interfaces - 127.0.0.1  - "::1" # Pro IPv6 adresy a jiné řetězce začínající # dvojtečkou je potřeba použít uvozovky. # DNS-over-TLS na portu 853 (default). - interface: *interfaces kind: dot # DNS-over-HTTPS (port 443 je default). - interface: *interfaces kind: doh2 # Port je také možné nastavit explicitně. port: 5000

Dalším výrazným zlepšením nejen v konfiguraci, ale v chování resolveru obecně, je změna přístupu k vyhodnocování a aplikaci policy pravidel. Deklarativní přístup v konfiguraci zajišťuje, že je vždy vybráno pravidlo, které přicházejícímu dotazu odpovídá nejlépe. Starý přístup v předchozích verzích vybral první pravidlo, které odpovídalo dotazu. Bylo proto třeba dbát velké opatrnosti s pořadím pravidel, jinak se často nechtěným způsobem vzájemně „zastiňovala“.

U pravidlel pro třídění uživatelů na základě zdrojové podsítě bude mít vždy přednost menší odpovídající podsíť před větší. To je možné vidět v následujícím příkladu. Jedním pravidlem jsou uživatelé ze všech podsítí odmítnutí a dalšími pravidly s menšími podsítěmi jsou povoleny.

# /etc/knot-resolver/config.yaml views: # Podsítě, které jsou povoleny. - subnets: [ 10.0.10.0/24, 127.0.0.1, "::1" ] answer: allow # Podsíť, pro kterou jsou přiřazena další pravidla # pomocí štítků (tags). - subnets: [ 192.168.1.0/24 ] tags: [ malware, localnames ] # Vše ostatní je odmítnuto. - subnets: [ 0.0.0.0/0, "::/0" ] answer: refused

Jednotlivá pravidla je možné mezi sebou kombinovat. K tomu slouží štítky (tags), které stačí přiřadit k pravidlům, které chceme zkombinovat. Kombinace různých pravidel se chovají výrazně předvídatelněji než dříve. Je tak možné filtrovat uživatele na základě podsítě, ze které dotaz přichází, a pomocí tagu přiřadit pro tuto podsíť další pravidla zpracování dotazu. Mohou to být například úpravy v lokálních DNS záznamech, blokovací seznamy a další.

# /etc/knot-resolver/config.yaml local-data: # Místo pro statické DNS záznamy. records: | www.google.com CNAME forcesafesearch.google.com rpz: # Malware seznam pro blokování. - file: /tmp/malware.rpz # Je použito pouze pro "malware" štítek (tag). # Například v kombinaci s podsítěmi ve "views". tags: [ malware ] # /etc/knot-resolver/config.yaml local-data: # Statické páry domén a adres. addresses: a1.example.com: 2001:db8::1 a2.example.org: - 192.0.2.2 - 192.0.2.3 - 2001:db8::4 # Import souboru ve formát "/etc/hosts". addresses-files: - /etc/hosts

Deklarativní přístup dále umožnil pokrýt další části použití v oblasti přeposílání dotazů, kde je nově možné přeposlání na více míst i rámci jednoho dotazu. Cílem dotazu pak může být i autoritativní server. Přeposílání nyní nerozbije CNAME a resolver dotaz vyřeší správným způsobem.

# /etc/knot-resolver/config.yaml forward: # Veškeré DNS dotazy budou přeposlány na ODVR servery. - subtree: '.' servers: - address: - 2001:148f:fffe::1 - 193.17.47.1 # Komunikace je zabezpečena pomocí TLS. transport: tls hostname: odvr.nic.cz # /etc/knot-resolver/config.yaml forward: # Přeposlání dotazu pro interní doménu. - subtree: internal.example.com servers: [ 10.0.0.53 ] options: # Cílem je interní autoritativní DNS server. authoritative: true     dnssec: false Závěrem

Na závěr bych rád poděkoval všem, kteří si nový Knot Resolver vyzkoušeli nebo teprve vyzkouší. Více o nové verzi naleznete v dokumentaci. Případnou zpětnou vazbu nám můžete poskytnout nejlépe v GitLabu nebo zaslat na e-mailovou adresu projektu. Pokud vše půjde podle plánu, na první oficiální vydání se můžete těšit začátkem příštího roku s označením verze 6.1.0.

Kategorie:

Krátké vlny: Šťastné a (kyber)bezpečné

Čt, 12/14/2023 - 07:20

Nárůst kybernetické kriminality je alarmující. Již na jaře tohoto roku byly publikovány statistiky dokazující, že v roce 2022 tvořila kybernetická kriminalita s více než 18 500 skutky přes 10 % z celkové registrované kriminality v Česku. Důraz je nutno klást na slovo „registrované“, s nenahlášenými kybernetickými zločiny to číslo může být ještě vyšší.

Tento týden Pavel Bašta z národního CSIRT pracoviště České republiky publikoval krátký článek s příklady podvodníků, kteří cílí na uživatele prodávající nebo nakupující zboží přes bazarové servery. Bohužel už není pravdou, že tito podvodníci používají nevěrohodné kontaktní adresy a lámanou češtinu. S vývojem a zlepšováním strojových překladů a dalších nástrojů, které nám pomáhají v práci, se zlepšují i padouši v kybernetickém prostoru, protože i oni umí používat nástroje jako DeepL a bohužel i další, které jim vylepšují důvěryhodné image.

A bude hůř. Prakticky na všech velkých platformách typu YouTube nebo Facebook se denně setkávám, s nabídkou „skvělých investic“. „ČEZGroup spouští novou platformu“ informuje mě prezident této země, Petr Pavel. A následuje odkaz vedoucí na falešnou stránku, která jako by z oka vypadla webu Novinky.cz a která dál omotává podvodnými pastičkami možnou oběť.

Doména pochybného webu visí samozřejmě na Cloudflare, zaregistrovaná na soukromou osobu, která uvedla jako místo svého působení Moskvu.

Jindy na mě zas vyskočí podvodné video přestrojené za zpravodajství CNN Prima NEWS, které přináší skvělou zprávu „o zářivém objevu 50 000 barelové denní ropy v Brně a Kujově.“ Nenechám se zmást, že Kujov v Česku neexistuje (podvodný kyberšmejd myslí zřejmě Kyjov) a „běžím investovat peníze do skvělého obchodu“.

V analogovém světě se samozřejmě také stávalo, že podvodníci inzerovali v novinách pochybné nabídky a lákali naivní zájemce. Ale pokud byl následně inzerát označen jako podvodný, nemohlo se stát, aby druhý den vyšel v novinách znovu. V digitálním světě tuto jistotu nemáme. Velké platformy sice mají svá nahlašovací tlačítka proti podvodnému obsahu, avšak prudce selhávají při hodnocení těchto reportů. I když nahlásíte podvodné video, platforma se zamyslí a do 24 hodin odpoví, že…“Rozhodli jsme se, že tuto reklamu neodstraníme. Zjistili jsme, že reklama neporušuje zásady PLATFORMY, které zakazují určitý obsah a postup, jež jsou podle nás škodlivé pro uživatele a online ekosystém celkově.“. Jediné, co mohu, je skrýt podvodnou reklamu na svém profilu. Vypadala by reakce platformy jinak, pokud by podvod reportoval důvěryhodný oznamovatel (trusted flagger)? Nebo je problém už v nakupování reklamy? Každopádně by bylo fajn, kdyby si „algoritmy“ platforem uvědomily, že Česko není zas taková banánová republika, aby zde prezident lákal na investice do státního podniku ČEZGroup a že v Brně najdeme spoustu „zářivých objevů“, ale 50 000 barelové ropy denně opravdu ne. Čím dřív si to uvědomí, tím lépe pro všechny.

Europol tento týden vydal předběžné varování o využívání geolokační bluetooth trackerů organizovaným zločinem.  Malá užitečná zařízení typu AirTag, jejichž klíčovou vlastnosti je podpora vyhledávání pomocí crowdsourcingu, nám zjednodušují život, ale nepřekvapivě pomáhají i padouchům. Sledovací zařízení založené na technologii bluetooth se nejčastěji objevují v souvislosti s obchodováním s drogami. V Europolem šetřených případech byla sledovací zařízení použita k lokalizaci vozidel využívaných k trestné činnosti nebo k lokalizaci plavidel používaných při pašování migrantů. Pašeráci drog používali AirTagy a podobná zařízení ke sledování tranzitu drog po příjezdu do přístavů a při následné distribuci ve vnitrozemí.

Nezahálí ani špioni. Z investigativní reportáže holandského deníku NRC vyplynulo, že čínská hackerská skupina „Chimera“ měla více než dva roky neoprávněný přístup do počítačové sítě nizozemského výrobce čipů NXP. I přes bezpečnostní opatření výrobce čipů zůstal tento kybernetický útok dlouho skrytý a ve svém důsledku vedl ke krádeži práv duševního vlastnictví společnosti NXP.

Vyšetřováním bylo zjištěno, že hackeři použili ukradené informace o účtech z předchozích úniků dat ve službách (např. LinkedIn nebo Facebook). Díky těmto informacím se mohli vydávat za běžné zaměstnance a získat přístup do sítě společnosti NXP. Poté začali metodicky krást, komprimovat a šifrovat velké množství dat. Kradená data byla připravena ke kopírování prostřednictvím cloudových služeb typu Google Drive, Microsoft OneDrive a Dropbox.

Digitální prostor je skvělé místo k zábavě, podnikání, vzdělávání. Digitální prostor je ale také skvělé místo pro šmejdy a podvodníky. Tak bacha na ně, ať Vám v adventním čase nezbydou místo dárků pro nejbližší oči pro pláč. Hezké vánoční svátky.

Kategorie:

Internetové kšefty

Po, 12/11/2023 - 08:40

Dnes se pro změnu podíváme na podvody při nákupech a prodeji zboží přes různé bazarové služby. Koukneme se na dva případy, kdy se podvodníci snažili okrást uživatele. Rozhodl jsem se, že se s vámi podělím o nevšední rozhovor, který jsem s jedním podvodníkem operujícím na Marketplace vedl již před nějakou dobou, ale zatím jsem neměl čas to zpracovat do lépe čitelného stavu. Vše začalo tím, že jsem se rozhodl prodat akvárium. Hned první reagující byl zjevný lump, ale protože jsem měl zrovna trochu času a chtěl jsem zjistit, zda bych mu to nemohl trochu znepříjemnit, rozhodl jsem se ním jeho hru hrát.

Protože jsem věděl, že je to lump, poskytl jsem mu údaje, které kromě jména, které už znal, k ničemu nejsou.

Bernardova představa, že 160 litrové akvárium pošlu pojištěnou obálkou mne pobavila, ale hlavně jsem se těšil, že mi Bernard pošle odkaz na nějakou stránku, přes kterou bude třeba „zaplatit“ za pojištění pomocí platební karty. Aspoň bychom mu stránku mohli nechat cvičně shodit a přidělat mu trochu práce. Bohužel, Bernard je zjevně skromný a tak mu do začátku stačila platební karta předplacená na 100 EUR. Do mé e-mailové schránky určené pro komunikaci s podobnými vejlupky mi pak dorazil e-mail od služby Fedex.

Z e-mailu vedl odkaz na stránky umožňující nákup předplacené kreditní karty Transcash. Nutno říci, že v době psaní tohoto článku jsou poukázky za 100 EUR vyprodány, tak snad to není proto, že se Bernardovi a jemu podobným daří.

Zároveň s příchodem e-mailu se ozval Bernard, který se zjevně těšil na svou skromnou odměnu.

K Bernardově velké smůle narazil na uživatele, který neumí ani kliknout na odkaz ani udělat screenshot. Řekl jsem si, že když už nemá Bernard web, který bychom mohli nechat shodit, tak bych si na něm aspoň mohl potrénovat sociální inženýrství a zkusit z něj vytáhnout jeho telefonní číslo. Zároveň jsem ho chtěl vystavit troše toho zdravého stresu a upozornil jsem ho, že u PC už nemohu být dlouho.

Naštěstí má zatím trpělivý Bernard v záloze další možnosti. Já ovšem cítil intenzivní potřebu Bernarda informovat, že stránka na kterou mi poslal odkaz je v jazyce, který neovládám.

Bernard měl ovšem zaseknuto a jako správný lovec neztrácel trpělivost.

Za to mne to už přestávalo bavit a tak jsem si řekl, že odkryji karty a ukážu Bernardovi, že ho celou dobu tahám za za nos.

Bernard byl ale buď úplný hňup nebo měl už oči zaslepené vidinou zisku a v komunikaci vesele pokračoval.

Abych dodal mé postavě na důvěryhodnosti, druhý den jsem se lehce ohradil vůči Bernardově neodbytnosti, neboť mne začal bombardovat zprávami hned v neděli brzy ráno. Zároveň jsem se rozhodl nadhodit Bernardovi další udičku.

Byl jsem si jistý, že Bernard si toho sám nevšiml, tak jsem ho pro jistotu upozornil, že nejsem zrovna technický typ. Předem jsem ho informoval i o mé slabozrakosti, ale ani to jej neodradilo.

Následně jsem Bernarda definitivně přesvědčil také o mých jazykových kompetencích.

I tak to nevzdal a trpělivě vyplňoval nesmyslná čísla, kterými jsem ho krmil.

Bernardova trpělivost začala narážet na své hranice a tak jsem se rozhodl zkusit znovu frontální útok.

Bernardova svatá trpělivost a sebejistota se pomalu začaly tavit v kotlíku zoufalství a tak se mne pokusil vyhnat ještě na čerpací stanici. Já byl ale neoblomný.

Nakonec jsem zkusil Bernarda na oplátku požádat ještě o 1000 EUR, ale dle očekávání se mnou přestal komunikovat.

Bernard byl ovšem příliš snadný cíl, proto bych vám rád ukázal i jiný příběh. Týká se uživatelky, která naštěstí přišla celkově o malou sumu, ale jejíž komunikace s podvodníky ukazuje jejich schopnost solidní manipulace s obětí. A to i přes skutečnost, že dotyčná oběť podvodu si byla možných rizik vědoma.

V tomto případě již podvodníci velmi dobře komunikovali, byli ochotní a v rámci vzbuzení důvěryhodnosti se ani vehementně nebránili osobnímu předání. Bankovní účty vedené u bankovních institucí v ČR také nebudily žádné podezření.

 

Ani tlapková patrola ani Lego vlak však nedorazily a oba facebookové účty přestaly s uživatelkou komunikovat. Podobně jako v případě e-shopů, kterým jsme se věnovali v minulém blogpostu, je proto potřeba být velice obezřetný. Naštěstí i v tomto případě existuje databáze, která může pomoci při rozhodování. Upozornila nás na ni uživatelka z našeho příběhu a najdete ji na adrese https://www.podvodnabazaru.cz/. Zde můžete vyhledávat podle kontaktních údajů, ale třeba také podle použitého čísla bankovního účtu. A pokud se stanete obětí podvodu, můžete do této databáze také přispět. Má také smysl hlásit podvody s malými částkami i PČR. Policie si tato hlášení umí spojit a čím více lidí podvodníka nahlásí, tím spíše dosáhne celková způsobená škoda částky, při které bude věc řešena jako trestný čin.

Kategorie: