# [OT] Erfahrungen mit Rootkits

## benjamin200

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

----------

## schmutzfinger

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

----------

## mkr

 *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.

----------

## ruth

 *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.
> ...

 

 *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.
> ...

 

korrekt

 *Quote:*   

> 
> 
> 5. sicherheitsupdates regelmässig einspielen
> 
> 

 

auch korrekt.

Was viel wichtiger heutzutage ist, ist folgender Befehl:

```

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.

----------

## Deever

 *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?  :Wink: 

Danke für den Link!

Gruß

----------

## ruth

hey Deever,

irgendwann muss Ich doch mal in Zürich vorbeischauen, hehe  :Wink: 

Ihr macht doch auch immer so lustige Usertreffen, gelle?

gruss

ruth

----------

## benjamin200

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...

```
# emerge chkrootkit
```

...ausführen.

Beste Grüße aus München

Benjamin

----------

## mkr

 *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.

----------

## Deever

chkrootkit ist super!

[ot] *ruth wrote:*   

> irgendwann muss Ich doch mal in Zürich vorbeischauen, hehe 

 Klar, jederzeit!  :Wink: 

Tipp: Wenn du keine Berge, aber Meer siehst, hast du die Ausfahrt verpasst!  :Very Happy: 

 *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

----------

## amne

 *ruth wrote:*   

>  *schmutzfinger wrote:*   
> 
> 1. kein modul support im kernel
> 
>  
> ...

 

Inwiefern? Kann das umgangen werden oder ist es einfach nicht mehr notwendig kompromittierte Kernelmodule einzusetzen?

----------

## ruth

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:

```

echo 0xFFFCFFFF > /proc/sys/kernel/cap-bound

```

alternativ zur Datei /etc/sysctl.conf folgendes hinzufügen:

```

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...  :Wink: 

---> Whitepaper mal lesen, empfehlenswert.

auch danach funktioniert übrigens kein X mehr, hihi  :Wink: 

auf einem Server braucht man eh keins, gell? *gg*

gruss

ruth

----------

## amne

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 ????ßß???ß  :Mr. Green: 

----------

## DarKRaveR

 *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 ....

----------

## Sumpfdrache

ruth schrieb hier vor Kurzem:

 *Quote:*   

> 
> 
> ```
> 
> emerge unmerge mod_php
> ...

 

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...  :Laughing: 

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...  :Embarassed: 

----------

## Ragin

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

----------

## phixom

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

----------

## andreask

Hallo!

 *Sumpfdrache wrote:*   

> ruth schrieb hier vor Kurzem:
> 
>  *Quote:*   
> 
> ```
> ...

 

Mal ein paar Links  :Wink: :

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

AndreasLast edited by andreask on Mon Jan 24, 2005 11:41 am; edited 2 times in total

----------

## Sumpfdrache

Na, da hab ich doch mal Futter  :Very Happy: 

Besten Dank!!

----------

## andreask

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

----------

## Tobiking

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   :Very Happy:  .

----------

## mkr

Auch immer wieder schön bei schlecht programmierten Scripts:

Bei einem Login-Formular als User und Passwort einfach

```
' OR '1'='1
```

eingeben.   :Very Happy: 

----------

## sirro

 *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  :Wink: ) Insbesondere:

1. Wie unterscheide ich böse Variablen von guten? 

11. Prüfe importierte Parameter. Traue niemandem

----------

## hoschi

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

----------

## DarKRaveR

 *mkr wrote:*   

> Auch immer wieder schön bei schlecht programmierten Scripts:
> 
> Bei einem Login-Formular als User und Passwort einfach
> 
> ```
> ...

 

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   :Very Happy:  .

----------

## andreask

 *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  :Wink: 

 *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

```
 OR 1=1
```

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.

----------

## DarKRaveR

 *andreask wrote:*   

>  *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 
> 
> 

 

Ja, aber wenn man es generell einschaltet, daß escaped wird, kann man es beim coden nicht vergessen   :Wink:  - so war das eher gemeint ...

 *Quote:*   

> 
> 
>  *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
> ...

 

Sofern ich strings die zahlen enthalten zu selbigen konvertiere ist ein escapen nicht mehr nötig, genauso wie übergeben strings, die zum beispiel 'gehashed' werden oder ähnliches, da kann man schwerlich noch injecten ...

Ja, das mit der Obscurity war unklar gesagt, meinte eher, wenn du z.B. kein error reporting hast und durch testen jedes teilstück des query strings in ne fehlermeldung bekommen kannst, wird es z.B. auch weitaus schwerer, sprich, generell fehler selbst abfangen und eine meldung ausgeben, die möglichst wenig über die hintergründe aussagt, den ausführlichen fehler lieber ins serverlog stecken ... falls für analyse gebraucht ....

 *Quote:*   

> 
> 
>  *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. 
> ...

 

JA, aber ein einfacher vergleich des übergebenen Logins mit dem im resultat könnte schon abhilfe schaffen, denn ein für eine injection modifizierter string wird kaum mit dem was er als output erzeugt übereinstimmen, beim pw würde ich ohnehin hshen, dann müßte einer schon einen string dort erraten, der den gleichen hashwert erzeugt ....

 *Quote:*   

> 
> 
>  *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.

 

ACK

----------

## chrib

 *hoschi wrote:*   

> 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?
> 
> 

 

man logrotate

 *Quote:*   

> 
> 
> Würdet ihr auf einem Desktop "noexec" für /tmp setzen?
> 
> 

 

Hängt m.E. davon ab, wie sehr Du den Usern traust, die auf der Maschine noch rumrödeln. Es gab auch mal einen Bug, wo man über das noexec-flag über den shared-library loader umgehen konnte. Der ist aber soviel ich weiss in aktuellen Kerneln beseitigt.

----------

## hoschi

danke  :Smile: 

ich vertraue mir als user, aber ob ich dem alkohol auch vertrauen kann...ich lass dann mal noexec  :Very Happy: 

----------

## benjamin200

mkr schrieb: *Quote:*   

> 
> 
> 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.
> 
> 

 

Wenn man von der Live-CD boote, stehe logischerweise das chkrootkit nicht zur Verfügung. Wie stellst du dir das Vorgehen vor?

1. booten von Live-CD

2. Partitionen mounten

3. chrooten

4. scannen

Wenn ja, finde ich das unlogisch, den durch das chrooten wird das System ja aktiviert. Wenn nein, Wie bekommt man chkroot für die Verwendung der Live-CD? Freue mich auf Antwort.

Thx,

Benjamin

----------

## mkr

 *benjamin200 wrote:*   

> Wenn man von der Live-CD boote, stehe logischerweise das chkrootkit nicht zur Verfügung. Wie stellst du dir das Vorgehen vor?

 

Entweder Du verwendest eine Live-CD mit chkrootkit drauf, oder Du lädst chkrootkit vom Live-System aus runter. Speichern kannst Du es schon auf einer Partition auf der Platte, denn das dort vorhandene System läuft ja nicht. Chrooten würde ich hingegen nicht.

----------

## benjamin200

mkr schrieb: *Quote:*   

> 
> 
> Entweder Du verwendest eine Live-CD mit chkrootkit drauf, oder Du lädst chkrootkit vom Live-System aus runter. Speichern kannst Du es schon auf einer Partition auf der Platte, denn das dort vorhandene System läuft ja nicht. Chrooten würde ich hingegen nicht.
> 
> 

 

Vom Live-CD draufladen? Wie das, wenn der emerge ja erst nach dem chrooten funktioniert. Source-Code mit wget laden und selbst kompilieren? Vielleicht kannst du mir ja das bitte noch Step-By-Step erläutern. Vielen Dank im voraus  :Smile: 

Thx,

Benjamin

----------

## mkr

 *benjamin200 wrote:*   

> Vom Live-CD draufladen? Wie das, wenn der emerge ja erst nach dem chrooten funktioniert. Source-Code mit wget laden und selbst kompilieren?

 

Entweder den Sourcecode downloaden und selbst kompilieren, oder auf einem Drittsystem kompilieren. Am besten statisch gelinkt, damit es auch sicher auf der Live-CD läuft:

```
make sense CC="gcc -static"
```

Oder eben eine Live-CD mit chkrootkit drauf verwenden. Im Moment fällt mir leider keine ein, aber es gibt sicher welche (such vielleicht im Google mal nach "forensic boot cd" oder ähnlich).

----------

## benjamin200

```
make sense CC="gcc -static"
```

kannst du das bitte nochmals genauer erläutern ???

Was bewirkt das genau?

----------

## mkr

Damit kompiliert man eine statisch gelinkte Version von chkrootkit. Statisch gelinkt bedeutet, dass die Binary von keiner Library (libc6 etc.) abhängig ist. Das ist manchmal notwendig, da auf der Live-CD nicht unbedingt die gleichen Versionen der Libraries installiert sind wie auf dem System, auf dem Du chkrootkit kompilierst.

Was "sense" bedeutet, weiss ich leider auch nicht. Ich hab nur von einer Website abgeschrieben...   :Rolling Eyes: 

make CC="gcc -static" oder make all CC="gcc -static" reicht normalerweise.

----------

## andreask

Also das würde mich auch mal interessieren. Ich hab es irgendwie noch nie hinbekommen irgendein Programm komplett statisch zu erstellen. Ich bin allerdings auch nicht der große C/GCC Experte  :Wink: 

Wenn ich z.B. mal wget komplett statisch, also ohne irgendwelche Abhängigkeiten bauen will:

```
$ ./configure --prefix=/home/ich/test/wget --without-ssl --with-PIC

$ make CC="gcc -static"
```

zeigt mir ldd immer noch

```
$ ldd wget

        libc.so.6 => /lib/libc.so.6 (0x20071000)

        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x20057000)

```

Exakt dasselbe wie ohne CC="gcc -static". "make sense" funktioniert nicht, und "make all" macht keinen Unterschied.

Wie funktioniert das?

----------

## DarKRaveR

Dumme Frage, was bedeutet denn PIC ?

Position independent Code, ich weiß zumindest, alle DSOs sind als PIC gelinked, ich weiß nicht, ob die option PIC einem statischen exetueable wiederspricht ..... Da bin ich grade überfragt, aber ich kann ja grade mal schauen ....

EDIT: Für die glibc gibt es nochmal extra ein static flag ....

-static-libgcc

versuche es mal damit zusätzlich

-sofern eine statische libc vorhanden ist ....

----------

## andreask

--with-PIC habe ich nur mal probiert, ich kenne das sonst auch nur von DSO. Was genau das (hier) für Auswirkungen hat weiß ich nicht. Aber auch ohne und mit -static-libgcc  ändert sich nichts. Woher bekommt man eine statische libc? Einen Fehler hate ich nicht. Warum braucht man die? Kann man nicht einfach ein komplett statisches binary erzeugen, welches auf keine externe Lib angewiesen ist?

----------

## DarKRaveR

Also, ich habe das mal fix gestestet - ein einfaches -static hat bei mir gelangt, um ein einfaches prog statisch zu bekommen. Hast Du mal auf den Output beim bauen von (in Deinem Beispiel wget) geschaut ? Ich vermute, da wird irgendwo bei den compilerflags was gesetzt, was sich mit dem -static nicht verträgt ....

----------

## AntonWert

Da doch alle Angriffe irgendwie darauf hinauslaufen dass root-Rechte erlangt werden, wie sicher ist dann das vorgehen (im Kernel) diese USB - Root - Login Sache zu aktivieren? (mir fällt leider der Name gerade nicht ein)

----------

