Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: xsouku04 09. 10. 2024, 14:15:42
-
Na serverech používám whitelist ip adress pro přihlášení na ssh a třeba k mailu, ale co O2 koupilo nej.cz, častěji mění ip adresy. Běžně to poskytovatelé internetu často nemění, ale vypadá to, že v O2 jsou prasáci.
Tedy ručně upravovat firewall na všech strojích se není moc praktické. Výrazné zlepšení by bylo, kdyby šlo nftables použít doména, ale vývojáři nftables nějak opět nedomysleli a přímo to nejde (jako by to nikdo nikdy nepotřeboval).
Nyní to řeším includem části nft konfiguračního souboru do hlavního nftables.conf, kde jsou definované všechny ip adresy v podobě proměnných. Tedy změny jsou na jednom místě, jednodušší a celé je to přehlednější, protože podle názvu proměnné je jasné co to je, ale pořád to není moc dobré.
Potřebuji to hlavně jako zadní vrátka, když by chcípl i server s wireguardem, abych se mohl někam přihlásit.
Jaké jsou možnosti jak to řešit? Něco jako metoda knock, knock, která mi na chvíli otevře port a útočník o tom mechanizmu neví?
-
myslíš to takto? na serveru, který řešíš, máš vpn a ten firewall. Ale mění se adresy klientů, odkud se připojují?
Na okraj: k čemu by byla aby měli doménu, když se stejně mění adresa?
A nebo se ti mění IP adresa na tom serveru? Tam ale vůbec zmiňovat vlastní IP serveru není potřeba. Nebo to máš nějak složitějc, s forwardováním?
nebo se nějak servery připojují mezi sebou? Ashodou okolností všem, nebo části jich se mění ta ip adresa, co o2 koupil nej.? a mezi sebou mají vzájemnáý whitelist? potom by stačilo mít je sesíťované přes ten WG a používat interní IP mezi sebou? (ale tomu rozumím, že wg stejně používáš a chceš pojistku )
-
... ale vývojáři nftables nějak opět nedomysleli ...
Tusi ty vubec co ten firewall dela? Jak bys tam asi tak chtel davat dns nazvy? A jak casto by ten firewal mell overovat, jakou to zrovna ma adresu? Kazdou sekundu? Jednou za rok?
-
myslíš to takto? na serveru, který řešíš, máš vpn a ten firewall. Ale mění se adresy klientů, odkud se připojují?
Na okraj: k čemu by byla aby měli doménu, když se stejně mění adresa?
A nebo se ti mění IP adresa na tom serveru? Tam ale vůbec zmiňovat vlastní IP serveru není potřeba. Nebo to máš nějak složitějc, s forwardováním?
nebo se nějak servery připojují mezi sebou? Ashodou okolností všem, nebo části jich se mění ta ip adresa, co o2 koupil nej.? a mezi sebou mají vzájemnáý whitelist? potom by stačilo mít je sesíťované přes ten WG a používat interní IP mezi sebou? (ale tomu rozumím, že wg stejně používáš a chceš pojistku )
Fyzických serverů 8 virtuálních třeba 30. Každý má firewall a otevřený přístup jen s whitelistovaných ip adres. Pokud su jinde, použiji wireguard. Wireguard je jeden virtuální server. Kterej ale může mít výpadek, pak by se tam nemohl připojit, abych to opravil. Vzájemný whitelisting mám, tam se mi ip adresy nemění.
-
... ale vývojáři nftables nějak opět nedomysleli ...
Tusi ty vubec co ten firewall dela? Jak bys tam asi tak chtel davat dns nazvy? A jak casto by ten firewal mell overovat, jakou to zrovna ma adresu? Kazdou sekundu? Jednou za rok?
Mě by stačilo, aby se DNS použil jen při startu nebo reloadu firewallu. Bohužel ale ani tohle nftables neumožňují bez nějakých ne zrovna vhodných přídavků. Všude se musí cpát ip adresy, které ale špatně pamatují a mohou se měnit.
Reloadovat to na důležitých serverech jednou vždy brzy ráno by nebyl žádný problém. Aktualizace DNS by šla také automatizovat to už jsem řešil kdysi dávno. O2 mění adresu vždy v noci a ráno už by to zase fungovalo.
-
Tusi ty vubec co ten firewall dela? Jak bys tam asi tak chtel davat dns nazvy?
Prekvapive existuji firewally, kde lze do pravidel davat DNS nazvy. Namatkou jen ty, se kterymi mam zkusenost: Fortigate, Cisco ASA, Juniper SRX.
A jak casto by ten firewal mell overovat, jakou to zrovna ma adresu? Kazdou sekundu? Jednou za rok?
Prekvapive k tomu existuje u kazdeho vendora dokumentace, ktera vam na tyto otazky odpovi...
-
Tusi ty vubec co ten firewall dela? Jak bys tam asi tak chtel davat dns nazvy?
Prekvapive existuji firewally, kde lze do pravidel davat DNS nazvy. Namatkou jen ty, se kterymi mam zkusenost: Fortigate, Cisco ASA, Juniper SRX.
A jak casto by ten firewal mell overovat, jakou to zrovna ma adresu? Kazdou sekundu? Jednou za rok?
Prekvapive k tomu existuje u kazdeho vendora dokumentace, ktera vam na tyto otazky odpovi...
Že to existuje vím, proto se divím, že nftables to neumí. Jako by to dělali lidé, co firewally moc nepoužívají. I když už co pamotuji, tak firewall na linuxu se už třikrát měnil, nejmodernější jen nftables. I freebsd je na tom lépe a to to třikřát nepředělávali.
Domény může být lepší používat už jen proto, že pak v těch pravidlech dá lépe vyznat. A když se změní, stačí reload.
-
Jako nouzovka jak se dostat na server by mohlo být port knocking.
https://goteleport.com/blog/ssh-port-knocking/
Ale je to zesložitění a potencionální snížení bezpečnosti, takže je lepší se bez toho obejít.
-
V tomhle popsaném případě mi implementace firewallu s používáním FQDN (tuplem ještě pro hosty z nějaké DynIP služby) nepřijde úplně dobrý nápad.
Teď úplně nejde jen o to, že to nftables (jako víceméně low-level filtrační mechanismus) nepodporuje. Ale i na produktech, které to přímo podporují, a při použitích kde to opravdu může výrazně zjednodušit obsluhu (typově přístupy z různých CDNek), to může mít spousty konsekvencí. Obecně se DNS překlad může stát velmi kritickou závislostí pro chod toho FW, měly by se ozkoušet všechny fallback varianty, jak se filtr chová při nedostupném nebo pomalu odpovídacím DNS, jaký to má případně vliv na prvotní spojení, jak se chová vzhledem k cachování a životnosti těch záznamů.. jestli to nebude problematické při velkém množství zpětných překladů s krátkým TTL atp.
Což neznamená, že to nejde, jen to nemusí být vždy ideální, nebo opodstatněné řešení pro nějaké obecné jednotlivé servery a virtuály s veřejnými adresami (vs např. zabezpečení něajké firmy, centra atp.).
Ale abych se vrátil k tomu, co jste psal. Pokud máte veřejnou dynamickou adresu, jste prostě normální road-warrior a podle mě je rozumná cesta jen to, co už používáte - nějaká forma zabezpečeného připojení na jump host.
Pokud se obáváte o dostupnost, zařiďte si jednoduše druhý. Osobně mám pro tyhle situace vždy druhý, záložní přístup, ideálně u jiného provozovatele na jiné síti.
Postačí na to jakákoliv nejslabší VPSka, je to otázka do 100,- měsíčně, případně zkusit i nějaký free tier (u Oraclu to šlo, nevím teď, jestli ještě přidělují veřejné IPv4 adresy). Výhoda pak je, že vám ten záložní jump host bude fungovat odkudkoli, ne jen z domova.
A stran toho O2, nevím co je nej.cz, ale mám doma VDSL a rovnou jsem si připlatil za veřejnou adresu. Ano, bylo by fajn to mít rovnou jako to bývalo před lety, když byly adresy za hubičku, a něco to stojí (jeden oběd). Nicméně nakonec jsem to prostě vzal jako další nástroj k práci. Krom statické adresy to hlavně řeší přímý přístup přes IPv4 bez CGNATu.
-
BTW, jak se nftables chová při aktualizaci tabulky pravidel?
V jednom projektu mám úkol, kdy bych potřeboval průběžně měnit seznam asi 500-900 whitelistovaných IP adres.
Cca co vteřinu.
V principu mám jak kompletní seznam IP, tak i to, co se má přidat a odebrat.
Ale jak se k tomu postavit?
Jde o to, aby se to necukalo/nepřerušoval se tok dat navázaných spojení, aby aktualizace pravidel co vteřinu nedělala paseku.
Jak na to jít správně? Že bych si to zkusil. ::)
Díky! ;)
-
Co kdyz nftables neni firewall? Co kdyz nftables je "modern Linux kernel packet classification framework" ? Blby, co?
-
BTW, jak se nftables chová při aktualizaci tabulky pravidel?
V jednom projektu mám úkol, kdy bych potřeboval průběžně měnit seznam asi 500-900 whitelistovaných IP adres.
Cca co vteřinu.
V principu mám jak kompletní seznam IP, tak i to, co se má přidat a odebrat.
Ale jak se k tomu postavit?
Jde o to, aby se to necukalo/nepřerušoval se tok dat navázaných spojení, aby aktualizace pravidel co vteřinu nedělala paseku.
Berte mě spíš s rezervou, reálně spíš používám hotové nadstavby nad nftables, jako firewalld nebo filtruji někde před servery. Ale kdybych měl řešit něco podobného, tak bych se na to snažil využít pojmenované sety, případně mapy (vmaps) v nftables. K nim by pak byla přiřazena pravidla, která bych neměnil. Tzn. programem na manipulaci bych jen přidával nebo odebíral z těch setů.. (add element, delete element).
Počítám, že při takhle časté manupulaci by program běžel pořád.. Po startu bych si vylistoval aktuální obsah toho setu z nftables a uložil do nějakého pole, seznamu v programu, pak bych si získal seznam adres z nějakého externího zdroje, porovnal a udělal nějaké dva další seznamy adres na přidání a odebrání elementů.
Ty bych nacpal do nftables a pokud by to proběhlo bez chyby, zaktualizoval bych si také ten vnitřní seznam s aktuálním stavem. Pak bych čekal až se případně změní ty externí adresy.. (nevím nějaký polling, nebo asynchornně) a jen bych to celé zopakoval. S tím, že už bych ten aktuální stav nemusel vytahovat, protože by byl v tom seznamu s aktuálním stavem.
Mělo by to jít implementovat třeba v Pythonu, kde je modul python-nftables, co používá třeba FirewallD. V podstatě je to wrapper okolo libnftables. Příkazy jsou víceméně stejné jako u nft, akorát se musí zabalit do JSON struktury.. podobně i výstupy z příkazu to vrací jako JSON.
Ale to je jen takový výkop, jak bych to zkusil sám. Možná zjistíte, že to zpracování je tak rychlé, že ty optimalizace s nějakými rozdílovými daty nemají smysl a můžete to sypat celé. Já jen vetšinou raději počítám s nějakou minimální zátěží a tím, že když mi někdo řekne, bude toho x, tak rovnou přemýšlím co se stane, až toho bude 5x :)
Jinak to jak jste se ptal, co jsem si kdysi zkoušel (klasicky seznam zdroj. adres, pravidlo na nová příchozí spojení), navázaná spojení a related by měla zůstat běžet i když odeberete hosta, další navázaní spojení už neprojde (klasifikace paketu nevyhoví). Jinak aktualizace rulesetu v nftables můžou být s optionem atomické (jako option -f u nft), tzn. není tam ten problém, že by třeba komplikovaný ruleset, který se nějakou dobu zpracovává (bambilion řádků) nechal filtr v mezistavu, kdy tam jsou chvíli nová i stará pravidla zároveň. Nemusí se explicitně dávat flush (který to typ. nechá neprůchozí, než se tam naládují nová pravidla).
-
Takhle nějak jsem si to představoval.
Děkuji, vyzkouším.
-
Podle mě vymýšlíš kravinu. To co potřebuješ je pevná veřejná IP adresa. O2 ji prodává za cca. 200 Kč.
-
Podle mě vymýšlíš kravinu. To co potřebuješ je pevná veřejná IP adresa. O2 ji prodává za cca. 200 Kč.
To bych ale musel kupovat každému zaměstnanci, kterému se zblázní poskytovatel internetu aby se dostal na servery. V principu není také spravidlivé připlácet O2 za to, že se nechová slušně a bezdůvodně mění ip adresu. Nej.cz je kabelovka a já můžu být vůbec rád, že jim to obstojně funguje, roky s tím měli problémy a nevěděli si rady. Takže chtít něco od takových lidí je risk.
Jednu veřejnou pevnou adresu mimo lokalitu máme, přes kterou by se dalo připojovat. Ale je to zase komplikace v případě potíží, což se mi moc nelíbí.
-
No, a co mít prostě záložní VPN server? Když nefunguje server A, použiješ B. Ostatně, jak u těch svých aktualizací firewallu vůbec chceš zjistit, jaké adresy máš povolit? To máte nějaké klikátko, kam si zaměstnanec zadá "dneska mám takovouhle IP"? Nebo povinná instalace dyndns klienta?
-
To bych ale musel kupovat každému zaměstnanci, kterému se zblázní poskytovatel internetu aby se dostal na servery. V principu není také spravidlivé připlácet O2 za to, že se nechová slušně a bezdůvodně mění ip adresu. Nej.cz je kabelovka a já můžu být vůbec rád, že jim to obstojně funguje, roky s tím měli problémy a nevěděli si rady. Takže chtít něco od takových lidí je risk.
Jednu veřejnou pevnou adresu mimo lokalitu máme, přes kterou by se dalo připojovat. Ale je to zase komplikace v případě potíží, což se mi moc nelíbí.
Pardon, to jsem vás blbě pochopil, já nejdřív myslel, že to myslíte jako přístup pro vás jako administrátora na nějaké servery, co spravujete.
Uff, jestli je to pro ostatní zaměstnance, a vy někde manuálně upravujete seznamy jejich IP adres (u kterých reálně nevíte, jak dlouho budou držet, kdo se z nich připojuje atp.), aby mohli přistupovat k různým službám z firmy, tak se mi spíš zdá, že se nezbláznil operátor :).
Ta cesta je už několikrát zmíněná.. udělejte si prostě dvě VPN brány (tomu, čemu já jsem říkal jumphost). Pokud první brána nebude dostupná, připojí se na druhou.
To je asi nejjednodušší řešení, pokud třeba nezaintegrujete nějakou placenou službu typu Tailscale nebo nevymyslíte vlastní řešení, co si failover může řešit transparentně pro uživatele.
Pro vaše zaměstnance, kolegy se nic nemění, v tuhle chvíli přistupovali počítám napřímo, a když se to "podělalo" nahodili ten Wireguard.. (nebo naopak). Tady budou mít variantu a) první VPN server, variantu b) druhý VPN server.
Budete mít pak jen dva body, odkud to můžete monitorovat přístupy na služby, selektivně je povolovat atp.
Přímý přístup s whitelisty je z mnoha ohledů nevhodný, tím že ty klientské sítě nemáte vůbec pod kontrolou, nevíte kdo bude na těch jejich domácích WiFinách. Podobně jestli klienti nemají ty IPv4 pevné a můžou se změnit (byť nutně ne často), tak až do momentu, kdy to zjistíte a manuálně přenastavíte, tak vám nějaký random člověk (co zrovna dostal adresu po vašem kolegovi) může projíždět ty služby, zkoušet relayovat na poštovní server atp. Podobně právě i lidé za CGNATem, kdy víc klientů dynamicky sdílí veřejné adresy.
To je podle mě úplná magořina.
To že se u některých operátorů relativně často mění adresa vychází z principu toho CGNATu. Céčkový IPv4 blok na volném trhu dneska stojí tisíce EUR. Můžeme si o tom myslet co chceme, nadávat, řešit nasazování IPv6, ale je to prostě realita. Pokud má malý operátor řekněme stovky, tisíce klientů a moc neroste jejich počet, tak se třeba v pohodě vejdou do rozsahů, které už mají léta koupené. Jiná situace může nastat pro velké operátory kdy jich můžou mít v pohodě i miliony lidí s mobilními daty a tohle víceméně neudržitelné.
Proto se z IPv4 stává dneska prémiová služba, jak u velkých ISP, cloud providerů atp. V normálním připojení dostanete třeba dostanete IPv6 přímo a IPv4 přes další překlad (CGNAT). Nefunguje to tak jako předtím, že vám nějaký DHCP server přidělí rovnou veřejnou adresu, ale dostanete privátní adresu, je tam další NAT v síti operátora a víc lidí může sdílet jednu veřejnou adresu.. (počítá se s tím, že typicky nepotřebujete komunikovat naráz ze všech odchozích 65535 TCP portů, takže se to rozdělí třeba na čtvrtky).
-
No, a co mít prostě záložní VPN server? Když nefunguje server A, použiješ B. Ostatně, jak u těch svých aktualizací firewallu vůbec chceš zjistit, jaké adresy máš povolit? To máte nějaké klikátko, kam si zaměstnanec zadá "dneska mám takovouhle IP"? Nebo povinná instalace dyndns klienta?
Zaměstnanci pracují téměř vždy ze stejného místa - z domu. Ip adresa se může změnit, ale je to třeba jednou za několik let. Když výjimečně pracují od jinud, použijí wireguard. Ale doma wireguard používat nesmí, protože kdyby se ním něco stalo, je třeba se umět hlásit napřímo. Respektive wireguard se používá v tomto případě jen k dosažení neveřejných ip adres.
Veřejnou ip adresu si zjistí např. na ip adrese www.mojeip.cz a tu nám pošle. On nemá ani svoji vlastní veřejnou, tu sdílí. Ip adresa není jediná ochrana, jsou samozřejmě ještě další hesla, ale proti tomu aby někdo skenoval internet to stačí.
Kdyby se ip adresa měnila častěji, udělat si dynamicDNS není problém. Horší je nepodpora nftables dns.
Teď to řeším tak, že na každém serveru mám includovaný soubor s definicemi priměnných pro nftables.
Např.
define Petr_doma = 85.93.12.29
A pak se v hlavním skriptu mohu odvolávat opakovaně na jména a ne nic neříkající se měnící se ip adresy, které by se pak musely měnit na více místech. Definovat proměnné pomocí domén by se někdy hodilo, ale hold to nejde.
A pak stačí aktualizovat jen ten soubor s definicemi, který dokonce může sdílet i více virtuálů a reloadnout všechny firewaly.
-
Ale doma wireguard používat nesmí, protože kdyby se ním něco stalo, je třeba se umět hlásit napřímo.
A to proč jako proboha? :o
Chápal bych, kdyby šlo o zero trust network, že se generická VPN postupně zařezává, protože "důvěryhodná síť" je tak trochu nesmysl, a nahrazuje se to client-to-server tunelama, nejspíš i s těžkým monitorováním všeho na každém individuálním zařízení (zmíněný Tailscale, nebo třeba Banyan). Ale tam pak taky vůbec není potřeba řešit nějaké takovéhle firewall věci, tam je důvěryhodný proxyhost(s), přes který všechno jde.
Ale takhle přímo vystrkovat kritické servery ven (kde zřejmě nejde počkat tu hodinu dvě, než jako admin pořešíš výpadek VPN), byť s omezením na IP, to mi zavání hrozícím průšvihem. Chyba v konfiguraci, co to omylem otevře víc, než měla, nesmazaná IP, kterou dostane nějaký zavirovaný uživatel... Navíc je to složitější, pořád se musí něco přenastavovávat. Můžeš nám vysvětlit, jaký přínos tohle řešení má, oproti dvěma nebo třem nezávislým VPN serverům?
-
Aneb stav CZ firmy co zamrzla s bezpecnosti nekdy v roce 2000 :D
Kdyz se dneska uz opousti i VPNky, dekuju fakt tenhle thread pobavil.
Presne jak pise Zopper.
https://www.zscaler.com/resources/security-terms-glossary/what-is-zero-trust-network-access
-
...
Vis vubec co je NAT (CGNAT).
Uvedomujes si, ze jsi daval roky do whitelistu IP adresy, pod jednou muze byt treba 128 zarizeni?
Co to je za firmu? :) Dobry uz vim, ty jsi leaknul svoji firmu v jednom postu.
-
Ale doma wireguard používat nesmí, protože kdyby se ním něco stalo, je třeba se umět hlásit napřímo.
A to proč jako proboha? :o
Chápal bych, kdyby šlo o zero trust network, že se generická VPN postupně zařezává, protože "důvěryhodná síť" je tak trochu nesmysl, a nahrazuje se to client-to-server tunelama, nejspíš i s těžkým monitorováním všeho na každém individuálním zařízení (zmíněný Tailscale, nebo třeba Banyan). Ale tam pak taky vůbec není potřeba řešit nějaké takovéhle firewall věci, tam je důvěryhodný proxyhost(s), přes který všechno jde.
Ale takhle přímo vystrkovat kritické servery ven (kde zřejmě nejde počkat tu hodinu dvě, než jako admin pořešíš výpadek VPN), byť s omezením na IP, to mi zavání hrozícím průšvihem. Chyba v konfiguraci, co to omylem otevře víc, než měla, nesmazaná IP, kterou dostane nějaký zavirovaný uživatel... Navíc je to složitější, pořád se musí něco přenastavovávat. Můžeš nám vysvětlit, jaký přínos tohle řešení má, oproti dvěma nebo třem nezávislým VPN serverům?
Protože kdyby wireguard nefungoval, tak by jste to opravovali jak, když se tam ani nepřihlásíte? Ano je možné mít wireguardy dva a přepínat, ale i když je to méně pravděpdobné, tak by nemuseli jet oba.
-
...
Vis vubec co je NAT (CGNAT).
Uvedomujes si, ze jsi daval roky do whitelistu IP adresy, pod jednou muze byt treba 128 zarizeni?
Co to je za firmu? :) Dobry uz vim, ty jsi leaknul svoji firmu v jednom postu.
Samozřejmě že vím. Firewall není jediná ochrana, ale je zde hlavně proto, aby služby nešlo hromadně skenovat a napadat z libovolné části světa.
-
Protože kdyby wireguard nefungoval, tak by jste to opravovali jak, když se tam ani nepřihlásíte? Ano je možné mít wireguardy dva a přepínat, ale i když je to méně pravděpdobné, tak by nemuseli jet oba.
Vyřešil bych to jednoduše, použil ten druhý server. A pokud ten server padá několikrát za týden, tak je něco dost špatně, a není to princip VPN. Nebo si jako admin pořídíš pevnou ip sám pro sebe, tu si dáš do whitelistu, aby ses teda dostal přímo, a když ten VPN server padne, tak ho opravíš. Ale nebudeš muset dělat poloautomatické vrtání děr do bezpečnosti kvůli ostatním zaměstnancům.
Apropo, co stane, když padne třeba ten firewall, třeba protože v těch pravidlech, co se pořád mění, jak se lidem mění IP, se stala chyba a zablokovala všechno?
Samozřejmě že vím. Firewall není jediná ochrana, ale je zde hlavně proto, aby služby nešlo hromadně skenovat a napadat z libovolné části světa.
Tak si tam prostě hoď IP bloky třeba z https://ipinfo.io/AS5610, omezíš to tím jen na zákazníky O2 a nemusíš pravidla upravovat pořád dokola.
-
Protože kdyby wireguard nefungoval, tak by jste to opravovali jak, když se tam ani nepřihlásíte? Ano je možné mít wireguardy dva a přepínat, ale i když je to méně pravděpdobné, tak by nemuseli jet oba.
Vyřešil bych to jednoduše, použil ten druhý server. A pokud ten server padá několikrát za týden, tak je něco dost špatně, a není to princip VPN. Nebo si jako admin pořídíš pevnou ip sám pro sebe, tu si dáš do whitelistu, aby ses teda dostal přímo, a když ten VPN server padne, tak ho opravíš. Ale nebudeš muset dělat poloautomatické vrtání děr do bezpečnosti kvůli ostatním zaměstnancům.
Apropo, co stane, když padne třeba ten firewall, třeba protože v těch pravidlech, co se pořád mění, jak se lidem mění IP, se stala chyba a zablokovala všechno?
Přesně tak, prostě separátní administrátorský přístup, klidně i jinou technologií nebo přes vlastní pevnou IP. Ale hlavně úplně netuším, z čeho je takový strach ohledně stability nebo dočasné nedostupnosti. Typický downtime na těch VPN bránách je zpravidla reboot po nějaké pravidelné aktualizaci v naplánovaném časovém okně (které by tam mělo být stejně domluvené na občasnou údržbu). Pokud je to někde virtualizované, nebo se použije třeba kexec na rychlé zavedení nového jádra, tak se konektivita obnoví řádově do 30 sekund a zrovna u Wireguardu se nemusí na klientech dělat vůbec nic dalšího.
Ale musím říct, cca 38 serverů, nebo kolik, přístupných přímo z internetu, při každé změně veřejné IP klienta (respektive jejich sítí schovaných za tou IP) distribuce nějakých include souborů a následný reload ACL pravidel ve všech použitých lokálních firewallech.. To zní jako noční můra a musím říct, že jsem se dozvěděl lecos nového, tohle by mě snad ani nenapadlo.. :o
-
Tak jsem to vyřešil pomoci Sets.
V /etc/nftables.conf v tabulce filter nadefinuji prázdný set
set ssh_acc_set {
type ipv4_addr
}
Přidám pak pravidlo:
ip saddr @ssh_acc_set counter accept # dynamické ip adesy
A do cronu pak pro každou doménu, co může změnit ip adresu dám tohle:
00 7 * * * root nft add element filter ssh_acc_set { $(dig +short subdomena.domena.cz) comment \"subdomena.domena.cz $(date +\%F_\%H:\%M:\%S)\" }
Tam je zajímavé, že znak % se v cronu musí escepovat, protože má zvláštní význam. ip adresu získávám pomocí příkazu
dig +short .
Že úloha crontabu proběhla mohu ověřit pomocí
journalctl -u cron| tail -n 50
Každou novou ip adresu to pak samo přidá do whitelistu včetně poznámky o jakou se jedná doménu a kdy se tak stalo. Pokud už tam ip adresa je (většina případů) tak se nestane nic. Zůstane původní záznam.
nft list set filter ssh_acc_set
table ip filter {
set ssh_acc_set {
type ipv4_addr
elements = { 49.176.124.121 comment "subdomena.domena.cz 2024-10-16_09:56:01" }
}
}
Množinu mohu promazat příkazem flush, ale pak je nutné přidat aktuální ip adresy.
nft flush set filter ssh_acc_set
Na to jak nftables přesložitělé, třetí předělávka, to bohužel nic moc neumí a nepracuje se s tím dobře.
Jako dynamický dns používám http://freedns.afraid.org/ . Je zadarmo a možnosti jak aktualizovat ip adresu jsou pravdu bohaté. Např. stačí načíst speciální url s hashem z cronu.
Lézt na všechny servery jen pomocí dvou jiných strojů nebo tunelů je zbytečně omezující, protože když jsou problémy, nemusí fungovat kde co. Takže tohle řešení celkem ujde.
-
Jen jestli to správně chápu,
tak v momentě kdy se z jakéhokoliv důvodu neaktualizují záznamy klienta u nějaké bezvadné free DNS služby, třeba kvůli její odstávce, přetížení atp. (počítám, že free varianta je bez jakéhokoliv závazku dostupnosti) nebo když nebude dočasně dostupná DNSka pro překlad na tom serveru, tak se klient po změně IP nepřipojí.
Taky je super, že ta DNS služba má na free tieru minimální hodinové TTL, takže když by tam někde u serveru byl třeba kešovací resolver (což občas dává docela smysl), tak vám může taky hodinu vracet starou IP (to se dá ale využít k tomu, že se může jít klient třeba projít, než vyprší všechny timeouty DNSce a cronu).
Nakonec to, že se v tom setu budou štosovat staré IP adresy, které může zrecyklovat kdokoliv (s tím CGNATem) a dáte jim přístup k těm službám, než je ručně vymažete a obnovíte celý set, už je jen taková třešnička na dortu.
Jako jo, je to docela vymakané, to nemohu říct. 8)
Taková VPN brána je oproti tomuhle systému problematická, protože - co kdyby se s ní něco stalo.
-
Lézt na všechny servery jen pomocí dvou jiných strojů nebo tunelů je zbytečně omezující, protože když jsou problémy, nemusí fungovat kde co. Takže tohle řešení celkem ujde.
Takhle evidentne nevhodne ovahovane moznosti selhani se jen tak nevidi :)
Jen pro zajimavost: proc si myslis, ze VPN, ktera potrebuje pouze funkcni DNS+UDP nemusi fungovat spise nez DNS+zdarma dynDNS kdesi za kopecky+TCP?
-
Lézt na všechny servery jen pomocí dvou jiných strojů nebo tunelů je zbytečně omezující, protože když jsou problémy, nemusí fungovat kde co. Takže tohle řešení celkem ujde.
Takhle evidentne nevhodne ovahovane moznosti selhani se jen tak nevidi :)
Jen pro zajimavost: proc si myslis, ze VPN, ktera potrebuje pouze funkcni DNS+UDP nemusi fungovat spise nez DNS+zdarma dynDNS kdesi za kopecky+TCP?
Protože ta vpn běží na stejných strojích s kterými může být právě problém. Běží na virtuálu, není to žádné speciální dedikované zařízení. Jinak stačí, když bude fungovat alespoň jedna možnost. Tedy vpn nebo přímá výjimka. A samozřejmě těch adres z kterých se dá přistupovat je vícero a ne všechny musí být přes dynDNS. Bohužel se někdy mohou nečekaně změnit i veřejné adresy, které by se měnit nikdy neměly. Např. u vodafone (UPC).
-
Proc myslis, ze selhani stroje s wireguardem je pravdepodobnejsi nez selhani stroje s SSH?
-
Jen jestli to správně chápu,
tak v momentě kdy se z jakéhokoliv důvodu neaktualizují záznamy klienta u nějaké bezvadné free DNS služby, třeba kvůli její odstávce, přetížení atp. (počítám, že free varianta je bez jakéhokoliv závazku dostupnosti) nebo když nebude dočasně dostupná DNSka pro překlad na tom serveru, tak se klient po změně IP nepřipojí.
Taky je super, že ta DNS služba má na free tieru minimální hodinové TTL, takže když by tam někde u serveru byl třeba kešovací resolver (což občas dává docela smysl), tak vám může taky hodinu vracet starou IP (to se dá ale využít k tomu, že se může jít klient třeba projít, než vyprší všechny timeouty DNSce a cronu).
Nakonec to, že se v tom setu budou štosovat staré IP adresy, které může zrecyklovat kdokoliv (s tím CGNATem) a dáte jim přístup k těm službám, než je ručně vymažete a obnovíte celý set, už je jen taková třešnička na dortu.
Jako jo, je to docela vymakané, to nemohu říct. 8)
Taková VPN brána je oproti tomuhle systému problematická, protože - co kdyby se s ní něco stalo.
Opakuji, že VPN mám, tohle je záložní řešení, když by vpn spadla spolu se serverem. VPN běží jako obyčejný virtuál takže se ho výpadek může týkat stejně jako jakékoli jiné služby. Stačí když bude fungovat tohle nebo VPN, nebo nějaká další ip adresa která se nemění. Pokud jeden fyzický stroj spadne, potřebuji pak nahodit virtuály co tam běžely na jiném stroji a tam se potřebuji co nejrychleji a nejednodušeji dostat. Dynamickým whitelistem vpn možnost neruším ani neruším možnost udělat to z ip adres, které se nemění.
Že by teoreticky mohlo hádat heslo několik set náhodných BFU lidí z ČR mne nijak netrápí. Jsou tam stejně klíče, přihlášení heslem zakázané. Firewall je tam hlavně proto, aby do něj nebušili útočníci co náhodně skenují internet a zkouší otravovat.
-
Proc myslis, ze selhani stroje s wireguardem je pravdepodobnejsi nez selhani stroje s SSH?
SSH mají všechny stroje, jak fyzické tak virtuální. Pravděpodobnost selhání virtuálu s wireguardem je stejná jako jakéholi jiného. Ale pro ten případ potřebuji wireguard či jiné virtuály spustit na jiném fyzickém stroji. A proto se tam musím umět nějak dostat i jinak než přes ten wireguard.
-
Pokud bych nedokazal zajistit stabilitu prostredi pro beh virtualek, sel bych teda radeji do varianty dve ruzne VPNky na dvou ruznych derivatech unixu, ale ok, kazdy sveho stesti strojvudcem :)
-
Pokud bych nedokazal zajistit stabilitu prostredi pro beh virtualek, sel bych teda radeji do varianty dve ruzne VPNky na dvou ruznych derivatech unixu, ale ok, kazdy sveho stesti strojvudcem :)
Ale přece spoléhat se na to, že to nikdy nespadne, nelze nikdy. Bez ohledu na to jaký máte hardware i software.
A přestože má serverovna záložní baterie i agregát, je nutné počítat s tím, že tak možná jednou za deset let nepůjde elektřina. A jednou za 10 let nepůjde internet. Nebo při DOS budou dostupné jen některé ip adresy a stroje.
A až proud opět půjde, může se stát, že správně nenaskočí více jak jeden stroj. Ve stejnou dobu. To všechno se už již stalo a je třeba mít co nejlepší možnosti se tam dostat a minimalizovat škodu.
Takže předpoklad, že bude určitě stačit jeden záložní VPN mi také moc nesedí. Krom toho by bylo třeba připojování přes VPN střídat, aby se nefunkčnost projevila dříve než hlavní VPN bude nedostupné. No a já prostě jako druhou možnost volím něco jiného než VPN, což je prostě větší diverzifikace a může někdy hodit.
-
Ale přece spoléhat se na to, že to nikdy nespadne, nelze nikdy. Bez ohledu na to jaký máte hardware i software.
Obecna univerzalni pravda bez vztahu k nasemu pripadu.
Ale rozbetlujme to trochu:
A přestože má serverovna záložní baterie i agregát, je nutné počítat s tím, že tak možná jednou za deset let nepůjde elektřina.
Jak ti pak pomuze filtr pro ip adresy na SSH?
A jednou za 10 let nepůjde internet.
Jak ti pak pomuze filtr pro ip adresy na SSH?
Nebo při DOS budou dostupné jen některé ip adresy a stroje.
Proc si myslis, ze zrovna SSH v techto pripadech bude na tom s dostupnosti lepe? (zvlaste, kdyz za nekterymi povolenymi adresami muze byt skryto i hodne ruznych lidi a i organizaci)
A až proud opět půjde, může se stát, že správně nenaskočí více jak jeden stroj. Ve stejnou dobu.
Jak ti pak pomuze filtr pro ip adresy na SSH?
To všechno se už již stalo a je třeba mít co nejlepší možnosti se tam dostat a minimalizovat škodu.
Takže předpoklad, že bude určitě stačit jeden záložní VPN mi také moc nesedí.
To jen proto, ze sis to jeste poradne nepromyslel :)
Krom toho by bylo třeba připojování přes VPN střídat, aby se nefunkčnost projevila dříve než hlavní VPN bude nedostupné.
Kdezto u SSH ne?
No a já prostě jako druhou možnost volím něco jiného než VPN, což je prostě větší diverzifikace a může někdy hodit.
Nekdy se muze hodit prohledavat po ceste vsechny popelnice, presto bych se do takove situace nechtel dostat :)
A ted ja:
VPN ti negeneruje praci s obskurni spravou ip adres.
Fungovani VPN neovlivnuje nedostupnost nejake zdarma sluzby kdesi v tramtarii.
-
Ale přece spoléhat se na to, že to nikdy nespadne, nelze nikdy. Bez ohledu na to jaký máte hardware i software.
Obecna univerzalni pravda bez vztahu k nasemu pripadu.
Ale rozbetlujme to trochu:
A přestože má serverovna záložní baterie i agregát, je nutné počítat s tím, že tak možná jednou za deset let nepůjde elektřina.
Jak ti pak pomuze filtr pro ip adresy na SSH?
A jednou za 10 let nepůjde internet.
Jak ti pak pomuze filtr pro ip adresy na SSH?
Nebo při DOS budou dostupné jen některé ip adresy a stroje.
Proc si myslis, ze zrovna SSH v techto pripadech bude na tom s dostupnosti lepe? (zvlaste, kdyz za nekterymi povolenymi adresami muze byt skryto i hodne ruznych lidi a i organizaci)
A až proud opět půjde, může se stát, že správně nenaskočí více jak jeden stroj. Ve stejnou dobu.
Jak ti pak pomuze filtr pro ip adresy na SSH?
To všechno se už již stalo a je třeba mít co nejlepší možnosti se tam dostat a minimalizovat škodu.
Takže předpoklad, že bude určitě stačit jeden záložní VPN mi také moc nesedí.
To jen proto, ze sis to jeste poradne nepromyslel :)
Krom toho by bylo třeba připojování přes VPN střídat, aby se nefunkčnost projevila dříve než hlavní VPN bude nedostupné.
Kdezto u SSH ne?
No a já prostě jako druhou možnost volím něco jiného než VPN, což je prostě větší diverzifikace a může někdy hodit.
Nekdy se muze hodit prohledavat po ceste vsechny popelnice, presto bych se do takove situace nechtel dostat :)
A ted ja:
VPN ti negeneruje praci s obskurni spravou ip adres.
Fungovani VPN neovlivnuje nedostupnost nejake zdarma sluzby kdesi v tramtarii.
Když vypnou elektřinu, je slušná šance, že některý stroj nenabootuje. Pokud by to byly dva a oba s VPN, nedostanu se tam.
U SSH jsi na tom podstatně lépe, protože nejsem limitovaný funkčností dvou konkrétních fyzických a virtuálních strojů.
Nerozumím té posedlostí VPN. Udržovat a aktualizovat další VPN virtuální stroj s vlastní ip adesou a routovací tabulkou a podobně je rozhodně více práce, než přidat vždy stejných několik řádek do /etc/nftable.conf a jeden do cronu.
Na všech strojích to stejné, bez další obsluhy a údržby. Bez dalších aktualizací. Není to pěkné řešení z toho důvodu, že nftables je obskurdní a špatně dokumentovaný, ale výsledek není až tak špatný.
Nemusí, to tedy tak úzkostlivě hlídat jako fungování dalšího jediného záložního VPN, protože těch strojů bude více a stačí mi, když se připojím k jednomu fungujícímu.
Je pravda, že kdyby byl druhý VPN v jiné lokalitě, bylo by to lepší. Ale na stejném místě je lepší se tomu vyhnout.
Krom toho si mohu velmi snadno v nastavení wireguardu udělat tak, aby u ip adressy, kam chci mít možnést se připojovat napřímo se routování přes wireguard nepužilo. Tohle mi bude spolehlivě hlídat funkčnost. Oproti tomu používat dva různé wireguardy současně nebo je náhodně střídat, mi tak pěkné nepřijde.
http://freedns.afraid.org/ funguje už 23 let a má i placené služby, kde má více jak dvojnásobek platících zákazníků, než které požadovali, aby mohli služby zdarma zachovat. Myslím že je spousta rizikovějších placených služeb.
Jo a v případě dostupnosti jen části veřejných ip address nebo DOS útoku na část strojů je VPN také o dost horší možnost.
Že nejde v serverovně internet jak by měl, není úplně vzácný případ. Už jsem to zažil vícekrát.
-
Ja to vzdavam. Povazovat VPNku za neco, ceho se musim bat a chtit pro ni zvlastni virtualku, to je trochu moc.
-
Zaplatit dvě VPS, každou u jiného posktovatele. Z obou VPS zřídit VPN do firmy. Ve firmě zakázat přístupy na služby z jiných ip adres, než jsou ty dvě VPS. Klienti/zaměstnanci budou mít VPN na obě dvě VPS, použijí jednu z nich. Jinak se do práce nepřipojí. Když spadne jedna VPS, druhá poběží. Administrátor si pořídí nějaký další přístup. Nazdar bazar.
-
V korporátech jsou asi moderní ty VPN, protože to jinak jejich myšlení zjevně nedovoluje a hůře by se hlídalo, že v tom firewallu nezůstanou díry. Ale my nejsme korporát a tak si to můžeme dělat i jinak a bez dalšího speciálního hardware navíc.
Je to nasazené a vypadá to OK.
Že si nějaký korporatec myslí, že to není nejlepší, mne nijak netrápí. Možná se to bude hodit někomu dalšímu.
-
A nejhorsi ze vseho jsou kotporatci... Vsude vlezou a desne rychle se mnozej.
Az (a pokud) ti jednou dojde, cos tady vykladal, budes se za sebe stydet :)
-
Opakuji, že VPN mám, tohle je záložní řešení, když by vpn spadla spolu se serverem. VPN běží jako obyčejný virtuál takže se ho výpadek může týkat stejně jako jakékoli jiné služby. Stačí když bude fungovat tohle nebo VPN, nebo nějaká další ip adresa která se nemění. Pokud jeden fyzický stroj spadne, potřebuji pak nahodit virtuály co tam běžely na jiném stroji a tam se potřebuji co nejrychleji a nejednodušeji dostat. Dynamickým whitelistem vpn možnost neruším ani neruším možnost udělat to z ip adres, které se nemění.
Že by teoreticky mohlo hádat heslo několik set náhodných BFU lidí z ČR mne nijak netrápí. Jsou tam stejně klíče, přihlášení heslem zakázané. Firewall je tam hlavně proto, aby do něj nebušili útočníci co náhodně skenují internet a zkouší otravovat.
Nejdřív píšete, že to je i pro kolegy a ti mají zakázáno se z domova připojovat přes WG a používají to jen z venku, z toho mi to vycházelo spíš jako primární řešení.
Teď to zas vypadá, že jste si vymyslel tuhle konstrukci s dynamickou DNSkou, abyste si pro sebe (počítám jako primární admin) ušetřil za pevnou adresu bez CGNATu, která se prostě z mnoha důvodů beztak hodí, a tohle má být tedy záloha pro váš SSH přístup.
K tomu nahazujete za mě dost nesmyslné scénáře, kterými si chcete obhájit systém konfigurace s mnoha veřejně přístupnými servery s lokálními firewally a hromadou generovaných pravidel místo standardní klientské VPN brány (případně druhé záložní s jednoduše replikovanou, ale identickou konfigurací). Což opravdu nechápu, nebo resp. chápu, protože jsem podobné věci dělal v 90. letech (pod rootem běžící lokální generátory incoming pravidel pro IPFW ve freebsd, které jsem psal v perlu, opičárny na dial up a tak.), ale dnes mi opravdu přijde, že se tohle poměřně přežilo.
S redund. bránami bych měl jediné body, kde můžu filtrovat, sledovat provoz, logovat přístupy, upravovat konfiguraci, přidávat a odebírat uživatele, revokovat atp. Když se bude něco opravdu nehezkého dít, můžu to prostě bloknout najednou, bez toho abych lezl po dvaceti lokálních fw.
Funguje to pak odevšud stejně, ať už se někdo připojuje z domova, nebo třeba z mobilu v Albánii. Je to také i mnohem lepší pokud by tam pak mimo SSH byly i služby, které nejsou samy o sobě tak zabezpečené. Ten VPN tunel je totiž bez dalšího přičinění uživatele typicky jen virt. interface na jeho počítači, oproti whitelistování jeho veřejné adresy, kdy zpřístupníte služby nejen jeho počítači, ale celé jeho LAN za NATem.
Jakmile tam jsou ještě po normální uživatele nějaké jiné přímé přístupy mimo VPNku (co kdyby náhodou), tak tohle celé trochu padá.
I kdybych pak chtěl nějakou další, svou administrační zálohu, nezávislou na těch zmíněných bránách (resp. třeba hypervizorech, nebo co tam máte), tak jsem přesvědčený, že tam bude dalších x možností jak to řešit čistěji a líp i s dynamickou veřejnou adresou odkud bych se případně připojoval, a zároveň i tak aby mi to fungovalo odevšud, ne jen z domova.
Ale beru, už jste se rozhodl, jste s tím takhle evidentně spokojený. Já jsem své napsal, svým způsobem i proto, že kdyby někdo ten dyndns whitelist chtěl replikovat, aby si to případně mohl zasadil i do nějakého jiného kontextu.
-
> Potřebuji to hlavně jako zadní vrátka, když by chcípl i server s wireguardem, abych se mohl někam přihlásit.
no, tohle se řeší tak, že máš nějaký malý routřík s vytočeným wireguardem někam na bastion host / jumpserver , kde máš přístup a je třeba i na normálním internetu. Nejsem dealer mikrotiku, ale od routerosv7 tam wireguard je, a funguje (pro podobné i serióznější účely) dobře.
-
Žádný další mikrotik nechci. Za každou další krabici bych musel platit a prostě nechci další krám. Já nepoužívám mikrotik ale openwrt a mikrotik se nehodlám učit. Openwrt samozřejmě umí wireguard také, pravděpodobně dříve než mikrotik, ale nehci další krám, který by navíc mohl být potenciálně děravý. Vlastní router před servery nepotřebuji, byla by to další věc, co se může polámat a pak by nešlo nic.
Všechny ty "vzácné nepravděpodobné scénáře" co popisuji, se již několikrát za posledních 20 let staly.
Kolegům se ip adresy zatím nesmyslně nemění, neb jejich poskytovatele zatím nekoupilo O2. Možná se časem i to O2 ustálí, jen teď mají možná období, že do toho v noci rýpou. Jsou to fušeři. Musel jsem napsat skript, který ráno zkontroluje, jestli jde internet a pokud ne tak restartuje modem.
Pokud by se poskytovatelé zaměstnanců také zbláznili, budu muset také pro každého přidat další jeden řádek do cronu a routování jejich wireguardu změnit. Ostatně i nyní wireguard mají, jen přes něj routují jen neveřejné ip adersy. Na veřejné jdou na přímo, aby testovali "záložní způsob".
-
BTW, jak se nftables chová při aktualizaci tabulky pravidel?
V jednom projektu mám úkol, kdy bych potřeboval průběžně měnit seznam asi 500-900 whitelistovaných IP adres.
Cca co vteřinu.
V principu mám jak kompletní seznam IP, tak i to, co se má přidat a odebrat.
Ale jak se k tomu postavit?
Jde o to, aby se to necukalo/nepřerušoval se tok dat navázaných spojení, aby aktualizace pravidel co vteřinu nedělala paseku.
Jak na to jít správně? Že bych si to zkusil. ::)
Díky! ;)
Předpokládám, že se sice seznam může měnit co vteřinu, ale ve skutečnost změna v jedné vteřině budou obvykle jen desítky adres. Ne výměna všech adres z blacklistu. Tedy mělo by jít přidávat a odebírat po jedný ze setu.