Wintervacht schreef op maandag 30 maart 2020 @ 23:49:
[...]
Ik zeg toch ook niet dat je zoiets dan maar helemaal niet moet beveiligen, ik zeg alleen dat je er met een paar simpele dingen al ver bent en dat het simpel op te lossen is mocht het mis gaan
Je kan security zo gek maken als je wil maar overdrijven is ook een vak en ik lees tussen de regels hier gewoon een enorme angst voor... ja wat eigenlijk? 'Gehackt worden' is een hypeterm die veel gebruikt word op faceboek en dergelijke congregaties van desinformatie en moedwillige onwetendheid, daarom ben ik benieuwd waar het vandaan komt.
Het issue met je opmerking is dat je focust op het opruimen nadat de schijt de ventilator raakt.
Even afgezien van alle collateral damage die op kan treden, is het een ontzettende kutklus om alles opnieuw te bouwen.
Sure, een SD kaartje opnieuw voorzien van Raspbian is zo gepiept. Alles opnieuw inrichten, website bouwen/inrichten en je artikelen overnieuw schrijven is wel een ontzettende klote klus.
Dus nog even compleet buiten de scope van wat voor rampen er zouden kunnen plaatsvinden, is het gewoon kut voor de eigenaar van de website/server.
En ja, dan kan je dingen roepen als 'maak backups'. Maar dat is alsnog opruimen nadat het kwaad is geschied. En dan moet je ook maar hopen dat je backups werken, want dat wordt altijd pas getest als de nood daadwerkelijk aan de man is. Het zal niet de eerste keer zijn dat het terugzetten van een backup niet blijkt te werken, om het zwak uit te drukken. Of dat het niet werkt in combinatie met een vers geinstalleerd OS omdat de softwarepackages inmiddels 80 versies verder zijn.
Een backup gebruik je liever niet, als je het ook maar enigzinds redelijk kan voorkomen.
Daarnaast roep je dat HTTPS het gros van de problemen oplost. You wish.
HTTPS is transportbeveiliging. Dat waarborgt alleen maar dat wat de server opstuurt tijdens de overdracht van de server naar de client niet wordt aangepast of ingezien. (en andersom, stel dat je een leuke reactie wenst te geven op een artikel of een login hebt op de betreffende pagina)
Als er ook maar iets schijnveiligheid is, dan is HTTPS het wel. Ja het heeft zijn plaats, maar het is géén beveiliging van de server in kwestie.
Een lek PHP script blijft net zo lek met HTTPS als zonder.
Fail2Ban lost ook helemaal niks op aan een lek script. Die monitort alleen maar logs op access-denied meldingen icm IP adressen en regelt dan een firewall regeltje in die dat IP blockt.
Een HTTP POST request met malicious content naar een random pagina die geen 401 oplevert maar gewoon 200 OK returned, triggert niet in Fail2Ban.
Ook hier, Fail2Ban heeft absoluut zijn plaats en toepassing, maar het is geen oplossing tegen een defect in code.
@
Room42 heeft dan ook een aantal hele goede punten en ik ben het absoluut met hem/haar eens.
Zorg voor een goed update regime. Maak (of jat) een cron-script die elke zoveel tijd automatisch een update uitvoert.
Kijk voor de lol even naar de video over
Shellshock door Tom Scott. Dit is een typisch voorbeeld van een bug in software die je nooit zal afvangen met HTTPS of Fail2Ban, alleen maar door de bug daadwerkelijk op te lossen met een bugfixed versie van je software.
Er vanuit gaande dat je software up-to-date en lek-vrij is: goede wachtwoorden. Op z'n minst op de plekken die public-facing zijn. Geen hergebruikte set user/pass die je elders al hebt gebruikt.
Bruteforce of poken met hergebruikte gegevens uit een leak van ergens anders dam je daar mee al enorm in. Leg daar dan nog eens Fail2Ban overheen, en het is ondoenlijk geworden om via normale login kanalen binnen te komen. (c.q. via de kanalen die netjes een access-denied opleveren bij een foute poging)
Installeer geen niet-noodzakelijke software. Als je geen PHPMyAdmin nodig hebt, installeer het dan gewoon niet.
Heb je het wel nodig, hang dan een 2de netwerkkaart aan je Pi (USB netwerkkaartje). Draai een separate Virtualhost in Apache die bound is aan die extra USB netwerkkaart, waarop dus geen traffic van buiten aangeleverd wordt.
Gebruik je een content management system voor je website, zorg dan dat je .htaccess rules gebruikt om het admin gedeelte alleen bereikbaar te maken via je lokale LAN (IP filter op lokale, private range IP adressen.)
Geef bij voorkeur ook default een HTTP 401 Unauthorized terug wanneer een request van een non-local IP komt. Deze worden dan weer utigefilterd door Fail2Ban. Hier mee houd je vulnerabilityscanners wat meer op afstand.
Forward alleen de poorten die noodzakelijk zijn. Er wordt gezegd dat 80 en 443 nodig zijn, maar dat is niet helemaal juist. Een redirect is ook niet noodzakelijk.
Wanneer je HSTS configureert in je webserver (een extensie op HTTPS), zal nagenoeg elke webbrowser automatisch HTTPS over poort 443 gebruiken, tenzij je expliciet http:// voor de URL intikt. Dat doet niemand, dus zal je browser altijd over HTTPS gaan. Geen redirect nodig, geen portforward op port 80 nodig. Probleem buiten de deur opgelost. Plus dat je daar mee SSL-Stripping attacks mitigeert, en dus je transportbeveiliging verbetert.
Dan komen we bij lekke PHP scripts. Als je niet zelf programmeert en een softwarepakket van een derde partij gebruikt, blijf die dan regelmatig updaten. Installeer zo min mogelijk plugins en schakel plugins uit die standaard mee geleverd worden maar welke je niet nodig hebt.
Mocht je de kennis in huis hebben, dan kan je kijken naar systemen als SELinux of AppArmor. Beide niet echt voor beginners, hell, het zijn zelfs ontzettende hoofdpijn systemen zolang je er geen cursus in hebt gevolgd. Hele hordes die het gewoon uitschakelen als een linuxdistro er mee geleverd wordt, want het is gewoon pittige kost. Het zijn echter wel tools die in staat zijn om heel veel shit van lekke PHP scripts te blokkeren. Of je je dat op de hals wil halen... maybe not. Of toch wel, mocht je het een aantrekkelijk onderwerp vinden. (ik vond t eigenlijk wel leuk.
kijkvoer
Maar, waarom raad ik dit nu aan?
Simpel. Webservers worden gescand. Automatisch en veelvuldig. Zet een kale webserver neer met 1 pagina en kijk de volgende dag even naar hoeveel logregels er zijn weggeschreven.
Wat doen die scanners? zoeken naar kwetsbare websites. Stukjes HTML die indicatie geven dat er een bepaalde versie van een CMS draait. Versies waar gaten in zitten die misbruikt kunnen worden bijvoorbeeld.
Gaat het die mensen om jouw data als website eigenaar of server eigenaar? Neuh, dat zal ze worst wezen.
Slecht beveiligde privé webservers worden misbruikt als springplank naar grotere doelen.
Bijvoorbeeld een pagina hosten die lijkt op een loginpagina van een bank, voor die prachtige phishing e-mails.
Of om dienst te doen in een botnet, of voor de verspreiding van injecteerbare code, of of of... genoeg scenario's waarvoor zo'n machine bruikbaar voor is.
En ze doen er dan ook alles aan om te zorgen dat ze niet zomaar ontdekt worden.
Eerder riep ik al 'collateral damage'. Mocht je Pi-servertje ingezet worden voor dit soort taken, dan loop je het risico dat je internet verbinding wordt afgesloten. Genoeg phishing mail triggert vanzelf een keer een melding naar je internetprovider dat er iets mis is bij jou.
En kom er dan maar eens van af. Ik heb wel eens voor iemand met de servicedesk van een ISP moeten boksen omdat de PC was geinfecteerd met rommel. Da's geen pretje en heeft toch gauw een maand geduurd voordat de internet verbinding werd hersteld.
En de mensen stom genoeg zijn om in dingen als phishing mails te trappen. Nog meer collateral damage Jij bent dat op z'n minst moreel verantwoordelijk daar voor als je je server willens en wetens onvoldoende hebt beveiligd. Als je het niet weet, sja, blijft kut. Weet je het wel of doe je onderzoek of bevraagt mensen die er wat van weten, zoals de TS, kudo's!
Wil ik hier mee zeggen dat je het dan maar niet moet doen?
Nee. Zeker niet. Het is een leuk onderwerp. Je moet je wel goed bewust zijn van het feit dat er risico's zijn en je daar een beetje in verdiepen. Dus, kudo's @
wobelaar , goed bezig!
Zeker lekker gaan doen, beveilig de boel goed, veel plezier
Dat ziet er inderdaad heel compleet uit. Qua basis installatie vind ik dat een prima tutorial.
Het gaat helaas niet dieper in op SSL/HTTPS instellingen van NginX, maar daar kan je ook prima dingen aan tweaken. Bijvoorbeeld HSTS en PKP, beperktere cyphersuites en forceren op TLS1.2 en hoger.
HSTS verwijdert ook meteen de noodzaak voor een port-80 redirect configuratie
Hetzelfde voor SSH. Helemaal puik dat er certificaten worden ingesteld ipv passwords (dat is echt ontzettend veel beter) icm wat restricties op wie er mag inloggen (geen root login over SSH).
Ook daar kan je nog wat tweaken aan de instellingen, maar als je het linea recta zo zou implementeren zit je best goed.
Het gebruik van PHP5 wordt inmiddels afgeraden, want dat is End-of-life sinds 1 januari 2019. Geen updates, geen bugfixes, nada.
Zie ook:
https://www.php.net/supported-versions.php
Kortom, vervang dat voor PHP7.4. Die blijft nog jaren in support en je krijgt ook gewoon updates via je packagemananger.
Ik weet niet van wanneer die tutorial is, maar ik gok dat die gewoon een tikkie verouderd is.
Ook wordt er PHPMyAdmin geinstalleerd in die tutorial. Opzich niet slecht, maar dan zou ik toch graag een htaccess (apache) of serverblock (nginx) configuratie zien die daar nog wat dingen inperkt. Bijvoorbeeld alleen toegang vanaf het lokale LAN.
PHPMyAdmin is een ontzettend machtige tool, maar er worden vrij vaak bugs in gevonden die een securityprobleem kunnen opleveren. Die zet je het liefst achter slot en grendel, so to speak.
Ook MySQL zou je volledig van de buitenwereld kunnen afschermen op TCP/IP gebied. By default bind MySQL aan alle beschikbare netwerkinterfaces. Beste om die gewoon te binden aan localhost via de configuratie files. Mysql_secure_installation is een goede tool, maar er kan wat mij betreft nog een schepje bovenop.
Ik ben helaas geen groot kenner van e-mail configuraties, maar als ik het zo zie is het in de basis best OK. Denk niet dat het voor de TS van toepassing is, dus dat mogen we hier nu wel even skippen.
Wie er wel mee bezig gaat: kijk even wat je nog kan verbeteren aan die config.
[
Voor 23% gewijzigd door
McKaamos op 31-03-2020 08:48
]
:strip_exif()/i/1354526135.png?f=thumbmini)
:strip_exif()/u/45517/GG85Logo.gif?f=community)
/u/848253/crop5b1fedd835c9e_cropped.png?f=community)
/u/847895/crop5db04067d9841_cropped.png?f=community)
/u/34186/crop62e07d174532d_cropped.png?f=community)
:strip_icc():strip_exif()/u/65626/crop5e441ed581fc5_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/50085/reaperavatar.jpg?f=community){kind=avatar}
)