Hi zusammen,

ich habe heute das Webinterface nach langem gefrickel zum laufen bekommen.
Abgesehen von Programiermüll in /home/eggdrops/script/eggdrop.sh und einem falsch aus der DB geholtem FTP-Passwort das erst gefixt werden musste, lief dann immerhin mal alles. Allerdings hab ich dann erfreulich festgestellt (ironie off), das jeder User der angelegt wird für einen neuen eggdrop, gleich mal ne ssh shell mit dazu bekommt. Find ich absolut mieß eine solche Lücke in ein System zu reißen.

Und die die sich nun Fragen warum Lücke? Stellt euch vor der Kernelbug der alle Systeme betraf, wo man mittels Wunderbar_Emporium sofort root-Rrechte hatte wenn man bloß ne Shell hat auf dem System.

Primär gefixt habe ich das jetzt erstmal mittels eines Eintrags in die sshd_config:

DenyUsers egg*

Ich bin aktuell eh dran für ein paar Freunde das eggdrop.sh zu überarbeiten, denn so wie es momentan ist, sorry will keinen angreifen, ist es einfach murks.
Ich stell euch das dann gern zur Verfügung wenn gewünscht.

Mein Anliegen wäre allerdings schon, das sich um diese "Lücke" vorab mal gekümmert wird.

so long das sofa :)

Nachtrag:

wie es aussieht wird in der DB das FTP-Password in der Tabelle "EGG_FTP_PASS" abgelegt und nicht wie in modules/usr/egg.php deklariert als EGG_SC_FTPP.
Zumindest ist bei mir ein Login mit dem in EGG_SC_FTPP "PW" via ftp nicht möglich nur mittels PW das in EGG_FTP_PASS liegt.
Ka warum das so gemacht wurde, vll kann es mir wer erklären.

Und was folgender Code soll muss mir auch mal wer erklären:
STARTM=`ls -l $DIR | grep $3 | wc -l`

if [[ $STARTM -lt 1 ]]
then
cd $DIR && rm -r *.chan && rm -r *.user
echo "Erstelle Benutzerdateien"
`su egg$2 - -c " cd $DIR && ./eggdrop -m $CFGFILE" > /home/eggdrops/script/egg$2`
else
`su egg$2 - -c " cd $DIR && ./eggdrop" > /home/eggdrops/script/egg$2`
fi

zu STARTM=`ls -l $DIR | grep $3 | wc -l`:
warum prüfe ich ob der Name des Edropps in dem Verzeichnis vorkommt?
wenn ich dann ein falsches Argument in  if [[ $STARTM -lt 2 ]] setze?

und warum versucht man Dateien zu löschen deren Existenz nie geprüft wurde?
Zu sehen hier:
cd $DIR && rm -r *.chan && rm -r *.user

Wenn ich das richtig verstehe, soll hier geprüft werden ob der eggdrop mittels -m gestartet werden soll oder nicht. Wozu dann bitte diese Abfrage und das löschen von Files die es eh nicht geben dürfte wenn man mittels -m startet?

Meiner Meinung nach müsste das wenn dann zumindest so aussehen:

STARTM=`ls -l $DIR | grep $3.user | wc -l`
if [[ $STARTM -lt 2 ]]
then
echo "Erstelle Benutzerdateien"
`su egg$2 - -c " cd $DIR && ./eggdrop -m $CFGFILE" > /home/eggdrops/script/egg$2`
else
`su egg$2 - -c " cd $DIR && ./eggdrop" > /home/eggdrops/script/egg$2`
fi

Vielleicht kann mir das auch noch wer erklären.

---

---

Hallo zeitsofa,

vornweg einmal vielen Dank für das Interesse am Interface, sowie die kritische Überprüfung des Codes.

Die eggdrop.sh ist wirklich nicht wirklich gut gelöst, über eine überarbeite von Dir würde ich mich freuen. Was die SSH User pro Eggdrop angeht, bin ich auf dem Stand, das ein Eggdrop einen gültigen SSH Nutzer benötigt um zu Laufen. Das dies unschöne nebenwirkungen hat, ist mir klar. Sollte es eine bessere Lösung geben, würde ich diese in einer neuen Version des Interfaces berücksichtigen.

Was genau ich mit der angeprangerten IF Abfrage im Shellscript vor hatte, kann ich dir nichtmehr sagen. Für mich ergibt sie momentan genauso keinen Sinn.

Zitat

wie es aussieht wird in der DB das FTP-Password in der Tabelle "EGG_FTP_PASS" abgelegt und nicht wie in modules/usr/egg.php deklariert als EGG_SC_FTPP.
Zumindest ist bei mir ein Login mit dem in EGG_SC_FTPP "PW" via ftp nicht möglich nur mittels PW das in EGG_FTP_PASS liegt.

Wenn ich mich richtig erinnere, werden 2 FTP Accounts angelegt bei der Eggdrop Erstellung. Einer fürs System und einer für den User um selbst Scripte via FTP zu uploaden, ohne auf die Eggdrop Dateien Zugriff zu erhalten.

Nachtrag:

Funktioniert auch nicht, da die Namen der Userfiles abhängig vom EggdropName oder Ident sind, funktionieren sollte ein:
(ungetestet)

---

Viele Grüße

"Jeder, der andere kritisiert, muss eine Alternative haben, die er ihnen anbieten kann." - Mo Ti

---

Zitat von take

Nachtrag:

CODE

1.

STARTM=`ls -l $DIR | grep $3.user | wc -l`

Funktioniert auch nicht, da die Namen der Userfiles abhängig vom EggdropName oder Ident sind, funktionieren sollte ein:

CODE

1.
2.

STARTM=`ls $DIR | grep *.user | wc -l`

(ungetestet)

Hihi schlecht wenn man nicht weiß was in $3 steht :P da steht der EggdropName nämlich drin. Ergo funktioniert beides :)

Bezüglich des FTP weiß ich noch nicht was da wie angelegt wird, faktisch funktionierte bei mir ein FTP-Login via Passwort aus EGG_SC_FTPP nicht.

Was das SSH angeht, wüsste ich bis heute keinen Grund warum ein SSH-User für den eggdrop benötigt wird. Meine eggdrops die ich ohne das Webinterface betreibe rennen auch alle als eigener user und befinden sich, wie die des Webinterfaces, auch alle in der selben Gruppe. Somit könnte man dann in die /etc/ssh/ssd_config entweder ein "DenyGroups egg" packen oder in die /etc/security/access.conf ein "-:@egg:ALL" und dazu in der /etc/pam.d/sshd die zeile mit "account  required  pam_access.so" auskommentieren.

Gäb sicher einige Möglichkeiten den SSH-Zugang zu unterbinden.

Mal sehen findet sich sicher was passendes.

So long das sofa

---

So ich habe noch einmal versucht mich in das Interface herein zu denken.

Zum SSH Problem:
- Jeder Eggdrop sollte einen eigenen SSH User haben, da sonst alle User über die gleichen Rechte auf andere Ordner hätten (TCL-Debug)
- Der SSH Zugang wird für die Eggdrops geblockt über den Eintrag in der sshd_conf "DenyGroups egg" [Siehe Installationsdokumentation]

FTP-Problem:
Auf meinem Testserver funktionieren die Daten so, wie sie sollten. "EGG_FTP_*" steht hierbei für das HomeDir FTP des jeweiligen Eggdrops, also z.B. "/home/eggdrops/egg1/". Wohingegen "EGG_SC_FTP*" für den Scripts Ordner steht.  "~scripts/"

Da sich die ganzen FTP Accounts in der Gruppe "eggs", wird ein SSH Zugang über DenyGroups verhindert.

Um das Shellscript umzuschreiben fehlt mir momentan leider die Zeit. Würde dies aber, sofern Du nicht schneller bist, bei Gelegenheit nachholen.

---

Viele Grüße

"Jeder, der andere kritisiert, muss eine Alternative haben, die er ihnen anbieten kann." - Mo Ti

---

Zitat von take

So ich habe noch einmal versucht mich in das Interface herein zu denken.

Zum SSH Problem:
- Jeder Eggdrop sollte einen eigenen SSH User haben, da sonst alle User über die gleichen Rechte auf andere Ordner hätten (TCL-Debug)
- Der SSH Zugang wird für die Eggdrops geblockt über den Eintrag in der sshd_conf "DenyGroups egg" [Siehe Installationsdokumentation]

Sorry nun zweifel ich gerade an den letzten 10 Jahren die ich mit Linux arbeite. Was bitte haben SSH Zugang und Berechtigungen für Order gemeinsam?

Und ja, es steht in der Installationsanleitung das ist richtig, mir ginge es auch darum den Eintrag automatisch vorzunehmen.

FTP-Problem:
Auf meinem Testserver funktionieren die Daten so, wie sie sollten. "EGG_FTP_*" steht hierbei für das HomeDir FTP des jeweiligen Eggdrops, also z.B. "/home/eggdrops/egg1/". Wohingegen "EGG_SC_FTP*" für den Scripts Ordner steht.  "~scripts/"

Ok, anders Fragen, woher nimmt der User übers Webinterface das PW um auf sich via FTP auf den Server zu verbinden um Änderungen an der eggdrop.conf vorzunehmen?

Liebe Grüße Sofa

Nachtrag:

Vor lauter im Code rumsuchen ist mir bei dem FTP Zeug ein Fehler unterlaufen. Sorry dafür. Was ich eigentlich meinte war.

Wenn ich im Webinterface www.meineggdropinterface.de/index.php?go=usr&;sub=egg&id=4&mode=config öffne - steht unten:

FTP User: eggs$
FTP PW: irgendeinpw

Die Kombination aus User und PW erlaubt es mir nicht mich einzuloggen auf Ebene des /home/eggdrops/egg$/ sondern lediglich auf ebene des Scripts-Ordner. Das war das eigentliche Problem. Sorry für die Verwirrung. Daraus resultiert die Frage, was will ein User mit diesen Zugangsdaten? Alles was dort geändert werden kann, kann auch übers Webinterface geändert werden (dafür hast du ja die Script-upload funktion eingebaut wie man www.meineggdropinterface.de/index.php?go=usr&;sub=egg&id=4&mode=scripte entnehmen kann). Viel entscheidender wäre doch, das dort die Daten stehen würden um sich via FTP in /home/eggdrops/egg$ einzuloggen wo sich ja die Konfigdatei "eggdrop.conf" befindet. Denn eine Funktion die Konfigdatei zu ändern habe ich bis heute im Webinterface selber nicht gefunden (nicht auszuschließen das ich blind war und es schlicht weg übersehen habe).

Um dem User aber etwas neues dort anzuzeigen was er auch wirklich braucht (den Zugang zum Scriptsordner braucht er ja nicht das macht ja das Webinterface) wäre es doch sinnvoll die Datei "modules/usr/egg.php" in den Zeilen 233 und 237 von


und


auf


und


abzuändern. Oder?

---

In der Datei "kernel/config.php" steht das eggdrop.conf-Template. Dies kannst Du dort global ändern. Der Scriptordner-FTP-Zugang war für den Upload größerer, oder mehrdateiiger Scripte gedacht.

Ich habe extra auf das Veröffentlichen des HauptFTP-Zugangs verzichtet, da die eggdrop.conf eh vom Webinterface überschrieben wird. Änderungen an ihr wären also eh nur temporär.

---------------------------

Zitat

Sorry nun zweifel ich gerade an den letzten 10 Jahren die ich mit Linux arbeite. Was bitte haben SSH Zugang und Berechtigungen für Order gemeinsam?

Wenn alle n-Eggdrops von x-Usern über ein und den selben Nutzeraccount gestartet werden, haben diese Eggdrops alle das selbe Recht. Sie könnten auf Ordner und Dateien anderer Eggdropnutzer zugreifen. Wodurch man die Dateien nicht über einfache Maßnahmen wie umask sichern könnte.

-----------------------------

Ich denke das es kein größeres Sicherheitsrisiko darstellt, wenn jeder Eggdrop über einen eigenen Benutzeraccount verfügt, als einen Account für alle Eggdrops.
Ein Account zum starten wird so, oder so gebraucht.

-----------------------------

Zitat

Und ja, es steht in der Installationsanleitung das ist richtig, mir ginge es auch darum den Eintrag automatisch vorzunehmen.

Das habe ich mir anfangs auch überlegt, und bin dann zu dem Entschluss gekommen, das der "sicherste" Weg das manuelle Hinzufügen des Eintrages ist. Sollte es zu -irgendwelchen- Komblikationen beim hinzufügen der Zeile kommen und somit der SSHd abstürzt, wären sicher viele Nutzer des Interfaces aufgeschmissen. Beim manuellen Einfügen würden Fehler sofort auf der Konsole sichtbar und es könnte dementsprechend reagiert werden.

---

Viele Grüße

"Jeder, der andere kritisiert, muss eine Alternative haben, die er ihnen anbieten kann." - Mo Ti

---

Ok bezüglich des SSH und Nutzeraccounts missverstehen wir uns gerade etwas.

Mal sprichst du von User(Nutzeraccounts) mal von SSH-Zugängen ;) Aber nun weiss ich wie du das meinst. Und es ist durchaus richtig, das jeder eggdrop einen eigenen User hat, von dem aus er gestartet wird.

Wie ich die automatische SSH-"Sperre" einbauen schreibe ich mit in meine überarbeite Version ;) (ganz ohne das Risiko einem User den SSH-zugang zu killen.
Was ja in der Tat fatal wäre.

Zitat

Ich habe extra auf das Veröffentlichen des HauptFTP-Zugangs verzichtet, da die eggdrop.conf eh vom Webinterface überschrieben wird. Änderungen an ihr wären also eh nur temporär.

hmm ok, das wirft die frage auf, warum die User in der Konfiguration ihres Eggdrops so beschnitten werden, denn jeder User hat vll andere Einstellungen die er bevorzugt (ggf. auch IRC-Server bedingt). Die User haben so also gar keine Möglichkeit tief greifende Veränderungen an der eggdrop.conf vorzunehmen?

Wenn der Haupt-FTP-Zugang vom User eh nicht gebraucht wird, warum legst du dann in deinem Skript einen User mit Passwort an? Dann wäre es doch einfacher "useradd -r" zu benutzen um einen Systemaccount anzulegen, oder?

Liebe Grüße das sofa

---

Ich glaube, das zusätzliche Optionen über TCL Scripte in die Config eingebunden werden können, oder ist dies so nicht möglich?

Der FTP Benutzer ist gleich ein ShellAccount - welcher zum starten des Eggdrops genutzt wird. Dieser hat also 2 Funktionen, zum einen um die abgeänderte Eggdrop.conf zu übertragen (via FTP) und zum anderen den Eggdrop zu starten.

---

Viele Grüße

"Jeder, der andere kritisiert, muss eine Alternative haben, die er ihnen anbieten kann." - Mo Ti

---

Wozu habe ich eine Konfigurationsdatei für den Eggdrop wenn ich die Konfiguration über TCL-Scripte machen muss?
das wäre doch ein bisschen am Sinn der Datei vorbei findest du nicht?

Wann wird denn die config immer überschrieben? Bei jedem mal wo
www.meininterface.de/index.php?go=usr&sub=egg&id=4&mode=config abgeändert wird?
wenn ich das richtig sehe in der egg.php wirklich bei jedem "ändern" klicken in der Eggdrop-Konfiguration des Webinterface. Das ist echt heavy wie ich finde.

Mir ist gerade aufgefallen, wenn ein Bot angelegt ist, und ich will als admin nachträglich den Server ändern, via www.meininterface.de/index.php?go=usr&;sub=egg&id=4&mode=config wähle also das neue Netzwerk aus dem drop down aus- wird diese änderung nicht geschrieben. Ist das normal und so gewünscht?

Änder ich das aber via editieren der eggdrop.conf und starte dann neu wird die Änderung vollzogen, natürlich steht im interface dann was falsches. (das interface liest ja aus der db und nicht aus dem config file wenn ich das richtig sehe)

---

Zitat

Wozu habe ich eine Konfigurationsdatei für den Eggdrop wenn ich die Konfiguration über TCL-Scripte machen muss?
das wäre doch ein bisschen am Sinn der Datei vorbei findest du nicht?

Das Problem ist, wenn Du Zugriff auf die Config-Datei gewährst, sind deine Admineinstellungen im Interface sinnlos, da der User dann nichtmehr an ein Netzwerk/IP/VHost/.. gebunden wäre, sondern dies selbst ohne große Probleme umgehen kann.

Zitat

Wann wird denn die config immer überschrieben? Bei jedem mal wo
www.meininterface.de/index.php?go=usr&sub=egg&id=4&mode=config abgeändert wird?
wenn ich das richtig sehe in der egg.php wirklich bei jedem "ändern" klicken in der Eggdrop-Konfiguration des Webinterface. Das ist echt heavy wie ich finde.

Richtig, dies war, abhängig von meinen Fähigkeiten vor 2,5 Jahren, für mich nicht anders zu Lösen.

Zitat

Mir ist gerade aufgefallen, wenn ein Bot angelegt ist, und ich will als admin nachträglich den Server ändern, via www.meininterface.de/index.php?go=usr&;;sub=egg&id=4&mode=config wähle also das neue Netzwerk aus dem drop down aus- wird diese änderung nicht geschrieben. Ist das normal und so gewünscht?

Ja, die Änderungen werden erst zum Eggdrop übertragen, wenn der User in seiner Config etwas bearbeitet. Dies habe ich aus Sicht der Performance getan, da ein PHP Script leider erst dann zu Ende ist, wenn es abgearbeitet ist/PHP ist nicht Multithreadfähig. Schon das Übertragen der Config auf 5 unterschiedliche Eggdrops (5 FTP Verbindungen nach einander) würde man Spürbar bei der Abarbeitung merken.

Zitat

Änder ich das aber via editieren der eggdrop.conf und starte dann neu wird die Änderung vollzogen, natürlich steht im interface dann was falsches. (das interface liest ja aus der db und nicht aus dem config file wenn ich das richtig sehe)

Das Verhalten ist bei Webinterfacen üblich, es wäre ein viel zu Großer Aufwand, bei jedem Webinterface Besuch erst die Daten aus der Config auszulesen. Durch die Benutzung von Interfacen wird das manuelle Bearbeiten von Konfigurationsdateien leider erschwert. Dies ist nur über eine 2. Datei möglich, welche das Interface nicht neu schreibt. Das Includen dieser könntest Du in der config.php als Defaulttemplate einsetzen und in das Eggdrop Image mit integrieren - als leere Datei, gelegen im Scriptordner (Um sie dem User zugänglich zu machen).

---

Viele Grüße

"Jeder, der andere kritisiert, muss eine Alternative haben, die er ihnen anbieten kann." - Mo Ti

---