Page Restrictor v0.08 FREE DOWNLOAD

Nachdem die Hemmschwelle sich fuer den Download per eMail zu melden doch zu hoch zu sein scheint, laeuten wir hier mal eine kleine Testphase ein und bieten den Page Restrictor v0.08 fuer jeden (damit aber leider auch den boesen Buben!!) zum freien Download an:

DOWNLOAD Page Restrictor (FREE) - Mitarbeit extrem erwuenscht!!

Nach dem Download bitte UNBEDINGT im Quelltext nachlesen wie das Script installiert wird! Sonst funktioniert es, bzw. der Auto Updater nicht!

Wenn der Code jetzt schon frei fuer jeden einsehbar ist, moechte ich doch wenigstens um folgendes bitten:
1. Code Review - Code in Ordnung oder wo liesse sich noch etwas verbessern?
2. Performance Review - haeufig (!) durchlaufener Code - wo liesse sich evtl. die Performance erhoehen (nicht im outRestrictMessage, dort macht es keinen Sinn)
Feedback entweder als Mail an PRES06 (at) airport1 [.] de - oder hier als Kommentar

Mit ausdruecklicher Bitte um Feedback und voller Erwartung,
Airport1

Weitere Nutzer des Page Restrictors sind:

foren4all
j4p4n
unico-leder

und 4 weitere Domains, die nicht genannt werden moechten

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Konzeptionelles Problem bei bot-traps ist, dass JEDER Zugriff bewertet wird. Als spam oder anderweitig negativ kann aber doch ernsthaft nur bewertet werden, wenn eine Vielzahl an Zugriffen pro Zeiteinheit erfolgen. Ausserdem kann man mit diese Event-getriggerten Methode NICHT die zahlreichen Sauger von dial-in-Zugaengen feststellen, die die Useragents normaler Browser nutzen. Um diese Sauger auszuschliessen, ist es zwingend notwendig, eine Zaehlung der GET-Zugriffe je Zeiteinheit verbunden mit der Festsetzung eines Limits zu machen.

Fazit: eine bot-trap kuemmert sich zu sehr um das "Rauschen" im IP-Verkehr, anstatt sich auf die wirklichen Boesewichte zu konzentrieren.

#1 ackermann (Homepage) am 20.06.2006 15:00 (Antwort)

Leecher die ihren UA aendern (doch ZUM GLUECK wissen nicht alle wie) und mit Dialin arbeiten sind mit PRES kaum zu fassen. Dazu hatte ich auch schon ein extra Script vor.

#1.1 Airport1 (Homepage) am 20.06.2006 16:07 (Antwort)

meine admin hilfe: "ferner hat XXX seit start der Ã¼berwachung mittels tcpdump rund 440.000 !!!! http-Verbindungen zu edona.de aufgebaut.

gehÃ¶rte edona.de zu dieser pagerank geschichte ?"

#2 red1 am 21.06.2006 16:00 (Antwort)

edona gehoert dazu, ja. Allerdings sind die 440000 ziemlich total ueberzogen. Laut meinen Log Files kommst Du hoechstens auf ca. 100 Update Downloads. Der Zufallsgenerator Auto Updater wird halt ca. 1mal pro 1000 Besucher ein Update versuchen..

#2.1 Airport1 (Homepage) am 21.06.2006 16:03 (Antwort)

NACHTRAG: Vielleicht hast Du ja den PR Balken bei Dir eingebaut. Der wird natuerlich pro Besucher aufgerufen, wenn Dein Admin dann die IP in den Logs reverse aufloest kommt evtl. edona raus. Anders kann ichs mir grad nicht erklaeren..

#2.2 Airport1 am 21.06.2006 16:14 (Antwort)

Ã¤h den balken muss man doch einbauen!? danke fÃ¼r die antwort.

#2.2.1 red1 am 22.06.2006 00:22 (Antwort)

Es ist sicherheitstechnisch sehr bedenklich, einfach die komplette .php Datei, welche man dann auch noch in seinen eigenen Scripts direkt "include(n)" soll zu Ã¼berschreiben. Besser wÃ¤re es, nur einen Datenblock mit Sperrlisteninfo zu Ã¼bertragen, am besten .gzipped. Man kÃ¶nnte den Datenblock fÃ¼r optimale performance (singelfile) nach ÃœberprÃ¼fung in die vorhandene Datei "einweben" (selbstmodifizierender Code mal anders).

#3 Michael Wegener am 21.06.2006 21:35 (Antwort)

Die Idee war urspruenglich es moeglichst klein und einfach zu halten, daher nur die eine Datei. Zudem hat das den Vorteil dass man auch Code Aenderungen einfliessen lassen kann. Zwei Dateien sind schon Mehrarbeit , und auch der Performance abtraeglich. Wobei, bzgl. Performance, koennte man in einer der naechsten Versionen die Sperrdaten im shared Memory vorhalten, das ginge dann noch schneller

#3.1 Airport1 (Homepage) am 21.06.2006 21:48 (Antwort)

Hi,
also von der Performance her dÃ¼rfte eine zweite Datei nur mit den Rohdaten keine Rolle spielen. In die kÃ¶nnte man auch das Updateintervall reinpacken, so dass das z.B. nur einmal am Tag erfolgt.

Dann kÃ¶nnteste allerings den eigentlichen Code nicht mehr so einfach updaten. Aber Du sendest ja (zumindest in der ersten Version von mir) die Versionsnummer und die Webseite mit. Anhand derer kÃ¶nnte man dem User eine Info zukommen lassen dass eine neue Version online ist. Also wie ein Virenscanner. Datafile lÃ¤uft automatisch und wÃ¤re dann auch von der Sicherheit her unproblematisch und das eigentliche Script per Hand.

GruÃŸ, Ingo

#3.1.1 Ingo (Homepage) am 22.06.2006 01:37 (Antwort)

Allerdings ist mit der zweiten Datei ja gar nicht viel gewonnen:
"Es ist sicherheitstechnisch sehr bedenklich" bleibt dann weiterhin, nun nur eben fuer die 2. Datei. Wer kein Vertrauen hat wird auch diese Variante nicht moegen.

Denn Parsen kommt ja gar nicht in Frage, wir wollen ja keine performance-kritischen Stellen.

Ich sehe einfach noch nicht die Vorteile einer 2. Datei, bislang nur Nachteile

Die Datei ueberschreibt sich zudem nur dann selbst und das in einem Rutsch (keine Haeppchen!) wenn die Datei GANZ SICHER komplett runtergeladen wurde (Pruefung ob Datei mit ?> endet).

#3.1.1.1 Anonym am 22.06.2006 11:01 (Antwort)

ich meine, man sollte eine 2. datei mit den StringblÃ¶cken herunterladen, diese kann man dann natÃ¼rlich auch 1x parsen und die "geparste" und bereinigte Variante abspeichern, dann ist da auch kein Performance oder Sicherheitsproblem.

Und eine Sache von Vertrauen ist es nicht, ich habe auch mal den kernelquellen meines Entwicklungsservers vertraut, nur dieser wurde eben kompromittiert. Das selbe kann mit dem Update-Server des Scripts passieren, ohne das der Betreiber dies beabsichtigt.

Bei einer neuen Version des Hauptprogramms kann ja eine kurze mail abgesetzt werden.

#3.1.1.1.1 Michael Wegener am 22.06.2006 21:48 (Antwort)

Genau das wollte ich mit meinem Post sagen

Und Sicherheitsprobleme gibt es da nicht, warum auch. Kann ja im .txt oder .dat Format sein. Die wird geparsed und entsprechend eingebunden. Da spielt eventueller fremder Code dann keine Rolle.

Und das mit der "kurzen Mail". Jep, das meinte ich mit "dem User eine Info zukommen lassen".

#3.1.1.1.1.1 Ingo (Homepage) am 24.06.2006 03:40 (Antwort)

Hallo, fange gerade an, mich mit diesem Thema auseinanderzusetzen.
Was ist z.B. mit
Snapbot/1.066.234.139.2xx und 38.98.19.115

#4 JÃ¶rg (Homepage) am 25.06.2006 09:27 (Antwort)

Laut Abakus (Frage an alle: sperren oder nicht??):

Snapbot macht Snapshots (bildliche Momentaufnahmen) von Internetseiten, welche dann auf snap.com auftauchen. FrÃ¼her nannte sich der Bot "snap.com beta crawler v0".

#4.1 Airport1 (Homepage) am 25.06.2006 13:05 (Antwort)

Kommentar schreiben

Name
E-Mail
Homepage
Antwort zu
Kommentar: Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.

Hier die Zeichenfolge der Spamschutz-Grafik eintragen:
BBCode-Formatierung erlaubt
Sie können [geshi lang=LANG][/lang] Tags verwenden um Quellcode abhängig von der gewählten Programmiersprache einzubinden
: Daten merken?
Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!