De kern van het probleem: vanaf internet bereikbaar.

Wat ik verbazingwekkend vind is dat er nog zoveel systemen zijn die niet achter een (NAT) router c.q. firewall zitten. Ik durf zelfs te beweren dat dit geen thuis systemen zijn want wie gaat er bewust UDP port 631 open zetten om vanaf het internet printopdrachten te versturen?

Ik heb bijna een dagtaak aan al die organisaties blokkeren. Duizenden subnets.

Het zijn ongetwijfeld 1€ hosting oplossingen (wordpress bv) waarvan de beheerder te lui is of de kennis ontbreekt om een cups service uit te zetten. Ze kunnen wel een kwetsbare cups versie detecteren maar ik denk niet dat deze uit te buiten is want default staat cups-browsed service uit. Aan de andere kant wie, zet er nu bewust port 631 open (dan zal alles wel open staan, firewall uit). Wat een domme mensen heb je toch.

Mijn CUPS zit achter de firewall... Maar ik kan me gevallen voorstellen waarbij toegang tot de printer vanaf een extern netwerk gewenst is. Medewerker heeft app om xxx-bon te printen, maar niet altijd toegang tot wifi, vestiging A kan opdrachtbonnen maken voor vestiging B, etc. (Dit hoor je natuurlijk met een VPN op te lossen...)

Oudere routers die standaard UPnP hebben aan staan?

Waarschijnlijk zijn een hoog percentage van deze 2500 systemen honeypots.

Zou mij niets verbazen dat veel systemen gewoon een VPS zijn. Met publiek IP address. Ik ken mensen welke Minecraft servers hebben draaien op Linux, die installeren maar wat omdat dat handig lijkt.

Maar CUPS bewust open zetten naar buiten toe. Dat is zelfde als RDP, SSH, SMB, LDAP naar buiten open zetten. Vragen om problemen.

Die zullen er ongetwijfeld zijn die dat wel doen. handig onderweg even een document printen naar huis.

Ssh is niet vragen om problemen.

Onhandig en niet doen. Er zijn beterschap oplossingen.

Mooi hoor Shadowserver Foundation. Maar hebben jullie alle 2000 Nederlandse bedrijven dan al gebeld of gemaild ? En als ze niet antwoorden dan dus via de autoriteiten eea duidelijk gemaakt?

Toch ik zou niet snel direct SSH aan het internet hangen.
Op z'n minst een andere poort pakken (evt. icm. knocking protocol, en iig icm firewall ALLOW rules), maar beter is deze enkel toegankelijk te maken via VPN.

Ik heb we een eens tijdje bewust een SSH honeypot aan het internet gehangen, en dan scannen wat erop gebeurt. Maar er vinden non-stop scans en brute-forces op plaats. Het is natuurlijk wachten totdat er een CVE naar buiten komt waar je net iets te laat mee bent om te patchen. Gevalletje 'voorkomen is beter dan genezen'.

Tja SSH is ook zo iets fijns... ik heb ergens noodgedwongen een SSH server draaien omdat er een beheerder op moet
kunnen inloggen die geen vast IP heeft. SSH staat ingesteld op "alleen public key logins", er draait fail2ban, maar toch
duizenden password login pogingen per dag. Die uiteraard allemaal fout gaan. En omdat men niet vanaf 1 IP allerlei
passwords probeert maar dat cyclisch via allerlei IPs doet komt fail2ban ook niet vaak in actie.
Je zou willen dat er een config was waarin alle connects zonder public key gewoon silent geweigerd worden met
doorlopen van zo weinig mogelijk code. Dan is het risico op vulnerabilities hopelijk minder.

Cups zelf doet niet aan upnp...

Ikbvermoed dat het systemen zijn waarbij een workstation distributie als server gebruikt wordtbomdat veel mensen zonder muisbediening radeloos worden.
Of die alles maar instaleren omdat ze anders moeten nadenken over wat er explciet welbop te zetten.
En dan in VPS uitvoering.

met ipset de netwerk subnetten van provider van ITer whitelisten voor ssh. je kunt ook alleen NL toelaten: http://www.ipdeny.com

Het hangt van de mogelijkheden bij de gebruikte apparatuur af, maar
je kunt in de firewall van de router ook wel een hostname opgeven
in de adressenlijst. Ik weet dat zoiets kan bij Mikrotik apparatuur.

Vervolgens configureer je in de firewall bij de betreffende SSH
regel als voorwaarde het dynamische DNS (sub)adres. Ofwel: IP
whitelisting op basis van (DynDNS) hostname.

Zodra uw beheerder zijn eigen dynamische ISP internetadres bijwerkt
naar de eerder geconfigureerde DynDNS hostnaam, dan krijgt hij
daarmee toegang; niet de gehele wereld.

Het dynamisch bijwerken van de hostname kan bijvoorbeeld met een
script (curl of wget) al dan niet in combinatie met een token
voor de authentificatie bij de DNS dienst. Je kunt de Time To Live
(TTL) van de DynDNS vaak ook meegeven bij zo'n dienst en de router
zal na afloop van de TTL de DynDNS hostnaam opnieuw resolven en het
actueel dynamische IP-adres van uw beheerder overnemen.

De SSH regel in de firewall kan ook worden aangevuld met voorwaarden
voor dag en tijd. Bijvoorbeeld de regel is alleen geldig/actief op
Ma-Vr van 07:00-19:00. Uiteraard is dat afhankelijk van de
werktijden van de beheerder, maar het verkleint de 'scope' jaarlijks
met 6.160 uur (24h*365d -/- 5d*10h*52w).

+++

Een andere techniek is 'Port Knocking'; zoek er maar eens op als u
het niet kent.

Ik kan me van zeker 10 jaar geleden herinneren dat een amerikaanse universiteit een hele webpagina had voor zijn studenten met uitleg hoe ze hun PC moesten instellen om op vanuit het internet op de universiteitsprinter te kunnen printen.

Ik heb me toen wel verbaast dat ze iets willen printen als ze niet in de buurt van de printer staan. Maar de standaard printerdriver op mijn PC heeft ook al de optie om bij elke printopdracht een voorblad mee te printen waarop staat voor wie de print bedoeld is. Blijkbaar is er toch behoefte aan bij grote instellingen om iets te printen als je niet in de buurt van de printer bent.

We zijn nu wel heel wat jaren verder en papierlozer geworden. Veel van die printouts zijn door pdf-jes vervangen.

Dat zou kunnen, maar meestal zit er op VPS'en (zeker de low-budget exemplaren) altijd wel een firewall.
Je moet zelf in het admin panel "poorten open zetten". Is al irritant genoeg omdat het meestal alleen voor TCP en UDP kan.
Standaard staat alles dicht of alleen een klein setje zoals 22,80,443 staat standaard open, de rest moet je zelf doen.

Ja leuk al die ideeen (ook van andere reageerder) maar in een zakelijke omgeving met meerdere partijen kun je zo
iets moeilijk goed krijgen. Ik kan niet bij de websitebeheerder aankomen met "ja ik kan het wel openzetten voor Ziggo IP's
maar als je even snel iets op je telefoon moet doen evt in het buitenland dan moet je me eerst even bellen".

Op mijn eigen systemen heb ik uiteraard WEL dat soort maatregelen in gebruik.
Waar ik naar vroeg (of hintte) was een SSH met een kleiner aanvalsoppervlak. Dus een waar password logins niet alleen
in de config uit staan, maar die dat gewoon niet KAN. En connecties die niet met pubkey werken zo snel mogelijk disconnect,
en dus bijvoorbeeld ook niet kijkt of de geprobeerde user bestaat op het systeem (doet sshd nu wel).
Want dat is allemaal weer uitgevoerde code waar bugs in zouden kunnen zitten!

Waarom zou je het voor de hele wereld openzetten? Ook op basis van IP openzetten is weer een drempel plus fail2ban gebruiken en wachtwoorden en root toegang niet toestaan. Blijft over een crtical cve inderdaad maar dat moet je inderdaad goed monitoren om direct te kunnen handelen. Gelukkig is SSH geen RDP. Volgens Redhat is er in 2018 voor het laatst een kritieke cve's geweest: https://access.redhat.com/security/security-updates/cve?q=ssh&p=1&sort=cve_threatSeverity+asc,allTitle+asc&rows=10&documentKind=Cve

"Vanuit Internet" was (en misschien is) op universiteiten ook "de campus" of als je ernaast staat.

Historisch gezien hebben Universiteiten (al) heel grote IP prefixen gehad, en waren gewoon alle werkplekken en netwerken voorzien van een publiek IP , en , destijds, ook gewoon wereldwijd bereikbaar.

Uit een uitleg dat de printer in campus zaal C via 145.68.72.10 bereikbaar is kun je - in die tijd en setting - niet opmaken dat dat alleen bedoeld is voor mensen heel ver weg .

Degene die ernaast staat (of in de practicum zaal op de gang ) gebruikt ook dat IP .


Amerikaanse universiteiten hebben echt het campus model - studenten wonen/leven in 'student dormitories' op de terreinen van de universiteit.
Dan is het nog logischer om je werkstuk waar je ongeveer mee klaar vanuit je dorm te printen op één van de printers in een centrale afdruk faciliteit, en dan even te gaan ophalen.
Of ook als je er wel bij in de buurt zit - bibliotheek, practicum zaal, noem maar op - dan stel je nog steeds op dezelfde manier die printer in

Een deel wel. Ik moet zeggen dat voor grondig lezen/reviewen ik papier prettiger vind dan een scherm.

Inderdaad, dat soort creatieve dingen is typisch een hobby-bob , of MKB omgeving.
Het schaalt niet .

Ik moet wel zeggen - _als_ je in zo'n kleinere omgeving zit moet je het vooral doen . De logruis beperken - zodat je beter kunt kijken op resterende pogingen - is de moeite waard.



Daar ken ik geen voorbeeld van , een minimale ssh daemon .
Afgezien van config strak trekken, en fors aan de slag met selinux (of andere LSM) om de dingen die een bug zou kunnen bereiken te beperken.
De andere standaard manier is natuurlijk een VPN server ervoor zetten , en dan geloven dat het aanvalsoppervlak van de ipsec/openvpn/whatever service kleiner is dan dat van ssh .

Ik ben privé om die reden ooit van fail2ban afgestapt en ben fwknop gaan gebruiken: een port knocking-oplossing die versleuteld en non-replayable is¹. Het is alweer heel wat jaren en twee verhuizingen geleden dat ik dat een aantal jaar lang gebruikte, en dat werkte feilloos. Of dat lekker schaalt naar veel mensen die via SSH werken daar zet ik mijn vraagtekens bij, afgaande op wat ik me vagelijk herinner over de configuratie, maar met één beheerder die zo toegang moet krijgen, of enkele, moet dat geen probleem zijn.

Sshd simpelweg op een hoog poortnummer zetten zal ook al enorm schelen. Daarmee houd je gerichte aanvallers die volledige portscans gaan draaien niet voor de gek, maar wel al die aanvallen die simpelweg op eindeloos veel IP-adressen kijken of ze een open SSH-poort tegenkomen.

Ik denk dat het mijn voorkeur heeft als die dingen wel gelogd worden maar je de meldingen niet ziet omdat aanvallers de poort niet kunnen benaderen. Mocht zich namelijk een keer een zero-day lek voordoen in sshd dan kan die extra hobbel net het verschil maken.

¹ https://www.cipherdyne.org/fwknop/

onzin. het gebruik van jumphosts [die restricted access bieden op basis van firewall rules] voor ssh is niet nieuw in de echte zakelijke wereld. jumphost kan ook nog eens via shell over https met MFA/x509 toegang bieden. poort 22 hoeft niet voor de hele wereld op te staan op elke machine van je 'klant'. heb je overzicht en control onaf wat 'klanten' op hun VPSen aan prutsen/klungelen in je netwerk.

Het voortdurend "access" moeten hebben, is de grond van dit alles.

Is het hier en daar al geblokkeerd, staat het op andere plekken nog open.

ha, de vrijwilliger voor de nachtdienst-op-kantoor, waar vind je die anders nog ?

Een VPN op OSI netwerklaag wil je helemaal niet hebben. IK zou zeggen alleen SSH of HTTPS (cockpit port 9090)

En wie ben jij om dat aan te bevelen ?

Heel misschien heb je een punt (ik denk het niet) , maar alleen maar anoniem die stelt dat er iets mis met een VPN op de OSI netwerklaag betekent helemaal NIETS.

Het betekent nog minder omdat je duidelijk het hele probleem (zie de vraag van 5 oct 11:30 waar ik op reageerde) niet gelezen of niet begrepen hebt.

5 okt 11:30 wilde "kleiner aanvalsoppervlag dan gewoon sshd" . Jij "sshd" . Ik snap ook niet waarom in een discussie over 'klein aanvalsoppervlak" iemand dan "HTTPS" durft in te brengen. Dat is , in de gebruikelijke implementatie een gigantische bak rete complexe code , met een serie aan historische protocol en implementatie bugs.

Doe nog eens een uitgewerkt voorstel en uitleg _waarom_ jij iets "zou zeggen" , en op welke manier je rekening houdt met 'zo klein mogelijk aanvalsoppervlak in sshd' .

voor al die sjefjes hierboven die stoere taal doen a la 'dat schaalt niet' en 'zakelijke omgeving' [en whatever dat dan nu weer precies is, en hoe groot het dan is vwb die schaling, daar kom je ook nooit echt achter he :P]

https://www.ssh.com/products/privileged-access-management-privx
https://goteleport.com/blog/ssh-jump-server/
https://guacamole.apache.org/
https://www.jumpserver.org/index-en.html

blijf maar lekker volhouden dat s/het/JIJ het/ niet kan :).

(dit is tevens een antwoord naar de anderen die oplossingen zoals een VPN suggereren)
Het is een situatie waarbij een bedrijfs webserver, die draait in een VPS bij een hoster geheel los van de rest van de infra,
beheerd wordt door iemand wiens specialiteit, laten we het neutraal zeggen, meer het grafisch ontwerp dan de IT is.
De website is uiteraard met wordpress gemaakt (dat verwacht je...) en wordt grotendeels via de admin interface daarvan
beheerd, maar soms is er shell toegang nodig op de user die eigenaar is van de site bestanden.
Ik kan die persoon moeilijk dwingen door nog meer hoepels te gaan springen dan die nu al doet, hij is kennelijk totaal niet gewend om te kijken naar security en komt soms al in de war door de situatie dat de eigenaar van de bestanden niet dezelfde is als de user waaronder de webserver draait, en de webserver dus niet kan schrijven in directories van de site...
(ik zou zeggen dat is stap 1 in je beveiliging maar dat is bij de gemiddelde website/webshop beheerder allemaal onbekend. daarom worden ze ook zovaak "gehacked" denk ik)

M.a.w. het moet allemaal simpel blijven en niet afhankelijk van beheerder actie op het moment van toegang.
Ik had gehoopt dat er mogelijkheden waren om OpenSSHD te "hardenen" maar helaas dus.
Met name het feit dat bij een geprobeerde password login (terwijl PasswordAuthentication no in de config staat)
er een verschillende logregel is voor pogingen voor users die wel of niet in de passwd file staan is natuurijk SLECHT.
Dat betekent dat sshd dit gechecked heeft, via PAM neem ik aan. M.a.w. er is PAM code aangeroepen in een situatie
waarin dat overbodig is. En dat in een security-sensitive service.
Dat de geprobeerde user ueberhaupt gelogd wordt is al een risico! User-supplied data in de log. Laten we hopen dat
het in ieder geval ontdaan is van allerlei controlcharacters en UTF codes.

probeer er eens zonder emotie logisch naar de informatie elementen te kijken. je reactie van 'ongeloof' is voor mij eerder een teken van onbegrip dan van een sterk onderlegd betoog.

dan kijk gerust in meer detail naar PrivX van ssh.com en wat een jump host / bastion host kan doen voor je klanten. beloof je me dan eerst eens een dagje te kijken en denken hierover voordat je weer reageert vol ongeloof alsof de goedbedoelde adviezen onzin zijn?

lees je dan ook eens in in teleport aub.

https://goteleport.com/how-it-works/

Het voordeel van _die_ situatie is - een breach hoeft dan helemaal geen grote ramp te zijn.

Richt je aandacht op backup van de content, en activiteits monitoring - en als het eens misgegaan mocht zijn met een zero-day ssh ding, wipe , re-install , recover .

Zo te horen (stand alone VPS 'buiten') hoef je je totaal geen zorgen te maken over verdere intrusie , 'lateral movement' etc , en is het alleen maar genant als de bedrijfs-site ge-defaced zou zijn .

Ha ha, hier moest ik om lachen. SSH wil je echt wel naar buiten open hebben staan. Hoe moet je anders je VPS netjes beheren? Natuurlijk wel even goed configureren en ww-auth uitzetten en alleen sterke keys accepteren. Verder een fail2ban op spanning brengen en wat helpt om je logs schoon te houden is een exotisch portje gebruiken.

Ik weet niet waar ik dit verwijt aan te danken heb, maar mijn vraag is "kun je OpenSSH hardenen in de zin dat het aanvalsoppervlak verkleind wordt door inkomende connecties die niet aan de config voldoen zo snel mogelijk te rejecten, gegeven de situatie dat een SSH server met pubkey login functioneel nodig is".
Allerlei zijpaden daar had ik niet om gevraagd dus als je dan die adviezen geeft dan moet je niet raar kijken als die genegeerd worden.

Er zijn - zoals gebruikelijk op fora - een hoop slechte lezers die na de eerste alinea met hun stokpaardje aan komen zetten ook al voldoet tot totaal niet aan je vraag.
En daarbij ook niet uitleggen je eisen niet relevant zijn of de voordelen van hun idee groter zijn dan het niet voldoen aan jouw eis;
Je kunt best een niet-gevraagde 'andere oplossing' aandragen, maar het is respectvol om dan te bespreken _waarom of wanneer_ dat toch beter is dan precies waar de vragensteller om vraagt. Het laat tenminste zien dat iemand het probleem snapt en _dan_ alsnog een alternatief voorstelt, en hoe dat beter is dan de oorspronkelijke wens.
Het bewijst ook dat de voorsteller misschien wel weet waar ie over praat, en niet alleen een fanboy is van een project wat niet het antwoord is op de concrete vraag . (ook al is het voor andere situaties misschien wel erg prima).

Een setje linken dumpen die allemaal _niet_ of zelfs het tegenovergestelde zijn van een 'hardened minimale sshd' - alle kenmerken van mensen die de vraag en reden niet snappen (en waarschijnlijk niet gelezen hebben), maar een drang tot posten hebben.

Ik ben een andere poster dan jij - en ik heb met gestrekt been een paar van de "adviezen" die jouw concrete vraag negeren maar er wel op reageren wat repliek gegeven . Ik denk dat een paar van de jumphost-url posters jouw en mijn postings door elkaar halen.
M.i. duidelijk genoeg voor wie een posting tot het eind kan lezen, maar dat is niet iedereen.

er zijn ook mensen die lezen wel, die inzien dat het gevraagde niet letterlijk kan en je dus een alternatieve [vaak betere] oplossing bieden [die wel degelijk in de 'zakelijke omgeving' gebruikt worden en 'schalen'] maar ja er zijn dan ook weer net zo goed mensen die dat dan niet snappen maar wel heel erg de drang hebben om dan toch [niet zo constructief] te posten.... doe er mee wat je wilt maar :).

heel goed bedoeld advies: kijk naar privX en of teleport en echt waar, jump hosts worden heel veel gebruikt [ook op schaal en in de zakelijke wereld] om precies datgene te bereiken waar de originele poster nu juist om vroeg...

En iets als Tailscale / Headscale? Hoeft er geen enkele poort meer open...

Mooi verhaal, maar die mensen zijn - als ze niks toelichten - totaal niet te onderscheiden van de genoemde fanboys die alleen hun hamer kennen en dus elke vraag als een spijker zien.
En ik stel dat mijn postings wel degelijk _ook_ constructief zijn - namelijk toelichten op welke manier dergelijke opties mismatchen met de vraag .

Om nog maar 's een olifant in de kamer te benoemen : 'enterprise gebruikt' wil niet zeggen "maximaal veilig" , het wil meestal zeggen "heeft veel functies die grootschalig gebruik mogelijk maken" . En , hopelijk , een solide implementatie.

Jammer maar helaas - sommige keuzes die erg veel veiligheid bieden schalen totaal niet .
Een whitelist packet filter dat netwerk toegang beperkt tot 3 vaste IP adressen van 3 beheerders _is_ een heel erg goede veiligheids maatregel.
Beter dan 500 MB code die een waanzinnig complex protocol (TLS) implementeert met een backend database koppeling om 3000 certificaten user-certificaten te beheren. Maar dat schaalt wel, en persoonlijke whitelisting niet.

In crypto land - de meest theoretisch perfecte oplossing (one time pad) heeft waanzinnig veel nadelen in gebruik.
Next best thing - symmetrische encryptie - heeft ook enorm ongemak met sleutelbeheer _op schaal_ en dus "doen we het" met public key encryptie erbij waarvan de wiskundige veiligheid elke decennium een sprongetje omlaag maakt, de implementatie een grote serie valkuilen heeft achtergelaten en de performance is ook naadje .
_Alleen_ de gebruikseigenschappen die public key encryptie kan bieden zijn zo overweldigend dat het om die reden een standaard component is in bijna ieder gebruik van cryptografie.


Een willekeurige enkele sshd server _is_ een (vorm van) een jumphost .

Wat die originele poster vroeg was (wil dat nou nog niet indalen ?) in zekere zin _beter_ dan dat , namelijk een meer-secure-dan-normaal sshd .
Het is misschien een kleine zorg in de situatie van sshd, maar zijn punt dat je wilt/verwacht dat code paden die niet gebruikt worden ook helemaal niet doorlopen worden _is_ terecht.
Elk code pad dat doorlopen wordt is een extra risico dat een bug erin ook bereikbaar/exploitable is.

Dat inzicht is al ongeveer drie decennia doorgesijpeld (na veel schade en schande) bij een hoop bekende Internet services.

sendmail was het klassieke voorbeeld van één brok code dat "alles" deed - mail aanpakken, adressen rewriten, mail bij de gebruiker afleveren, mail verzenden etc etc. De toenmalige 'nieuwe generatie' - qmail, postfix splitste al die functies op in aparte daemons die via strak gedefinieerde APIs met elkaar praten .
Idem voor bind (DNS)- authoritief, recursion, dynamic updates, alles in een. De nieuwe generaties DNS software zijn wel aparte programma's (nsd/unbound , powerdns/powerdns recursor etc) voor verschillende functies.

En dan vraagt iemand - vanuit dezelfde filosofie - kan ik een sshd krijgen die geen password-code-pad ingaat als ik dat uitgezet heb, en ben ik blijkbaar de enige die snapt waarom (/dat) iemand dat vraagt, en heb je mensen die gewoon roepen dat ie beter af met de ene of de andere full-featured jumphost oplossing. Z'n hele vraag was nu juist NIET full-featured maar 'minimaal featured'.
Echt - laat 's zien dat je een vraag en achtergrond snapt voordat je een totaal andere oplossing aanbeveelt . Het geeft een beetje vertrouwen dat je aanbeveling ook wat waard is.
Bedenk dat - in tegenstelling tot waarschijnlijk je (werk/studie) situatie - je hier als anoniem _geen_ historische reputatie, functietitel, of bewezen kwaliteit hebt. Je staat of valt alleen met wat je schrijft - en niet schrijft.

joh... seriously? omdat iets sshd draait is het een jumphost?

hier speciaal voor jou dan:

https://en.wikipedia.org/wiki/Jump_server

"A jump server, jump host or jump box is a system on a network used to access and manage devices in a separate security zone. A jump server is a hardened and monitored device that spans two dissimilar security zones and provides a controlled means of access between them. The most common example is managing a host in a DMZ from trusted networks or computers. "

Tuurlijk hoor. Als je het niet snapt pak je een woordenboek.

Het limietgeval met n=1 , dan is de enkele server ook 'de' jumphost.
Zeker wanneer "de" server toch al internet-facing moet zijn (zoals de genoemde webhost).

tuurlijk een schaalbare zakelijke oplossing perse willen voor maar een server...