Hackerangriff mit Layer-Ads Werbung?

[mgutt]

Meine aktuelle .htaccess, falls Interesse besteht: (und damit die weitere Diskussion in diese Richtung)
http://www.phpbb.de/viewtopic.php?p=775787#775787

Ich habe sowohl die Firma Layer-Ads, als auch Freewebs, dass die die Datei vom Server nehmen sollen.

Weiterhin erstatte ich Anzeige mit Angabe aller IPs und der Layer-Ads Ref-ID. Mal sehen ob es etwas bringt.

In wie weit neue Dateien auf dem Server gelandet sind werde ich direkt als nächstes überprüfen. Aus Spass wollte ich das "includes"-Folder auch per .htaccess schützen habe aber dann gemerkt, dass ich dort zu includende .js Dateien habe

@ larsneo
Ich werde jeden Tipp beherzigen und mit dem Techniker besprechen.

EDIT:
Was ich im Moment nicht verstehe ist, warum dieser C99 Shell in der Lage ist das Adminfolder zu öffnen, obwohl ich doch den .htaccess-Schutz drin habe.

EDIT2:

hoi,

hast auch mit chkrootkit auf eventuelle Rootkits ueberprueft?

nochmal das Kommentar des Technikers dazu: Rootkits sind Scripte mit denen ein Hacker Root Rechte (wie bei Windows Administrator Rechte) erlangen kann, dies ist aber aufgrund von Sicherheitsvorkehrungen die wir getroffen haben nicht möglich.

[cYbercOsmOnauT]

EDIT:
Was ich im Moment nicht verstehe ist, warum dieser C99 Shell in der Lage ist das Adminfolder zu öffnen, obwohl ich doch den .htaccess-Schutz drin habe.

Einfach erklärbar. Die .htaccess ist eine Datei die externen Zugriff steuert. Die C99 Shell jedoch arbeitet lokal. Die Verzeichnis- und Dateizugriffe werden ja lokal durchgeführt. Somit ist Apache aussen vor und die .htaccess wirkungslos.

[larsneo]

Rootkits sind Scripte mit denen ein Hacker Root Rechte (wie bei Windows Administrator Rechte) erlangen kann, dies ist aber aufgrund von Sicherheitsvorkehrungen die wir getroffen haben nicht möglich.

obacht, linux 2.6 bis und einschliesslich kernel 2.6.17.4 hat eine bekannte "race condition" die zum lokalen hack genutzt werden kann falls /proc nicht als noexec gemountet ist. hinweise auf dazu passende exploits (aka h00lyshit) habe ich - wenn auch für j! - bei remote code injections gefunden. dass der c99 hack überhaupt möglich ist zeugt schon von einer nicht wirklich guten sicherheitsstrategie, von daher würde ich nicht unbedingt darauf vertrauen, das sonst nix passiert ist

[IPB_Flüchtling]

Aus Spass wollte ich das "includes"-Folder auch per .htaccess schützen habe aber dann gemerkt, dass ich dort zu includende .js Dateien habe

Dann schreibst Du diese Mods halt um und legst dann einen .htaccess-Schutz auf den Includes-Folder (habe ich auch getan). Handelt sich dabei ja bitte nur um Pfadangaben.

Du hast geschrieben, Du hättest den Shoutbox-Mod von phpBB.com? What to do when you find a vulnerability in MODs

LG, IPB_Flüchtling

[blubbin]

Aus Spass wollte ich das "includes"-Folder auch per .htaccess schützen habe aber dann gemerkt, dass ich dort zu includende .js Dateien habe

Warum verbietest du dann nicht den Zugriff nur für die php-Dateien?

[cYbercOsmOnauT]

Die ganze Mühe kann man sich auch sparen, wenn man einfach nur "register_globals" und/oder "allow_url_fopen" per .htaccess (oder in der php.ini falls man nen eigenen Server besitzt) auf "off" stellt.

[mgutt]

Du hast geschrieben, Du hättest den Shoutbox-Mod von phpBB.com? What to do when you find a vulnerability in MODs

LG, IPB_Flüchtling

Alles schon passiert. Der Autor war kurzfristig erreichbar und hat den Fehler behoben:
http://www.phpbb.com/phpBB/viewtopic.ph ... 54#2502854

Gruß

EDIT:
Was ich im Moment nicht verstehe ist, warum dieser C99 Shell in der Lage ist das Adminfolder zu öffnen, obwohl ich doch den .htaccess-Schutz drin habe.

Einfach erklärbar. Die .htaccess ist eine Datei die externen Zugriff steuert. Die C99 Shell jedoch arbeitet lokal. Die Verzeichnis- und Dateizugriffe werden ja lokal durchgeführt. Somit ist Apache aussen vor und die .htaccess wirkungslos.

Danke. Gut zu wissen.

Gruß

Aus Spass wollte ich das "includes"-Folder auch per .htaccess schützen habe aber dann gemerkt, dass ich dort zu includende .js Dateien habe

Warum verbietest du dann nicht den Zugriff nur für die php-Dateien?

Danke. Hätte ich auch drauf kommen können [ externes Bild ]

Die ganze Mühe kann man sich auch sparen, wenn man einfach nur "register_globals" und/oder "allow_url_fopen" per .htaccess (oder in der php.ini falls man nen eigenen Server besitzt) auf "off" stellt.

Jeder Aufwand ist mir recht und man kann nie wissen, ob z.B. bei einem Update von php oder durch einen anderen ungeschickten Vorgang plötzlich die php.ini auf Standard zurückgesetzt wurde und dann steht man da. Solange kein Nachteil daraus entsteht sehe ich kein Argument mehr für die Sicherheit zu tun. Oder nicht?

[larsneo]

Jeder Aufwand ist mir recht und man kann nie wissen, ob z.B. bei einem Update von php oder durch einen anderen ungeschickten Vorgang plötzlich die php.ini auf Standard zurückgesetzt wurde und dann steht man da. Solange kein Nachteil daraus entsteht sehe ich kein Argument mehr für die Sicherheit zu tun. Oder nicht?

wenn mein provider die aktuellen security settings 'mal eben so' und ohne rücksprache ändern würde, würde ich ihm die ohren ganz schön lang ziehen

vielleicht als diskussionsgrundlage für eine möglichst optimale serverkonfiguration in bezug auf sicherheit und performance mein aktueller tipp:
- php 5.1.6 mit suhosin patch und extension (ggfs. cookie und session encryption deaktivieren)
- apache 2.2.3 mit modsecurity (rules an anderer stelle im forum)
- register_globals=off, allow_url_fopen=off, expose_php=off, magic_quotes_gpc=on
- ggfs. safe_mode und open_basedir (nur, wenn man wirklich weiss, was man tut...)
- disable functions: show_source, system, shell_exec, passthru, exec, popen, proc_open, symlink
- apc als accelerator

[IPB_Flüchtling]

Ahoi,

wie setzt man denn allow_url_fopen per .htaccess auf off?

Ich habe es mit allow_url_fopen off und mit allow_url_fopen=off probiert, aber dabei beide Male einen Internal Servor Error 500 erhalten.

LG, IPB_Flüchtling

[larsneo]

wie setzt man denn allow_url_fopen per .htaccess auf off?

leider gar nicht.

Die seit PHP 4.0.4 gesetzte Grundeinstellung allow_url_fopen=on ermöglicht in vielen schlecht geschriebenen Skripten die Einbindung von entferntem Programmcode. Seit PHP 4.3.4 ist diese Einstellung darüberhinaus leider auch PHP_INI_SYSTEM, was bedeutet, dass ein lokales Überschreiben via ini_set() nicht mehr möglich ist. Dies führt dazu, daß gerade im Shared Hosting die Anwender in aller Regel auf gute Progammierung vertrauen müssen, da viele Provider allow_url_fopen auf on gesetzt haben.