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.
Vystup z postconf je VELKEJ! Snad 20-30 stran textu, jestli ne jeste vice. To sem mam vsechno dat? Aby se nekdo nestezoval, ze tady spamuju...Stačí sem dát ten jeden řádek s myorigin. Např.:
postconf | grep myorigin
každopádně nemá smysl se o tom bavit, protože problém to stejně neřeší. To samé s D-linkem.Vzhledem k tomu, že ISP ten problém nechce vyřešit, bavíme se teď o tom, jak to udělat, aby to pro h4kuna fungovalo alespoň doma. Což je primární způsob využití. Holt budou muset myslet na to, že sousedé se k nim nedostanou a případné soubory pro ně vystavovat jinde.
Ale je to marny, je to marny, je to marny...Výstup postconf je tedy jaký?
Vede to pak k domnění, že root s ssh klíčem je bezpečný, také není (nešifrovaný klíč v home složce je čitelný skoro i pro internetové stránky).To je nesmysl. Bezpečnost je vždy skládačka a bezpečné musí být všechny díly. Pokud si někdo myslí, že když nastaví přihlášení na SSH klíčem, zabezpečil tím vše včetně domu a auta, nic mu nepomůže.
Notifikace, pravidelné sledování, nástroje jako fail2ban či pokročilejší mohou nevýhodu hesla smazat.Ne, nic z uvedeného nevýhodu hesla smazat nemůže. Protože heslo je možné hádat distribuovaně a také ze stejného místa, odkud se přihlašuje i správce.
Je to až s podivem, ale třeba v některých bankách se setkávám pouze s přihlašováním na roota a pouze s doménovým heslem, protože věci jako cyberark, Microsoft AD a nulová podpora ssh klíče při SSO.Na tom, že je někde přihlášení jen na roota, není nic s podivem. A to přihlašování doménovým heslem k SSH v bankách – předpokládám, že ten SSH není jen tak vystrčený do internetu, aby se k němu mohl připojovat kdokoli. Pokud je ten server v chráněné síti a jakmile detekujete pokusy hádat hesla, můžete zasáhnout přímo proti zdroji (protože je ve vaší správě), je situace úplně jiná – tohle může smazat nevýhodu hesel.
2. si můžete nastavit sám, 3. zasahuje do správy vaší sítě.Řeč je o routeru ISP, který je umístěn u klienta a je předávacím místem sítě. Tento router je ve správě ISP, takže vaše body neplatí. A na D-Linku h4kuna takhle NAT nastavit nejde (alespoň podle manuálu) – umí jen port forwarding z WAN portu.
Ještě mě napadlo, zda by to nešlo řešit např. stížností na ČTÚ na nefunkční spojení či filtrování provozu, protože jestliže si platíte službu s veřejnou IPv4, musejí být schopni se na ni připojit i vaši sousedi, jinak je to vada.Obávám se, že ta veřejná IPv4 adresa je spíš poskytována na dobré slovo a že takováhle stížnost by vedla jen k ukončení této služby.
Možná by bylo dobré, kdyby lidé, co doporučují zákaz roota, současně uvedli scénáře nějakých útoků, které to může odvrátit. Já vím o jednom, CVE-2008-0166. Jak moc je to relevantní dnes (jako že se objeví podobná chyba) nedokážu posoudit, IMHO trochu jo. Ale teda roota nezakazuju.Zároveň je ale potřeba na druhou misku vah dát to, že se pak dotyčný bude neustále přihlašovat na roota. Buď bude mít povolené su na roota bez hesla, nebo bude heslo kopírovat ze správce hesel, nebo bude dokonce heslo psát ručně.
Pokud by těch NAT serverů bylo více, tak to ničemu ohledně haipin NATu nevadí.Pokud by to byl třeba nějaký bezestavový NAT, nemusí vůbec hairpin podporovat.
A pokud tento nástroj neumí hairpin NAT "naklikat", tak nehodlají bádat a prát se s ním, jak to tam ručně donastavit. :-(No právě.
zakazat prihlaseni roota je naprosty zakladAno, stejně jako vynucení pravidelné změny hesla nebo používání fail2ban. Všechno to má jedno společné – bezpečnost to nezvyšuje spíš naopak, ale objevuje se to mezi radami často. Protože to radí ti lidé, kterých je nejvíce – tedy ti, kteří problému nerozum, jenom si někde něco přečetli a tak to opakují. Lidé, kteří problematice rozumí, nic z toho neradí – protože vědí, že je to hloupost.
Hairpin_NAT můžeme nastavit případně u Vás na routeru, ale nelze naHairpin NAT na routeru u vás by pomohl ve vaší domácí síti – prostě byste si veškerý provoz na tu veřejnou IP adresu NAToval u sebe, tím pádem by se do sítě ISP nedostal a ISP na tom nemá co zkazit. Samozřejmě to ale nebude fungovat sousedům.
našich NAT severech.
Pokud nemám/nemohu mít přihlášení jen klíčem, tak zakázat přihlášení pro uživatele root je podle mě důležitý bod. Když kouknu na mou statistiku fail2ban tak cca 300 pokusů denně zkouší právě root a vedle toho pár dalších jmen. Fail2ban mám s Whitelistem abych si neblokl domácí spojeníPokud nemáte přihlášení jen klíčem, změňte to. Pokud nemůžete mít přihlášení jen klíčem, vyřešte důvod, proč to nemůžete mít, a změňte to. Zákaz přihlášení na roota nic neřeší, akorát to odvádí pozornost správce od toho skutečného problému (kterým je povolené přihlášení heslem).. A pokud by se povedlo bloknout se někde z venku, tak mám vždy možnost použít admin konzoli od poskytovatele VPS.
email skutečného odesílatele nepřepsal, ale byla k němu v nějakém zvláštním firmátu přidána emailová adresa, z které se to přeposílalo spolu s vloženým stringem “srs”. To ale na “koncovém” serveru rozbíjelo filtryTakže se přepisovala adresa odesílatele v e-mailu (hlavička From). Jak jsem psal, řešením tohoto problému je přepisovat jenom obálkového odesílatele, ne odesílateel v e-mailu (hlavičku From). Měnit hlavičku From je pro SPF zbytečné, SPF adresu odesílatele v e-mailu neřeší, řeší jen obálkového odesílatele. Samozřejmě se nedá vyloučit, že s tím někde nebude problém – správci poštovních serverů si dnes často stanovují svoje vlastní pravidla, a běda jak jim někdo nevyhoví.
Vy pane Jirsáku máte SRS nasazené?Já v současné době naštěstí neprovozuju poštovní server.
Jak jste ješte psal o dalších technikách, které rozbíjejí přeposílání, mohl by jste být víc konkrétní prosím?Provozovatelé poštovních serverů pod záminkou boje proti spamu nastavují nejrůznější pravidla s odůvodněním, že „regulérní e-maily tohle splňují“. Porovnávají adresy odesílatele v obálce a v -emailu, porovnávají to se jménem, kterým se ohlásil poštovní klient, s doménou, na kterou směruje reverzní záznam k IP adrese, s MX záznamem pro doménu. Ty kontroly jsou víceméně náhodné a jediné spolehlivé řešení je být GMail nebo někdo jiný velký, kdo je na whitelistu takového provozovatele. U přeposílání máte tu výhodu, že množina cílových serverů je omezená, takže můžete zjistit, že je mezi nimi někdo problematický, a to pak řešit individuálně.
Taky mám VPS a taky řeším omezení přístupu, na jedné VPSce mám Fail2ban a logy jsou hodně dlouhý (mám nastaveno že po 5 pokusu dám ban na hodinu). Na nové VPS mám nastaveno povolení SSH pouze z domácí IP adresy a je to jednodušší. Jen potřebuješ veřejnou adresu která se ti nemění a pak VPNku domu aby ses na server dostal i když jsi někde na cestách. Anebo si vytvoř VPNku na server a až přes vpnku jdi do SSH. A to co píše kolega tj. místo hesla příhlašování klíčem je také dobrá varianta. A určitě nezapomeň zakázat přihlašování uživatele root přes SSH. Pokud půjdeš do VPN tak doporučuju použít Wireguard (velice jednouchá konfigurace oproti OpenVPN).Nakonfigurovat přihlašování klíčem a zakázat přihlašování heslem je to nejdůležitější – to je potřeba vyřešit na prvním místě. Fail2ban nebo povolení jen určitých IP adres je dvousečná zbraň, snadno tak můžete odříznout sám sebe. Pro mne je to už za hranou, kdy nevýhody převažují nad výhodami. Zakázat přihlašování roota přes SSH nedává vůbec žádný smysl, pokud je na daném serveru jediný správce. Pokud je na serveru více správců, jde jen o to, zda chcete konkrétního uživatele logovat na základě klíče použitého pro přihlášení nebo na základě toho, přes jakého uživatele se přihlásil.
Pokud budou DNS záznamy kdekoli jinde, než primární záznamy u Forpsi (tj. na vašem routeru, na DNS serveru ISP), nebudou podepsané – tudíž ten, kdo dostane příslušnou odpověď a validuje DNSSEC, tu adresu nepřeloží. I kdybyste nechal na té doméně vypnout DNSSEC a ty záznamy byly na DNS serveru ISP, může někdo z klientů ISP používat jiné DNS servery a jemu se to pak stále bude překládat na tu vaši veřejnou IPv4 adresu (tj. nedostane se na váš server). Pokud by se to mělo hackovat na úrovni DNS, je to (vypnutí DNSSEC u Forpsi pro vaši doménu matejckovi.eu a statický záznam v DNS resolveru ISP) asi nejkompletnější „řešení“. Ale není to skutečné řešení, pořád jsou tam díry a v některých případech to fungovat nebude.CitaceNastavení DNS záznamu na našem DNS serveru a vytvoření statických
záznamů na našem zařízení u Vás, kdy pak musíte své zařízení nastavit
jako bridge
Pořád nevím zda je schopen zajistit fungování DNSSEC? A pokud by to fungovalo, tak tohle řešení je asi taky ok? Že na jeho dnsce bude záznam kam směrovat doménu v interní síti?
Ať se fakt naučí udělat ten hairpin NAT na své NAT bráně a vyřeší to jedním vrzem por X dalších. :-)Přesně tak. Než řešit DNS na svém serveru, statické záznamy na Mikrotiku u vás, konfigurace hairpin NATu je jednoduchá věc na jednom místě. Používá to tak kde kdo, takže je to ověřené a funkční. Bude dál veřejné IPv4 adresy řešit na jednom místě, může to tak nastavit pro všechny zákazníky, kteří mají veřejnou IPv4 adresu, a bude to fungovat spolehlivě pro všechny jeho zákazníky bez ohledu na to, jak používají DNS. Podle mne je to v této situaci nejjednodušší řešení a zároveň řešení s nejlepším poměrem cena/výkon.
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.