Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
9.2.2012 12:32
| Přečteno: 1610×
| 
Tak nějak se mi zdá, že klasifikace iptables -m state --state ESTABLISHED,RELATED občas zašvindluje.
U nás v práci máme hraniční router a v něm stovky pravidel iptables určujících, odkud kam se smí a nesmí. Někde skoro na začátku se skví tohle:
# ACCEPT ustanovene spojeni iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Očekává se od toho, že pakety patřící do již navázaného spojení (ESTABLISHED) a také pakety navazující nové spojení v rámci již běžící komplexnější komunikace (RELATED) budou bez dalšího odroutovány. Při tom do kategorie ESTABLISHED se počítají i pakety SYN-ACK odpovídající na úvodní SYN při navazování TCP soketu. Dobře, tak se to obvykle dělá. 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. Na první pohled to vypadá, jako kdyby WWW server byl asi kraknutý a snažil se připojit z portu 80 na pécéčko klienta.
Avšak zdání klame. 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í. Co se tedy děje? Nejspíš to, že od stanice odejde regulérní navazující SYN a modul -m state si ho nevšimne. Následně server vrátí potvrzující paket SYN-ACK a ten je vyhodnocen jako pokus o navázání spojení zvenčí na stanici a tedy odmítnut.
Jiné vysvětlení mě nenapadá. Navazující SYN nemohl odejít jinudy, to je vyloučeno. A zakázaný paket od serveru musí mít nastavený příznak SYN, protože tam máme taky pravidlo
iptables -A FORWARD -p TCP ! --syn -m state --state NEW -j NOTSYNKdyby ten nečekaný paket neměl SYN, byl by chainem NOTSYN zalogován jiným způsobem, než jak se to děje. Nevidím jinou možnost, než že modul -m state občas zachybuje. Což má ovšem za následek, že spojení je odmítnuto, klient to musí zkusit znovu a uživatel pak vidí zhoršenou odezvu.
Tiskni
Sdílej:
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.
9.2.2012 15:53
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz