Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
for watch in $UDP_PORT_SENTRY; do $IPTABLES -A INPUT -i $INTERFACE -p tcp --dport $watch -j ACCEPT done
PS: ano, ja vim ze toto neni 100% reseni, ale ja opravdu radeji jednoduchy system ktery dela to co ma bez zbytecnych "blbinek" navic.
.
U SSH doporučuji kromě standardních opatření použít direktivu AllowUsers (popř. AllowGroup) na povolení přístupu k SSH ze strany pouze některých uživatelů. Pro každý případ.
Monitoring. Vlastní skripty parsující logy, logcheck, logwatch. Občasné použití chrootkitu a rkhuntera nezaškodí. Aktivní IDS nepoužívám, můj server by to nezvládal, a i kdyby ano, vzhledem k topologii sítě by nebyl efektivní.
Kernel. Líbí se mi grsecurity, ale bez oficiálního zdroje pro Debian s binárkou určenou pro mou architekturu budu raději používat distribuční kernel.
Díry. Ano, audit pomocí Nessusu či dalších nástrojů pomáhá, jinak hlavní je (kromě správné konfigurace) častá aktualizace (v mém případě jednou denně).
Modul recent používám pro ochranu SSH, ale v mém případě moc využívaný není. Démon mi totiž nevisí na portu 22, kam směřuje většina automatizovaných útoků. Na portu 22 mám tarpitJakym zpusobem vytvarite tuto past? Ja pouzivam tinyhoneypot ale hledam neco lepsiho, vite o necem?.
Nicmene je to skutecne tak zhave?Já myslím, že vůbec ne. Dokonce bych řekl, že pokud nepoužíváte vyloženě slabá hesla a máte vypnutý PermitRootLogin, můžete mít SSH klidně na portu 22, firewallem k němu přístup nijak neomezovat, a přesto být v relativním bezpečí. Mít SSH na jiném portu se hodí (pouze) k odražení automatizovaných útoků, protože ty v drtivé většině případů portscan neprovádí a předpokládají, že SSH bude na portu 22. Když ho u vás nenajdou, půjdou "o dům dál". Zkušený útočník bez problémů najde SSH na kterémkoliv portu. Pokud použije sniffer, odhalí třeba i port knocking. Nicméně, podle mého soudu, i zkušený útočník bude dávat přednost strojům se slabším zabezpečením, protože mu průnik do nich zabere mnohem méně času a úsilí. Pokud tedy nebude mít nějaký explicitní důvod, proč se probourat zrovna na váš server.
mam za to, ze kdyz mam zakazane prihlasovani pres heslo...a svuj klic mam chraneny passphrase...tak clovek, ktery by se byl schopen lognout by musel byt takoveho kalibru, ze nejake pasti v podobe toho cos rikal ho asi neprekvapiPřesně tak. Tohle zabezpečení je více než dostatečné. Ono v pohodě stačí i silnější heslo a přihlašování bez klíče. Samozřejmě je třeba dbát zejména na to, odkud se hlásíte (keylogger, apod.).
nebo je to snazsi nez sem si myslel? prolomit ssh??Neřekl bych. Zejména pak, pokud pravidelně aktualizujete.
Tiskni
Sdílej: