UBB.Developers Forums UBB.classic V6.4 - 6.7 Modifications International Support Floodschutz für Memberdatenbank

Huhu
Wir haben seid einiger Zeit bei uns jemanden der Floodet die Memberdatenbank, also er meldet sich wohl über ein Script bis zu 4000 mal an. Erst war es ein PHP Script.

Das haben wir so gelöst :
$Flooderarsch = "PHP";
$Flooderarschmsg = "Aufgrund von Spammings werden keine Anmeldungen mehr entgegengenommen. Bitte per Mail registrieren";

sub RegSubmit {
&HackChecker;

if ($ENV{'HTTP_USER_AGENT'} =~ $Flooderarsch ) {
&StandardHTML($Flooderarschmsg);
exit;
}

Nunja jetzt macht der Sack das anders, hmmm meine Idee wäre es das man sich nur einmal pro IP anmelden kann. Aber ich habe es nicht hinbekommen.

Greetz
ByteGhost

------------------

Homo homini lupus..."Der Mensch ist dem Menschen ein Wolf"

Wie meldet er sich den an? Mit der gleichen e-mail adresse oder läßt er zufällig eine eintragen? Nimmt er die gleiche, aktiviere die Überprüfung auf doppelte e-mail in der Administration!

------------------
Matze

Er nimmt immer eine andere E-Mailaddy

------------------

Homo homini lupus..."Der Mensch ist dem Menschen ein Wolf"

@ByteGhost:
in welchem zeitraum erstellt er denn die neuen user?
hast du mal geprüft, wie die url lautet, die als origin für dir registrierung im falle eines floods lautet?

ansonsten fällt mir auf die schnelle nichts ein, wie man sojemanden ausperren kann


Grüße aus FFM
joking

Ich weiss zwar nicht konkret, wie die Jungs vom strato-forum.de das Ubb insoweit modifiziert haben, dass der jeweils registrierte User vom Admin erst freigeschaltet werden muss (id/passwort werden auch via eMail zugesandt), zumindest ist dies wohl eine Möglichkeit, zu verhindern, dass neue User das Forum verspammen...

Ich würde mich auf jeden Fall mal mit dem Thema der x-forward-html-IP auseinandersetzen und ggbfs. Euren Provider bitten, ein entsprechenden Skript zu installieren, welches ebendiese IP in ein Logfile schreibt: somit habt Ihr nicht nur die reguläe IP, die zumeist auf den Proxy-Server hinweist (damit also keine vollkommene Identifizierung des Users zulässt) sondern die IP, mit der der entsprechende Provider den User komplett identifizieren kann und entsprechende Schritte einleiten kann.

Macht Euch doch auch mal schlau, ob's nicht gar zufällig div. Engines gibt, die dafür bestimmt sind, UBBs zu flooden - ich denke, sowas existiert sicherlich; sobald man die Funktionsweise erkannt hat, findet sich vielleicht ein Lösungshinweis?

Was sagt InfoPop eigentlich zu diesem Problem?

Hmmnnn... vielleicht ist auch 'ne einfache Lösung, mittels Javascript den 'Annehmen'-Button bei Euren AGBs mit 'ner Zeitsperre von 60 (oder mehr) Sekunden zu belegen?

Ein anderer Lösungsansatz wäre, das UBB dahingehend zu modifizieren, dass VOR dem RegistrierungsProzedere ein kleines 'passwort'-CGI integriert wird, welches per Zufall nummerische Passwörter erzeugt und ebendiese sofort per html ausgibt, sodass folgende Situation erscheint:

> registrieren
> Umleitung auf das passwort-CGI
> nummerischer 'Code' wird erzeugt
> html-output:
> "Wenn Du Dich registrieren willst, gib' bitte folgenden Code ein: 8262628"
> EingabeFeld für ebendiesen Code
> bei korrekter Eingabe Weiterleitung zu entsprechendem Registrierungsprozedere
...setzt natürlich voraus, dass der Flooder nicht weiss, wie man die commandLine beim UBb direkt aufruft, um sich anzumelden

Hmnnn....
grübel,
chris




------------------

Sinn des ganzen werden bestimmt nicht tausende von benutzernamen sein, sondern eher den Server mit Mitgliedsdaten voll laufen zu lassen. Schalt mal Coppa ein, vielleicht bringt ds sein Script durcheinander! Und das du erst freigeschaltet werden mußt bevor du schreiben kannst ist ebenfalls schon in ubb integriert: CP: Generelle Einstellungen - Überprüfung neuer Registrationen - Freischaltung aktivieren

------------------
Matze

was ist eigentlich keine schlecht idee, nur hindert das auch nicht am flooden, es dauert halt nur länger.

ich würde dieses PWD garnicht erst ausgeben, sondern es direkt (nicht über die Argumentliste) übergeben, denn alles was aus ausgabe erscheint kann ausgewertet werden.


Grüße aus FFM
joking

Hmnnn, vielleicht bringt ein kleines JScript Abhilfe ? Kennt vielleicht der ein oder andere von Euch von diesen seltsamen Wärz-Seiten: "Klicke erst auf einen Banner, dann wird der andere Button/Link aktiviert", Infos hier:
http://www.webaid.de/js/index.shtml?jav112.shtml
Integration in's entsprechende Ubb-Script sollte kein Problem sein.
Ist zwar für Banner gedacht, aber das kann man ja geschickt umwandeln á lá "Bevor Du auf 'Annehmen' klickst, drücke bitten DIESEN Button, um den RegistrierungsButton zu aktivieren" ...
Hmnnn.
chris


------------------

wenn ich mich richtig erinnere, wird das über cookies gelößt...
im zweifelsfall anzeige gegen "unbekannt" erstellen, wegem versuchtem DoS. über die IP kommt man dann auch an den user.

@GhostByte:
ist es denn immer die gleiche IP, oder wechselt die bei jedem angriff??? wenn die IP aus einem "kleinem" bereich kommt, würde ich diesem bereich sperren. dadurch blokiere ich zwar eventuell auch ein paar user, aber den störer auch.


Grüße aus FFM
joking

Hmmmm.
Das Problem ist dieser Typ ist ein Coder nehme ich an. Er hat sich jetzt schon mehrmals auf die neue Situation eingestellt.
Seine IP hab ich aber eben gerade durch das hier bekommen:
open (LIST, ">>$MembersPath/regfile.cgi");
print LIST "$UserName|!!|$ENV{'REMOTE_ADDR'}|!!|$ENV{'HTTP_USER_AGENT'}|!!|$ENV{'REMOTE_HOST'}n";
close (LIST);
chmod (0777, "$MembersPath/regfile.cgi");
Er scheint ein T-Online User zu sein. Erst mal eine E-Mail an abuse@t-online geschickt, mal schauen was die sagen.

Das Problem ist wie gesagt nicht das er Beiträge erstellt. Nein er meldet sich halt so oft an bis das UBB Feierabend sagt, weil alles durcheinander kommt. Ist klar bei 20.000 oder mehr Members dafür ist das UBB nicht auf einmal ausgelegt.

Wie gesagt, ich sehe als einzige Möglichkeit nur einen IP Blocker. Das jede IP nur einmal für eine Registrierung geht. Am besten noch mit Cookie setzen etc. Gab es so was nicht schon mal fürs UGB ?

Greetz
ByteGhost

------------------

Homo homini lupus..."Der Mensch ist dem Menschen ein Wolf"

Zwecks t-online: mach' Dir keine Hoffnungen, ich warte seit 2 1/2 Wochen auf eine Reply bzgl. Spams eines t-online-Users. Warum nicht auf der MainSite einen Hinweis posten, dass Flooden nichts bringt, da Ihr die Ip speichert und dementsprechende Schritte einleiten werdet? So haben wir in den vergangenen 12 Monaten 2 Spammer 'abgeschreckt' - jedoch - wie bereits erwähnt - wird auch t-online Euch nicht helfen können, da die IP nur auf den spezifischen ProxyServer hinweist, um einen User exakt identifizieren zu können, benötigt man die x-forward-Daten aus dem Header
chris

------------------

ich hab die erfahrung gemacht, das t-online der einzige provider ist, bei dem man schnell weiterkommt, wenn man unbedingt die adresse des users ermittelt werden muß (bei mir war leider gefahr im verzug )
ruf doch mal beim abuse-kontakt der telekom an, und laß dir erklähren, wie du vorgehen solltest, damit da auch etwas unternommen wird.

ich denke das geht schneller, wenn du gegen denjenigen eine anzeige erstattest wegen DoS.


Grüße aus FFM
joking

Hmnn, hat jemand Interesse, mit mir zusammen ein kleines AddOn zu coden, welches das iplist.cgi (siehe entsprechender Hack) ausliest und bei ggbfs. doppelter bzw. gleichlautender IP die Registrierung ablehnt..? Bin noch'n kleiner PerlDummy, gerade aus korrekte Auslesen von Files und Übernehmen von Variablen ist bei mir grundsätzlich buggy -
Wäre die wohl angenehmste Lösung,
chris



------------------

Wenn der Idiot das tatsächlich am Stück durchlaufen läßt, dann sollte sich das in den Sreverlog Dateien wiederfinden lassen. Sofrn er nicht die IP spooft, solltest du darüber alles weitere erfahren können. Ausserdem ist das auch schon kein dummerjungenstreich mehr, sondern wie joking andeutete, eine Straftat, wo du zur Not anwaltlichen Beistand einholen solltest, Kosten trägt der ermittelte Angreifer!!!

------------------
Matze

Das blöde an der ganzen Sache ist ja aber auch, da er sich mit wechselnder IP bei T-Online einloggt, das man ihn nicht generell mit dem IP-Stamm sperren kann! Schade!

Aber das mit IP-Spamming geht auch nicht so ganz! Ich meine damit das das UBB "Nein" sagt zur neuen Registrierung wenn zweimal die gleiche IP die Registrierung macht!

Dann geht er halt mal ganz schnell über einen anonymen Proxy-Server und das Problem ist wieder da, oder er macht sogar ein Multiproxy Script, welches sich dann bei der Registrierung jedesmal über einen anderen Proxy registriert, und schon ist das Problem wieder da!

Ich denke der Typ hat´s drauf, und dem kann man wirklich nur abhelfen!

Ich wüsste da schon was, ich hab nur keine Ahnung damit, ihn hacken! Ich hab gehört, das man via IP einen Hacken kann! Vielleicht lernt er daraus!

Mehr fällt mir dazu leider nicht ein! Sorrry

------------------
Chef @ Mp3 Kraut und Rüben, dem Info-Forum!!!
Mod @ UBBDev

Hmnnn, ich würde mal als vorläufigen Lösungsansatz vorschlagen:

a) Einbau von 'ner kleinen Zeitsperre und/oder
b) Integration eines kleinen Zusatzbuttons, der zuvor geklickt werden muss
c) die Modifikation, bei der Registrierung eines neuen Users die Ip in ein eigenes Logfile zu schreiben, sollte dahingehend verändert werden, dass noch das DATUM(+Uhrzeit) der Registrierung integriert wird; darauf basierend könnte man eben doch einen Ip-Vergleich coden, der bei gleicher Ip-Adresse die Registrierung verweigert; um den Spammer zu verwirren, sollte die FehlerMessage NICHT auf die identische Ip hinweisen, vielmehr irgendeinen FakeText. So wäre zumindest eine kleine Basis erschaffen; letztendlich verlangsamen diese o.g. Vorgänge das mehrfache Login-Prozedere so, dass mit'n wenig Glück der Spammer keine Lust mehr hat..? Anonymizer oder das Wechseln des Proxys sind nervig und zeitaufreibend
Hmmn, hat hier jemand von Euch ausreichend Ahnung, o.g. IpVergleichsSkript zu coden..?
Grüße,
chris

------------------

Sooo, Allen hat das Thema mal mit InfoPop erörtert und die Jungs kümmern sich drum; desweiteren wird MasterMind einen FloodSchutz für alle aktuellen UBB-Versionen coden; ich halte Euch auf dem Laufenden, Infopop bedankt sich soweit für die Info und wird versuchen, etwas gegen einen MemberFlood zu unternehmen..!
Liebe Grüße,
chris

------------------

Also ich habe ein bisschen gebastelt.
Nach langen suchen habe einen Floodschutz für UGB gefunden. Diesen Schutz habe ich mir mal zu Brust genommen und umgebaut für das UBB. Das UGBSchutzding ist ja dafür gedacht das man das Gästebuch nicht mit sinnlosen Beiträge zumüllt. Dabei wird die Eintragdatei der GB-Einträge nach der IP abgefragt. Das kann man doch auch für die Mitgliederdatenbank des UBB, mit ein paar Umbauten nehnen dachte ich mir:

$ip = $ENV{'REMOTE_ADDR'};
if (-e "$MembersPath/ipfile.cgi") {
open (FLOODPROTECT, "$MembersPath/ipfile.cgi") || die ("Fehlerchen");
}
@floodprotect = ;
close (FLOODPROTECT);
foreach $line (@floodprotect) {
@entryline = split(/||/, $line);
chomp $entryline[7]; # (Bugfix)
if ($entryline[7] eq $ip) {
&StandardHTML("Error! Hier wird nicht mehr gefloodet. Thank you!");
exit;
}
}
}
}

In dem Teil wo er die Anmeldung abgefragt hab ich des genacht;
open (LIST, ">>$MembersPath/ipfile.cgi");
print LIST "$ENV{'HTTP_USER_AGENT'}||$ENV{'REMOTE_HOST'}||$UserName||$RegEmail||$NextNumber||$ipn";
close (LIST);
chmod (0777, "$MembersPath/ipfile.cgi");

Das Ding haut auch super hin, nur jetzt das Prolem. Ich würde gerne noch eine Zeitabfrage einbauen. Das man sich mit der selben IP erst wieder 15 Minuten später anmelden kann. Jetzt macht das Ding ja alles dicht was bei der Anmeldung zweimal mit der gleichen IP kommt. Also muss ich die Datei alle 2-5 Tage von Hand löschen. Nicht das jemand mal vorbei kommt und sich reinzufällig mit der selben IP anmeldet wie vorher der Flooder und das nicht geht.

Ich Leute sagt was! *g*

Greetz
ByteGhost

------------------

Homo homini lupus..."Der Mensch ist dem Menschen ein Wolf"

Hallo ByteGhost,

deine lösung höhrt sich interessant an.

nur seh ich noch ein großes problem...

flooded jemand die memberdatenbank über einen anonymisierer hast du wieder verloren ich hab bei mir 4 anos ausgesperrt. der eine hat den IP-Bereich 63.64.0.0 - 63.127.255.255. alleine über diesen ano ist der schutz leider nicht sehr effektiv. ein anderes problem besteht, wenn man sich über einen bestimmten telekom-server einwählt (welcher genau das ist weiß ich nicht mehr genau)... der vergibt, so wie es aussieht, bei jedem abruf einer seite eine neue IP. deswegen würde der schutz da auch nicht greifen. diese IPs auszusperren ist auch nicht sinnvoll, da es sinnvoll, da nicht jeder user aus diesen ip-bereichen die memberdatenbank flooden will.


Grüße aus FFM
joking

------------------
UBB-Admin



ubbadmin@kids-hotline.de

Wäre es nicht sinnvoller, den vorhandenen Floodcheck zu erweitern, statt den Code weiter aufzublähen? Nur mal so als Frage in den Raum gestellt, da hast du einen Zeitintervall gleich integriert, und denk ausserdem an die WG's, die sich gemeinsam DSL (sofern vorhanden) teilen, da rennt der ene in das Zimmer des andern und erzählt von einer coolen Seite, und der Nachbar kann sich erst wieder in 15 Minuten anmelden...

Matze

mir ist noch etwas eingefallen...

• hänge ein feld mit der aktuellen zeit an und lasse für 30 sekunden von dieser IP keine neue registration zu. das sollte die möglichkeit die memberdatenbank zu sprengen einschränken.
• man könnte ja auch prüfen, ob man 15 registrationen von der selben IP innerhalb von 1 minute bekommt. wenn ja, wird diese IP erstmal für eine bestimmte zeit gesperrt. das sieht für mich eindeutig nach einem versuch des floodens aus.
• bei der anmeldung eines neuen users sollte geprüft werden, wo der user herkommt. kommt er nicht von der normalen adresse, von der ins Reg-Script gesprungen wird, ist IMHO zu 90% etwas faul und der neueuser will blödsinn machen.

hmmm... mehr fällt mir zu diesem thema immoment nicht ein. aber ich überlege weiter, da mich das sicher demnächst auch noch betrifft...


Grüße aus FFM
joking