DDoS Protection?

S

Sadakazu

Well-Known Member
Moin moin...
ich spiele ja immernoch mit Jails und PF rum...
PF kann ja sogenannte bruteforce attacken in entsprechenden Tabellen schreiben, und diese verbindungen schlussendlich auch blocken....

Aber wie "sicher" funktioniert sowas bei eimen DoS oder DDoS Angriff?

Das sieht bei mir zur zeit in etwa so aus:
Code: 
[schnipp]
table <bruteforce> persist
[schnipp]
block quick from <bruteforce>
[schnipp]
pass in on $if proto tcp from any to any port $open_tcp flags S/SA keep state (max-src-conn 50, max-src-conn-rate 15/5, overload <bruteforce> flush global)

Reicht sowas aus um sich zumindestens ein bisschen vor einem DDoS zu schützen?
Ich denke mal wenn da ein großangelegter DDoS stattfindet mit ... ka einigen Zombierechnern glaub ich nicht das das wirklich wirkung zeigt oder?

Aber nen kleinen Angriff sollte das doch standhalten oder?

Was könnte sonst noch gegen DDoS hilfreich sein?
 
Informationen, die ein Angreifer bereitstellt (Quelladresse), in eine Blockliste zu schreiben, ist nicht sehr clever.
 
öhm warum nicht?
Die liste wird ja durch expieretables alle 24 Stunden wieder gelöscht.....
hätte ich oben vielleicht noch erwähnen sollen/können
 
Weil du dich damit ggf. selbst aussperrst, falls der Angreifer die Adressen kennt, von denen aus du dich einloggst.
 
TCM schrieb:
Weil du dich damit ggf. selbst aussperrst, falls der Angreifer die Adressen kennt, von denen aus du dich einloggst.
Zum Vergrößern anklicken....
Man kann ja recht einfach alle IP Adressen als Quelle durchspielen und schon ist die DB voll und kein Zugriff mehr da :D

Einen DDoS auf dem Server abzuwehren dürfte nicht klappen, man müsste vorher einfach ein Großteil des Traffics sperren.
Wenn jetzt allerdings jedes Paket einen random Absender hat, dann fällt mir auch nur noch warten ein (immerhin kostet den Angreifer der DDoS Geld und spekuliert darauf, dass Du einknickst bevor sein Budget für den Angriff verbraucht ist)
 
Ja gut, ich meinte ja.. einem richtigen DDoS kann man vermutlich selber nicht sehr viel entgegensetzen....
Mir gings nur um "so kleine kinder" die meinen sie sind die "oberhacker" und fahren ne DDoS attacke mit hping3 oder sowas...
Und mit der oben genannten config müsste ich das doch noch "aufhalten" können... oder? ^^
 
Wenn eine Attacke mit hping deinen Uplink oder deinen Server an seine Grenzen bringt hast du sowieso ganz andere Probleme.
 
Hallo,

ich möchte TCM und bananenBrot an der Stelle widersprechen. Auch wenn das Fälschen des Absenders in IP-Paketen einfach ist (sofern man die Anbindung durch einen Provider hat, der BCP38 nicht umsetzt), dreht sich der konkrete Fall um TCP-Verbindungen. Durch den 3-Wege Handshake sind gefälschte Absender-IPs kein Thema und somit das Risiko des sich-selbst-Aussperrens überschaubar.

Dazu auch ein Auszug aus den OpenBSD pf FAQ:

max-src-conn number
Limit the maximum number of simultaneous TCP connections which have completed the 3-way handshake that a single host can make.

@Sadakazu: Wie Du selbst geschrieben hast - solche Rate Limiter dienen dem Erschweren von Brute Force Angriffen, nicht mehr. (D)DoS, im Sinne von Volumenangriffen, kannst Du am Ende eines Ressourcen-Engpasses (=Deine Internet-Leitung) nichts entgegensetzen. Das kann wirkungsvoll nur an einer Stelle im Kommunikationspfad passieren, die über ordentliche Bandbreiten verfügt, d.h. im Backbone-Netz Deines Providers oder an dessen Upstream-/Peering-Punkten.

Gruß
 
Mir ging es da auch ehr um die "theorie"... ob ich mit der config es erreichen kann, das irgend nen möchtegern mit seinem super tollen Kali Linux den Server in die Knie zwingt....
Rein praktisch gesehen steht die Kiste eh bei mir zu Hause und dient zum spielen, experimentieren und lernen und es ist kein zugriff über das Inetnet möglich...
Da ich selber aber keine Ahnung hab wie man so eine "protection" austesten kann... war's hier ne allgemeine frage.....
Klar ich könnte jetzt auch mein Kali in ner VM starten und hping3 oder was es da nicht alles noch gibt starten....
Aber ich frag lieber vorher ... nicht das noch was kaputt geht ;)
 
Was mir nicht ganz klar ist ist, dass ja DOS/DDOS-Angriffe erwähnt wurden. Da hilft sowas nur wenig. Also wenn jemand einen DDOS fährt dann ist das state keeping eher ein Vorteil für den Angreifer. Der macht genug connections bis dein state table voll ist und das Ziel Denial of Service wäre erreicht.

Insofern wäre die Antwort auf die Frage ob das vor einem DOS schützt: Nein, er wird dadurch erleichtert.
 
Hilfreich könnte auch noch eine Regel wie folgende sein:
Code: 
pass in on $if proto tcp to $mail_server port 25 keep state (max 500)
Das verhindert zwar nicht, dass "normalen" User den Dienst ohne Einschränkung verwenden können aber der Server sollte dadurch nicht zwangsweise in die Knie gehen und sich verabschieden. Mit den Werten muss man halt spielen. Solche CDN's wie Cloudflare schreiben sich ja auf die Fahne in solchen Fällen hilfreich zu sein.

Gruss
 
Um das jetzt mal zb auf einen Gameserver zu projezieren....
wenn ich nen Gameserver mit sagen wir 50 slots aufsetzte und in der pf.conf (max 200) zb eingebe wäre ich praktisch auf einer sicheren seite?
gut aber dann wäre ja wieder die frage nach dem keep state... wenn ich Athaba richtig verstanden hab, wäre gerade das ja pracktisch eine einladung......
 
Eine state-table voll zu bekommen, ist garnicht so einfach. Wenn man nicht gerade mit einer soekris arbeitet, ist der uplink eher voll.
 
@double-p: Wenn ich mich nicht irre gibt es ein default-limit, erst mal unabhängig von Ressourcen. Ein state braucht 256 bytes an kernel memory. 10000 ist default. Das sind also unter drei MB.

Die kann man bei einem DDOS ala SYN-Flood schon erreichen. Also wenn du wirklich einen DDOS hast natürlich. Jetzt nicht unbedingt, das was man im Home-Network erwartet.

Das kann man mit set limits state <wert> auch höher schrauben. In dem Zusammenhang sind natürlich auch timeout-settings ein Thema - also wann der State wieder aus dem Table entfernt wird.

Worum's mir eigentlich ging ist, dass nicht nur der Service, sondern auch das Packet Filtering selbst der Limitierende Faktor sein kann - auf unterschiedliche Weise. Wenn man ein Limit erreicht, auch wenn es sich grundsätzlich von den Hardware-Resourcen ausgeht ist das Service genauso unerreichbar.

Kleine Anmerkung noch: UDP ist auch ein potentieller State-Entry in pf. (auch wenn das in der config ja kein Thema zu sein scheint)

Aber wie gesagt, DDOS ist eher weniger ein Angriff auf das Heim-Netzwerk und auch nicht unbedingt die "kleine Attacke".
 
ich denke mal ich poste eben meine komplette pf.conf.....
Code: 
##### Netzwerk Interface #####
if ="alc0"
ip=192.168.178.28

##### Tabellen #####
table <rfc1918> persist {10.0.0.0/8, 172.16.0.0/12, 224.0.0.0/5}
table <sshguard> persist
table <bruteforce> persist

##### Ports ######
icmp_types="echoreq"
open_tcp="{25,80,110,143,443, 25565}"
ssh="{2210}"

##### Jails #####
jails="{10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4, 10.0.0.5, 10.0.0.6}"
j2_tcp_udp = "{80, 443}"

db=10.0.0.1
www=10.0.0.2
mail=10.0.0.3
cache=10.0.0.4
svn=10.0.0.5
samba=10.0.0.6

#### Timeouts ######
set block-policy drop
set skip on lo0
set timeout { interval 10, frag 30}
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set timeout { adaptive.start 0, adaptive.end 0 }

set limit { states 10000, frags 5000 }
set loginterface alc0
set optimization normal
set require-order yes
set fingerprints "/etc/pf.os"
set ruleset-optimization basic

scrub in all fragment reassemble random-id

##### Forwards ######
rdr on $if proto tcp from any to $if port { 80, 443 } -> $www
rdr on $if proto udp from any to $if port { 80 } -> $www
rdr on $if proto tcp from any to $if port { 25, 110, 143 } -> $mail
rdr on $if proto tcp from any to $if port { 25565 } -> $db

##### NAT #####
nat on $if proto {tcp udp icmp} from $jails to any -> $ip

##### Blocks #####
block log all
block return
block in quick on $if inet from <rfc1918> to any
block in quick on $if proto tcp from <sshgurad> to any port 2210
block quick from <bruteforce>

antispoof quick for $if

##### Pass in Pass out #####
pass in on $if proto tcp from any to any port $open_tcp flags S/SA keep state (max-src-conn 100, max-src-conn-rate 15/5, overload <bruteforce> flush global)
pass out log on $if inet proto tcp from $mail to any port 25 flags S/SA synproxy state

pass out quick all keep state
pass in on $if inet proto icmp all icmp-type $icmp_types keep state
pass in on $if inet proto udp from any to any port 33422 >< 33626 keep state
pass in on $if proto tcp from any to any port $ssh flags S/SA keep state (max-src-conn 10, max-src-conn-rate 15/7, overload <bruteforce> flush global)

Und nochmal.... mir gehts hier um das theoretische....
Angenommen irgend ein vollhorst kommt auf die Idee.... hey... ich ärger den jetzt mal.... startet irgend ein billig DDoS tool und "greift den server an"......
also... ein angriff von einer einzigen IP/quelle...
Gegen einen richtigen DDoS mit einigen 100 Bots hat man vermutlich keine chance da der Traffik der da generiert wird ins unermessliche steigt... ohne massiv hohen uplink der den Traffik schlucken kann wird man da keine Chance haben.. soweit ist mir das klar....

Aber wie schaut es aus... wenn einer alleine Angreift? wäre ich damit "safe"?
 
Um dir auf deine theoretische Frage eine theoretisch Antwort zu geben: Fuer einen einzelnen Angreifer, der von daheim mit LOIC auf deine Kiste draufhaelt, brauchst du kein spezielles Ruleset.
 
Sadakazu schrieb:
startet irgend ein billig DDoS tool und "greift den server an"......
also... ein angriff von einer einzigen IP/quelle...
Zum Vergrößern anklicken....
dann ist das ein DoS und kein DDoS :-) und dagegen brauchst du wirklich keine extra Rulesets - schlimmstenfalls läuft dir da die Platte mit Logs zu wenn du kein logrotate machst.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben