Příspěvky

736

Sítě / Re:Mikrotik - NAT Log

« kdy: 31. 03. 2020, 17:21:39 »

To se dá jednoduše vysvětlit.
Provádíte dnat - tedy zaměňujete cílovou adresu za novou.
Teprve poté, co tu adresu změníte, tak se může router rozhodnout, na jaký interface vlastně packet pošle.

Proto při logování dnatu nemůžete vidět odchozí interface, protože v tu chvíli není ještě vyhodnocený.

Na googlu najdete schémata, jak teče packet a kdy nastává routing decision - hledejte obrázky "packet flow in linux".

737

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 31. 03. 2020, 14:19:21 »

1) povedzme ze neverim, ze je Tomcat (ktory bezi u mna na lokale/devel stanici) bezpecny.
2) vytvorim uzivatela ferko a nastavim iptables tak ako popisujem hore
3) ked spustim tomcat resp. catalina.sh (tusim tak sa ten script vola, nechce sa mi to hladat/overovat) pod userom ferko, tak mozem s tomcatom komunikovat z localhostu ale Tomcat ziadnu moju java classu neposle do sveta.

suhlas? za tomcat si mozno dosadit mysqld/svnserve/keepassx/python whatever......

Mám pocit, že si nerozumíme. Navrhované řešení řeší NOVÁ spojení ze serveru do světa. Nevyřeší se tím to, aby se zablokovaly přístupy zvenčí (to se zase řeší jinak, ale to jsme tu nediskutovali). Možná si pletete pojem "odeslat data" (nějaký script aktivně něco odešle) a "odpovědět na požadavek" (což je nejběžnější činnost, co dělá http server).

Každopádně, pokud jde o Tomcata, toho bych nikdy nespouštěl na přímo, ale vždy zřetězený až za reverzní proxy. Jako reverzní proxy může sloužit nginx, haproxy, apache. Na proxy pak můžete nejlépe ovládat kdo smí přistupovat k službě.

(Zbytek naší diskuse výše se týká situace "odeslat data").

738

Server / Re:Aky mail+kalendar+kontakt server vybrat?

« kdy: 31. 03. 2020, 13:29:13 »

Skusim upresnit otazku:
Ma niekto odporucanie k instalacii mail serveru i s rozhranim (aspon zakladne veci, nech je mozna naklikat)?

IceWarp má grafickou konfigurační konzoli pro Windows.
Nicméně mám poslední asi dva roky pocit, že na tom serveru už prd vyvíjejí. Funguje, ale budoucnost asi nemá. Hromada zákazníků utíká do cloudu.

739

Server / Re:Hypervisor - zmenšení svazku pro hosta

« kdy: 31. 03. 2020, 12:17:13 »

...
V praxi se to řeší odklonováním...

jó to se někomu pracuje, když má dostatek místa. Já už na hypervisoru pro tuto akci nemám

Nelenil jsem a ověřil jsem na vSphere 6.7 přidat místo, zpět už nejde odebrat ani přesto, že OS na to nesáhl.
Takže bez klonování to asi neuděláte.

740

Server / Re:Hypervisor - zmenšení svazku pro hosta

« kdy: 31. 03. 2020, 11:23:59 »

Nejsem si úplně jistý, teoreticky by to jít mělo / mohlo, pokud volné místo na konci OS trimuje.
V praxi se to řeší odklonováním, na virtualizaci je to bezpečné a hlavně velmi jednoduché řešení.

741

Sítě / Re:Reklamace WiFi routeru

« kdy: 31. 03. 2020, 09:33:03 »

A tohle nikdo u pravděpodobně domácího spotřebního routříku řešit nebude (tj. nikdo za to v této sféře nedá takové peníze navíc).

Přesně tak, tam jsem mířil. Profesionální routery a security appliance stojí desetitisíce + podobné částky i za podporu. Navíc u profi routerů je běžné, že mají pouze routovat, ne dělat firewall, nedej bože další služby. Od toho slouží různé security appliances, gateways apod. To je právě z praktických důvodů, aby bylo možno zajistit podporu.

U SOHO zařízení musí člověk brát, že i nejdražší Mikrotik stojí jen zlomek ceny profi routeru a security appliance a musí se smířit s tím, že nemá garantováno nic do budoucna. Může však vycházet z historie firmy a jak se k tomu doposud stavěla.

742

Sítě / Re:Reklamace WiFi routeru

« kdy: 31. 03. 2020, 02:55:21 »

U posuzování reklamace nejde o to, jestli je nefunkční dnes. Reklamace řeší vady výroby, a, ač se to nezdá, po právu se řeší to, jestli vada existovala v době koupě. V prvním půlroce existuje fikce odpovědnosti výrobce - má se za to, že vada, která se projevila 0-6 měsíců od koupě, byla už z výroby a prodejce by musel prokázat opak. V období 6-24 měsíců je břemeno na kupujícím. Ten musí prokázat, že vada existovala už při koupi (byť se projevila až později). Laicky se to zjednodušuje na to, že se zařízení nesmí porouchat, ale právě v případě aktualizací je už tento rozdíl viditelný.

Žádný zákon nepřikazuje výrobci zařízení aktualizovat. Jediné, co je ze zákona požadováno je, aby plnil přesně tu funkci, kterou měl plnit v době pořízení. Výrobce poměrně logicky nemůže nést odpovědnost za to, co přijde v budoucnu, i kdyby se to dalo aspoň z části předpokládat.

Pokud požadujete aktualizace po dobu několika let, lze najít takové výrobce, kteří to zaručují (a pak to musí dodržet). Jedná se především o dražší zařízení. Podporu lze obvykle dokoupit i na další období, dokud není produkt EoL.

Jestli hledáte levného výrobce, tak se musíte smířit s tím, že můžete akorát vycházet z dlouhodobé zkušenosti s výrobcem, ale že ani tak Vám to (většinou) negarantuje.

Ani samotný pojem "aktualizace" taky není dostatečný. Aktualizovat výrobce může 2x týdně i jednou za rok. Může aktualizovat bezpečnostní definice, nebo taky jen opravovat překlepy ve Web GUI. Aby byl takový slib naplnitelný, musí být jasně definováno, jaké vlastnosti si výrobek s aktualizacemi zachová a podle čeho se to bude měřit.

743

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:27:48 »

...že odborník už umí svojí diskrecí pokračovat v nastavení.

Tak tohle by možná stálo za vysvětlení.

Howto obvykle ukáží jak se řeší nějaká modelová situace. Např. jak zahodit packet, jak zjistit nevalidní TCP flagy, jak filtrovat podle uživatele. Jiné howto ukáže, jak nastavit PHP-FPM pooly pod různými uživateli. Jiné howto ukáže, jak nastavit proxy server. Jiné howto napoví, jak přes proxy server nastavit aktualizace systému. Další howto ukáže L7 filtrování na proxy serveru.

Profesionál se od laika liší tím, že umí nejprve specifikovat, co vlastně chce a v druhém kroku umí uvážit a syntetizovat poznatky z různých oblastí v jeden funkční celek.

Kvas se zeptal poměrně jednoduše na oblast, která je řešitelná velmi namáhavě a liší se situace od situace. Proto na to nejsou žádná howtos.

744

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:24:16 »

Rozumiem. Ale teraz mi ide o zabezpecenie len jednej aplikacie na desktope takze totoby asi mohlo stacit. samozrejme, keby to bolo  nejake php CMStak by bolo potrebne mat pod ferkom spusteny  apache/nginx + php.

Ale na destkopu je to to samé. Běží vám PHP pod uživatelem www-data a tím pádem to pravidlo se nevyhodnotí a projde to.

745

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 13:13:21 »

Ano, takto by to mohlo fungovat, ale z hlediska bezpečnosti je to tzv. "na vodě". Bezpečný postup je DROP ALL (pro všechny uživatele) a poté jedno po druhém povolovat. Nikdy nevíte, které spojení se skryje pod jiného uživatele. Např. odchozí pošta se skryje pod uživatele MTA (např. postfix).

Ze stejného důvodu musíte spustit i nginx/apache a php-fpm pod userem ferko, protože jinak se to skryje (nejčastěji) pod uživatele www-data.

746

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 12:47:09 »

co som googlil, tak by to malo fungovat nasledovne:
1) aplikaciu spustal len pod userom ABC
2) na firewalle zakazat outgoing pre usera ABC
stacia zabezpecit tieto 2 body pre "pocit bezpecia a istoty"? mate link na jednoduchy postup ako to nastavit? zatial som ziadny pre mna rozumny nenasiel.

Jednoduchý postup na to nemám, jsou to hodiny práce. Internetové návody toto vůbec neobsahují (ostatně stejně jako jakékoliv opravdu dobré postupy), předpokládá se, že odborník už umí svojí diskrecí pokračovat v nastavení.

Na to, abyste měl spojení od usera ABC, musíte apache/nginx i php-fpm spustit pod tímto userem - tj. ona nezávislá instance, o které píšu.

Asi vhodnější je na serveru zakázat celý outgoing a naopak povolovat jen uživatele a směry, které chcete umožnit. Jedině tak máte (jakš takš) jistotu, že jste neudělal chybu.

747

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 12:37:05 »

...

Velmi přesně popsáno. OSS CMS jsou dobrý nástroj na rychlý launch (potřebuju rychle dostat produkt ven a získat čas na pořádné stránky), nebo naopak na velmi silný vlastní vývoj (vytvořím si vlastní pluginy, šablony, nakoupím si profesionální pluginy s podporou atd.) a vlastní správu.

Reálně ale 99 % zadavatelů volí WordPress a spol. s představou, že je to cesta jak získat dokonalou funkcionalitu za nula korun a bez správy. Tam je každá rada drahá.

748

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 30. 03. 2020, 11:43:09 »

Co se týče OSS, musíte určitě z části věřit. Dobrým vodítkem jsou statistiky CVE společně s nějakou informací o používání. Nejlepší je hodně používaná aplikace s minimem bezpečnostních chyb ve statistikách. Není to samozřejmě záruka, že zrovna zítra se nenajde díra jako hrom, ale něco to vypovídá. Zrovna Joomla a hlavně WordPress dopadají katastrofálně. Navíc u nich jsou ještě další díry v pluginech a motivech, které do CVE základního produktu nespadnou.

Pokud chci postavit aplikaci a rozumně ji zabezpečit, pak:
1. Běží odděleně. Docker nepovažuji za bezpečný. Samostatná VPS je neekonomická. Mám rád FreeBSD jaily, to je takový kompromis mezi těmi dvěma.
2. Oprávnění musejí být segregovaná. Pokud apache / nginx / php-fpm běží pod uživatelem www-data a pod ním běží i další weby, nelze bezpečnost rozumně nastavit. => Spouštím nezávislou instanci webserveru a php, která běží pod oprávněními jednoho nezávislého uživatele.
3. Na firewallu nefiltruji jen provoz dovnitř, ale i provoz ven. Aplikace nemá co komunikovat ven ze serveru, když o tom nevím. (Tím se také značně omezí možnosti šíření (D)DoS a červů.
4. Aby aplikace mohla komunikovat jen tam, kam chci, nastavuji na serveru proxy server. Aplikace má povinnost komunikovat přes proxy, pokud potřebuje spojení směrem ven. Na firewallu mohu filtrovat jen L3, na úrovni IP adres, za kterou mohou být stovky služeb, např. celé cloudy, a ty IP adresy se čas od času mění, takže by bylo potřeba neustále reloadovat firewall. Na proxy serveru nastavím L7 filtr, obvykle na URI služby, kterou chci povolit.
5. Směrem dovnitř komunikaci proháním přes reverzní proxy, na které běží aplikační firewall. ModSecurity + pravidla, např. od Atomicu.
6. PHP má zásadně omezenou paměť (co nejméně, pár nižších megabajtů).
7. PHP script musí mít omezenou dobu běhu (např. 5 sekund). Cokoliv, co běží déle není na webu stejně použitelné (z hlediska UX) a otevírá to dveře útokům.
8. Administrace webů vyžadují vyšší limity (např. na přeškálování obrázků, pro složitější DB operace, upload souborů, ...). Administrace se musí oddělit na jiný virtuální server, běžící v jiné instanci včetně oddělené instance PHP.

Tím vším se posunete ke zvýšené bezpečnosti. Ano, je to v tu chvíli dost náročné na správu, ale jestli hledáte bezpečnost, tak toto je jedna z cest.

749

Vývoj / Re:NoSql document databaze

« kdy: 29. 03. 2020, 20:44:50 »

Ale měla, měla. Já jsem ochoten uznat, že nějaká specifika, neboli nějaké takové rozdíly jsou např. mezi db typu key/value vs. relační db vs. grafovou db, (případně relační vs. objektovou, tam má ta odlišnost i teoretický základ), ale i tak jsem to myslel trochu jinak.
Ve chvíli, kdy relační databáze umožní uložit libovolný dokument (json) do jednoho sloupce, tak v tom okamžiku se na ni můžu dívat jako implementaci dokumentové databáze, a v tomto ohledu jsou ekvivalentní v tom smyslu, že nemůžu říct, která je vhodnější, nebo není. Prostě jsou na tom stejně. Pochopitelně jedna implementace bude rychlejší v tom, jedna pomalejší v onom, ale jako koncept umí totéž. Ale proč bych kvůli změně měl přepisovat aplikaci?

Příklad - nejblíž té univerzálnosti má podle mě GraphQL, ne ORM, a jaká je tam databáze je pak jedno.

Uznávám, pokud nevyžadujete relační funkce, tak se to dá zuniverzálnit.
Neumím si představit situaci, kdy potřebujete ukládat dokument a zároveň nepotřebujete relační funkce, ale možné to je. Např. mít jedno spojení na relační databázi (a využívat specifické vlastnosti), a nezávislé spojení na získání dokumentu (a to může být univerzální).

Já jsem spíš (asi off topic) komentoval dnešní snahy o ORM, která databáze výkonově degraduje v podstatě na úroveň dBase nebo FoxPro (a dohání se to rostoucím výkonem hardware).

750

Vývoj / Re:NoSql document databaze

« kdy: 29. 03. 2020, 18:48:17 »

volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

Spravna odpoved.

Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?

no samozrejme :-)

Ne, neměla. Každá databáze má svá specifika, svůj vlastní dialekt a je jinak silná v jiných operacích.
Když použijete ORM nebo jiný způsob zuniverzálnění práce s daty, připravíte se o největší sílu databází.

Pokud děláte malou aplikaci s malými daty, stojí za to používat ORM a neřešit to.
Kdykoliv děláte něco většího, je to už koule u nohy a nikdy nic nevyladíte.