Google spustil konverzační AI Bard. Vyzkoušet lze zatím pouze ve Spojených státech a Spojeném království. Více v Bard FAQ.
David Buchanan na svém blogu rozebírá zranitelnost acropalypse (CVE-2023-21036) telefonů Google Pixel. Z výřezu (crop) snímku obrazovky vytvořeného integrovanou aplikací Markup může být možné částečné obnovení původního snímku obrazovky. Viz tweet Simona Aaronse. Vyzkoušet lze webovou aplikaci acropalypse.app. Opraveno v březnové aktualizaci.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.19.0. Přehled novinek i s náhledy v příspěvku na blogu. Kvůli "převzetí Gitei" společností Gitea Limited byl v prosinci loňského roku představen fork Gitei s názvem Forgejo (Codeberg).
Byla vydána nová verze 5.11 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Nově je používán zram. Tor Browser byl aktualizován na verzi 12.0.4. Thunderbird na verzi 102.9.0.
Na GOG.com běží Spring Sale. Při té příležitosti lze získat zdarma počítačovou hru Lorelai (ProtonDB).
Curl, řádkový nástroj a knihovna pro přenos dat po různých protokolech, slaví 25 let. Vydána byla nová verze 8.0.0. Mimo jiné řeší 6 zranitelností.
V sobotu 25. března proběhne Arduino Day 2023. Od 14:00 lze sledovat oficiální stream. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Fabrice Bellard, tvůrce FFmpeg nebo QEMU, představil TextSynth Server. Jedná se o webový server nabízející REST API k velkým AI jazykovým modelům. CPU verze je k dispozici zdarma jako binárka pod licencí MIT. GPU verze je komerční. Vyzkoušet lze na stránkách TextSynth.
Na konferenci LibrePlanet 2023 byly vyhlášeny ceny Free Software Foundation. Oceněni byli Eli Zaretskii za dlouhodobé příspěvky (správce Emacsu), Tad „SkewedZeppelin“ za nové příspěvky (správce DivestOS, distribuce Androidu) a projekt GNU Jami za společenský přínos.
Projekt Libreboot (Wikipedie) vydal novou verzi 20230319 svého svobodného firmwaru nahrazujícího proprietární BIOSy. Přibyla například podpora Lenovo ThinkPadů W530 a T530. Libreboot je distribucí Corebootu bez proprietárních blobů.
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 52 byte packets
1 192.168.2.1 (192.168.2.1) 1.257 ms 1.099 ms 1.076 ms
2 ul_vanovska_175.amigonet.cz (10.27.58.1) 3.818 ms 2.976 ms 3.005 ms
3 85.193.4.53 (85.193.4.53) 3.106 ms 2.961 ms 4.294 ms
4 217.117.213.49 (217.117.213.49) 7.310 ms 6.006 ms 5.650 ms
5 78.108.176.49 (78.108.176.49) 7.094 ms 6.451 ms 5.979 ms
6 192.168.1.1 (192.168.1.1) 10.770 ms 8.492 ms 6.917 ms
Co si o tom můžu myslet? Někde někdo zapojil stroj s touhle adresou do veřejné sítě? Je to možné/běžné? Nebo je to normální a on zase může pingat mě? Nejsem profík, ale myslel jsem, že tohle by možné být nemělo...
Firewall tam očividně nemá, otevřený má snad úplně všechno, ale asi sem nebudu posílat kompletní výpis nmapu... Traceroute je docela pěkný . No správně to určitě není. Pravděpodobně router 78.108.176.49 má někde připojenou větev s rozsahem 192.168.1.0/něco či podobně. Daleko by se to dostat nemělo, někde se najde router, který to odfiltruje.
Každopádně stává se to. Občas mi na server, který je v serverovně připojen pouze do veřejné sítě, připlujou pakety z privátních rozsahů. Samozřejmě je toto špatně a může se taky jednat o útok. Není problém tyto pakety blokovat přímo na firewallu.
Ono když dneska kde kdo provozuje WiFi a říká si ISP, tak to není problém. Pak chceš veřejnou IP a ve výsledku se k tobě dostane několikrát NATovaná, atd.
Jinak, jak nás učili. Privátní rozsahy do internetu nepatří a nejbližší router to zablokuje. A to, že je realita jiná, to už nikoho nezajímá
Zkuste napsat dotyčnému ISP, zajímá mě odpověď :).
Privátní rozsahy do internetu nepatří a nejbližší router to zablokuje.Router nemůže nic blokovat, blokuje vždy firewall. A IMHO na nastavení firewallu ohledně těchto adres žádné oficiální pravidlo (ala RFC) není. IMHO správná odpověď na traceroute na privátní adresu by měla být buď to co vidíme v tazatelově případu (tj. úspěšné protrasování, viz níže) nebo !N (network unreachable) protože jednoduché routery s defaultní cestou budou paket přeposílat, zatímco páteřní routery s BGP nebudou mít pro privátní síť cestu. Ale většinou je odpověď * (timeout) protože to právě cíleně blokují buď proto že to vede někam k nim nebo se řídí tím Vaším pravidlem. Mít možnost se dotrasovat až k živému stroji na priv. síti ale není IMHO zas takový problém. Z hlediska síťového se router chová správně - priv. rozsahy jsou normální IP, akorát u nich není zajištěna jednoznačnost. Z hlediska bezpečnosti je otázka: jestli si to cílové PC umí ohlídat svou bezpečnost samo za sebe, tak že se dostanete až na něj problém není. Obecně je to lepší bezpečnostní politika než "na perimetru natvrdo zaříznout privátní rozsahy a doufat že se dovnitř nikdo nedostane".
Router nemůže nic blokovat, blokuje vždy firewall. A IMHO na nastavení firewallu ohledně těchto adres žádné oficiální pravidlo (ala RFC) není.Router teoreticky může "blokovat". A to tak, že příslušné IP rozsahy bude routovat na interface odpovídající /dev/null Jinak myslím, že RFC 1918 se o těchto adresách a chování routerů zmiňuje. Dokonce snad tak, že na rozhraní s veřejnou IP adresou je korektní zahazovat pakety přicházející z privátních rozsahů. Jegnou jsem to řešil, protože od našeho ISP jsme měli na rozhraní routeru veřejnou adresu, ale on ve své síti pro jiné zákazníky používal 192.168.1.X, a my v interní síti taky. Takže tihle jeho zákazníci se pak na naše servery nemohli dostat, nehledě na to, že na logy z firewallu pak člověk kouká divně a hledá kde je chyba.
Jo to je taková šedivá oblast. Ale asi bych to sejně nazval firewallem i když je implementovaný pomocí routovací tabulky. Důležitý je vždy účel, ne technologie.Router nemůže nic blokovat, blokuje vždy firewall. A IMHO na nastavení firewallu ohledně těchto adres žádné oficiální pravidlo (ala RFC) není.Router teoreticky může "blokovat". A to tak, že příslušné IP rozsahy bude routovat na interface odpovídající /dev/null
Jinak myslím, že RFC 1918 se o těchto adresách a chování routerů zmiňuje. Dokonce snad tak, že na rozhraní s veřejnou IP adresou je korektní zahazovat pakety přicházející z privátních rozsahů.
It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise.Tohle je dost vágní a jediné co z toho má smysl je to o tom filtrování routovacích cest. Což by se mělo dělat bez ohledu na rozsahy :) Vím že hodně lidí prostě privátní adresy zvenku zahazuje a naopak ale myslím si že to není stavební kámen ničeho jen taková zvyklost.
A nemáš tam někde nějakej tunel? Jakou máš routovací tabulku, je tam ten rozsah nebo defaultka? Kdybys měl spojení lan to lan, tak to neni nic divnýho. Přijde mi to na lameřinu od ISP, že nechává takhle vnitřní adresní prostor otevřený.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 303 0 0 wlan0
default 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0
Dokud jsem si tu hrál s tím svým routerem, tak nebylo rozeznat, že 192.168.1.254 je úplně někde jinde, myslel jsem si, že se mi někdo napíchnul na wifi... když jsem ho odstavil, tak jsem zjistil, že je takto dosažitelná i cizí 1.1, a pak jsem zkusil ten traceroute a bylo mi jasný, že to je někde jinde...
pokud bude správně nastaven firewall bez NATu, tak pro stroje za firewallem to bude vypadat dosti podobně (neříkám, že stejně) - nepůjde navázat spojení zvenkuPokud bude ten firewall nastaven správně, nepůjde navázat spojení z venku – u NATu ale možná nějakým způsobem z venku spojení navázat půjde, a správce pokládající NAT za náhradu firewallu o tom nebude vědět.
Navíc slušnej firewall zahodí paket se zdrojovou adresou, kterou má/zná na jiném interfejsu.
iptables
na ně hodíte rozkládání zátěže, takže každý paket může odejít i přijít z kteréhokoliv vnějšího rozhraní, pochopíte proč
Pak napovim ... anti-spoofing firewall.
Buď neumíte anglicky, neumíte hledat a selektovat informace nebo nerozumíte základním pojmům. Abych oplatil stejnou mincí.
Jelikož vim, co chci říct a na první stránce toho výsledku hledání to vidim jasně, tak považuju svou odpověď za dostačující.
Buď neumíte anglickyKdyž anglicky tak proč nás posíláte na google.cz?
na první stránce toho výsledku hledání to vidim jasněMyslíte tenhle blábol na dobrou noc? ;) Tak tomu nevěřte. Jak říkám - ty odkazy nevedou na nic zajímavého.
Budiž.
A to jsem teprve v půlce stránky ... mimochodem, není to technologie dostupná pouze u jednoho výrobce.
Vy jste našel jeden blábol na celé stránce. Já pět odkazů v půli stránky, pět takových, které se týkají zmiňované problematiky.
Buď si děláte srandu nebo jste malé dítě.
Jestli Vám to přijde jako výmluva na předražený produkt, tak nevim. Asi Vás to nezajímá, že si nenajdete něco víc.
Klidně se bavte, já jdu dělat.
To může způsobovat i dalekosáhlejší a mnohem závažnější problémy než jen že se pár lidí nepřipojí.
Tiskni
Sdílej: