Magára hagyott openvpn szerver OpenBSD-n

OpenBSD-security

OpenBSD rendszerre telepített Open VPN szervert magára lehet hagyni különösebb biztonsági kockázat nélkül?

Semmilyen más szolgáltatás nem futna a rendszeren a defaulton telepítetteken kívül + Open VPN. 

Természetesen ideális esetben rendszeresen karban kellene tartani, biztonsági frissítések, stb. De nincs rá munkaerő azon a helyen. Mivel az OpenBSD -n nagyon ritkán vannak távoli sebezhetőségek és az Open Vpn szerveren is legfeljebb szökőévente van kritikus hiba, talán megengedhető egy ilyen kompromisszum. 

( agostonl | 2022. 08. 31., sze – 10:38 )

Sztem nem gond, de én például ugyanezt pfSense-el oldottam meg, ott elég volt összekattingtatni és az FreeBSD.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"

"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

(ugyan nem pfsense, hanem opnsense)

Na, azt havonta peccselgetni kell, mert a 1manshow project keretében a kis führer észnélkül hányja bele a teszteletlen kipróbálatlan kódot. Aztán megjelenés után pár nappal záporoznak a .1, .2 stb peccsek.

Ha meg szóváteszed a fórumban h. tróger a quality controlljuk (eleinte még szépen megfogalmazva, nem tahón), akkor az nem tetszik a kis galamblelkének, mindent azonnal magára vesz. Aztán pár kommentváltas után besértődik, fejlődés a témában általaban nem lesz, viszont az ember kedvét elveszi az állandó bugreportolgatástól. Főleg ha egy nemszexitrendi sokak által használt funkció szarik be, akkor évekig lesheted mire elmozdul ebből az állapotból. Kíváncsi volnék, a fizetős vendégekhez is így állnak-e hozzá, de arra egy otthoni hasznalatú nem céges/pénztermelő cuccnál nem akartam annyi eurót kidobni az ablakon h. kipróbáljam.

Illetve minden upgrade egy rizikó, h.beszopsz-e valamit amit épp bem teszteltek le kedves developerjeik, és akkor mehetsz ki a halál faszára megnyomni a reset gombot, ha onsite nincs senki akire ezt rá lehetne bízni.

Szóval az opnsense tutujgatas-igényes tűzfal disztrib.

Meglepődnék ha ez a része nem állna a pfsense-re is.

Nem áll, mi aktívan használunk pfSense-t. Minden hibajelzésre többé-kevésbé korrekt választ kaptunk eddig. Ezzel együtt is vannak hibák, és a quality control lehetne jobb, de nagyrészt egész stabil tűzfalként.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nekem éppen ellenkező tapasztalatom van opnsense terén. Kb. azóta használom több helyen, mióta forkolták a pfsense-t, és eddig egyszer sem volt helyszínre utazós gondom frissítés miatt (vagy bármi más miatt, amit nem tudtam megoldani rajta távolról). Pedig előfordult már olyan szégyenszemre, hogy 4-5 "főverziót" frissítettem egymás után azonnal egy régvolt ügyfélnél, mert el volt maradva. Komolyabb (GUI-n nem megoldható) problémába nem futottam eddig.
Bugreportot még nem küldtem 7 év alatt egyet sem, lehet nem használom azon részeit, amivel gondok vannak (pedig elég sok dolog van rájuk lapátolva), vagy találtam mindig valami megoldást ha felmerült valami. Így azt nem tudom sem alátámasztani, sem megcáfolni, hogy hogyan állnak (emberileg, szakmailag) a hibákhoz, kritikához.
Amíg HardenedBSD-t használtak alapnak, addig aggódtam, hogy mi lesz, mert annak a fejlesztése nagyon lelassult a FreeBSD-hez képest, mert az tényleg 1 emberes projekt. De szerencsére a 2022.1 verzióval átálltak vanilla FreeBSD 13.x-re, amit főleg az egyéb szoftverek kompatibilitása miatt léptek meg (a HardenedBSD alapnál voltak ilyen gondok).

Ellenben pfsense már állt meg frissítéses automata újraindulás során konzolon kiírt kérdéssel, ami miatt oda kellett menni, és gombot nyomni, hogy továbbmenjen és elinduljon. Hátrányának a régebbi FreeBSD alapot mondják, amivel a friss driver-ek hiánya jár, de én jellemzően nem futtattam ilyesmit annyira kurrens hardveren, hogy ez gondot okozott volna. De érdemes ezt figyelembe venni. Én személy szerint azért váltam meg tőlük mindenhol, mert szerintem elfogadhatatlan fesztivált csináltak, mikor az elvileg teljesen open source és megengedő licencű szoftverüket forkolták az opnsense alapjának, mert nem értettek egyet a fejlesztési iránnyal (ugye a fő gondjuk az volt, hogy nem volt köztes réteg, a GUI hajtotta végre a feladatokat, ergo nem szabadott lapot váltani, amíg nem futott le a művelet - nem tudom ezzel most hogy áll a pfsense). Aztán a Wireguard fiaskó sem tett jót a hírnevüknek...

( sibike | 2022. 08. 31., sze – 10:43 )

Nagyban függ az OpenVPN konfigtól.  Bizonyos konfig beállítások mellett azért szoktak lenni remote sebezhetőséegek. Szerver vagy kliens lesz? Bárhonnan lehet csatlakozni, vagy le lehet tűzfalazni?

geokorlátozás a mai világban, amikor a szofisztikáltabb próbálkozók aws-ből, azure-ból jönnek, mennyit ér? Kínai ip cím max a nagyon amatőr automatizált próbálkozásoknál fog látszani. Aki kicsit komolyabban csinalja, az a botnet-ben a célponthoz tartozó országból bérel támadókat, nem?

( STP | 2022. 08. 31., sze – 10:50 )

Egy biztonsági rendszerrel nem foglalkozni nagy fokú kockázat.
Még ha teszi a dolgát hibátlanul, akkor is illik azért átfésülni periodikusan - legalább - a log-okat.

Akkor csak így tovább a lenini úton! De előtte azért célszerű lenne megkérdezni a projektvezetőt, hogy ha felnyomják a kutatási projektjüket és mindent bedarálnak a devnull-ba, az mennyibe fog fájni nekik? És ehhez képest mennyi lenne erőforrást allokálni a bejárat védelmére? Tippem szerint nagyságrendnyi lesz az eltérés, több nagyságrendnyi.

Kérdés kit tesznek meg majd felelőssé a végén .. aki "puszira" összerakta a rendszert? Akkor saját maguk alatt vágták ki a fát.

Akivel anno kötöttek egy megbízási szerződést egyszeri telepítésre és megpróbálnak utánanyulni ? Sok sikert -> saját maguk alatt vágták a fát ...

Sehogy se lesz ez így jó :)

Azért mondtam RedHat-et, mert:

  • Atom stabil, nem lesz gond az automata frissítéssel és reboot-tal
  • Hosszú távú frissítés
  • Mégis enterspajz, lessz aki frissen tarja, és ha kell akkor backportol fix-eket, nem csak akkor ha éppen nincs szabin és van kedve

Centos ha jól tudom most a fedora és a redhat közé van beékelődve, elképzelhető hogy kevésbé stabil.

Értem,

Nem vagyok Redhat ellenes, sőt, van pár szerver ami még redhat 7 -8 -al fut, .. subscriptiion nélkül -> azaz nincs biztonsági frissítés se.

Centos -> sok helyen használtam / használom a "régi" verziót, a 7-esig kb. Az egy copypaste volt, ami a lényeg volt hogy Redhat / Centos "binary-compatible" volt, tehát ha a HP pl kiadott egy drivert redhathoz, az ment centoson is, stb..

De fixme,  nem olvastam el a fenti linket teljesen, de redhat developer* szerepelet benne, akkor az hogy lehet enterprise ? meg sok évig támogatott ? Ennyi erővel lehetne egy debian sid is...

+ ^^ OPból kiindulva nincs aki karbantartsa.. 

( x-daemon | 2022. 08. 31., sze – 11:24 )

tudom mar honnan jonnek a spamek...

neked aztan fura humorod van...

( _Franko_ v | 2022. 08. 31., sze – 11:44 )

Bátor dolog, pont két hete jött ki egy zlib heap buffer overflow és ez csak az alaprendszer, az OpenVPN se lesz attól biztonságosabb, hogy OpenBSD-n fut. Legalább olvassa valaki a security advisory és annak megfelelően, ha lyuk van, akkor lesz workaround majd fix? Mert különben bátor dolog, de hát ott tudják, hogy mi a fontos nekik.

https://iotguru.cloud

ne tegyünk úgy, mintha a világ összes interneten lógó tűzfalának lenne gondosgazdája. Millió helyen fut Cisco ASA is, évtizedes szoftverrel, mert alatta az IOS már end of life. De a vas maga még bírja, áramon kívül mást nem kér enni, szóval jó lesz az úgy.

( hrgy84 | 2022. 08. 31., sze – 12:14 )

Egy belső hálózathoz hozzáférést engedő cuccot magára hagyni... hát, nekem mérsékelten tűnik jó ötletnek. Értem, hogy nincs rá pénz, de mérjétek fel annak a kockázatát, hogy mekkora károkat lehet okozni azzal, ha valaki mégis bejut azn a VPN szerveren keresztül a belső hálóra, és ezt az egész kalkulációt tegyétek a vezetés elé. Ha továbbra sincs pénz, legyen lepapírozva, hogy semmilyen ebből fakadó kárért felelősséget nem vállaltok.

De én egész egyszerűen megszűntetném ebben az esetben a VPN szervert, mert biztonsági kockázat így. Oldják meg máshogy.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Zs | 2022. 08. 31., sze – 15:51 )

Hegessz rá knockd-t, akkor a port alapban zárva van.

A kliens meg a VPN húzása előtt kopogtat.

( GaLbi | 2022. 08. 31., sze – 17:38 )

Talán egyszerűbb lenne adni a kezükbe egy leírást, hogy hogyan tudják frissíteni a rendszert. (vagy ezt lehetne automatizálni is, habár sokan nem szeretjük automatikusan telepíteni a frissítéseket) 

( Raynes v | 2022. 08. 31., sze – 18:04 )

Bármilyen szervert és rendszert magára hagyni kockázat, és felelőtlenség. Nem az OpenBSD okán, hanem akármilyen OS-sel. Mint minden rendszert, karban kell tartani, frissíteni, stb.. Persze attól is függ, hogy mit értesz pontosan a magára hagyáson, valami távfelügyeleti lehetőséget hagysz-e, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( ggallo | 2022. 09. 01., cs – 00:11 )

Ha nincs rá pénz, de pénzben kifejezhető a veszteség, amit okozhat, ha gond lesz, akkor más megoldás után kell nézni, vagy pénzt kell rá szánni.

Én valójában nem is tudom értelmezni soha az ilyen "szükségünk van X-re, de nincs rá pénz" helyzeteket. Nekem még sose jött be a boltba, hogy szeretnék téli szalámit, de nincs rá pénzem, adjanak már csak úgy. Meg még a falamat sem festette le senki ingyen, mert tetszene az új szín, csak nincs rá pénzem...

( ibenny v | 2022. 09. 01., cs – 00:25 )

Szerkesztve: 2022. 09. 01., cs – 00:25

Nem hagynám szívesen/jó érzéssel magára. De ha ennyire nem tudjátok kapásból megoldani, írj rám itt a kapcsolat formon és meglátom mit tehetek.