RootForum Community

Hallo,

gibt es eine Möglichkeit entweder im Nachhinein oder für die Zukunft herauszufinden, welches Script eine Datei in /tmp angelegt hat? Ich gehe stark davon aus, dass irgendeine Sicherheitslücke von irgendeinem PHP Script auf dem Webserver (z.B. ein ungepatchtes phpBB Forum) ausgenutzt wird um "nette" .pl Dateien im /tmp Verzeichnis abzulegen. Um die Ursache zu beseitigen und nach Mühsamen neu aufsetzen und neu einrichten der Accounts am Wochenende nicht wieder vor dem gleichen Problem zu stehen. Die "netten Zeitgenossen" sitzen ja oft in der ersten Reihe, sprich: Sind angemeldete User des Webservers.

Danke im Voraus für Eure Hilfe.

mfg k

Hi,

mounte doch /tmp einfach sicherer - noexec,nosuid,nodev - damit umgehst Du schon mal das Problem.

Haben die User bei Dir Shell-Zugriff?

flo.

Hallo,

das tmp Verzeichnis liegt auf der gleichen Partition wie auch alles andere (ja, ich weiss.. ist aber leider so vorkonfiguriert gewesen. Da ich jetzt schon einiges mehr an Ahnung habe was Linux betrifft, werde ich mir ein sauberes Debian selbst aufsetzen.)

Kann ich das trotzdem irgendwie hintricksen?
Warum schreien die PHP Applikationen wenn ich dem /tmp Verzeichnis die Execute Rechte wegnehme? Die werden für die Session Daten doch eigentlich nicht gebraucht, oder?

mfg k

edit: Nein die User haben keinen Shellzugriff, ich hab aber schon so nette PHP Scripts gesehen welche eine Shell simulieren...

agent_k wrote:edit: Nein die User haben keinen Shellzugriff, ich hab aber schon so nette PHP Scripts gesehen welche eine Shell simulieren...

Wie wäre es mit php-(f)cgi? Und die Manual von PHP Safe Mode sollte man nicht ausser acht lassen, vor allem disable_functions.. :x

agent_k wrote:das tmp Verzeichnis liegt auf der gleichen Partition wie auch alles andere

Dann mounte ein kleines ISO über Loopback ;-)
(Ich vergesse auch jedesmal wieder, meinem Home-Server eine Temp-Partition zu geben)

agent_k wrote: Warum schreien die PHP Applikationen wenn ich dem /tmp Verzeichnis die Execute Rechte wegnehme?

Sollte nicht sein - ich benutze allerdings auch einen phptemp-Ordner im Home des Benutzers, aber auch auf dem Heimserver arbeitet das einwandfrei.

flo.

agent_k wrote:Warum schreien die PHP Applikationen wenn ich dem /tmp Verzeichnis die Execute Rechte wegnehme? Die werden für die Session Daten doch eigentlich nicht gebraucht, oder?

Du kannst einem Verzeichnis keine Execute-Rechte wegnehmen, weil es nicht ausgeführt werden kann. Wenn Du dieses Recht wegnimmst, kommt man nicht mehr in das Verzeichnis.

http://www.selflinux.org/selflinux-deve ... l#d20e1256

caput wrote:Wie wäre es mit php-(f)cgi? Und die Manual von PHP Safe Mode sollte man nicht ausser acht lassen, vor allem disable_functions.. :x

Das bringt Dir aber nur dann was, wenn Du kein CGI erlaubst, denn damit kann man das alles umgehen.

Und man sollte in Zusammenhang mit Safe-Mode folgendes Statement des Entwickler-Teams kennen: http://de3.php.net/security-note.php

Safe-Mode ist nicht die Lösung dieses Problems, es ist ein Workaround für einen Teil der Probleme - der zudem löcherig ist.

Hallo,

danke für die zahlreichen Antworten.

@Joe User:
Da ich auch verstehen möchte was ich auf meiner Kiste mache, tut sich die Frage auf was dein Eintrag in der fstab bewirken würde.. Kann ich diesen Eintrag machen wenn das /tmp Verzeichnis auf der gleichen Partition liegt? Ich bin durch das tmpfs etwas verwirrt da am Anfang doch normalerweise das Device/die Partition steht... Für man fstab oder Ã?hnliches hab ich grad keine Zeit da mich scheinbar wirklich jemand nicht mag:
CPU Last alles in allem 100%, alle 4 Prozesse stehen bei PASSWD, daher gehe ich davon aus dass es sich um eine Bruteforce Attacke handelt. Gibt es eine Möglichkeit mit proftpd z.B. nach x fehlgeschlagenen Anmeldeversuchen die Quell IP für z.B. 15 Min zu sperren? Dieses Problem werde ich durch neuaufsetzen des Servers ja wohl nicht loswerden.

Danke & mfg k

Durch die dritte Option (tmpfs) in der fstab wird /tmp in den RAM verlegt und zudem mit erweiterten sicheheitsrelevanten Mountsoptionen (nodev,noexec,nosuid) gemountet. Das erste tmpfs ist lediglich ein Bezeichner, welcher die Identifikation der "Partition" vereinfacht (siehe Manpage).

@Joe User: tmpfs ist eine gute Idee, aber einen Ã?berlauf kann man damit doch damit nicht verhindern, da sehe ich bei solchen Usern dann auch die Gefahr eines DOS - oder nicht?

flo.

Hallo,

danke! Ich nehm aber mal stark an dass ich dann das vorhandene tmp Verzeichnis löschen muss?

mfg k

edit: Habt ihr noch eine Hilfe bezüglich der Bruteforce Attacke? Ich bin halt grad am IP Range in der FW sperren und am Absue Mails an die Provider schicken. :(

agent_k wrote:Ich nehm aber mal stark an dass ich dann das vorhandene tmp Verzeichnis löschen muss?

Nein. Dir gehen beim Reboot lediglich die temporären(!) Daten in /tmp verloren. Ausserdem kannst Du mit dieser Lösung /tmp gefahrlos im laufenden Betrieb (un)mounten. Nützlich, wenn man unliebsame Gäste in /tmp hat und diese schnell loswerden muss. Desweiteren lässt sich auch noch die Grösse des tmpfs festlegen, wodurch man das Volllaufen des RAM verhindern kann...

flo wrote:@Joe User: tmpfs ist eine gute Idee, aber einen Ã?berlauf kann man damit doch damit nicht verhindern, da sehe ich bei solchen Usern dann auch die Gefahr eines DOS - oder nicht?

Definiere "Ã?berlauf" / Siehe oben :roll:

Hallo,

ok - ich habe ein mysql Socket im tmp liegen (ja schlagt mich), imho kotzt sich das ganze werk an, wenn nach einem reboot das socket weg ist. was kann ich dagegen tun? Wie kann ich die Größe festlegen? Tut mir leid wenn ich nicht selber ins man schaue aber ich kann grade wirklich nicht.

Danke
mfg k

Grösse = 32MB:
Mounten:
Der Socket sollte beim Reboot/MySQL-Restart automatisch angelegt werden.

Ok, danke.

wenn
nun in der fstab steht, wirds doch eh beim nächsten reboot automatisch gemountet oder täusch ich mich da?

mfg k

agent_k wrote:nun in der fstab steht, wirds doch eh beim nächsten reboot automatisch gemountet

Jupp.

dangeee ;) Soll nochmal jemand sagen dass man hier unfreundlich behandelt wird.

mfg k

hallo,

noch eine frage, ist zwar schon off-topic, aber soll ich dafür einen neuen thread aufmachen?

ich könnte doch theoretisch zumindest die cpu last welcher der proftpd erzeugt senken, indem ich für netfilter die packet flow rate für port 21 begrenze, oder? was wäre denn da ein sinnvoller wert? bin grad schon am googeln aber vielleicht kann mir hier jemand gleich detailliertere infos oder links posten.

mfg k

Joe User wrote:Grösse = 32MB:

Code: Select all

tmpfs   /tmp   tmpfs   nodev,noexec,nosuid,size=32M   0 0

Mounten:

Code: Select all

mount tmpfs

Der Socket sollte beim Reboot/MySQL-Restart automatisch angelegt werden.

hmm, ich stell mir gerade die Frage, in wieweit sowas sinnvoll ist und welche Probleme die Lösung hat. Könnte es vorkommen, dass es mangels Speicher (32mb sind zwar wenig, aber bei z.B. 512mb Ram doch wieder relativ viel) bei einigen Diensten zu Problemen kommt im Hosting-Betrieb? Hat da schon jemand von euch Erfahrungswerte sammeln können?

Gruss,
Jens

@agent_k
Wenn du mal sagst was du dir unter Packet Flow vorstellst könnten wir dir vielleicht helfen :D Bisher kenn ich nur die Theoretischen Ansätze, aber nix wirklich brauchbares aus er Praxis.

@jeti-power
Ach, 32 Mega sollten schon langen, ich hab selten mehr als 5 im tmp liegen :D ausserdem haben die Leute eh meist Ihr phptmp und dann kann mir das egal sein. Ausserdem, wer sagt das man nicht einfach ein Container mit dd erstellen kann und dann eine Datei auf /var hat die dann das tmp enthält und dann muss man das nur erweitern :) Aber 32 MB reichen eigentlich aus.