Zugangsschutz Intranet / Zugriff auf Benutzerverwaltung

[xelarep]

Hallo,

die wichtigsten Antworten zu .htaccess und einer evtl. Passwortanforderung beim Zugriff auf einen bestimmten Bereich meiner DS habe ich schon gefunden (Hier/WiKI und SelfHTML):

# .htaccess-Datei für Internen Bereich 
AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /volume1/web/internes/.htpasswd
Require valid-user
Order deny,allow
Deny from all
Allow from 192.168
Satisfy any

Ich möchte also eine Passwortabfrage, wenn jemand "von aussen" kommt, und keine Passwortabfrage im lokalen Netz. Obiges funktioniert übrigens prima.

Jetzt sehe ich aber vor lauter Bäumen den Wald nicht: ich möchte eiegntlich keine eigene/parallele Benutzerverwaltung aufbauen, sondern auf die bestehende Benutzerkonten zugreifen. Welchen Pfad müsste ich da für AuthUserFile angeben? Oder mach ich hier einen kompletten Denkfehler?

Alexander

 

[jahlives]

Ich glaube nicht, dass du direkt an der lokalen Userdatei (/etc/passwd und /etc/shadow) mit dem Webserver authentifizieren kannst. Das geht wohl nur über eine eigene Benutzerverwaltung mittels htpasswd im Webserver.
Als einzigen automatisierten Weg könnte ich mir vorstellen, dass du die Benutzerdaten nach htpasswd importieren könntest mittels shellscript

cut -f1,2 -d: /etc/shadow

obiger Code als root und mit installiertem ipkg Paket (cut ist glaub ich bei fileutils mitdabei) sollte dir die UserasswortHashes aus shadow rausholen. Diesen String könntest du nach htpasswd kopieren.
Achtung: Der Webserver übermittelt die Passworte unverschlüsselt. Schlechte Idee z.B. für root.
Und zwei Dateien hast du auf jeden Fall, denn der direkte Zugriff auf /etc/shadow ist für den Webserver nicht möglich. Du musst in jedem Fall eine Userverwaltung im Webserver führen.

Gruss

tobi

 

[xelarep]

Hallo Tobi,

hört sich gut an! Ich hab mir gerade die /etc/shadow mal angeschaut. Cut muss ich mal testen, installiert ist es.
Da bau ich mir mal was, wo nur bestimmte Benutzer exportiert werden: ich brauch nicht alle Benutzer, das vereinfacht die Sache etwas. Mir geht's hauptsächlich darum, dass die Passworte aktuell/synchron sind.

Melde mich später nochmal!

Danke,
Alexander

 

[xelarep]

Funktioniert!

OK, jetzt ist später

1. per konsole anmelden und kleines script bauen. Heisst bei mir beispielsweise getlist.sh. Nano ist mein Freund...

# Kopiere User in .htpasswd
cut -f1,2 -d: /etc/shadow >/root/current.tmp
echo User1,
grep User1 /root/current.tmp >/root/mylist.tmp
echo User2,
grep User2 /root/current.tmp >>/root/mylist.tmp
echo Kopiere temporäre Liste und lösche Zwischendateien
cp /root/mylist.tmp /volume1/web/internes/.htpasswd
rm /root/current.tmp
rm /root/mylist.tmp
echo Fertig!

Das Ganze geht per Piping bestimmt eleganter, aber es geht ums Prinzip
Obiges Scripts holt sich nur die beiden Benutzer User1 und User2 aus der Kennwortliste. Somit bleiben root und andere Konten unangetastet und können auch nicht ausgelsen werden.

2. das ganze ausführbar machen mit

chmod 755 getlist.sh

und
3. laufen lassen

./getlist.sh

Jetzt muss ich nur noch raussuchen, wie ich das entweder in meine Managementoberfläche reinbauen kann, oder bei jedem Systemstart einmal laufen lasse. Aber dazu gab's hier ja schon Beiträge.

Das wird jetzt das zweite Dingens, dass ich ins WiKi stellen sollte... Trag ich noch nach.

Gruß,
Alexander

 

[jahlives]

OK, jetzt ist später

1. per konsole anmelden und kleines script bauen. Heisst bei mir beispielsweise getlist.sh. Nano ist mein Freund...
Ist auch mein Freund

2. das ganze ausführbar machen mit

	
	



	
	

		
chmod 755 getlist.sh
	
und

Sehr schöne Lösung :) Ich würde aber das Teil nicht für alle ausführbar machen, sondern nur für root und sonst für niemanden. Als Startscript würde es eh als root laufen und auch im DSM würde es wohl unter root ausgeführt.
Wobei die Lösung mit dem DSM ganz edel wäre. Bei jeder Änderung der User im DSM einfach das Script zum Abschluss ausführen. Allerdings keine Ahnung wie du den DSM dazu bringen könntest in der Benutzerverwaltung zum Abschluss dein Script aufzurufen

 

[xelarep]

Sehr schöne Lösung Ich würde aber das Teil nicht für alle ausführbar machen, sondern nur für root und sonst für niemanden. Als Startscript würde es eh als root laufen und auch im DSM würde es wohl unter root ausgeführt.
Wobei die Lösung mit dem DSM ganz edel wäre. Bei jeder Änderung der User im DSM einfach das Script zum Abschluss ausführen. Allerdings keine Ahnung wie du den DSM dazu bringen könntest in der Benutzerverwaltung zum Abschluss dein Script aufzurufen

Hm, ohne jetzt näher drüber nachgedacht zu haben: eigentlich müsste man nur /etc/shadow Datei auf Veränderung überwachen? Immer wenn diese sich ändert (z.B. Passwortänderung) das Script ausführen. OK und hier weiss ich nicht weiter ;-) Neue Benutzer müssen sowieso manuell aufgenommen werden.
Ich dachte eher an: "ich hab nen Knopf im DSM (oder auf meinem Internen Bereich), mit dem ich das Script manuell starten kann."

Alexander

 

[jahlives]

Eine Idee könnte sein, von der shadow den md5 Hash zu bilden und den in einer Datei zu speichern. Dann dein Script, das jede Minute von cron aufgerufen wird und den md5 Hash mit dem aktuellen Hash der Datei vergleicht. Wenn sie unterschiedlich sind, dann schreib die htpasswd wieder neu und speichere den md5Hash der aktuellen Shadow wieder in der Datei. Wenn die beiden Hashes übereinstimmen, dann einfach exit.
Oder du machst das ganze mit einer Endlosschleife und sleep.

 

[xelarep]

So in der Richtung hatte ich auch gedacht: passender cron job, oder einfach Vergleich mit der letzten Kopie der /etc/shadow

1x die Minute ist mir viel zu oft - ich dachte eher an alle 6-12h. So oft ändert sich bei mir nix

Da stellt sich dann eher die Frage, ob der Cron Job eine schlafende Festplatte wecken würde, das fände ich schon wesentlich ärgerlicher.

Wahrscheinlich pack ich das eh besser in den "Autostart" - alle 24h reicht auch. Und wenn ich manuell neu synchronisieren möchte, mach ich per DSM einfach einen reboot - Quick'n'Dirty

Alexander

 

[jahlives]

Und wenn ich manuell neu synchronisieren möchte, mach ich per DSM einfach einen reboot - Quick'n'Dirty

wieso nicht einfach das Script auf der Konsole aufrufen ? -Quicker'n'lessDirty

 

[xelarep]

wieso nicht einfach das Script auf der Konsole aufrufen ? -Quicker'n'lessDirty

Ich bezog das auf den "Auswärts-Fall". Ich hab telnet/SSH nicht durchgeroutet. Wenn ich zu Hause bin natürlich per Konsole

 

[itari]

Jede Linux-Datei hat 3 Zeitstempel:

1] wann sie zuletzt gelesen wurde
2] wann sie zuletzt geändert wurde
3] wann ihre Inode-Infos geändert wurden (Eigentümer, Rechte usw.)

Der ls hat Optionen, mit denen man sich das jeweils anzeigen lassen kann. Mit dem find kann man auch prüfen, ob eine Dateiänderung älter oder jünger als einen andere Datei ist. Auf dieses Weise, kann man auch herausbekommen, ob eine Datei geändert wurde ...

Itari

 

[xelarep]

Ach so,
bevor es untergeht, und mir die Zeit nehme das alles über Weihnachten ins WiKi zu stellen:

Bis mir was besseres einfällt, oder ich öfters Updates meiner "Benutzerverwaltung" benötige, habe ich mein obiges Script um den #! bins/sh header erweitert und als "S99cpiusers.sh" in den Ordner /usr/syno/etc.defaults/rc.d meiner DS gelegt.

Somit wird jeden morgen beim zeitgesteuereten Hochfahren die Passwortliste abgeglichen.

 

[jahlives]

Noch was kleines: Die Pasworte werden beim Webserver unverschlüsselt übermittelt. Da in diesem Fall lokale und webserver User/PW identisch sind, könnte man das als Sichereitslücke sehen
@itari
Was passiert eigentlich mit dem "geändert Datum" wenn man den 100% identischen String nochmals reinschreibt?

 

[itari]

@itari
Was passiert eigentlich mit dem "geändert Datum" wenn man den 100% identischen String nochmals reinschreibt?

Du kennst ja sicherlich die Dateiverarbeitung von PHP.

- Open eines Dateistreams
- Write der Daten
- Flush der Daten ... und jetzt wird der Änderungszeitstempel geschrieben ... weil ja auch das Transaktionsprotokoll von ext3 davon lebt
- Close des Dateistreams ... Freigabe eventueller Lock-Ressourcen ... Commit des Transaktionsprotokolls von ext3 (= Journal)

Idee klar? Wenn kein Buffer-Flush ... keine Änderung des Zeitstempels

Itari

 

[MathewDE]

Hallo zusammen,

sehr schöner Guide - genau den habe ich gesucht.

Was passiert aber, wenn ich nicht das "User-Grep" in der Skript-Datei nicht mache und damit alle User inkl. DS nobody, root etc. übernehme. Zwar steht da im Passwort dann "*" aber anmelden kann man sich damit doch auch nicht?! Oder????

Probleme bereiten mir nämlich die Auseinanderhaltung der System/Normaluser. Kann da mit den ersten zwei Spalten leider keine Regel anwenden.

Viele Grüße
matthias

 

[Tagger]

Probleme bereiten mir nämlich die Auseinanderhaltung der System/Normaluser. Kann da mit den ersten zwei Spalten leider keine Regel anwenden.

Dann nimm doch die "etc/group" zu Hilfe. Lege dir eine Gruppe an (web) für alle benötigten user. Dann liest du per script die "etc/group" aus und die gibt dir dann die entsprechenden user. Von da an normal weiter.