Hilfe, mein WYSIWYG-Editor ist plötzlich weg!!!

Unglaublich...aus forensischen Gründen (Fehleranalyse offline)!
Zuviel CSI geschaut?
Was soll denn ein Laie mit diesem Backup anstellen? Für ihn bringt dies NIX! Und wenn überhaupt, dann nur die conf und die log Dateien.

Zitat von paulchen

... ob php genau so kritisch ist wie andere sprachen, da auf seinem server definitiv php läuft.

Was für ein Quatsch...da auf diesem Server sicherlich auch CGI, Perl, SSI oder ASP läuft! Es geht um deine Verallgemeinerungen die haltlos sind.
Nur nen Tipp: mit Perl kann man viel mehr anstellen

Zitat von paulchen

mit restriktive php-config meine ich wenigstens ein eingehendes befassen mit der php.ini
stichworte wären hier z.b. allow_url_fopen, allow_url_include, disable_functions, open_basedir, register_globals, safe_mode etc.

An dieser Aussage merkt man ganz deutlich, dass dein Wissen einfach aus einer Zeit vor PHP 5.1 stammt. Mal davon abgesehen das ein Laie, der ein Server mietet schon einen Standard vorkonfigurierten Server bekommt und solch Einstellungen nicht mehr vornehmen muss. Des weiteren sind register_globals und safe_mode Dinge der Vergangenheit die mit Ver6 vollständig verschwunden sind und allow_url_fopen + allow_url_include sind Einstellungen welche ich nicht missen möchte.
Welche Funktionen würdest du denn disablen, eval? lol

...threadstarter? PHP unterstützt gar keine Threads. Der Vergleich hinkt, eher User oder Clients.

Zitat von paulchen

ssl THEMENBEZOGEN, was sonst? d.h. aktiviertes apache-ssl-modul. in diesem fall hat der apache sehr wohl etwas mit ssl zu tun. ebenso muss bei der shopeinrichtigung ssl berücksichtigt werden.

Ok dann zum Thema: mod_ssl ist standardmäßig im Apache 2 aktiviert, viel wichtiger ist dabei ein gültiges Zertifikat.
wenn nicht, loggt sich auch der admin unverschlüsselt ein.

Auch in Bezug auf FTP sind deine Informationen nur zum teil richtig und man merkt wie wenig du die Materie verinnerlicht hast, denn sonst wüsstest du, dass SFTP nicht die momentan beste alternative ist! Denn SFTP verschlüsselt nämlich nur einen Teil des FTP-Protokolls, den Steuerkanal...sonst wäre in diesem Zusammenhang Secure FTP (Basis SCP) oder FTPS (Basis TSL/SSL) zu nehmen.

nach deiner methode (wiederherstellen eines backups), würdest du genau den fehlerhaften zustand wie VOR dem hack herstellen, welcher zu den entsprechenden ereignissen führte - ohne zu wissen WO der betreffende fehler liegt.

Zitat von paulchen

streng fahrlässig

???

Wenn man davon ausgeht, dass dieser Server bei einem vertrauenswürdigen Provider steht, wäre Restore - Passwörter wechseln - Provider informieren unter gewissen Voraussetzungen eine schnelle Möglichkeit den Urzustand wieder herzustellen.
Außerdem auf Prob. von similar bezogen stellt sich die Frage, ob der private PC oder der Server befallen ist, denn dies sind Windows-Meldungen. Vorstellbar wäre durchaus, dass vom privaten Rechner aus die Passwörter ausgespäht wurden und der Server nicht einem Hack, sondern der Tatsache der Bekanntgabe der Passwörter zum Opfer gefallen ist.

Zitat von exception

Unglaublich...aus forensischen Gründen (Fehleranalyse offline)!
Zuviel CSI geschaut?
Was soll denn ein Laie mit diesem Backup anstellen? Für ihn bringt dies NIX! Und wenn überhaupt, dann nur die conf und die log Dateien.

csi? kenne ich nicht. ich vermute mal, dass es sich dabei um eine fernsehsendung handelt, welche ich in "ermangelung" eines fernseher nie gesehen habe.
wenn ein server gehackt wurde, ist das eine kriminelle handlung - für manche shopbetreiber ist das vielleicht eine "normale" situation. es geht dabei jedoch nicht um umsatzausfälle, zeitverlust und derlei, sondern um kundendaten und darüber hinaus um eigene strafbare handlungen.

hättest du mein 1. posting gelesen, hättest du verstanden, was er mit dem backup machen kann.
nach einem standart-hack werden die logs unter umständen gesäubert, zumindest sind diese mit vorsicht zu genießen.
man kann jedoch das gezogene backup mit dem letzten vergleichen. zu dieser schlussfolgerung kann man selbst als laie kommen.

Zitat von exception

Was für ein Quatsch...da auf diesem Server sicherlich auch CGI, Perl, SSI oder ASP läuft! Es geht um deine Verallgemeinerungen die haltlos sind.
Nur nen Tipp: mit Perl kann man viel mehr anstellen

fein der shop ist in php geschrieben. d.h. php ist definitiv auf seinem server installiert, der rest sind nur vermutungen.
und ja, ich glaube dir, dass du die besten perl-scripts weit und breit schreibst. hat aber nichts mit dem thema zu tun.

Zitat von exception

An dieser Aussage merkt man ganz deutlich, dass dein Wissen einfach aus einer Zeit vor PHP 5.1 stammt. Mal davon abgesehen das ein Laie, der ein Server mietet schon einen Standard vorkonfigurierten Server bekommt und solch Einstellungen nicht mehr vornehmen muss. Des weiteren sind register_globals und safe_mode Dinge der Vergangenheit die mit Ver6 vollständig verschwunden sind und allow_url_fopen + allow_url_include sind Einstellungen welche ich nicht missen möchte.
Welche Funktionen würdest du denn disablen, eval? lol

ich muss gestehen, dass bei mir noch php 5.2.4 läuft und das wird vorerst auch so bleiben. da sind diese einstellungen durchaus noch relevant. interessierte können sich unter http://www.php.net/manual/de/ini.list.php die direktiven und deren funktion anschauen. disable_functions wäre auch noch sehr interessant.

du als php- und server-crack kannst uns bestimmt erklären, wie eine korrekt auf diesen shop dedizierte php.ini auszusehen hat. ich bin gespannt und lerne immer gerne dazu.

du schreibst von version 6?? die kommt irgendwann, aber momentan sind wir bei 5.3.3. was mitnichten heißt, dass diese auch auf einem gut gewarteten server laufen muss.

Zitat von exception

...threadstarter? PHP unterstützt gar keine Threads. Der Vergleich hinkt, eher User oder Clients.

mit threadstarter meinte ich den menschen, welcher das ursprungsposting in diesem "diskussionfaden" umgangsschriftlich auch "thread" genannt, schrieb.

Zitat von exception

Ok dann zum Thema: mod_ssl ist standardmäßig im Apache 2 aktiviert, viel wichtiger ist dabei ein gültiges Zertifikat.
wenn nicht, loggt sich auch der admin unverschlüsselt ein.

natürlich. ein zertifikat ist notwendig. wenn auch für die shopeinrichtung ein selbst unterschriebenes (und sogar abgelaufenes) temporär reichen würde. da jedoch für den shop so und so ein offiziell unterschriebenes nötig ist, gesetzt dem fall man bietet verschlüsselung für den kunden an, ist vorhergehende überlegung hinfällig.

Zitat von exception

Auch in Bezug auf FTP sind deine Informationen nur zum teil richtig und man merkt wie wenig du die Materie verinnerlicht hast, denn sonst wüsstest du, dass SFTP nicht die momentan beste alternative ist! Denn SFTP verschlüsselt nämlich nur einen Teil des FTP-Protokolls, den Steuerkanal...sonst wäre in diesem Zusammenhang Secure FTP (Basis SCP) oder FTPS (Basis TSL/SSL) zu nehmen.

man merkt, wie wenig du die materie verinnerlich hast, denn sonst wüsstest du, dass sftp (nachfolger von scp) sehr wohl komplett verschlüsselt ist.
du verwechselst sftp mit secure ftp, bei welchem nur der steuerkanal verschlüsselt wird, was aber immerhin schon mal besser als gar nix ist.

eines deiner ersten beiträge in diesem thread:

Zitat von exception

3. Was bitte hat FTP damit zu tun? Wie überträgst du denn Files zum Server? --per $_POST...haha - insider

scheint gar darauf hinzudeuten, dass du bis dato gar keine ftp-alternativen kanntest.

Zitat von exception

Wenn man davon ausgeht, dass dieser Server bei einem vertrauenswürdigen Provider steht, wäre Restore - Passwörter wechseln - Provider informieren unter gewissen Voraussetzungen eine schnelle Möglichkeit den Urzustand wieder herzustellen.

das sehe ich auch so. jedoch wäre vor dem restore ein backup sinnvoll. das kann er dann einer sachkundigen person übergeben und/oder selbst noch dazulernen, in dem er das backup z.b. wie oben beschrieben untersucht.

Zitat von exception

Außerdem auf Prob. von similar bezogen stellt sich die Frage, ob der private PC oder der Server befallen ist, denn dies sind Windows-Meldungen. Vorstellbar wäre durchaus, dass vom privaten Rechner aus die Passwörter ausgespäht wurden und der Server nicht einem Hack, sondern der Tatsache der Bekanntgabe der Passwörter zum Opfer gefallen ist.

ja. es gibt einige möglichkeiten.
sein eigener lokaler rechner kann befallen sein, so dass zugangsdaten übermittelt wurden. sein lan (oder wlan) kann ausgespäht worden sein.
sein server kann gehackt sein - über welches einfallstor auch immer.

seine beschreibung sah für mich so aus, als würde sein virenscanner bei seitenaufrufen seines shops alarm auslösen, was ein typisches indiz für eine kompromittierung ist.

mag ja sein, dass dir die eristische dialektik nach schopenhauer sehr nahe steht und du auch ein guter php-programmierer bist.
das ändert wiederum nichts daran, dass mein themenbezogener erkenntnisgewinn durch deine schriftlichen ergüsse immer noch gleich null ist. das sollte doch angesichts der hochgesteckten erwartungen nach

Zitat von exception

OMG - paulchens Bullsh.. kommentiere ich gleich noch *kopfschüttel*

Zitat von exception

In Foren sind nun mal oft Laien unterwegs auf der Suche nach Hilfe und bekommen dann solchen bullsh... präsentiert und nehmen es wahrscheinlich noch für "bare Münze". Dabei gilt, wenn man keine Ahnung hat...

doch eigentlich bedeutend anders ausfallen.

klar, können wir jetzt völligst offtopic darüber philosophieren, ob jetzt php sicherheitskritisch ist oder perl, asp, c noch kritischer - dafür wäre ich btw. der falsche partner.

klar, user und programmierer stellen das höchste risiko dar, denn letztendlich haben diese nicht nur das script geschrieben/entworfen bzw. genutzt, sondern auch ALLES was damit zusammenhängt - nebst php, dem os, den peripheren firmwares und den anderen 1000 dingen, welche da noch dran hängen.

damit möchte ich den programmierern diesen shopsystems überhaupt nicht unterstellen, dass ihnen sachkenntnis fehlt - allzumal ich mich nicht in der lage befinde dieses auch wirklich einschätzen zu können. ich finde, dass seo-commerce wirklich eine tolle leistung darstellt. es können jedoch fehler passieren und das ist völlig normal.

letzten endes kann die ursache dieses themas auch eine ganz andere sein

Zitat von paulchen

...welche ich in "ermangelung" eines fernseher nie gesehen habe.

...wer es dir glauben mag! Auch kein Internet TV?

Zitat von paulchen

wenn ein server gehackt wurde, ist das eine kriminelle handlung - für manche shopbetreiber ist das vielleicht eine "normale" situation. es geht dabei jedoch nicht um umsatzausfälle, zeitverlust und derlei, sondern um kundendaten und darüber hinaus um eigene strafbare handlungen.
hättest du mein 1. posting gelesen, hättest du verstanden, was er mit dem backup machen kann.

Stimme ich dir zu, Provider informieren ggf. Polizei und Staatsanwaltschaft informieren.

Zitat von paulchen

nach einem standart-hack werden die logs unter umständen gesäubert, zumindest sind diese mit vorsicht zu genießen.
man kann jedoch das gezogene backup mit dem letzten vergleichen. zu dieser schlussfolgerung kann man selbst als laie kommen.

Und wieder nur ein Teil genommen, sehr schön! Natürlich werden die Logs gecleant...aber auch egal, denn nun trifft oben geschriebener Fall zu und dann sollte er gar nichts mehr am System machen, Profis an fertig.

Zitat von paulchen

fein der shop ist in php geschrieben. d.h. php ist definitiv auf seinem server installiert, der rest sind nur vermutungen.
und ja, ich glaube dir, dass du die besten perl-scripts weit und breit schreibst. hat aber nichts mit dem thema zu tun.

Darum ging es bei meiner Argumentation überhaupt nicht. Ich habe bloß andere Beispiele gebracht um deine Aussagen in Bezug auf PHP zu wiederlegen.

Zitat von paulchen

php ist sehr sicherheitskritisch - ergo ist mindestens eine sehr restriktive php-konfig unabdingbar, da mit sicherheit in jedem php-script sicherheitsrelevante fehler enthalten sind. die frage ist nur, WANN diese ausgenutzt werden.

Denn diese Aussage (Panikmache) ist schlicht und einfach FALSCH! PHP ist NICHT sicherheitskritisch und NICHT jedes Programm enthält FEHLER! Dies sind einfach nur pauschale Behauptungen deinerseits.

Zitat von paulchen

ich muss gestehen, dass bei mir noch php 5.2.4 läuft und das wird vorerst auch so bleiben. da sind diese einstellungen durchaus noch relevant. interessierte können sich unter http://www.php.net/manual/de/ini.list.php die direktiven und deren funktion anschauen. disable_functions wäre auch noch sehr interessant.

Hmm...gekonnt der Falle mit disable_functions und eval ausgewichen. Also wusstest schon das eval nicht disabled werden kann. Respekt! Eval ist eben keine Funktion.
disable_functions "" - viel mehr achte ich darauf, dass die PHP Erweiterung Suhosin installiert und up to date ist.

Zitat von paulchen

du als php- und server-crack kannst uns bestimmt erklären, wie eine korrekt auf diesen shop dedizierte php.ini auszusehen hat. ich bin gespannt und lerne immer gerne dazu.

Gehe ich richtig der Annahme, dass du Ubuntu 8.04 LTS benutzt? Das würde die Version 5.2.4 erklären.
Aber welche PHP - Standardeinstellungen stören dich denn nun, dass sich ein Laie damit UNBEDINGT befassen muss?

Ich, für meinen Teil achte neben der Standardkonfiguration darauf:
- allow_call_time_pass_reference off
- arg_separator.output & - W3C konforme URLs zu erhalten
- display_errors off - auf einem Produktivsystem haben Fehleranzeigen nichts verloren
- html_errors off
- log_errors on - um Fehlermeldungen natürlich mitzubekommen
- magic_quotes_gpc off - schalte ich immer ab, verlasse mich nur auf meine Einstellungen und ist ab 5.3 eh auf off
- memory_limit "128M" - wenn es nicht schon einstellt ist und der Server ausreichend Ressourcen besitzt
- register_long_arrays off

Aber all diese Einstellungen sind als Beispiel bei Strato & 1und1 mit OpenSuse Server schon so eingestellt. Allerdings nutzen diese PHP Versionen > 5.2.4.

Zitat von paulchen

du schreibst von version 6?? die kommt irgendwann, aber momentan sind wir bei 5.3.3. was mitnichten heißt, dass diese auch auf einem gut gewarteten server laufen muss.

Du hast mich missverstanden. Ich sprach von Version 6, weil PHP Version 5.3 (Zwischenschritt) schon viele der größeren Änderungen mitbringt und da dieser Shop sich PHP 5.3 auf die Fahnen geschrieben hat, schaue ich dementsprechend auch voraus (Stichpunkt: PHP 5.3 DEPRECATED).

Zitat von paulchen

mit threadstarter meinte ich den menschen, welcher das ursprungsposting in diesem "diskussionfaden" umgangsschriftlich auch "thread" genannt, schrieb.

Stimmt, wie blöde von mir. Das hab ich einfach falsch verstanden.

Zitat von paulchen

natürlich. ein zertifikat ist notwendig. wenn auch für die shopeinrichtung ein selbst unterschriebenes (und sogar abgelaufenes) temporär reichen würde. da jedoch für den shop so und so ein offiziell unterschriebenes nötig ist, gesetzt dem fall man bietet verschlüsselung für den kunden an, ist vorhergehende überlegung hinfällig.

Sehe ich genauso!

Zitat von paulchen

man merkt, wie wenig du die materie verinnerlich hast, denn sonst wüsstest du, dass sftp (nachfolger von scp) sehr wohl komplett verschlüsselt ist.
du verwechselst sftp mit secure ftp, bei welchem nur der steuerkanal verschlüsselt wird, was aber immerhin schon mal besser als gar nix ist.

Stimmt habe ich genauso verwechselt, aber Wiki ist da auch geil:
Zu Anfang: SSH File Transfer Protocol (SFTP) ist eine Weiterentwicklung von SCP
2 Zeilen darunter: ist SFTP eine Neuentwicklung der IETF

Zitat von paulchen

scheint gar darauf hinzudeuten, dass du bis dato gar keine ftp-alternativen kanntest.

Natürlich kenne ich andere Varianten, wie den Upload über http, wget usw...aber wie du an meiner Verwechselung schon bemerkt hast, zählte ich SFTP fälschlicher Weise voll zum Kreis FTP. Da ich den SSH-Server (Port 22) bisher eben nur mit Putty angesprochen habe, wohl noch ein Überbleibsel meiner Windows-Server Zeit.
Normalerweise übertrage ich immer FTPS da es eben Plattform übergreifend ist.

Zitat von paulchen

seine beschreibung sah für mich so aus, als würde sein virenscanner bei seitenaufrufen seines shops alarm auslösen, was ein typisches indiz für eine kompromittierung ist.

Sicherlich hat sich der Threadstarter einfach schlecht ausgedrückt und es war Zufall das das Virenprogramm zur selben Zeit Alarm schlug.
Das bei seinem Shop etwas fehlte bzw. verschwunden war, ist vielleicht eher der Tatsache geschuldet, dass er Shop-Dateien und Einstellungen selbstständig veränderte. Wahrscheinlich greifen wir beide schon einen Schritt zuweit oder wie man so schön sagt: "Wenn Du Hufe hörst, denke an Pferde, nicht an Zebras!"

Ironie ist es doch, dass wir beide über die bessere Vorgehensweisen oder über Möglichkeiten der Kompromittierung diskutieren und "similar" sein Problem einfach ausführlicher beschreiben könnte, um somit sämtliche Missverständnisse zu beseitigen.

Zitat von paulchen

das ändert wiederum nichts daran, dass mein themenbezogener erkenntnisgewinn durch deine schriftlichen ergüsse immer noch gleich null ist. das sollte doch angesichts der hochgesteckten erwartungen nach doch eigentlich bedeutend anders ausfallen.

klar, können wir jetzt völligst offtopic darüber philosophieren, ob jetzt php sicherheitskritisch ist oder perl, asp, c noch kritischer - dafür wäre ich btw. der falsche partner.

Wechle themenbezogenden Erkenntnisse sind denn von dir eingeflossen??? Das Erkennen eines Windows Virus oder eher:

- PHP ist sehr sicherheitskritisch
- eine restriktive config ist notwendig
- darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar

Da haben sich deine Ergüsse und Problemlösungsansätze aber in Grenzen gehalten!

Zitat von paulchen

letzten endes kann die ursache dieses themas auch eine ganz andere sein

Kann ich so nur doppelt unterstreichen und mit SFTP noch was gelernt

Zitat von exception

...wer es dir glauben mag! Auch kein Internet TV?

nein, das wäre irgendwie des gleiche
die entscheidung des "verzichts" bzw. der lebensbereicherung fiel während des wahlkampfes 2002 ("viel reden und nichts sagen" in kombination mit knappen zeitressourcen und der absurdität für derlei auch noch gebühren zu zahlen.

Zitat von exception

Und wieder nur ein Teil genommen, sehr schön! Natürlich werden die Logs gecleant...aber auch egal, denn nun trifft oben geschriebener Fall zu und dann sollte er gar nichts mehr am System machen, Profis an fertig.

dito
genau. deshalb ist es gar nicht mal so sinnlos, erst den server herunterzufahren und weiteres über die remote-konsole zu veranlassen. ein backup mit bordmitteln könnte auch etwas sehr ungewolltes auslösen.
wer weiß, was bereits ein simples "cd" oder "ls" bewirkt

Zitat von exception

Darum ging es bei meiner Argumentation überhaupt nicht. Ich habe bloß andere Beispiele gebracht um deine Aussagen in Bezug auf PHP zu wiederlegen.

Denn diese Aussage (Panikmache) ist schlicht und einfach FALSCH! PHP ist NICHT sicherheitskritisch und NICHT jedes Programm enthält FEHLER! Dies sind einfach nur pauschale Behauptungen deinerseits.

ich kenne mich mit php-programmierung nicht aus. jedoch weiß ich eines: php ist ausreichend mächtig und darüber hinaus die breiteste angriffsfläche eines kleinen standart-servers (die masse) von irgendwelchen bruteforce-ssh- und mail-attacken einmal abgesehen, mit welcher man auch eine php-shell erzeugen könnte (ohne safe_mode) und darüber hinaus auch noch datenbankanbindung besteht.
php selbst beinhaltet auf jeden fall fehler und das wird immer so bleiben (so wie bei fast jeder software). die aufgedeckten kann man den bugfix-listen entnehmen. wer jedoch glaubt, dass nach einem bugfix oder gar major release keine fehler mehr enthalten sind, der irrt definitiv.

in dem zusammenhang auch ganz interessant: http://webdeveloper.franzis.de/php-5x/php-6-i…er-pierre-joye/

Zitat von exception

Hmm...gekonnt der Falle mit disable_functions und eval ausgewichen. Also wusstest schon das eval nicht disabled werden kann. Respekt! Eval ist eben keine Funktion.
disable_functions "" - viel mehr achte ich darauf, dass die PHP Erweiterung Suhosin installiert und up to date ist.

WENN php nicht sicherheitskritisch wäre, gäbe es keine hardened php und damit auch kein suhosin.
suhosin macht nichts anderes, als funktionen, welche alternativ unter disable_functions standen, zu deaktivieren.

in dem kontext auch interessant: http://www.hardened-php.net/suhosin/why.html

aber bei aktiviertem safe_mode würde disable_functions nicht greifen.

Zitat von exception

Gehe ich richtig der Annahme, dass du Ubuntu 8.04 LTS benutzt? Das würde die Version 5.2.4 erklären.
Aber welche PHP - Standardeinstellungen stören dich denn nun, dass sich ein Laie damit UNBEDINGT befassen muss?

ja, 8.04.

register_globals off (ja, ich weiss, ab 5.3 nicht mehr interessant)
magic_quotes off (-"-)
expose_php off (ja, kontrovers, aber es schadet auf keinen fall)
allow_url_fopen off (da ich nicht einschätzen kann, ob das script "sauber" programmiert ist)

im wesentlichen halte ich mich an die offiziellen empfehlungen, auf welche auch noch mal in der php.ini hingewiesen wird:

Zitat

;;;;;;;;;;;
; WARNING ;
;;;;;;;;;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult php.ini-recommended
; and http://php.net/manual/en/security.php.

Alles anzeigen

früher hatte ich zusätzlich mod_security in betrieb. ob das noch nötig ist, entzieht sich meiner kenntnis.

Zitat von exception

Stimmt habe ich genauso verwechselt, aber Wiki ist da auch geil:
Zu Anfang: SSH File Transfer Protocol (SFTP) ist eine Weiterentwicklung von SCP
2 Zeilen darunter: ist SFTP eine Neuentwicklung der IETF

ja. prinzipiell fast egal, da die standart-applikationen a la winSCP, cyberduck bzw. ssh2 (sftp), welche meist verwendet werden da schon das entsprechende protokoll verwenden und ein ftp-server eh nicht läuft, sondern schön säuberlich der sshd (2) mit deaktiviertem root-login und sonst nix. aber wie schon bemerkt: bei schwachen passwörtern bringen starke verschlüsselungen auch nicht viel - deshalb ist eine schlüsseldatei mit passwort optimal.

Zitat von exception

Ironie ist es doch, dass wir beide über die bessere Vorgehensweisen oder über Möglichkeiten der Kompromittierung diskutieren und "similar" sein Problem einfach ausführlicher beschreiben könnte, um somit sämtliche Missverständnisse zu beseitigen.

ja, auf jeden fall jetzt geht es kaum noch um seinen fall, sondern um typisch männliche verhaltensweisen - quasi als soziologie-studie ;);)

Zitat von exception

Wechle themenbezogenden Erkenntnisse sind denn von dir eingeflossen??? Das Erkennen eines Windows Virus oder eher:

- PHP ist sehr sicherheitskritisch
- eine restriktive config ist notwendig
- darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar

Da haben sich deine Ergüsse und Problemlösungsansätze aber in Grenzen gehalten!

mein 1. posting war folgendes (nochmal zum rekapitulieren):

Zitat

ich, an deiner stelle, würde wie folgt vorgehen:

server abschalten.
backup ziehen.
jemanden hinzuziehen, der sich mit serversicherheit auskennt.

jeden tag werden mehr server gehackt, als man sich vorstellen kann.

php ist sehr sicherheitskritisch - ergo ist mindestens eine sehr restriktive php-konfig unabdingbar, da mit sicherheit in jedem php-script sicherheitsrelevante fehler enthalten sind. die frage ist nur, WANN diese ausgenutzt werden.

darüber hinaus sind folgende anwendungen/szenarieren im prinzip auch nicht mehr tragbar - gleich gar nicht, wenn man mit kundendaten hantiert:
- fehlender apache-ssl
- ftp
- schwache passwörter

Alles anzeigen

das war doch ganz konkret. auch auf einen "laien" zugeschnitten. oder?

wie läuft es denn im normalfall?
phpmyadmin installiert
ein webadmin-interface installiert
ein völligst overdressed cms (php) mit plugins von drittanbietern
ein webshop (php) mit vielen hacks
irgendein php-script für irgendeine abstruse funktion (gästebuch, counter, logger, mailform ...)

updates (meist sicherheitsrelevante bugfixes) werden oft nicht eingespielt. damit liegt der fehler zwar beim user - jedoch nur aus dem grund, weil ein fehler im script erkannt und beseitigt wurde.

wenn da nix geht, dann weiß ich auch nicht mehr. meist laufen nicht einmal die (erwünschten) kernfunktionen zu 100% fehlerfrei, da will ich gar nicht ahnen, was noch so alles gehen könnte ...

ich möchte da mitnichten zu krankhafter paranoia anregen, jedoch sollte man sich bestimmter risiken auch bewusst sein.
man kann mit warez-servern, bot-nets und spam-servern ordentlich geld verdienen (und einiges anderes). das reicht als motivation.

open-source ist schön. wenn man den code jedoch nicht versteht oder in seiner gänze mitnichten überblicken kann, lassen sich fehler (oder schlimmeres) kaum bzw. schlicht und einfach nicht erkennen - und wenn, dann auch nur bei unfehlbarkeit des prüfers bzw. reichlich manpower.

nichtsdestotrotz: alles bestens

vielleicht finden wir ja bald einen verleger :D:D