| View previous topic :: View next topic |
| Author |
Message |
benjamin200
Veteran
Joined: 01 Feb 2004
Posts: 1426
Location: DE Munich
|
 Posted: Sun Jan 23, 2005 4:12 pm Post subject: [OT] Erfahrungen mit Rootkits |
 |
|
Hallo Leute,
mich würden eure Erfahrungen mit Rootkit interessieren.
Habt ihr negative Erfahrungen machen müssen?
Wie Sichert Ihr eure Server ab?
Für alle die nicht wissen was ein rootkit ist:
http://www.linux-magazin.de/Artikel/ausgabe/2002/03/rootkit/rootkit.html
Thx,
Benjamin
_________________
Gentoo Linux Stage1 / Kernel 2.6.18
AMD Athlon64 3500+ on Asus A8N-E / 1024 MB DDR-RAM / ATI X700 PCIe
Take LINUX and forget Blue Screens |
|
| Back to top |
|
 |
schmutzfinger
Veteran
Joined: 26 Oct 2003
Posts: 1287
Location: Dresden/Germany
|
| Posted: Sun Jan 23, 2005 7:18 pm Post subject: |
|
|
Ein kumpel von mir hatte mal ein rootkit auf seinem web-/ssh-/ftpserver. Was es für eins war und wie er es sich eingefangen hat weiss ich allerdings nicht.
Wenn du deinen Server sicher machen willst dann sind folgende sachen wichtig:
1. kein modul support im kernel
2. kein compiler -> kein gentoo ;(
3. firewall schön dicht machen
Bsp: 4 rechner in einem netz, alle sollen von aussen per ssh erreicht werden.
Da reicht es wenn einer seinen sshd nach aussen offen hat, alle anderen kann man dann indirekt erreichen.
4. dienste gewissenhaft konfigurieren
5. sicherheitsupdates regelmässig einspielen |
|
| Back to top |
|
|
mkr
Apprentice
Joined: 14 Dec 2003
Posts: 188
|
| Posted: Sun Jan 23, 2005 7:44 pm Post subject: |
|
|
| schmutzfinger wrote: | | Ein kumpel von mir hatte mal ein rootkit auf seinem web-/ssh-/ftpserver. Was es für eins war und wie er es sich eingefangen hat weiss ich allerdings nicht. |
Bei mir war mal eine Datei namens "r0nin" im /tmp-Verzeichnis auf dem Server. Der Angreifer konnte sie jedoch nicht ausführen.
| Quote: | Wenn du deinen Server sicher machen willst dann sind folgende sachen wichtig:
1. kein modul support im kernel |
ACK.
| Quote: | | 2. kein compiler -> kein gentoo ;( |
Ist das denn so wichtig? Wenn ein Angreifer Files uploaden kann, kann er sich doch auch seinen eigenen Compiler uploaden, oder? Oder er verwendet gleich Binaries.
| Quote: | | 3. firewall schön dicht machen |
ACK. Wobei man für einen einzelnen Rechner IMHO nicht unbedingt eine Firewall braucht. Aber nur, wenn der Server alleine am Internet hängt und nicht zusätzlich noch ein LAN bedient. (Also wenn nur die Dienste laufen, die man auch anbieten will.)
| Quote: | Bsp: 4 rechner in einem netz, alle sollen von aussen per ssh erreicht werden.
Da reicht es wenn einer seinen sshd nach aussen offen hat, alle anderen kann man dann indirekt erreichen. |
ACK. Zudem sollte man auch "unsichere" Protokolle wie X-forwarding und VNC durch SSH tunneln. Den SSHd kann man auf Pubkey-only umstellen, so schliesst man Passwortrater aus. Mir persönlich genügt Password-Auth, natürlich mit einem gut gewählten Passwort.
| Quote: | | 4. dienste gewissenhaft konfigurieren |
Sehr wichtig! Potentiell unsichere Dienste kann man auch in einer Chroot-Umgebung laufen lassen. Wobei man aus der auch ausbrechen kann...
| Quote: | | 5. sicherheitsupdates regelmässig einspielen |
Full ACK. Gerade bei Standard-Diensten wie SSHd und Apache sehr, sehr wichtig. Es gibt viele Angriffe, bei denen alte Lücken auszunutzen versucht werden. |
|
| Back to top |
|
|
ruth
Retired Dev
Joined: 07 Sep 2003
Posts: 640
Location: M / AN / BY / GER
|
| Posted: Sun Jan 23, 2005 7:49 pm Post subject: |
|
|
| schmutzfinger wrote: | Ein kumpel von mir hatte mal ein rootkit auf seinem web-/ssh-/ftpserver. Was es für eins war und wie er es sich eingefangen hat weiss ich allerdings nicht.
Wenn du deinen Server sicher machen willst dann sind folgende sachen wichtig:
1. kein modul support im kernel
|
nützt leider heutzutage nichts mehr.
| Quote: |
2. kein compiler -> kein gentoo ;(
|
nützt dir auch nichts...
| Quote: |
3. firewall schön dicht machen
|
auf einem root-Server ist eine Firewall sinnbefreit. Warum? - Siehe Definition Firewall
siehe dazu auch:
http://faq.1und1.de/server/root_server/security/2.html
| 1und1 wrote: |
Der Begriff >> Firewall beschreibt ein Konzept, um eine Netzwerkinfrastruktur zu schützen, und den Datenverkehr in und aus einem Netzwerk zu regulieren.
Bei Systemen die direkt an das Internet angeschlossen sind, lässt sich aus diesem Grund keine Firewall im klassischen Sinn realisieren.
...
Den Zugriff über einen Paketfilter zu unterbinden, wäre die unsaubere Herangehensweise. Ein Dienst der nicht benötigt wird, sollte generell deaktiviert werden.
|
| Quote: |
Bsp: 4 rechner in einem netz, alle sollen von aussen per ssh erreicht werden.
Da reicht es wenn einer seinen sshd nach aussen offen hat, alle anderen kann man dann indirekt erreichen.
4. dienste gewissenhaft konfigurieren
|
korrekt
| Quote: |
5. sicherheitsupdates regelmässig einspielen
|
auch korrekt.
Was viel wichtiger heutzutage ist, ist folgender Befehl:
| Code: |
emerge unmerge mod_php
|
sehr provokativ, ich weiss.
Dennoch ist das PHP Subsystem heutzutage die meistgenutzte Sicherheitslücke.
Sei es durch unsichere PHP Konfiguration oder die Installation z.B. eines *Nuke CMS...
der bevorzugte Weg für Hacker, ein System zu kompromittieren ist zur Zeit zu 80% der Weg über schrottig 'programmierte' PHP Scripten.
Sei es durch remote Code Inclusion, CSS(cross site scripting), oder SQL Injections.
Um Web Applikationen sicher zu bekommen, nützt leider auch eine Distribution nicht mehr viel.
Das ist Sache des PHP Programmierers, wohl eher also des Webdesigners.
Und diese Leute haben wohl i.a. zuwenig Plan, um Sicherheitslücken zu erkennen und selbige zu schliessen.
demzufolge:
suPHP, hardenedPHP mal anschauen, fopen_remote(oder so) ausschalten usw...
Der klassische Weg eines Hackers über Buffer Overflows in Daemonen wie Apache oder Postfix kann heutzutage nahezu, nicht vollständig(!!) ausgeschlossen werden.
Die weitaus grössere Gefahr im Augenblick sind wirklich schrottige Amateur PHP Scripten.
In diesem Sinne
ruth
p.s.
um Fehlinterpretationen vorzubeugen:
Es kann _natürlich_ sein, dass man z.b. nächste Woche einen riesigen remote Buffer Overflow in Apache entdeckt, der dann natürlich auch exploitet wird.
viel wahrscheinlicher ist es jedoch, dass ein Webserver eben z.B. durch unsauber programmierte PHP Systeme kompromittiert wird.
_________________
"The compiler has tried twice to abort and cannot do so; therefore, compilation will now terminate."
-- IBM PL/I (F) error manual |
|
| Back to top |
|
|
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Sun Jan 23, 2005 7:58 pm Post subject: |
|
|
| schmutzfinger wrote: | | 1. kein modul support im kernel |
Ein Server-Kernel braucht sowieso keine Module. Umgekehrt kann man auch bei einem monolithischen Kernel Funktionen/Zeiger umbiegen.
| Quote: | | 2. kein compiler -> kein gentoo ;( |
Oder nur noch root dessen benutzung erlauben.
| Quote: | | 3. firewall schön dicht machen |
Nein, "Firewall" deinstallieren und ein Buch über IP/TCP/UDP lesen. Allenfalls eine burst rate bestimmen. [edit]Ach so, auf einem Gateway hat ein Packetfilter (+ALG?) natürlich seinen Sinn![/edit]
| Quote: | | 4. dienste gewissenhaft konfigurieren |
Dieser Punkt ist bei Servern an erster, nicht an vierter Stelle. Und echte[tm] Firewalls/NAT-Boxes bieten keine Dienste an.
| Quote: | | 5. sicherheitsupdates regelmässig einspielen |
Punkt 2, nicht 5.
HTH!
/dev
[edit]@ruth: Na, sieht man sich mal wieder? 
Danke für den Link!
Gruß |
|
| Back to top |
|
|
ruth
Retired Dev
Joined: 07 Sep 2003
Posts: 640
Location: M / AN / BY / GER
|
| Posted: Sun Jan 23, 2005 8:01 pm Post subject: |
|
|
hey Deever,
irgendwann muss Ich doch mal in Zürich vorbeischauen, hehe
Ihr macht doch auch immer so lustige Usertreffen, gelle?
gruss
ruth
_________________
"The compiler has tried twice to abort and cannot do so; therefore, compilation will now terminate."
-- IBM PL/I (F) error manual |
|
| Back to top |
|
|
benjamin200
Veteran
Joined: 01 Feb 2004
Posts: 1426
Location: DE Munich
|
| Posted: Sun Jan 23, 2005 8:12 pm Post subject: |
|
|
Hallo zusammen,
freue mich das eine kleine Diskussion ins Rollen gekommen ist. Bis jetzt scheint das ja der einzige Thread im Deutschen-Bereich zu sein, der sich mit rootkits befässt.
Nebenbei --> Im Portage gibt es ein nettes Tool welches über 50 verschiedene Abarten von bekannten rootkits über Veränderung es Filessystem, Dienste usw. erkennt.
Bei Bedarf o. Interesse einfach ein...
| Code: | | # emerge chkrootkit |
...ausführen.
Beste Grüße aus München
Benjamin
_________________
Gentoo Linux Stage1 / Kernel 2.6.18
AMD Athlon64 3500+ on Asus A8N-E / 1024 MB DDR-RAM / ATI X700 PCIe
Take LINUX and forget Blue Screens |
|
| Back to top |
|
|
mkr
Apprentice
Joined: 14 Dec 2003
Posts: 188
|
| Posted: Sun Jan 23, 2005 8:31 pm Post subject: |
|
|
| benjamin200 wrote: | | Nebenbei --> Im Portage gibt es ein nettes Tool welches über 50 verschiedene Abarten von bekannten rootkits über Veränderung es Filessystem, Dienste usw. erkennt. |
Anmerkung: Vom (evtl.) befallenen System aus erkennt man Rootkits nur sehr unzuverlässig. Es gilt das gleiche wie bei Virenscannern: von einem sauberen System aus ausführen, zB. der LiveCD oder Knoppix. |
|
| Back to top |
|
|
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Sun Jan 23, 2005 8:32 pm Post subject: |
|
|
chkrootkit ist super!
[ot] | ruth wrote: | | irgendwann muss Ich doch mal in Zürich vorbeischauen, hehe |
Klar, jederzeit!
Tipp: Wenn du keine Berge, aber Meer siehst, hast du die Ausfahrt verpasst! 
| Quote: | | Ihr macht doch auch immer so lustige Usertreffen, gelle? |
Die hier im Board? Kam noch nicht zu stande, muss mich noch eintragen! Merci für die Erinnerung![/ot]
Gruß,
/dev |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Sun Jan 23, 2005 8:35 pm Post subject: |
|
|
| ruth wrote: | | schmutzfinger wrote: |
1. kein modul support im kernel
|
nützt leider heutzutage nichts mehr.
|
Inwiefern? Kann das umgangen werden oder ist es einfach nicht mehr notwendig kompromittierte Kernelmodule einzusetzen?
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
ruth
Retired Dev
Joined: 07 Sep 2003
Posts: 640
Location: M / AN / BY / GER
|
| Posted: Sun Jan 23, 2005 9:18 pm Post subject: |
|
|
Hallo,
ja, es kann umgangen werden.
Dennoch kann man etwas dagegen tun:
man sollte zumindest CAP_SYS_MODULE und CAP_SYS_RAWIO entfernen.
das kann man zum Beispiel so machen:
| Code: |
echo 0xFFFCFFFF > /proc/sys/kernel/cap-bound
|
alternativ zur Datei /etc/sysctl.conf folgendes hinzufügen:
| Code: |
kernel/cap-bound = 0xFFFCFFFF
|
hat leider auch Einschränkungen:
lsof geht nicht mehr.
X geht nicht mehr.
lilo geht auch nicht mehr.
Diese Einstellungen sind nur noch durch einen Reboot aufzuheben.
das Laden von Kernelmodulen ist ab hier absolut unmöglich.
ach ja:
http://people.redhat.com/mingo/exec-shield/
das hier ist auch sehr gut und empfehlenswert...
---> Whitepaper mal lesen, empfehlenswert.
auch danach funktioniert übrigens kein X mehr, hihi
auf einem Server braucht man eh keins, gell? *gg*
gruss
ruth
_________________
"The compiler has tried twice to abort and cannot do so; therefore, compilation will now terminate."
-- IBM PL/I (F) error manual |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Sun Jan 23, 2005 9:41 pm Post subject: |
|
|
Danke für die Erklärung.
| ruth wrote: |
auch danach funktioniert übrigens kein X mehr, hihi
auf einem Server braucht man eh keins, gell? *gg*
|
Und wie konfigurier ich dann die Firewall ????ßß???ß 
_________________
Dinosaur week! (Ok, this thread is so last week) |
|
| Back to top |
|
|
DarKRaveR
Guru
Joined: 11 Oct 2003
Posts: 500
Location: Old Europe/G-Many
|
| Posted: Mon Jan 24, 2005 2:38 am Post subject: |
|
|
| Deever wrote: | | schmutzfinger wrote: | | 1. kein modul support im kernel |
Ein Server-Kernel braucht sowieso keine Module. Umgekehrt kann man auch bei einem monolithischen Kernel Funktionen/Zeiger umbiegen.
HTH!
/dev
|
Einspruch, leider kommt man bei einem Server zu oft nicht drumherum, Beispiele:
Rechner mit mehren NEtzwerkkarten, sind die NEtzwerkkarten alle fest im kernel, fehlt gerne mal ein ethX, aus irgendeinem grund wird in der monolithischen form dem Treiber nicht mitgeteilt, welcher devicename er tragen soll - Mag bei 2.6.x wegen udev nicht mehr zwingend so sein, bei 2.4 wars leider ständig zu beobachten.
Parameter an Netzwerkkartentreiber können teilweise nur in der Modulform übergeben werden, zumindest bestimmte Parameter bei diversen Treibern. Versuch mal einem nonolithischen KErnel beizubringen tagged vlan pakete zu empfangen, die sind leider überlang udn weden weil das tag an der position der checksumem steht gerne komplett vernichtet.
Nur zwei Beispiele, die mir direkt einfallen .... |
|
| Back to top |
|
|
Sumpfdrache
Apprentice
Joined: 19 Jun 2004
Posts: 169
|
| Posted: Mon Jan 24, 2005 8:34 am Post subject: |
|
|
ruth schrieb hier vor Kurzem:
| Quote: |
| Code: |
emerge unmerge mod_php
|
sehr provokativ, ich weiss.
|
Ich befinde mich in der (un-)glücklichen Lage, demnächst genau das in Angriff (php-Seiten schreiben...) nehmen zu dürfen. Kannst Du mir evtl. eine Dir gefällige Doku zum Vermeiden von Kardinalfehlern in php nennen?
Disclaimer:
Ich kenne diesen Suchdienst mit den zwei o im Namen, ich dachte mir aber daß Du vielleicht direkt was Griffiges kennst... 
Kann mir vorstellen, daß man jede Eingabe konkret fett prüfen muß -soweit die Theorie- aber dann...???
Danke im Voraus, im Zweifel reicht mir natürlich auch ein Tritt in die richtige Galaxie... 
_________________
Die Erkenntnis war wie ein Betonblock, der in den Treibsand seines Bewußtseins sank. |
|
| Back to top |
|
|
Ragin
l33t
Joined: 14 Apr 2003
Posts: 776
|
| Posted: Mon Jan 24, 2005 9:44 am Post subject: |
|
|
Naja, also eine Firewall (oder besser einen Paketfilter) als unsinnig zu abzustempeln würde ich mal eher mit Abstand betrachten.
Sicher verwenden die meisten eine Firewall nur um Ports zu sperren (die durch nicht aktivierte Dienste eh abgeschaltet sind). Es gibt aber auch noch andere Einsatzgebiete von Paketfiltern wie iptables. Hier ist halt die Frage, ob man dann noch von einer Firewall sprechen kann.
Teilweise macht es z.Bsp. Sinn über diese Filter Beschränkungen in Bezug auf wiederholte Anfragen innerhalb eines bestimmten Zeitraumes auf bestimmten Ports, um z.Bsp. DoS Attacken zu verhindern.
Das Problem mit schlecht programmierten Webseiten (nicht nur PHP) ist aber zur Zeit wirklich beträchtlicher als früher.
| Sumpfdrache wrote: | ruth schrieb hier vor Kurzem:
Ich befinde mich in der (un-)glücklichen Lage, demnächst genau das in Angriff (php-Seiten schreiben...) nehmen zu dürfen. Kannst Du mir evtl. eine Dir gefällige Doku zum Vermeiden von Kardinalfehlern in php nennen? |
Was du beachten solltest ist z.Bsp. alle Scripte schon von Anfang an mit safe_mode=off zu programmieren (php.ini Einstellung). Des weiteren solltest du dir evtl. eine Art "getter/setter" Klasse bauen, die übergebene Variablen auf deren Gültigkeitsbereich prüft. Z.Bsp. sollte ein Wert, der eine Zahl sein sollte (und auch nur eine Zahl sein darf) nicht SELECT * FROM [...] o.ä. enthalten, damit bei SQL-Abfragen nicht dieser Teil mitverwendet wird. Denn genau darüber findet man schnell Daten die nicht unbedingt sichtar sein sollen.
Ab PHP5 gibt es diese Getter und Setter, allerdings weiss ich nicht genau, wie sicher diese sind. Ich kenne diese Dinge mehr aus der Java-Welt, wo ja bei jeder Variable auch eine exakte Typenzuweisung vorhanden ist und diese auch strickt befolgt wird. In PHP ist das alles leider noch etwas schwammig und dadurch leicht infiltrierbar, wenn man sich nicht selbst Gedanken dazu macht.
Viele Informationen findest du auch auf http://www.php.net
_________________
"Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird."
Clifford Stoll, amerik. Astrophysiker u. Computer- Pionier |
|
| Back to top |
|
|
phixom
Apprentice
Joined: 07 Jan 2003
Posts: 224
|
| Posted: Mon Jan 24, 2005 10:40 am Post subject: |
|
|
Ich würde ausserdem empfehlen Hardened-PHP einzusetzen. Des Weiteren sollte auf dem Server ein Hardened-System laufen mit richtig eingerichtenten SE-Linux und Grsecurity.
phixom |
|
| Back to top |
|
|
andreask
Apprentice
Joined: 09 Sep 2003
Posts: 282
Location: Aachen, Germany
|
| Posted: Mon Jan 24, 2005 11:25 am Post subject: |
|
|
Hallo!
| Sumpfdrache wrote: | ruth schrieb hier vor Kurzem:
| Quote: |
| Code: |
emerge unmerge mod_php
|
sehr provokativ, ich weiss.
|
Ich befinde mich in der (un-)glücklichen Lage, demnächst genau das in Angriff (php-Seiten schreiben...) nehmen zu dürfen. Kannst Du mir evtl. eine Dir gefällige Doku zum Vermeiden von Kardinalfehlern in php nennen? |
Mal ein paar Links :
http://www.php.net/manual/de/security.index.php
http://www.linux-magazin.de/Artikel/ausgabe/2004/10/php/php.html
http://shiflett.org/php-security.pdf
http://www.goldenbluellc.com/PHP_Security
http://www.zend.com/zend/art/art-oertli.php
http://talks.php.net/index.php/Security?
http://httpd.apache.org/docs-2.0/misc/security_tips.html
http://www.w3.org/Security/Faq/www-security-faq.html
Securing Apache: Step-by-Step: http://www.securityfocus.com/infocus/1694
Securing Apache 2: Step-by-Step: http://www.securityfocus.com/infocus/1786
Securing PHP: Step-by-Step: http://www.securityfocus.com/infocus/1706
Securing MySQL: Step-by-Step: http://www.securityfocus.com/infocus/1726
Als erstes ist es wichtig dass PHP/Apache möglichst sicher konfiguriert sind, so dass selbst wenn es irgendein Problem mit einem PHP-Script gib, so wenig Schaden wie möglich angerichtet wird. Ein PHP-Script sollte möglichst wenig dürfen. Vor allem so Sachen wie register_globals, allow_url_fopen... abschalten, aber siehe Links für Details.
Vor allem wenn verschiedene User auf dem Server arbeiten sollte man php-cgi + suPHP o.ä. verwenden. Ich verwende inzwischen lighttpd mit php-fastcgi, weil das auf der einen Seite sogar schneller ist als Apache mod_php, und auf der anderen Seite _erheblich_ einfacher zu konfigurieren als Apache + mod_fastcgi, und bietet eben die sicherheitstechnischen Vorteile von CGI.
Und wenn das vernünftig konfiguriert ist, eben das wichtigste KEINER einzigen Variable die der User beeinflussen kann zu vertrauen. Alles validieren und/oder escapen (mysql_real_escape_string, escapeshellarg...), nach Möglichkeit keine Variablen und wenn dann eben nur sehr genau geprüfte und escapte, an Funktionen die PHP-Code ausführen (include, eval...), shell-Kommandos ausführen (exec, system...) Datenbank-Kommandos ausführen (mysql_query...), etc... übergeben. Aber wie gesagt, dass kan man IMHO nicht mal eben aufzählen, ich kann nur empfehlen die Links oben zu lesen.
Grüße
Andreas
Last edited by andreask on Mon Jan 24, 2005 11:41 am; edited 2 times in total |
|
| Back to top |
|
|
Sumpfdrache
Apprentice
Joined: 19 Jun 2004
Posts: 169
|
| Posted: Mon Jan 24, 2005 11:29 am Post subject: |
|
|
Na, da hab ich doch mal Futter
Besten Dank!!
_________________
Die Erkenntnis war wie ein Betonblock, der in den Treibsand seines Bewußtseins sank. |
|
| Back to top |
|
|
andreask
Apprentice
Joined: 09 Sep 2003
Posts: 282
Location: Aachen, Germany
|
| Posted: Mon Jan 24, 2005 11:47 am Post subject: |
|
|
| Ach ja, anlässlich der vielen aktuellen Sicherheits-Probleme in PHP-Anwndungen hat das Entwicklerteam von PHP vor wenigen Wochen das folgende Statement abgegeben: http://www.php.net/security-note.php |
|
| Back to top |
|
|
Tobiking
Tux's lil' helper
Joined: 14 Dec 2004
Posts: 109
|
| Posted: Mon Jan 24, 2005 2:06 pm Post subject: |
|
|
Das mit PHP ist manchmal schrecklich. Habe mir vor kurzem ein Managment System für Clanseiten angeguckt. Es gab eine Datei in der die Mysql verbindung hergestellt wurde und die Rechte die man hat gesetzt wurden und danach wurde je nachdem wo man war der rest der Seite geladen.
Der Rest der Seite begann immer mit einem "if($acces=irgendwas)" und man konnte nu einfach direkt die Seite aufrufen und per get einach access auf den richtigen wert setzen und man war z.B. im Admin Panel. Mit etwas geschick konnte man dann auch die Seiten aufrufen mit denen dann Member erstellt/editiert/gelöscht werden konnten usw. Das Problem war nur das die User daten für mysql in der 1. datei standen und man nicht dran kam so leicht. Aber sobald jemand in der php.ini die standard mysql daten richtig einträgt oder sogar kein pw für localhost verlangt ist die Page übernommen . |
|
| Back to top |
|
|
mkr
Apprentice
Joined: 14 Dec 2003
Posts: 188
|
| Posted: Mon Jan 24, 2005 7:35 pm Post subject: |
|
|
Auch immer wieder schön bei schlecht programmierten Scripts:
Bei einem Login-Formular als User und Passwort einfach
eingeben. |
|
| Back to top |
|
|
sirro
Veteran
Joined: 20 Jul 2003
Posts: 1472
Location: aachen.nrw.de.eu
|
| Posted: Mon Jan 24, 2005 9:47 pm Post subject: |
|
|
| Ragin wrote: | | Z.Bsp. sollte ein Wert, der eine Zahl sein sollte (und auch nur eine Zahl sein darf) |
Wie waere es mit: Nach dem einlesen 0 auf den Wert addieren, danach sollte die Variable AFAIK immer einen Zahlwert haben.
Ansonsten noch ein Link: http://www.php-faq.de (Daher auch dieser Tipp ) Insbesondere:
1. Wie unterscheide ich böse Variablen von guten?
11. Prüfe importierte Parameter. Traue niemandem |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Mon Jan 24, 2005 11:23 pm Post subject: Ich und mein Desktop-Gentoo - und was ich falsch mache |
|
|
Hallo, ich würde gerne mal mich selbst auf "Home-Security" checken lassen (also Desktop für einen Anwender, nämlich mich), oder viel mehr mich und wie ich es mit meiner Sicherheit halte!?
System-Hardware:
Serielle und Parallel-Ports sind per Bios deaktiviert
USB 2.0 und AGP/PCI/S-ATA sind aktiviert
System-Software:
Gentoo 2004 (einmal wöchentlich wird mind. "geupdatet")
Vanilla-Kernel 2.6.x mit VESAFB-TNG+Gensplash
| Quote: |
USB-Support an, S-ATA-Support an, Serielle+Parallel aus, kein SE-Linux oder so etwas, laden von Moduellen möglich |
Außerdem wird das System durch einen 3Com-Router "geschützt", W-LAN ist aktiviert und wird nur mit WEP verschlüsselt *selber_paddel*
Trotzdem betrachte ich Softwarefirewalls und Virenscanner, als eine Krankheit von Windows - und nicht als Beitrag zur Sicherheit - eher als zusätzliche Sicherheitslücken
Mein User ist in der Gruppe "Wheel" und darf auch CD-ROM Laufwerke und drei NFTS-Partition mounten, CD-ROM nur Read-Only, aber das ausführen von Binarys ist erlaubt!
/var hat keine extra Partition - werde ich ändern
/tmp hat keine extra Partition - werde ich ändern
/home hat keine extra Partion - werde ich ändern (wegen Sicherheit, Daten sind schnuppe)
/opt und /boot liegen auf extra Partitionen
/tmp hat kein "noexec"
Folgende Fragen hätte ich schon mal:
Ich habe Metalog und einen Cron-Dämon, wie schützte ich mich gegen das "Platzen" der Logs (wenn ich keine extra /var-Partition habe), hat Metalog schon einen Schutz, muss ich mit dem Cron-Dämon was tun?
Würdet ihr auf einem Desktop "noexec" für /tmp setzen?
Danke
_________________
Just you and me strogg! |
|
| Back to top |
|
|
DarKRaveR
Guru
Joined: 11 Oct 2003
Posts: 500
Location: Old Europe/G-Many
|
| Posted: Mon Jan 24, 2005 11:32 pm Post subject: |
|
|
| mkr wrote: | Auch immer wieder schön bei schlecht programmierten Scripts:
Bei einem Login-Formular als User und Passwort einfach
eingeben. |
Humm, stimmt zwar prinzipiell, würde aus dem ' nicht automatisiert ein \' bei übermittelten Variablen - und wenn dem nicht so ist, selbiges grade selbst tun (einzeiler) ....
Zweitens funktioniert das nur, wenn du quotest (mußt Du erstmal wissen, bzw. testen) ....
Und wer zum henker sagt das der login okay ist, wenn die daten bank für login and passwort mindestens eine zeile ausspuckt ? Sowas nimmt ma nicht an ....
Naja, okay, lassen wir das philosophieren, selbst einige wenige wirklich einfache Dinge können verdammt viel verhindern . |
|
| Back to top |
|
|
andreask
Apprentice
Joined: 09 Sep 2003
Posts: 282
Location: Aachen, Germany
|
| Posted: Tue Jan 25, 2005 12:07 am Post subject: |
|
|
| DarKRaveR wrote: | | Humm, stimmt zwar prinzipiell, würde aus dem ' nicht automatisiert ein \' bei übermittelten Variablen - und wenn dem nicht so ist, selbiges grade selbst tun (einzeiler) ... |
Er sprach ja auch von "schlecht programmierten" Scripten
| DarKRaveR wrote: | | Zweitens funktioniert das nur, wenn du quotest (mußt Du erstmal wissen, bzw. testen) .... |
Wenn Du nicht quotest bist Du selber Schuld, denn dann hilft Dir auch kein mysql_real_escape_string() oder mysql_escape_string() mehr gegen sowas wie
Abgesehen davon ist Code der auf "mußt Du erstmal wissen, bzw. testen" beruht IMHO sehr gefährlich... ("security by obscurity")
| DarKRaveR wrote: | | Und wer zum henker sagt das der login okay ist, wenn die daten bank für login and passwort mindestens eine zeile ausspuckt ? Sowas nimmt ma nicht an .... |
es ist eben eine sehr effiziente Methode dies zu ermitteln, entsprechend häufig wird das verwendet. Mit entsprechenden quotes und escape... auch kein Problem.
| DarKRaveR wrote: | | Naja, okay, lassen wir das philosophieren, selbst einige wenige wirklich einfache Dinge können verdammt viel verhindern . |
Ja, aber das wissen leider zu viele Leute nicht, wenn doch wenigstens http://de3.php.net/security mal gelesen würde. Denn selbst wenn ein Server hervoragend konfiguriert und abgesichert wurde, in jedem Fall sind bei Sicherheitslücken in PHP-Scripten alle Scripte/"Web-Dateien" des Users gefährdet, der diese Scripte einsetzt. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
