Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
Byla vydána nová major verze 9.0 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání.
Spíš myslím že ne. Když se na TCP spojení dlouho nic neděje, opravdu router může usoudit, že spojení není aktuální a příští paket potom bude vyhodnocen jako NEW. Ale ten příští paket nebude přece SYN? A když nebude, zamečuje pravidlo NEW_NOT_SYN a podle toho to bude zalogováno, což se ale neděje.
A jsou po celé cestě stejné timeouty? V linuxu by měly platit jako zde uvedené ... ?
Mimochodem, pokud je spojení vyhodnoceno jako prošlé, mělo by se o tom přes icmp či nějaký tcp/reset poslat info ...
A nepřeplňuje se connection-tracking tabulka?
Nevím,to bych měl vidět v logu? Log je hodně objemný, co mám grepovat? Zdá se mi to dobrá myšlenka, ale v logu nic nevidím.
V logu jádra není nic, co by ukazovalo na přeplnění tabulky pro conntrack. Škoda, vypadalo to jako slibný vysvětlení.
Pozorujem to však spravidla na ssh spojení.
jenže v logu routeru vidíme četné zakázané pokusy o navázání spojení iniciovaného z nějakého WWW serveru se zdrojovým portem 80, kde cílovým strojem je nějaká naše stanice vysoký port.
Ve skutečnosti šňupání paketů pomocí tcpdump ukázalo, že nic takového se neděje, žádné SYN pakety od cizích WWW serverů neběhají.
Pokud to router zahodí, tak je snad logické, že to dál po síti neběhá, ne? Nebo kde se to přesně zakáže a kde šňupete tcpdump-em?
Jinak server nemusí poslat SYN+ACK v jednom paketu, může poslat ACK zvlášť a SYN zvlášť, a není vůbec nic proti RFC793, to říká, že ACK a SYN od serveru může být v jednom paketu. Že to tak být může, se časem nějak vytratilo z překladu, takže se na to přehnaně spoléhá, čehož využívá tzv. split handshake attack, na nějž jsou náchylné některé HW routery. Takže otázka je, jestli před iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT není ještě jiné pravidlo, které SYN od serveru (nesprávně) zahodí. Případně se může stát, že se ACK serveru ztratí (nebo zpozdí) někde po cestě k routeru a dorazí pouze SYN.
Až tak ??? Řekněme že klient i server jsou MS. Něco si řeknou a pak zavřou spojení. Uživatel klikne a IE pošle rovnou HTTP request. Pakety odejdou, protože ven pouštíme všecko. Server se zaraduje a pošle odpověď. Pakety od serveru nemečujou s podmínkou
-m state --state ESTABLISHED,RELATEDprotože spojení nebylo řádně navázáno. Ale nemečujou ani s podmínkou
-p TCP ! --syn -m state --state NEWNení to sice SYN, ale není to ani NEW, protože před chvilkou tady nějaký provoz šel. Vypadá to divně, ale když vyslechnu uživatele postižených stanic a všichni se přiznají k použití MS IE, tak by to začalo vypadat jako docela dobrá hypotéza.
Šňupáme samozřejmě na routeru. SYN který není NEW propouštíme. Zahozené něco od serveru šlo na stanici, která před chvilkou s tím samým serverem normálně komunikovala. Ta chyba není fatální, uživatelé vůbec nevědí, že jim něco nefunguje. Jenom mají asi delší odezvu.
Ono to jenom vypadá jako pokus o pokračování spojení ze serveru na stanici, je to ze zdrojového portu 80 na nějaký vysoký port, ale není to tak. Číslo portu stanice je jiné než ze kterého šlo předchozí spojení. Takže to není chyba conntrack a dokonce ani chyba Microsoftu, je to jen obyčejný útok. Omlouvám se za zbytečné plašení. Jako IP adresy atakujících serverů jsou fingovány adresy oblíbených webových serverů, takže vlastně každému logovanému případu předcházelo skutečné připojení na tento server v nedávné minulosti.
Tiskni
Sdílej: