Da's leuk, dan heb je een onzettende beveiligde VPS server en ga je onderuit als er een DDOS aanval uitgevoerd wordt op je VPS server. Wat jij wilt, wilt iedereen. iedereen is op zoek naar het veilige, begin door je website alleen maar html te maken ipv php. Dat maakt het al een stuk veiliger. Veilig VPS server is een illusie, men kan heel ver gaan, maar uiteindelijk is veel en veel kwetsbaar als er een backdoor ontdekt wordt en er een exploit voor komt.

Niks is perfect en veel hangt af van wie wat waar toegang moet hebben alsmede wat voor services en data je exact wilt aanleveren. Er is geen template die je even kan uitrollen daarvoor je kan ervan af beginnen maar finetunen en hardening blijf je de hele levensduur van de servers doen. Je kunt niet web applicaties buiten dit plaatje houden omdat je dan weer veiligheid van extra modules mogelijk overslaat die dus ook impact hebben op de vectors naar de server. SOAP nodig voor je service wel weer een nieuw risico erbij waar je rekening moet houden. Meerde versies nodig van een library wel dan ook meer zaken om bij te houden.

Kortom je moet gewoon eens rustig gaan zitten en alles uittekenen in een blauwdruk en overleggen met je leveranciers en waar mogelijk hun best practices toepassen en waar niet mogelijk moet je iedergeval de risicos in kaart hebben waar je wel voor gevoelig blijft want die zijn er altijd. Voorbeeld wij hebben hele strenge regels qua modsec maar dat zorgt ook voor vertraging van acties en als je dus maar groot genoeg een aanval krijgt dan zit je met resource tekort dus je moet opschaling gereed hebben. Alternatief is versoepelen van modsec beleid maar dat brengt weer andere risicos met zich mee.

Het is verder niet verstandig om opties open te houden als je dat kan voorkomen. Stel je wilt nu geen mailserver maar straks wel dan kun je dit hele proces van grond op opnieuw doen het is dus vele malen verstandiger om iets langer na te denken of je het wel of niet wilt. Als je het niet nodig denkt te hebben in komende 5 jaar dan installeer het niet. Als je dat wel denkt dan prepareer de omgeving en zet de functie voor zolang je het niet nodig hebt op uit.

Zonder zeer veel informatie hier te overleggen ga je geen productie waardige omgeving krijgen die niet meer dan voor hobby doeleinde geschikt is en zeker niet als het op maatwerk aan komt daar zit ook geld in.

Als laatste iets is ook niet per definitie veilig als het niet aan internet zit verbonden maar de risicos hangen heel erg af van hoe waardevol die omgeving is voor hackers. Je kan als netwerkbeheerder nooit dat niet meenemen in je risico analyse al kun je wel heel vaak beargumenteren waarom je het een acceptabel risico vindt.

Als hobbyist vroeg ik gewoon.
Resultaat is een hele lap tekst die niet eens in gaat op mijn vraag...

EDIT: snipped my own negativity.
Al die negativiteit, wat een teleurstelling!
ik had ten minste nog wel verwacht dat er iemand zoiets als HSTS zou roepen of zo... :-(

Trouwens, Anoniem van 10:27, reden dat ik VPS zij is dat ik uitging dat de hosting een DDoS filter heeft.
Anders had ik wel gezegd een thuis gehoste server te gebruiken. ;)

Persoonlijk ben ik gecharmeerd van een FreeBSD bak waar apache/nginx in een jail met eigen IP-adres(sen) draait.
SSH-toegang (naar de host) via firewall beperken tot je eigen IP-adres, met als reserve misschien een paar adressen van goede en betrouwbare kennissen. Dit lukt natuurlijk alleen met vaste IP's.
Zorg ervoor dat je updates z.s.m. installeert!

Je vraagt iets dat niet helemaal kan. Niks is 100% veilig, maar stel de vraag dan anders "Hoe kan ik het beste een webserver beveiligen ?", maar nu wek je de illusie dat je een 100% veilige webserver wilt, wat in de praktijk onmogelijk is. Daarom ontvang je deze in jouw ogen, maar wel een feit, negatieve response. En noem geen VPS als je denkt dat een DDOS door de hosting tegen gehouden wordt. Zelfs grote providers gaan soms met een DDOS onderuit, dus je vraag over hostende DDOS filter geeft al aan dat je niet goed snapt dat dat niet altijd dingen oplost.


Je kan het beste gewoon gevraagd hebben "Hoe kan ik de webserver het beste beveiligen ?", ik denk dat dat een betere vraag was geweest dan wat je hierboven er neer gezet hebt. Maar dat denk ik en vind ik.

Ik zal eens vanuit technisch en persoonlijk oogpunt reageren:


Daar heb je wel iets aan... Het geeft weer dat wat je op internet zet, vroeger of later op straat komt te liggen. Je moet daar dus NIETS op zetten wat belangrijk is dat het niet op straat mag komen.
Dus jouw oma's GEHEIME appeltaartrecept, mwa, niet zo erg... lanceercodes voor nucleaire raketten? liever niet..
In die context moet je dat dus zien..

En inderdaad, deze website security.nl zal ook wel eens gehacked worden. Userdatabase van websites zijn interessant, voor harvesten van e-mail adressen, en de plaintext wachtwoorden en zelfs gehashte wachtwoorden zijn interessant. Want ook die kun je gebruiken. De hashes kun je namelijk zelf ook aanmaken, en daarmee een soort van modernere rainbowtable maken. Oldschool techniek, maar verbazingwekkend effectief met genoeg rekenkracht. (een Ryzen7 met Samsung 970 is al voldoende).



Dat is dus geen 'dichte' firewall... ICMP is erg handig om te zien of iets online is... En online betekent 'kansen'... als je al een ICMP pakket toestaat, wat nog meer dan? HTTP, HTTPS, SSL zullen in de top 10 van meest gescande poorten staan (naast SMB, telnet enz). Portknocking is zinloos als je al andere poorten hebt open staan. Je 'presence' is al bekend.. kwestie van genoeg interesse of obfus of mgnjeb technieken toepassen.

Meningen op internet zijn als anussen, iedereen heeft een en is niet perse iets wat je wilt zien... Net zoals de mijne maar 1 mening is van 17 miljoen Nederlanders... Wellicht met meer ervaring maar ook mijn eigen referentiekaders die beperken of misschien wel GOM syndroom bevatten.


Een zo'n dom mogelijk systeem, gemaakt voor domme mensen (slimme mensen maken slimme fouten namelijk en domme fouten zijn makkelijker te spotten) met zo min mogelijk fratsen en GEEN plugins. NOOIT NEVER NIET plugins.


Elke entry tot het systeem is er 1... elke mogelijkheid tot communicatie is een mogelijk tot binnendringen. Is IPv6 nodig? Nee zet dan uit. Firewalls en andere beveiligingstechnieken zijn zwaar onderontwikkeld op het gebied van IPv6, dus die moet je zo veel mogelijk proberen te voorkomen. SSH toegang leuk, maar doe dat dan niet op TCP22.. Webserver? aub geen poort 80 openzetten... mailserver? wil je dat risico echt lopen? Ik zou het niet doen op een 'zo veilig mogelijk' systeem. Dat is een beetje als een bepanserde auto kopen en dan landsail bandjes eronder leggen..


Heb je al gedacht dat je misschien niet SSH voor de wereld moet openzetten maar alleen vanaf 1 (of redundantie 2) punt(en)? VPN naar die ene endpoint en daarvandaan hop je verder, soort van steppingstone server... dat scheelt namelijk 3402823669209379999999999999999999999999 mogelijke IP adressen waarvab je gehacked kan worden.. Wat niet binnen mag, komt er moeilijker bij.

Je kunt asymetrisch en symetrisch tegelijk gebruiken, ook wat meer toekomstproof.


F2B is zwaar beinvloed door de NSA... ik weet niet of je die moet vertrouwen... Maar als je die vertrouwd, kun je ook Kaspersky antivirus installeren.


Zolang je webserver implementatie daar niet vatbaar voor is, is dat een probleem die niet zo spannend is als een brakke http deamon met 30 plugins van heel internet.


Nee... IPv6 moet je toch al niet willen.


poort een keer in de 6 dagen aanzetten... anders gewoon uit. gebruikersvriendelijkheid is niet secure.

Begin eens met je OS en Web Server te hardenen. Heel veel problemen voorkom je daar al mee. Zie bijvoorbeeld de CIS benchmarks https://www.cisecurity.org/cis-benchmarks.

Je snapt weinig van de realiteit van je situatie als je niet eens de waarde kan inzien van gratis advies.
Eerste je vraag is onmogelijk zoals ieder hier aangaf pefect bestaat niet het is gevaarlijk voor je sanity om dat uberhaubt na te streven. Die lap tekst legt je in het kort uit waarom er niet kant en klare instructies bestaan en geeft algemene adviezen over potentiele struikelblokken in je denkwijze aangaande het opzetten van je server met twee praktijk voorbeelden.

Maatwerk advies is niet goedkoop. Een paar simpele vragen kan ieder wel beantwoorden vast en zeker maar gezien het gegeven dat er geen enkel situatie 100% hetzelfde is zul je zeer weinig animo vinden om je alles bij te brengen we zijn geen mentors en meeste met kennis doen dat in hun vrije tijd of pauze tijd. 10 tot 15 minuten van een anders tijd mag je al heel blij mee zijn en het respecteren van de ander hun tijd is wel het minste dat je dan kan doen. En dat doe je niet als je niet weet wat je vraagt en er van uit gaat dat de andere kant jou dan maar helpt met je vragen opstellen.

Voorbeeld we weten niet eens welke OS, kernel je gebruikt of wilt gebruiken laat staan kennis in hebt. Het enige gegeven dat je gaf daarover was fail2ban wat vermoeden doet dat het iedergeval linux achtig is tenzij je Windows met docker setup bedoeld. En dat is een van die belangrijke onderdelen qua informatie want als je een Debian server wilt opzetten ga je toch net weer iets anders krijgen dan een Redhat achtige als voorbeeld. We wisten als tweede voorbeeld tot je latere berichtgeving niet eens of het voor hobby was. Kunnen we wel leuk aannames maken maar dat doe je niet in IT zeker niet bij het opzetten van omgevingen daar wil je gewoon harde data hebben waar je mee kan werken.

Je kunt er niet vanuit gaan dat wij die gaten elke keer vullen over jou vraagstelling zo werkt het niet. Advies is een ding handje vast houden is iets anders en dat is nogmaals vaak niet goedkoop nog verstandig als jezelf kennis er van op wilt doen.

En negativiteit?
Er zat helemaal geen negativiteit in mijn nog de reactie van 10:27 gewoon een lading aan ervaring en realisme in de hoop dat je niet trapt in de valkuilen om te makkelijk te denken over bepaalde zaken. De negaviteit heb jezelf zojuist gecreeert door te denken dat je een comeback kon maken door wat termen te noemen en een sneer naar anderen.

Maar hier om je niet daarmee teleur te stellen.
Je sneer naar 10:27 wel daar zet je jezelf nu mee voor het blok.
DDoS filter op je hosting? Heb je uberhaubt wel DDoS scrubbing in je contract? Wat is maximale bandbreedte waar je een contract voor afsluit? Is het voor Gbps is het pps is het rps? Hoe zit het met je overflow strategie heb je loadbalancers?
Of misschien betere vraag als het toch enkel hobby matig is waarom zou je uberhaubt nu tijd steken in DDoS beveiliging gezien de kans dat een hobby server getarget wordt door DDoS minimaal is vergeleken bij conventionele aanvallen en bots die resources vreten.

En waarom zouden we HSTS benoemen als het eigenlijk algemeen advies is sinds rond 2019 dat als je ten alle tijden HTTPS kan aanbieden het beter is om het standaard aan te laten. Je gaat er toch ook niet vanuit dat we gaan vertellen dat het verstandig is om alles up to date te houden? Je vraagt over goede beveiliging van een server dan mag je toch wel als lezer hopen dat je iedergeval iets weet van moderne opzet en wat basis best practices? Anders ben je beter af te beginnen bij de basiskennis qua IT en protocollen en helemaal nog niet de stap te maken naar server architectuur.

Ik wens je veel geluk met het opzetten van je perfecte server maar als dit je houding is naar anderen die het beste met je voor hebben dan kom je van een koude kermis thuis bij het gros van de mensen hier vrees ik. En naar mijn mening ook gewoon verdiend.

Teleurstelling mag je in jezelf hebben als je beschikt over zelf reflectie dat is.

Je haalt ook van alles door elkaar onder de term "veilig".

De server zelf tegen "hackers" - dan moet je management access ontzettend dicht zetten.
En eigenlijk plain HTTP met statische HTML "leveren" .
TLS is een enorme bak code met regelmatig bugs . Allerhande dynamische backends zijn ook een risico vanuit dat perspectief.

Gewoon amper functionaliteit - dat maakt de server veilig maken beter doenbaar.

De _gebruikers_ervaring 'veilig' maken - dan krijg je het hele TLS circus. En evenrtueel HSTS . En als je ook nog praat over "inloggen" - beheer van user accounts, gekozen password of andere credentials (user certificates ofzo)
single-DES is voor de server helemaal niet onveiliger dan AES - dat is het alleen deels voor de data confidentiality van heen en weer gestuurde data.

"security" heeft veel aspecten - wat beveilig je precies tegen welk risico of welke aanvaller, en die moet je goed uit elkaar houden.

En wat jij 'negativiteit' noemt is duidelijk ervaringsrealisme van die poster.

Zo'n maximale bunker server verzinnen is nogal hobbyisme - het bouwen is dan voor jou een doel.
Professioneel gezien is het bouwen een middel. Het DOEL is , bijvoorbeeld, het leveren van een webshop service, of een bankier site . En dan is een van de verwante doelen zorgen dat je zonder totaal opnieuw te beginnen ook iets erbij kunt bouwen.
De wensen en eisen van 'de klant' (interne organisatie ) veranderen in de loop van de tijd. Niemand wordt dan blij van een een antwoord "dan beginnen we van voren af aan" .
Op dezelfde manier zoals kantoren systeemwandjes plaatsen intern, omdat de indeleing in werk en vergaderkamers nog wel eens wijzigt en dan ga je geen dubbele bakstenen muren neerzetten.

Al het gepraat over port knock, fail2ban etc - heb je al bedacht dat die (slechts) gericht zijn op externe aanvallers die direct proberen in te loggen op de server ?

Zoals we nu soms zien bij de crypto coin exchanges - de aanvallers richten zich op de laptop van de developers/beheerders van het platform.
Daarnaast : blijkbaar ga je ervan uit dat er "een" beheerder is, en dat die persoonlijk 100% integer is.
Mooie aanname. Vaak klopt die ook wel.
In een grootschaliger omgeving wil je dingen niet bouwen op basis 1 super beheerder die dan (met alle leuke 2/3 factor speeltjes) ook alles kan en mag .
Misschien moet je gaan denken over een beheeropzet waarin de acties van "de" (een) beheerder gelogd en eventueel eerst approved moeten worden . Dan wordt het fors veel complexer - maar ergens wordt dat noodzakelijk.

HSTS en HTTPS uberhaupt hebben weinig te maken met de 'hackbaarheid' van je server.

Met veiligheid in algemene zin heeft het voldoen, maar dat gaat niet altijd om een systeem hacken (toegang verkrijgen, privilege escalation, etc.).

Als je op een forum over Kwantumfysica vraagt hoe je de kat zowel levend als dood UIT de doos krijgt zal je ook antwoorden krijgen waarin mensen je proberen uit te leggen hoe kwantum superpositie WEL werkt. En dat is dan inderdaad geen antwoord op je vraag. Maar dat ligt aan de vraagstelling en niet aan de mensen die je beantwoorden. Je mag in die situatie blij zijn dat je uberhaupt nog antwoorden krijgt in plaats van dat mensen de vraag links laten liggen.

"
Wat is de mening van de security professionals onder ons hierover?
Welke configuratie opties zijn een must, wat te vermijden, etc..."


Dat een leek geen server dient te configureren. Er bestaat niet voor niets "managed hosting" inclusief (security) updates en beheer.

Als je een webshop gaat draaien met - het eerste jaar - een brutowinst van 10.000 euro per maand, voordat je een ferrari bestelt voor jezelf, huur iemand in voor security en systeembeheer voor 30% - de helft van dat bedrag.

Precies dit, hardening, zero trust met rechten op het onderliggende file systeem maar ook op alle andere plekken waar de webserver software ook bij kan. Het draaien ven een webserver is GEEN next/next/finish geval. Draai deze dan ook niet als system, maar maak een sterk beperkte gebruiker aan waaronder de server draait en neem alle rechten ervan weg die niet nodig zijn.
Zo draai ik al jaaaaaren een web server en zelfs met een lek component kan een aanvaller niks want het component mag niks.

dat dacht ik ook, totdat 3 bugs gecombineerd werden en mijn apache een module installeerde genaamd modproxy...
aanvaller kan niets, bestaat helaas niet.

Het is wel weer duidelijk dat hier een hoop mensen zitten die zelf niets hosten, alleen maar in de theorie zitten of slechts thuis een machientje draaien.

Een aantal punten:

Maak je over SSH niet zo druk, met key auth en eventueel op een ander poortje dan de standaard is prima.
Als er iets is dat je best op het internet kunt hosten is het wel SSH.
Wachtwoord authenticatie zou je geheel uit kunnen schakelen of je moet er een sterk wachtwoord op zetten, online bruteforce is zo tragisch langzaam dat het tot het eind der tijden zou duren.

Ook dingen als Nginx of apache zijn dingen waar je je niet echt druk over hoeft te maken als je maar regelmatig een keer een update doet.

Het voornaamste 'attack service' zit 'm sowieso in de website die je er op gaat draaien.
Omdat we geen idee hebben wat dat zou moeten zijn op basis van je vraag zit 'm daar de crux.
Indien je kunt werken met statische content dan heeft dat absoluut de voorkeur, elk draaiend onderdeel is een potentieel risico.
Mocht het niet publiek hoeven zijn dan doe je er beter aan om dit niet te exposen aan het web.

Verder zou hardening met behulp van selinux een hoop kunnen doen mocht je server toch geexploit worden.

En je zou kunnen overwegen om een gratis cloudflare accountje voor je server te hangen, dat helpt een hoop bij het weg filteren van rotzooi richting je server.

Aan alle hobyisten en IT ethousiasts die dit lezen. Het doel van de reacties is niet om je te ontmoedigen een server op te zetten maar wel goed te begrijpen dat het net als van een fiets naar een auto is qua situatie Je hebt meer verantwoordelijkheden en vormt een potentieel groter gevaar voor jezelf en anderen en als je niet goed weet waar je aan begint en ervaring op doet.

Lees je goed in er zijn honderden boeken over server beheer er zijn duizenden meer zelf gestelde vragen. Niemand zit te wachten op het beantwoorden van het niveau let me google that for you vragen het flagged je meteen als iemand die niet competent genoeg is in informatie vergaring en dat is een vereiste in dit vak omdat je elke dag situaties kan tegen komen waar je dus voor op onderzoek moet gaan.

Mijn dag begint met 400+ nieuws feeds om te zien wat een leverancier nu weer gesloopt of gefixed heeft in stukje code. Dan nog eens stuk of 100 feeds over veiligheid nieuws dan paar honderd mails false positives die beoordeeld moeten worden wegens de dagelijkse updates die code hebben veranderd. Dan vragen van collegas en klanten overleg met collegas en verbetering trajecten alsmede voorbereidingen voor over maanden of zelfs jaren qua uitfacering van onderdelen. Nog niet te hebben over reageren in werkgroepen en leveranciers forums om sturing te krijgen over ontwikkeling van nieuwe features.

Meeste van mijn dag bestaat uit lezen lezen. beetje schrijven en praten. Acties op de server zelf zijn maar een fractie van mijn werk het is voornamelijke controle niet het bouwen van oplossingen.

En als hobbyist heb je het geluk dat je minder te doen hebt maar als je verder wilt gaan in dit vak gebied dan is het noodzakelijk dat je leert om te gaan met massas aan informatie in hele korte tijd en zelf keywords eruit te pikken om acuraat beknopt alle informatie op een rij te krijgen.

En zodra je dat besef hebt begin je ook te begrijpen waarom we als ITers die al wel hier mee te maken hebben niet zitten te wachten op de obivious vragen. Omdat het slechter ITers creeert omdat we weten welke shitload aan information overload je mee te maken krijgt en hoe ontzettend belangrijk ons werk is zodat andere hun werk kunnen blijven doen.

Maar dat het belangrijk is wil niet zeggen dat het altijd leuk is want dit is het eerlijke antwoord het is ook vaak verdomd saai. Soms gebeurt er echt geen hol en lig je als je de boel goed onder controle hebt nog net niet te slapen als je door alle nieuws en tickets bent en andere keren maak je allnighters omdat er iets goed gefcked is ergens.

De hollywood achtige sht met hackers wel kan je teleurstellen daar wordt je niet warm nog koud van als het gebeurt en het gebeurt genoeg. Je isoleert het probleem aan de hand van de log data je schrijft custom rules, IP table om er van af te komen je patched code maakt een notitie en je gaat door.

Er is niks spannends aan en er is niks leuks aan. Geen enkel beheerder zit met smart te wachten om weer een bot attack op te lossen die door je eerste beveiliging heen is geen enkel ITer gaat met collegas hebben over wat ze nu weer hebben tegengehouden op hun netwerk en denken dat het de andere intereseert. Het hoort erbij en je dealt ermee en je denkt er verder niet over na. Vergelijk het met de afval buiten zetten je doet het omdat het moet omdat je niet wilt dat de boel gaat stinken.

En interesse is altijd iets wat men graag ziet over IT maar zelfredzaamheid en iniatief tonen is wel een van de vereiste in dit gebied. Ik zie tich keer liever vier kantjes aan probleem omschrijving waaruit ik het niveau van de ander kan schatten hoe secuur de gene is hoe diep iemand al in de stof is gedoken en welke troubleshoots al overbodig lijken. Vergeleken met een vraag hoe doe ik dit? wat is de beste oplossing voor dit. Want geloof me als ik zeg dat er geen te lange antwoorden ooit zijn in de IT onder elkaar maar wel te korte.

En als je nu in je hoofd hoort jezus wat een lange tekst dan bedenk je twee keer voor je aan dit vak begint want dit is wat je te wachten staat. herhaling op herhaling, lappen tekst, ego en realisme.

Het eenvoudige antwoord is dat je zelf lui bent. Je wilt iets waar je met je rug naartoe kunt zitten en anderen moeten dat maar voor je oplossen.

Voor thuisgebruik, bluetooth krultangen en wifi, daar moet je met je rug naartoe kunnen zitten. Zoals elke consument.

Maar een server is dagelijks bij de les blijven. Monitoren. Zorgen dat die niet wordt misbruikt om bluetooth krultangen in de fik te laten vliegen. Regelmatig een beetje daas naar je scherm kijken. Wat gebeurt hier en zie ik gekke dingen. Niet enkel belangrijk voor jezelf maar voor het hele internet. Totaal veilig en maffen bestaat niet. Er is een sociaal gevoel bij nodig voor het hele web, en als je dat negativiteit noemt, dat anderen niet alles voor je oplossen, huur dan een wasmachine in plaats van een server. Servers draaien is bij de les blijven. Spijbelen is geen diploma krijgen.

Hou applicatie en data gescheiden. Applicatie/webserver in DM-Zone , Database weer in andere Zone.
Doe stukje logging met automatische melding ( mail bijv) over threats , verkeerde inlogpogingen etc...
Doe IP block op adressen die teveel achter elkaar bijv proberen in te loggen of attacks uit voeren.
Gebruik indien mogelijk zoiets als nginx voor reverse proxy....
Backup alles....
Follow best practises voor inrichting zoals die van bijv de CIS standaarden......zo kom je al een heel eind.

Dat klinkt interessant. Helaas levert het doorklikken naar de downloads, onder learn.cisecurity.org/benchmarks, een onbereikbare website op.

Alles wat niet HTTPS is enkel beschikbaar maken over OpenVPN/Wireguard.

Diensten (webserver, vpn, evt. DB) in docker draaien zonder root rechten.

Website zo veel mogelijk statisch maken (als het zelfbouw is), zo min mogelijk serverside logica voor het renderen om zo bugs te voorkomen.

Alles (server, container images, website) zo veel mogelijk up-to-date houden en de hele setup laten PEN testen.

IP whitelisten in firewall voor VPN.

Indien mogelijk website ook firewallen indien mogelijk of tenminste geofencen.

Trek je website(s) eens door:
https://securityheaders.com/
https://www.ssllabs.com/ssltest/

Natuurlijk wil je je server ook voorbereiden op IPv6.
Je hoeft niet alles van icmp door te laten voor ipv6.
Ik weet niet meer precies hoe het zat maar je kan bepaalde subtypes blokkeren en andere subtypes moet je juist doorlaten.

ICMP kan een security risk zijn. Hackers zijn in staat dmv protocol tunneling je netwerk binnen te dringen.

Met een beetje Googlen vind je hier gemakkelijk de details over.

Werkt bij mij (nu) wel. Eerder deze week kreeg ik ook een timeout.
Verder heb je ook nog de STIGs (https://public.cyber.mil/stigs/downloads/); je zou daar ook een kijkje kunnen nemen.

Ik zou niet adviseren ICMP te blokkeren, het is wel mogelijk dmv. packet inspection delen te blokkeren, maar je moet dan echt wel weten waar je mee bezig bent. Ik zou eerder adviseren voor je server een losse firewall appliance te hebben en die te laten reageren op ICMP requests.

Overigens, als je niet los bent op IPV6 en een term als pin-holing je niets zegt zou ik lekker IPV6 volledig disabelen totdat je er zeker van bent hoe het werkt.

Ja, en als je meer leest snap je dat dat helemaal niet 'zomaar' gaat.


Afschuiven op "de appliance doet het wel" - dat is ook maar een server met een config.
En iemand moet die config maken - hier dezelfde persoon die de webserver config wil maken,, dus dat verschuift de vraag alleen maar naar "hoe maak ik de meest veilige firewall appliance voor mijn meest veilige webserver".


Nou ben ik aardig los op IPV6, maar pin-holing in die context moest ik opzoeken.
(waarom nou weer een ander woord - wat is er mis met port forwarding..)

Ik stel voor dat jij dat ook doet, en dan eens uitlegt wat de relatie "hosted internet facing webserver" is met "IPv6 pinholing" .

Hint - TS vraagt specifiek naar de situatie waarin zijn verantwoordelijkheid precies alleen de server is. Geen "enterprise netwerk met DMZ" of 'enterprise netwerk met interne server die bereikbaar moet zijn) . (later verduidelijkt naar 'VPS bij hoster') . Oftewel - (vrijwel) ongefilterd internet-facing met een adres of adresblokje.
Voor een simpele server kan dat prima - en dan is het een kwestie van server hardening, en alle niet gebruikte poorten/protocollen/niet-relevante icmpv6 (en icmpv4) typen firewallen op de server.
Alleen de term daarvoor is niet 'pin holing' noch 'port forwarding'.

Een aantal dingen waar ik aan denk:
- Ik weet dat je public key authentication moet gebruiken en password login uit moet zetten voor SSH.
- Maar is dat voldoende? is Fail2Ban goed genoeg, of toch maar dat port knocking inzetten?
- En je standaard TLS configuratie gebruikt zwakke ciphers, maar wat is nog meer standaard zwak?
- ICMP ja/nee? Het zou kritiek zijn voor IPv6. Is het echt zo gevaarlijk, gezien het vaak gewoon aan staat?
- Er is HTTP op poort 80 voor HTTPS redirect of voor certificate challenges. Beter wel dan niet, toch?

Een muur van directe antwoorden:

Je moet het splitsen in twee onderdelen: de host (OS / webserver / etc) en de website(s).
De host kan je inderdaad zeer goed beveiligen, beperk management tot 2 of 3 IP's en gebruik inderdaad minimaal pubkey authenticatie. Mocht je het beter willen, gebruik MFA (bv TOTP of beter, Yubikeys / FIDO2) bij het inloggen. Zorg voor een regelmatig update regime of nog beter auto-update voor alles behalve major versions (monitor dit ook). Draai webserver software geïsoleerd zoals in een jail of containers (handig voor updates). Op die manier is fail2ban of portknoking in principe niet nodig (enkel een paar ip's toegestaan om verbinding te maken). Je kan ook nog notificaties op inlogpogingen zetten om misconfiguraties snel te herkennen. Mijn notificaties (K8s) gaan naar een Mattermost (slack) channel waar alle alermering en update notificaties samen komen.

Wanneer je management moet doen vanaf een willekeurige locatie, maak dan een VPN verbinding met de management locatie (zoals werk). Zwakke ciphers blokkeren is meestal een kleine moeite en maakt MiTM attacks moeilijker. Doe dit wel op alle diensten (vergeet SSH niet).

ICMP moet inderdaad aan staan voor IPv6. Gezien het een apart protocol is, kan je dit ook apart toestaan mocht je ICMP IPv4 willen blokkeren. Als je het tot echo beperkt, maakt het niet veel verschil. Maar minder poorten open is altijd beter. Poort 80 hoeft naar mijn mening niet meer open te staan, je kan gewoon DNS challanges gebruiken en dat is veiliger. Gebruik snapshots van de host machine voor snelle restore functionaliteit.

Wat betreft de websites die je host, het veiligste is om statische sites te draaien (dus simpelweg html). Er zijn daarvoor diverse frameworks en dat geeft geen aanvalsvector (geen management). De meest gehackte sites draaien wordpress en worden meestal gehacked door plugins en gebrek aan updates. Zorg dus ook dat dat geautomatiseerd is.
Ik gebruik verder Crowdsec op de ingress firewall, die banned direct de meest ranzige ip's. Dat geeft al een goede eerste bescherming van de gehoste sites maar het is verstandig deze continue te scannen. Mocht je ranzige wordpress sites moeten draaien, zorg dan weer dat updates goed gemanaged worden (diverse plugins en software voor).

Dat is mijn huidige opzet... Ik ben nu bezig om cis-benchmarks controles te automatiseren tegen de hosts en sites:
https://www.cisecurity.org/cis-benchmarks
Mogelijk ook nog bezig met Wazuh.. dat ziet er veelbelovend uit als SIEM oplossing.

Niet slecht als Homelab, al zeg ik hetzelf ...

De onbereikbare site lag hier aan één van de filters in mijn pihole. Die blokkeerde een marketingtool (pardot dot com) die daar gebruikt wordt.

Waarom moet je zonodig vanaf het hele internet managen, als je een "supermaximaal veilige server" wilt ?

Zet een packetfilter op een heel klein aantal trusted IPs (typisch je thuis IP).
Of desnoods een kleine range (heel KPN mobiel is een heel klein brokje van "het Internet" .).


Dat is voor je server helemaal geen risico, alleen nogal theoretisch voor data die je verstuurt.
Het hele feit dat je TLS praat is al een risico .

Je gooit het (ik heb dat eerder gezegd) allemaal op dezelfde 'security' hoop.

Natuurlijk niet. En je kunt een hoop functionaliteit kapot maken als je het volledig uitzet.
Zorg dat je snapt hoe icmp werkt. Zorg uberhaupt dat je heel grondig snapt hoe dingen werken.

En ja - icmpv6 volledig blokkeren zorgt voor een onbereikbare server.

Blindings scrippies met 'tuning' of 'hardening' overtypen is voor prutsers.
Weet wat je doet , als je dan de hobby of ambitie hebt om met dit soort dingen te werken.


Wat wil je, of wat wil je niet ?
Er zijn meer challenge opties dan http . DNS kan ook.

Een simpele webserver met plain HTTP is - voor je server - veiliger dan een https webserver.

yup.


MITM heeft vooral met authenticatie te maken, minder met het werkelijke cipher.

Om de een of andere reden vinden mensen een 'exposed VPN protocol' minder een risico dan een 'exposed SSH port' .
Ik snap dat niet zo goed.
Denk ook bij de VPN server aan alle noodzakelijke hardening. Het is ook gewoon een OS met een nogal complex stuk software dat "VPN" doet .
VPN is fijn als je een end-to-end IP connectiviteit naar (diverse) hosts wilt/moet hebben. Doe je 'gewoon' cli management of wat gescripte zaken kan dat ook over SSH.


yup. Hoewel plain http echt geen groter risico hoeft te zijn dan "dns" - en de manieren waarop je data in die dns server wilt stoppen.
Soms is DNS 'somebody elses problem' - dat kan een voordeel zijn. Maar fundamenteel is het yet another informatie bron met een erg publieke query API , software van verschillende kwaliteit en diverse mogelijke APIs om informatie erin te wijzigen.
De APIs om informatie erin te stoppen moet je ook hard over nadenken, hoe je zorgt dat dat alleen kan door de authorized bronnen.
Of het nu een webpanel met authenticatie is, hidden master, scripted login en config edit, een of andere database sync naar de onderliggende database , whatever.
De keuze van DNS server software maak je (eventueel) ook zelf, net als de keuze van de webserver software.


yup.

...

Ik snap ook wel dat er geen pin-holing is als de doos direct aan het internet hangt. Maar meer dan eens zijn security issues te wijten aan slechte firewall inrichtingen, tel daarbij het onbegrip van IPV6 bij op, dan kom ik met het advies het firewallen te laten doen door een appliance die ervoor gemaakt is, met een UI waar je nog een beetje mee uit de voeten kunt.

De TS wil meerdere dingen, en soms sluit het een de ander uit. Vandaar ook het *advies*.

Als de TS aangegeven had een doorgewinterde sysadmin te zijn met alle kennis van SELinux, hardening, firewalling, IPV6, enz. Dan was de operking niet nodig geweest, maar dan was denk ik deze hele thread niet nodig geweest. Dus ik schat de kennis gering in, en dan ontkom je er niet aan kennis in te kopen. Wellicht dat de VPS provider firewalling aanbiedt.

TS wil gewoon hobbyistisch leuteren en misschien een beetje klungelen aan een hobby server, dat blijkt uit alle berichten.

Niet iemand die een werkelijke dienst moet of wil bouwen en een echte _oplossing_ zoekt ; In dat geval is het beste advies inderdaad "besteed het uit aan een partij die het vaker gedaan hebt, want je hebt niet de kennis om het zelf goed te doen, en van een paar forum postings ga je dat ook niet leren" .

Ik ken overigens geen firewall UI die de knop "klik hier om deze server optimaal veilig te maken" biedt.

De UIs maken het zeker overzichtelijker om te bouwen wat je bedacht hebt dat je wilt doorlaten of blokkeren - maar het bedenken wat er minimaal noodzakelijk is om door te laten moet je zelf doen.
En overzicht houden door dingen te groeperen in allerlij objecten en groepen is ook wat UIs erg goed doen .

Kortom - als je probleem is "ik weet dat ik port/protocol/icmp6 type/subtype wil doorlaten en de rest niet naar server 2001:x:y:1", maar de syntax van ipfilter kom ik niet uit dan is een firewall UI een heel goede hulp .
Voor een open vraag als "ik wil een maximaal veilige webserver bouwen wat moet ik doen/doorlaten/dichtzetten" zijn firewall UIs imo maar van beperkt nut.

Redelijk simpel.
Maak gebruik van containers en static images waar je website op gedeployed is, waardoor het read-only wordt, en dus hackers niet zomaar je website kan manipuleren. Traefik of NGINX gebruiken voor het automatisch routeren en monitoren van je traffic :)
SQL injections voorkomen door gebruik van ORM's, die bouwen de queries voor je op, waardoor je geen typo's of fouten maakt.
Alles dicht gooien, en toegang voor je admins maken via bijv. Wireguard of welke VPN server software dan ook (Softether is ook prima), en deze alleen toegang geven tot SQL en andere componenten.

Ik host nu 15 websites, waaronder ook wat oude PHP 5.6 meuk, maar ook wat Python en Rust (niet de game, maar de programmeer code) servers.
Zorg ook voor correct configureren van je (als je Linux gebruikt) netwerk stack in sysctl, voor optimaal netwerk afhandeling, fail2ban helpt bij het scannen van log files en aggeren als nodig (automatisch brute-force attacks firewall droppen, etc...)

Wordpress sites via automatic patching process patchen, en outdated plugins disablen, of gewoon, GEEN WORDPRESS MEUK GEBRUIKEN... Ben eerder een Symfony programmeur en Rust programmeur met hulp van de Actix web framework.

Ohja, en Cloudflare helpt al heel veel (al moet je wel de header van hun gebruiken als je hun proxy servers gebruikt om de remote IP en poort te krijgen, X-Forwarded-For werkt ook)

We hebben zelf ingebouwde best practice list en live setting checks met voor meeste zaken een autorestore knop per advies. Maar dat zit in onze bedrijfs firewalls dat is ingericht als provider van honderen bedrijven met custom integraties en dat kost wel wat. Dus ja het bestaat maar of het nodig is voor de meeste of betaalbaar nee.

En zelfs dan nog moet je zelf afwegingen maken en de boel echt snappen. Simpele interfaces vragen vaak meer kennis van de lezer dan de gene die een info dump doen. Ze zijn er hoofdzakelijk om kosten te besparen op tijd van specialisten en om makkelijk klanten handelingen zelf te laten verrichten mits je elk knopje dat schade kan brengen uit hun UI haalt.

Het is niet de manier om iets echt te leren daarvoor wil je gewoon een paar keer de boel goed slopen om te snappen wat er mis kan gaan waarom het mis ging en hoe je het hersteld. Heb je al die kennis dan kun je de more lazy approach hanteren zolang je maar actief monitored.

Ik kan mijn stagiares leren theoretisch om modsec rules op te stellen en te monitoren ik kan ze echter niet leren hoe het voelt om de boel vast te laten lopen en hoe je daar weer uitkomt zonder dat ik ze gewoon wat laat klungelen tot ze het snappen. Je leert nu eenmaal het meeste van wat je fout doet niet wat je is aangeleerd is als goed of bij toeval eerste keer lukte.

Welkom in de wereld van IT, die van het adagium "kennis is macht", waarbij dat regelmatig flink ingewreven wordt...

Om te beginnen kan je nooit iets echt perfect veilig maken, er worden continu zwakheden ontdekt waardoor het hebben draaien van een (web)server niet moet worden gezien als een eenmalige 'install and forget', maar als een voortdurend proces.

Iets kan wel veilig genoeg zijn, dan denk ik bijvoorbeeld aan (semi-)overheden en grote bedrijven die beducht moeten zijn voor statelijke actoren. Er van uitgaande dat je webserver ook gegevens verwerkt (is meestal zo) dien je je ook te kunnen verantwoorden naar derden en dus moet je altijd je papierwerk op orde hebben. Denk aan de AVG, doe aan dataminimalisatie, stel een DPIA op en ook hier geldt dat dit een terugkerend proces is.
Bedenk van te voren wat je te doen staat als er ingebroken wordt en wat de schade wordt wanneer data gestolen en/of gegijzeld wordt.

Bij het inrichten van een webserver begin je met het principe van least privilege. Alles wat niet nodig is zet je dicht (firewall) of laat je weg (overbodige software en accounts). Software update je naar de veiligste versie, en sommige software kan je beter helemaal niet gebruiken (Wordpress, liefst heel PHP ondanks de populariteit.)
Dit vereist dat je iemand hebt (jijzelf?) die bij blijft met de laatste ontwikkelingen.
Ik zie overigens geen reden om IPv6 niet te gebruiken, mits met de juiste privacy-maatregelen. IPv4 wordt steeds minder gebruikt.

Bovenop een VPS moet je een besturingssysteem installeren. Hier heb je ontzettend veel keuze, kies het liefst een lichtgewicht OS dat extra goed is in netwerken en beveiling. FreeBSD is een goede keuze, maar er zijn er meer. Harden je OS.
Installeer je een applicatieserver of maak je er zelf een, volg dan de principes secure by design en privacy by design, en houd je aan de standaarden die er zijn, controleer dat met bijvoorbeeld https://cheatsheetseries.owasp.org/Glossary.html. Zorg dat de apps / sites toegankelijk zijn, soms is dat een wettelijke vereiste: https://wcag.nl/kennis/wet-en-regelgeving.
Stel je webserver / TLS minimaal in naar moderne maatstaven: https://ssl-config.mozilla.org. Ga het liefst meteen voor PQC als je dat voor elkaar krijgt met de gekozen software. Valideer je webserver via https://internet.nl en test je certificaten met een online checker als https://www.ssllabs.com/ssltest.
Harden je webserver en volg de tips voor veilige headers, buffering, rate limiting (tegen DoS).
Een mailserver zou ik uitbesteden, dat is een hele andere wereld.
SSH afschermen met PKI (client en server) en via de firewall alleen toestaan voor je eigen IP's.
ICMP ja, als je webserver een publieke is.
Sites altijd via HTTPS, beter Let's Encrypt dan helemaal geen certificaat maar het beste is gewoon een betaald certificaat.
Poort 80 alleen opzetten voor ACME en redirect.

Wanneer je alles hebt draaien heb je alleen de installatiefase gehad. Dan moet je gaan en blijven monitoren. Tijdelijk automatisch blokkeren van IP's die te vaak achter elkaar inloggen. Aan gebruikers vragen of hun login-informatie klopt en er op acteren als ze aangeven dat zij niet degene waren die een inlogpoging hebben gedaan. Bots weren die je sites proberen te scrapen. Audit logs monitoren. Technische logs monitoren, netwerklogs monitoren. Er kaas van maken gaat het beste in een SIEM-tool.
En vergeet de gebruikers niet, die moet je bewust maken en houden van risico's, wat mogen ze wel doen en wat niet, waar moeten ze op verdacht zijn, zorg een FG-er, IBF-er, en meld altijd datalekken aan de AP.

Heb je alles opgezet en gemonitord, dan wil je dit ook onafhankelijk kunnen aantonen. Dit doe je door een ISO 27k-certificering te halen en periodiek een PEN-test te laten uitvoeren. Als je je werk goed hebt gedaan is een PEN-test heel erg saai, zonder verrassingen.

Bedenk ten slotte dat er al zoveel aan het internet hangt, dat het 32-bit IPv4 protocol niet genoeg is gebleken. Een webserver opzetten is goed te doen als je maar open blijft staan voor verbetering en de actualiteit en bedreigingen blijft bijhouden, je blijft altijd leren.

De opzet die ik hierboven beschrijf is zelfs nog maar een conventionele, misschien al weer een achterhaalde. Dat zeg ik omdat kunstmatige intelligentie in opkomst is, waarvan op dit moment nog niet precies duidelijk is hoe daarmee bestaande beveiliging te omzeilen is, en wat je daar allemaal tegen kan doen.

Echt veilig maakt ook leasy en dat maakt dat je geen personeel hebt die de juiste acties kan ondernemen omdat die niet gewend zijn om in actie te treden of die al is vermindert omdat alles toch goed loopt ... en dan heb je problems . Voor dos attack moet je gewoon een goede ethernetkaart hebben (die ziet er dan meer uit als een graffisch kaart) met grote koelbloken en ventilators en dan een meevolgende app server waar je dus zo goed als onmiddelijk paginas kan afleveren(tijd zo kort mogelijk)
60ms voor een pagina tov 300ms wil ook zeggen 5keer meer paginas kunnen afleveren en dus 5keer groter leger van dummy slavehost om te kunnen aanvallen . En je kan soms beter net ervoor simuleren dat de server eruit gaat zonder hij effectief down is dan ben je sneller up in running.