Ddos Protection - Ideen für den Server

[christophkrner]

Hallo,

das die 0815-Attacken leider recht öfter vorkommen, wollte ich fragen, ob folgendes System, dass ich mir komplett selber ausgedacht habe,effektiv funktionieren kann:


Normalbetrieb:
1. Man besitzt verschiedene Nameserver, die alle auf die IP x zeigen
2. IP x ist ein Masterserver, der Anfragen auf weitere Server im Netzwerk weiterleitet, die dann ihre Antworten im "Namen" vom Masterserver über die selbe Verbindung rausgeben. Bei Sessions wird der Master-Server jeweils informiert, damit der den Kunden richtig weiterleiten kann. Unbekannte Session kann er selber beantworten.

DDOS/DOS-Angriff:

1. Die Nameserver weißen auf jeweil eine "neue" IP, nachdem diese Floots, etc. rausgeworfen haben (mit Abstimmung zum Masterserver)
2. Der Masterserver bekommt eben über die "neue" IP Anfragen, die alte bleibt vorerst nur für "vertrauliche" Verbindungen bestehen. Unbekannte Verbindungen werden genullt.

Was haltet ihr so davon? Effektiv? Schwachpunkte?

[accC]

Also bekommt im Falle eines Angriffs der Server sowohl die vertraulichen, als auch die potentiell "gefährdenden" Anfragen, nur eben über 2 verschiedene IPs?
Wie soll das jetzt schützen? Der Traffic kommt dann so oder anders an und den muss der Server doch irgendwie bearbeiten. Die potentiell "gefährlichen" Anfragen könntest du dann verwerfen und nur vertrauliche Anfragen weiter behandeln, das wäre ein "Schutz" vor flooding..

[christophkrner]

genau.. die Nameserver sind sozusagen schon die Warnposten, die jeweils 20 Gigabit pro Sekunde abarbeiten können (da eben Nameserver kaum Resourcen pro Anfrage brauchen).

Die altbekannten IPs werden sozusagen genullt oder durch das System gelassen. Wenn das System die IP durchlässt, dann wird eine genauere Überprüfung des Systems vorgenommen... z.B. gleicher HTTP-Aufruf, wie schon 12x davor -> Sperre einfügen

Durch das Wechseln der IP beim Angriffmodus soll ein IP-basierter Angriff vermieden werden. (Jeder User lädt ja nicht die IP, sondern eben den Namen wie hier board.gulli.com)

So sollte doch ein DDos einigermaßen beherrschbar werden, oder? Das einzige Problem wäre dann das bekommen von neuen IPs, aber das ist ja letztendlich die kleinere Problematik.

Gibt's sonst irgendwelche Angriffsmöglichkeiten (außer Exploits, die werde ich seperat behandeln)

[Kugelfisch23]

IP x ist ein Masterserver, der Anfragen auf weitere Server im Netzwerk weiterleitet, die dann ihre Antworten im "Namen" vom Masterserver über die selbe Verbindung rausgeben. Bei Sessions wird der Master-Server jeweils informiert, damit der den Kunden richtig weiterleiten kann. Unbekannte Session kann er selber beantworten.

Dies entspricht - abgesehen davon, dass der `Masterserver` nicht ausschliesslich Last verteilt bzw. Client-Requests delegiert - einem NAT- oder MAT-basierten Loadbalancing-Setup - siehe etwa http://de.wikipedia.org/wiki/Loadbalancer#NAT_based_SLB ff. Ob dies in einem konkreten Einzelfall sinnvoll ist, hängt von den konkreten Anforderungen der zu hostenden Website ab.


Zur Abwehr von (d)DoS-Angriffe: Zunächst solltest du genau definieren, gegen welche Art von (d)DoS-Angriffen du eine konkrete Schutzmassnahme ergreifen möchtest. In aller Regel wirst du im Falle eines tatsächlichen Angriffs kaum umhinkommen, manuell einzugreifen und ggf. zu versuchen, `schlechte` Pakete automatisiert zu erkennen und in Folge möglichst früh (d.h. nahe am Gateway) filtern zu lassen. Das konkrete Vorgehen hängt jedoch stark von der Natur des Angriffs ab - z.B. kannst du im Falle eines Layer-7-Angriffs aufgrund der etablierten TCP-Verbindungen davon ausgehen, dass die Absender-IP-Adressen authentisch sind und demnach nach Erkennen eines `schlechten` Pakets fortan als Filtermerkmal nutzen, während dies für einen SYN-Flood-Angriff nicht gilt.

1. Die Nameserver weißen auf jeweil eine "neue" IP, nachdem diese Floots, etc. rausgeworfen haben (mit Abstimmung zum Masterserver)

Wie soll dein Nameserver `Floots, etc.` erkennen? Abgesehen von der grundsätzlichen Problematik einer automatisierten Erkennung von `schlechten` Paketen: Bedenke, dass Hostnamen üblicherweise über rekursive DNS-Anfragen an den im System eingetragenen Nameserver (nicht iterativ durch das System selbst) aufgelöst werden. Dies hat insbesondere zur Folge, dass der Host, welcher deinen Nameserver kontaktiert (etwa ein Nameserver eines ISPs), nicht mit dem Host identisch ist, der die rekursive DNS-Anfrage gestellt hat und in Folge eine Verbindung zur zurückgelieferten IP-Adresse aufbaut.

Ein weiterer Punkt ist die sinnvolle Cachebarkeit von DNS-Antworten. Abhängig von der von dir ausgelieferten TTL des A-RRs wird sowohl der Client als auch der von ihm verwendete Nameserver das Ergebnis der DNS-Abfrage im Cache halten und den autoritativen Nameserver nicht erneut kontaktieren. Um dein Konzept zu realisieren und im Falle eines (d)DoS-Angriffs zeitnah andere Antworten ausliefern zu können, müsstest du die TTL massiv reduzieren, was im Regelbetrieb kaum sinnvoll wäre.