Beste CHMOD voor openbare map

[tom.cx]

Ik heb een webserver draaien en wil graag de beveiliging verder opvoeren.
Nu draai ik de site vanaf /home/username/www i.p.v. /var/www/. Maakt het rechten een stuk eenvoudiger. Ik log ook elke keer in als de speciale gebruiker die bij het domein hoort.
Nu heb ik alle poorten dicht gezet behalve SSH ₍₂₂₎, HTTP ₍₈₀₎ en HTTPS ₍₄₄₃₎. Ook als je drie keer een verkeerde login doet wordt je na 3 pogingen voor 1 maand geblokkeerd. Dus dat zit wel goed. Met root inloggen doe ik alleen als ik eenmaal in de server zit d.m.v. het commando SU.

Mijn vraag
Nu zit ik alleen met het volgende. Ik heb bijna alle mappen in /home/username/www op chmod 777 moeten zetten. Ik heb voor FTP namelijk een speciale gebruiker en die kan niks uploaden als ik de chmod niet op 777 zet. Hoe kan ik er voor zorgen dat deze niet op 777 hoeven gezet te worden en toch met een andere user kan uploaden naar de betreffende map. Ik wil niet dat de username gelijk is aan de usernaam home directory waar ik naar upload.

Ik zat er zelf aan te denken om een speciale FTP groep te koppelen aan de /home/username/www en deze dan een chmod te geven. Ik weet alleen niet hoe dat kan op Debian. En wordt van Google ook niet echt wijzer.

Relevante software en hardware die ik gebruik
Debian 8.4
Apache (last version)
PHP (last version)

Als je deze regel leest dank ik je in elk geval al voor het lezen

Aanvulling: Ik werk nog niet zo heel lang met Debian/Linux server. Nu ongeveer een jaar en ken helaas nog niet alles. Zou aan de andere kant wel knap zijn

[ Voor 5% gewijzigd door tom.cx op 25-07-2016 09:44 ]

[CurlyMo]

tom.cx schreef op maandag 25 juli 2016 @ 08:50:
Nu heb ik alle poorten dicht gezet behalve SSH ₍₂₂₎, HTTP ₍₈₀₎ en HTTPS ₍₄₄₃₎. Ook als je drie keer een verkeerde login doet wordt je na 3 pogingen voor 1 maand geblokkeerd. Dus dat zit wel goed. Met root inloggen doe ik alleen als ik eenmaal in de server zit d.m.v. het commando SU.

SSH keys gebruiken is nog beter.

Ik zat er zelf aan te denken om een speciale FTP groep te koppelen aan de /home/username/www en deze dan een chmod te geven. Ik weet alleen niet hoe dat kan op Debian. En wordt van Google ook niet echt wijzer.

Ik kan me niet voorstellen dat je niks vind. Toevoegen van gebruikers aan meerdere groepen staat toch echt uitvoering en op zeer veel sites uitgelegd. Je kan eventueel ook kijken naar ACL's. Dat maakt het rechten beheer nog uitgebreider.

[McKaamos]

Ok, meerdere opties.

1: FTP lekker achterwege laten en gebruik maken van een SSH-Client met geintegreerde file-transfer. Bijvoorbeeld Bitvise SSH Client. En dan gewoon inloggen met de user die bij de betreffende map/home-directory hoort.
Veiligste optie, je behoudt scheiding en vergeet die FTP-gebruiker.

edit:

Wat hier boven mij ook zegt, gebruik SSH ook nog in combinatie met key-files voor de login.
zie b.v.: https://www.digitalocean....ication-on-a-linux-server
Als je het dicht timmert, pak deze optie. Maak voor elke user een keypair en log gewoon per user in.

2: Chmod 777 gebruiken. Lekker onveilig. writeable by everyone... whoops...

3: Een aparte group aanmaken en alle users, inclusief de FTP user, lid maken van die groep (groupadd en usermod commando's). Daarmee wordt je chmod al 770. Scheelt ietsjes, alleen schrijfbaar door de gebruiker zelf en de groep(en) waar de gebruiker bij hoort.
Je dacht wel in de goeie richting, maar vanaf de verkeerde kant. Je geeft de map geen group, maar de user.

4: FTP user maken met zijn eigen FTP-upload map en een cronscript wat elke zoveel tijd checkt of je nieuwe content hebt geplaatst, en dit verzet naar de user-homedir waar het heen moet.

[ Voor 30% gewijzigd door McKaamos op 25-07-2016 09:09 ]

[tom.cx]

CurlyMo schreef op maandag 25 juli 2016 @ 08:59:
[...]

SSH keys gebruiken is nog beter.


[...]

Ik kan me niet voorstellen dat je niks vind. Toevoegen van gebruikers aan meerdere groepen staat toch echt uitvoering en op zeer veel sites uitgelegd. Je kan eventueel ook kijken naar ACL's. Dat maakt het rechten beheer nog uitgebreider.

ACL's is nieuw voor mij. Ik ben pas een jaartje bezig met Debian en ken nog niet alles. Zal het vanavond eens opzoeken. En wat ik zocht kon ik niet op Google.

McKaamos schreef op maandag 25 juli 2016 @ 09:02:
Ok, meerdere opties.

1: FTP lekker achterwege laten en gebruik maken van een SSH-Client met geintegreerde file-transfer. Bijvoorbeeld Bitvise SSH Client. En dan gewoon inloggen met de user die bij de betreffende map/home-directory hoort.
Veiligste optie, je behoudt scheiding en vergeet die FTP-gebruiker.

edit:

Wat hier boven mij ook zegt, gebruik SSH ook nog in combinatie met key-files voor de login.
zie b.v.: https://www.digitalocean....ication-on-a-linux-server
Als je het dicht timmert, pak deze optie. Maak voor elke user een keypair en log gewoon per user in.

Bedankt voor de tip. Ik zal hier eens naar kijken. Heb nog nooit eerder met SSH key gewerkt.

McKaamos schreef op maandag 25 juli 2016 @ 09:02:

2: Chmod 777 gebruiken. Lekker onveilig. writeable by everyone... whoops...

Ik weet het. Daarom wil ik het graag veranderen. Nu verander ik ook zelfs steeds de chmod als ik klaar ben. Veel werk en daar wil ik ook vanaf.

McKaamos schreef op maandag 25 juli 2016 @ 09:02:
3: Een aparte group aanmaken en alle users, inclusief de FTP user, lid maken van die groep (groupadd en usermod commando's). Daarmee wordt je chmod al 770. Scheelt ietsjes, alleen schrijfbaar door de gebruiker zelf en de groep(en) waar de gebruiker bij hoort.
Je dacht wel in de goeie richting, maar vanaf de verkeerde kant. Je geeft de map geen group, maar de user.

Dat is wel beter en de groepen zijn tot nu toe zeer beperkt.

McKaamos schreef op maandag 25 juli 2016 @ 09:02:
4: FTP user maken met zijn eigen FTP-upload map en een cronscript wat elke zoveel tijd checkt of je nieuwe content hebt geplaatst, en dit verzet naar de user-homedir waar het heen moet.

Hmmm. Dat klinkt als een goed idee. Echter heb ik meerdere sites en meerdere ftp users die in verschillende mappen kunnen schrijven. Dat zal dan vrees ik geen optie zijn.

[Hero of Time]

ACLs zijn leuk en zeer uitgebreid, maar het kan ook aardig wat complexiteit opleveren. Als je namelijk ACLs gebruikt en je voert een chmod of chown uit, dan wordt de ACL verwijdert.

Wat je kan doen, is de gebruiker waar de webserver onder draait toevoegen aan een groep waar de SFTP gebruikers ook in zitten. Dan worden de rechten op de mappen 750. Apache hoeft tenslotte alleen maar te lezen. De SFTP gebruikers schrijven dan naar hun afzonderlijke map, zonder dat ze bij elkaar kunnen schrijven (maar wel lezen).

Als je SSH op de server nog eens zo instelt dat de gebruikers in de sftp groep in een chroot zitten, die binden aan hun home map, kunnen ze ook niet door het systeem heen. Je beheer gebruiker zit dan niet in die groep en kan gewoon via 'su' root worden en het beheer doen. Hiermee scherm je het nog een stukje verder af, zodat niet zomaar het hele systeem open ligt als een van de SFTP gebruikers gekraakt wordt.

[8088]

Met PHP-FPM kun je PHP draaien als de eigenaar van de bestanden.

tom.cx schreef op maandag 25 juli 2016 @ 09:42:
Hmmm. Dat klinkt als een goed idee.

Het klinkt als een verschrikkelijk slecht idee. FTP is inherent onveilig. De voorgestelde SFTP (met keys uiteraard, zoals ook al eerder is genoemd) chroot-oplossing klinkt als een veel beter idee.

Hero of Time schreef op maandag 25 juli 2016 @ 12:25:
Apache hoeft tenslotte alleen maar te lezen.

Een bestand uploaden via de webapplicatie of schrijven naar een logfile zijn kan soms best handig zijn.

[tom.cx]

Bedankt voor alle reacties.

Ik ga ze nog een keer nalezen en het een en ander toepassen. Het is momenteel een hobby waar ik mij meer in wil verdiepen.

Groet Tom.

[Hero of Time]

8088 schreef op maandag 25 juli 2016 @ 17:44:

[...]

Een bestand uploaden via de webapplicatie of schrijven naar een logfile zijn kan soms best handig zijn.

Dan maak je een speciale map voor die webapplicatie aan waar Apache in kan schrijven, big whoop.

En log bestanden als access_log en error_log worden al geschreven door het systeem. Daar hebben de rechten op de webroot niets mee te maken.

[8088]

Hero of Time schreef op dinsdag 26 juli 2016 @ 12:03:
Dan maak je een speciale map voor die webapplicatie aan waar Apache in kan schrijven, big whoop.

't Is weer een extra handeling die door een generieke oplossing als PHP-FPM overbodig wordt gemaakt.

En log bestanden als access_log en error_log worden al geschreven door het systeem. Daar hebben de rechten op de webroot niets mee te maken.

Dat klopt, maar ik vind het wel prettig om de logging van mijn applicaties te scheiden van die van de webserver. Bovendien is het slechts ter illustratie; er zijn legio redenen te verzinnen waarom het handig is om te kunnen schrijven naar de webdir. En als daar geeigende methodes voor bestaan, zie ik geen enkele reden om die niet toe te passen.

[Hero of Time]

8088 schreef op dinsdag 26 juli 2016 @ 12:22:
[...]

't Is weer een extra handeling die door een generieke oplossing als PHP-FPM overbodig wordt gemaakt.

Zoals ik al zei, big woop. En je gaat er wel gelijk vanuit dat je webapplicatie in PHP draait, en niet iets anders. Zonder PHP heb je nogal weinig aan php-fpm.

[...]

Dat klopt, maar ik vind het wel prettig om de logging van mijn applicaties te scheiden van die van de webserver. Bovendien is het slechts ter illustratie; er zijn legio redenen te verzinnen waarom het handig is om te kunnen schrijven naar de webdir. En als daar geeigende methodes voor bestaan, zie ik geen enkele reden om die niet toe te passen.

Dan geef je per vhost aan wat het logbestand is waar het in moet gaan schrijven. TS vraagt voor een basis, die is gegeven. Nu ga jij er dieper op in, zonder te weten of de TS dat ook echt nodig heeft.

[8088]

Hero of Time schreef op dinsdag 26 juli 2016 @ 12:28:
Zoals ik al zei, big woop.

Iedere handmatige handeling die voorkomen had kunnen worden door het inzetten van een generieke oplossing is wat mij betreft inderdaad een big whoop.

En je gaat er wel gelijk vanuit dat je webapplicatie in PHP draait, en niet iets anders.

Klopt, dat is immers wat er in de TS staat. Maar wat mij betreft mag je PHP-FPM ook vervangen door FastCGI. Het gaat om het idee.

Dan geef je per vhost aan wat het logbestand is waar het in moet gaan schrijven.

Daarmee scheid je je applicatielog niet van die van de webserver. En zoals ik al zei is logs wegschrijven slechts een voorbeeld. Als je een plaatje wilt uploaden, een dynamische sitemap wilt genereren, of sessies weg wilt schrijven, dan heb je toch echt schrijfrechten nodig.

TS vraagt voor een basis, die is gegeven. Nu ga jij er dieper op in, zonder te weten of de TS dat ook echt nodig heeft.

tom.xc vraagt naar tips om zijn LA(M?)P-stack verder te beveiligen. Mijn bedoeling is 'm te hepen bij het maken van een weloverwogen keuze. Als 'ie niets aan mijn opmerkingen heeft, dan staat het 'm vrij om ze links te laten liggen.

[tom.cx]

8088 schreef op dinsdag 26 juli 2016 @ 13:07:
[...]

tom.xc vraagt naar tips om zijn LA(M?)P-stack verder te beveiligen. Mijn bedoeling is 'm te hepen bij het maken van een weloverwogen keuze. Als 'ie niets aan mijn opmerkingen heeft, dan staat het 'm vrij om ze links te laten liggen.

Ik draai een LAP server. Linux, Apache, Php. Geen MYSQL.

[igmar]

Hero of Time schreef op maandag 25 juli 2016 @ 12:25:
ACLs zijn leuk en zeer uitgebreid, maar het kan ook aardig wat complexiteit opleveren. Als je namelijk ACLs gebruikt en je voert een chmod of chown uit, dan wordt de ACL verwijdert.

Dat klopt echt niet : ACL's blijven bewaard, ook na een chmod / chown.

Wat je kan doen, is de gebruiker waar de webserver onder draait toevoegen aan een groep waar de SFTP gebruikers ook in zitten. Dan worden de rechten op de mappen 750. Apache hoeft tenslotte alleen maar te lezen. De SFTP gebruikers schrijven dan naar hun afzonderlijke map, zonder dat ze bij elkaar kunnen schrijven (maar wel lezen).

Als je SSH op de server nog eens zo instelt dat de gebruikers in de sftp groep in een chroot zitten, die binden aan hun home map, kunnen ze ook niet door het systeem heen. Je beheer gebruiker zit dan niet in die groep en kan gewoon via 'su' root worden en het beheer doen. Hiermee scherm je het nog een stukje verder af, zodat niet zomaar het hele systeem open ligt als een van de SFTP gebruikers gekraakt wordt.

Je sites onder een aparte user draaien is beter, al is dat niet even makkelijk.

[Hero of Time]

igmar schreef op maandag 01 augustus 2016 @ 22:02:
[...]

Dat klopt echt niet : ACL's blijven bewaard, ook na een chmod / chown.

Ah, juist. Even m'n RHCSA boek erbij gepakt, want ik was het ook niet meer zeker. Daar staat idd dat de group-owner rechten niet verandert, maar de ACL mask.