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.
Tam zbývá ta odvěká otázka, v čem se liší ta naše neuronová síť v mozku od umělé a proč jedna kreativní být může a ta druhá ne (a jak se vlastně kreativita měří)...
Po aplikování následujících pravidel v Nftables jsem bez konektivity z localhostuKód: [Vybrat]add table ip Restrictive
add chain ip Restrictive Incoming { type filter hook input priority 0; policy drop; }
add chain ip Restrictive Redirect { type filter hook forward priority 0; policy drop; }
add chain ip Restrictive Outgoing { type filter hook output priority 0; policy accept; }
add rule ip Restrictive Incoming iifname lo counter accept
add rule ip Restrictive Incoming oifname lo counter accept
Čekal bych, že pravidlo
add chain ip Restrictive Outgoing { type filter hook output priority 0; policy accept; }
povolí všechna odchozí spojení, ale na internet se nedostanu.
Pokud pravidloKód: [Vybrat]add rule ip Restrictive Incoming iifname lan33 counter accept
add rule ip Restrictive Incoming oifname lan33 counter accept
povolím i pro lan tak to sice funguje, ale všichni se z lan dostanou na všechny služby.
Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.To automatizovane riesenie nie je nutne znova vyvijat. Mozete pouzit napr. certbot. Pripadne ine riesenie, ktorych je internet uz plny. Alebo mozete ist starou cestou a vynalozit radovo viac zdrojov na certifikat od nejakej CA.
Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.Vypinat 80 port nie je najstastnejsi napad, je dobre tam dat aspom redirect na port 443. K tomu do aplikacie siahat nemusite, da sa to osetrit uz na urovni http serveru.
Dalsie riesenie je skryt aplikaciu za vlastnu lokalnu proxinu(traefik, nginx, haproxy..), takze aplikacia sa odbremeni od https a dvoch spojeni, co je super, lenze zase ta proxy treaz musi routovat 99.99999% dat na prazdno, a zrat hw, len kvoli LE ktore pride raz tri mesiace. Ale zase to riesi sama uz, takze aplikacia samotna sa o nic starat nemusi. Ale zase na produkcii to prinasa dalsiu starost - namiesto jednej binarky a jej konfiguracie je vyzadovana dalsia binarka pre tuto proxinu a konfiguracia pre nu a dodatocne znalosti pre spavnu konfiguraciu a prevadzku.
Tretia moznost je pouzit externu proxinu typu CloudFlare ktora kompletne odbremeni od riesenia HTTPS za cenu ze prevadzka zo serveru na cloudflare je nesifrovana(prakticky mitm) a teda cloudflare ma plny pristup k datam uzivatelov a taktiez pod kontrolou komplet cele DNS. A ked sa rozhodne ze sa im nepacite, tak vas vypnu a mate mozno aj niekolko-hodinovy vypadok. Takze taktiez nie idealna situacia.Preco by mal byt nesifrovany? Ked sa snazite ohnut sluzbu ktora je urcena k niecomu inemu, tak musite ratat aj s rovnakom na ohybak...
Preto ma zaujima co dnes fici ako najpouzivanejsi postup?Aplikacia o https nic vediet nemusi. K tomuto je urceny http server. Location http serveru je smerovana na adresar kde si certbot vytvara challenge. Aplikacia o tejto location nema mat ani len tusenie. Ak pouzivate hosting tretej strany, tak je samozrejme ze toto nastavenie dostanete default. Ak si server spravujete sam, tak by ste to mal zvladnut, je to jedna z tych trivialnejsich zalezitosti ohladne bezpecnej spravy serveru.
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
basicConstraints=critical,CA:TRUE
keyUsage=critical,keyCertSign, cRLSign
keyUsage=critical,digitalSignature, keyEncipherment
Že se pro vytvoření self-signed certifikátu nepoužije žádná CA jste někde četl nebo si to jen myslíte? Kdo tedy vytvořil kořenový (a tudíž i self-signed) certifikát ISRG Root X1, který používá Let's Encrypt?
Certifikační autorita je entita, která vystavuje certifikáty. Když si generuji vlastní certifikáty, tak jsem sám sobě certifikační autoritou a je úplně jedno, jestli pro koncová zařízení generuji self-signed certifikáty a nebo mám nějaký kořenový certifikátm, kterým pak teprve podepisuji CSR od koncových zařízení.
Nebo co podle vás znamená "vlastní CA"?
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout example.key -out example.crt -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.net"
Radí mi, že mám pro spojení mezi proxy a tiskárnou použít self-signed.
Co jsem zatim zkousel, tak editace samotneho souboru Postgresu nijak nevadi. Kdyz do nej neco pripojim, nevadi mu to vubec a vse funguje bez problemu dal a pokud ho komplet zevnitr smazu nebo prepisu, tak jen vraci prazdne vysledky a dokonce nehaze chybu ani pri insertu, ackoliv nasledny select insertovany radek neobsahuje.Postgres sa snazi co najviac dat drzat v pamati, do suborov nezapisuje zmany okamzite, s vynimkou write ahead logu. WAL potom prechadza wal writer a ked ma cas alebo prekroci nastavene limity tak tie zmeny zapise fyzicky na disk. Ak medzi tym vypadne napajanie a ne je k dispozicii napajanie, tak zmeny vo WAL co nie su na disku sa pri starte zapisu. Cize ak mu chcete menit subory, s cielom testu ci to rozdycha, tak najskor tu db stopnite, skuste nieco prepisat a znova nastartujte.
V logu se rovnez zadna chyba neobjevi.
Narazil jsem na to, ze od verze 14 je k dispozici pg_checksums a predpokladal jsem, ze po jeho zapnuti tohle nejak osetri. V zakladu se tak ale nestale, vse puvodne popsane funguje stejnym zpusobem dal.
A to se vám při téhle kariéře podařilo úplně minout to, jak už čtvrt století funguje web? To vás nikdy nenapadlo, jak může webhosting obsloužit násobně víc doménových jmen, než má IP adres?
O SPF vůbec nebyla řeč.
Ne, virtual host se používá kvůli nedostatku IPv4 adres. S výkonem serveru to nijak nesouvisí. Víc webů na jednom serveru byste klidně mohl mít s více IP adresami na server – dříve, když bylo IPv4 adres dost, se to tak dělalo. Nebo naopak můžete mít doménu nasměrovanou na nějaký reverzní proxy server, který dělá třeba rozvažování zátěže. Takže na provoz webu třeba potřebujete 4 servery, ale jsou schované za proxy serverem s jednou IP adresou. A za tím proxy serverem mohou být schované i jiné weby.
Prosím vás, nepište o věcech, o kterých vůbec nic nevíte. Podívejte se na webhostingy typu Wedos nebo CDN jako Cloudflare a uvědomte si, kolik by museli mít IPv4 adres, kdyby pro každé doménové jméno měli samostatnou IP adresu.
Kanonické jméno v PTR dáte snadno – server má jedno kanonické jméno, třeba server123.example.com. Na to vede PTR záznam. A pak mohou existovat stovky dalších A záznamů, které vedou na stejnou IP adresu, a k nim žádné reverzní záznamy neexistují, nemusí existovat a je to tak v pořádku, protože to nejsou kanonická jména.
To je váš problém, že používáte ne moc chytrou správu DNS záznamů.Ja nerad vymyslam blbiny, radsej hram na bezpecnost. Cim menej duplicit, tym menej priestoru na chyby.
Takový typ záznamu ovšem v DNS neexistuje. Už jsem vám to psal, že nevíte, co CNAME znamená.
Redundance je jeden z důvodů, proč rozvažovat zátěž.Redundancia je sposob ako nahradit pripadny vypadok. Nic ine.
V tom vašem příkladu je www.example.org alias pro kanonické jméno example.org. Zkuste teď ten váš příklad upravit tak, abyste pro domény example.org a www.example.org mohl přijímat e-maily (s pomocí MX záznamů s prioritami). A pak zkuste přidat TXT záznam pro example.org a jiný pro www.example.org (třeba kvůli ověření vlastnictví domény).Preco by som to robil? Za MX zaznam alias nepatri, tam patri common name.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.