Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
|-router | |-server_a - 1. subnet |-server_b - 2. subnet |-server_c - 2. subnetMezi oběma subnety routuju pomocí routeru, který má jedno rozhraní mající ip adresy z obou subnetů. Mám ale hrozné problémy s "duchy v síti". Po restartu firewallu na serveru_a se nemůže server_b dopingat na server_a (wiresharkem mám ale ověřeno, že na serveru_a je paket přijat a je odeslána i odpověď, vše projde přes accept na firewallu). Pokud nějakým jakýmkoliv způsobem na chvíli navážu komunikaci ze serveru_b na server_a (např. telnet server_a 80), pak již ping funguje. Opačně ping funguje vždy. Nejedná se ale jen o ping. Na serveru_c běží apcupsd, k němuž se připojuje server_a. Server_a ztrácí spojení s apcupsd na serveru_c cca 30x denně. Mezi routerem a servery a v jednotlivých subnetech je komunikace vždy ok. Nevíte někdo co tohle může způsobovat? Automatický nexthop? Neměl už někdo někdy podobný problém?
Někde se vám ztrácí ICMP redirect zprávy nebo máte někde IP stack nastavený tak, aby nepřijímal packety z různých ethernetových adres nebo máte příliš přísný reverse path filter.
Když odchází ICMP response z A, odchází na jakou ethernetovou adresu? Adresu B nebou adresu routeru?
server_a -(gateway)-> switch -(gateway)-> router -> switch -> server_bJenže problém bude určitě v tom, že ty stroje na sebe vidí přímo a nějaký chytrý algoritmus se asi snaží zkracovat cesty paketům. Vyloučil bych ale z toho STP (zapojeni switchů to neumožňuje a na serverech je vyplé).
Jenže problém bude určitě v tom, že ty stroje na sebe vidí přímo a nějaký chytrý algoritmus se asi snaží zkracovat cesty paketům.
Někdo ten problém vidí jako vlastnost. Ostatně je to výchozí nastavení Linuxu.
Předpokládejme, že všechny stroje Linux ve výchozím nastavení, že switch jen skutečně prostá L2 krabička a všchny stroje mají prázdnou směrovací a ARP keš. Pak packety by měly proudit takto:
A GW B |→ ARP request for GW →| |← ARP response for GW ←| |→ Echo request 1 →| |← Redirect to B ←| |→ ARP request for B →| |← ARP response for B ←| |→ Echo request 1 →| |← Echo response 1 ←| |→ Redirect to A →| |← Echo response 1 ←|
Teď A i B vědí, že se na druhý stroj mají obracet přímo a pravidlo si zanesly do směrovací keše (ip route show cache
).
Pokud A pošle další echo request pro B, tak už se vůbec nebude s GW bavit:
A B |→ ARP request for B →| |← ARP response for B →| |→ Echo request 2 →| |← Echo response 2 ←|
B už ARP dotaz na A neposílá, protože jeho ethernetovu adresu zná z ARP dotazu od A na B. V ARP keši na obou strojích by nyní měly být záznamy jak pro GW, tak i pro opačnou stanici (ip ne show
).
Vyloučil bych ale z toho STP (zapojeni switchů to neumožňuje a na serverech je vyplé).
STP jsem vůbec neuvažoval. Stejně rámce chodí stejnými cestami. Spíše jsem myslel, že první adresu (s kterou máte problém) dostane stanice třeba přes DHCP, a pak chytré switche tohle sledují, a pak mohou podle toho nasadit „bezpečností“ filtry.
Pokud nechcete, aby stanice komunikovali napřímo, je možné v proc nebo přes sysctl vypnout na stancích accept_redirects a na routeru send_redirects.
rp_filter by měl zafungovat hned. Každopádně se tcpdumpem podívejte, jestli vám packet odeslaný z druhého stroje dorazí. Tcpdump ho uvidí ještě před rp_filterem nebo netfilterem.
Nemám tušení, co vám nastavuje shorewall. Zřejmě nějaké packety zablokuje, čímž se stroj nedozví potřebnou ethernetovou adresu nebo žádost o přesměrování. Teprve až s odchozím spojením se inkriminovaný nebo úplně jiný packet jakožto související se spojením dostane dovnitř, čímž se stroj potřebný údaj dozví. Jak jsem psal, porovnejte si směrovací a ARP keš. Taky když jste si vybral shorewall, mohl byste si za trest přečíst firewellová pravidla, která stvořil. A ještě porovnejte výstup ze sysctl --all
(je možné, že do toho shorewall také šahá).
Nepochopil jsem, co jste pozoroval na kterém stroji.
Tu tabulku jsem sledoval a dokud tam byla jen routa přes router, tak ping neprošel, ale potom se tam objevilo <redirected> na server_b
A pravidlo pro přesměrování se tam objeví, až když stroj přijme ICMP redirect. Takže hledejte, kde se vám ztrácí redirect.
Navíc i tak by to fungovat mělo, jen by požadavek šel přes router. Pořád má pocit, že vám něco někde blokuje redirect packety. Už jsem viděl „switche“ od Cisca, které pouštěli ICMP a ARP packety jen jednou za několik sekund, protože to považovali za bezpečnostní opatření.
paket odejde, cíl odpoví a už nedorazí zpátky
Pokud odpověď cíle B směřuje na ethernetovou adresu stroje A, ale tcpdump na stroji A tuto odpověď nevidí, tak vám straší v kabelech.
Tiskni
Sdílej: