Lösung gegen Shell-Dateien die hochgeladen werden

mulipo43

mulipo43

New Member
Hi.

Suche für SuSE 10.3 eine recht einfache und gute Abwehr-Lösung gegen Shell-Dateien (also gegen Sachen wie z.B. C99.php etc.). Es werden ab und zu solche Dateien hochgeladen mit denen man die Kontrolle über den Server erlangen kann ... Am besten wäre es wenn sowas sofort gelöscht/gesperrt wird. Sicher gibt's keine einfache Einheitslösung, aber falls jemand da etwas in dieser art für SuSE 10.3 hätte.... thx.
 
Solltest du nicht lieber die Ursache suchen wie die Dinger auf deinen Server kommen und diese verbieten bzw. zu machen?
 
Ne, die Shells laden Kollegen um mich zu schikanieren ab und zu hoch. Ist ein geschützter Bereich, kann nicht groß was passieren. Möchte es nur für die Zukunft eben verhindern...
 
Den Kollegen einfach Ihren Zugang sperren ... sowie exec(),shell_exec() usw. per php.ini verbieten, aber wenn Sie Shell Zugriff haben sollten kannste gegen solche Exploits nicht viel machen.
 
exec() ,shell_exec() hab ich bereits gesperrt. Also sie haben kein SSH-Zugriff, nur FTP aber da laden manche ab-und-zu eben "lustige" Scripte hoch ... kann man da echt gar nichts groß machen? Was machen den z.B. Webspace-Anbieter dagegen?

mulipo43
 
Alle Funktionen sperren die böswillige Sachen machen könnten, aber wenn die Benutzer sowas bewusst per FTP hochladen sperren die meisten einfach nur die Benutzer.
 
Aso, an dieser stelle würde mich auch mal interessieren wie Freehoster und co. das machen, l0l :o Ist es eigentlich möglich wenn man z.B. einen Upload-Dienst hat Dateien hochzuladen die z.B. die Endung böse-shell.php.gif haben die auszuführen? Endung ist ja eigentlich .gif, hoffentlich ist dies nicht so ...

mulipo43
 
Bilderhoster kontrollieren mit mime oder indem sie das Bild mit gd aufmachen einfach ob es ein Bild ist :D

So einfach ist es - PHP-Dateien psucken da nämlich nur Fehlermeldungen aus.

Freehoster haben einfach alles gesperrt was ein Sicherheitsloch sein könnte - somit kann der Kunde zwar auf funpic eine c99 hochladen. Aber anfangen kann er dafür noch lange nix damit :D
 
Ach so gut zu wissen ;) Falls jemand noch mehr Infos und/oder eine Idee zur Absicherung hat nur her damit... :D
 
Brauchen die Kollegen überhaupt php? Wenn nein ist es vermutlich am einfachsten das für die entsprechenden Verzeichnisse/vHosts abzuschalten.

php_flag engine off
PHP: Wie man Konfigurationseinstellungen ändert - Manual
Und damit sie es nicht per .htaccess wieder einschalten:
AllowOverride
indem sie das Bild mit gd aufmachen einfach ob es ein Bild ist
Click to expand...
Auch ein Bild kann PHP Code enthalten. Am einfachsten schreibt man den Code direkt in den JPEG Komentar, dann muss man sich nicht mit Prüfsummen rumärgern ;)
 
Code: 
Am einfachsten schreibt man den Code direkt in den JPEG Komentar, dann muss man sich nicht mit Prüfsummen rumärgern
Der wird aber nicht ausgeführt solange man nicht den EXIF extrahiert, sondern jediglich mit imagecreatefromjpeg() und imagecreatejpeg() die Bilder einliest/anzeigt. (Zumindest hab ich die ML's so aufgefasst :D )
 
Das größte Problem bei dir dürfte sein dass deine Kollegen FTP Zugriff haben und somit die Dateien eh an jeglichen Checks vorbei erstmal auf den Server hochbekommen.
Da kannst du quasi nur die Funktionen verbieten die in den Dateien zu schädlichen Sachen führen können. Wie eben exec(), url_fopen() und so Scherze. Eventuell würde dir auch mod_security weiterhelfen und/oder der suhosin Patch für php.
 
d4f said:
Der wird aber nicht ausgeführt solange man nicht den EXIF extrahiert, sondern jediglich mit imagecreatefromjpeg() und imagecreatejpeg() die Bilder einliest/anzeigt.
Click to expand...
Es war nur von einem 'aufmachen' Test die Rede, danach wäre böse-shell.php.jpg auf der Festplatte und würde ggf. von PHP ausgeführt werden. Ein (verlustbehaftetes, rechen- und arbeitsspeicherintensives) Rekomprimieren würde die Sache erschwert. Aber jeder der ein imagejpeg(imagecreatefromjpeg("...")) in seinen Code schreibt hat ernstere Probleme als eine PHP Shell...
(Zumindest hab ich die ML's so aufgefasst :D )
Click to expand...
ML? Manual?
CentY said:
Eventuell würde dir auch mod_security weiterhelfen und/oder der suhosin Patch für php.
Click to expand...
Was genau bringt bei einem Angriff von Innen mod_security? Und wenn Kollegen aktiv Sicherheitslücken von PHP ausnutzen vor denen suhosin schützen könnte(bufferoverflows or format string vulnerabilities) geht das deutlich über schikanieren hinaus.
 
Last edited by a moderator:
Naja mod_security bringt in sofern was als dass sie ihre Scripte teilweise nicht mehr aufrufen können da hier bestimmte Argumente mitgegeben werden die geblockt werden.

Aber wie gesagt solchen Kollegen die überhaupt auf solch lustige Ideen kommen würde ich einfach PHP ganz deaktivieren oder vom Server verbannen fertig.
 
ML? Manual?
Click to expand...
Mailingliste :D
Als ich mich mal darüber schlau machen wollte war nur eine PHP-Mailingliste aufzutreiben wo darüber diskutiert worden war :D


jeder der ein imagejpeg(imagecreatefromjpeg("...")) in seinen Code schreibt
Click to expand...
Je nach EInsatzzweck macht man ja eh oft Resample-Optionen um die Größe aller hochgeladenen Bilder zu vereinheitlichen. Also fällt die Operation ja eh an :D

wenn Kollegen aktiv Sicherheitslücken von PHP ausnutzen vor denen suhosin schützen
Click to expand...
Egal was dann der Chef, die Kollegen oder die Admins sagen: wenn jemand den Server richtig exploitet einfach den FTP-Hahn zudrehen und demjenigen eine kleben :D
(Das zweitere nicht direkt anwenden bitte: Gewalt ist keine Lösung :D )
 
"Wer solche Freunde hat braucht keine Feinde."

CentY said:
Eventuell würde dir auch mod_security weiterhelfen und/oder der suhosin Patch für php.
Click to expand...
suhosin Patch ist installiert :)

HornOx said:
Und wenn Kollegen aktiv Sicherheitslücken von PHP ausnutzen vor denen suhosin schützen könnte(bufferoverflows or format string vulnerabilities) geht das deutlich über schikanieren hinaus.
Click to expand...

CentY said:
Aber wie gesagt solchen Kollegen die überhaupt auf solch lustige Ideen kommen würde ich einfach PHP ganz deaktivieren oder vom Server verbannen fertig.
Click to expand...
Tja, wer solche Freunde hat braucht keine Feinde :D Ist nur ein DynDNS Server, daher mir egal was sie machen ist ja pure Zeitverschwendung und ist sowieso nur wenige Stunden am Tag online, von daher denk ich mir "lass die Kinder spielen" ...

Mich würde wie gesagt für die Zukunft interessieren wie man sowas optimal blockt, wenn man z.B. echten Webspace auf seinem Server Freunden und dritten zur Verfügung stellt soll ja nichts passieren ... Also wenn jemand noch Ressourcen hat ;)

multi
 
You must log in or register to reply here.
Back
Top