Webserver user-beveiliging

[Verwijderd]

Hi,

Ik ben bezig een eigen webserver te configgen om te kunnen gaan plaatsen bij een provider. Een eventueel toekomstplan is om andere gebruikers toe te laten op deze server. Met hun eigen domein, mail, etcetera. Het gaat om een Linux bak (Debian)

Het probleem waar ik nu mee zit is het volgende: als die gebruikers ook telnet-toegang krijgen, hoe zorg ik er dan voor dat die gebruikers mijn server niet ruineren.

Concrete vraag is: Welke commando's moet ik afschermen voor de gebruikersgroep voor webserver-users (en waarschijnlijk ook de Nobody user omdat die de PHP scripts uitvoert ). Dus niet alleen de schrijfrechten in bepaalde directories afschermen (dat begrijp ik nog wel), maar hoe weiger ik gebruikers toegang tot commando's als halt, shutdown, kill, enzo, en welke commando's zou ik allemaal moeten afschermen?

Alvast bedankt

[supakeen]

Waarom moet het telnet zijn? En niet ssh

[Verwijderd]

Op maandag 20 mei 2002 15:01 schreef zmn het volgende:
Waarom moet het telnet zijn? En niet ssh

Maakt in principe geen verschil voor het probleem. SSH is inderdaad beter voor een server, maar ik heb nog steeds het probleem dat ik niet weet hoe en welke processen ik moet afschermen

[Steije]

www.openwall.com
www.grsecurity.net

[Rob]

Op maandag 20 mei 2002 15:02 schreef freewilly het volgende:

[..]

Maakt in principe geen verschil voor het probleem. SSH is inderdaad beter voor een server, maar ik heb nog steeds het probleem dat ik niet weet hoe en welke processen ik moet afschermen

Je zorgt er dan voor dat de users geen uitvoer (X) rechten krijgen, je kunt daarbij de belangrijke commando's hernoemen.

[Verwijderd]

Op maandag 20 mei 2002 14:59 schreef freewilly het volgende:
Concrete vraag is: Welke commando's moet ik afschermen voor de gebruikersgroep voor webserver-users (en waarschijnlijk ook de Nobody user omdat die de PHP scripts uitvoert ). Dus niet alleen de schrijfrechten in bepaalde directories afschermen (dat begrijp ik nog wel), maar hoe weiger ik gebruikers toegang tot commando's als halt, shutdown, kill, enzo, en welke commando's zou ik allemaal moeten afschermen?

Alvast bedankt

Ik heb vrijwel alle commando's in /sbin/ en /usr/sbin een chmod 500 gegeven. In /usr/local/sbin heeft bijna alles de permissie 550. Haal in ieder geval de suid weg van commando's zoals halt, reboot, shutdown. Het is nog beter om er gewoon voor te zorgen dat users die bestanden niet kunnen uitvoeren.

code:

240 -r-x------  4 root  wheel  227212 May 12 22:49 /sbin/halt

Kill zou ik wel beschikbaar houden voor de users. Ze kunnen er toch alleen maar processen die ze zelf hebben gestart mee killen.

[deadinspace]

Op maandag 20 mei 2002 15:21 schreef epauli het volgende:
Ik heb vrijwel alle commando's in /sbin/ en /usr/sbin een chmod 500 gegeven. In /usr/local/sbin heeft bijna alles de permissie 550.

Daarmee maak je alleen maar je systeem kreupel. Sommige dingen in die dirs, zoals ifconfig, lsof enzo worden ook gebruikt door progs die als non-root draaien.

Haal in ieder geval de suid weg van commando's zoals halt, reboot, shutdown.

Die zijn in Debian standaard niet suid.

Het is nog beter om er gewoon voor te zorgen dat users die bestanden niet kunnen uitvoeren.

Waarom dat in godsnaam?
Shutdown moet om de machine uit te zetten het runlevel veranderen. Om dat te doen moet shutdown naar /dev/initctl schrijven. Shutdown en vriendjes onuitvoerbaar maken voor non-root users heeft dus geen enkel nut aangezien je zo zelf een progje kunt maken dat het runlevel verandert (hell, een creatieve constructie met 'echo bledder > /dev/initctl' zou volstaan).

Verder is /dev/initctl is rw------- root, dus de kernel laat simpelweg *alleen* maar toe dat root ernaar schrijft. Als je user dus als halt uitvoert dan zou je een EACCES op /dev/initctl van de kernel krijgen.

Kill zou ik wel beschikbaar houden voor de users. Ze kunnen er toch alleen maar processen die ze zelf hebben gestart mee killen.

En dat geldt meteen voor alle andere commando's.
Die commando's non-executable maken heeft ook hier geen nut. Als je /bin/kill non-executable zou maken dan zou je zelf een progje kunnen schrijven dat de kill() systemcall aanroept. Zelfde verhaal voor rm, cp, lsof, ps, enz, enz.

[Verwijderd]

met andere woorden: ik hoef alleen dat initctl bestandje non-writable te maken voor niet-root users het belangrijkste is dat de server in de lucht blijft en gebruikers niet elkaars bestanden gaan zitten mollen.

[blaataaps]

Op maandag 20 mei 2002 17:37 schreef freewilly het volgende:
met andere woorden: ik hoef alleen dat initctl bestandje non-writable te maken voor niet-root users

/dev/initctl is al non-writable voor iedereen anders dan root (zoals deadinspace ook al zei). En een standaard debian install overleeft een rm -rf / van een gewone user al wel. En gewone users mogen elkaars bestanden sowieso niet veranderen.

[Verwijderd]

Op maandag 20 mei 2002 17:35 schreef deadinspace het volgende:
Daarmee maak je alleen maar je systeem kreupel. Sommige dingen in die dirs, zoals ifconfig, lsof enzo worden ook gebruikt door progs die als non-root draaien.

Daar merk ik dan heel erg weinig van. Het systeem draait al maanden zonder problemen. Ik zag een paar weken geleden dat XS4ALL op de nieuwe FreeBSD shell server dezelfde methode heeft toegepast.

[deadinspace]

Op maandag 20 mei 2002 17:37 schreef freewilly het volgende:
met andere woorden: ik hoef alleen dat initctl bestandje non-writable te maken voor niet-root users het belangrijkste is dat de server in de lucht blijft en gebruikers niet elkaars bestanden gaan zitten mollen.

Dat kunnen users dus al sowieso niet.
Een process mag alleen signals sturen naar processes die onder dezelfde user draaien, mag alleen files lezen/schrijven/removen/aanmaken als de permissies op de files (of onderliggende dir) dat toelaten. (uitzondering hierop is UID 0, aka root, die praktisch alles mag.
Dat is allemaal op kernel-level vastgelegd; het doet er dus niet toe welk programma dat probeert.

De enige programma's die hierop een uitzondering vormen zijn de programma's die setuid (SET User ID, analoog is er ook nog setgid) zijn. Setuid programma's worden uitgevoerd alsof ze door de owner werden opgestart. Als jij als user een setuid programma van root opstart dan heeft dat programma root-permissies.

Als zo'n programma dus niet oppast wat hij doet, dan kan dat programma een beveiligings-risico vormen. Typische voorbeelden van setuid root programma's zijn /bin/ping en /bin/su.

Je kunt met 'find / -perm +6000 -type f' kijken welke files op je systeem allemaal setuid of setgid zijn en dan per file bepalen of dat zo moet blijven (merk op dat als je permissies verandert dat dpkg de oude perms vrolijk terugzet als hij die file upgradet).

Waar je ook naar kunt kijken als je niet wilt dat users je systeem mollen is quota. Daarmee kun je per user instellen hoeveel diskruimte ze maximaal mogen gebruiken.

Op maandag 20 mei 2002 18:11 schreef epauli het volgende:
Daar merk ik dan heel erg weinig van. Het systeem draait al maanden zonder problemen. Ik zag een paar weken geleden dat XS4ALL op de nieuwe FreeBSD shell server dezelfde methode heeft toegepast.

Nee, maar als je dan als user ifconfig of lsof wilt doen dan kan dat weer niet zomaar... Das onhandig. En ik kan me best voorstellen dat er progs zijn die lsof-functionaliteit nodig hebben.

[Verwijderd]

Op maandag 20 mei 2002 19:41 schreef deadinspace het volgende:

[..]

Hey! Thanx man ben nog een n00b op Linux-gebied, wist niet dat die beveiliging allemaal standaard zo netjes inelkaar zat ik kan in elk geval weer ff vooruit

[Verwijderd]

Ik zou imho geeneens een compiler installen op die doos. Gewoon met de debian packages werken. Verder kun je nog het volgende doen:

_geen_ telnet installen, reden lijkt me duidelijk
ssh access alleen toelaten vanaf bekende ip adressen. Er is zelfs een patch voor sshd om users te chroot()'en naar hun homedir op het moment dat ze inloggen.
met de grsec patch users zga alles verbieden en het systeem verder dicht spijkeren.
van je belangrijke dirs alleen de user/group rechten setten, dan kun je iedere user die _wel_ toegang moet hebben tot die binaries daar gewoon nog bij
een te dik geconfigde packet filter installen (zijn genoeg voorbeelden van)
portsentry draaien om probes te detecten
_veel_ docs lezen om alles wat ik hier vergeten ben te implementeren

[Verwijderd]

Op maandag 20 mei 2002 20:50 schreef r3b00t het volgende:
Ik zou imho geeneens een compiler installen op die doos. Gewoon met de debian packages werken. Verder kun je nog het volgende doen:

_geen_ telnet installen, reden lijkt me duidelijk
ssh access alleen toelaten vanaf bekende ip adressen. Er is zelfs een patch voor sshd om users te chroot()'en naar hun homedir op het moment dat ze inloggen.
met de grsec patch users zga alles verbieden en het systeem verder dicht spijkeren.
van je belangrijke dirs alleen de user/group rechten setten, dan kun je iedere user die _wel_ toegang moet hebben tot die binaries daar gewoon nog bij
een te dik geconfigde packet filter installen (zijn genoeg voorbeelden van)
portsentry draaien om probes te detecten
_veel_ docs lezen om alles wat ik hier vergeten ben te implementeren

En hoe wil jij zonder compiler de nieuwste php/apache installeren ? ik wil nog wel een *beetje* systeem overhouden... gaarne

[Verwijderd]

apt-get install apache
apt-get install php4
apt-get install what ever u want


en met een beetje tweaken heb je nog een best functionele box over ^_^

[Mark]

Op maandag 20 mei 2002 20:51 schreef freewilly het volgende:

[..]

En hoe wil jij zonder compiler de nieuwste php/apache installeren ? ik wil nog wel een *beetje* systeem overhouden... gaarne

PHP/Apache/Whatever je wilt op een andere (gelijkwaardige) machine compileren misschien ??