phpbar.de logo

Mailinglisten-Archive

[php] Re: =?iso-8859-1?Q?=5Bphp=5D_Re:_=5Bphp=5D_Re:_=5Bphp=5D_PHP_verschl=FCsseln?= =?iso-8859-1?Q?=3F!?= =?iso-8859-1?Q?=3F!?=

[php] Re: =?iso-8859-1?Q?=5Bphp=5D_Re:_=5Bphp=5D_Re:_=5Bphp=5D_PHP_verschl=FCsseln?= =?iso-8859-1?Q?=3F!?= =?iso-8859-1?Q?=3F!?=

Andreas Braukmann braukmann_(at)_tse-online.de
Mon, 28 Feb 2000 19:27:45 +0100


Hi,
 ... ich meine, man sollte bei 'Sicherheitsueberlegungen' - neben
 dem sicher wichtigem Blick auf die Einzel-Risiken - das entstehende
 Verbundrisiko im Auge behalten.

On Mon, Feb 28, 2000 at 06:24:51PM -0100, Arne Blankerts wrote:
> On Mon, 28 Feb 2000 15:29:32 +0100, Björn Schotte wrote:
> >* Seth Iorio wrote:
> >> gibt es eine Möglichkeit php3 bzw. php4 zu compillieren?
> >> Genauer gesagt geht es darum den Source-Code für andere
> >> unleserlich zu machen. Gibts da Möglichkeiten?

> >
> >Nein. Vielleicht gibt es mal einen PHP Compiler, darauf
> >sollte man aber lieber nicht warten ... du kannst aller-
'nur tokenisierter' Code ist 'relativ' einfach zu 'entschluesseln'.

> Man kann php code compilieren (bzw eigentlich eher tokenisieren) ,
> was einen nicht lesebaren "Sourcecode" zu Tage fördert.
Man hat aber immer noch eine sehr, sehr sourcecode-nahe Repraesentation
der Software, die mit einem 'Kompilat' nicht viel gemein hat.


> >dings versuchen, die Dateirechte deiner Scripte so zu setzen,
> >dass nur du und dein Webserver Zugriff darauf haben.
 
> Uaargls.. Das hilft vor "root"-attacken so ziemlich garnix..
Wenn Dein bzw. ein wichtiger Webserver 'gerooted' wird, hat man 
wahrscheinlich deutlich groessere Probleme als ein paar geklaute
PHP-Sourcen. (Betriebsausfall, Aerger, Regressansprueche von Kunden,
etc. etc.; selbst ein sofort bereitgestellter Failover-Server hilft
in einer solchen Situation ja nicht wirklich; da er ja prinzipiell
mit derselben Technik, die beim ersten Server zum Erfolg gefuehrt 
hat (den noetigen Ehrgeiz beim Angreifer mal vorausgesetzt),
angegriffen werden kann.

Wenn Deine PHP-Software so wertvoll ist, dass die 'root-exploits'
mit dem Ziel unternommen werden, die Software zu stehlen, sollte
man eher versuchen die betroffenen Webserver staerker zu schuetzen.
Wenn es jemand schafft eine auf Sicherheit getrimmte Webserver-Maschine
in Besitz zu nehmen, so wird ihn 'tokenized php' wohl kaum vor
groessere Probleme stellen.


Das ziemlich elativ hohe Risiko (gerade in mittelgrossen und groesseren
Unternehmen), dass sich jemand Deine Geschaeftsgeheimnisse relativ
problemlos per 'social engineering' verschaffen koennte, sollte man
bei einer Risikoanalyse auch nie ausser acht lassen.
Das ist im Zweifelsfall naemlich sogar sehr viel angenehmer fuer
den Angreifer als naechtelange, zudem wahrscheinlich vergebliche, Versuche,
eine gut administrierte Unix-Maschine zu knacken.

Oder kennt hier jemand z.B. einen 'remote root exploit', der mit
einem nackten Port 80 (hinter dem ein aktueller apache lauscht) 
auskommt?
Mehr _muss_ von einem 'sicherem' Webserver ja garnicht im Netz
zu sehen sein.

-Andreas

-- 
: Anti-Spam Petition:     http://www.politik-digital.de/spam/          :
: PGP-Key:                http://www.tse-online.de/~ab/public-key      :
: Key fingerprint:  12 13 EF BC 22 DD F4 B6  3C 25 C9 06 DC D3 45 9B   :


php::bar PHP Wiki   -   Listenarchive