Hoe een website superveilig maken?

[HenkEisDS]

Voor een website waarvan het beheer sporadisch is, maar het gebruik dagelijks wil ik fatsoenlijke beveiliging introduceren die minder beheer vereist dan normaal. Ze weet ik bijvoorbeeld dat de huidige beheerder zelf wel eens een scriptje schrijft en die op de site plempt en aangezien ik zelf verantwoordelijk ben voor de updates weet ik dat dit ook sporadisch gebeurt. Joomla draait er en aangezien je hier ongeupdate een sitting duck bent voor hacker wil ik deze voor zijn.

Het idee is dat als joomla zelf niet eens te benaderen is door gebruikers die niet inloggen de automated scripts die het web afstruinen naar vulnerabilities al bij voorbaat buiten de deur gehouden worden. Dit lijkt mij de beste manier om een site zo lek als een mandje toch online te laten staan zonder last te hebben van ongewenst bezoek.

Ik weet dat je via een .htpasswd bestand kan prompten om een gebruikersnaam en wachtwoord. Dit lijkt me perfect, maar is dit wel veilig? Zou de joomla installatie hier mee overweg kunnen of moet je die ook rechten geven en is zo het nut van de joomlamap afschermen niet ongedaan gemaakt?

Wellicht had de titel moeten zijn: "Hoe een crappy website toch te beveiligen"

[ Voor 3% gewijzigd door HenkEisDS op 16-08-2013 21:00 ]

[CAPSLOCK2000]

tip 0: minder beheer en wel veilig is bijna een tegenspraak, ik snap het stukje over de scriptjes van de beheerder snap ik niet.

tip 1: defense in depth. Pas meerdere beveiligingsmaatregelen toe. Een enkele laag beveiliging bevat altijd gaten.

tip 2: htpasswd is ok als je het goed gebruikt, maar niet super, lees de handleiding

tip 3: gebruik SSL, anders heeft de rest van de beveilingsmaatregelen weinig zin

tip 4: kun je de server van internet afhalen en achter een VPN stoppen?

tip 5: ip-blokkades, laat alleen verbindingen van bekende IP's toe. In een bedrijfssituatie is dat makkelijk omdat je waarschijnlijk met vaste IP's werkt. Als je met prive-internetverbindingen werkt is het lastiger omdat die geen vast IP hebben. Whitelist in zo'n geval de hele provider, dan blokkeer je nog steeds 99.9% van de rest van internet.

tip 6: er is geen alternatief voor je Joomla up to date houden. Ook met alle bovenstaande maatregelen kan het nog fout gaan. Denk bijvoorbeeld aan de situatie dat een van je medewerkers een virus heeft.

[HenkEisDS]

Dat stukje over scriptjes bedoel ik mee dat gebruikers die admin zijn wel eens zelf in elkaar geknutselde modules online zetten, en dat is wat mij betreft prima. Probleem is wel dat ik geen zin heb om hun progsels te gaan nalopen op gaten.

SSL is een goede tip denk ik. Ik zie dat Neostrada de nieuwe hostingpartij dit ondersteunt, dus dat zou niet zo moeilijk hoeven zijn.

Htpasswd kan ik volgens mij niet goed gebruiken als ik dit zo lees:

Web password files such as those managed by htpasswd should not be within the Web server's URI space -- that is, they should not be fetchable with a browser.

Aangezien ik op een shared host zit kan ik volgens mij het htpasswd bestand niet ergens plaatsen buiten de URI space. Aan de andere kant boeit dat niet heel veel, automated hacking scripts zullen de site wel overslaan als ze een htpasswd beveiliging tegen komen gok ik zo.

Server van het internet afhalen en achter een VPN stoppen lijkt me te moeilijk voor de gebruikers. Net als alleen bekende IP's toelaten, want dit kost me weer werk om nieuwe bekende IP's te whitelisten. Wel een goed idee trouwens, maar in mijn situatie niet praktisch.

Ik zie trouwens nu dat nieuwere versies van Joomla een auto-update functie hebben. Alleen update je daar alleen de core mee en niet je modules/componenten. Zou opzich ook al flink wat schelen.

Zijn er nog andere zaken die ik eenvoudig kan beveiligen zonder al teveel te hoeven updaten?

[CAPSLOCK2000]

Zelf geknutselde scriptjes voor een verouderde Joomla op een shared webhost zonder ruimte buiten de webroot en een admin met gebrek aan tijd. Sorry voor de negatieve toon, maar het is een recept voor een ramp. In een ideale wereld zou ik de stekker er uit trekken tot er meer budget is om het goed te doen.

Ik heb nog wel wat ideetjes maar die gaan er van uit dat je controle hebt over webserver en dat heb jij niet.

Nog 1 ideetje voor je wachtwoorden: gebruik een externe authenticatie-service, dan hoef je zelf geen wachtwoorden bij te houden op je server, dat laat je aan een ander over. Kijk eens naar OpenID of OAuth ofzo. Na bovenstaande verhaal vrees ik alleen dat het implenteren hiervan te veel werk zal zijn.

[HenkEisDS]

Tnx juist voor de negatieve toon. Het is geen gelukkig geen bedrijfskritische website, het is een site van een vriendengroep waarop plaatjes / filmpjes gedumpt worden, een forum en een wiki.

Aangezien de site gemigreerd moet worden toch maar eens proberen de hele webroot te beveiligen met htpasswd.

[grippa]

CAPSLOCK2000 schreef op zaterdag 17 augustus 2013 @ 09:58:
tip 0: minder beheer en wel veilig is bijna een tegenspraak, ik snap het stukje over de scriptjes van de beheerder snap ik niet.

tip 1: defense in depth. Pas meerdere beveiligingsmaatregelen toe. Een enkele laag beveiliging bevat altijd gaten.

tip 2: htpasswd is ok als je het goed gebruikt, maar niet super, lees de handleiding

tip 3: gebruik SSL, anders heeft de rest van de beveilingsmaatregelen weinig zin

tip 4: kun je de server van internet afhalen en achter een VPN stoppen?

tip 5: ip-blokkades, laat alleen verbindingen van bekende IP's toe. In een bedrijfssituatie is dat makkelijk omdat je waarschijnlijk met vaste IP's werkt. Als je met prive-internetverbindingen werkt is het lastiger omdat die geen vast IP hebben. Whitelist in zo'n geval de hele provider, dan blokkeer je nog steeds 99.9% van de rest van internet.

tip 6: er is geen alternatief voor je Joomla up to date houden. Ook met alle bovenstaande maatregelen kan het nog fout gaan. Denk bijvoorbeeld aan de situatie dat een van je medewerkers een virus heeft.

weet je uberhaupt wel wat ssl doet?
'server van internet halen en achter een vpn stoppen' ? *knip*

[ Voor 2% gewijzigd door Rupie op 20-08-2013 19:36 ]

[Verwijderd]

Als het toch maar een site is van een vriendengroep maakt het ook niet uit dat ie gehackt wordt (geen belangrijke bedrijfsinformatie etc). Stel gewoon gebruikers/wachtwoorden in die jullie nergens anders gebruiken, en maak backups. Site gehackt? -> site updaten -> backup terug -> niks aan de hand.

En er is altijd mod_security. Mochten je gebruikers dan scripts maken die falen, heb je iig de basic bugs eruit.
http://www.howtoforge.com/apache_mod_security

[ Voor 17% gewijzigd door Verwijderd op 21-08-2013 11:10 ]

[LnC]

Verwijderd schreef op woensdag 21 augustus 2013 @ 11:01:
Als het toch maar een site is van een vriendengroep maakt het ook niet uit dat ie gehackt wordt (geen belangrijke bedrijfsinformatie etc). Stel gewoon gebruikers/wachtwoorden in die jullie nergens anders gebruiken, en maak backups. Site gehackt? -> site updaten -> backup terug -> niks aan de hand.

Pardon? Dat is bijna hetzelfde als je voordeur open laten staan en je schouders ophalen als er ingebroken wordt. Want er staat toch niks waardevols in....

Zoals met alles, voorkomen is beter dan genezen.

[Verwijderd]

LnC schreef op woensdag 21 augustus 2013 @ 12:29:
[...]
Pardon? Dat is bijna hetzelfde als je voordeur open laten staan en je schouders ophalen als er ingebroken wordt. Want er staat toch niks waardevols in....

Ja dat is inderdaad hetzelfde. Want er staat inderdaad niks waardevols in. Puntje puntje puntje. En wat meneer hier omschrijft is dat hij geen andere keuze heeft dan "zijn voordeur open laten staan", omdat gebruikers zelfgemaakte plugins toevoegen, en hij geen tijd heeft om die te checken op fouten. Dus kan je best even kijken naar wat een daadwerkelijke 'hack' voor impact heeft.

En wat hebben sommige mensen toch met vage vergelijkingen met huizen? Van mij mogen criminelen elke dag m'n huis (waar geen privégegevens in liggen) leegroven, als ik met een magisch knopje al m'n spullen terug kon toveren (backup), om vervolgens te zien hoe ze hebben ingebroken (logs), zodat ik het punt van inbreken gratis (-kosten security audit) dicht kan timmeren (patch). Zie het als een honeypot

[u_nix_we_all]

Verwijderd schreef op woensdag 21 augustus 2013 @ 17:06:
[...]


Ja dat is inderdaad hetzelfde. Want er staat inderdaad niks waardevols in. Puntje puntje puntje. En wat meneer hier omschrijft is dat hij geen andere keuze heeft dan "zijn voordeur open laten staan", omdat gebruikers zelfgemaakte plugins toevoegen, en hij geen tijd heeft om die te checken op fouten. Dus kan je best even kijken naar wat een daadwerkelijke 'hack' voor impact heeft.

En wat hebben sommige mensen toch met vage vergelijkingen met huizen? Van mij mogen criminelen elke dag m'n huis (waar geen privégegevens in liggen) leegroven, als ik met een magisch knopje al m'n spullen terug kon toveren (backup), om vervolgens te zien hoe ze hebben ingebroken (logs), zodat ik het punt van inbreken gratis (-kosten security audit) dicht kan timmeren (patch). Zie het als een honeypot

Eerste wat zo'n hacker doet is het systeem gebruiken om spam mee te versturen. Dan verdient hij er nog wat aan, jou data zal hem worst zijn. Maar voor je het weet staat je domain op een spamlijst, en daar wordt je niet blij van.

Meerdere lagen van beveiliging is een goed idee. Een publieke webserver kun je natuurlijk niet helemaal wegstoppen achter een firewall, dus dat is geen optie.
Tools die nuttig kunnen zijn:
Fail2ban (+ iptables) : deze houdt de logfiles van je webserver bij, en blokkeert IP's waarvan verdachte requests komen. Hiermee vang je alle scriptjes die op outdated php ed scannen meteen af.
Gelijk ook ssh voor fail2ban aanslingeren, als je die open hebt staan.
IPTables: zo configureren dat er geen mail uit kan. (uitgaand verkeer naar poort 25) Als je wel wilt kunnen mailen, kun je iptables zo configureren dat alleen de process-group waar je sendmail (of whatever MTA) onder draait (meestal root) toegang heeft tot die poort. Dan kunnen ze misschien je webserver hacken, maar nog niet gebruiken om spam te versturen.

[HenkEisDS]

Fail2ban kan ik waarschijnlijk niet installeren, omdat ik alleen CPANEL/PLESK toegang heb tot de server. Hierdoor ook de uitbreidingen hierop niet.

Mail versturen vanaf mijn server vind ik niet echt een issue, mijn hostingpartij zal vanzelf wel aan de bel trekken als ze last van me hebben.

Tnx for the info in ieder geval. Ik ben weer iets wijzer geworden.