[IMAPd] Remote inloggen als root

[Eelis]

.

[ Voor 100% gewijzigd door Eelis op 18-02-2015 20:05 ]

[_JGC_]

Nou, wat er tegen remote root login is:
- iemand kan heeeeel erg simpel je IMAP password sniffen omdat het plaintext is
- iemand pakt dit zelfde password om direct met root in te loggen op je SSH
- iemand hackt je bak en we hebben er weer een DDoS zombie bij

leuk, maar niet heus. Die maatregel is er niet voor nix, evenals PermitRootLogin No in sshd_config.

[Mark]

Eelis schreef op 18 november 2003 @ 22:36:
Iemand enig idee?

In je alias file:

root: usernaam

Vervang usernaam voor de juiste user.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:05 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:05 ]

[Seth4Chaos]

Mark schreef op 18 november 2003 @ 23:01:
[...]

In je alias file:

root: usernaam

Vervang usernaam voor de juiste user.

dit maakt niets uit, dit heeft alleen als gevolg dat de mail die naar de root gestuurd wordt niet meer wordt doorgestuurd naar "username", kortom volledig onafhankelijk van Imapd.

Ik weet niet hoe je als root remote kan inloggen op imapd alleen is het toch niet verstandig.
Op het moment dat jij dit toelaat, betekend dit dat er een proces draait dat van de root is (en dus alle rechten heeft). Als er een fout (bug) in dit programma zit (imapd dus) en deze kan gebruikt worden met een exploit dan krijgt deze 'hacker' toegang tot jouw systeem als de gebruiker die het process draaide en dat was de root dus kan deze gebruiker ALLES doen op jouw systeem.

kortom ik ga je niet vertellen hoe of wat je kan inloggen als root (zie streepje 3 van _JGC_) ik vertel je alleen maar dat het heel onverstandig is.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:05 ]

[pinball]

Buggy imap-client:
-normale user: sloop je mailmappen
-root: sloop je systeem

Zelfs als thunderbird al wel volwassen zou zijn lijkt me dat genoeg reden om niet als root in te willen loggen.

En verder sluit ik me lekker kuddedier bij de rest hierboven aan: als jij te lui bent om 2 passwords te onthouden ben ik te lui om uit te zoeken hoe het moet

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:05 ]

[wica]

Ik begrijp wel waarom je als root ingelogd wilt zijn. Lekker gemakkelijk ala windows.
Maar bekijk 't eens van de andere kant.
Je kan een normale user zoveel rechten geven als je wilt.
En er zijn zelfs programma's die weigeren om op te starten als je root bent. (zeer wijs)

Waarom denk je. Dat onder Linux zoweinig virussen enzo zijn?

[Erkens]

wica schreef op 18 november 2003 @ 23:45:
Ik begrijp wel waarom je als root ingelogd wilt zijn. Lekker gemakkelijk ala windows.

ook dan ben je niet goed wijs, althans mits je niet w9x of xp home hebt, want dan heb je geen echte keus.

Overigens kan je je account ook gewoon in de sudoers zetten, heb je zonder veel moeite of meerdere passwords onthouden direct root rechten

Waarom denk je. Dat onder Linux zoweinig virussen enzo zijn?

omdat dat maar een kleine doelgroep is

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:06 ]

[Erkens]

Eelis schreef op 18 november 2003 @ 23:54:
[...]

Waardoor het hacken van die account net zo schadelijk kan worden als het hacken van de root account..

maar je weet bijna altijd zeker dat er een root account bestaat, voor user accounts moet er wat meer moeite gedaan worden

[Eelis]

.

[ Voor 103% gewijzigd door Eelis op 18-02-2015 20:06 ]

[Erkens]

Eelis schreef op 19 november 2003 @ 00:00:
[...]

Naar mijn mening moeten het wachtwoord en de authenticatie-techniek genoeg veiligheid bieden, en moet het niet-weten-van-de-username geen rol spelen.

de authenticatie techniek is gebaseerd op zowel de username als het wachtwoord
dus je geeft al de helft prijs, daarnaast is het gewoon dom om remote (lees: onveilig netwerk) direct in te kunnen loggen met het account wat volledige rechten heeft...

[Gondor]

Ik ben met Erkens me eens.

Ik gebruik ssh om mijn server te benaderen. Ik heb een account aangemaakt om via ssh in te loggen en vervolgens gebruik ik 'su' indien nodig.

Als je root toe staat moeten ze
1- wachtwoord van root vinden en het is gedaan
Anders:
1- een bestaand account vinden
2- het wachtwoord daarvan vinden
3- het wachtwoord van root vinden
Dus dit is moeilijker.

En dat het via ssh of wat ever gebeurt, maakt niet uit.

[_JGC_]

Ik ken iemand die met ettercap bezig was geweest.

"ow, ik heb net ff 120 mailpasswords verzameld"
"das ook niet zo moeilijk met POP3 he?"
"ehm, tis IMAP/SSL hoor"

een goede sniffer zoals ettercap luistert de hele sessie inclusief key-exchange af en decrypt de gesniffte data gewoon. IMAP/SSL houdt dus alleen scriptkiddo's een beetje buiten de deur.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:06 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:08 ]

[Eelis]

.

[ Voor 103% gewijzigd door Eelis op 18-02-2015 20:06 ]

[Erkens]

Eelis schreef op 19 november 2003 @ 00:15:

Ruik ik hier een tekort aan zinnige argumenten?

ik weet niet wat jij ruikt en eerlijk gezegt wil ik het niet eens weten

wat ik wel weet is dat jij gewoon niet in ziet waarom je voorzichtig om moet gaan met het root account. Zeker als deze bak aan het internet hangt, hiermee kan je niet alleen jezelf duperen (zal me een rotzorg zijn) maar ook andere, als een kwaadwillend persoon zich root rechten verkrijgt is het een eitje om van alles met je internetverbinding te doen, van spammen tot DoSsen
En ja, ik vind het dom als iemand die een dergelijke machine aan internet hangt niet voorzichtig is.

offtopic:
overigens zou je ook de edit knop kunnen gerbuiken, heb je geen eens admin rechten voor nodig

[ Voor 8% gewijzigd door Erkens op 19-11-2003 00:24 ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 00:15:
Ruik ik hier een tekort aan zinnige argumenten?

Nee, dat heb je verkeerd.

Jij zet een pc open voor buitenwereld.
Waar het ook nog eens relatief gezien erg eenvoudig van is, om op die pc volledige rechten te verkrijgen.
Komt dus op neer dat jouw pc overal voor gebruikt kan worden, waar jij voor verantwoordelijk word gehouden.

Nou is het natuurlijk niet onmogelijk om een beveiliging te breken, maar wat je op zijn minst kan doen is het zo moeilijk mogelijk maken om root access te krijgen.
Hoord bij de verantwoordelijkheid die je hebt als je een server neerzet met internetaccess.

[offtopic]
Zou je btw de editknop willen gebruiken?
Staat wat netter dan 3 posts van je onder elkaar.

[Eelis]

.

[ Voor 133% gewijzigd door Eelis op 18-02-2015 20:06 ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 00:27:
Sinds wanneer is het 'relatief gezien erg eenvoudig' om zomaar een linux pc te hacken?

Je leest het niet goed.
Met relatief vergelijk ik deze 2 mogelijkheden.
Iemand hackt jou (jij gebruikt root), en heeft meteen root acces.
Iemand hackt mij (ik gebruik een user), en moet daarna eerst nog root password achterhalen om wat te kunnen op mijn pc.

Nou bij wie heb je dus relatief eenvoudig root acces? Bij jou.
Jij weet zelf wel wat je allemaal als root kan.

Mijn stelling is dus dat 1 wachtwoord (ongeacht of de username bekend is) genoeg moet zijn en ook is.

Met een goeie wachtwoord maak je het idd wat moeilijker, maar zeker niet onmogelijk.
Het zijn juist combinaties dat veiligheid vergroot, goed password op een "veilige" verbinding. En dat samen met een useraccount waar zorgvuldig mee omgegaan word.
Dat houd in: niet een account die onnodige risico oplevert als die gehackt word.

Over vetgedrukte 'ook is':
Als jij al je security op 1 paswoordje wil funderen, kun je er zeker van zijn dat je jezelf nog wel tegenkomt.
Dat is namelijk gewoon blind zijn voor de gevolgen en de consequenties van je doen en laten.

Denk hier maar eens over na: (een vervolg van je stelling)
Waarom zou er zoveel geld omgaan in security van bedrijfsgegevens?
Omdat directeur geen goed password kan verzinnen?

offtopic:
Als je een stelling neerzet moet je geen meningen als feiten neerzetten.
Haalt doel van stelling nogal onderuit. Of je moet met overtuigende bewijzen komen.

[Eelis]

.

[ Voor 132% gewijzigd door Eelis op 18-02-2015 20:07 . Reden: Reply op Gondor toegevoegd ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 01:20:
Ik heb het hier niet over directeuren, maar over een enkele account die alleen ik gebruik en waarvan ik het wachtwoord kies. De vraag is dan: is het reëel om een goed gekozen wachtwoord (brute-force of anderszins) te kraken (als je de username kent).

Wat jij nu vergeet is dat het ook over een pc gaat die aangesloten is op internet.
En dat jij daar de verantwoordelijkheid over draagt. En van je verwacht word dat je er verstandig mee omgaat.
Meerdere malen is in dit topic al vermeld dat jouw idee over root niet zo verstandig is in dit geval. Ook met meerdere uitleg erbij.
Waaronder (niet onbelangrijk) brakke clients! Lees nog even terug zou ik zeggen.

Ik heb geen concrete bewijzen die aantonen dat dat niet het geval is, maar ik kan me niet voorstellen dat het zo is (aangezien het toch wel een vrij veel gebruikt authenticatie-systeem is).

Met de vergelijking met directeur erin, wil ik duidelijk maken dat je je security niet alleen op een password moet baseren.
Het is idd een veelgebruikte auth. systeem, maar geen enkele auth systeem is 100% veilig.

Het begint er een beetje op te lijken dat je je zinnen gezet hebt op het root gebeuren.
En daarbij totaal alle waarschuwingen/tips ed. negeert.
Streep de dagen maar af totdat je gehackt word.

offtopic:
Mits je dus met bewijzen aankomt.

[Eelis]

.

[ Voor 105% gewijzigd door Eelis op 18-02-2015 20:07 . Reden: zin over verantwoordelijkheid toegevoegd ]

[Vae Victis]

Heb het net nog express in bold gezet, maar je hebt er dus toch nog overheengelezen.
Bak op internet + root gehacked = leuk voor
-spammen
-dossen
-ftp-warez
-etc...

Je moet eens verder denken dan alleen jouw mail en files.

[Eelis]

.

[ Voor 98% gewijzigd door Eelis op 18-02-2015 20:07 ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 02:09:
Voor die activiteiten heb je geen root nodig.

User kan idd ook een aantal dingen, maar je vergeet dat als iemand anders root access heeft je je systeem kwijt bent.
Alleen een herinstall helpt daarbij.
Bij een user hoef je alleen een kleine schoonmaak beurt te houden.

Waar bij een user sneller opvalt als er processen draaien die je als die user niet zou draaien.

[Eelis]

.

[ Voor 115% gewijzigd door Eelis op 18-02-2015 20:07 ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 02:33:
'T systeem (de installatie) vind ik niet zo'n probleem; een paar uurtjes installen & configgen en het draait weer. Veel erger vind ik het wanneer hackers toegang verkrijgen tot mijn data, en dat zouden ze met een user account ook kunnen.

Tja, als je graag blijft herinstalleren ..

Anyway, je verantwoordelijkheid-voor-een-pc-aan-internet-argument lijkt weerlegd te zijn (aangezien het in een non-root-user setup net zo'n probleem is), dus ik wacht met smart op nieuwe argumenten.

Sorry maar daar weerleg je het echt niet mee.
De problemen zijn nl niet hetzelfde. Ga trouwens eens een paar topics lezen over linux bakken die gehackt zijn.
Weet je wat je tegen zult komen.

Ik zit zowieso niet voortdurend te monitoren welke processen er allemaal draaien. Noem me onverantwoordelijk, maar dat is me echt teveel gedoe. Misschien dat ik daar eens een intrusion detection system voor moet gaan gebruiken oid.

Je checkt niet wat er allemaal draait op je pc, wat aan internet aangesloten is?
Zelfs niet in een bepaalde regelmaat?

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:07 ]

[Erkens]

Eelis schreef op 19 november 2003 @ 02:33:
[...]

'T systeem (de installatie) vind ik niet zo'n probleem; een paar uurtjes installen & configgen en het draait weer. Veel erger vind ik het wanneer hackers toegang verkrijgen tot mijn data, en dat zouden ze met een user account ook kunnen.

Anyway, je verantwoordelijkheid-voor-een-pc-aan-internet-argument lijkt weerlegd te zijn (aangezien het in een non-root-user setup net zo'n probleem is), dus ik wacht met smart op nieuwe argumenten.

enig verschil met een root account en een normaal user account is dat een root logfiles kan editen, nieuwe user maken om later er weer in te kunnen (of een bestaande user editen die je niet gebruikt zoals bijvoorbeeld de user 'mysql' ofzo) en deze extra rechten geven.
Backdoors installeren en dat zo dat je er niet snel achter komt, nee prima zo'n root account

[_JGC_]

Back ontopic:
dat je via IMAP je mail niet kunt lezen als root heeft en reden, en die reden proberen wij dus uit te leggen.
Blijkbaar gebruik je ook geen veilige MTA, want een veilige MTA zoals qmail weigert zelfs mail af te leveren voor root. Reden hierachter: om qmail in de maildir van een user te laten schrijven, moet ie setuid naar die user doen, en als die user toevallig root is, wil qmail daar niet aan beginnen. It's by design, en als je zoiets wilt aanpassen, moet je de auteur van het stukje software vragen of ie je niet zal vermoorden als jij stiekum een versie van zijn pakket op het internet zet wat niet die check heeft.

[active2]

Secure IMAP -> whehehe

Kijk eens naar het tooltje ettercap

Jij wil als root inloggen ? Kun je dan niet beter meteen je password weggeven ?

Ik kan je een ding vertellen als je ook maar iets aan security doet dan is dit het eerste wat je uit zet:
- Remote root logins voor ssh
- Imap als speciale user
- Sendmail vervangen door wat anders (liefst Postfix of Qmail)
- Firewall voor het nodige verkeer.

En wat mij betreft mag je zo koppig zijn als wat maar geef mij je ip maar is dan wil ik jou bak wel is screenen. Als jou email server in de blacklists van internet komen te staan dan kun je geen e-mail meer ontvangen van Qmail/Postfix/Sendmail deze gebruiken allemaal een blacklist. Wat gebeurt er bijvoorbeeld als er bij jou ingebroken wordt ? Precies dan word je bak als zombie gebruikt voor een DDoS (Dedicated Denial of Service) wat betekend dat ? Dat betekend dat je aangepakt kan worden door de overheid voor het niet beveiligen van je server.

* active2 denkt dat jij nog een heleboel moet leren

En zeker op het gebied van beveiliging.

Jij vindt de mail user en de www-data user erg belangrijk...
Een user account die niet mail of www-data heet (mail en www-data zijn trouwens disabled logins (normaal)) dan kan die user ook niks deleten wat van mail of van www-data is zolang deze niet 777 gemaakt zijn.

Maar goed als jij als root wil inloggen mag dat van mij hoor. Maar denk ook even aan de andere mensen die je lastig valt op internet zodra je bak gehacked wordt.

Ik hoop eerlijk gezegd dat die binnenkort gehacked wordt alleen maar om jou met je neus op de feiten te drukken. En zoals al gezegd tel de dagen maar af.

[ Voor 22% gewijzigd door active2 op 19-11-2003 08:57 . Reden: Even de complete thread doorgelezen. ]

[Wilke]

Eelis schreef op 18 november 2003 @ 22:36:
(ik heb namelijk nog geen voor mij overtuigend argument tegen remote root logins gehoord, en gebruik daarom al jaren enkel en alleen de root user).

Altijd als root inloggen is zo volmaakt onnodig en dom, dat ik niet eens de tijd er aan ga verspillen om nogmaals uit te leggen waarom. Er zijn wel eerder topics over geweest, maar ik kan de laatste helaas niet zo snel terugvinden

Maar als je het toch per se wilt, dan moet je dat natuurlijk zelf weten

Alleen hoef je daarbij van mij geen hulp te verwachten; als iemand van een flat wil springen ga ik hem daar tenslotte ook niet bij helpen. Zoals je zelf al zegt: het is niet voor de grap dat dit 'by default' expliciet uitgeschakeld is!

active2: nu is overdrijven ook een vak, maar inderdaad, wat jij en JGC en nog anderen al zeggen, daar komt het wel op neer ja.

[ Voor 8% gewijzigd door Wilke op 19-11-2003 09:23 ]

[active2]

Inderdaad is overdrijven een vak

Ik heb het vak alleen niet gevolgd

Als je het zo stelt komt het misschien een keer over waarom het secure by default is.

[igmar]

Eelis schreef op 19 november 2003 @ 01:20:
Hoeft niet. Noem de lengte van jouw gekozen username x, noem de lengte van het wachtwoord daarvan y, en noem de lengte van het root wachtwoord z. Qua aantal te brute-forcen permutaties is dat niet veiliger dan wanneer ik geen user gebruik maar een root wachtwoord kies van lengte max(x+y,z)+1.

su rechten heb je hier alleen als je in de wheel groep zit, en we gebruiken (lees : forceren) hier password-strengt checking, en een password history. In dit geval moet je

1) een user zien te vinden die in de juiste groep zit
2) het wachtwoord zien te vinden
3) het root wachtwoord zien te vinden.

Met imapd kun je onbeperkt wachtwoorden gokken, en mijn ervaring leert dat je met een dictionary attack vaak al een aardig eind komt. En bijkomend voordeel is dat scriptkiddies het leven wat moeilijker wordt gemaakt, aangezien je met een root account niet kan inloggen, en inkomende connecties hier door de firewall worden afgevangen.

Op een afgesloten systeem zonder directe internet link zal het wat minder spelen, maar op systemen die rechtstreeks aan inet hangen vind ik rechtstreekse root-logins wat minder verstandig. Wil je dat wel zul je met keys moeten gaan werken, of met strong authentication (en dat zijn per definitie geen wachtwoorden).

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:09 ]

[Gondor]

Eelis schreef op 19 november 2003 @ 01:20:
Hoeft niet. Noem de lengte van jouw gekozen username x, noem de lengte van het wachtwoord daarvan y, en noem de lengte van het root wachtwoord z. Qua aantal te brute-forcen permutaties is dat niet veiliger dan wanneer ik geen user gebruik maar een root wachtwoord kies van lengte max(x+y,z)+1.

Gondor denkt: Heey das een goed idee.

Hoeft niet. Qua aantal te brute-forcen permutaties is dat niet veiliger dan wanneer ik geen wachtwoord gebruik maar een loginnaam kies van lengte max(x+y,z)+1+nogiets. En als deze loginnaam met een wachtwoord wordt gebruikt is het ongeldig. Ziezo, zie je wel dit is veiliger.

Wat ik probeer te zeggen is het volgende:
Je zegt dat je argumenten wilt horen. Maar dan moet je ook met tegen argumenten komen en niet van dit soort dialogen:

Persoon A zegt: Standaard stokbrood is langer dan en standaard pen.
Persoon B zegt: Als ik [lengte stokbrood]/[lengte pen]+1 aantal pennen aan elkaar plak is die pen langer. Dus volgende argument aub.

Sorry maar zo zie ik het.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:07 ]

[pinball]

sjeez.. is deze nou nog steeds open

Eelis schreef op 18 november 2003 @ 23:38:
Jij noemt het 'lui', ik noem het de conclusie van een verantwoorde rationele kosten-baten analyse .

Ik noem het het resultaat van een erg beroerde kosten-baten analyse

Kosten:
-extra ww onthouden
-af en toe su/sudo

Baten:
-lagere impact bij exploit in userland
-bescherming tegen typefouten (rm, chmod et al)
-bescherming tegen buggy software
-veiliger en betrouwbaarder systeem systeem

Eelis schreef op 19 november 2003 @ 00:27:
<..>Ik heb op alle in deze thread genoemde argumenten inhoudelijk gereageerd<..>

Kom maar dan

Ik snap jou argument dat je userdata het belangrijkste is van je systeem wel, maar met een beetje moeite kun je de rest van je computer een stuk veiliger en stabieler maken waardoor juist je userdata nog beter beschermd is.

[Eelis]

.

[ Voor 104% gewijzigd door Eelis op 18-02-2015 20:07 ]

[_JGC_]

Dan maar op de botte manier:

dd if=/dev/zero of=/dev/hda

doe dat eens als user, en daarna als root. Bij de eerste is je data nog heel, bij de tweede ben je alles kwijt.

Er zijn 100-en-1 manieren om je data omzeep te helpen behalve gewoon verwijderen of wijzigen, en toevallig kan root deze acties altijd uithalen. Maar ja, jij bent koppig, ik hoop dat ze je bak binnenkort eens rooten, en dan kom je er niet eens achter ook.

[Vae Victis]

Eelis schreef op 19 november 2003 @ 16:24:
Het verschil tussen een root exploit en een user exploit waarbij de user toegang heeft tot mn mail en www is voor mij verwaarloosbaar.
[...]
Het verschil tussen als root het hele systeem per ongeluk opblazen met een misplaatste rm/chmod/etc, en als user mn mail en www per ongeluk opblazen met een mistplaatste rm/chmod/etc is voor mij verwaarloosbaar.

En weer denk je alleen aan je eigen zaak, ipv van ook te denken aan wat anderen aan last kunnen ondervinden als jouw bak gehackt is.
Ik moet zeggen erg sociaal!

Hmm, dit is het eerste argument waarvan ik oprecht zeg: daar zit wat in. Een buggy programma zou bijvoorbeeld per ongeluk kunnen proberen het systeem op te blazen. Als ik dat programma als user draai is er niks aan de hand, terwijl als ik dat programma als root zou draaien het systeem (inclusief mn mail en www) weg is. Het essentiële verschil tussen een buggy programma en een hacker is uiteraard dat een buggy programma niet doelbewust gaat klooien met m'n mail/www, terwijl een hacker dat wel zou doen.

Pardon? Eerste argument?
Lees je wel alle reply's? Lijkt er niet op namelijk.
Lees deze nog eens: [rml]Seth4Chaos in "[ IMAPd] Remote inloggen als root"[/rml]
Maar zo zijn er meer argumenten die gegeven zijn, waar je je niets van aantrekt.

Bedankt, je hebt me overtuigd, ik maak direkt een user aan . De thread kan wat mij betreft dicht, aangezien het originele probleem dus geen probleem meer is.

Toch mooi dat je eindelijk een verstandige keuze kunt maken.

[Mark]

Seth4Chaos schreef op 18 november 2003 @ 23:07:
[...]
dit maakt niets uit, dit heeft alleen als gevolg dat de mail die naar de root gestuurd wordt niet meer wordt doorgestuurd naar "username", kortom volledig onafhankelijk van Imapd.

Nee, dat heeft als gevolg dat mail voor de user root naar een user word doorgestuurd. Schijnbaar wil de TS de mailbox raadplegen van de user root (waarom wil hij anders imappen als root), op deze manier kan hij dus gewoon een usermailbox openen om de mail voor root te kunnen lezen.

Op het moment dat jij dit toelaat, betekend dit dat er een proces draait dat van de root is (en dus alle rechten heeft). Als er een fout (bug) in dit programma zit (imapd dus) en deze kan gebruikt worden met een exploit dan krijgt deze 'hacker' toegang tot jouw systeem als de gebruiker die het process draaide en dat was de root dus kan deze gebruiker ALLES doen op jouw systeem.

Bij elke gemiddelde brakke imap server zal het imapd process als root draaien (poort < 1024). Staat dus geheel los van de later in te loggen user. Mocht de TS een echte IMAP server gebruiken dan zou het zo kunnen zijn dat eventuele child processen onder een andere user draait, dit hoeft echter niet gelijk te zijn aan de user welke inlogd (zou een beetje lastig zijn met SQL en LDAP lookups).

Grootste probleem met wat de TS inderdaad wil is dat het password plaintext over het boze internet gaat. Dit zou hij eventueel kunnen beveiligen middels SSL, maar hier zijn ook al methodes voor om passwords te rippen. Verder is er inderdaad het probleem dat imapd geen lockout kent, mensen kunnen dus, zoals igmar al zegt, met een dictionary attack al de nodige passwords achterhalen.

Wellicht is het zo dat deze user alleen de server in zijn eigen lokaal netwerk heeft staan, dan mag hij van mij ermee doen wat hij wil. Als dat het geval is, ga dan maar eens op zoek naar een oude uw-imap versie, deze zijn zo brak en lek dat je vast met root in kunt loggen (of je kunt vrij makkelijk de src aanpassen hiervoor). Mocht je deze machine via internet benaderen moet je dit dus niet doen.

[pinball]

Pfew :-)

Voor de volledigheid moet ik toch nog even wat rechtzetten Jij zegt

Het verschil tussen een root exploit en een user exploit waarbij de user toegang heeft tot mn mail en www is voor mij verwaarloosbaar.

Zit wat in, als exploits gericht zouden zijn op users. In mijn ervaring zijn ze dat niet. Iemand met kwade bedoelingen gaat niet voor de 'rm -R /home' maar zal proberen om vaste voet aan de grond te krijgen. Met normale userrechten lukt dat niet, met root rechten wel.

Wat betreft de tiepfouten, voor jou is dat verschil misschien verwaarloosbaar, voor mij niet.
Als ik m'n homedir weggooi blijft m'n webserver gewoon draaien, komt mail gewoon aan. Als ik zin en tijd heb restore ik m'n homedir en ik ben klaar.
Als ik als root per ongeluk /var weggooi heb ik geen werkend systeem meer. Mail komt niet aan, webserver dood. Ik moet meteen m'n systeem restoren om weer up&running te zijn.

En omdat dit topic toch al lang niet meer over imap gaat ga ik nog ff volledig offtopic door:

-niemand zegt dat je root ww 100% verschillend moet zijn van je eigen ww. De scheiding zit hem imo (zoals jij hierboven al een paar keer terecht opmerkte) niet zozeer in de moeilijkheid van een 2de wachtwoord, maar in de veel lagere startpermissies van een user.
-mail/www belangrijk? Dagelijks door root laten backuppen naar een partitie die alleen root mag mounten. Zo bescherm je jezelf tegen je eigen typefouten. (dit los van je normale backupprocedure natuurlijk).
-alleen een ssh connectie en problemen met su ? Gebruik screen, heb je met crtl-a " altijd een rootconsole binnen handbereik

[/rant]

@ iedereen die nog ff door wil gaan over al dan niet 'sociaal' gedrag van/door een gehackte machine: niet overdrijven. Met een useraccount kan je prima vooruit als je wil spammen en/of ddossen, heb je echt geen root voor nodig. Bovendien geeft ie al een paar keer aan dat veiligheid hem echt wel interesseerd, maar dat zijn prioriteiten gewoon anders liggen. Dat mag je best respecteren, het is niet zo dat ie een ongepatchte IIS aan inet hangt, hij wil gewoon makkelijk werken.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:08 ]

[Vae Victis]

Eelis schreef op 19 november 2003 @ 17:19:
In die post heeft Seth het over een exploitable bug die hackers kunnen gebruiken om zich toegang tot het systeem te verschaffen, dat is iets totaal anders als wanneer ik zelf een programma draai dat een bug bevat waarbij de bug zelf direkt de schade veroorzaakt.

Heb idd verkeerde link gepost.
Het was deze: [rml]Pinball in "[ IMAPd] Remote inloggen als root"[/rml]
2 reacties eronder.

Pinball
@ iedereen die nog ff door wil gaan over al dan niet 'sociaal' gedrag van/door een gehackte machine: niet overdrijven. Met een useraccount kan je prima vooruit als je wil spammen en/of ddossen, heb je echt geen root voor nodig. Bovendien geeft ie al een paar keer aan dat veiligheid hem echt wel interesseerd, maar dat zijn prioriteiten gewoon anders liggen. Dat mag je best respecteren, het is niet zo dat ie een ongepatchte IIS aan inet hangt, hij wil gewoon makkelijk werken.

Je kunt idd met useraccount je prima redden.
Maar een proces gestart door 1 bep. user is sneller te achterhalen (verdacht) dan 1 gestart door root. Welk de proces ook als elk ander user kan starten.
En zoals je zelf al enigszins aangeeft, het is zoveel eenvoudiger een gehackte user te recoveren dan wanneer je root er aan heeft moeten geloven.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:08 ]