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 - Miroslav Šilhavý

Stran: 1 ... 32 33 [34] 35 36 ... 206
496
Odkladiště / Re:Jak co nejvýhodněji prodat BTC
« kdy: 09. 09. 2020, 07:08:48 »
Tak dvě upozornění:
  • Na virtuální měny se zákon nedívá jako na měny. Daní se jako věc, kterou získáte (nákupem, směnou) a prodáte.
  • Je možné, že jste porušil zákon, pokud se jednalo o průběžnou činnost, ze které máte zisk. Možná Vám vznikla povinnost být podnikatelem (a tím pádem odvádět i pojištění na sociální politiku a zdravotní).

S touto otázkou Vám poradí buďto daňový poradce - ale vím, že KDPČR v otázce virtuálních měn není jednotná a daňoví poradci se do toho nehrnou. Nebo můžete situaci popsat správci daně (finančnímu úřadu) a ten Vám za 10.000 Kč dá tzv. závazné vyjádření, jak danit. To, když dodržíte, tak máte jistotu, že si stát v příštích letech nemůže vzpomenout, že to má být jinak a že máte doplatit i úroky. Čím lépe situaci popíšete a doložíte, tím je větší šance, že uznají např. náklady. Čím méně důkazů máte, tím se zvyšuje riziko, že prostě odvedete 15 % z prodejní ceny bez odečtení nákladů.

497
V rychlosti jsem mrknul na návod a bohužel musím konstatovat, že konfigurace bridge/vlan je tam hodně zmršená. Ano, je to funkční, ale neoptimalizované a zbytečně to degraduje výkon routeru. Správně má být pouze jeden bridge a na něm teprve pověšené VLANy.

U levnějších modelů nepodporuje zabudovaný switch vlan table, takže to na výkon vyjde na stejno (letí to přes CPU). Nicméně doporučují to konfigurovat na bridgi jakožto dobrou praktiku.

498
@Hamparle

Předně bych počítal, že router může mít víc než dva interface. Ať už fyzické, nebo i jiné. Tím mám na mysli např. VPN, tunely, VLAN. Pravidla bych si tvořil dopředu tak, jako kdyby byla rozhraní tři, čtyři - je to lepší na představivost.

Teď začneme u záludnosti s NATEM. Na FORWARDU už u packetu uvidíte adresu po DNAT překladu. Takže na FORWARDU už nerozlišíte, jestli packet -o interni -dst 192.168.x.x takto přišel z internetu, nebo tu adresu získal až překladem. Ověření, jestli dst/src odpovídají tomu, co se očekává na interfacu musí přijít do místa, kde se s tím dá pracovat.

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

Osobně bych tyto kontroly nascriptoval, aby se příslušná pravidla vygenerovala, protože ta samá pravidla v obdobách patří do vícero míst.

Teprve po nich bych zpracovával pravidla pro filtrování provozu - tedy co kam smí a co kam nesmí. Jestli používat -i, -o, -src, -dst záleží na směru (a dalších okolnostech). Např. povolení provozu směrem ven z routeru bych řešil -src 192.168.x.x/24 -o vystupni_interface -j ACCEPT a naopak přesměrování portů dovnitř pomocí -i -dst.

Ku pomoci jsou chainy. Do chainu nasměrujete např. veškerý provoz z internetu dovnitř (pomocí -i), ale uvnitř chainu už můžete pracovat jen s -dst.

Metod je spousta, a těžko se radí, protože to záleží na situaci i gustu každého.

Znovu opakuji, nevynalézejte kolo, na toto jsou hotová řešení, kde si jiní lámali hlavu za Vás.

499
Návod na VLANy jsem použil tento:
https://vaclavkrejci.cz/Mikrotik-nastaveni-VLAN-a-trunku

Pokud chcete jít s bezpečností dál, tak dalším krokem je oddělit ty sítě na routeru přes VRF. Tím odpadají konfigurační rizika na firewallu, aby se z návštěvnické sítě nedalo dostat jinam. Obdobně to lze řešit i jen firewallem, ale tam je to přecijen náchylnější na konfigurační chybu.

500
10.x.x.x je pro router neznámá adresa, a tak ji zcela přirozeně předává na výchozí bránu.
Na interních rozhraních je dobré filtrovat jaké IP adresy očekáváte - tj. jen adresy použité ve vnitřních sítích.
Na externím rozhraní musíte naopak filtrovat, jaké IP adresy neočekáváte - tj. RFC1918.

Když už v tom budete, je samozřejmě na místě sanitizovat i další situace - např. nevalidní kombinace TCP flagů, nebo, pokud to jde, tak naopak vyjmenovat validní.

Správná reakce je REJECT (ale podle protokolu se liší, jaký typ rejectu odesíláte). Nicméně na externí lince by se mohlo stát, že při útoku jen zesílíte důsledky tím, že linku zahltíte o to víc tím, že rejecty odesíláte. Buďto se pak limituje počet rejectů (a následně se provádí DROP), nebo jen dropujete. Pokud chcete zpomalit TCP útoky, můžete použít TARPIT (ble, ale funguje). Do interní sítě bych preferoval REJECT nad DROP zcela určitě (i když výjimky z tohoto pravidla se taky najdou).

Nevýhoda linuxu a čistých iptables / nftables je to, že kvůli univerzalitě musíte každý sofistikovanější úkol (jako je třeba toto) řešit na více místech, hlídat si vše ručně je náchylné k chybě. Nebylo by jednodušší použít Shorewall? Ten poměrně hodně takovýchto věcí nastaví podle konfigurace a dá se i hodně přizpůsobit. Matlat to v čistých (ip|nf)tables je peklo.

Ip route blackhole bych nepoužíval, je to nepohodlné a nezapadá to do konceptu firewallu jako takového.

501
Odkladiště / Re:Jak co nejvýhodněji prodat BTC
« kdy: 08. 09. 2020, 10:17:51 »
Nemusi to byt vyslovenie obchadzanie zakona, kludne postaci nejaky trik vdaka comu to bude aspon trocha vyhodnejsie, pretoze 15% z takej vysokej sumy mi proste pride vo vysledku vela.

Jak neobcházet zákon je jednoduché. Buďto je to podnikání, nebo jiná činnost, na kterou pamatuje zákon, a kde si můžete uplatnit náklady. Pak platíte daň jen z rozdílu mezi náklady a výnosy. Pokud jde o příjem z činnosti v zahraničí, musíte ještě ověřit i tamní zákony a ověřit, že s danou zemí máme podepsanou dohodu o zamezení dvojího zdanění (pokud ne, platí se daně v obou zemích). V případě podnikání Vám vzniká ještě povinnost platit zdravotní a sociální pojištění.

Pokud můžete legálně peníze převést a odvést pouze 15 % daň, tak to berte všemi deseti. Je to nejvýhodnější sazba, jakou zákon zná. (Oproti dvojímu zdanění, oproti odvádění pojistného). Všechny ostatní způsoby jsou obcházení.

Jo, ještě bacha. Pokud je škoda >= 50.000 Kč, tak správce daně automaticky podává i trestní oznámení pro trestný čin. U danění 1,5M by se o takovou škodu jednat mohlo docela jednoduše.

502
Odkladiště / Re:Jak co nejvýhodněji prodat BTC
« kdy: 08. 09. 2020, 10:13:18 »
Ještě malé upozornění z daňového práva. Správce daně má právo požadovat vyjasnění veškerých situací, kdy se osobě navýší jmění (majetek, hotovost, ...) a na nevyjasněná zbohatnutí doměřit daň. Aktuálně je v ČR nepsané pravidlo, že se zabývají rozdíly >= 5 MKč, nicméně nic nebrání finančnímu úřadu se pídit i po menších rozdílech. Záleží jen na tom, jestli na to kápnou a budou mít dostatek motivace se tomu věnovat.

503
Sítě / Re:Nastavení a výběr switche pro VLAN kolem 1000 Kč
« kdy: 07. 09. 2020, 09:27:52 »
Pokud si však pod L3 představujete IPv4 TCP&UDP PAT, tak to si ale pletete pojmy s dojmy, protože je to L4.

Dovolím si nesouhlasit v té věci jednotné terminologie. Např. NAT 1:1 je záležitost L3, helpery mohou zasahovat i do L5 a L6.

Nicméně souhlasím s tou poznámkou, že L3 switche umějí právě ty L3 operace a nic, co by mohlo zasáhnout do L4 a L5. Pokud je mi známo, tak ale ani ten 1:1 NAT ty switche nepodporují, jakkoliv je to čistě L3 operace.

504
Já teda nevím, jestli to příliš nezjednodušuji a zda OP má chytrý switch, ale řešil bych  to fyzickou bezpečností LAN zásuvek plus nastavit na portu switche ( <- LAN zásuvce) povolenou MAC adresu , pokud nad dírou nemám kontrolu, třeba na chodbě. Pokud někdo nemá kontrolu nad tím “kam se strká kabel” tak je něco špatně a hračičkovánínepomůže. YMMV

Já k tomu doplním, že na switchích lze i nastavit např. to, že MAC adresa nemusí být dopředu nastavená, ale učí se dynamicky a povolí např. jen jednu změnu za den (nebo jiný časový rámec) a při porušení pravidel může dojít buďto k dočasnému nebo trvalému vypnutí portu + report přes AAA. To je takový dobrý kompromis mezi fyzickou bezpečností a snadnou spravovatelností.

505
Sítě / Re:Vysoký ping na optice
« kdy: 07. 09. 2020, 09:19:50 »
Ach jo, věčné diskuse, protože lidé jsou zblblí z toho že "optika je to nejlepší".
Ano, ani nejlepší metalika, natož nejlepší radio nemůže dosáhnout parametrů, jako dobrá optika.

Nicméně, dobře udělaný metalický spoj, i dobré rádio dokáží poskytovat daleko lepší službu, než špatně udělaná optika, nebo optika, která stejně část trasy překonává např. vzduchem. Je naprosto běžné, že operátoři mají plán postupně přecházet na kompletně optické sítě - ale začíná se z obou konců. Nakonec se nahradí i poslední radio a začne to fungovat plně opticky.

Taky nikdo nezaručí, jaké technologie se použijí. Je rozdíl, jestli je optika honěná na kvalitních switchích, routerech. Nebo jestli operátor nechá v síti nějaké mikrotiky a do optiky to převede laciným transceiverem.

Doporučuji se nezajímat o technologii (optika, metalika), ale prostě chtít od dodavatele určité paramtery - aby sdělil, nebo garantoval. Pak Vám to může být jedno, jak si to vyřeší.

506
@M_D

Chtěl jsem říct tři různé věci:
1. komunikace s radius serverem je zabezpečená, ale pokud se někdo necítí na to, aby s jistotou udržoval šifrování, certfikáty, ..., pak by měl být prvním krokem i to, že samotné ověřování proti radiusu proběhne v jiné VLAN, než která se přiděluje (ne vždy se to totiž tak praktikuje)
2. 802.1x bych považoval za daleko účinnější první krok, než řešit DHCP snooping. Pokud něčím začít, tak 802.1x a to druhé jako něco navíc. Opačný postup nedává z hlediska bezpečnosti tak velký smysl.
3. pokud mi jde opravdu o bezpečnost, pak investice do switche není stěžejní položka; práce s nastavením a údržbou bezpečnosti je mnohem nákladnější, než nějaká škatule

Z dotazu tazatele jsem nabyl dojmu, že se zaobírá správnou myšlenkou (tj. co chránit), ale tápe v tom, jaké existují metody jak to provést. Přijde mi škoda vymýšlet řešení, které nikdy nemůže dojít k cíli - protože takovou ochranu obejde první geek, který se o to pokusí.

507
Server / Re:Jsou nutná tato pravidla v iptables?
« kdy: 04. 09. 2020, 07:56:49 »
Takže pokud vám přijde z internetu paket se zdrojovou IP adresou z RFC1918, zahodí ho buďto už rp_filter (pokud je to adresa z vaší vnitřní sítě), nebo ho můžete zahodit ve FORWARD (protože ta zdrojová IP adresa bude ještě nezměněná).

rp_filter Vám zahodí jedině packet, který by přišel na interface a s adresou, která náleží jinému interface. Jenže on tam může přijít packet s RFC1918 adresou, kterou vůbec jinde na routeru nepoužíváte - tudíž rp_filter na tom nevidí nic podezřelého. Dokonce i odpověď na něj odejde ven, směrem k výchozí bráně. Jenže Vy víte, že z internetu nic z RFC1918 neočekáváte, proto se takovým packetem nechcete vůbec zabývat, chcete ho zahodit co nejdřív to jde.

Dále, rp_filter zahodí packety jen které kolidují s rozsahem na jiném interface. Jenže Vy ten rozsah můžete mít použitý hlouběji ve vnitřní síti (odroutovaný).

A poslední důvod je, že může dorazit "z internetu" packet, který nemá RFC1918 adresu jako destination, ale jako source. A ani to nechcete do sítě propustit, a za určitých nastavení se právě tato informace může ztratit díky DNATU, kterým to projde ještě před FORWARDEM.

Proto je rozumné tyto základní kontroly nastavit na mangle. Navíc to zpřehlední filter.

508
což bude asi znamenat potřebu nějaké správy certifikátu (minimálně na authentikaci toho Radius serveru když už ne klientů).

Opět, v jednoduchém nastavení bych to neřešil a Radius ověření dal do oddělené VLAN.

509
Software / Re:Rozpadající se weby při blokování JS
« kdy: 03. 09. 2020, 13:24:48 »
Takze ne jen bezpecnost, ale vytizeni PC je duvod k blokaci. Nektere stranky ale bez JS nejdou.

Proto je to marný boj. Stránek, které se bez JS neobejdou přibývá.
Je lepší hodinu času věnovat vydělávání, než řešení něčeho, kde vývoj utíká vpřed rychleji. Za vydělané peníze, za pár stovek, se dá koupit jak lepší CPU, tak víc RAM. Prakticky všechno kolem nás je škálovatelné, čas života ne.

510
Narozdíl od toho 802.1x, což je teda výrazně složitější na nastavení i správu. alší věc je že pro WiFi je potřeba mít wireless controller který něco podobného taky umí. To už se to pravda trochu prodražuje.

S tím bych nesouhlasil. Stačí obyčejný radius server, a jestli se nepletu, dá se Radius naklikat i do Mikrotika. (Nikdy jsem nezkoušel, mám Radius v rámci AD). WiFi bych taky moc nedramatizoval. Vcelku hojně používané Ubiquity to podporují, a jestli je k dispozici PC, tak kontrolér se dá provozovat velmi jednoduše v rámci existujícího Linuxu.

Proto mi to právě celkově přijde jako jednodušší, než vymýšlet opičárny, postupně řešit jeden problém za druhým a na konci stejně neexistuje možnost, že by to fungovalo dostatečně zabezpečeně.

Stran: 1 ... 32 33 [34] 35 36 ... 206