Beiträge von cywhale

    Hm, in deiner CSS-Datei steht für .content und .pic folgendes:

    CSS
    background: url(images/spring_flavour/schatten.png) no-repeat bottom right !important;

    Wäre es dann nicht möglich dass die Anfragen doch aus dem CSS kommen (auch wenn da noch ein /images davorsteht)? Zumal selbiges als Referer angegeben ist?

    Dieses Bild (aus dem CSS) scheint nicht zu existieren -> 404, wenn dann .content oder .pic häufiger angewandt werden summiert sich das. Könnten daher auch mehrere Probleme sein, ein Script was den Server mit Anfragen überlastet, die dann wiederum auch als quasi Nebeneffekt die 404er verursachen. Wie häufig kommen denn die Anfragen und wie sehen die Daten (User agent, Request o.Ä.) der jeweils ersten Anfrage aus? Irgendetwas seltsames?

    Grüsse

    1) Korrekt, wenn kein Referer vorhanden oder Referer nicht von deiner Domain -> Forbidden-Fehler (kann man dann auch schön in den Logfiles sehen). Kein Referer KANN aber auch manchmal legitim sein (Firewall, Blocker, Anonymizer).

    2) Ich verstehe immer noch nicht was 'auf ein PNG klicken' heissen soll, sind die PNGs verlinkt? Wenn nicht dann löst das 'Klicken' kein Ereignis und keinen Logeintrag aus sondern es wird direkt darauf zugegriffen (Hotlinking).

    Grüsse

    Denke auch dass absolut nichts dagegen spricht sich über notwendige Änderungen wg. einer zukünftigen Version zu erkundigen, wird ja niemand gezwungen zu antworten.

    Ist in jedem Fall besser als erst am Release-Tag zu aktualisieren, festzustellen das irgendetwas nicht funktioniert und dann erst an die Problemlösung zu gehen - da haben weder Admin noch Benutzer etwas davon.

    Nachteil ist natürlich dass man immer nur den aktuellen Stand erfragen kann, wenn sich trotzdem noch etwas ändert gibt es auch trotzdem evtl. ein Problem.

    Grüsse

    Habe in einem Testlauf ein WP2.7 lokal neu installiert, die Plugins und mein eigenes Theme installiert und aktiviert - gab überhaupt gar kein Problem. Theme läuft wie gehabt, die getesteten Plugins glücklicherweise auch.

    Die comments.php muss man nur ändern wenn man die neuen Threaded Comments oder Paged Comments verwenden möchten.

    Hast du noch einen Link zu dem was du gelesen hast?

    Grüsse

    Hm, ich habe noch nicht ganz begriffen was es bedeutet dass jemand 'auf einem PNG' ist - heisst dass
    1) das jemand eine Blogseite mit dem PNG als Inhalt aufruft ?
    2) das jemand das PNG direkt aufruft (so verstehe ich es) ?

    Eine Möglichkeit wäre die Benutzung von PNGs zu verbieten falls der Referer nicht deine Seite repräsentiert, d.h. auch wenn er leer ist:

    Apache Configuration
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_REFERER} !^http://(www\.)?wie-auch-immer-deine-domain-heisst.de/.*$ [NC]
    RewriteRule .(jpe?g|png)$ - [F]
    </IfModule>

    Würde den Zugriff auf .jpg,.jpeg und .png von ausserhalb der Domain (mit oder ohne www, Gross-/Kleinschreibung egal =[NC]) sperren (403 Forbidden=[F]). Im Normalfall wird als Referer deine Domain angegeben sofern die Bilder
    durch diese Domain eingebunden werden, Ausnahme wäre wenn der Referer durch z.B. Firewallsystem oder Anonymizer geändert/entfernt wird.

    Der Referer kann auch durch den Benutzer beeinflusst werden, evtl. wird da aber auch nur ein Script verwendet, käme auf einen Versuch an.

    Grüsse

    Jetzt muss ich mal ganz dumm fragen - wieso fragst du nicht auf der Pluginseite den Autor selbst (Dafür sind die Kommentare offen) ? Seit der Veröffentlichung von CyStats bemühe ich mich so es zeitlich geht alle Komentare/Fragen/Fehlermeldungen zu beantworten?

    Zum Thema: Ein Widget ist bisher nicht integriert, mit den Template-Tags nach obigem Link lässt sich das aber einbauen.

    Die gesuchte Templatefunktion ist

    Code
    [COLOR=#000000][B][I]function[/I][/B][/COLOR] cystats_getMostVisited([COLOR=green][COLOR=green]$limit[/COLOR][/COLOR], [COLOR=green][COLOR=green]$pre[/COLOR][/COLOR], [COLOR=green]$[COLOR=#0000ff][B]pos[/B][/COLOR][/COLOR], [COLOR=green][COLOR=green]$showmode[/COLOR][/COLOR]=[COLOR=#000000][B][I]true[/I][/B][/COLOR])

    Vorausgesetzt deine Sidebar ist als Liste (ul oder ol) aufgebaut lässt sich die Anzeige z.B. so einfügen:

    PHP
    <li>
        <span>Meistbesucht (Top 5):</span>
        <ul>
            <?php cystats_getMostVisited(5,'<li>','</li>');?>
        </ul>
    </li>

    Grüsse

    Wie versprochen, hier nun der Link zu meinen Top5 und eine Beschreibung hier im Forum:

    - WordPress und Plugins immer aktuell halten, dabei so wenige Plugins wie wirklich nötig einsetzen.

    - Neuen Benutzer mit neuer ID anlegen und Standardbenutzer 'admin' löschen, verhindert MySQL-Injection-Versuche mit Standardwerten. Das Passwort des Benutzers sollte stark sein und ab und an geändert werden.

    - WordPress Tabellennamen-Präfix ändern, bestenfalls VOR der Erstinstallation, danach wird es vor allem für neue Benutzer im Bereich WP/MySQL etwas komplizierter. Es existiert auch ein Plugin dafür das aber den Comments nach nur manchmal funktioniert. Das Präfixändern verhindert ebenfalls Angriffserfolg über Standardwerte ( Präfix=wp_ ) die auch jedem Angreifer bekannt sind.

    - Datei- und Verzeichnisrechte niemals für die ganze Welt auf 'beschreibbar' setzen, immer abwägen wie viele Rechte überhaupt sinvoll sind.

    - Externen Zugriff auf PHP-Dateien mit .htaccess verbieten. Verhindert direkten Zugriff diverser Scripte/Robots auf WordPress-PHP-Dateien.

    Grüsse

    wenn ich ein wp blog mit 35 und mehr tipps absichern müsste, dann hätte ich auf ein wp-blog keine lust mehr!


    Das ist ja auch nur eine zusammenfassende Liste möglicher Absicherungstechniken, niemand sagt dass man das tun muss.

    Nach den Diskussionen hier und in anderen Threads schreibe ich auch gerade an einem Ergänzugsartikel zu einigen wenigen Tips die man bherzigen KANN wenn man möchte.

    Was sind inoffizielle Quellen? Auf wordpress.org gibt es das Pluginverzeichnis, die eingestellten Plugins kommen auch 'nur' von den Autoren und werden von diesen verwaltet.

    Zitat

    Ich denke auch kaum, das Profi-Hacker Interesse an einem privaten Blog haben.

    Profi-Hacker wohl nicht, in meinem eigenen, kleineren Blog sind die Logfiles trotzdem voll mit irgendwelchen automatisierten Angriffsversuchen. Nicht ohne Grund tauchen hier immer wieder Threads mit dem Thema 'Hilfe, ich wurde gehacked' o.Ä. auf.

    Zitat

    einfach wenig plugins (offizielle quellen)nutzen und immer die aktuelle wp version nehmen.

    Das ist alles? Nein, ich denke mit ein paar zusätzlichem Massnahmen könnten auch potentielle Sicherheitslücken schon VOR einem WP/Pluginupdate geschlossen werden. Man muss es wirklich nicht übertreiben, aber ein paar Sicherheitsmassnahmen schaden auch nicht.

    Hallo volumana. Danke für den Link oben. Das Problem mit der grossem Menge an Informationen ist mir auch aufgefallen, wie soll man da (v.a. als jemand der/die sich noch nicht so gut mit WordPress/PHP/Servern/Sicherheit usw auskennt) die wichtigsten Sachen herausfiltern. Ich arbeite gerade an einer Zusammenfassung der (für mich subjektiv) wichtigsten Hinweise, wenn veröffentlicht gebe ich nochmal Bescheid.

    Grüsse

    Auch das Duplicate Content Problem darf nicht vergessen werden, auch wenn im GoogleBlog geschrieben wird man hätte das Problem im Griff - abgesehen vom moralischen Aspekt würde ich wenn ich per Suchmaschine gefunden werden möchte keinesfalls Inhalte kopieren. Satzzitate gerne, aber keine grossteiligen Inhalte, egal unter welcher Lizenz sie stehen.

    Nun, irgendwie kann ich den Autor da schon verstehen. Aus der Erfahrung mit CyStats heraus kann ich sagen dass oft neue Features gewünscht werden, neben dem allgemeinen Bugfixing/Maintainen eines so einigermassen komplexen Plugins wie es auch Semmelstatz war kostet das unheimlich viel Zeit. Anderer Effekt ist das das Plugin irgendwie 'mit einem selbst verwächst', es ist eine 'eigene Kreation', weiss nicht wie man das besser ausdrücken kann. Würde selbst auch nur ungern die Entwicklung weitergeben wollen.
    Ausserdem war Semmelstatz scheinbar ein aussergewöhnliches Phänomen, es scheint es kein anderes Statistikplugin zu geben das auch nach Einstellung der Entwicklung noch für derartig viel Gesprächsstoff sorgt und gesucht wird - beeindruckend und bewundernswert.

    Grüsse

    Es gibt noch einen gezip-ten Download von Semmelstatz , der scheint aber nicht offiziell zu sein (Link in einer sitemap.xml.gz) da auf der zugehörigen Website nicht erwähnt, daher auch keinen direkten Link hier, möchte mich da nicht in die Nesseln setzen. Aber es gibt ihn. Einfache Suche hat geholfen.

    Grüsse

    Semmelstatz stellt Entwicklung ein | Web Analytics News

    Ja, hat er.

    Auch auf die Gefahr hin dass ich wg. Eigenwerbung gesteinigt werde (mir fehlt einfach die Werbung) - kann mein eigenes Plugin CyStats empfehlen :)
    - Allgemein übliche Statistiken
    - BounceRate
    - Referer
    - Suchworte intern/extern
    - Meistgelesene Posts/Tags/Kategorien
    - Template Tags
    - ...

    Wird durchgehend weiterentwickelt.
    WordPress › CyStats « WordPress Plugins

    Wenn so etwas nicht erwünscht ist bitte Bescheid geben, wird dann sofort wieder herausgenommen.

    Grüsse

    Hast du den Code aus einer Anleitung in einem WP Blog kopiert? Möglicherweise passen einfach die Hochmommata ' nicht, habe einfach mal alle vorkommenden seltsamen Hochkommatavarianten in ein einfaches ' umgewandelt und der vorher angezeigte Syntaxfehler (unter Linux einfach mit 'php -ln datei.php' geprüft) ist verschwunden.

    Edit: Ja, nach oben verlinkter Anleitung könnte das wirklich der Fehler sein.

    Grüsse

    Hallo, habe vor kurzer Zeit auch einen etwas umfangreicheren Artikel (Sicherheit / WordPress absichern) zu diesem Thema geschrieben - mittlerweile müssten neue WordPress-Features wie das Verschieben von wp-config.php und /wp-content noch hinzugefügt werden - vielleicht hilft er ja auch etwas weiter.

    Ganz allgemein ist WordPress wie alle dynamischen CMS natürlich potentiell angreifbar, durch die schon fast unüberschaubare Anzahl verfügbarer Plugins wird natürlich auch die Anfälligkeit bzw. Wahrscheinlichkeit für Sicherheitslücken für Angriffe erhöht - je weniger Plugins/Themes installiert sind desto geringer ist die Wahrscheinlichkeit für ein Sicherheitsloch.

    WordPress selbst ist sehr schnell was Sicherheitsupdates angeht (sh. 2.6.2 z.B.), bei verwendeten Plugins und Themes kommt es natürlich auf die entsprechenden Autoren an - wurde mit dem Sicherheitsgedanken im Hinterkopf programmiert und entsprechende Grundregeln bedacht oder wird ein einfaches Script ohne z.B. weitere Überprüfung von Eingabevariablen verwendet dass potentiell schädlichen Code direkt in die Datenbank schreiben will, reagiert der Autor zügig mit einem Bugfix bei Bekanntwerden eines Sicherheitsrisikos etc...

    Mittels .htaccess lässt sich so einiges anstellen um Sicherheitsrisiken zu verringern, trotzdem - es kommt wirklich darauf an WIE heikel die Daten sind, ausschliessen kann man einen Exploit/Angriss/sonstwas sicher nicht.

    Grüsse

    Hmnja, lang ist's her :)
    Mittlerweile bin ich der Meinung das die Robotererkennung (gut/böse) ein ganz grosses Problem der Plugin-Statistiksysteme ist. Wenn das einigermassen funktioniert könnte man IMHO zumindest einen grob zuverlässigen Überblick über Besucherzahlen generieren, immer abhängig natürlich vom spezifischen Zeitintervall/Webseitentyp/Besucherverhalten. Ich glaube, jetzt wird's endgültig offtopic. Entschuldigung.

    :oops: Von 'nützlich' hab ich nichts gesagt.

    Aber ein Beispiel (eig. Interesse im Moment) wären z.B. die Http-Header und PHP $_SERVER/$_POST-Daten zwecks Spamerkennung/-blockung.
    Auch interessant ist eine Kombination aus Statistik/Besuchermonitor in verbindung mit einem Warnsystem (Harvesting/Scraping/Flooding -> Information des Admin und automatisches Blocken). Über die Serverlogfiles lässt sich das in mehr-oder-weniger Echtzeit nicht realisieren.

    Für eine Auswertung der Besucherinteressen/Ausgabe in den Beiträgen wäre (auf WP bezogen) die Kategorien/Tag/Beitrags-ID oder auch die internen/externen Suchworte interessant. Das lässt sich zwar zum Teil (Suchworte) auch mit den Server-Logfiles machen - die beinhalten aber auch 'nur' (gibt eben nicht mehr) die gleichen Daten (z.B. Request-URI) - die Auswertung muss wieder extern gemacht werden.

    Läuft also auf gleiches Procedere hinaus - Serverlogfiles/Statistiksystem speichern Daten - diese werden dann mehr oder weniger gut ausgewertet.
    Was ich damit eigentlich nur sagen wollte ist dass man bei den Serverlogfiles mit den Daten zurechtkommen muss die geliefert werden, über ein Script hat man etwas mehr Freiheiten. Dafür sind die Logfiles serverschonender und bieten z.B. auch die Dokumentengrösse (Trafficanalysemöglichkeit) mit an.

    In jedem Fall muss jeder selbst entscheiden was er gerne wissen möchte - das kann vom Statistik-Fetischisten über den Puristen (so wenig Info wie nötig) bis hin zu jemandem den das überhaupt nicht interessiert gehen. Genaue und korrekte Besucherzahlen sind eine Frage des Zählsystems und nicht realisierbar, die Einzelzugriffe schon.

    Grüsse

    Nachdem noch keine Antwort da ist - habe letzte Nacht aus Interesse bissl gegoogelt - und nichts passendes gefunden.

    Da die Kriterien gleichwertig zu sein scheinen (Stadt/Preisklasse/...) würden sich Tags gegenüber verschachtelten Kategorien anbieten. Es gibt Plugins die die Suche auf 'nach Tag' erweitern, scheinen aber entweder Probleme zu haben oder die Suche auf einen Tag zu begrenzen.

    Andere Variante wäre ein neu zu schreibendes Plugin welches die Custom Fields der Beiträge durchsucht - man gibt jedem Beitrag Custom Fields für die Kriterien mit, diese lassen sich dann nebenbei auch schön einfach auslesen und darstellen, z.B. als Übersichtstabelle - und schreibt eine Suchfunktion die das Auswählen existierender Kriterien (also Custom Tags) z.B. per Dropdown Menü ermöglicht. Soetwas scheint es aber noch nicht zu geben.

    Grüsse

    Die Server-Logfiles haben den Vorteil dass sie automatisch geschrieben werden (keine zusätzliche Serverbelastung) und Zugriffe auf SÄMTLICHE Dateien aufgezeichnet werden. Durch diese Informationen lassen sich unter Umständen Bots von Besuchern besser unterscheiden - warum z.B. sollte ein angeblicher MSIE 6.0 ausschliesslich 20 Beitrags-URLs aufrufen nicht aber die zugehörigen CSS/JS/Bilddateien - muss ein Bot sein.

    Nachteil ist dass die Informationen limitiert sind - über Scripte lassen sich beliebige Informationen und Auswertungen speichern.

    Zitat

    halt nur sinnvoll vorverarbeiten und richtig interpretieren


    Und das ist der Knackpunkt - mit 'nur' ist es nicht getan, das ist ein komplexes Themengebiet und ein Statistiksystem kann nicht eben 'nur' mal schnell und simpel geschrieben werden.
    Zwecks der Besucherzahlauswertung - auch bei den Serverlogfiles ist die errechnete Anzahl abhängig vom verwendeten System/Algorithmus mit o.g. Variablen - macht also keinen grossen Unterschied in der Zuverlässigkeit der Angaben.
    Schönes Beispiel was dahinter stecken KANN: Web-Robots Erkennung: Inhalt