Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: aigor.net 08. 04. 2019, 11:06:23
-
Ahoj, předtím než mě odkážete na VPN, prosím o přečtení celého dotazu..
Jedná se o server ve firmě, který spravuji. Není vystaven na netu a ven žádné služby neposyktuje. Nicméně provider nám nabídl za symbolický poplatek veřejnou IP a líbí se mi myšlenka v případě potřeby se jednoduše připojit.
V celé jejich síti jde o jediný Linux server + Win stanice, jinam se tedy připojovat nepotřebuji. GUI samozřejmě není instalováno, zajímá mě pouze SSH na občasné servisní úkony a správu. Router mikrotik.
Moje představa je vystavit libovolný port s SSH serverem, přihlašování pouze klíčem.
Připojovat se budu jednak ze svého desktopu, nebo v nouzi na cesták i z tabletu, tzn. filtrování na IP nejde použít.
Jaká jsou rizika útoku? Nedostupnost SSH (ddos) není problém, vyřeší se to autem jako postaru. Naopak možné napadení (krádež/poškození firemních dat) by znamenalo hodně velký průšvih!
Pokud neuvažuju nějaké Zero-Day chyby v openssh a pravidelně aktualizovaný server, jaké má tohle řešení možné slabiny?
-
Mám to přesně takhle na všech serverech i routerech. Otevřené SSH do světa na standardním TCP portu 22, přihlašování pouze klíči. Pokud je systém aktualizovaný, nevidím v tom žádné bezpečnostní riziko. Hesla se hádat nedají, uživatelé mají přístup jen do svého adresáře pro SFTP.
-
Používám roky jen hesla, občas klice na desítkách virtualech a bez problémů. Pokusu o přihlášení samozřejmě miliarda ale na 13ti mistnejch heslech bez šance. Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.
-
Jak píšou ostatní, SSH nechat na standardním portu (někde blokují odchozí provoz podle portů, SSH tam obvykle potřebují pro sebe, takže se pak i z takové sítě dostanete na svůj server). Povolil bych přihlášení jenom klíčem, hádači hesel pak mají smůlu a podle mne je to i pohodlnější. Pokud byste přeci jen chtěl povolit přihlašování heslem, vyjmenujte uživatele, pro které to povolíte a u kterých si budete jistý, že mají dostatečně silné heslo. Ohlídejte si, ať máte aktuální verzi jádra a OpenSSH, abyste tam nepovolil nějaké staré protokoly nebo algoritmy, a ať na té veřejné IP adrese neposlouchají jiné programy, než to OpenSSH (a to ani po restartu – ať se vám programy pro naslouchání nepřipojují na 0.0.0.0). Klíče doporučuji použít různé pro každého klienta – když vám někdo ukradne tablet, pohodlně se na server přihlásíte z desktopu a tabletový klíč deaktivujete a nemusíte hned řešit jeho výměnu i na desktopu.
Pokud máte na těch stanicích s Windows uživatele, kteří klikají na kde co, jsou řádově větším rizikem pro firemní data, než ten OpenSSH server. U toho serveru hrozí to, že něco špatně nakonfigurujete, krádež přístupového klíče (dá se posílit zabezpečením klíče heslem – po dobu, co útočník louská heslo, máte čas na deaktivaci klíče) a zero-day v softwaru – to všechno jsou řádově menší rizika, než málo obezřetní uživatelé.
-
Díky za potvrzení myšlenky. Osobně už roky používám stejně jen klíče - jak už tady padlo, je to i pohodlnější.
S portem stejně budu muset udělat malou šarádu, protože i 22 někde mají bloknutou. Myšlenka je na mikrotiku otevřít 443 a tu NATovat 1:1 do 22 na server. Na TCP/80 bude zbytečně velký provoz.
A na Mikrotiku jsou samozřejmě servisní porty i služby bloknuté kromě SSH jen z místní sítě.
-
[...] Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.
no to je strasna ztrata casu :-D
ssh user@server -t 'sudo -i'
[...] Klíče doporučuji použít různé pro každého klienta – když vám někdo ukradne tablet, pohodlně se na server přihlásíte z desktopu a tabletový klíč deaktivujete a nemusíte hned řešit jeho výměnu i na desktopu. [...]
nebo stejnej klic s passphrase, na tabletu (predpokladam Android) pouzivat ConnectBot (https://f-droid.org/en/packages/org.connectbot/) v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...
-
Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.
zákaz přímého přihlášení roota má spíš význam v auditovatelnosti, tj. víš který konkrétní sysop co kdy udělal, a taky se lépe řeší oprávněných různých opů.
nebo stejnej klic s passphrase
nn, tady opravdu souhlas s kolegou, privátní klíč by mezi zařízeními vůbec neměl cestovat.
protože i 22 někde mají bloknutou.
Z takovýchto divných sítí bych se ven dostával spíš VPNkou a server bych nechal standardní.. Ale záleží na vkusu, bezpečnost to neovlivní.
-
Je ještě moderní port knocking ?
-
Je ještě moderní port knocking ?
https://cs.wikipedia.org/wiki/Security_through_obscurity
Nenapadá mě rozumný použití.
-
nebo stejnej klic s passphrase, na tabletu (predpokladam Android) pouzivat ConnectBot (https://f-droid.org/en/packages/org.connectbot/) v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...
Nikoli. Louskání hesla ke klíči může útočník dělat off-line, tedy může zkoušet hesla jak rychle chce a na jakém množství zařízení chce (resp. zaplatí). Heslo ke klíči tedy neslouží jako absolutní zabezpečení (typu „když mi ten tablet ukradnou, klidně ten klíč budu používat ještě za dva roky“), ale jenom vám dává čas příslušný klíč zablokovat. Rozumné heslo vám samozřejmě neposkytne pár sekund nebo minut, mělo by i odhodlaného útočníka zbrzdit minimálně na měsíce – bavíme se o bezpečnosti, takže je potřeba mít rezervu v řádech. I tak je lepší používat na každém klientovi jiný klíč, protože až k té ztrátě zařízení s klíčem dojde, nemusíte ve stresu všude vyměňovat klíče, ale prostě ten jeden klíč zablokujete (což samozřejmě předpokládá, že ty klíče máte pořádně označené a na serveru ten klíč snadno najdete). Postupy pro krizové situace by měly být co nejjednodušší – když vám někde ukradnou tablet, určitě budete řešit spoustu jiných věcí, než abyste se zabavoval generováním nových klíčů.
Ze začátku jsem se jakoby snažil mít zakazanyho roota a řešit všechno přes sudo, ale to je strašná ztráta času.
Chápu, že se někde sudo používá pro potřeby auditu kdo co dělal, i když mi to připadá trochu zvláštní postup. Ale pokud je někde sudo nakonfigurované tak, že se dá spustit shell pod rootem, a má to sloužit k většímu zabezpečení, je to podle mne kontraproduktivní. Víc bych se bál chybné konfigurace sudo nebo chyby v sudo než toho, že někdo něco omylem spustí pod rootem a tím napáchá škody. sudo bych dál používal k tomu, k čemu bylo původně určeno – tedy ke spuštění vybraných aplikací s vyššími oprávněními. Pokud to daná aplikace ještě vyžaduje a nedá se to řešit např. přes capabilities.
-
nebo stejnej klic s passphrase, na tabletu (predpokladam Android) pouzivat ConnectBot (https://f-droid.org/en/packages/org.connectbot/) v kterem pred pripojenim odemkne klic a po zavreni ConnectBoot je passhrase zapomenuta...
Nikoli. Louskání hesla ke klíči může útočník dělat off-line, tedy může zkoušet hesla jak rychle chce a na jakém množství zařízení chce (resp. zaplatí).
to je teorie, v praxi, kdyz pouzijes 20mistne passhrase s kombinaci male/velka pismena, cisla a specialni znaky, tak si zpocitej kolik milionu superpocitacu bys potreboval na rozlousknuti v radu let ;-)
-
to je teorie, v praxi, kdyz pouzijes 20mistne passhrase s kombinaci male/velka pismena, cisla a specialni znaky, tak si zpocitej kolik milionu superpocitacu bys potreboval na rozlousknuti v radu let ;-)
Já bych takové heslo v praxi na tabletu zadávat nechtěl. Nehledě na to, že bych příslušný klíč stejně v případě ztráty tabletu zablokoval, protože nechci myslet na to, že pokud by se třeba za půl roku našla díra ve způsobu, jak se s tím heslem nakládá, budu muset klíče vyměnit. Navíc nějak nevidím důvod, proč bych se měl bránit použití více klíčů – znamená to přidat jeden řádek do souboru s povolenými klíči.
-
Já bych takové heslo v praxi na tabletu zadávat nechtěl. Nehledě na to, že bych příslušný klíč stejně v případě ztráty tabletu zablokoval, protože nechci myslet na to, že pokud by se třeba za půl roku našla díra ve způsobu, jak se s tím heslem nakládá, budu muset klíče vyměnit. Navíc nějak nevidím důvod, proč bych se měl bránit použití více klíčů – znamená to přidat jeden řádek do souboru s povolenými klíči.
ja s takovym "heslem" zadavanem na telefonu problem nemam...
nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...
puvodne si psal ze pri ztrate tabletu clovek nemusi rychle resit vymeny klicu, ted pises (kdyz sem upozornil na moznost silne passphrase ktere potrebuje miliony superpocitacu k rozlousknuti v radu let) ze za pul roku muze byt nalezena dira...
jinak "tve" reseni ma take mouchu, kdyz mi ukradnou tablet a nebudu mit u sebe NB, nebo nekoho na telefonu, tak nemuzu na serveru zrusit ten ukradenej klic a s tvojim snadnym heslem mi ho nekdo rozlouskne driv nez se k NB dostanu ;-)
-
nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...
Možnost to je. Ale má ta možnost nějaké výhody?
puvodne si psal ze pri ztrate tabletu clovek nemusi rychle resit vymeny klicu, ted pises (kdyz sem upozornil na moznost silne passphrase ktere potrebuje miliony superpocitacu k rozlousknuti v radu let) ze za pul roku muze byt nalezena dira...
jinak "tve" reseni ma take mouchu, kdyz mi ukradnou tablet a nebudu mit u sebe NB, nebo nekoho na telefonu, tak nemuzu na serveru zrusit ten ukradenej klic a s tvojim snadnym heslem mi ho nekdo rozlouskne driv nez se k NB dostanu
Asi jste můj příspěvek nečetl úplně pozorně. Psal jsem o tom, že heslo by mělo být takové, aby ho útočník reálně zkoušel několik let. Počítám samozřejmě s nějakou rezervou, výkon se neustále zvyšuje, odhodlaný útočník si může pronajmout nějaký botnet s grafickými kartami nebo si to zaplatí v cloudu, takže počítám s teoretickou odolností toho hesla v řádu měsíců. Pokud se nenajde žádná chyba v implementaci. Takže mám několik měsíců na to dostat se k tomu notebooku – to mi připadá jako dostatečný čas. Ale zase pokud by k té ztrátě/krádeži skutečně došlo, nebudu tu rezervu několika měsíců využívat do poslední minuty (navíc se pohybuju v řádech, takže nedává smysl „řádově měsíce“ převádět na minuty), ale budu se snažit ten klíč (a třeba spárování s Google účtem a další) řešit bez zbytečného odkladu, v řádu hodin nebo maximálně jednotek dní. Tím opět získávám smysluplnou bezpečnostní rezervu.
Podstatné je to, že ochranu heslem (sebesilnějším), na kterou může útočník útočit off-line, nechápu jako absolutní ochranu „navždy“, je to časově omezená ochrana. A na takovou ochranu mám nějaké minimální požadavky, ale pokud je splní, už mne nezajímá, že za současné situace je ta ochrana přemrštěná a teoreticky bych se tedy na ní mohl dívat jako na neomezenou. Prostě je omezená a v případě úniku ten klíč zneplatním. Stejně jako bych zneplatnil certifikát k privátnímu klíči uloženému na čipové kartě, kdybych tu kartu ztratil – bez ohledu na to, že přístup k privátnímu klíči je chráněn PINem a po třech neúspěšných pokusech se přístup zablokuje. Jde o to, že pokud chcete něco mít bezpečné, musíte mezi tím, co je teoreticky bezpečné, a tím, co reálně používáte, mít odstup v dostatečných řádech, ne v jednotkách. Protože až příliš často dochází k tomu, že se někomu podaří prolomit přes několik řádů.
-
nerozporoval sem vyhodnost oddelenych klicu pro zarizeni, pouze zminil druhou moznost mit klic stejnej ale zabezpecenej passphrase (a ano logicky, silnou)...
to není druhá možnost, to je prostě špatně.
:-D
;-)
;-)
S ohledem na frekvenci mrkacích smajlíků ve tvých postech je ještě možný, že tvé bezpečnostní metody byly myšleny jako sarkasmus. Ale nejsem si 100% jistý ;)
-
to není druhá možnost, to je prostě špatně.
S ohledem na frekvenci mrkacích smajlíků ve tvých postech je ještě možný, že tvé bezpečnostní metody byly myšleny jako sarkasmus. Ale nejsem si 100% jistý ;)
je to druha moznost, a lepsi s pouzitim 20mistneho Velke/male/cisla/znaky passphrase, nez mit ruzne klice s bez passphrase nebo s "Filip" ;-) jak sem psal, prolomeni takove dukladne passphrase vyzaduje miliony superpocitacu s sanci v radu let, nebo tvuj domaci pocitac za ~trilion let ;-) mnozstvi smajliku chapes spatne, jen nejsem takovej suchar jako nekteri mistni mistri teoretici ;-)
-
Klepani na firewallowou branu (port knocking) je security by obscurity, ale pouzitelne to je. Po spravne sekvenci zatukani na ruzne porty firewall otevre port pro ssh.
-
Ahoj, předtím než mě odkážete na VPN, prosím o přečtení celého dotazu..
Jedná se o server ve firmě, který spravuji. Není vystaven na netu a ven žádné služby neposyktuje. Nicméně provider nám nabídl za symbolický poplatek veřejnou IP a líbí se mi myšlenka v případě potřeby se jednoduše připojit.
V celé jejich síti jde o jediný Linux server + Win stanice, jinam se tedy připojovat nepotřebuji. GUI samozřejmě není instalováno, zajímá mě pouze SSH na občasné servisní úkony a správu. Router mikrotik.
Moje představa je vystavit libovolný port s SSH serverem, přihlašování pouze klíčem.
Připojovat se budu jednak ze svého desktopu, nebo v nouzi na cesták i z tabletu, tzn. filtrování na IP nejde použít.
Jaká jsou rizika útoku? Nedostupnost SSH (ddos) není problém, vyřeší se to autem jako postaru. Naopak možné napadení (krádež/poškození firemních dat) by znamenalo hodně velký průšvih!
Pokud neuvažuju nějaké Zero-Day chyby v openssh a pravidelně aktualizovaný server, jaké má tohle řešení možné slabiny?
Preco sa hned v prvej vete branis vpn (napr. openvpn) pre znaleho je to nastavovanie na par minut.
-
je to druha moznost, a lepsi s pouzitim 20mistneho Velke/male/cisla/znaky passphrase, nez mit ruzne klice s bez passphrase nebo s "Filip" ;-)
Takže to není druhá možnost, ale třetí možnost – druhá možnost je ten váš vynález s žádným nebo slabým heslem. Jenže vy jste se tvářil, že to porovnáváte s tou první možností, tedy klíč chráněný silným heslem. Takže se znovu ptám – v čem je lepší vaše varianta „jeden klíč se silným heslem všude“ oproti variantě „unikátní klíč se silným heslem pro každého klienta“?
Taky by mne zajímalo, kolik těch dvacetiznakových hesel si pamatujete. Pokud si to heslo nepamatujete a používáte správce hesel, je to zase další prostor pro útok, který jste zapomněl zmínit.
jak sem psal, prolomeni takove dukladne passphrase vyzaduje miliony superpocitacu s sanci v radu let, nebo tvuj domaci pocitac za ~trilion let ;-)
To ovšem vycházíte z předpokladu, že se nenajde žádná chyba ani v algoritmu ani v programu a že nedojde k žádné neočekávané změně v používané technice. Což klidně za půl roku platit nemusí. Je zbytečné zvyšovat zabezpečení z milionu let na bilion, protože je velmi nepravděpodobné, že by zrovna tahle změna zastavila nějaký útok. Mnohem účinnější je přidat jinou vrstvu zabezpečení, která funguje na úplně jiném principu a nebude dotčena průlomem v té první vrstvě.
Z tohoto důvodu třeba může dávat smysl port-knocking, protože i kdyby někdo zjistil, jak rozlousknout heslo ke klíči za vteřinu na kapesní kalkulačce, port-knocking by byla druhá vrstva, která by tímhle zůstala nedotčená a server by ochránila. (Což neznamená, že bych port-knocking osobně doporučoval – riziko, že pomocí port-knockingu vyrobím nějakou jinou bezpečnostní díru nebo že nebude fungovat považuji za mnohem větší, než že někdo bude umět louskat hesla ke klíčům lusknutím prstu.)
Druhou takovou vrstvou k tomu louskání hesel od klíčů je mít kontrolu nad tím, kde se ten zaheslovaný klíč nachází. Když totiž útočník nemá ani ten zaheslovaný klíč, nepomůže mu, že by ho uměl rozlousknout během pár vteřin. A když už mám kontrolu nad tím, kde všude ten klíč je, je jednoduché mít na každém klientovi jiný klíč.
-
Preco sa hned v prvej vete branis vpn (napr. openvpn) pre znaleho je to nastavovanie na par minut.
Já jsem to pochopil tak, že se aigor.net nebrání VPN, ale že se ptá, zda to jde i bez VPN udělat přiměřeně bezpečné. Nakonfigurovat VPN na serveru je jednoduché, ale nemusí to být stejně jednoduché na všech klientech a v některých sítích může být problém protlačit VPN provoz – u SSH je přeci jen o něco pravděpodobnější, že projde, zvlášť když to chce mít na portu 443.
Neznám VPN klienty pro Android – je tam možnost do VPN tunelu směrovat jen určitý rozsah IP adres nebo jednu IP adresu?
-
Je nekolik reseni, ktera jsou o penezich a pracnosti (ve strucnosti)
1/ dedikovany VPN server v DMZ acces zone, odkud ma user pristup na konketni stroje v Inside (nebo do celeho Inside?)
2/ VPN server v obecne DMZ zone, odkud ma user pristup na konketni stroje v Inside (nebo do celeho Inside?)
3/ VPN server na hranicnim firewallu, odkud ma user pristup na konketni stroje v Inside (nebo do celeho Inside?)
4/ "otevrit" konkretni stroje v Inside, na ktere se hlasi uzivatele
Kterou cestou se tazatel rozhodne jit, je jen jeho volba. Vybrat si musi sam na zaklade jim provedene analyze rizik
-
Proc se branim VPN ?
- SSH je nastaveni take na par minut a nevim o zadne bezpecnostni slabine proti VPN
- vzdy se potrebuju pripojit 1:1 z cehokoliv (PC, tablet, mobil) na jeden jediny server a jen do konzole, na to mi VPN prijde proste zbytecne
- pro provoz VPN je vhodne mit oddeleny stroj na CA
- ze vsech variant mi pripada jako rozumna volba jen OpenVPN, mikrotik ho nezvlada a na iOS jsem taky nic nenasel
- uz mnohokrat jsem se potkal s nastavenim (hotely, verejne hotspoty,..) kde projde jen 80 a 443
..tedy se zeptam co by mi pres uvedene prineslo VPN za vyhody navic...
-
Nikdo nerika, ze otevrit SSH do internetu je spatne, ale...
Odpoved Vam da provedena analyza rizik a porovnani nakladu jednotlivych reseni
BTW - CA pro OpenVPN nepotrebuje oddeleny stroj, muze bezet v podstate kdekoli
-
Myslím, že už se bavíte hodně v teoretické rovině. Podle mě SSH, kde se dá přihlásit jen s klíčem, není v reálu problém. Jasně, může tam být chyba, ale to by jste pak nesměli otevřít do netu nic... Takhle SSH už x let provozuju doma, y let to takhle provozujou v práci a nikdy se nestalo, že by byl někomu zneužit privátní klíč (i když v teoreticky tady ta možnost je). Řádově větší pravděpodobnost je, že vás vykrade insider nebo že ten server někdo fyzicky odnese. A pokud jste hodně paranoidní, tak použijte více vrstev ochrany, jak už se tady někdo zmiňoval.
-
ssh s klicem na aktualizovanem systemu je minimum
Vzdy zalezi na konkretni situaci
-
Většinou mám SSH na dvou portech - standardní 22 a např. 10022...
- Přístup na port 22 povolen ze známých IP, autorizace i pomocí hesla;
- přístup na port 10022 povolen z IP v ČR (ipset), autorizace pouze pomocí klíče.
Doporučuji použít s Fail2Ban. Zkoušel jsem i varianty s dvou fázovým ověřením, ale to už mi přijde zbytečné :-)
-
autorizace i pomocí hesla
K čemu je to dobré? Kdy nastane případ, že znáte heslo, jste ochoten jej použít a nemůžete použít klíč?
Doporučuji použít s Fail2Ban.
Já to nedoporučuji. Nevidím v tom žádný přínos, naopak je riziko, že tím zablokujete sám sebe. Osobně mi připadá zvrácený už samotný fakt, že se parsují nestrukturované logy a na základě toho se provádějí bezpečnostně citlivé operace navíc pod rootem. To ještě nikdo nezkusil udělat Fail2Ban injection?
-
Fail2Ban neni vsespasitelny, ale pridava urcitou uroven ochrany proti brute-force utokum
Lepsi neco, nez nic
A ze zablokuju sam sebe? Tak jsem proste blb
-
Fail2Ban neni vsespasitelny, ale pridava urcitou uroven ochrany proti brute-force utokum
V čem ta další úroveň ochrany spočívá? Nebo-li jaký je vektor útoku, před kterým ta ochrana chrání?
Lepsi neco, nez nic
To je nesmysl. Něco neúčinného je horší než nic, protože v tom může být chyba, která v důsledku vytvoří díru do systému. A i když tam ta díra není, akorát se plýtvá energií na něco neúčinného, místo aby se dělala skutečná bezpečnostní opatření, a vyvolává to dojem, že se přece pro bezpečnost udělalo už dost. S heslem „lepší něco než nic“ můžete server chránit tak, že pod něj zakopete kořen mandragory, ale to doufám neděláte.
-
Ako kde, ako kto. VPN, alebo RDP viazane na IP. Teamviewer, .. :-) Zriedkavo Port knocking, pristup z dynamickych dynamickych IP cez SSH kluc.
-
Proc se branim VPN ?
- SSH je nastaveni take na par minut a nevim o zadne bezpecnostni slabine proti VPN
- vzdy se potrebuju pripojit 1:1 z cehokoliv (PC, tablet, mobil) na jeden jediny server a jen do konzole, na to mi VPN prijde proste zbytecne
- pro provoz VPN je vhodne mit oddeleny stroj na CA
- ze vsech variant mi pripada jako rozumna volba jen OpenVPN, mikrotik ho nezvlada a na iOS jsem taky nic nenasel
- uz mnohokrat jsem se potkal s nastavenim (hotely, verejne hotspoty,..) kde projde jen 80 a 443
..tedy se zeptam co by mi pres uvedene prineslo VPN za vyhody navic...
-Pokial chces cisto len ssh pristup, tak OK. Pouzi SSH. ci uz s port knockingom, alebo aj na roznom inom vysokom porte (prip. spominsl, ze hotely a spol maju vsetko blokovane okrem 80 a 443, tak pouzi 443) a samozrejme prihlasovanie klucom.
-Preco by si chcel mat oddelene CA zo stroja na ktorom sa podpisuje ? Ked pises, ze stroj neni vobec vystaveny do netu a predpokladam ze do /etc/openvpn ma pristup len root
-Pokial viem tam MK openvpn vie (iOS neviem nepoznam)
-
Miktorik OpenVPN umi, ale jen na TCP
-
Inak podotazocka (OT)
Ja som prevadzkoval OpenVPN na x86_64 ako server a asi pred 4-5 rokmi sa mi stalo, ze klienti sa nevedeli na server pripojit. Resp. vedeli sa pripojit, ale po 3-5-10 minutach nabehlo spojenie. Ked bolo spojenie vytvorene, tak fungovalo vsetko normalne. Googlil som a nic som nevygooglil. Teda vygooglil som ze mam zmenit udp na tcp a ked som to zmenil, tak klienti sa vedeli zase pripojit bez problemov.
Od vtedy pouzivam TCP a neni problem.
Myslim, ze este mam niekde ulozene logy zo servera aj klienta, ale uz sa k tomu nechcem vraciat
-
autorizace i pomocí hesla
K čemu je to dobré? Kdy nastane případ, že znáte heslo, jste ochoten jej použít a nemůžete použít klíč?
Jsou případy, kdy se to "hodí". Třeba v případě, že se jednou za čas potřebuji přihlásit ze serveru zákazníka na náš server.
Doporučuji použít s Fail2Ban.
Já to nedoporučuji. Nevidím v tom žádný přínos, naopak je riziko, že tím zablokujete sám sebe. Osobně mi připadá zvrácený už samotný fakt, že se parsují nestrukturované logy a na základě toho se provádějí bezpečnostně citlivé operace navíc pod rootem. To ještě nikdo nezkusil udělat Fail2Ban injection?
Zablokovat sám se mi spíš povede při konfiguraci firewallu :-) Musím zaklepat, ale ještě nikdy jsem neřešil problém s tím, že by to někdo překonal.