Příspěvek na blogu Google Security popisuje, jak tým Chrome Security využívá umělou inteligenci k zásadnímu zrychlení a zlepšení procesu odhalování, třídění a opravování bezpečnostních chyb v prohlížeči Chrome. Díky AI byla nalezena kritická chyba, která byla v kódu přes 13 let. Ve verzích Chrome 149 a 150 bylo opraveno více chyb než v předchozích 23 verzích dohromady.
Firmy v EU musí počínaje dnešním dnem označovat obsah vytvořený umělou inteligencí. Znamená to povinnost informovat uživatele, že člověk komunikuje s chatbotem či jiným systémem AI. Rovněž obrázky, audia či videa, které jsou vytvořené nebo zmanipulované pomocí umělé inteligence a které mohou působit jako autentické, musejí být jasně označeny jako uměle vytvořené.
Byla vydána nová major verze 11.0 open source unixového operačního systému NetBSD (Wikipedie). Přehled novinek v poznámkách k vydání.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) se zapojil do mezinárodní iniciativy vedené americkou agenturou CISA (Cybersecurity and Infrastructure Security Agency) a dalšími partnery, jejímž cílem je stanovit minimální náležitosti pro tzv. Software Bill of Materials (SBOM). Nový dokument přináší praktická doporučení, jak by měl vypadat přehled komponent softwaru a jak s ním v praxi pracovat. SBOM lze
… více »V aktuálním přehledu vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) bylo oznámeno vydání nové verze 0.4.0. Výrazně se zlepšilo vykreslování stránek jako lichess.org, Zulip nebo Speedtest.
Vládní CERT upozorňuje (𝕏) na kritické zranitelnosti v produktech VMware: CVE-2026-59309, CVE-2026-59310 a CVE-2026-47876. Zranitelnosti v VMware vCenter umožňují vzdálenému útočníkovi se síťovým přístupem obejít autentizaci a získat neoprávněný přístup k vCenter, případně zneužít directory traversal ke spuštění libovolného kódu na vCenter.
Společnost Coinkite upozorňuje na bezpečnostní chybu svých hardwarových kryptopeněženek Coldcard. Jedná se o kritickou chybu v generování náhodných čísel (RNG). Místo hardwarového generátoru náhodných čísel (TRNG) byl omylem používán softwarový fallback (PRNG).
Představena byla nová linuxová distribuce Shadowfetch Linux. Na rozdíl od mnoha nováčků, které nabízejí převážně jiné téma a výběr softwaru, tato distribuce založená na Debianu Testing s desktopovým prostředím KDE Plasma 6.6, klade lokálně běžící umělou inteligenci do centra svého desktopového zážitku.
Max Leiter v roce 2019 zkusil zprovoznit X server na iPadu (iOS). Nyní se k tématu vrátil a s pomocí LLM a balíčkovacích nástrojů Procursus rozběhl desktop s X11 i Waylandem. Jeho balíčky jsou dostupné v repozitáři xiOS.
Společnost Google Cloud dnes oznámila, že její infrastruktura a služby byly oficiálně zařazeny do Katalogu cloud computingu vedeného Digitální a informační agenturou (DIA). Tato certifikace potvrzuje, že infrastruktura a služby Google Cloud splňují přísné bezpečnostní a regulační požadavky České republiky pro provoz cloudových služeb ve veřejném sektoru.
1 Mikrotik (RouterOS) jako NAT/FIREWALL/DHCP: - ether1 - WAN - ether2 - síť 100 - 10.100.0.1/24 - ether3 - síť 200 - 10.120.0.1/24 - ether4 - síť 300 - 10.130.0.1/24 - SFP - VLAN trunk do Mikrotik switchSwitch:
- port1 - síť 100 - port2 - síť 200 - port3 - síť 300 - port4 - síť 300 - port5 - síť 300 - SFP - VLAN trunk do Mikrotiku viz. výšeSwitch mám nastavený a vyzkoušený jak potřebuju. Pročítám manuály do Mikrotiku, jejich dokumentaci a tutoriály a docházím k závěru, že tento problém lze vyřešit dvěma způsoby (možná více). První způsob:
Vytvořit interface: - SFP-vlan-100 - SFP-vlan-200 - SFP-vlan-300 Vytvořit 3 bridge: - bridge-100 s interfaci: ether2, SFP-vlan100 - bridge-200 s interfaci: ether3, SFP-vlan200 - bridge-300 s interfaci: ether4, SFP-vlan300Druhý způsob:
Vytvořit bridge: - bridge1 s interfaci: ether2, ether3, ether4, SFP a nastavit VLAN: - vlan100: tagged: SFP, untagged: ether2 - vlan200: tagged: SFP, untagged: ether3 - vlan300: tagged: SFP, untagged: ether4Oboje by dle mého mělo fungovat (testovat budu zítra). Spíš mě zaráží (možná samozřejmost - se síťařinou začínám), že to lze udělat více způsoby, každý bude mít jistě pro a proti. Cíl je jasný - udělat 3 oddělené sítě, každá budou mít svůj rozsah adres, porty, DHCP server a všechny sítě budou za 1 NATem do WAN. Je nějaký zásadní rozdíl (jak v bezpečnosti, tak v rychlosti) mezi výše uvedenými postupy? Díky moc za poznámky k řešení
/interface bridge port print. Ak ukazuje "H" pri nazve portu a v stlpci HW je hodnota "yes", tak je vsetko ako ma byt.[user@RB] > /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PR PATH-COST INTERNA... HORIZON 0 H eth01 br01-lan yes 1 0x 10 10 none 1 H eth02 br01-lan yes 1 0x 10 10 none 2 I H eth03 br01-lan yes 1 0x 10 10 none 3 I H eth04 br01-lan yes 1 0x 10 10 none 4 H eth05 br01-lan yes 1 0x 10 10 none 5 I H eth08 br01-lan yes 1 0x 10 10 none 6 H eth09 br01-lan yes 1 0x 10 10 none 7 H eth10 br01-lan yes 1 0x 10 10 none [user@RB] >... tiez je dobre nezabudnut, ze routing ide vzdy cez CPU a linka do CPU moze limitovat rychlost spojenia medzi roznymi subnetami.
Ještě taková drobnost, v konfiguraci /interface bridge vlan bude potřeba přidat port "cpu", aby byl provoz switchován i do Mikrotika a fungoval vlan na bridge interfacu.Můžeš to prosím upřesnit port "cpu"? Ve winboxu nevidím nic, co by tomu odpovídalo, v dokumentace se o tomto portu zmiňují, ale příklad jsem nenašel. Jestli to chápu správně: vytvořím z interfacu "my-bridge" interface "my-bridge-vlan100" s VLANem 100 a tento interface potom vložím do /interface bridge vlan ?
/interface bridge add name=bridge1 vlan-filtering=yes /interface vlan add interface=bridge1 name=bridge1-vlan100 vlan-id=100 add interface=bridge1 name=bridge1-vlan200 vlan-id=200 add interface=bridge1 name=bridge1-vlan300 vlan-id=300 /ip pool add name=vlan100 ranges=192.168.0.100-192.168.0.250 add name=vlan200 ranges=192.168.20.100-192.168.20.250 add name=vlan300 ranges=192.168.30.100-192.168.30.250 /ip dhcp-server add address-pool=vlan100 disabled=no interface=bridge1-vlan100 name=dhcp-bridge1-vlan100 add address-pool=vlan200 disabled=no interface=bridge1-vlan200 name=dhcp-bridge1-vlan200 add address-pool=vlan300 disabled=no interface=bridge1-vlan300 name=dhcp-bridge1-vlan300 /interface bridge port add bridge=bridge1 interface=ether2 pvid=100 add bridge=bridge1 interface=ether3 pvid=200 add bridge=bridge1 interface=ether4 pvid=300 add bridge=bridge1 interface=ether5 /interface bridge vlan add bridge=bridge1 tagged=ether5,bridge1 untagged=ether2 vlan-ids=100 add bridge=bridge1 tagged=ether5,bridge1 untagged=ether3 vlan-ids=200 add bridge=bridge1 tagged=ether5,bridge1 untagged=ether4 vlan-ids=300 /ip address add address=192.168.0.1/24 interface=bridge1-vlan100 network=192.168.0.0 add address=192.168.20.1/24 interface=bridge1-vlan200 network=192.168.20.0 add address=192.168.30.1/24 interface=bridge1-vlan300 network=192.168.30.0 /ip dhcp-server network add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1 netmask=24 add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1 netmask=24 add address=192.168.30.0/24 dns-server=192.168.30.1 gateway=192.168.30.1 netmask=24A při kopírování v rámci sítě VLAN100 jedu s využitím CPU 1-2% 3 oddělené sítě, v každé jedna ethernetka a trunk do switch. DNS ok, DHCP ok. Ještě nastavím Wi-Fi, aby se mi podle MAC adresy přiřazovali klienti do VLAN a hotovo. Vantomas: díky!
VLAN-y podporuju skoro vsetky MKT, ale nie vsetky maju HW podporu pre offloading, cize vsetko riesi hlavne CPU a nie CPU na switch-chip-e.4011 bohužel VLAN na switchi nepodporuje, takže jestli to chápu správně prostředky CPU oproti stávajícímu řešení neušetřím.
Tiskni
Sdílej: