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.