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.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána nová verze 2.4.64 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 8 bezpečnostních chyb.
Společnost xAI na síti 𝕏 představila Grok 4, tj. novou verzi svého AI LLM modelu Grok.
iptables --table filter --new-chain SECURE_SSH iptables --table filter --append SECURE_SSH --match recent --set --name SECURE_SSH_RECENT iptables --table filter --append SECURE_SSH --match recent --update --name SECURE_SSH_RECENT --hitcount 10 --seconds 60 --jump DROP iptables --table filter --append SECURE_SSH --jump ACCEPT iptables --table filter --append INPUT --match state --state NEW --protocol TCP --match multiport --destination-port 22 --jump SECURE_SSHA to je asi tak všetko čo mám - čomu rozumiem. Chcem sa ale opýtať, že aké su ešte možné techniky škodenia a ako im zabrániť na firewalle? Napríklad na nete som našiel takéto niečo:
iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,SYN FIN,SYN --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags SYN,RST SYN,RST --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,RST FIN,RST --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags FIN,ACK FIN --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags PSH,ACK PSH --jump DROP iptables --table filter --append INPUT --protocol TCP --tcp-flags ACK,URG URG --jump DROPO čo tu presne ide? Na rôznych stránkach som našiel rôzne varianty takéhoto kódu, niektoré to boli príklady na 4 riadky, niektoré na 6 a tento 9 riadkový príklad je najdlhší aký som našiel. Ďalej som našiel takého niečo:
iptables --table filter --new-chain SYN_FLOOD iptables --table filter --append SYN_FLOOD --match limit --limit 1/s --limit-burst 3 --jump RETURN iptables --table filter --append SYN_FLOOD --jump DROP iptables --table filter --append INPUT --protocol TCP --syn --jump SYN_FLOODTomuto rozumiem čo robí, len ten limit je nastavený správne? Aké sú ďalšie techniky na obranu proti svinstvu z netu? Vopred vám veľmi pekne ďakujem za odpovede.
napríklad privátne adresy nemajú čo hľadať na rozhraní, ktoré ide do netu
To neplatí obecně. IPSec je jedna z důležitých výjimek.
(Ať tak nebo tak, IPv4 se svými „privátními“ adresami je něco jako mor, protože kvůli němu přestal fungovat Internet „tak, jak měl“ a zvítězily pak pochybné technologie typu Skype, které celý uměle vytvořený problém „řeší“.)
Základní technika obrany proti svinstvu z netu (na které všechno ostatní stojí) je aktuální kernel. Pokud jde o ip{,6}tables, filtrovat se dá téměř všechno, ale v každém případě by mělo být povolené ICMP{v4,v6}. Dají se nastavit omezení na frekvenci a typ zpráv, ale bez ICMP může docházet ke spoustě ošklivých jevů jak pro klienty serveru ve vnějším Internetu, tak pro stroje ve vnitřní síti, pro které server třeba slouží jako router. Jde zejména o MTU. Když je někde po cestě menší MTU než lokální, uživatelům se pak třeba nestahují z některých serverů stránky, případně se jejich stahování pokaždé na pár minut zasekne.
Pravidla s typy TCP paketů by pravděpodobně měla být vhodně seřazená a na vhodném místě v řetězci oddělená něčím jako
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
To oddělí kombinace flagů, které jsou podezřelé vždy, od těch, které se v navázaném spojení můžou vyskytovat. To všechno by pak mělo být před přijímacími pravidly pro různé konkrétní protokoly nad TCP. Otázkou zůstává, jestli má smysl „závadné“ kombinace flagů takto fitrovat. Nesmyslné kombinace musí zahodit přímo TCP stack v kernelu. (Kdyby na něj nebylo spolehnutí, Internet by byl velmi nebezpečným místem.) Jediné vysvětlení by mohlo být, že správce u nějaké konkrétní služby neočekává jisté typy chování (protistrany), takže si může dovolit některé zvláštnosti odfiltrovat. Nicméně nepřipadá mi, že by se něco takového obecně hodilo jako globální nastavení pro všechny protokoly nad TCP.
Ochrana proti SYN floodingu je v kernelu zabudovaná pro IPv6 i IPv4 a ve většině případů není nutné vymýšlet na to nějaká explicitní pravidla. Přímé filtrování na základě frekvence se sice na první pohled může jevit jako dobrý nápad, ale nějaký globální limit nadělá nakonec víc škody než užitku, protože jeden útočník útočící na jednom portu může klidně omezit použitelnost všech ostatních služeb, když se mu zlíbí. Přinejmenším by mělo existovat jiné nastavení pro SSH (velmi nízká frekvence i burst) a jiné třeba pro HTTP, DNS (ano, i tam dojde na TCP, třeba u DNSSEC) či obecně pro protokoly, kde se větší bursty dají očekávat. Rozhodně tady nebude fungovat one size fits all konfigurace; server pak může navenek vypadat jako nespolehlivý a každou chvíli offline.
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTZ "vonku" povoľujem len ICMP, 22, 25, 53U, 53T, 80, 443, 465, 993, 1194 a z "vnútra" je to samozrejme nejaká samba, proxy, ntp, cups, udpxy, ... Ešte raz ďakujem.
Mimochodom, dala by sa viac rozviesť tá myšlienka ohľadom tohto:-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Před tím pravidlem jsou pravidla, která sežerou všechny možné vadné nebo nechtěné pakety — nechtěné nebo vadné za všech okolností, bez ohledu na to, jestli existují nějaká TCP spojení. (Ne že by taková pravidla byla nutná, ale někteří správci je rádi používají kvůli logování — aby měli přehled o případných pokusech o útok.)
Po tom pravidle následují pravidla, která sežerou pakety předstírající existenci nějakého TCP spojení, přestože ve skutečnosti žádné neexistuje. Taková pravidla se používají snad jedině kvůli logování; každopádně ale nechceš, aby se k nim řetězec dostal v případě, kdy spojení opravdu existuje. Že spojení existuje, o tom ví právě modul conntrack
.
Pravidlo s conntrack
se dá použít ještě v jednom případě: Když je nějaký řetězec extrémně dlouhý. Pak se toto pravidlo dá někam na začátek řetězce a ušetří tak průchod celým řetězcem při každém paketu. V některých jiných systémech (FreeBSD, Solaris) má firewall stromovitou strukturu, která se samovolně přeuspořádá a rotuje v závislosti na přijímaných paketech, aby se vždycky nejčastěji přijímaný typ paketu ocitl nejblíž kořeni stromu. (Tím pádem není potřeba řešit dělení pravidel do řetězců a počet pravidel.) Tohle ale v Linuxu (zatím) není, takže se někdy může hodit průchod dlouhým řetězcem zkrátit. Na gigabitovém ethernetu to rozhodně nehraje roli, zatímco u 10 Gb/s se už o takových věcech uvažovat musí.
Tiskni
Sdílej: