[FreeBSD] Remote root écht niet mogelijk?

[bvk]

Ik zit even met het volgende en ik hoop dat er nog een tweaker misschien een "trucje" weet.

Sinds bijna 2 jaar draait er in een acheraf hoekje van mijn huis een FTP server, draaiende onder FreeBSD 6.1. Gaat helemaal perfect, oudere Dell Optiplex in goede staat, netjes geconfigureerd. Het OS is vanaf de basis cd geinstalleerd waarbij dus alleen maar van FreeBSD.org is gedownloaded wat nodig was voor het opzetten van het basis OS en een FTP server.

Omdat ie zo prima werkte ging al snel monitor en toetsenbord eraf om ruimte te besparen, beide heb ik ook niet meer.
Jammer, want nu na al die tijd wordt het toch eens hoog tijd voor wat beheer werkzaamheden op de machine waar je expliciet root voor moet zijn.
En dat gaat dus niet remote, ook niet via SSH etc. Je krijgt een vriendelijk, maar onverbiddelijk "sorry..." terug als je pogingen doet om van afstand root te worden...

Voor wat ik begrepen heb uit de documentatie en internet is dit een hopeloze zaak en zal ik persé een monitor en tobo moeten aankoppelen om beheer te verkrijgen.
Ik heb ook begrepen dat ik dan in ieder geval wél remote acces kan aanzetten zodat het probleem verder verholpen is voor een volgende keer, maar dan moet ik dus eerst weer die hardware gaan regelen voor één keer en dat was ik nu net niet van plan...

Weet er iemand toch misschien nog een manier, of komt dit neer op hacken? (op zich wel interessant, maar verboden op GoT )

[Nvidiot]

Zit geen van de gebruikers waar je mee kunt inloggen in de 'wheel' groep? Als dat wel het geval is, met die gebruiker via ssh inloggen, dan 'su' naar root en gaan

[bvk]

Nee, dat is dus het probleem. Machine was dacht ik netjes geconfigureerd toen ik de hardware afkoppelde, behalve dat ik vergeten was mezelf de juiste rechten toe te kennen...
Ben net zo'n gewone gebruiker als de rest, dus behalve root zit er niemand in de wheel groep.

[SA007]

Dat lijkt me typisch zo'n geval geen keus buiten fysiek naar het ding toe.

Als het makkelijker is kan je evt de schijf eruit gooien en via een andere pc /etc/group aanpassen.

Heb zelf 's wat vergelijkbaars gehad, alleen was toen sudo kapot door een foute chmod en stond de pc een goede 150km verderop...

[Verwijderd]

Ik zou seriele kabel eens proberen, kan wonderen doen. Maar goed, zo is het systeem niet geconfigureerd waarschijnlijk, dus kansloos. Enige manier word dan fysiek. Helaas pindakaas.

Maar een keyboard heb je toch wel? Gewoon aansluiten, laten opstarten, en blind gaan toevoegen, heb ik ooit wel eens gedaan, en was ook gelukt .

[ Voor 29% gewijzigd door Verwijderd op 12-11-2007 16:06 ]

[Petuhr]

Tsja.. je moet er wel root voor zijn, maar je sshd_config in /etc/ssh editen :

PermitRootLogin yes

Dan kan je wel remote root ssh doen.

[Aike]

Verwijderd schreef op maandag 12 november 2007 @ 16:05:
Maar een keyboard heb je toch wel? Gewoon aansluiten, laten opstarten, en blind gaan toevoegen, heb ik ooit wel eens gedaan, en was ook gelukt .

Je zou zelfs een scriptje kunnen maken dat even replace doet op de sshd config, dat uploaden met ftp en dan blind ./scriptje kunnen draaien zodra je root bent.

[bvk]

Petuhr schreef op maandag 12 november 2007 @ 16:12:
Tsja.. je moet er wel root voor zijn, maar je sshd_config in /etc/ssh editen :

PermitRootLogin yes

Dan kan je wel remote root ssh doen.

Bovenstaande had ik zelf ook al gevonden, maar dan moet ik eerst in kunnen loggen. Maar dit ga ik alleen doen als je het zo kunt instellen dat remote access alleen lokaal wordt toegestaan...
Aan de andere kant: als ik er gewoon een heel sterk wachtwoord op zet is het een knappe jongen die er door komt toch?

Bedankt voor de verdere tips, maar ik ga wel een monitor regelen, er zit niets anders op. Want in blind typen of scriptjes draaien ben ik niet zo'n ster

[Rainmaker]

Wachtwoorden kraken is volgens mij allang niet meer the way van hackers.

Niet dat ik er zo in thuis ben, maar volgens mij zou je ervoor moeten zorgen dat alle andere vormen van authenticatie uitstaan. Bijvoorbeeld public / private keys e.d. Ook altijd de laatste versie tegen evt beveiligingslekken e.d.

Volgens mij zijn er nog maar weinig "hackers" die binnenkomen door 50000 verschillende wachtwoorden te proberen. Zeker als je password retry timeout op 10 seconden staat

[SA007]

erm, public/private keypair is veiliger dan direct inloggen hoor?

Wordt eerder aangeraden normaal in te loggen uit te zetten en alles public/private keypairs te gebruiken.

Remote bruteforcen is nooit echt populair geweest, zeker niet nu opties als 10x fout -> halfuur ban en dergelijke redelijk standaard worden.

[bvk]

Ik ben me toevallig net voor mijn werk in PKI en PKCS# aan het verdiepen, als ik meer geleerd heb kan ik het mooi op mijn server toepassen en uittesten

Gewoon om het te leren en te kunnen, want ik denk bij nader inzien dat een sterk wachtwoord al meer dan voldoende is. Want welke gek gaat er nou uren besteden om op een kleine particuliere Unix machine in te breken met een zeer minieme kans op succes?

Onbeveiligde Windows machines zat op internet...

[deadinspace]

bvk schreef op maandag 12 november 2007 @ 17:44:
Bovenstaande had ik zelf ook al gevonden, maar dan moet ik eerst in kunnen loggen. Maar dit ga ik alleen doen als je het zo kunt instellen dat remote access alleen lokaal wordt toegestaan...

Hoe bedoel je, "remote access alleen lokaal toestaan"?

Ik zou gewoon PermitRootLogin uit laten staan en je user toevoegen aan wheel. Op die manier moeten ze bij bruteforcen ook je username en diens wachtwoord nog raden. Als ik in mijn logs kijk, dan is root verreweg de meest geprobeerde username, dus als PermitRootLogin aan staat hoeven ze maar één keer mazzel te hebben met het wachtwoord

Om root te krijgen op je huidige bak kun je zoeken naar local root exploits voor de FreeBSD versie die je draait. Als je die niet vindt, of die werken niet, dan heb je pech en mag je idd met een toetsenbord gaan slepen

[bvk]

deadinspace schreef op maandag 12 november 2007 @ 18:55:
[...]

Hoe bedoel je, "remote access alleen lokaal toestaan"?

Ik zou gewoon PermitRootLogin uit laten staan en je user toevoegen aan wheel. Op die manier moeten ze bij bruteforcen ook je username en diens wachtwoord nog raden. Als ik in mijn logs kijk, dan is root verreweg de meest geprobeerde username, dus als PermitRootLogin aan staat hoeven ze maar één keer mazzel te hebben met het wachtwoord

Om root te krijgen op je huidige bak kun je zoeken naar local root exploits voor de FreeBSD versie die je draait. Als je die niet vindt, of die werken niet, dan heb je pech en mag je idd met een toetsenbord gaan slepen

Dat de permit alleen voor lokale IP adressen geldig is natuurlijk

Ik ga inderdaad als ik er weer op kan mezelf gewoon meer rechten geven, eerst eens uitvogelen hoe dat met die certificaten werkt.

Exploits? Ik verwacht eigenlijk dat een OS met zo'n lange historie op dat gebied spijkerhard dicht zit!

Maar wie weet..

[robbert]

bvk schreef op maandag 12 november 2007 @ 19:03:
Exploits? Ik verwacht eigenlijk dat een OS met zo'n lange historie op dat gebied spijkerhard dicht zit!

Ik ken de geschiedenis van FreeBSD qua veiligheid niet precies, maar als je dat ding al 2 jaar niet hebt geupdated is de kans er in die tijd een exploit voor FreeBSD (of een van jouw andere als root draaiende applicaties) gevonden is wel aanwezig.

[ Voor 10% gewijzigd door robbert op 12-11-2007 19:11 ]

[bvk]

Valt er iets te updaten aan een FreeBSD kernel buiten de upgrade naar een nieuwe release dan? Eventueel modules en natuurlijk de losse programma's. Maar de laatste kernel exploit stamt uit 2002 ofzo als ik goed gelezen heb.

En ik gebruik helemaal geen andere programma's, het is de basis kernel installatie met de standaard FTP deamon.
De machine vertoond verder geen enkele foutmelding en dat is ook wel tof na 2 jaar zonder onderhoud

Maar goed, voor dat laatste gaat er een monitor en toetsenbord aan, klaar.

Verder is het wel een leuke discussie natuurlijk, hoe beveilig ik een *nix systeem

[Boudewijn]

En ik gebruik helemaal geen andere programma's, het is de basis kernel installatie met de standaard FTP deamon.

Voila, al meer dan een kernel.
en hoe goed zit die FTP daemon dicht?
en je SSH?

[deadinspace]

bvk schreef op maandag 12 november 2007 @ 19:03:
Exploits? Ik verwacht eigenlijk dat een OS met zo'n lange historie op dat gebied spijkerhard dicht zit!

Mja, dat is een tikkeltje naief

Alle OSsen zijn complexe systemen waar fouten in zitten, en sommige van die fouten vormen een veiligheidsrisico.

Elk fatsoenlijk OS heeft dan ook een security advisory / correction afdeling. Voor FreeBSD is het een en ander te vinden op http://www.freebsd.org/security/ .

bvk schreef op maandag 12 november 2007 @ 20:26:
Valt er iets te updaten aan een FreeBSD kernel buiten de upgrade naar een nieuwe release dan? Eventueel modules en natuurlijk de losse programma's. Maar de laatste kernel exploit stamt uit 2002 ofzo als ik goed gelezen heb.

FreeBSD is een stuk meer dan alleen de kernel; de meeste security problemen treden typisch op in userspace code.

Van de 20 security advisories sinds 6.1 tel ik er 4 voor de kernel, en 16 voor userspace. En dat is nog zonder de ports collection (de veiligheidsproblemen daarvan worden in een ander document bijgehouden), wat allemaal userspace is.

Ik heb even vlug door de lijst gekeken, maar volgensmij zitten er geen local root exploits tussen die op jouw systeem van toepassing zijn, maar om dat zeker te weten moet je elke advisory in meer detail bekijken.

Verder is het wel een leuke discussie natuurlijk, hoe beveilig ik een *nix systeem

Begin eens met security updates bijhouden

(in het geval van FreeBSD betekent dat vzviw dat je de Security branch voor je release moet volgen, of de STABLE branch)

[ Voor 3% gewijzigd door deadinspace op 12-11-2007 21:15 ]

[icyx]

bvk schreef op maandag 12 november 2007 @ 20:26:
[...]
Verder is het wel een leuke discussie natuurlijk, hoe beveilig ik een *nix systeem

Zeker! Ik weet zeker dat je hier wel leuke 'discussie's' over kan houden. Denk aan SELinux mogelijkheden, het keys / pw punt van sshd, etc, etc. Een thread in de trant van 'hoe maak ik mijn OS waterdicht' zou an sich wel grappig zijn.
jammer alleen dat ik (bijna) niets van beveiligingen mbt het OS afweet, en het lezen alleen wel interessant vind...

[Boudewijn]

offtopic:
zou idd wel een leuk onderwerp zijn (ik zag net een 'thema' voorbijkomen, is dat niet interessant?)

[icyx]

offtopic:
Thema is inderdaad wel leuk, alleen denk ik dat het voor dit 'idee' minder boeiend is. Thema is namelijk cross-platform, en gaan discussieren over SELinux heeft voor iedere WOS-based server weinig zin. Ik kan morgen als ik weer terug ben van de uni evt. wel een topic openen voor een 'NOS-only' discussie, maar nu ga ik slapen ^^

[Boudewijn]

offtopic:
tsja , een quote van dat thema-dingie:
[quote]
MSSQL2000 database.
Access frontend voor het bewerken van de data (imports, analyse, export naar Excel)
Excel voor rapportage en exports van lijsten.
IIS als webbased frontend (dashboard) voor diskspace.
VBscripting.
TreeSize Pro.
DUMPACL.[/quote]
duidelijk echt heel erg nos

[Borromini]

Rainmaker schreef op maandag 12 november 2007 @ 17:51:
Wachtwoorden kraken is volgens mij allang niet meer the way van hackers.

Niet dat ik er zo in thuis ben, maar volgens mij zou je ervoor moeten zorgen dat alle andere vormen van authenticatie uitstaan. Bijvoorbeeld public / private keys e.d. Ook altijd de laatste versie tegen evt beveiligingslekken e.d.

Volgens mij zijn er nog maar weinig "hackers" die binnenkomen door 50000 verschillende wachtwoorden te proberen. Zeker als je password retry timeout op 10 seconden staat

Bruteforce attacks op SSH-services maken een groot deel van de hackpogingen uit op *nixes.

Public/private keys is net een versterking van het SSH-protocol. Als je gebruikers verplicht om een keypair te gebruiken dan kan er niemand z'n pass ingeven zonder geldige sleutel. Dat is niet makkelijk te kraken .
Aangezien de TS die vziw niet gebruikt maakt het geen verschil of ze uit of aan staan.

Root login over SSH toelaten is evenmin aan te raden, tenzij de box niet van het internet benaderbaar is. Niettemin blijft het een bedenkelijke praktijk.

@ TS: er is geen exploit waarmee je root-rechten kan krijgen op dat ding?

Btw... Als je al die tijd geen root-rechten gehad hebt, dan veronderstel ik ook dat dat ding ondertussen 'verouderde' software draait? Daar moeten wel veiligheidsgaten in te vinden zijn hier en daar. Misschien zelfs in de SSH server zelf .

[ Voor 12% gewijzigd door Borromini op 13-11-2007 14:19 . Reden: Spuit 11 blijkbaar ]

[bvk]

Kijk, het is natuurlijk altijd een afweging tussen gebruikersgemak en veiligheid in dit soort gevallen. Ik ben neem ik aan totaal niet interessant voor een hacker die bijvoorbeeld een server zoekt om lekker mee te FXP'en, te kleine schijf en te trage verbinding.

Blijft alleen een hacker over die zijn bruteforce "technieken" wil uitproberen, maar dan heb je een veel grotere eer van je werk als je bijvoorbeeld de FreeBSD servers van Xs4all weet te hacken, krijg je nog een gratis abonnement ook.

Met andere woorden, daar maak ik me niet zo druk over. Het is meer voor mezelf het idee dat het relatief veilig is (vergeleken met de gemiddelde Windows server bijvoorbeeld) en ik er niet veel omkijken naar heb.

En ik ben noch een security, noch een Unix expert, dus ik ben al lang blij dat het OS standaard de onveilige opties zoals root over SSH uit heeft staan.
Nu na dit topic ben ik me er van bewust dat het allemaal nog veel veiliger kan en moet, al was het alleen maar om hackers te ontmoedigen

Zoals ik al aangaf ben ik geinteresseerd in dat PKI verhaal en ga dat misschien wel implementeren, al hoewel mijn gebruikers daar waarschijnlijk niet blij mee zijn. Root logon toestaan ga ik waarschijnlijk niet doen, wel mezelf in de wheel groep zettten.

En aangezien de server nu waarschijnlijk tóch down gaat vanwege het onderhoud (extra schijf erin, stof eruit), gooi ik er misschien wel meteen de nieuwe 6.2 op of ga ik eens experimenteren met OpenBSD. Dan wil ik jullie nog wel eens horen over security holes

Local root exploit heb ik niet kunnen vinden, ik draai geen programma's tenminste die in dat opzicht een lek hebben voor zover ik kan nagaan.

Maar zijn er hier dan mensen die zeg maar dagelijks de vulnerabilities nagaan en kijken of hun systeem misschien wel kwetsbaar is? Voor een bedrijfs produktieserver kan ik me dat wel voorstellen, maar voor een privé server lijkt het me wel een beetje paranoia...

Tenzij security je hobby is natuurlijk

De moderne OS'en distro's zoals Ubuntu of PC-BSD hebben veelal update mogelijkheden, al dan niet automatisch. Maar voor FreeBSD (zonder gui) heb ik hier niets over kunnen vinden in het handbook etc, weet iemand misschien of ik iets over het hoofd zie?

Edit:

Au!, blij dat ik in het weekend aan de slag kan met een monitor:

/var: write failed, filesystem is full

[ Voor 4% gewijzigd door bvk op 13-11-2007 19:02 ]

[Borromini]

Ik dacht dat je met de BSD's een update kon doen die dingen (de ports dan) lokaal compileerde als update. En ongetwijfeld zijn er ook binaries beschikbaar.

[blorf]

Borromini schreef op dinsdag 13 november 2007 @ 18:52:
Ik dacht dat je met de BSD's een update kon doen die dingen (de ports dan) lokaal compileerde als update. En ongetwijfeld zijn er ook binaries beschikbaar.

In FreeBSD:
#cd /usr/ports/ports-mgmt/portupgrade
#make install
#portupgrade portupgrade
#portugrade --all

maar daar moet je helaas nog steeds root voor zijn.

[blorf]

Borromini schreef op dinsdag 13 november 2007 @ 18:52:
Ik dacht dat je met de BSD's een update kon doen die dingen (de ports dan) lokaal compileerde als update. En ongetwijfeld zijn er ook binaries beschikbaar.

In FreeBSD:
#cd /usr/ports/ports-mgmt/portupgrade
#make install
#portupgrade portupgrade
#portupgrade --all

maar daar moet je helaas nog steeds root voor zijn.

[serkoon]

In de praktijk zal je met lokale non-root rechten op een FreeBSD-bak aardig wat moeite hebben om toch root te krijgen. De suid/sgid-binaries zijn echt wel geaudit door de jaren heen en zullen niet 123 misbruikt kunnen worden. Alleen als je echt clue hebt en zelf de kernel source door wil spitten zul je wat (kunnen) vinden, maar denk dan meer aan race conditions en integer overflows dan aan makkelijker te exploiten buffer overflows. Ook FreeBSD is niet onfeilbaar, maar het 'laaghangende fruit', zoals dat heet, is er zo langzamerhand wel uit.

Wat bij productiedozen vooral de kansen op privilege escalations opleveren zijn dingen als:
1) Outdated 3rd party software (FreeBSD ports) die als root draaien; tegenwoordig al stukken minder makkelijk te exploiten dan eerder; bovendien worden veel daemons met beperkte privileges uitgevoerd.
2) Foute configuratie van die software, bijvoorbeeld een user rechten geven om 'vi' uit te voeren middels sudo.
3) Filepermissies waarmee non-root users naar files kunnen schrijven die door root (al dan niet indirect) uitgevoerd worden.
4) Wazige scripts die onveilige dingen doen (tijdelijke files gebruiken bijv) en als root uitgevoerd worden

Dat soort dingen moet je aan denken wanneer je een modern, fatsoenlijk OS van binnenuit zou moeten hacken. Wat dat betreft had je beter bepaalde commerciele UNIXen (AIX?) kunnen draaien, waar nog steeds, anno 2007, stack based bufferoverflows in standaard meegeleverde suid-binaries gevonden worden

Overigens heb je op zich geen monitor nodig om root-access te fixen; inloggen als root (zonder te zien wat je doet) en een goed werkende one-liner intypen zou genoeg moeten zijn

[bvk]

Ok, laatste mededeling en daarna mag het topic wat mij betreft wegebben of gesloten worden.

Daar ik net van mijn provider een nieuw modem ontvangen heb en monitor/keybord beschikbaar heb gaat komend weekend mijn hele netwerk maar plat. Ik ga dan de server upgraden naar Gigabit ethernet, er een schijf en evt geheugen bijplaatsen en een verse FreeBSD 6.2 installatie doen.
Mijn eigen account voeg ik aan wheel toe, verder doe ik de setup zoals ik die eerst ook gedaan heb. In een later stadium komt daar nog PKI bij, dat is voor mij verder secure genoeg.

Het nieuwe modem is een Speedtouch 780wl, ik hoop dat de firewall net zo goed is als die van mijn huidige Zyxel 660HW

Opmerkingen over de security kunnen verder denk ik beter in het beveiligings topic van icyx geplaatst worden, iedereen nog bedankt voor het meedenken