Forum

Salve

@stefan, ich verlange nicht das jemand zaubert. Wir sind alle Menschen und das mit Plesk ist oder war unglücklich. das war nicht gegen Dich oder andere gemeint, ich meinte wirklich ernsthaft das man das Hotfix vielleicht anpassen sollte. Ist geschehen und das ist auch gut so.

Wie ich bereits schrieb, ich hatte den Hack nicht und kam aber halt in den Genuß das dafür die Seite down war. Außnahmsweise hatte ich tatsächlich mal kein Backup gemacht und ich Danke nochmals für die rasche Hilfe.

Wie gesagt, es war auch eigentlich eine Nachfrage. Gut, ist alles geklärt und Danke nochmals, hauptsache ist der Fix hilft den Leuten.

aha, danke, hab ich gefunden, hilfe ist das ne Menge.

Aber wieder was dazugelernt.

darksweetys schrieb am 01.05.2006 um 13:13:16 Uhr folgendes:

das Tracking molul hab ich mir wieder installiert. Wo finbdet man den Serverlog?

Ich weiss ihr müsst Euch vorkommen wie Lehrer die nem begriffstutzigen Schüler versuchen etwas beizubringen "fg" Aber wo das Forum schonmal so gut besucht ist...

Nicht in OPN Das stellt dein Anbieter zur Verfügung, aber mit Webalizer ist glaube ich nicht viel Staat zu machen in der Beziehung. Auf vielen Servern findet sich, vom Provider bereitgestellt, ein Verzeichnis stats oder plesk-stat oder statistics. Dort sollten Logdateien drin sein, meist für eine Woche, der Rest in der Regel komprimiert. Aber wie gesagt, nur einmal am Tag aktualisiert, und im Textformat, du solltest also zur Auswertung noch ein Programm hinzuziehen.

das Tracking molul hab ich mir wieder installiert. Wo finbdet man den Serverlog?

Ich weiss ihr müsst Euch vorkommen wie Lehrer die nem begriffstutzigen Schüler versuchen etwas beizubringen "fg" Aber wo das Forum schonmal so gut besucht ist...

Danke Webschmied, hattest Recht, hätte nur besser lesen sollen.

besser gleich im serverlog, weil nicht jeder hat tracking aktiviert.....

darksweetys schrieb am 01.05.2006 um 12:50:16 Uhr folgendes:

mich würde mal interessieren woran man erkennt dass es ein Angriff war. Also offtmals steht ja im Errorlig ausgelöst von User: darksweetys. Das ist dann wohl ne Sache die intern ist (nehm ich an)
.
.
Nur das man als Laie mal erkennt woran man erkennt das es ein böswilliger angriff war.

Lies mal meinen Beitrag etwas weiter oben, im Tracking (oder wenn du Zugriff hast auch im Serverlog, aber das meist mit zeitlicher Verzögerung verfügbar), kannst du sehen wo versucht wurde reinzukommen.

P.S. Kennt jemand www.thescourge.org? Scheint es auch erwischt zu haben.

McBright schrieb am 01.05.2006 um 12:30:30 Uhr folgendes:

Salve

@ spinne, schon verstanden was er meinte und ich habs bereits im Einsatz. Ich meinte den Satz mit

problem ist das du da dann wohl httpdocs drin hast. ist eigentllich nicht zu empfehlen.

>
> bzw. verstehe ich es so, das trotz des EReg kein wirklicher Schutz da ist, korrigiert mich bitte wenn ich falsch liege....

*korrigiert*

der beitrag ist in zeitlichem abstand entstanden zuerst stand da nur das du es löschen sollst damit die seite ging dann erst kamm der fix (10 min später)

mich würde mal interessieren woran man erkennt dass es ein Angriff war. Also offtmals steht ja im Errorlig ausgelöst von User: darksweetys. Das ist dann wohl ne Sache die intern ist (nehm ich an)

Was be4deutet aber z.B.

- 404 - Fehler
Die gewünschte Seite wurde nicht gefunden.


Ausgelöst von der IP Adresse: 88.65.3.160 um 01.05.2006 12:43:24

Die URI die den Fehler ausgelöst hat war:
/home/e/erzandre/public_html//admin/openphpnuke/error.php?op=404

Die Error-Seite wurde aufgerufen von:
N/A


So und jetzt noch ein paar Infos

Browser : Mozilla/3.0 (compatible; Indy Library)
REMOTE_PORT : 36571
REMOTE_NAME : dslb-088-065-003-160.pools.arcor-ip.net
SERVER_PORT : 80
SERVER_PROTOCOL : HTTP/1.1
SERVER_SOFTWARE : Apache/2.0.48 (Linux/SuSE)
SERVER_NAME : erzandre.h103718.serverkompetenz.net
SERVER_ADDR : 81.169.166.160




REQUEST_URI=/admin/openphpnuke/error.php?op=404

user information
UNAME:anonymous
UID:1


Client=

* ua ::=> mozilla/3.0 (compatible; indy library)
* browser ::=> ns
* version ::=> 3.0
* maj_ver ::=> 3
* min_ver ::=> .0
* letter_ver ::=> Unknown
* javascript ::=> 1.1
* platform ::=> Unknown
* os ::=> Unknown
* ip ::=> 88.65.3.160
* cookies ::=>
* language ::=> en-us
* long_name ::=> mozilla
* gecko ::=> Unknown
* label ::=> 0
* shrinkinputbox ::=> 1
* dpi ::=> 96

Nur das man als Laie mal erkennt woran man erkennt das es ein böswilliger angriff war.

McBright schrieb am 01.05.2006 um 11:57:32 Uhr folgendes:

Salve

Versteht mich nicht falsch, aber der Security Fix sollte auch für Plesk bzw. andere Systeme gehen und das System "sicher" machen, den so wie ich das verstehe ist jetzt das System noch immer nicht sicher bei mir

a) ist das hot-fix aus dem artikel bereits angepasst worden
b) wird das update netter weise durch tine im hintergrund ebenfalls angepasst werden
c) zaubern können wir nun auch nicht

d) die konfigurationen sind sehr vielfältig das dieses mit plesk sofort nicht ging ist sagen wir mal pech. es ist nicht möglich alle systeme die es gibt vorher zutesten.

nur um mal einen eindruck zu geben ... getestet wurde unter folgenden system jeweils 100% richtig konfiguriert teilweise mit Confixx

(W) IIS 4 php 5.1.2
(L) apache 2.0.54 php 4.4.2
(W) apache 2.2.0 php 5.1.2
(L) apache 1.3.26 php 4.4.1

tatsache ist das eine richtige Server Config (100% richtig) eigentlich jeden angriff stoppen bzw verhindern kann.

Klar ist das es leider viel zu viele schlechte installationen gibt.

Es ist somit unmöglich jede auch nur denkbare Config zu testen. Es geht eben nicht anderes als das wenn Probleme da sind, sie gelöst werden. Und wenn es sein muss durch einen fix für einen fix für einen fix.

Tut mir leid aber ich verstehe da das probnlem nicht wirklich es wird hier sicherlich schnell geholfen. Auf alle fälle so schnell wie möglich. Sicher unterscheiden wir zwischen wichtig und unwichtiger. Trotzdem wenn nicht jemand überstürzt irgendwas tut wovon er keine ahnung hat und uns auch ne moment zeit läst nach zudenken. kann man eigentlich alles irgendwie hinbiegen.

der neuste fix sollte dann auch unter plesk gehen. und auch da wirken. aber auch das ändert nichts daran das eigentlich die php.ini angepasst werden sollte... da wo das problem sitzt.

Wie heinz schon sagte wenn man uns nichts meldet oder sagt dann ist es auch nicht möglich zu reagieren.

Und nochmal Backups sollte man immer haben oder wie wir adrenalin junky sein