Freenas vraagje

Windows, Android, iOS, Linux, Chrome OS, ...
Plaats reactie
ITnetadmin
userbase crew
userbase crew
Berichten: 8974
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 690 keer
Recent bedankt: 2 keer

Freenas blijft blijkbaar koppig weigeren om hun console interface van een pwd te voorzien, waardoor die storage environment wel heel open en bloot ligt naar accidentjes toe.
Nu kan je wel de console interface uitschakelen, waardoor je een gewone login prompt krijgt.
Dan kan je na root login die interface gewoon terug oproepen door "/etc/netcli" te runnen.
Probleem is dat ik daarna niet meer uitgelogd geraak.
Ik kan wel terug naar de shell (door die optie te kiezen in de interface), maar als ik dan mijn user probeer uit te loggen, kom ik terug in de console interface (begrijpelijk, want hij heeft wss een nested shell opgestart.

De vraag is dus:
Hoe geraak ik terug uit de console naar de shell, als ik de console manueel opgestart heb vanuit de shell?

Een unprotected console interface runnen is een no-go voor mij.
Ik dacht dus de console te disablen, en dan een symbolic link te creeren naar "/etc/netcli" en die "console" ofzo te noemen, maar eenmaal ik die oproep geraak ik er niet meer uit, laat staan terug uitgelogd, wat de deur wel weer wagenwijd openzet.

De freenas forums geven niet direct een antwoord.
En forumreacties a la "please lock your console" krijgen botte "if someone can access the hardware you're f*** anyway" antwoorden die ik klasseer als de typische botte "linux/unix rtfm cultuur", dus daar blijf ik liever weg.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5250
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

tgoh, theoretisch hebben ze wel gelijk natuurlijk: fysieke toegang tot je server, dan maakt een paswoord op je console niet zo meer uit (bios in, booten vanaf stickje, et voila)

wat betreft je vraag: werkt suspenden (ctrl-z) en dan killen niet? of gewoon rechtstreeks het proces killen vanuit de shell die je er krijgt?
ITnetadmin
userbase crew
userbase crew
Berichten: 8974
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 690 keer
Recent bedankt: 2 keer

Ik zal het ns proberen.
Het is alleszins vervelend dat je de console wel kan opstarten vanuit de shell maar niet kan sluiten.
De enige methode die ik tot nu toe gevonden heb is via de GUI de console enablen en terug disablen.

Ivm met de argumentatie dat hardware access betekent dat je verder geen maatregelen hoeft te nemen, citeer ik effe iemand van het forum die dat genuanceerder ziet, en ik kan het niet beter uitleggen :-)
It's quite common in many environments.  In particular, I've seen lots of academic environments where a room has been "modernized" to be a computer lab, but since the facility wasn't designed for it, there isn't a separate lockable closet or room for servers and networking gear.  In many colocation centers, there's a security guard at the door who will verify permission to remove equipment and log such removals, but internal protection will typically consist only of fences and video cameras, and there are easily exploitable weaknesses.

Security is a complicated thing.  It is worthwhile to note that most locks are designed to keep honest people honest, and that virtually no amount of security will keep a determined, well-resourced attacker from being successful against you.  I like to explain physical security with the door analogy:

Think about a door.  You can close your bathroom door and set the privacy lock, but any adult with a solid shoulder can break that door, or with a pin (or flathead or whatever your particular knob uses) can stick it in and trigger the unlock.  Your front door is more solid, but if it's wood, and not reinforced, I'll give my steel-toed boots better than even odds against it.  What?  You have a commercial hollow steel door?  Ok, that beats all of that, let me go get my big crowbar, a little bending will let me win.  Something more solid?  Ram it with a truck.  You got a freakin' bank vault door?  Explosives, torches, etc.  Fort Knox?  Bring a large enough army, you'll still get in.

Console logins are a completely reasonable level of defense for certain environments.  Consider a small office where the fileserver might contain sensitive materials such as payroll data or the boss' e-mail.  Do you really want to trust that someone with a little Linux experience isn't going to get curious, one night when they're working late, all alone, and go poking around and looking at files?

So, let me wind this up as follows:

You're RIGHT, in any environment where an adversary could accomplish goals via theft, securing the server from physical removal is a necessary step.

However, in some cases, theft of hardware is a trite goal, because hardware is worth relatively little, and alerts the victim of the event.  In many cases, it is the information *on* the server that's of true value, and it probably isn't that hard for someone to come along, attach a USB drive, run a few commands through that unprotected console interface, and have a copy of your juicy data.  Or, worse, log in, twiddle the FreeNAS database, adding an additional user who then has access to shares until either someone notices or the server is reloaded and reconfigured from scratch, which might be months or years of illicit access.

There's a reason that most gear offers the option to protect its console.  FreeNAS definitely has the capability to do what we're talking about, by the way, there's just no WebGUI checkbox to cause it to happen.  My previous suggestion in this thread is sufficient for people who find themselves with such needs.  It would be kind-of nice to see FreeNAS support this though, it probably wouldn't be too difficult to add some logic in /etc/netcli to do this.
(source: https://forums.freenas.org/index.php?th ... sole.5382/)
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5250
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

ITnetadmin schreef: Ivm met de argumentatie dat hardware access betekent dat je verder geen maatregelen hoeft te nemen, citeer ik effe iemand van het forum die dat genuanceerder ziet, en ik kan het niet beter uitleggen :-)
...
(source: https://forums.freenas.org/index.php?th ... sole.5382/)
ik zeg niet dat je de consolle niet moet beveiligen (dat is een ieder-voor-zich verhaal), maar het blijft er toch nog steeds op neerkomen:
heeft je server een usb aansluiting, en heeft iemand fysieke toegang... dan is het nog steeds triviaal om je data vast te krijgen.
ITnetadmin
userbase crew
userbase crew
Berichten: 8974
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 690 keer
Recent bedankt: 2 keer

Uiteraard. Ik geef je gelijk.
Maar vele mensen denken in IT vaak "als je het niet volledig kan beveiligen dan kan je beter niks doen".
En da's uiteraard totale onzin.

Ja, de server fysiek stelen zorgt ervoor dat iedereen eraan kan.
Maar een of andere collega ITer die op de KVM per ongeluk de verkeerde toetsen indrukt en je storage environment is om zeep.

Passwords enzo zijn dan ook vaker access control, ipv totale security.
Beter nog is meer dan 1 user hebben, zodat meneer junior sysadmin bv wel de toestellen mag rebooten, maar niet aan de settings mag komen.
Of curieuzeneuzen een beetje op afstand houden.

Het argument "het is fysieke access dus een pwd beschermt je niet" gebruiken om het er gewoon niet in te steken en alles open en bloot te laten is totale onzin, en maakt freenas in mijn opinie serieus slecht voor elke omgeving.
Mijn cisco consoles hebben een paswoord. En ja, dat is ook fysieke access, maar toch.
Dat geldt ook voor dingen als vmware esx, pfsense, xenserver, ...
Allen hebben ze minstens een root login op de console, als je geluk hebt zelfs multi-user finegrained access.

Het laatste wat je wil is toch dat je storage omgeving per ongeluk gewist kan worden, of totaal gemisconfigged.
Dat je pfsense router onderuit gaat, is geen gigantisch euvel en mits wat backups snel opgelost, en zelfs dat ding heeft een pwd optie op zijn console.

Een pwd gebruiken wil dan ook niet zeggen dat je geen fysieke access moet proberen te controleren, maar in de praktijk lukt dat niet altijd.
Bv het serverlokaal is ook het kuiskot, of de baas heeft overal sleutels van en kan nergens afblijven, etc etc...

Security is in lagen, en de verantwoordelijkheid ervoor helemaal op de fysieke laag leggen is verkeerd van freenas, maar ze blijven blijkbaar koppig volhouden.
Nu, je kan idd de console afzetten, maar in tegenstelling tot pakweg pfsense, krijg je dan ook de console helemaal niet meer te zien als je inlogt op het toestel.
En vind je terug hoe de console op te roepen (/etc/netcli) dan zit je er terug in vast want kan je blijkbaar niet meer uitloggen.
Dit is amateurisme op z'n best.
Gebruikersavatar
Splitter
Elite Poster
Elite Poster
Berichten: 5250
Lid geworden op: 10 maa 2010, 12:30
Uitgedeelde bedankjes: 64 keer
Bedankt: 526 keer
Recent bedankt: 12 keer

ITnetadmin schreef: Security is in lagen, en de verantwoordelijkheid ervoor helemaal op de fysieke laag leggen is verkeerd van freenas, maar ze blijven blijkbaar koppig volhouden.
klopt, alles wat security bijvoegt (fysiek of niet, by obscurity of niet) helpt.

ik gebruik al geruime tijd geen nas distro meer: gewoon een ubuntu server met enkel ssh, en dan sshfs en public key authentication.
al de rest is toch maar fancy stuff dat je éigenlijk amper gebruikt.
(nu moet ik wel eraan toevoegen dat mijn nas in vmware draait, en ik hardware raid gebruik)
ITnetadmin
userbase crew
userbase crew
Berichten: 8974
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 690 keer
Recent bedankt: 2 keer

Ik gebruik dat vooral om een iscsi omgeving op te zetten voor een gepoolde xenserver environment.


EDIT:
Splitter schreef: wat betreft je vraag: werkt suspenden (ctrl-z) en dan killen niet? of gewoon rechtstreeks het proces killen vanuit de shell die je er krijgt?
Woohoo, dat suspenden werkt.
Nu het killen nog. Hoe doe je dat op een freebsd? Systemctl kent dat ding precies niet.
En dan die commandos in een of andere batchfile gieten zodat de ITers dat kunnen onthouden.


PS:
Aangezien je niet kan dubbelposten en een edit het topic niet refresht, heb ik de post dan dan maar gekopieerd, gewist, en opnieuw gepost.


EDIT 2:
Never mind, blijkbaar terminate de job vanzelf als je uitlogt.
Je moet spijtig genoeg het exit of logout commando wel 2 keer geven, omdat hij niet wil vanwege die suspended job, maar het bespaart de minder technisch aangelegde ITers toch de moeite om te leren werken met "jobs" en "kill".
(de kill is als volgt, voor de geinteresseerden: je vraagt het jobnr op via "jobs -s", en dan "kill %1", maar het percent voor de jobnr vergeten kan serieuze gevolgen hebben, kill 1 bv is al nefast, want dan killt hij het process met dat process ID ipv het job ID ;-) ).
ubremoved_539
Deel van't meubilair
Deel van't meubilair
Berichten: 29849
Lid geworden op: 28 okt 2003, 09:17
Uitgedeelde bedankjes: 434 keer
Bedankt: 1972 keer

ITnetadmin schreef:Maar vele mensen denken in IT vaak "als je het niet volledig kan beveiligen dan kan je beter niks doen".
En da's uiteraard totale onzin.
Tja, en wie maakte opmerkingen over het feit dat Tweakers z'n pagina's volledig in https geeft :lol:
ITnetadmin
userbase crew
userbase crew
Berichten: 8974
Lid geworden op: 28 jan 2012, 18:22
Uitgedeelde bedankjes: 199 keer
Bedankt: 690 keer
Recent bedankt: 2 keer

Ik heb nooit gezegd dat je dan beter geen https gebruikt ;-)
Wel dat je eigenlijk vals speelt door een kleine achterdeur open te zetten en de user er niet van te verwittigen dat bepaalde data op de pagina extern ingeladen werd door de server via een http sessie.
Maar dat is idd geen enkele reden om geen https te gebruiken; wel om niet via de achterdeur mixed content unsecure in te laden.

Wat ik wel haat is redirects die http intercepten en naar https omleiden.
Bv oude tablets die geen CA updates meer krijgen worden zo uitgesloten als ze de https pagina niet willen laden en geen optie geven om het cert te authorisen.
Maar da's voor dat ander topic ;-)
Plaats reactie

Terug naar “Software en apps”