[linux -> bash] hoe te beveiligen?

[decramy]

OK, we hebben op school een bakkie met LINUX

Jehh denk je vast, maar deze bak is al 2x gehackt

Dus heeft onze systeembeheerder ervoor gekozen om iedereen als shell 'mc' te geven...
Alleen, nu kun je dus nix... Geen files naar jezelf toe mailen en ...
je kunt dus gewoon nix

Maar nu wil ik onze systeembeheerder een oplossing geven, dat WIJ gewoon bash hebben maar wel een beveiligde versie.

De hacker gebruikte tot 2x aan toe een perl scrippie om het root-pwd te kraken (natuurlijk wel copietje gehouden )

Maar nu ff samenvattend: Ik zoek een iets om bash te beveiligen. Er mogen alleen maar een paar commando`s uitgevoerd worden, en eigenlijk moet dit heel simpel aan te passen zijn.
We draaien op een RH7.1based systeem...

[kenneth]

Op vrijdag 08 maart 2002 14:33 schreef decramy het volgende:
De hacker gebruikte tot 2x aan toe een perl scrippie om het root-pwd te kraken (natuurlijk wel copietje gehouden )

Wordt het niet gewoon tijd om over te gaan op shadow passwords enzovoort?

Symptoombestrijding helpt je niet echt...

[_cyclops_]

"k denk dat je misschien naar 'n soort virtual machine moet zoeken.. of misschien wel geen redhat?
BIj debian zou je simpel een apt-get upgrade kunnen doen om de security weer op pijl te krijgen...

en overigens denk ik dat 't veranderen van bash naar mc ook nietecht gaat helpen, vanuit mc kun je toch gewoon /bin/bash opstarten!?

[decramy]

Op vrijdag 08 maart 2002 14:34 schreef mithalph het volgende:

[..]

Wordt het niet gewoon tijd om over te gaan op shadow passwords enzovoort?

Symptoombestrijding helpt je niet echt...

hebben we al

[wzzrd]

Op vrijdag 08 maart 2002 14:36 schreef _cyclops_ het volgende:
"k denk dat je misschien naar 'n soort virtual machine moet zoeken.. of misschien wel geen redhat?
BIj debian zou je simpel een apt-get upgrade kunnen doen om de security weer op pijl te krijgen...

en overigens denk ik dat 't veranderen van bash naar mc ook nietecht gaat helpen, vanuit mc kun je toch gewoon /bin/bash opstarten!?

Sure, een apt-get zou ervoor zorgen dat je root password niet te hacken is Weer zo'n overmatige debian adept
Anyway, als het om een Perl scriptje ging, zou ik zoeken naar een manier om Perl af te schermen van de buitenwereld.
En shadowen natuurlijk.

[decramy]

Op vrijdag 08 maart 2002 14:36 schreef _cyclops_ het volgende:
"k denk dat je misschien naar 'n soort virtual machine moet zoeken.. of misschien wel geen redhat?
BIj debian zou je simpel een apt-get upgrade kunnen doen om de security weer op pijl te krijgen...

Onze systeembeheerder wil perse op dit systeem blijven draaien

Op vrijdag 08 maart 2002 14:36 schreef _cyclops_ het volgende:
en overigens denk ik dat 't veranderen van bash naar mc ook nietecht gaat helpen, vanuit mc kun je toch gewoon /bin/bash opstarten!?

Nee, als je mc als shel hebt, kun je nix doen. ook ctrl-o werkt niet...
Dit omdat je geen bash draait

[kenneth]

Op vrijdag 08 maart 2002 14:38 schreef decramy het volgende:

[..]

hebben we al

Ik doelde eik meer op de 'enzovoort' dan het specifieke 'shadow passwords'
Zorg er gewoon voor dat het systeem goed beveiligd is, dan heb je dat soort stunts als een beperkte bash niet nodig.

[Bigs]

Is die bek wel goed up-to-date gehouden? Want er zijn voor alle distributies natuurlijk tal van local root exploits en inderdaad, shadowed passwords.

[decramy]

Dat heeft geen zin...
Die 'hacker' heeft een user+password gekregen, progie erop, en feesten

[kenneth]

Op vrijdag 08 maart 2002 14:45 schreef decramy het volgende:
Dat heeft geen zin...
Die 'hacker' heeft een user+password gekregen, progie erop, en feesten

Brute force password cracking is heus wel af te vangen hoor.

Het lijkt me een beetje stug dat het allemaal echt zo moet. Dit soort beperkingen aan de user-kant hoeft helemaal niet. Een systeem moet gewoon goed beveiligd worden. Daar is hij toch een systeembeheerder voor?
M.i. is dit de verkeerde aanpak, magoe...

[decramy]

Kijk, we hebben gewoon een systeem beheerder die nix van LINUX weet, dus daar heel voorzichtig mee is...

Ik moet dus nu gewoon een klein 'stappenplan' moeten hebben, en naar hem toe stappen. Ik hoop dat hij dan een testuser maakt, en dat we dan gewoon kunnen klooien...

Maar ik moet dan wel iets hebben...
"updates uitvoren" is dan natuurlijk nix...

[Verwijderd]

je zou even aan de mensen van cyberspace.org kunnen vragen hoe zij het gedaan hebben (daar kan je een gratis shell acount aanvragen en je kan dan emailen en inetten maar daar houd het dan ook gelijk mee op en dat alles onder bash, je moet ze alleen zo ver krijgen dat ze je het uitleggen)
/edit ff url dur bij
http://www.cyberspace.org

[blaataaps]

Op vrijdag 08 maart 2002 14:50 schreef decramy het volgende:

"updates uitvoren" is dan natuurlijk nix...

Wat is er mis met updates uitvoeren? Als je niet update, blijft je systeem zo lek als een mandje.

[ecageman]

De volgende zaken zijn te implementeren:
- Fysieke toegang tot server beveiligen (slot op deur)
- Remote via telnet/ssh niet direct in kunnen loggen als root.
- Alleen bepaalde gebruikers het recht geven om root te kunnen worden. (alleen de systeembeheerders bijv.)

Als iemand dan het root passwd achterhaald, dan kan hij er nog niks mee. Daarnaast gewoon een goed passwd voor root kiezen. Dus geen woorden die in een woordenboek voorkomen. En ook niet een te kort passwd kiezen.

[saryon2413]

Je kan een loggende-bash gebruiken. Dit zal iig een DEEL van de problemen oplossen, omdat bekend zal worden HOE de machine gehackt wordt.(prima te doen...er zijn patches voor bash,en met een beetje spelen in shell.c kan je het zelf ook wel doen, als je C kent, tenminste)

vervolgens moeten ALLE mogelijke exploits nagekeken worden, of die ook aanwezig zijn op de server, en als dat zo is, ff de package updaten. (securityfocus.com is handig)
Overigens, s-bitjes op sommige exploit-bare progjes weghalen kan ook al helpen.

verder...hmm...ja....hmmm.....overbodige meuk wegmikken die toch niet gebruikt worden (ik neem aan dat het een remote shell server is, dus X kan weg, en waarschijnlijk nog wel een heeeeeeeel zooitje andere dingen).

Success....

[decramy]

Op vrijdag 08 maart 2002 14:52 schreef ecageman het volgende:
- Alleen bepaalde gebruikers het recht geven om root te kunnen worden. (alleen de systeembeheerders bijv.)

Als iemand dan het root passwd achterhaald, dan kan hij er nog niks mee. Daarnaast gewoon een goed passwd voor root kiezen. Dus geen woorden die in een woordenboek voorkomen. En ook niet een te kort passwd kiezen.

Ehh, mag ik dan ook ff vragen Hoe je dat doet??

[blaataaps]

Het oplossen zoals in BSD, waar alleen group wheel mag su'en naar root, is een optie.

[decramy]

Op vrijdag 08 maart 2002 14:53 schreef saryon2413 het volgende:
verder...hmm...ja....hmmm.....overbodige meuk wegmikken die toch niet gebruikt worden (ik neem aan dat het een remote shell server is, dus X kan weg, en waarschijnlijk nog wel een heeeeeeeel zooitje andere dingen).

Success....

Bash zelf logt toch ook al?

en we hebben e-smith. daar is X al uitgesloopt, en alle overige dingen ook

[blaataaps]

Op vrijdag 08 maart 2002 14:58 schreef decramy het volgende:

[..]

Bash zelf logt toch ook al?

bash zelf logt, maar die logging is erg makkelijk te omzeilen.

[decramy]

OK, daar moeten we dus naar opzoek

[decramy]

Maar we hebben nu dus allen:
-patches
-loggen van bash.

Maar dit vind ik zelf ook niet alles... Je kunt nu gewoon nog "alles". ff een RPM-pie downloaden via FTP, en je kunt weer vanalles

[blaataaps]

WAT kun je dan?
Is rpm echt zo slecht dat je als nonroot user met een simpel rpm'etje root wordt?

[sundevil]

Op vrijdag 08 maart 2002 14:33 schreef decramy het volgende:

Jehh denk je vast, maar deze bak is al 2x gehackt

De hacker gebruikte tot 2x aan toe een perl scrippie om het root-pwd te kraken (natuurlijk wel copietje gehouden )

Ik ben nieuwsgierig... Wat heeft die hacker uitgespookt??? Hoe weet je dat je gehackt bent? Is de hacker zo 'netjes' geweest om alle logs te verwijderen etc. (sporen uit te wissen)?

Ideeen voor beveiliging: Lijkt me dat je idd niet naar de shell zelf moet kijken, maar naar de rest van de beveiliging (user-rights beperken, root password lekker lang en veel '^@$^#'-shit (lastig te brute forcen).

Wat moet een gebruiker allemaal kunnen eigenlijk? Waar is die server voor bedoeld?

[chem]

ik heb op m'n BSD (macos x) bak de su en sudo acties alleen exectutable gemaakt voor de group 'staff', en de users zitten in 'wheel' (behalve ik en root)

Je kan dan domweg niet jezelf naar root krijgen.

gewoon met chmod + chown ! (tnx kees )

[Creepy]

Lekkere systeembeheerder heb je dan.. een beetje systeembeheerder met wat verstand van linux kan echt een linux machine zo dichttimmeren dat scriptkiddies geen kans meer maken (perl scrippie downloaden en runnen.. das scriptkiddie ja).

Misschien moet die systeembeheerder toch maar eens gaan nadenken om e.e.a. bij te leren??

MC? daarin kan je toch ook shell commando's uitvoeren? Dus lijkt me dat je dat perl scrippie alsnog kan uitvoeren. EN alles wordt gelogd? Lekker boeiend als je het root passwd hebt. Logs cleanen en doorgaan..

[sundevil]

Wat vind ik??

http://www.google.nl/search?q=redhat+7.1+exploit&hl=nl&btnG=Google+zoeken&lr=

Er zijn dus heel veel exploits bekend voor RH7.1 (zoals voor zoveel distro's). Zorg dat je dus WEL alle security updates hebt van RH! Waarchijnlijk dicht je dan ook het gat dat de cracker gebruikt heeft.

[saryon2413]

Bash zelf logt toch ook al?

en we hebben e-smith. daar is X al uitgesloopt, en alle overige dingen ook

Ok, bash logt ja.....maar vraag niet hoe....
komt in ~/.bash_history te staan, die netjes door jou
gewist kan worden....woep....

en e-smith....jaja.....beheerder weigert redhat er af te halen. (persoonlijk, debian zou beter zijn, ivm. redelijk up-to-date fixes)
en dat X er uit gesloopt was is als voorbeeld: er zijn nog
legio andere programmas die NOOIT gebruikt worden door
de gebruikers en toch nog geinstalleerd worden. (half /usr/bin en zo)

om terug te komen op het probleem.....
Wat je ook kan doen, is een kernel patch installeren: ik ken iemand die een bepaalde patch geinstalled heeft, en vervolgens was het voor gebruikers onmogelijk om te zien wie er ingelogd is/welke processen die niet van hem/haarzelf zijn draaien, etc.
Dit zou evt. handig kunnen zijn: het is dan moeilijker om uit te vinden welke mogelijk remote-exploit-dingen er zijn.
Tevens, een beetje goede firewall die als er op een verkeerder port verbonden word de route naar de host gewoon killed. (maw: access denied, bugger off)

[ecageman]

Op vrijdag 08 maart 2002 14:56 schreef decramy het volgende:

[..]

Ehh, mag ik dan ook ff vragen Hoe je dat doet??

Als er gebruik gemaakt wordt van PAM:

edit /etc/pam.d/su en voeg de volgende regel erbij:

auth required /lib/security/pam_wheel.so use_uid

Vervolgens zorg je dat alleen bepaalde users tot de groep wheel behoren. Bijv:

usermod -G10 admin

(groupid van de group wheel is 10)

Zodoende kan alleen de user admin su doen naar root.

[saryon2413]

Op vrijdag 08 maart 2002 15:14 schreef Creepy het volgende:
Lekkere systeembeheerder heb je dan.. een beetje systeembeheerder met wat verstand van linux kan echt een linux machine zo dichttimmeren dat scriptkiddies geen kans meer maken (perl scrippie downloaden en runnen.. das scriptkiddie ja).

Misschien moet die systeembeheerder toch maar eens gaan nadenken om e.e.a. bij te leren??

MC? daarin kan je toch ook shell commando's uitvoeren? Dus lijkt me dat je dat perl scrippie alsnog kan uitvoeren. EN alles wordt gelogd? Lekker boeiend als je het root passwd hebt. Logs cleanen en doorgaan..

mc-vraag: jah....bash <enter> zow....eigen shelletje

sysbeheer opmerking: klopt, maar de meeste doen dat niet, omdat ze niet weten HOE. dus zitten ze opgescheept met een brak geconfigd systeem die zo te hacken is. (redhat he?)

Trouwens: als je toevallig een paar linkjes weet waarmee je de server lekker kan dichttimmeren, graag posten (wil ik nl. zelf ook wel weten....meer planken en zo voor de gaten is altijd leuk;) )

[decramy]

Ik log in op m`n SSH accountje
ik krijg een mc venstertje
ik ga naar /bin
k druk met enter op bash
hij opent het met mcedit.

Hoe zouden jullie het dan doen?

[decramy]

Hoe kan ik eigenlijk (met een bash account (geen root)) kijken of ik alle updates heb??

[saryon2413]

Op vrijdag 08 maart 2002 15:21 schreef decramy het volgende:
Ik log in op m`n SSH accountje
ik krijg een mc venstertje
ik ga naar /bin
k druk met enter op bash
hij opent het met mcedit.

Hoe zouden jullie het dan doen?

mc was toch zo'n norton-commander clone?
nou....je hebt dan onderin zo'n leuk zwart regeltje....
daar tik je dan in "bash", en dan mep je op enter
of, als dat niet werkt, en /bin/bash bestaat wel, ff bash
kopieren naar je homedir, chmod 700 ~/bash, ~/bash <enter>
klaar....eigen shell...toch?

[ecageman]

Kijk eens naar: http://www.openna.com/products/books/securing-optimizing-linux/abstract.htm

Dit is versie 2.0 van het book wat niet gratis is, maar er is een link naar oudere versies en die kun je in pdf formaat gratis downloaden. (of je koopt de nieuwe versie). In dit document staan een hoop dingen volledig en goed uitgelegd.

[saryon2413]

Op vrijdag 08 maart 2002 15:24 schreef decramy het volgende:
Hoe kan ik eigenlijk (met een bash account (geen root)) kijken of ik alle updates heb??

dat kan je niet.
alleen # mag zo iets doen, dacht ik. (m'n dunk van rh zou nog harder crashen als gebruikertjes het WEL mochten)

je zal dus de beheerder lief aan moeten kijken, en als dat niet helpt ff mededelen dat als ie niet de zooi update, dat die kiddie binnenkort WEER # heeft, en er dus gewoon niets opgelost word.
want zolang de beheerder z'n systeem niet netjes dicht houdt, zal de hacker terug komen, en # worden, en de beheerder nog grotere problemen hebben met het hebben van een shell-account in plaats van een mc-account.....



edit: merceu ecageman....ff downloaden

[decramy]

HIER DE SYSTEEMSBEHEERDER:
ik heb alle users niet mc als shell gegeven, maar mcedit.
Dus, je kunt GEEN executable's uitvoeren!

[kenneth]

Op vrijdag 08 maart 2002 15:37 schreef decramy het volgende:
HIER DE SYSTEEMSBEHEERDER:
ik heb alle users niet mc als shell gegeven, maar mcedit.
Dus, je kunt GEEN executable's uitvoeren!

HIER EEN ANDERE SYSTEEMBEHEERDER:
Pak een boek over Linux, Security en System Administration en ga lezen.
Serieus.

[ecageman]

Op vrijdag 08 maart 2002 15:41 schreef mithalph het volgende:

[..]

HIER EEN ANDERE SYSTEEMBEHEERDER:
Pak een boek over Linux, Security en System Administration en ga lezen.
Serieus.

Mee eens. Zonder enige vorm van opleiding (dus ook zelfstudie) kun je dit soort taken niet uitvoeren.

[chem]

uhhh wat moet je met een shell waar je niks kan doen

dan kan je net zo goed alle toegang ontzeggen (shell = /dev/null)

[_cyclops_]

Op vrijdag 08 maart 2002 14:39 schreef wzzrd het volgende:

[..]

Sure, een apt-get zou ervoor zorgen dat je root password niet te hacken is Weer zo'n overmatige debian adept
Anyway, als het om een Perl scriptje ging, zou ik zoeken naar een manier om Perl af te schermen van de buitenwereld.
En shadowen natuurlijk.

'k zeg niet dat dat je beveiligt tegen brute force of tegen het beveiligen van je root password...

'k zeg dat het helpt dat je systeem niet gehacked wordt en het gemakkelijk up-to-date gehouden wordt....


Zoals 'k al heb gelezen wil de systeembeheerder niet over van rh7.2, dat is een stomme fout van hem. Dat is ongeveer 't zelfde als geen e-mail virussen meer willen maar toch outlook blijven draaien in mijn ogen...

[jep]

Als je machine al 2 keer door leerlingen is gehacked moet je:

- of eens een stukje gaan lezen
- toch maar bij NT servers blijven
- leerlingen laten helpen. die het wel weten.

Dergelijke rare shells lijken me geen echte oplossing

[deadinspace]

Op vrijdag 08 maart 2002 15:27 schreef saryon2413 het volgende:
dat kan je niet.
alleen # mag zo iets doen, dacht ik. (m'n dunk van rh zou nog harder crashen als gebruikertjes het WEL mochten)

uh?
Als gebruiker kun je toch zo kijken welke versie van een programma geinstalleerd is? En zo dus concluderen of het een up-to-date versie is?

Maar hoe is die cracker binnengekomen? Met een perl-scriptje zeg je? Wat voor perl-scriptje? Want dat hoort gewoon niet te kunnen.

[scorpie]

volgens mij is die admin van jullie er eentje die zegt van:

ah joh, doen we even

en dan komt ie er later achter dat het toch niet zo makkelijk is als wat hij had gedacht / gehoopt.
er zijn zat sites die je kunt bijhouden op securitygebied.
packetstorm
securityfocus
securitydatabase
dsinet
security.nl
hackers4hackers

[decramy]

Op vrijdag 08 maart 2002 15:59 schreef deadinspace het volgende:

[..]

Maar hoe is die cracker binnengekomen? Met een perl-scriptje zeg je? Wat voor perl-scriptje? Want dat hoort gewoon niet te kunnen.

Nee, hij is binnen gekomen door iemand die z`n gebruikersnaam en w8woord...
Toen heeft ie een perlscrippie gemaakt, en zo t rootpwd gekraakt.

En ja, dan gooi je SSH eruit, FTP vervagen, etc

PS: Perl kan er niet uit, omdat de hele webbased admin er op draait

[moto-moi]

Op vrijdag 08 maart 2002 16:09 schreef decramy het volgende:
Toen heeft ie een perlscrippie gemaakt, en zo t rootpwd gekraakt.

Waarschijnlijk zwakke wachtwoorden -> John de Ripper gebruiken dus..

[_cyclops_]

Over dat MC

je kan bij mc gewoon een command INTIKKEN...
dus je tikt als je je mc voor je hebt gewoon /bin/bash in en je hebt je shell weer...

hier iig

[moto-moi]

Op vrijdag 08 maart 2002 15:47 schreef ecageman het volgende:
Mee eens. Zonder enige vorm van opleiding (dus ook zelfstudie) kun je dit soort taken niet uitvoeren.

Da's een beetje kort door de bocht vind ik

Je kunt genoeg leren door het zelf te ontdekken.. Maar het moment waarop je genoeg weet, om een linux c.q. unix-bak scriptkiddie vrij te houden, duurt langer dan het opzetten van een Win NT bak. Ik gebruik nu al ruim 5 jaar Linux, en ik durf er wel een kratje bier op te zetten, dat ik die bak /wel/ script-kiddie-proof kan krijgen...

[saryon2413]

Op vrijdag 08 maart 2002 16:14 schreef _cyclops_ het volgende:
Over dat MC

je kan bij mc gewoon een command INTIKKEN...
dus je tikt als je je mc voor je hebt gewoon /bin/bash in en je hebt je shell weer...

hier iig

maar goed, dat is niet van toepassing, omdat ie mcedit gebruikt.....een of andere vage mc-component waar je alleen maar filetjes mee kan editten.......

[moto-moi]

Op vrijdag 08 maart 2002 16:14 schreef _cyclops_ het volgende:
je kan bij mc gewoon een command INTIKKEN...
dus je tikt als je je mc voor je hebt gewoon /bin/bash in en je hebt je shell weer...

Jups, klopt, de systeembeheerder heeft, zoals je hierboven ziet staan, mcedit als shell ingesteld.. Die server is dus een veredelde typemachine op dit moment

[decramy]

idd

er staat PHP MySQL en dat soort shit op, maar meer niet...

Maar als jij als shell '/usr/bin/mcedit' hebt, krijg je een mc venstertje

Er draai dan geen bash op de achtergrond, en als je /bin/bash intypt, ga je /bin/bash editen

[decramy]

Maar ok:

k moet dus alle updates downen
en die 'su' beveiligen...

dan heb ik dus een veilig systeem??

[moto-moi]

Op vrijdag 08 maart 2002 16:32 schreef decramy het volgende:
dan heb ik dus een veilig systeem??

Niet per se.. Dan heb je op dit moment een redelijk secure systeem, maar de hackers zitten niet stil, dus je zult dit vaak moeten doen, bijv. elke week, maar nog liever elke dag, en sites in de gaten houden waar dit soort dingen aangekondigd worden..

[decramy]

k zit bij RH op een mailing list...

Daar gooien ze iedere keer als er een update is, een mailtje naar me toe

[ecageman]

Op vrijdag 08 maart 2002 16:16 schreef moto-moi het volgende:

[..]

Da's een beetje kort door de bocht vind ik

Je kunt genoeg leren door het zelf te ontdekken.. Maar het moment waarop je genoeg weet, om een linux c.q. unix-bak scriptkiddie vrij te houden, duurt langer dan het opzetten van een Win NT bak. Ik gebruik nu al ruim 5 jaar Linux, en ik durf er wel een kratje bier op te zetten, dat ik die bak /wel/ script-kiddie-proof kan krijgen...

Ik schreef toch (ook zelfstudie). Oftewel de manier waarop jij allerlei dingen geleerd hebt, valt onder zelfstudie.

[moto-moi]

Op vrijdag 08 maart 2002 16:45 schreef ecageman het volgende:
Ik schreef toch (ook zelfstudie). Oftewel de manier waarop jij allerlei dingen geleerd hebt, valt onder zelfstudie.

Woeps.. my bad, ik las het op een iets andere manier , sorry .

[Verwijderd]

Op vrijdag 08 maart 2002 15:52 schreef jep het volgende:
Als je machine al 2 keer door leerlingen is gehacked moet je:

- of eens een stukje gaan lezen
- toch maar bij NT servers blijven
- leerlingen laten helpen. die het wel weten.

Dergelijke rare shells lijken me geen echte oplossing

I agree...

- Mensen die je niet vertrouwt sowieso geen shellaccess geven (of je moet de security fixes ECHT heel strak bijhouden en zelf het nodige tweaken als kernel patches als openwall en suid van een berg bestanden halen)
- Als er alleen maar files geup/download hoeven te worden volstaat chrooted ftp imho en heb je geen mcedit nodig...

[Verwijderd]

Een aardige optie om Redhat een beetje veiliger te maken is http://www.bastille-linux.org. Hier kun je een programma downloaden waarmee je zonder een linuxguru te zijn toch je systeem beter kan beveiligen dan het out of the box is.

[Kettrick]

Hoeveel users gaat het om ?

FreeBSD met jails is nl. de ultieme oplossing

[jep]

Op vrijdag 08 maart 2002 19:56 schreef RoeLz het volgende:
Hoeveel users gaat het om ?

FreeBSD met jails is nl. de ultieme oplossing

*Zucht*

Linux heeft ook jails

[Kettrick]

Op vrijdag 08 maart 2002 20:01 schreef jep het volgende:

[..]

*Zucht*

Linux heeft ook jails

*Zucht*

Zullen we die discussie maar niet in deze thread gaan voeren

Maar de jail/security features van *BSD zijn iig. strakker als die van Red-Hat

[Verwijderd]

Allereerst een link naar een site met daarop goede info over security en hoe je het zou kunnen aanpakken: Trinity OS
Je zult je bak eens kritisch moeten bekijken en rechten die gewone users niet nodig hebben weghalen. Dit kun je o.a. bereiken door world (het derde setje met rechten in rwxrwxrwx) geen of nauwelijks rechten te geven en users alleen die rechten op programma's die ze nodig hebben.

[odysseus]

Is de meest eenvoudige oplossing niet om alle gebruikers die inloggen (met uitzondering van root en dergelijke) te chroot'en naar een of andere subdir? Dan krijgen ze daar gewoon een binary voor mailen, je zet er ls, mv, cp en dergelijke neer en in 'hun' /etc/passwd staat gewoon alleen hun eigen wachtwoord...waarom zou dat niet kunnen?

[wzzrd]

Op vrijdag 08 maart 2002 21:31 schreef RoeLz het volgende:

[..]

*Zucht*

Zullen we die discussie maar niet in deze thread gaan voeren

Maar de jail/security features van *BSD zijn iig. strakker als die van Red-Hat

Een jail is een jail. Als het anders is doe je het fout. En als je de discussie niet wilt voeren, moet je er niet over beginnen.

[decramy]

Op vrijdag 08 maart 2002 15:17 schreef ecageman het volgende:

[..]

Als er gebruik gemaakt wordt van PAM:

[..]

Ehh PAM??
Kan iemand mij daar een linkje van geven (een RPM-pie voor RH7.1)
En een linkie naar een manual van PAM...

PS: volgens mij laat ik nu wel zien dat k een "newbie" ben

[kenneth]

Op dinsdag 12 maart 2002 15:02 schreef decramy het volgende:

[..]

Ehh PAM??
Kan iemand mij daar een linkje van geven (een RPM-pie voor RH7.1)
En een linkie naar een manual van PAM...

PS: volgens mij laat ik nu wel zien dat k een "newbie" ben

Of niet hebt gekeken op http://rpmfind.net en http://google.com/

google:

Op het web gezocht naar pam linux.
Resultaten 1 - 25 van circa 162,000. Zoekbewerking duurde 0.90 seconden

rpmfind:

RPM resource pam

Found 2 sites for pam

http://parc.power.net/morgan/Linux-PAM/index.html
http://www.us.kernel.org/pub/linux/libs/pam/index.html

Found 146 RPM for pam

[decramy]

OK, bedankt

[decramy]

Nog een klein vraagje

hoe zorg je ervoor dat ROOT niet kan inloggen via SSH.
Als je dan naar root toe wil, moet je su- doen...

[kenneth]

Uit dit topic:

Indien je het toch wil wijzig dan de file /etc/ssh/sshd.conf de regel "allow root access" of iets dergelijks, dat weet ik niet meer uit m''n hoofd, maar dat wijst zichzelf wel denk ik .

[Solarsparc]

Op dinsdag 12 maart 2002 15:15 schreef decramy het volgende:

Nog een klein vraagje

Hoe zorg je ervoor dat ROOT niet kan inloggen via SSH.

Als je dan naar root toe wil, moet je su- doen...

Zet

code:

PermitRootLogin no

in sshd_config

BTW: met su - schakel je een user terug vanuit root (of een andere user waarnaar je geswitcht bent), met su (zonder -) kun je root worden.

[Solarsparc]

#su offtopic
Opera is een kutbrowser, iedere keer als ik m'n post edit krijg ik een lege regel tussen al m'n zinnen
#su -

[odysseus]

Op dinsdag 12 maart 2002 15:25 schreef Solarsparc het volgende:
Zet

code:

PermitRootLogin no

in sshd_config
BTW: met su - schakel je een user terug vanuit root (of een andere user waarnaar je geswitcht bent), met su (zonder -) kun je root worden.

Ik word anders met 'su -' toch echt root hier...de optie '-' is equivalent met -l of --login en maakt van de door su gestarte shell een loginshell. En aangezien je geen username opgeeft valt hij terug op de default: root. 'su -' levert dus een loginshell voor root .

_{Niemand verplicht je om Opera te gebruiken, er zijn genoeg goede free-software browsers te vinden .}

[kenneth]

Op dinsdag 12 maart 2002 15:28 schreef Solarsparc het volgende:
#su offtopic
Opera is een kutbrowser, iedere keer als ik m'n post edit krijg ik een lege regel tussen al m'n zinnen
#su -

# su offtopic
Moet je ff upgraden naar 6.0 (of de TP voor Linux, ik weet niet welke je gebruikt, maar waarschijnlijk een 5.0 versie)
$ ^D

[Solarsparc]

Niemand verplicht je om Opera te gebruiken, er zijn genoeg goede free-software browsers te vinden

Ik vind Opera voor de rest de beste browser voor Linux, alleen is ie soms wat instabiel en heeft ie wat rare kuren. Ik zal eens upgraden naar 6.0. Mozilla en Konqueror zijn mij veels te instabiel en ook nog eens traag en geheugenvretend.

[active2]

Op dinsdag 12 maart 2002 16:07 schreef odysseus het volgende:

[..]

Ik word anders met 'su -' toch echt root hier...de optie '-' is equivalent met -l of --login en maakt van de door su gestarte shell een loginshell. En aangezien je geen username opgeeft valt hij terug op de default: root. 'su -' levert dus een loginshell voor root .

_{Niemand verplicht je om Opera te gebruiken, er zijn genoeg goede free-software browsers te vinden .}

Dat kan dus met pam!

In /etc/pam.d/su de volgende regel toevoegen:

auth required pam_wheel.so "group=<groepnaam van de users die mogen inloggen>"

Vervolgens in /etc/group
root:x:0:<groepnaam> --> groepnaam dus toevoegen!

Ik heb het vanmiddag en vanavond op mijn eige servers gedaan en het werkt perfect! Kunne me broertjes niet vervelend doen

[ecageman]

Op dinsdag 12 maart 2002 15:25 schreef Solarsparc het volgende:

BTW: met su - schakel je een user terug vanuit root (of een andere user waarnaar je geswitcht bent), met su (zonder -) kun je root worden.

Ehhh,

Niet helemaal waar. Met "su -" doe je een Set User naar Root (als je de user weg laat is de default root) waarbij je ook het profile laad van root. Als je alleen "su" doet, dan doe je setuser naar root zonder zijn profile te laden. De min is dus voor het wel of niet laden van het user profile.

<edit>
Heb niet goed alles gelezen. Dit werd al eerder gezegd.
</edit>

[odysseus]

Op dinsdag 12 maart 2002 23:36 schreef active2 het volgende:
Dat kan dus met pam!
[knip]

Ik zei toch ook niet dat dat niet kon? Ik reageerde alleen op de persoon die zei dat 'su -' was om naar een andere user terug te vallen .