Linux appliance bij klanten thuis zetten, hoe connecteer je?

[bucovaina89]

Ik ben met een "wild" idee bezig waarbij ik een mini Linux/Debian bakje (RPI compute module of aanverwante) bij klanten thuis zou willen zetten maar wel nog de mogelijkheid tot remote onderhoud zou willen behouden. Hoe pak je dat beste aan en wat schaalt er relatief goed?

Enige wat ik me nu kan bedenken is een WireGuard VPN installeren, port forwarden en credentials bij houden. Dan "phonet" dat ding niet home (ik zou het zelf als klant niet graag hebben) maar "bel" je in als het wenselijk is.

Maar dan zit ik met het probleem: wat is het IP van de klant? Zou je dan een DDNS dienst gebruiken? Maar dan moet zo'n appliance toch "phone home" doen? Of een LCD op de RPI behuizing zetten die het publieke IP laat zien, klant opbellen, vragen naar het publieke IP, en dan kan ik een VPN aanleggen.

Maar het klinkt me allemaal wat DIY, er zijn waarschijnlijk betere oplossingen.

[gebruiker]

https://www.zerotier.com/ is hiervoor perfect.

[eric.1]

Het ligt natuurlijk ook wel aan het type onderhoud. Je kan al snel een scriptje periodiek laten draaien op die PIs om via een beveiligde verbinding elders update-instructies op te halen.

Geen idee wat voor klanten het zijn en wat die dingen gaan doen, maar dat je daar überhaupt remote zonder toezicht op wilt komen is wel een design-probleem (of je moet pentests uitvoeren, maar daar klinkt het niet naar) lijkt me. In zekere zin is het een backdoor tot hun netwerk. Dit zal je dan, als je dit toch zo gaat doen, ook juridisch dicht moeten timmeren (met alle beveiligingsimplicaties van dien).

[ Voor 3% gewijzigd door eric.1 op 12-09-2022 21:01 ]

[MAX3400]

Een beetje klant (zakelijk?) heeft een static IP dus daarmee is 50% van je vraag al beantwoord.

Hoe kom je erbij / erin op een veilige manier? SSD-keypairs configureren (en natuurlijk je SSH-port veranderen etc).

Ben een beetje zoekende naar je vraag / achtergrond; het klinkt wat "beginner" en dan vraag ik me af wat jij of je klant eraan hebt als er mogelijk onveilige apparatuur zonder monitoring wordt achtergelaten.

[tafkaw]

Reverse SSH tunnel opzetten naar een server van jezelf.

[bucovaina89]

MAX3400 schreef op maandag 12 september 2022 @ 20:58:

Ben een beetje zoekende naar je vraag / achtergrond; het klinkt wat "beginner" en dan vraag ik me af wat jij of je klant eraan hebt als er mogelijk onveilige apparatuur zonder monitoring wordt achtergelaten.

Neen in principe niet, maar stel dat het toch wat wordt (waarschijnlijk niet), en er staan 100 bakjes verspreid over België, wil ik niet bij elke habbekrats gaan liggen rondrijden maar vanop afstand problemen kunnen oplossen. Ik wil dus een min of meer betrouwbare manier tot toegang, op een veilige manier én waar mensen zich OK bij voelen.

Ik was nog aan het denken aan een custom RPI case met een of meerdere knoppen erop en status LCD. Om bijv de VPN aan/af te zetten, soft reboot, ... . Dan is het altijd op vraag/actie van de klant dat ik erop zou kunnen.

[frickY]

Maak er een support-knopje op die "home phoned" als de klant er op drukt?

[Vorkie]

Probeer het onderhoud te automatiseren met een API op een centrale plek.

De client checkt de API en als er iets klaarstaat voert hij het onderhoud uit op het moment dat de klant dat wilt.

Dat stukje software stop je in een eigen repository, zodat je via die weg ook nieuwe versies van het onderhoudsscript kan ophalen.

[ Voor 25% gewijzigd door Vorkie op 13-09-2022 07:13 ]

[evilution]

frickY schreef op dinsdag 13 september 2022 @ 07:06:
Maak er een support-knopje op die "home phoned" als de klant er op drukt?

Zoiets dus. Als klant zou ik er namelijk ook niet blij mee zijn als een leverancier te pas en te onpas mijn home kan phonen...

[Brahiewahiewa]

evilution schreef op dinsdag 13 september 2022 @ 07:19:
[...]

Zoiets dus. Als klant zou ik er namelijk ook niet blij mee zijn als een leverancier te pas en te onpas mijn home kan phonen...

Precies dat. @bucovaina89 wil voorkomen dat zijn appliance zelf een phone home doet en daarom moet de klant dan maar toestaan dat @bucovaina89 op zijn netwerk mag? Ben je nou helemaal van de ratten besnuffeld?
Dat apparaten naar huis bellen zijn we ondertussen wel gewend. Windows doet het. Linux doet het. Mac's doen het. Al onze thermostaten, LED lampen en deurbellen doen het. Ga naar die ervaringen kijken en probeer het op een verantwoorde manier te implementeren. Maar jou inbel rechten geven op mijn netwerk is erger dan de kwaal

[hsb85]

gebruiker schreef op maandag 12 september 2022 @ 20:42:
https://www.zerotier.com/ is hiervoor perfect.

Dit is inderdaad precies waar ik zerotier voor gebruik.
Al mijn apparaten hebben zerotier en via zerotier kan ik overal in de wereld bij die apparaten via hun eigen IP.

Gebruik ook 1 van mijn domeinen om ze een URL te geven.
bv zerotower.xx.xx is mijn server thuis of zeropad.xx.xx is mijn Thinkpad.
Leuke is dat die URL alleen werkt als je ook daadwerkelijk toegang hebt tot mijn zerotier netwerk.

Zerotier kan je daarnaast ook als docker container draaien, dus je hoeft niet eens hem te installeren als aparte applicatie.

Zo kan ik dus altijd bij mijn server zonder dat de server poorten heeft die open moeten staan in de router.

[ Voor 7% gewijzigd door hsb85 op 13-09-2022 10:06 ]

[jurri@n]

Als je dat aantal machines moet beheren, kun je dan niet beter gaan kijken naar iets als Ansible, Chef, CFEngine of Puppet, zodat je installaties consequent zijn en vanaf 1 plek te beheren?

Bij Ansible zou je de playbooks in een git-repo kunnen zetten (beveiligd met een eigen key voor iedere machine), en die periodiek naar lokaal ophalen en uitvoeren.

Bij Puppet wordt standaard verbonden met een server (puppermaster) voor het ophalen van configs, maar dat komt dan wel weer aardig in het 'phone-home'-gebied.

Dekt dit alle problemen? Nee. Maar als je je playbooks (of hoe jouw gekozen tool het ook maar mag noemen) goed opzet, blijven alleen situaties over waar de verbinding naar het internet niet meer werk (dus had je ook al niets aan een remote oplossing) en situaties met hardware-problemen (dan moest je toch al langs).

[Sjnieboon]

Al eens naar Tailscale gekeken? Ook als open source project (headscale) verkrijgbaar.

[elleP]

hoe dan ook ben je een 'phone-home' constructie aan het bouwen, op welke manier je het ook inricht maak je een mogelijkheid om arbitraire commandos uit te voeren op een doosje op iemand anders' netwerk.

De enige manier om dat als netwerk-eigenaar tegen te gaan is het doosje op een eigen (v)lan te parkeren, zonder toegang to de rest van het netwerk. Maar dat is voor de meeste bedrijven en zeker particulieren een brug te ver.

[Sharky]

En oplossingen met een ingebouwde simkaart, lost dat iets op? Geen idee over wat voor device we het hebben, maar dan hoeft het in ieder geval niet via het wan van de klant.

[fastedje]

bucovaina89 schreef op maandag 12 september 2022 @ 20:37:
Ik ben met een "wild" idee bezig waarbij ik een mini Linux/Debian bakje (RPI compute module of aanverwante) bij klanten thuis zou willen zetten maar wel nog de mogelijkheid tot remote onderhoud zou willen behouden. Hoe pak je dat beste aan en wat schaalt er relatief goed?

Wat een relatief makkelijke oplossing is:: maak een systemctk file waarin je een ssh tunnel opzet naar een van je eigen systemen. Hierdoor heb je geen VPN nodig en hoef je ook geen firewall open te zetten.
Toegang met ssh kan je regelen met de authorizedkeys file(s), maar het kan ook mooier en beter met ssh-certificates. Dat laatste is wel wat voor gevorderde ssh admins.

Het mooie aan ssh is dat je naast een remote shell ook allerlei extra poorten kan tunnelen ocer een ssh verbinding. Zet wel de keepalive reteies hoog genoeg zodat je verbinding lang open blijft. je kan dus ook prima een remote vnc server benaderen met je ssh tunnel.

[bucovaina89]

@fastedje : dat moet ik eens bekijken hoe ik dat mooi kan doen, ik vermoed dat dat een remote SSH-tunnel heet dan? Dat lijkt me dan nog het mooiste. Geen poort open zetten en enkel op vraag van klant. De klant duwt op een knopje en ~20min wordt er een reverse SSH tunnel opgezet met SSH-keys. Als er dan niets gebeurt, gaat die automatisch weer afgesloten worden. Dat zou dan ook voorkomen dat als mijn servers gehackt worden (waar dan aan Ansible Repo op zou kunnen staan) dat dat zomaar verder zou kunnen lopen naar alle klanten (sort of painful).

[MAX3400]

bucovaina89 schreef op dinsdag 13 september 2022 @ 13:22:
Dat zou dan ook voorkomen dat als mijn servers gehackt worden (waar dan aan Ansible Repo op zou kunnen staan) dat dat zomaar verder zou kunnen lopen naar alle klanten (sort of painful).

En wie zegt dat je niet nu al gehackt bent en dat de payload langzaam maar zeker bij jouw klanten terecht gaat komen?

Als je je al zorgen maakt over dat "jouw servers" gehackt worden, dan zou ik als klant eigenlijk helemaal wel willen weten of je geschikt bent voor de job?

[WoLFjuh]

Voor van dit soort oplossingen gebruik ik OpenVPN met zelf gegenereerde certificaten voor authenticatie en validatie. Dit is een always-on oplossing die je kunt gebruiken over TCP of UDP. Je kunt er voor kiezen om deze te gebruiken op port 443/tcp als je bang bent dat een uitgaande firewall het zal blocken.

De certificaten kun je zelf aanmaken (eigen PKI): een root CA, een server certificaat en meerdere client certificaten. Hiermee valideer je dat je doosje daadwerkelijk met jouw server connect door het CA dat je hebt gegeneereerd in je doosje te laten. Je server valideert weer een client certificate en daar mee bewijs je dat het ook echt je doosje is. Als een doosje kwijt is, of je vermoed dat iemand de certificaten van een doosje in handen heeft dan voeg je het client certificaat toe aan je eigen CRL (certificate revocation list) die door de server wordt nagekeken bij iedere connect.

Voor de haters die het slecht vinden dat je met je vingers potentieel in hun netwerk zit? Of je dit nou oplost met een upgrade knop, een periodieke call home, of een andere oplossing: als jij in charge bent wat er op dat doosje draait dan kan jij in potentie alles op dat netwerk. Als mensen jou niet hier mee vertrouwen dat moeten ze jouw doosje maar in een eigen isolated netwerk stoppen.

Verder moet je natuurlijk wel goed je server kant firewallen zodat klanten die je doosje hacken niet zomaar via de tunnel op jouw server/netwerk kunnen komen.

[bucovaina89]

MAX3400 schreef op dinsdag 13 september 2022 @ 14:04:
[...]

En wie zegt dat je niet nu al gehackt bent ...

Ik heb nog geen servers

[bucovaina89]

Maar ik heb er nog eens verder over nagedacht. Ik vermoed dat ik wat onderschat heb wat een verantwoordelijkheid dat is, en dat onderhoud daaraan eigenlijk permanent is. En wil je dat ...

[fastedje]

bucovaina89 schreef op dinsdag 13 september 2022 @ 13:22:
@fastedje : dat moet ik eens bekijken hoe ik dat mooi kan doen, ik vermoed dat dat een remote SSH-tunnel heet dan? Dat lijkt me dan nog het mooiste. Geen poort open zetten en enkel op vraag van klant. De klant duwt op een knopje en ~20min wordt er een reverse SSH tunnel opgezet met SSH-keys. Als er dan niets gebeurt, gaat die automatisch weer afgesloten worden. Dat zou dan ook voorkomen dat als mijn servers gehackt worden (waar dan aan Ansible Repo op zou kunnen staan) dat dat zomaar verder zou kunnen lopen naar alle klanten (sort of painful).

Je ssh key moet je sowieso encrypten en verder kan je de key het beste in een ssh-agent opslaan, Deze agent kan je met een timeout automatisch kunnen afsluiten.

Een reverse tunnel zet je op vanaf het systeem dat je wilt beheren naar een van je servers. De reverse tunnel luistert op een poort op een van je eigen servers en 'tunnelt" deze over ssh naar de remote te beheren machine:

code:

ssh -R 30022:localhost:22 tunneluser@myaccessserver

Ansible is prima geschikt in combinatie te gebruiken met ssh. Ik denk wel dat je dat een .ssh/config file moet genereren zodat je de locale poorten (30022, waarbij je de eerste digits variëert) maakt op de remote ssh hostname.

[fastedje]

MAX3400 schreef op dinsdag 13 september 2022 @ 14:04:
[...]

En wie zegt dat je niet nu al gehackt bent en dat de payload langzaam maar zeker bij jouw klanten terecht gaat komen?

Als je je al zorgen maakt over dat "jouw servers" gehackt worden, dan zou ik als klant eigenlijk helemaal wel willen weten of je geschikt bent voor de job?

Wat echt helpt is:
- Installeer security updates.
- zet password access dicht voor sshd (oo je eigen servers en de remote systemen.
-Zet alleen sshd poort open op je firewall, bij voorkeur op een niet standaard poort.
-installeer fal2ban of een dergelijk intrusion dectection/prevention.

[Jan-man]

Als het om zakelijke klanten gaat waarom dan geen rmm oplossing ? Laat ze x bedrag per maand per pc betalen kun je direct de AntiVirus netjes regelen. Heb je remote beheer (of niet). Kan je vanalles op de achtergrond regelen ed.

En mooiste geen gedoe met vpn waarbij de klant eerst nog iets moet doen om toegang te krijgen. Via rmm (solarwinds) is het gewoon van hey klik even op akkoord bij de melding die je nu op je scherm krijgt en je kan meekijken bijvoorbeeld.

[amx]

is het nog wel een appliance als je remote beheer moet doen? Een dergelijk apparaat wil je denk ik alleen updates sturen en de klant de kans geven diagnostics op te vragen om zo nodig door te sturen of het zelf op te lossen. Als je moet troubleshooten, kun je je dan afvragen heb ik het simpel genoeg ontworpen?

[bucovaina89]

Mja idd. Met appliance bedoelde ik een zo kaal mogelijke debian install met enkel de pakketten op die ik nodig heb. Maar dat is idd al geen appliance meer.

[locke960]

bucovaina89 schreef op maandag 12 september 2022 @ 20:37:
klanten thuis

Ik proef hier een beetje een tegenstelling.

Klanten. Iemand die betaald. Altijd goed om te hebben.
thuis. ehh? niet zakelijke klanten? Dat lijkt me geen markt waarvan je vet wordt. En dan investeren in hardware en systemen om remote te kunnen supporten.

Ik vraag me af of dat zin heeft. Het hangt natuurlijk volledig van de business case af, maar op het eerste gezicht klinkt het niet echt winstgevend. Je moet hardware en software beheren, regelmatig hardware vervangen, het veilig houden, regelmatig proberen of het nog wel werkt want het moet natuurlijk wel werken op het moment dat je het nodig hebt, enz, enze

Ik vraag me dan ook af wat voor bijzonders je doet wat je niet ook via Teamviewer oid kan doen.

[DutchKel]

Als je iets bij klanten neerzet qua apparatuur die ook nog eens via internet communiceert (eventueel met jou eigen server). Houd er dan rekening mee dat als het mis gaat en er komt een virus of iets anders vervelends bij de klant dat het wel eens kostbaar kon worden om het op te lossen.

Mogelijk dien je hier nog een extra verzekering voor af te sluiten om je in te dekken.

[MartinMeijerink]

MAX3400 schreef op maandag 12 september 2022 @ 20:58:
Hoe kom je erbij / erin op een veilige manier? SSD-keypairs configureren (en natuurlijk je SSH-port veranderen etc).

'Veilig' én 'SSH-port veranderen' in één zin... Dat klinkt een beetje als security through obscurity Je SSH-port veranderen maakt het in ieder geval echt niet veiliger. In mijn geval echter (ik heb ook verspreid door NL wat PC's neergezet, en sinds 2 jaar geleden ook RPi's), laat ik ze via SSH over poort 443 naar de server een tunneltje opzetten, om de reden dat klanten nogal eens uitgaand verkeer dichtgetimmerd hebben, vaak met uitzondering van poort 80/443. En op deze manier hoeven we al niet eens meer naar de klant toe, we sturen ze een geprepareerde RPi op, met de mededeling deze in het netwerk te hangen, de rest gaat (voor hun) dan vanzelf.

[bucovaina89]

locke960 schreef op dinsdag 13 september 2022 @ 20:39:
[...]

Ik vraag me dan ook af wat voor bijzonders je doet wat je niet ook via Teamviewer oid kan doen.

Heel erg weinig om eerlijk te zijn, maar dat maakt ook dat TeamViewer niet kan . Een web servertje draaien/database draaien en wat communicatie met randapparatuur. Maar ook niet meer dan dat. Geen desktop omgeving noch X/Wayland geïnstalleerd wegens niet nodig/wenselijk.

En Los daarvan, waarom TeamViewer als het simpelweg met SSH kan ?

Maar ik denk dat ik alles wat errond komt kijken wat onderschat heb hoor. Gewoon al verzekering moeten afsluiten, stel dat ik "prul" bij een ander veroorzaak (waar ik me best wel bewust van ben dat dat perfect mogelijk is), ... Had ik niet bij stil gestaan.

[init6]

bucovaina89 schreef op maandag 12 september 2022 @ 20:37:
Ik ben met een "wild" idee bezig waarbij ik een mini Linux/Debian bakje (RPI compute module of aanverwante) bij klanten thuis zou willen zetten maar wel nog de mogelijkheid tot remote onderhoud zou willen behouden. Hoe pak je dat beste aan en wat schaalt er relatief goed?

Enige wat ik me nu kan bedenken is een WireGuard VPN installeren, port forwarden en credentials bij houden. Dan "phonet" dat ding niet home (ik zou het zelf als klant niet graag hebben) maar "bel" je in als het wenselijk is.

Maar dan zit ik met het probleem: wat is het IP van de klant? Zou je dan een DDNS dienst gebruiken? Maar dan moet zo'n appliance toch "phone home" doen? Of een LCD op de RPI behuizing zetten die het publieke IP laat zien, klant opbellen, vragen naar het publieke IP, en dan kan ik een VPN aanleggen.

Maar het klinkt me allemaal wat DIY, er zijn waarschijnlijk betere oplossingen.

Gebruik een Git repo waar de appliance zijn code van kan downloaden en voer de scripts lokaal uit?

[Andre_J]

Omdat je het over een Rpi hebt, kijk eens naar Ubuntu Core.
Die is speciaal hiervoor ontwikkeld.
Veilig updaten, remote support, LTS versie.
Je moet natuurlijk wel van de werkwijze van Canonical houden.

[i-chat]

ik heb even door dit topic gescrold en er vallen mij een aantal dingen ontzettend op.

Ten eerste... geef je in de Topic start eigenlijk helemaal niet zo heel veel duidelijke aanwijzingen wat nu precies het plan is, en wat je denkt te bereiken. Dat maakt het voor de wat professionelere tweakers toch wel heel lastig om goede tips te geven. 'wij' kunnen immers alleen maar antwoord geven op de vragen die je stelt aan de hand van de informatie die je geeft. Stel jij de verkeerde vraag, of laat je belangrijke context weg, dan geven 'wij' verkeerde antwoorden.

--- enkele vragen die misschien zouden kunnen helpen om je richting een beter (implementeerbaar) plan te helpen.

1: je hebt het over een raspberry pie, : wat moet die precies gaan doen, moet het 1 enkele app server of service draaien, of is het meer de bedoeling dat het een soort low-power desktop idee wordt.

2: je wilt op afstand kunnen besturen, of beheren of.... - maar wat wil je nu precies kunnen doen, gaat het alleen om updates, gaat het om troubelshooten of gaat het om volwaardige techsupport via remote desktop.. voor elke van deze 3 functies bestaat namelijk totaal verschillende software... respectievelijk zou ik denken aan: ansible, SSHd of bijvoorbeeld Apache Guacamole...

3: Dan is er natuurlijk altijd nog de vraag over de hardware, van SBC-tjes zoals de raspberry pi's is bekend dat ze nogal eens stuk gaan of dat ze hun sdkaartje opvreten, deels is dat op te lossen door bijvoorbeeld geen sdkaart te gebruiken maar een USB-stick. maar dat brengt (deels) weer met zich mee dat er extra usbsticks in het ding zitten ... en die kunnen ook weer kapot. dan kun je al snel de vraag stellen hoe handig het is om bepaalde hardware in te zetten, in plaats van bijvoorbeeld het meest zuinige (en goedkope) intel nuc setje. het verbruiksverschil tussen een intel celeron essential 7 (cel 4005 4gb ram) nuc kit (€200) en een raspberry pi 4 4gb kit (€80) is maar zo'n 15watt bij gebruik (nadeel intel). maar het prestatieverschil onder andere op een linux dekstop is enorm. (voordeel intel) - vooral als je hardware voor de langere duur bij klanten?? wilt plaatsen is betroubaarheid ECHT een ding.


conclusie: als dit een soort zorgeloos pc bij u thuis project moet worden dan is het plaatsen van betrouwbare hardware ontzettend belangrijk... maar ook de integratie met andere systemen, begin je gedachten eens te laten lopen bij een contraal gehoste configuriratie/update server. bouw op basis van bekende technologiën eerst eens een proef-netwerk. kies voor betrouwbare hardware (desnoods 2e hands thin clients uit de zakelijke hoek)..

als je verbindingen op wilt zetten voor support doelen .. maak je dan niet druk om het IP van de client, maar kies voor een technologie waarin zij verbinden met jouw publieke server... bijvoorbeeld via helpdeks.jouwdomijn.nl maar ook voor updates.jouwdomijn.nl dat betekend natuurlijk wel dat je ook moet investeren in een publiek toegankelijke server - maar er zijn meer dan genoeg relatief ontzettend goedkope cloud services providers of vps-hosters die zoiets prima in de lucht kunnen houden. de kosten daarvan zullen bij enkele tientalle klanten al in het niets vallen ten opzichte van je andere kostenposten.