DDoS Abwehr Updated

Vorwort:
Synflood ist eine sehr häufige Angriffsmethode von Botnet-Besitzern, doch in Wirklichkeit ist es ein Kinderspiel derartige Attacken abzuwehren, denn ein Synflood erzeugt weder viel Traffic (Datenverkehr), noch ist er sonderlich schwer zu erkennen. Vorab möchte ich sagen, dass dieses Tutorial lediglich unter Linux funktionieren wird. Dieses Tutorial wurde sehr gründlich verfasst und macht es daher auch Neulingen möglich die folgenden Schritte zu tätigen.

Sysctl-Tuning u. Syncookies

Mit Hilfe der sysctl könnt ihr u.a. das Netzwerkverhalten bzw. die Kernelsettings konfigurieren.
ACHTUNG: Dieser Schritt funktioniert nur auch einem Dedicated Server, auf einem VPS (VServer) wird das sysctl-Tuning keinerlei Wirkung zeigen. In diesem Fall müssen Sie ihren Hoster bitten diese Konfigurationen in die sysctl.conf des Nodes zu schreiben.

Die Datei sysctl.conf befindet sich im Verzeichnis /etc, wir öffnen also diese Datei mit dem Befehl vi /etc/sysctl.conf.
Falls ihr mit dem Texteditor vi nicht vertraut seit, könnt ihr auch einen anderen Texteditor wie z.B. nano (nano /etc/sysctl.conf) verwenden. Wobei vi wesentlich mehr Funktionen bietet, aber diese Funktionen braucht ihr hier sowieso nicht.

Als erstes suchen wir die Zeile net.ipv4.tcp_synack_retries = 5, falls diese nicht existiert, müsst ihr diese Zeile irgendwo hinschreiben (wo genau spielt keine Rolle).
Wir ändern den Wert 5 auf den Wert 3.
Nun suchen wir den Wert net.ipv4.tcp_syn_retries = 5, falls diese Zeile nicht existiert, müsst ihr auch diese Zeile anlegen.
Diesen Wert ändern wir ebenfalls auf 3.

Hinweis: Sollte danach irgendwelche Verbindungsprobleme geben, könnt ihr den Wert auf 4 ändern.

Danach sucht ihr die Zeile net.ipv4.conf.default.rp_filter, ggf. fügt ihr diesen Text ein.
Wir ändern falls nötig die Zeile auf folgendes ab: net.ipv4.conf.default.rp_filter = 1
Somit wird IP-Spoofing unterbunden, weil die IP zuerst verifiziert wird.

Nun aktivieren wir die Option Syncookies, dies gestaltet sich sehr einfach.
Wir schreiben in die sysctl.conf folgenden Eintrag:
net.ipv4.tcp_syncookies = 1
Mehr müssen wir nicht machen.

Wenn nun Jemand versucht uns mit SYN-Paketen zu flooden, wird in /var/log/messages folgender Eintrag sichtbar sein:
possible SYN flooding on port 80. Sending cookies.
Wir können die messages geziehlt nach so einer Meldung filtern, das geht mit folgendem Befehl:
cat /var/log/messages | grep cookies.

Damit die Befehle wirksam werden, müssen wir folgendes in SSH ausführen:
sysctl -p
Oder einfach den Server rebooten.

IPtables

Wir können ein Limit von SYN-Verbindung per IP setzen, das funktioniert mittels IPtables.
Gebt einfach folgenden Befehl in SSH ein:

Code: Alles auswählen

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

Eingehende Verbindungen sind solange erlaubt, bis das Limit für diese IP erreicht wurde.

Zusätzlich kann man alle fragwürdigen Pakete filtern:

Code: Alles auswählen

iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Firewall

Es gibt viele Firewalls für Linux. Ich empfehle APF oder CSF.
Mit beiden kann man syn/udp traffic filtern.

Ich werde hier eine Anleitung für CSF schreiben.

Also laden wir mal CSF herunter, http://www.configserver.com/cp/csf.html.
Wir geben folgendes in die SSH Konsole ein:

Code: Alles auswählen

cd
mkdir csf
cd csf
wget http://www.configserver.com/free/csf.tgz
tar xfvz csf.tgz
cd csf

So, nun haben wir CSF heruntergeladen. Nun rufen wir das install script auf.
Wir führen also folgendes aus:

Code: Alles auswählen

./install.sh

Nun wird CSF installiert. Hier sind keine weiteren Eingaben mehr erforderlich.

Code: Alles auswählen

Note: The port details above are for information only, csf hasn't been auto-configured.

Don't forget to:
1. Configure the TCP_IN, TCP_OUT, UDP_IN and UDP_OUT options in the csf configuration to suite your server
2. Restart csf and lfd
3. Set TESTING to 0 once you're happy with the firewall

Installation Completed

[root@loadbalancing1 csf]#


CSF wurde in den Verzeichnis /etc/csf installiert. Wir wechseln also in den Verzeichnis /etc/csf.

Code: Alles auswählen

cd /etc/csf

Nun führen wir erstmal die csftest.pl aus. Dieses Script überprüft alle IPtables-Module. Für einige Funktionen sind „spezielle“ Module notwendig, die aber eigentlich auf jedem Server aktiviert sein sollten, falls nicht müsst ihr euren Hoster kontaktieren oder selbst aktivieren, falls möglich (auf einem VPS könnt ihr KEINE Module aktivieren).

Wir führen also folgenden Befehl aus:

Code: Alles auswählen

./csftest.pl

Nun können wir sehen ob alle Module funktionieren oder nicht.

Code: Alles auswählen

[root@loadbalancing1 csf]# ./csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing ipt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK

Wir sehen, wir können CSF voll nutzen!

Sollten die letzen 3 Module nicht geladen sein, ist das nicht weiters schlimm. Aber ihr könnt trotzdem euren Hoster fragen, ob er sie aktiveren kann.
Solltet ihr einen Root-Server haben, könnt ihr das selbst machen mit folgenden Befehlen:

Code: Alles auswählen

modprobe iptable_nat
modprobe ipt_owner
modprobe ipt_recent


Nun bearbeiten wir die Config.
Wir geben folgenden Befehl ein um die Config zu bearbeiten

Code: Alles auswählen

vi csf.conf

Als erstes ändern wir

Code: Alles auswählen

TESTING = "1"

in

Code: Alles auswählen

TESTING = "0"

Somit ist der Testmodus deaktiviert.

Falls ihr nur ein bestimmtes Netzwerkinterface schützen wollt, könnt ihr bei ETH_DEVICE = „“ zwischen den beiden „“ die Bezeichnung des interfaces angeben.
Das Interface kriegt ihr mit dem Befehl ifconfig heraus (z.b. eth0, venet0, etc.).
Im Normalfall ändern wir bei diesem Punkt nichts.

Bei # Allow incoming TCP ports, # Allow outgoing TCP ports, # Allow incoming UDP ports, # Allow outgoing UDP ports, könnt ihr die Ports öffnen, die ihr braucht.
WICHTIG: Falls ihr euer SSH Port geändert habt, müsst ihr es unbedingt hier eintragen. Ansonsten könnt ihr nacher nicht mehr auf den Server connecten.

Code: Alles auswählen

# Allow incoming PING
ICMP_IN = "1"

ändern wir in

Code: Alles auswählen

# Allow incoming PING
ICMP_IN = "0"

und

Code: Alles auswählen

# Allow outgoing PING
ICMP_OUT = "1"

ändern wir in

# Allow outgoing PING
ICMP_OUT = „0“

Somit ist der Server nicht mehr pingbar.

Nun zum nächsten Punkt.

Code: Alles auswählen

DROP_PF_LOGGING = "0"

ändern wir in

Code: Alles auswählen

DROP_PF_LOGGING = "1"

Nun kommen wir zur SYN-Flood-Protection von CSF.

Code: Alles auswählen

SYNFLOOD = "0"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

ändern wir in

Code: Alles auswählen

SYNFLOOD = "1"
SYNFLOOD_RATE = "300/s"
SYNFLOOD_BURST = "300"

Den Wert RATE und BURST kann man dementsprechend anpassen.
Allerdings sollte man den Wert nicht zu niedrig ansetzen, da ansonst normale Nutzer geblockt werden.
Am besten stellt ihr es so ein wie ich es oben beschrieben habe.

Nun gehen wir weiter zum nächsten Punkt.
Wir aktivieren die Portflood-dedection.
ACHTUNG: Falls das csftestscript euch sagt, dass das iptablesmodul „ipt_recent“ nicht funktioniert, dann könnt ihr diesen Punkt überspringen. Er wird bei euch nicht funktionieren!
Wir ändern

Code: Alles auswählen

PORTFLOOD = ""

in

Code: Alles auswählen

PORTFLOOD = "80"

Wir können natürlich auch ein anderes Port angeben. Aber für die meisten sollte das HTTP Port passen.

Den Rest können wir so lassen wie es ist.

So, dann legen wir uns noch einen Cronjob an, damit CSF nach 5 Minuten automatisch wieder gestoppt wird. Sinn ist es, falls der Server wegen einer fehlerhaften Config nicht mehr erreichbar sein sollte, CSF zu beenden. Somit könnt ihr dann wieder auf den Server und könnt den Fehler suchen.
Wir führen also folgenden in SSH aus:

Code: Alles auswählen

crontab -e

Dort schreiben wir folgenden hinein:

Code: Alles auswählen

*/5    *     *     *     *   root  /etc/init.d/csf stop

Nun starten wir CSF mittels folgenden Befehl:

Code: Alles auswählen

/etc/init.d/csf start

Wenn alles gut läuft, was anzunehmen ist, könnt ihr den Server weiterhin per SSH, HTTP etc. erreichen. Falls nicht, dann habt ihr keinen Grund zur Panik. Wir haben ja unseren Cronjob aufgesetzt (5min warten, dann zum Server verbinden und Fehler fixen).
Falls alles gut verlaufen ist, löschen wir nun den Cronjob. Wir geben wieder crontab -e ein und entfernen die entsprechende Zeile.
Danach starten wir CSF wieder mittels

Code: Alles auswählen

/etc/init.d/csf start.

Wenn nun etwas gedroppt wird, können wir das in /var/log/messages nachlesen.
Wir geben also folgendes ein:

Code: Alles auswählen

cat /var/log/messages

-> DADRUCH SEHEN WIR ALLERDINGS ALLE MESSAGES SEIT BEGINN

Oder um nur die letzen Einträge zu sehen

tail -n100 /var/log/messages

Wenn etwas gedroppt wurde, sieht das so aus:

Code: Alles auswählen

Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=89.246.39.194 DST=xxx LEN=53 TOS=0x00 PREC=0x00 TTL=120 ID=9633 PROTO=UDP SPT=33792 DPT=31337 LEN=33
Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=212.11.166.190 DST=xxx LEN=53 TOS=0x00 PREC=0x00 TTL=118 ID=1653 PROTO=UDP SPT=63301 DPT=31337 LEN=33
Firewall: *SYNFLOOD Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=84.28.138.21 DST=xxx LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=44778 DF PROTO=TCP SPT=33348 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Firewall: *SYNFLOOD Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=222.86.72.144 DST=xxx LEN=48 TOS=0x00 PREC=0x00 TTL=108 ID=31328 DF PROTO=TCP SPT=60263 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
Firewall: *UDP_IN Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=85.0.2.52 DST=xxx LEN=53 TOS=0x00 PREC=0x00 TTL=119 ID=25697 PROTO=UDP SPT=52874 DPT=31337 LEN=33
Firewall: *SYNFLOOD Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=80.1.252.54 DST=xxx LEN=64 TOS=0x00 PREC=0x00 TTL=35 ID=25462 DF PROTO=TCP SPT=3862 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Firewall: *SYNFLOOD Blocked* IN=eth0 OUT= MAC=SERVERMAC SRC=77.164.234.51 DST=xxx LEN=48 TOS=0x00 PREC=0x00 TTL=120 ID=48968 DF PROTO=TCP SPT=61402 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0

Bei MAC= steht natürlich eure Servermacadresse.

Syn-Deflate Script

Dieses Script checkt alle x Minuten wie viele SYN Verbindungen pro IP aufgebaut sind.
Sollte eine IP den Wert X überschreiten, wird sie gedroppt.
Dieses Script war original ein HTTP deflate script. Das Script wurde simpel umgebaut zum SYN deflate script.

Wir laden also das Script herunter und führen die Installation aus.

Code: Alles auswählen

cd
mkdir syn
cd syn
wget -O install.sh http://www.anti-hack.net/scripts/synd/install.sh
chmod 777 install.sh
./install.sh

Wir erhalten folgende Ausgabe zurück:

Code: Alles auswählen

Installing Syn-Deflate 0.1 alpha

Downloading source files.........done

Creating cron to run script every minute.....(Default setting).....done

Installation has completed.
Config file is at /usr/local/synd/synd.conf
Please send in your comments and/or suggestions to [email protected]

[root@loadbalancing1 syn]#

Wir öffnen die synd.conf mit folgendem Befehl (vi ggf. mit nano ersetzen):

Code: Alles auswählen

vi /usr/local/synd/synd.conf

Erstmal ändern wir

Code: Alles auswählen

##### How many connections define a bad IP? Indicate that below.
NO_OF_CONNECTIONS=10

in

Code: Alles auswählen

##### How many connections define a bad IP? Indicate that below.
NO_OF_CONNECTIONS=15

Ansonst werden eventuell echte Benutzer geblockt.

Nun ändern wir

Code: Alles auswählen

##### APF_BAN=1 (Uses APF to ban)
##### APF_BAN=0 (Uses iptables for banning ips instead of APF)
APF_BAN=1

in

Code: Alles auswählen

##### APF_BAN=1 (Uses APF to ban)
##### APF_BAN=0 (Uses iptables for banning ips instead of APF)
APF_BAN=0

Da wir ja kein APF installiert haben.

Danach speichern wir ab und erstellen einen Cronjob.
Wir führen folgendes aus:

Code: Alles auswählen

cd /usr/local/synd
./synd.sh --cron

Wir erhalten folgende Rückmeldung:

Code: Alles auswählen

Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]
Der Cronjob ist nun aktiv!

Auf Debiansystemen kann es sein, dass es hier zu einer Fehlermeldung kommt!
Sollte dies so sein, erstellen wir den Cronjob manuell, das geht so:
Wir geben crontab -e in die SSH Konsole ein und tragen folgendes ein:

Code: Alles auswählen

*/1    *     *     *     *   root  /usr/local/synd/synd.sh

Danach speichern wir und der Cronjob ist erstellt!

Gedroppte IPs können wir mit diesem Befehl einsehen:

Code: Alles auswählen

iptables -L

Hier werden wir auch die CSF Regeln sehen!

Falls ihr die Iptables löschen wollt, müsst ihr folgendes eingeben:

Code: Alles auswählen

iptables --flush

Dadurch werden allerdings auch die CSF Regeln verworfen, also muss man CSF mittels /etc/init.d/csf restart neustarten.

Apache optimieren

Erstmal wechseln wir in unser Apache Verzeichnis. Normalerweiße finden wir Apache in /etc/apache2, aber das ist nicht immer so. Die Apache-config Datei ist meistens in irgendeinem von diesen Ordern:

/etc/apache2
/etc/apache2/conf
/etc/httpd/
/etc/httpd/conf

Nachdem wir im richtigen Verzeichnis sind öffnen wir die Config mittels vi oder nano.

Code: Alles auswählen

vi httpd.conf

Falls die httpd.conf leer sein sollte oder dort nur sehr wenig drinnen steht, dann müsst ihr die apache.conf öffnen!

Erstmal verringern wir die Konfiguration timeout:

Code: Alles auswählen

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 120

ändern wir in

Code: Alles auswählen

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 25

Danach suchen wir die Funtion KeepAlive

Code: Alles auswählen

KeepAlive Off

ändern wir in

Code: Alles auswählen

KeepAlive On

MaxKeepAliveRequests lassen wir auf 100.

Code: Alles auswählen

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 15

ändern wir in

Code: Alles auswählen

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 2

Und wir setzen HostNameLookups auf off (sollte sogar standartmäßig so eingestellt sein).

Nun kommen wir zu einer der wichtigsten Sache. Der MPM config. Um so mehr Ram ihr habt, um so besser wird Apache laufen. Apache ist generell sehr resourcenfressend.
Man kann keine MPM Config erstellen die auf jedem Server gleich gut läuft, denn es spielen viele Faktoren eine Rolle (CPU, RAM, Netzwerk, geladene Module, etc., etc.).

Wir nehmen als Beispiel diese Config:

Code: Alles auswählen

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

Ich kopiere einfach mal die Beschreibung von der offiziellen Apachewebsite:

Ein einzelner Steuerprozess ist für den Start von Kindprozessen verantwortlich, die auf Verbindungen warten und diese bedienen, sobald sie eintreffen. Der Apache versucht immer, mehrere freie oder unbeschäftigte Serverprozesse vorzuhalten, die zur Bedienung eingehender Anfragen bereit stehen. Auf diese Weise müssen Clients nicht darauf warten, dass neue Kindprozesse geforkt werden, bevor ihre Anfrage bearbeitet werden kann.

StartServers, MinSpareServers, MaxSpareServers und MaxClients regulieren, wie der Elternprozess Kindprozesse zur Bedienung von Anfragen erstellt. Im Allgemeinen ist der Apache sehr selbstregulierend, so dass die meisten Angebote die Voreinstellung dieser Direktiven nicht verändern müssen. Systeme, die mehr als 256 gleichzeitige Anfragen bedienen müssen, können MaxClients erhöhen, während Systeme mit begrenztem Arbeitsspeicher möglicherweise MaxClients heruntersetzen müssen, um den Server vor Flatterverhalten (Arbeitsspeicherinhalte auf Platte auslagern – und zurück) zu schützen. Weitere Informationen zur Feinabstimmung der Prozesserstellung sind in den Performance-Hinweisen zu finden.

Währen der Elternprozess unter Unix normalerweise als root gestartet wird, um sich an Port 80 binden zu können, werden die Kindprozesse unter einem weniger privilegierten Benutzer gestartet. Die Direktiven User und Group werden dazu verwendet, die Privilegien der Apache-Kindprozesse festzulegen. Die Kindprozesse müssen in der Lage sein, alle Inhalte zu lesen, die sie ausliefern sollen, sollten darüber hinaus jedoch so wenig wie möglich Rechte besitzen.

MaxRequestsPerChild bestimmt, wie häufig der Server Prozesse erneuert, indem er alte beendet und neue startet.

Wir müssen aufpassen, dass wir hier richtig rechnen, ansonst wird eventuell der gesamte RAM verwendet und ihr könnt nichts mehr am Server machen, da kein RAM mehr frei ist. MaxClient ist einer der wichtigsten Einstellungen.
Apache benötigt pro MaxClient etwa 12 MB Ram. Dh. wir rechnen den Wert den wir bei MaxClients sehen * 12, bei MaxClient 256 wären wir hier schon bei fast 3,5GB Ram.
Wir müssen beachten, dass das System, MySQL und andere Dienste ebenso Ram benötigt. Bei einem System mit, sagen wir mal 1GB Ram, setzen wir hier den Wert auf 50.
Die anderen Optionen wie MinSpareServers kann man ebenfalls anpassen, allerdings gibt es hier bereits genug Dokumentationen. Hier kann man eine Menge Performance rausholen.

Info: Beitrag ist noch in Arbeit!
Original von 13speedtest37
Mofifikation durch Tobias