gcc & wget?

[webigor]

hallo zusammen,

mir geister da so ein kleiner Gedanke im Hinterkopf umher.. Wie sinnvoll ist es, die beiden Programme wget und gcc (deren Gefährlichkeit ja durchaus bekannt sein dürften) durch ein Script zu ersetzten, dass mir eine Email schickt und vielleicht noch ein paar Standartausgaben auf den Bildschirm packt...

Jetzt sagt mir aber bitte nicht, dass die Programme grundsätzlich nichts auf einem Webserver verlohren haben... ich brauch sie leider zu oft, um sie unterhauen zu können.....

Als nächstes werden ihr vielleich sagen, dass sowas doch ganz einfach auffällt, sobald man sich die dateien anguckt... aber im ernst: Wer tut das? als erstes wird doch einfach ausprobiert, oder nicht? und danach ist zu spät, dann weiß ich bescheid, vorausgesetzt ich schlafe nicht...

Habe ich irgendwelche wichtigen Ã?berlegungen vergessen?

Dies soll kein 100%er Schutz sein.. aber da ich meinen Server so sicher gemacht habe, ich es meines Wissens nach mit vertretbarem Aufwand geht würd ich das gerne noch als I-Tüpfelchen draufsetzten :-)

Bitte um eine Bewertung des ganzen :-)

gruß

Igor :-)

[outofbound]

Wieso installierst du die Teile? Lass Sie doch Lokal in /root liegen, dann kommt auch keiner dran. ;)

*grins*

Out

[webigor]

Dann ist aber noch lange nicht gesagt, dass ich mitkriege wenn jemand da ist... Ich meine, dass ist grundsätzlich eine gute Idee, aber deine Idee und meine lassen sich ja durchaus kombinieren :-)

Gruß

Igor :-)

[oxygen]

ich würde die entsprechenden Binarys nach /root/bin verschieben und /root/bin in deinen PATH aufnehmen, danach an die alte Stelle ein entsprechendes Script kopieren. So kannst du weiterhin ohne Probleme beide Programme verwenden, aber normale User bekommen nur das Script zu sehen.

[crasline]

und wenn man die entsprechenden Binarys da lässt wo sie sind, einfach root als owner macht und dir richtigen rechte setzt? Habs zwar nicht ausprobiert, aber müsste doch den gleichen effekt haben ..

[webigor]

Schon... aber wo pack ich dann meine Scripte hin? also ich halte das Verschieben nach /root und das ersetzten durch Scripte für schöner

[crasline]

also ich find Rechte entziehen viel schöner *g*

dann kommt eben einfach ein Permission denied ..

[webigor]

und ich erfahre nichts davon... wenn jemand soweit ist, dass er diese meldung krigt, habe ich ein RIIEESEN Sicherheitsloch! Denn ausser mir hat niemand einen Shellzugang..

Und wenn irgendjemand soweit ist, würde ich es gerne erfahren, und ich halte das für eine Methode, die relativ sicher ist.. den ich denke, diese beiden Befehle sind der erste Anlaufpunkt eines jeden, der gerade in ein fremdes System eingedrungen ist...

Gruß

Igor :-)

[captaincrunch]

den ich denke, diese beiden Befehle sind der erste Anlaufpunkt eines jeden, der gerade in ein fremdes System eingedrungen ist...

Da würde ich mal strikt das Gegenteil behaupten. Die meisten Scriptkiddies laden sich einfach fertige Exploits hoch, und nutzen diese.

Hilfreich wäre so etwas aber natürlich in dem Fall, in dem das Kiddie sich seinen BNC kompilieren möchte. ;)

[webigor]

Hochladen? Wie??

Abgesehen davon, dass ich bezweifel, dass ein "ernsthafter" Hacker sich an "meinem" System zu schaffen macht..

Aber ich fänds nett, wenn Du mir deine Meinung erklähren könntest, da ihc da gerade nich so ganz hinterher komme... Wie läd man etwas auf einen Server hoch? (davon ausgegangen dass der FTP-Server dicht ist)

Denkst du an scp? Da ich das nicht nutze hab ich da auch noch garnicht dran gedacht.. Mal schauen ob ich das irgendwie unterbunden kriege....

Gruß

Igor :-)

[webigor]

Ã?hm.. Zur grundsätzlichen Erklährung:

In meinem GedankenSzenario ist der Eindringling über irgendwelche fehlerhaften PHP-Scripte eingedrungen, hat also keine Passwörter für Useraccounts

Gruß

Igor :-)

[captaincrunch]

Kleines Beispiel: ein fehlerhaftes Script (PHP), das vom Webserver ausgeliefert wird, könnte es einem Angreifer ermöglichen, Daten ins /tmp zu laden, und u.U. sogar automatisiert auszuführen. Solche Dinge habe ich jetzt mittlerweile zigfach gesehen.

[webigor]

hmmmmmmmmmmm........ Du hast recht....

Deshalb hab ich hier nachgefragt, um solche Antworten zu kriegen... *danke*

Du redenst von Aufrufen wie "xy.de/test.php?data=blablablabla"
welche dann durch ein selten dämliches Script auf die Platte gepackt werden?
Das würde definitiv nicht auffallen, da hast Du recht...

Da muss ich auch in Ruhe nochmal drüber nachdenken....

Danke fürs drauf aufmerksam machen!

Gruß

Igor :-)

[gangsta]

Hi

es gibt noch mindestens 2 weitere Methoden, um Dateien auf einen Server zu kriegen, wenn man nur wwwroot ist:

- Der FTP-Client (Befehl ftp)
- per echo , indem man damit eine html-datei erstellt im wwwroot-Verzeichnis (irgendeinen Ordner gibts da meistens, wo jedermann Schreibrechte hat). In der html-Datei steht dann drin: <input type=file>
und schon kann man mit ein wenig Aufwand eine datei hochladen.
- kann man mit lynx auch Dateien runtersaugen?? *denkz*

Aber ich gebe dir Recht, dass die meisten Script-Kiddies (und von nichts "höherem" gehen wir mal aus) zu allererst wget oder ftp probieren. und da ist eine automatische Benachrichtigung per Mail UND der automatische logout garnicht mal so unwirksam !!
Da du nur von Sicherheitslücken im php ausgehst, wäre ein direktes stoppen des apache auch zu überlegen, damit sich das kiddie nicht direkt wieder reinhackt und dann irgendwas anderes macht.......
Kleine Hürde: apache kann nur root stoppen....


Aber ansonsten sehr interessante Idee mit dem wget und gcc ersetzen... ich habe bisher auch nur die rechte für others weggenommen.. werd jetzt auch mal die script-sache implementieren. Danke für die Idee!
[/list]

[webigor]

Danke auch für die ganzen Denkanstöße, die Du eingebracht hast...

Ist auch alles sehr interessant.. da ich den ftp-Client auch nicht verwende, sollte es auch kein Problem sein, diesen durch ein Script zu ersetzten..

Nun.. das Runterfahren des Apaches ist in der Tat nicht ganz leicht. Aber man könnte die gesammten auszuliefernden Dokumente wegräumen.. das sollte sich Rechtemäsig einfädeln lassen und hat ca. den selben Effekt...

Gruß.. Igor :-)

[webigor]

noch eine Idee zum Thema <input type="file">

sowas erzeugt doch einen HTTP-Put-Request, oder? Da ich keine Seite habe, die sowas erwartet kann man den doch in den ApacheConfigs einfach disablen (hab da mal sowas gesehen)

Ein Weg weniger :-)

Gruß

Igor :-)

[Joe User]

Code: Select all

#!/bin/bash

if [ $# = 0 ]; then
  echo "Usage: http-get <URL>" >&2
  exit 1
fi
URL=${1##http://} &&
SERVER=${URL%%/*} &&
FULLFILENAME=${URL#$SERVER} &&
FILENAME=${FULLFILENAME##*/}
echo -n "Fetching $SERVER$FULLFILENAME... "
(echo -e "GET $FULLFILENAME HTTP/0.9rnrn" 1>&3 &
cat 0<&3) 3<> /dev/tcp/$SERVER/80 | (
  read i
  while [ x"$(echo $i | tr -d 'r')" != "x" ]
  do
    read i
  done
  cat
) >$FILENAME 
echo "done."

Soviel zum Thema wget ;)

[webigor]

Joa.. das ist ein wirklich schönes Script... aber dass muss man auch erstmal haben... ich denke, bevor man ein solches Script verwendet wird man erstmal eine menge anderer Möglichkeiten probiert haben... und eine davon sollte mir vorher eine Email geschickt haben :-) und dann kann ich ja was dagegen tun :-)

Aber wirklich ein schönes Script.. ich weiß nich warum, aber es gefällt mir.. warscheinlich wegen der ungeheuren Simpelheit :-)

Gruß

Igor

[nn4l]

Vielleicht kommt eine chroot Umgebung für den Apache in Frage? Da gibt es halt dann nur die Binaries, die du brauchst. Z.B. so ein email-send gcc script.

Bei mir z.B. ist das nur der Apache selbst und Perl. Keine shell, kein gcc, wget, lynx (mit lynx kann man auch files downloaden) usw.

[webigor]

Hmm.. das ist auch eine interessante Ã?berlegung.. Mit ChRoot habe ich absolut keine Erfahrung, dahier hier einige kleine Fragen:

:arrow: Ein ChRoot ist ein Verzeichniss, in das ein User (?) Eingesperrt ist?
:arrow: Es wird also ein künstlicher / erzeugt?
:arrow: Zugriffe (rw) sind nur innerhalb dieses Verzeichnisses möglihc, jedoch nicht höher?
:arrow: Andere User können auf dieses Verzeichniss frei zugreifen?
:arrow: In diesem Verzeichniss müssten liegen:
- die Binarys
- www-Dokumente
- LogVerzeichnisse
- Irgendetwas, dass es dem Apache ermöglicht mails zu verschicken
- Irgendetwas, dass es dem Apache ermöglicht, auf MySql zuzugreifen
- Irgendetwas, dass es dem Apache ermöglicht, PHPs zu parsen. (Diese PHPs sind dann auch alle in diesem Verzeichniss eingesperrt?)

Sorry, aber ich hab da echt keine Ahnung

In Hoffnug auf Vielsagende Antworten :roll:

Gruß

igor :-)

[dea]

Hmm.. das ist auch eine interessante Ã?berlegung.. Mit ChRoot habe ich absolut keine Erfahrung, dahier hier einige kleine Fragen:

:arrow: Ein ChRoot ist ein Verzeichniss, in das ein User (?) Eingesperrt ist?

Nein, das wäre ein Jail. Ein chroot ist lediglich eine "OS-Installation in einem OS"

:arrow: Es wird also ein künstlicher / erzeugt?

Nein, der ist ziemlich real, liegt üblicherweise (in DevEnv's) in Deinem $HOME

:arrow: Zugriffe (rw) sind nur innerhalb dieses Verzeichnisses möglihc, jedoch nicht höher?

Nicht zwangsläufig, denn sobald Du diese Umgebung verlässt, is alles wieder beim alten (s.u.)

:arrow: Andere User können auf dieses Verzeichniss frei zugreifen?

Wenn Du ihnen die Rechte dafür zugestehst (s.o.)

:arrow: In diesem Verzeichniss müssten liegen:
- die Binarys
- www-Dokumente
- LogVerzeichnisse
- Irgendetwas, dass es dem Apache ermöglicht mails zu verschicken
- Irgendetwas, dass es dem Apache ermöglicht, auf MySql zuzugreifen
- Irgendetwas, dass es dem Apache ermöglicht, PHPs zu parsen. (Diese PHPs sind dann auch alle in diesem Verzeichniss eingesperrt?)

So ungefähr (s.u.)

Sorry, aber ich hab da echt keine Ahnung

In Hoffnug auf Vielsagende Antworten :roll:

Gruß

igor :-)

Code: Select all

man -a chroot[/quote]

Vll. kennt einer noch weiterführende Literatur im Web?

[captaincrunch]

An dieser Stelle sag ich's gerne noch einmal: ein chroot kein wirklicher Schutz mehr, wenigstens dann nicht, wenn's um den guten alten chroot()-Systemcall geht (schau dir mal die manpage des Calls in der Sektion 2 an). Selbst viele Scriptkiddies haben mittlerweile das "Breaking out of a chroot-jail" gelesen.

"Sicherer" wird das ganze durch (z.B.) GRSecurity, neben vielen anderen "Nettigkeiten" bietet aber auch RSBAC etwas ähnliches (Jail, nicht zu verwechseln mit dem BSD-Zeugs). Unter Umständen solltest du dir diee beiden Sachen mal näher anschauen, da sie die Sicherheit z.T. enorm erhöhen können (richtige Handhabe natprlich vorausgesetzt ;) ).

Btw.: Wie passend. Just in dieser Sekunde kam eine Advisory vom FreeeBSE-Team per Mail rein, dass Jailed Prozesse Zugriff auf andere solche erhalten können. So viel also dazu. ;)

[nn4l]

Eine chroot-Umgebung für den Apache ist nicht das Allheilmittel, ich sehe andererseits auch keine Nachteile gegenüber einer identischen Apache Konfiguration ohne chroot.

Ich hab diese Anleitung benutzt:

http://penguin.epfl.ch/chroot.html

Meine Apache chroot Umgebung besteht aus Apache mit mod_php und suexec, Perl und ssmtp, alles aus den Sourcen kompiliert. Es gibt keine sonstigen executables und keine devices.

Das Versenden von mail erfolgt mit ssmtp, das ist ein minimaler sendmail Ersatz (forwarded alles zum echten mail Server, der ausserhalb des chroot läuft). MySQL Zugriffe gehen übers Netz (--host=127.0.0.1) zum MySQL Server, der sich in einer anderen chroot Umgebung befindet.

[captaincrunch]

Eine chroot-Umgebung für den Apache ist nicht das Allheilmittel, ich sehe andererseits auch keine Nachteile gegenüber einer identischen Apache Konfiguration ohne chroot.

Wo habe ich etwas von Nachteilen gesagt? Sofern du dich durch dein chroot sicher fühlst: Bitteschön. Sofern dir diese trügerische Sicherheit reicht, ist doch nichts dagegen einzuwenden. ;)

[gangsta]

kann es sein, dass zur liste der "gefährlichen" progs auch noch w3m gehört? oder hängt da der wget hinter?

ich bin übrigens grade dabei, mir ein vernünftiges "Ersatzscript" zu bauen, was ich anstelle der ganzen "gefährlichen" progs einsetze.. Habt ihr da auch schon was fertig? dann könnte man das beste zusammenfügen

Mir ist noch ein problem eingefallen: Ich hab zufällig gelesen, dass mehrere Progs den wget nutzen (u.a. auch yast und fou4s). Funktionieren die evtl nicht mehr, wenn ich wget "verschiebe" und das originalfile ersetze durch mein kleines script?