Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 2 [3] 4 5 ... 265
31
Odkladiště / Re:abclinuxu.cz je dead?
« kdy: 13. 09. 2020, 18:00:57 »
Nedělal bych zas takovou kovbojku z toho, že přes víkend neběží web, o který se stará jeden člověk ve svém volném čase. Než kupovat doménu a data bude jednodušší počkat, až to Luboš v pondělí nahodí.

32
Bazar / Re:Koupím knihy o umělé inteligenci
« kdy: 11. 09. 2020, 18:05:50 »
Mám jen díly 1–3. Máte zájem i o ně, nebo chcete jen komplet 1–5?

33
O tom se budu hádat. Tam už nerozlišíte dst před NATEM.
Místo hádání si raději nastudujte průchod paketu netfilterem. Obrázek jste sám nedávno linkoval.

Sanitizace není filtrování v pravém slova smyslu, to je z pohledu routeru-firewallu nevalidní provoz a do reálných pravidel se ani dostat nemá.
Filtrování je blokování nevalidního provozu. Není rozdíl v tom, jestli paket zahodíte proto, že víte, že zařízení s cílovou IP adresou ve vaší síti není, nebo proto, že víte, že služba na cílovém portu není ve vaší síti poskytována ven. Například.

34
Pravidla ovšem mají jak -i, tak -o, a kromě -src i -dst.  Je to takhle kompletní? Tedy filozofie : externí  = "blacklist" v směru dst ip neočekávám privátní rozsahy a v směru  src neočekávám moji síť; interní="whitelist"= směr src pouze. Jelikož dst zde nedává logiku
Musíte vědět, v jaké síti je váš router. Pokud je to ten nejjednodušší případ, máte router připojen do internetu a router má na svém vnějším rozhraní veřejnou IP adresu, router je tedy připojen do skutečného internetu. Pak se IP adresy z privátních rozsahů nemohou objevit u paketů z internetu ani v src ani v dst (ani pro INPUT ani pro FORWARD). Jedinou výjimkou by byl váš privátní rozsah v dst ve FORWARD, pokud byste používal DNAT (např. přesměrování portu z veřejné IP adresy do vnitřní sítě).

U paketů z vnitřní sítě se nesmí žádný privátní rozsah objevit v dst (pokud router propojuje jen vaši jednu privátní síť s internetem), v src bude jenom privátní rozsah z vaší sítě, ostatní také budete blokovat. Váš privátní rozsah v src je v pořádku, protože se následně v POSTROUTINGu aplikuje SNAT. Pakety, které vznikají na vašem routeru (INPUT) jako dst nemohou mít privátní rozsahy mimo ten, který používáte ve vaší interní síti.

Co když používám pravidla která mají -i  + -o zároveň? (jelikož router má 2 interface ). Je to dobrá věc nebo zbytečná komplikace
Mezi dvěma sítěmi (místní a internet) se to moc nepoužívá, protože obvykle na hranicích těch sítí zkontrolujete, že jde o povolený provoz z/do té sítě, a pak už mezi těmi sítěmi chcete povolit vše. Ale pokud byste měl sítí víc (a každou na samostatném rozhraní), dávají taková pravidla smysl – někdy budete chtít mezi různými sítěmi povolit různý provoz. Hodně primitivní příklad z dávných dob je ten, že do demilitarizované zóny povolíte z interní sítě přístup přes SSH, ale z internetu ne.

35
Kolegové mě opraví, nemám to před sebou, ale myslím, že je to nějak takto:
1) kontrola src vůči vstupnímu interface patří do raw/prerouting
2) kontrola dst vůči výstupnímu interface patří na dvě místa: filter/output + filter/forward
Nikoli, veškeré blokování provozu patří do tabulky filter. Průchozí provoz se kontroluje ve FORWARD, provoz z/na router v OUTPUT/INPUT.

36
Z jakého důvodu počítač v roli routeru (linux, ipv4.forwarding=1) opouští pakety s cílovou adresou 10.0.x.x do upstream sítě, když má vnitřní síť je 192.168.1.0/24  a upstream síť 192.168.2.0/24? Probíhá NAT na 192.168.2.99.
Buď takové pakety generuje nějaký proces na tom routeru, nebo na něj přicházejí z nějaké sítě, ke které je připojen.

Brána providera vrací ICMP unreachable.
To je správně.

Tyto pakety (když už by neměly opouštět upstream síť) , což se neděje, tak nechci aby opouštěly mou síť .
Upstream síť je síť ISP. Vy jste to na začátku psal opačně – ty pakety jdou z vaší sítě do sítě ISP.

Je nějaký usecase, kdy je komunikace do privátních sítí legitimní (Samozřejmě kromě případů, že sám počítač do té sítě náleží)?
Kdykoli, kdy existuje nějaká cesta do takové privátní sítě. To může být např. přes VPN nebo přes nějakou jinou síť. Ale nebude to váš případ.

Nemá tomuto jádro zabránit bez explicitních pravidel ve firewallu, jelikož jde o privání rozsahy?
Ne, musíte si na to nastavit sám pravidla ve firewallu. Jádro neví, jak vypadá vaše síť.

Nebo je k tomuhle nějaký podobný flag v sysctl.net.* jako rp_filter?
Ne.

Je lepší to řešit pomocí iptables -I FORWARDING -d 10.0.0.0/8 -j REJECT nebo ip route add blackhole 10.0...?.
Spíš to první. Případně, pokud nechcete odesílatele informovat, můžete místo REJECT použít DROP. Blackhole by se použilo někde na páteřní síti v případě, že by ten provoz byl tak silný, že byste se ho potřeboval co nejefektivněji zbavit – což nebude váš případ s počítačem v roli routeru.

37
Software / Re:Otravné hlášky googlu
« kdy: 07. 09. 2020, 20:20:14 »
Pane Jirsáku, 
Už několik příspěvků výše píšu, že problém jsem vyřešil. Tak nechápu co Vás pudí se dál vyjadřovat a do mě navážet.
Nemám pocit, že bych vás urážel. Pokud jste to tak vnímal, omlouvám se.

Jen jsem reagoval na váš komentář s vysvětlením, že lidé obvykle nebývají moc ochotní pomáhat někomu s řešením problému, který si dotyčný sám úmyslně způsobil.

38
Software / Re:Otravné hlášky googlu
« kdy: 07. 09. 2020, 18:44:43 »
Mazání historie a dat z prohlížení je každého věc.
Pokud to vy nepoužíváte, mě je to jedno.   
Nám je zase jedno, že to používáte. Jak píšete, je to každého věc – včetně důsledků.

Řešení je jednoduché, už vám bylo několikrát naznačeno, pro jistotu to napíšu explicitně: Nemažte při uzavření prohlížeče cookies ani ostatní data.

Pokud se vám takové řešení nelíbí, je to váš problém.

Mě žádné podmínky služeb na těch serverech nazajímají, jsou mi ukradené, nečtu je, otravné okno je pro mě jen obdélník s balastem který zdržuje, nechci na něj klikat, nechci na něj reagovat. Cookies mažu

– „Střelil jsem se do nohy, ale bolí mne to. Jak se mám střelit do nohy, aby to nebolelo?“
– „Nestřílejte se do nohy.“
– „Ne ne, já se chci střelit do nohy, ale nechci, aby mne to bolelo.“


Asi se budete muset smířit s tím, že na některé otázky se odpovědět nedá.

Howgh.

39
Software / Re:Otravné hlášky googlu
« kdy: 07. 09. 2020, 11:27:37 »
Je to bezpečnostní pravidlo. A vím proč to dělám. A nedivím se.
Je to „bezpečnostní“ pravidlo. Podobně jako fail2ban, zákaz vzdáleného přihlášení na roota, přesouvání SSH serveru na jiný port nebo vynucená pravidelná změna hesla. Samo o sobě bez dalších znalostí to vypadá jako dobrý nápad. Se znalostí věci se to ale najednou obrátí a ukáže se, že z toho v žádném případě nelze dělat pravidlo. Že sice mohou existovat případy, kdy je to užitečné a zlepšuje to bezpečnost, ale jsou dost výjimečné.

40
Software / Re:Otravné hlášky googlu
« kdy: 07. 09. 2020, 10:24:05 »
Mazat cookies, veškerou historii a data z prohlížení při každém vypnutí prohlížeče beru jako základní pravidlo pro bezpečné používání internetu.

Nechápu, že se nad tím někdo na tomhle servru pozastavuje.
Je logické, že se nad tím na Rootu lidé pozastavují, protože tady jsou lidé, kteří těm technologiím rozumí. Mazání cookies a veškeré historie nemá s bezpečností nic společného.

Když dáte webu nějaký souhlas, a pak smažete informaci o tom udělení souhlasu smažete, nemůžete se divit, že se vás na to web příště ptá znova. Navíc když tak důsledně mažete historii – pokud by si web pamatoval, že jste mu dal souhlas, bylo by to vaše mazání neúčinné, nemyslíte? Takže byste si asi měl rozmyslet, co vlastně chcete – chcete, aby si o vás web nic nepamatoval, nebo chcete, aby si něco pamatoval? Navzájem se to vylučuje.

41
Server / Re:Jiné cesty "zviditelnění NASu"
« kdy: 07. 09. 2020, 08:09:30 »
Dával jsem vám sem odkaz na popis služby QuickConnect. Co vám z toho není jasné?
Princip funkce na klientovi - zda  z jeho pohledu nebo jde o připojení na ten zQuickConnectěný Server jako na kterýkoli jiný FTP,HTTP(S), RTMP, ATD server, na jaké to běží IP adrese(vyhrazené?) nebo na to potřebuje nějaké speciální aplikace. V kostce: je potřeba quickconnect protipól i pro klienta?

A nebo to (poslání quickconnect) chápu špatně a quickconnect není určen pro připojování nějakých individuí k serveru , ale defacto jen pro vlastníka nas, který se k tomu bude nějak nestandardně(z pohledu z člověka co si chce otevřít  nějakou stránku na webserveru někde a tedy do prohlížeče zadá http://123.123.123.1/menu.html) připojovat (v horší případě přes nějakou appku quickconnect)?

konkrétně z "knowledgebase":
Služba QuickConnect umožňuje klientským aplikacím připojit se k zařízení Synology NAS prostřednictvím internetu bez starostí s nastavováním pravidel pro předávání portů- kterým klientským aplikacím
Klientským aplikacím Synology. Je to určeno pro vlastníka NAS serveru.

42
Server / Re:Jiné cesty "zviditelnění NASu"
« kdy: 06. 09. 2020, 18:12:58 »
Jak to tedy je... to stačí mít zařízení Synology a jako k tomu je právě tento tunel či  zprostředkování dostupnosti na veřejné IP v "ceně"? Funguje to technicky tak, že si tedy kdokoli může přistoupit do NASu (nemyslím to teď tónem že mi kterýkoli hacker se nabourá do NASu když je tedy veřejné ale ve smyslu že jde o standardizovanou službu FTP,HTTP,ATD a ten člověk ani nemusí vědět že je to na NASu od synology nebo že je to přes jejich Quickconnect?) kdo zná IP "serveru" či doménové jméno na FTP server, HTTP  Server, SSH a cokoli jiného co na svém nasu bych provozoval? Nebo je to přes nějakou "třetí stranu" s nutností mít "appku" nebo nějak "nepřímo?
Dával jsem vám sem odkaz na popis služby QuickConnect. Co vám z toho není jasné?

43
Sítě / Re:Vysoký ping na optice
« kdy: 04. 09. 2020, 21:41:58 »
Co viem, tak DSLam je stale na poste (v ustredni) do ktoreho som bol zapojeny este dnes doobedu. Od posty byvam max do 200m, takze metalika nech mala do 300-350m.
Jinými slovy, vyměnil jste 300 metrů metalického kabelu za 300 metrů optiky. Dál je to pořád stejná trasa jako dřív. Pokud na téhle trase („od pošty dál“) je „ping“1) nějakých 15 ms, celkový ping rozhodně nemůže být nižší. Jak už jsem psal, poslední míle tvoří jen část trasy od vás do NIXu, a když jste přešel na optiku, změnila se jenom tahle poslední míle, zbytek zůstal stejný.

1) První aktivní prvek, který může odpovídat na ping, bude ve skutečnosti až dál, ale berme to jako čas,kterým ta trasa k pingu přispívá.

Cize z toho moze vyplivat, ked mam vyssi ping ako som si myslel ze budem mat, ze problem bude niekde smerom od OLT do internetu.
Já bych problém viděl spíš v tom, jak jste přišel na to, že byste měl mít nově tak nízký ping. V tom spojení nejspíš žádný problém nebude. Ping 15 ms v takhle velké síti do NIXu není nic hrozného, v Praze mám v síti UP do českého NIXu ping zhruba stejný. Na počítači, který je od NIXu na 4 hopy po optice je to kolem 1 ms, ale to je dobrá komunitní síť, to je trochu jiná kategorie než Telekom.

44
Sítě / Re:Vysoký ping na optice
« kdy: 04. 09. 2020, 19:49:18 »
Nezalezi ci je to 1, alebo 4, ale 15ms  je zvycajne na DSL, tak som pocital, ze na optike to bude aspon pod 10ms.
Aha, tak to je nepochopení toho, jak funguje internet. Poskytovatel internetu nemá přímou linku od vás z baráku do NIXu a už vůbec ne k cílovému serveru. Má linku od vás z baráku do své sítě, pak má svou síť, buď po celém Slovensku nebo třeba jen v jednom městě, a pak má spoje ze své sítě do NIXu, případně další spoje do dalších peeringových uzlů, a spoj(e) k tranzitním operátorům. Když jste měl VSDL, byla to jen jiná linka od vás do sítě ISP – možná byla delší než vaše současná optika (nevím, zda Slovak Telekom je vlastníkem slovenské VSDL sítě). Taky je dost možné, že ta optika jen nahradila pár set metrů metalického kabelu a dál už jdete po té samé trase, jako dřív.

Každopádně to, co se změnilo, je jenom ta linka z vašeho domu k ISP. Od ISP dál to zůstalo pořád stejné. Takže záleží na tom, jaký podíl na tom pingu do NIXu. měla trasa od vás k ISP a jaký od ISP dál. Pokud to dříve od vás k bráně ISP bylo 17 ms a od brány ISP dál 13 ms, těžko to teď celkem může být pod 10 ms, protože to by na tu vaší lokální linku zbývaly -3 ms, a to – jak jistě uznáte – je dost nepravděpodobné.

Nebo-li ještě jednou. Teď jste naměřil cca 4 ms od vás k bráně ISP – nevím, zda k bráně směrem k vám, nebo k bráně směrem do NIXu. Na optiku to není nic světoborného, na druhou stranu, o víc než 4 milisekundy to snížit nepůjde. To, že to dál do NIXu trvá 11–13 ms také není vůbec žádná sláva, každopádně na tom ale už vůbec nic nezmění to, zda máte na poslední míli optiku, WiFi, nebo jestli tam pakety nosí poštovní holubi.

45
Sítě / Re:Vysoký ping na optice
« kdy: 04. 09. 2020, 18:31:20 »
To, že máte optiku domů, ovlivní jen poslední míli, tj. od vás do sítě ISP. Mohlo by to být méně, záleží na síti ISP, ale opravdu vám záleží na tom, zda je to 4 ms nebo 1 ms?

Stran: 1 2 [3] 4 5 ... 265