Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Ovšem všechny návody spojovaly pouze dva Linuxy proti sobě a využívaly manuální spojení ipsecem bez IKE (internet key exchanger) a to mi nevyhovuje.
Např. v LARTC HowTo je i návod na zprovoznění IPsec na jádře 2.6 s automatickým klíčováním (s démonem racoon).
Dovolil bych si upozornit, ze pluto kernelova implementacia ISAKMP a pokial budete mat vela tunnelov a pouzivat dost dlhe kluce, tak mozete mat problem s dostatkom RAMPluto jsem v kernel space jeste nevidel. Vsechny IKE demony co znam (pluto, racoon, isakmpd, ...) bezi v userspace a do kernelu cpou teprve vysledky sveho snazeni, tedy klice a dalsi parametry spojeni. Ano, kdyz budete mit fakt hodne tunelu (radove tak miliony), tak na problem s pameti mozna narazite
Ahoj, nedávno jsem řešil problém s propojením Cisca a Linuxu (racoon implementace), který se mi nepodařilo vyřešit. Pokud se někdo s podobným problémem již setkal a vyřešil jej a mohl by mi poradit, tak bych byl moc rád.
Mám dvě zařízení - Cisco směrovač a Linuxový směrovač (Debian Sarge). Za směrovači je několik sítí s neveřejnýma adresama, řekněme sítě A, B, C, D, kde sítě A a B jsou za směrovačem s Ciscem a sítě C a D jsou za směrovačem s Linuxem. Pokud chci propojit sítě A a C přes IPsec tunel mezi Ciscem a Linuxem, tak vše funguje, jak má. Pokud chci přes stejný tunel propojit i sítě B a D, tak to již nefunguje, tj. funguje jen jedna varianta tj. A <-> C nebo B <-> D, podle toho, které propojení bylo po restartu IPsec tunelu poprvé použito. Propojení Linux to Linux mi, samozřejmě, fungovalo v pořádku.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#
# /etc/racoon/racoon.conf
#
path pre_shared_key "/etc/racoon/psk.txt";
log notify;
timer {
phase1 60 sec;
phase2 60 sec;
}
listen {
isakmp verejna_adresa_Linux;
}
remote verejna_adresa_Cisco {
exchange_mode main, aggressive;
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group modp1024;
lifetime time 10 min;
}
}
sainfo address C any address A any {
lifetime time 10 min;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
sainfo address D any address B any {
lifetime time 10 min;
encryption_algorithm des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
#
# /etc/ipsec-tools.conf
#
spdadd C A any -P out ipsec
esp/tunnel/verejna_adresa_Linux-verejna_adresa_Cisco/require;
spdadd A C any -P in ipsec
esp/tunnel/verejan_adresa_Cisco-verejan_adresa_Linux/require;
spdadd D B any -P out ipsec
esp/tunnel/verejna_adresa_Linux-verejna_adresa_Cisco/require;
spdadd B D any -P in ipsec
esp/tunnel/verejna_adresa_Cisco-verejna_adresa_Linux/require;
Jako nejvhodnější, a v podstatě jediný, se mi pro Linux jeví projekt Openswan.Ktery projekt je nejvhodnejsi je otazka osobnich preferenci, nicmene jediny neni: IPsec-tools (daemon racoon a utilita setkey) je zcela stabilni a kompatibilni implementace IPsec ktera vam nejen s Ciscem a Windows bude taky chodit.
V Main modu pracuje IKE, který ověří obě strany šifrovaného spojení a ustanoví prvotní bezpečnou komunikaci. V této fázi se nepřenáší zatím žádná data. Cisco používá pro tuto část ISAKMP, Openswan Pluto.... a v IPsec-tools se ten daemon jmenuje racoon.
Quick mod se pak již používá pro samotný přenos dat. U Cisca se to nazývá ipsec, Openswan Klips.Tesne vedle. Phase 2, neboli Quick mode, se pouziva pro nastaveni jednotlivych tunelu. Jinak receno - pri sestavovani spojeni mezi dvema pocitaci se provede Phase1 a tim se ziskaji klice pro naslednou komunikaci mezi IKE demony na obou stranach. Tito demoni si potom v Phase2 sifrovne domlouvaji parametry jednotlivych tunelu, tzn. pouzite algoritmy, sifrovaci klice (ruzne od Phase1), atd. Az se domluvi tak pro kazdy tunel zadaji tyto parametry do kernelu. Vlastni sifrovani dat potom provadi kernel, nikoliv IKE demon at uz v Main modu ve Phase 1, nebo v Quick modu ve Phase 2.
Existuje ještě jeden mód, Agressive. Je to zjednodušené spojení main a quick s trochu ořezanou bezpečností. Tento mód se používá pro připojení klientů, kteří nemají pevnou IP adresu, třeba připojení z dial-upu a podobně. Omezení bezpečnosti je ale vyváženo ještě dodatečnou autorizací (xauth), ale o tom si povíme dále.Tohle je uplne spatne - Aggressive mode neslucuje Main mode a Quick mode ale je nahradou jen za Main mode. Rozhodne neni nezbytne ho pouzivat pro klienty bez pevne IP, tem bude za urcitych okolnosti fungovat i Main mode. Ma sve vyhody i nevyhody a ano, je mene bezpecny. Jo a xauth je neco uuuuplne jineho. Bezpecnost Aggressive modu sice muze zvysit, ale je to zcela nezavisly algoritmus ktery jen shodou okolnosti Cisco pouziva dohromady s Aggressive mode.
DH group - Dieffiel-Hellmanovo čísloChudak pan Whitfield Diffie, tedy nikoliv Dieffiel, takhle mu zkomolit jmeno! V tabulce jsou jeste dalsi drobne nepresnosti u Preshared key (nejak se mi nezda ze by se PSK primo zapojoval do vypoctu, ale cist RFC se mi ted nechce) a u Perfect forward secrecy, ale nebudu zas takovy hnidopich
samotná data pak proudí dvěma jednosměrnými tunely navázanými quick módem. To je dáno asymetrickým šifrováním ipsecu, zašifrujete jedním klíčem, ale rozšifrovat musíme druhým. U asymetrické šifry se klíč na zašifrování nedá použít na rozšifrování zprávy.To taky neni pravda. Quick mode samozrejme domluvi symetricke sifrovaci klice a kernel je potom pouziva. Vzdyt i v tabulce mate uvedeny algoritmy 3DES a AES, to jsou prece symetricke algoritmy! Dva nezavisle tunely pro data s ruznymi klici se pouzivaji z ruznych praktickych duvodu a taky proto ze tak pravi RFC
Ovsem s asymetrickymi klici to nema nic spolecneho - ty se v IPsecu pouzivaji jen pri navazovani spojeni pres RSA nebo X.509 certifikaty a to jen na vzajemne overeni komunikujicich stran. Pak uz vsechno bezi na symetrickych klicich jako obvykle.
Klíč tedy máme, ale jak jsme se k němu dostali, aniž by to někdo zjistil, že klíč je 30, i když poslouchá naši domluvu? Odpověď je právě v tom násobení. Při sestavování klíče si strana A vygenerovala číslo, zde 5. Strana B číslo 2. Strana A pošle straně B svoje vygenerované číslo a strana B udělá pro stranu A to samé. Číslo 3 je v příkladu sdílený klíč. Obě strany tedy mají všechna čísla a mohou vypočítat daným vzorcem, který je všeobecně znám, šifrovací klíč. Asi si někdo řekne, že to je nesmysl, když znám vzorec a že jsem odposlechl čísla 5 a 2, mohu si klíč sestavit.Sorry, ale tohle je nesmysl. Patrne to mel byt pokus o popis Diffie-Hellmanova algoritmu, ktery je ovsem tak zjednoduseny, ze doufam ze vam ho nikdo neuveril
V D-H nestaci jen nasobit a uz vubec ne posilat moje tajna cisla otevrenym kanalem. Kdo chce vedet vic at mrkne treba na Wikipedii, je to tam velice nazorne ukazano a clovek nemusi byt matematik aby to pochopil.
Ale jak rikam, je to pekny clanek. Ovsem u takhle sloziteho a exaktniho tematu by to chtelo proof-reading od nekoho kdo by dokazal vychytat nepresnosti.
Tiskni
Sdílej:
