Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Řešení dotazu:
Jsem si vzpomněl .. denyhost mají umožňovat synchronizovat svuj seznam s ostatními ... link.
Jj. Co jsem dřív sledoval diskuse, tak to spíš lidi vypínali, odesílání nasosaných a zabanovaných.
Používám denyhosts. Ten si seznam útočníků vytváří sám podle místní reality.
Kromě toho umí sdílet data z některých dalších seznamů, a to oběma směry, tedy udávat útočníky i přijímat data o nich.
Je tam samozřejmě zabudovaná i odolnost vůči různým estébáckým útokům.
Jinak řečeno, těžko lze někoho dostat na seznam útočníků, pokud ve skutečnosti neútočí.
Je tam samozřejmě zabudovaná i odolnost vůči různým estébáckým útokům.Samozřejmě že tam je ... a velmi inteligentní! Kolik máte ten threshold? 10? Tak to Vám tam nasubmituje každý kdo se umí připojit 10x na nějakou veřejnou síť pod různými adresami.Jinak řečeno, těžko lze někoho dostat na seznam útočníků, pokud ve skutečnosti neútočí.
Jenže nic by tím nezískal. Proč by to vlastně dělal? Zabránil by mi v přístupu na spousty serverů, na které jsem se stejně nikdy nechtěl hlásit. (A i kdybych snad chtěl, stačí změnit IP adresu.) Ta „ochrana“ je tam spíš proto, aby si někdo kvůli jednomu překlepu nezamkl okamžitě přístup ke všem serverům ve firmě. Jeden server ho odřízne, ale ostaní to neřeší, pokud nejde o nějaký masový útok. A tak to má být. Neumím si představit, že by mě ve škole kvůli překlepu najednou odmítla celá laborka. Nicméně pokud budu rýpat do deseti hostů najednou, to už je jiné kafe!
Mám takový dojem, že i tohle se tam dá nějak ošetřit. Něco v tom stylu že udavači musí být z různých C bloků, aby se počítali. Ten konfigurák je poslední dobou hodně dlouhý a už mě nebaví se v něm vrtat. 
Pokud jde o mé nastavení, nikoho neudávám a žádnými udavačskými seznamy se neřídím. Ty seznamy bývají dost velké a nic pozitivního nepřinášejí. Můj seznam obsahuje stabilně cca 200 záznamů (které se po pěti týdnech mažou, pokud to během dané doby útočník nezkusí znova) a jsem naprosto spokojený.
Můj cíl byl jasný: snížit počet pokusů o přihlášení z původních cca 3 milionů denně na únosnou mez. Dnes mám v průměru 2 pokusy za den, které samozřejmě vyřeší denyhosts. Takže jsem spokojený a nějaké sdílení dat tam vymýšlet nepotřebuju.
Už jsem chtěl přejít výhradně na autentifikaci certifikátem, ale bohužel se pořád ještě tu a tam buď já nebo některý jiný uživatel serveru potřebuje nalogovat z počítače, který není jeho. Jasně, tohle s sebou nese další riziko, ale prostě to tak je. Leda že bych u sebe pořád nosil flashdisk s klíči a certifikátem,
v podobě vhodné pro OpenSSH i Putty... No, to asi ne.
Jsou tu i jiné a důležitější věci, které mě dost tankují a které se občas netýkají SSH. Například
Zkrátka a dobře, obava z toho, že mě někdo nahlásí všem instancím denyhosts, je jeden z nejmenších problémů. 
3 milionů denněTo je asi 35 spojení za sekundu a každou sekundu. Kam na to chodíte?
Někdy jich bylo za sekundu 100, jindy zase třeba hodinu skoro klid. Fakt nevím, co tím kdo sledoval. (Ano, mít v iptables omezení počtu SYN paketů za sekundu je fakt dobrý nápad... Ale každý s administrací jednou začínal, že.)
Tenkrát byl dost pomalý upload, takže samozřejmě bylo divné to neustálé škubání na VoIP a další síťové problémy. Ale hlavní nápor byl v noci, kdy nikdo nic po serveru nechtěl. Takže to pořád nestačilo na nějaké velké podezření.
Na logy jsem tehdy koukal tak jednou týdně. Byl to prostě malý domácí server, který nejlépe slouží tím, že o něm člověk vůbec neví, a čtení logů není můj jediný smysl života. 
Až jednoho krásného dne (a ten krásný den nastal setsakra rychle) došlo místo na logovacím oddíle, který měl 800 MB. To je asi tak stokrát víc logů, než běžně mívám.
Ty pokusy nepocházely z jedné adresy. Byly to minimálně desítky (IPv4) adres. Podle logu to vypadalo, jako by někdo vzal třeba CIDE (Cambridge International Dictionary of English) a zkoušel jedno heslo za druhým.
Proč tolik úsilí kvůli domácímu serveru, to fakt nevím.
Proč tolik úsilí kvůli domácímu serveru, to fakt nevím.To nikdo nezkoumá, co je to zač. To je jednoduše snaha získat pod kontrolu počítač, který pak může sloužit k rozesílání spamu, k řízení dalších počítačů/zombie v takto budované síti, k DDoS útokům… A pokud se ukáže, že je ten počítač na slušné lince, dá se použít jako skladiště warezu apod. Ta hesla (i počítače) zkouší nějaký automat, který nejspíš řídí síť takto již dříve získaných počítačů („domácích“ serverů, na kterých nezáleží).
To bylo přes IPv4, nikoliv IPv6.
Přes IPv6 jsem zaznamenal několik šťourání v DNS a mailových útoků, ale bývá to asi tak pět případů do týdne.
table bruteforce persist
block quick from bruteforce
pass in proto { tcp udp } from any to any port ssh \
flags S/SA keep state \
(max-src-conn 1, max-src-conn-rate 1/10, \
overload bruteforce flush global)
Pred a za jmenem tabulky bruteforce jsou spicate zavorky, ale mistni server to povazuje za tag, tak jsem to nemohl pouzit
pass in quick proto tcp from any to port 22 keep state \ (max-src-conn-rate 12/60 overload badguys flush global)kde badguys je bruteforce u mna .. ale nemalo to zmysel, ten zoznam len rastol ( viac ako 2tisic ked som to stopol) ..
Tiskni
Sdílej: