• bist du webmaster oder sysadmin?
    als ersteres kannst du kaum was tun.

    ansonsten: es ist ein sehr komplexes thema
    google
    http://www.computec.ch/download.php?view.49
    http://www.networkcomputing.de/cms/8260.0.html

    Otto: Apes don't read philosophy. - Wanda: Yes they do, Otto, they just don't understand
    Beleidigungen sind Argumente jener, die über keine Argumente verfügen.
    «Signanz braucht keine Worte.» | «Signanz gibts nur im Traum.» 

    Das neue MTB-Projekt (PO, Wiki, Mitschriften, Ausarbeitungen, Folien, ...) ist online
    http://mtb-projekt.at

  • Ja ich bin Webmaster...

    Auf Server-Ebene sind ja Firewalls... DIe funktionieren auch sofern ....


    Die Angreifer greifen meine Seite auf Aplication-Ebene; in dem sie pro sekunde mehrmals die Ip ändern per Angriffe die Bandbreite der Seite lahm legen...


    Meine überlegung war so...

    Mittels PHP schaue ich mal ob COOKIES aktiviert sind...
    Dann erzeuge ich eine SESSION-ID Nr.

    Wenn cookies aktiviert sind dann lege ich die SESSION-ID per cookie ein (für eine Stunde).
    Und weiters lege ich für 5-10 sekunden eine weitere Session an die dem User verhindert sich eine neue Seission ID hollt. (Wenn er das trotzdem versucht dan soll er für 60 sekunden z.b: gebannt werden)...



    Das war mal ein kurzes Ablauf wie ich mir das überlegt habe.

  • Zitat von RoBzErOo

    Auf Server-Ebene sind ja Firewalls... DIe funktionieren auch sofern ....

    bezweifle, dass ein firewall gegen DDOS-attacken was ausrichten kann...

    Zitat von RoBzErOo

    Die Angreifer greifen meine Seite auf Aplication-Ebene; in dem sie pro sekunde mehrmals die Ip ändern per Angriffe die Bandbreite der Seite lahm legen...

    wieviele unterschiedliche IP-Adressen sind das? vielleicht die entsprechenden IP-adressen blockieren, wenn es nicht zuviele sind.

    Zitat von RoBzErOo

    Mittels PHP schaue ich mal ob COOKIES aktiviert sind...

    das ist schon mal recht umständlich...

    Zitat von RoBzErOo

    Dann erzeuge ich eine SESSION-ID Nr.

    macht üblicherweise PHP

    Zitat von RoBzErOo

    Wenn cookies aktiviert sind dann lege ich die SESSION-ID per cookie ein (für eine Stunde).

    in essig und öl?

    Zitat von RoBzErOo

    Und weiters lege ich für 5-10 sekunden eine weitere Session an die dem User verhindert sich eine neue Seission ID hollt. (Wenn er das trotzdem versucht dan soll er für 60 sekunden z.b: gebannt werden)...

    zwei sessions?

    zugriffe auf deine seite finden doch aber trotzdem statt, und was ist, wenn die angreifer keine cookies zulassen (als angreifer würd ich nämlich cookies sperren)?

  • Die werden die Bandbreite deines Servers auch so lahmlegen (können), auch ohne deine Applikation.

    Ich würd d. ganze Sache eher auf Server-Ebene versuchen zu lösen. Z.B. Eine ausgeklügelte Firewall-Konfiguration, die bei zu vielen oder verdächtigen Connections die IPs sperrt oder d. Verbindung abbricht.

    Otto: Apes don't read philosophy. - Wanda: Yes they do, Otto, they just don't understand
    Beleidigungen sind Argumente jener, die über keine Argumente verfügen.
    «Signanz braucht keine Worte.» | «Signanz gibts nur im Traum.» 

    Das neue MTB-Projekt (PO, Wiki, Mitschriften, Ausarbeitungen, Folien, ...) ist online
    http://mtb-projekt.at

  • tja wie ist eine verdächtige ip definiert...

    pro sekunde können die bis zu 100 mal ihre IP wechseln und mit jeder ip dann den Server angreifen....


    Das muss einfach euf Aplikation-Ebene geschenen ich muss das irgendwie hin bekommen dass sie nur einmal eine Verindung aufbauen... (Cookies setzen...?) dann wenn sie eine 2. verbindung inner halb von ein paar Sekunden öffnen dann per httacces oder was ähnliches blockieren.... Dann könnte ich auch noch per cron Jobs alles 5 Minuten die blockade aufheben...


    Bzw. ich brächte einen Server der täglich bis zu 1-10 Milionen Anfragen problemlos bearbeiten kann... Gegen DDdos absolut gesichert ist.... Kann bis zu 100-150€pro Monat Zahlen,... Traffic sollte mindestens 500GB/Monat,....

  • Du gehst davon aus, dass die Attacke gezielt passiert, oder?
    Wenn die dich abschießen wollen, dann greifen sie z.B. den Webserver an, dann fällt php aus und aus die Maus.
    Die Idee mit Cron Job ist subptimal, sag ich jetzt aus dem Bauch heraus.

    BTW. Nicht mal M$ ist vor DoS-Attacken gefeit, an absolut ist Illusion.

    Es gibt aber Dienstleister, die Server-/Traffic-Monitoring anbieten und bei Angriffen gezielt Gegensteuern können. Wenn du diese "absolute" Sicherheit brauchst, dann könntest du so eine Dienstleistung mit dem nötigen Kleingeld einkaufen.
    Ich schätze aber, die sind teurer als 150€.

    BTW2: Wenn du Webspace bei einem guten Provider kaufst, dann sollte er sich schon um die DoS - Attacken kümmern, nicht?

    Otto: Apes don't read philosophy. - Wanda: Yes they do, Otto, they just don't understand
    Beleidigungen sind Argumente jener, die über keine Argumente verfügen.
    «Signanz braucht keine Worte.» | «Signanz gibts nur im Traum.» 

    Das neue MTB-Projekt (PO, Wiki, Mitschriften, Ausarbeitungen, Folien, ...) ist online
    http://mtb-projekt.at

  • Pakete, die reingehen, gehen rein, selbst wenn die Firewall sie wegschmeißt und die Anwendung nie was davon sieht! Damit die Bandbreite dadurch nicht saturiert wird, müßte der Provider schon davor filtern.

    Wenn das aus beliebigem Grund nicht möglich ist, hilft nur riesige Bandbreite, um dennoch online zu sein - warum verwenden (oder verwendeten, bin über den aktuellen Status nicht informiert) Google, Yahoo, Microsoft, Apple etc. alle Akamai?

  • Zitat von Jensi

    warum verwenden (oder verwendeten, bin über den aktuellen Status nicht informiert) Google, Yahoo, Microsoft, Apple etc. alle Akamai?



    Weil sie genug Kohle haben :)

  • "Wir" wurden mal Opfer eines DDoS auf den Webserver, was aufgrund des Alters des Rechners (Cel400) schnell zum Quasistillstand des Apache und auch der restlichen Maschine führte.

    Mein Fix damals war, den Webserver auf Port 81 umzubiegen, und auf Port 80 einen eigenen Daemon (in Java ;)) zu hängen, der nichts anderes tut, bei jeder Connection einen HTML-Redirect auf Port 81 rauszuschießen und die Connection wieder zu schließen. Legitime User konnten somit locker-fröhlich weitersurfen, alles andere belastete den Apache nicht weiter => Load wieder niedrig. (quasi 7200->0, bin heute noch begeistert vom heldenhaften Einsatz vom Celeron und Java ;))
    Problem is halt nur, daß diese Variante nur für HTTP/HTML funktioniert, bzw. alle Protokolle, die Client-Redirects unterstützen...ansonsten is man meistens hilflos dem Angriff ausgeliefert, man kann maximal versuchen, mit dem ISP zusammenzuarbeiten, wobei auch die nicht viel tun können, da die IPs im schlimmsten Fall scheinbar Random sind.

    yast, SuSEconfig, apt-get and rpm - the 4 horsemen of the apocalypse

    Platform of insanity :: http://www.dose-xp.org

  • ich hoffe, der serveradmin schnappt nicht ein, dass ihm wer vorschläge unterbreitet... *bei firmen skeptisch bin*

    good luck!

    Otto: Apes don't read philosophy. - Wanda: Yes they do, Otto, they just don't understand
    Beleidigungen sind Argumente jener, die über keine Argumente verfügen.
    «Signanz braucht keine Worte.» | «Signanz gibts nur im Traum.» 

    Das neue MTB-Projekt (PO, Wiki, Mitschriften, Ausarbeitungen, Folien, ...) ist online
    http://mtb-projekt.at

  • Zitat von Wings-of-Glory

    ich hoffe, der serveradmin schnappt nicht ein, dass ihm wer vorschläge unterbreitet... *bei firmen skeptisch bin*

    good luck!




    danke ja das hoffe ich auch :shinner:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!