VPN (of andere oplossing) voor mijn situatie

[oyay]

Dag Allen,

ik heb een vraagje mbt onze situatie.

Wij hebben bij onze klanten een kleine pc staan met een linux distro. Wij hebben er nu meer dan 2000 her en der staan. Wij willen voor onze toekomstige klanten remote bij onze pc`s kunnen om het een en ander te bekijken op de pc.

Nu hebben wij al bedacht dat we wel een VPN server kunnen opzetten bij ons intern en de client dmv een vpn client automatisch latten connecten bij het booten en zo een connectie laten opbouwen waar wij bij kunnen.

Nu is dit wel "een" oplossing maar sommige klanten hebben veel poorten dicht staan of willen deze niet openen. Hier zijn wij dan dus verplicht om over poort 80 te connecten (als dit al kan).

Nu mijn vraag:

Hoe zouden jullie dit doen? Wat is hier een goeie oplossing voor? Ik vind een vpn server niet echt een " hufter proof" oplossing en wij zijn hiermee te veel afhankelijk van de infrastructuur van de klanten.

Ik kan wat budget vrij krijgen om dit op te zetten. Maar het moet natuurlijk geen duizenden euro`s gaan kosten.

Ik geef hier boven aan dat het om 2000 pc`s gaat maar dit zal niet meteen het geval zijn. Planning is om dit binnen 1,5 jaar wel te hebben.

Alvast bedankt voor het meedenken.

[lier]

Zou je iets meer context willen geven? Wat doen deze pc's?

Mij lijkt dat naast poort 80 ook poort 443 open staat (of gezet kan worden). Wellicht kan je in dat geval met OpenVPN gaan werken en hiervoor poort 443 inzetten?

[Keypunchie]

Klinkt als een display-PC of iets dergelijks, iets dat een ander apparaat aanstuurt in ieder geval.

Eigenlijk wil je gewoon dat jij shell-access met die machines kunt opzetten (dus dat ze een port-forwarding op een publiek IP+poort hebben) , maar kan me voorstellen dat er klanten zijn voor wie dit boven de pet gaat, of juist klanten die het absoluut niet toestaan voor het netwerk waar jij in zit.

Wat voor soort akties wil je ondernemen? Want misschien is het makkelijker als het bijvoorbeeld om een nieuwe versie van een bestand of content gaat, dat ze die via een cron-job binnenhengelen. Of als het om een status-check gaat, dan kun je iets doen met dat ze via curl met een bepaalde agent-string (al naar gelang status) een webserver aanroepen en dat je daar de logs van monitort.

[jeanj]

Ik weet niet wie je klanten zijn, maar heb je van elke klant toestemming dit te doen.
En met dit is een device in hun netwerkt te hangen, wat op afstand over te nemen is, en daarmee ook de rest van het netwerk potentieel compromitteert?

Als we kijken naar puur technisch , kan je overigens gewoon een vpn over 443 laten lopen, zoals hierboven aangegeven. Maar waarom gebruik je geen teamviewer, logmein of dat soort tools. Waarom wil je zelf iets bouwen (en ja als teamview etc gaat doen, moetje het ook even met je klant er over hebben)

[CAPSLOCK2000]

Het is een Linux PC, die beheer je niet met grafische tools die zijn gericht op Linux.

Ik denk dat je inderdaad een verbinding vanaf de client moet opzetten naar een server die je zelf draait. Als de klant dat helemaal dicht firewalled dan houdt het op, tenzij je zelf een GSM op je computer aansluit.

Voor VPN zou je kunnen kijken naar (reverse) SSH-tunnels, dat is een lichtgewicht alternatief op andere VPN-oplossingen, dat kan leuk zijn in zelfbouwoplossingen.
Eigenlijk denk ik dat je beter af bent met OpenVPN.

[jeroen3]

In de automatisering doen we dit met modules van eWON. Dat is niets anders dan een openvpn client in een doosje. Met 3G als optie.
Deze modules worden automatisch geupdate, en ze maken verbinding met de cloud van eWON, zodat je dat zelf niet hoeft te hosten.
Dit is volledig firewall friendly. Als je naar internet kan, dan werkt dit.
Jij maakt vervolgens ook verbinding met deze cloud en dan met de apparaten naar keuze.

Wellicht voor een IT oplossing wat prijzig, maar het idee valt af te kijken.

[ Voor 10% gewijzigd door jeroen3 op 05-12-2018 17:40 ]

[mcDavid]

Zou je hierover niet gewoon in gesprek moeten met die klanten? Als die geen VPN verbinding toestaan (wat ik me héél goed kan voorstellen) zullen ze daar vast een reden voor hebben.

Als je volledig onafhankelijk wilt zijn van het netwerk van die klant, moet je i.m.o. ook bereid zijn je systeem daar volledig van los te koppelen, en dus verbinden via een 4G modem of andere verbinding die je zelf beheert.

Ik heb in het verleden wel eens zo'n setup gemaakt, daarvoor gebruikten we viprinet apparatuur. Die kon dmv WiFi- en 3g insteekkaarten meerdere verbindingen pairen en regelde ook direct de VPN. Voor de betreffende usecase was het wel te legitimeren maar normaal gesproken zou ik me heel erg hard achter de oren krabben voordat ik een 3e partij zo'n device in mijn pand (laat staan op mijn netwerk) zou laten plaatsen.

[FreshMaker]

knip

[ Voor 99% gewijzigd door FreshMaker op 28-01-2019 12:47 ]

[oyay]

lier schreef op woensdag 5 december 2018 @ 12:27:
Zou je iets meer context willen geven? Wat doen deze pc's?

Mij lijkt dat naast poort 80 ook poort 443 open staat (of gezet kan worden). Wellicht kan je in dat geval met OpenVPN gaan werken en hiervoor poort 443 inzetten?

Het gaat om een display pc die wat info zal tonen.

Keypunchie schreef op woensdag 5 december 2018 @ 14:38:
Klinkt als een display-PC of iets dergelijks, iets dat een ander apparaat aanstuurt in ieder geval.

Eigenlijk wil je gewoon dat jij shell-access met die machines kunt opzetten (dus dat ze een port-forwarding op een publiek IP+poort hebben) , maar kan me voorstellen dat er klanten zijn voor wie dit boven de pet gaat, of juist klanten die het absoluut niet toestaan voor het netwerk waar jij in zit.

Wat voor soort akties wil je ondernemen? Want misschien is het makkelijker als het bijvoorbeeld om een nieuwe versie van een bestand of content gaat, dat ze die via een cron-job binnenhengelen. Of als het om een status-check gaat, dan kun je iets doen met dat ze via curl met een bepaalde agent-string (al naar gelang status) een webserver aanroepen en dat je daar de logs van monitort.

cronjob is ook een optie. Bedankt.

jeanj schreef op woensdag 5 december 2018 @ 14:58:
Ik weet niet wie je klanten zijn, maar heb je van elke klant toestemming dit te doen.
En met dit is een device in hun netwerkt te hangen, wat op afstand over te nemen is, en daarmee ook de rest van het netwerk potentieel compromitteert?

Als we kijken naar puur technisch , kan je overigens gewoon een vpn over 443 laten lopen, zoals hierboven aangegeven. Maar waarom gebruik je geen teamviewer, logmein of dat soort tools. Waarom wil je zelf iets bouwen (en ja als teamview etc gaat doen, moetje het ook even met je klant er over hebben)

Teamviewer is geen optie ivm geen grafische desktop. (tenminste niet zonder wat tweakwerk). Toestemming is er natuurlijk vanuit de klanten.

Bedankt. Zoals het er nu uit ziet zullen we poort 443 gebruiken omdat deze poort bij veel klanten open staat.

[oyay]

Allen bedankt voor jullie input en mogelijke opties!

[Keypunchie]

Zelf ben ik gewend aan sterk gecentraliseerde IT. Mijn servertjes staan, gevirtualiseerd of niet, meestal netjes in een datacenter, omsingelt door firewalls en gescheiden door VLANs, met allemaal beheertooling die monitort, logt, rapporteert en patcht.

Kortom, het scenario, waarbij mijn servers decentraal (in klantnetwerken) staan is voor mij geen gesneden koek. Getriggerd door dit topic was ik zelf gaan nadenken, wat zou ik doen, als ik alleen poort 80/443 uitgaand zou hebben en toch remote beheer wilde uitvoeren.

Ik had het volgende bedacht en vraag me af, in hoeverre dit volgens jullie medetweakers secure is, of welke anti-patroon ik dan inloop.

Mijn gedachte zou zijn. Ik zet ergens een webserver neer op domein www.centraleserver.nl.

Iedere client wordt uitgerust met een script, dat via cron x keer per dag checkt op www.centralserver.nl/hostID

Aan zijde van de centrale server kan ik dan in ieder geval monitoren wat de laatste keer is dat een specifiek ID zich gemeld heeft. Meldt hij zich al meer dan 3 dagen niet, ofzo, dan kan ik aannemen dat er wat mis is. Op die manier heb ik zeer basic uptime monitoring. Desnoods kan ik nog meer informatie in de http-request stoppen, maar laten we het voor nu simpel houden.

Security: Bij voorkeur gaat dit over https. Omdat het puur status is, kan ik er nog mee leven als het alleen poort 80 is. Om spoofing te voorkomen zou ik nog een client-certificate kunnen vereisen.

Nu voor het beheerstuk:
Mijn gedachte is dat de file die ik check, ook gewoon een .sh-zou kunnen zijn. Als onderdeel van de cron wordt de file binnengehaald, wget, gechmod naar executable en uitgevoerd. Eventueel met een "en check nog een keertje nadat je dit gedaan hebt". Het terugkoppelen van informatie zou in gelimiteerde vorm kunnen door naar www.centralserver.nl/hostID/logoutput telkens http(s)-requests te doen met regel voor regel de output van standard-out.

Security: Dit is natuurlijk tricky, want zeer kwetsbaar voor MitM. Alleen https lijkt mij onvoldoende. Zelfs als ik alleen mijn eigen certificaat in de trust-store zet, kan in geval van hacken van de webserver dit tot problemen leiden. In dit geval zou ik dan op een andere server die de commando's genereert ook de .sh zelf ook moeten signen, om te voorkomen dat iemand mijn commando's kan spoofen.

Als alternatief:
Meestal zal ik geen generieke commando's willen doen, maar eerder een setje van van te voren opgestelde commando's. Scenario's kunnen van heel specifiek tot generiek "reboot". Dan zou je in plaats van een .sh, simpelweg een filenaam met "aktie_A", "aktie_B" op de centrale server kunnen neerzetten, die door het cron-script herkend worden als een van te voren gedefinieerd lokaal aanwezig shell-script.

In dat geval zou het zelfs over poort 80 kunnen (onwenselijk). Immers, iemand kan dan mijn server spoofen, maar de impact is dan op zijn ergst een DOS (de client gaat continu rebooten, ofzo) en niet dat ze de facto toegang hebben tot de client.

Allemaal redelijk omslachtig, uiteraard, t.o.v. een shelletje, maar volgens mij wel werkbaar, en ook redelijk te beveiligen.

[pyrofielo]

en hardware oplossingen?

Ik kan even niet op de naam komen van het merk wat ik bedoel maar met google kwam ik nu hier op uit:
https://www.secomea.com/sitemanager-hardware/#

Gewoon een kastje wat in het netwerk hangt. Je kan er van alles mee ook RS232 rotzooi eraan hangen. Voordeel is dat je gewoon een kastje in het netwerk van de klant hangt en ze zelf centraal managed. Zo kan je makkelijk ergens even "inbellen".

Over het algemeen hebben dit soort oplossingen al voor je nagedacht over hoe om te gaan met firewalls en dergelijke.

[jeanj]

oyay schreef op donderdag 6 december 2018 @ 10:55:
[...]
Teamviewer is geen optie ivm geen grafische desktop. (tenminste niet zonder wat tweakwerk). Toestemming is er natuurlijk vanuit de klanten.

Bedankt. Zoals het er nu uit ziet zullen we poort 443 gebruiken omdat deze poort bij veel klanten open staat.

Ok dat stond niet in je TS. Echter het principe kan je nog steeds toepassen, de client verbind met de server, en over die verbinding neem je de client over.

Het makkelijkste is dan reverse ssh tunnel over https te laten lopen. Er zijn tools om dit voor de proxy onzichtbaar te laten zijn, zoals corkscrew . Je zou een port kunnen forwarden naar de server op poort XXX waar bij je als je op de server op die poort connect en daarme direct op de client (ssh port 22) zit. Het enige wat ik zie dat het lastig kan zijn een continue verbinding open te houden.
En natuurlijk unieke sleutels voor de toegang etc etc

[ Voor 7% gewijzigd door jeanj op 07-12-2018 08:39 ]

[FreshMaker]

oyay schreef op donderdag 6 december 2018 @ 10:55:
[...]


Het gaat om een display pc die wat info zal tonen.
[...]

Kijk voor info displays anders eens op piSignage.com
Kan je remote de indeling en info aanpassen.

[Frogmen]

FreshMaker schreef op woensdag 5 december 2018 @ 19:04:
Hier ook zo'n externe partij ( meerdere zelfs )
Een drietal leveranciers van alarmontvangende installaties roepen al 10 jaar dat ze toegang moeten hebben voor veiligheid en updates, en één wil remote toezicht instellen op de handling software ( het pakket waarin wordt bijgehouden welke centralist - wat en wanneer gedaan heeft )

Dat gaat dus niet gebeuren, ondanks dat we op verschillende levels het netwerk hebben lopen, willen ( en mogen) we geen externe toegang verlenen.
Wie wordt er verantwoordelijk gesteld bij een lek, bij ongeoorloofde toegang of erger - mislukte update waardoor wij uren / dagenlang geen meldingen van alarmsystemen ontvangen ?

Alle aanpassingen mogen op lokatie gedaan worden, onder supervisie van de verantwoordelijkeICT'er / gedelegeerde, en elke handeling wordt besproken en gedocumenteerd
( we kunnen reboots van 15 jaar terug opvragen, nooit nodig geweest, maar wel aanwezig )

Ik als ICT kan bij sommige applicaties, via een verbinding op basis van NoMachine ( soort teamviewer idee ) maar ook niet bij de 'echte' hardware erachter.
Meer dan een reboot kan dan ook niet, bij echte shit moet ik gewoon in de auto stappen

Je mag dat als klant allemaal willen maar daar hangt een prijskaartje aan, jouw organisatie kan en wil dat betalen. Echter zijn er heel veel die die kosten niet willen en waar de risico's anders liggen.

[FreshMaker]

@Frogmen Klopt, maar wanneer je je als klant laat leiden door wat een toeleverancier wil, is het einde zoek.
Voor je het weet ben je zo afhankelijk, dat je in de hoek gedrukt wordt.

Kijk naar een café op de hoek, die 'makkelijk' geld kan lenen van een bier-leverancier, maar ondertussen steeds meer aan wurgcontracten vast komt te zitten.
Begint met "onze viltjes en posters" en als je een paar maanden verder goed draait "je mag alleen ONS bier tappen, en daar valt ook dit frisdrankmerk onder ...

Als klant moet je ten alle tijden voor jezelf blijven opkomen, externe partijen die geld aan jou verdienen hebben niet per definitie 'het beste' met je voor hoor

[Kasper1985]

Ik werk voor een internationale cloud provider.

Wij werken voor alles met jumphosts met 2fa. Dus naast een statisch wachtwoord ook een usb key die een code genereert.

Om bij een klant server te kunnen (weleenswaar op ons platform dus iets anders natuurlijk) moet ik eerst een vpn (anyconnect) opzetten (passwd en 2fa) dan op een jumphost (shelladmin) inloggen en vervolgens kan ik vanaf daar pas inloggen bij de klant. Shelladmins zijn van buiten niet te bereiken zonder vpn.

Het is natuurlijk een wat ander uitgangspunt dan servers op klant lokatie. Maar dit is behoorlijk veilig. Veel klanten doen en willen self managed. Maar wanneer de shit de fan raakt kunnen we er op deze manier altijd bij.

Voor mijn thuis servertje pas ik hetzelfde principe toe. Ik heb bij ons een virtual servertje draaien waar voor ssh 2fa nodig is en een key. Thuis staat een raspberry pi die alleen ssh connecties ondersteunt vanaf het ip van de virtuele server. Vanaf die raspberry pi (beveilogd met 2fa key én wachtwoord) kan ik bij m’n server.

[ Voor 19% gewijzigd door Kasper1985 op 07-12-2018 17:10 ]