Schutz vor unerlaubten Zugriff mit Hilfe von iptables

  • Hallo liebe Community,


    ich möchte euch hier gerne zeigen und erklären, wie ihr euren Server vor unerlaubten Zugriffen schützen könnt. Beachtet bei dieser Anleitung bitte, dass ich die Konfiguration am Ende nur den Zugriff auf alle notwendigen TeamSpeak 3 Server Dienste, sowie den SSH Dienst erlaubt. Alle weiteren benötigten Dienste müssen manuell hinzugefügt werden, damit sie wieder erreichbar sind bzw. "funktionieren".


    Inhaltsverzeichnis

    • Vorwort
    • Was ist iptables?
    • Was ist eine Firewall?
    • Konfiguration der Firewall


    • Vorwort
      Das nachfolgende Tutorial wird anhand von Standardports und Beispiel IP Adressen gezeigt. Zum Schluss des Tutorials erlaubt euer Server nur noch den Zugriff auf die TeamSpeak 3 Server Dienste, sowie eure SSH-Verbindung (falls dieser vorhanden ist).


      (Eingehende) TeamSpeak 3 Dienste sind folgende:

      • Sprachübertragung (Standardport UDP 9987)
      • Avatar (Standardport TCP 30033)
      • ServerQuery (Standardport TCP 10011)
      • Accounting (Standardport TCP 2008 )
      • TSDNS (Standardport TCP 41144)


      Den Unterschied zwischen TCP und UDP ist relativ einfach. Beides sind Protokolle für unsere Ports. UDP ist, sagen wir mal, das "dumme" Protokoll. Mit UDP werden Pakete einfach nur an das Ziel gesendet. Ob es dort jemals angekommen ist oder nicht, ist dem Protokoll egal. Wenn also ein Paket verloren geht, interessiert das keinen und das Paket wird auch nicht erneut gesendet. Bei TCP dagegen wird überprüft, ob das Paket auch angekommen ist oder nicht. Sollte das Paket nicht angekommen sein, wird das Paket solange erneut gesendet, bis es beim Ziel ankommt. So hat TCP natürlich den Nachteil, dass es langsamer als UDP ist, da es immer wieder überprüfen muss, ob jedes einzelne Paket angekommen ist oder nicht.


      Bei Spielen und Sprachübertragungen möchte man aber keine Verzögerungen haben. Hier möchte man "flüssig" spielen und hören können. Wenn hier mal ein von tausenden Pakete fehlt, fällt das (fast) nicht auf. Es kann sein, dass das Bild bzw. der Ton für eine sehr kleine Zeit nur mal kurz nicht ankommt und ihr ein kurzes Standbild bzw. einen Aussetzer des Sounds habt. Aber mal ehrlich: Wenn stört das bzw. fällt das wirklich auf? Beim Telefonieren ist das genauso. Wenn du ein, zwei Buchstaben vom Partner nicht verstanden hast, dann denkst du dir den Rest automatisch. Du fragst doch nicht nach, ob er/sie es dir nochmal sagen können... Oder etwa doch?! ?(


      Stellt euch vor, ihr würdet über TCP spielen und ein Paket würde dauernd verloren gehen: Ihr hättet ein dauerhaftes Standbild, da die einzelnen Pakete bei beiden Protokollen in der richtigen Reihenfolge erst wieder zusammengebastelt werden müssen. Wenn ihr gerade beim Paket 13 seid und das 14. nicht kommt, können auch die nachfolgenden Pakete 15, 16 ... nicht verarbeitet werden. Darum verlieren wir lieber das ein oder andere Pakete und nehmen "Laggs" bzw. "Aussetzer" entgegen, anstatts dauernd auf ein Paket zu warten. :thumbsup:


      Jut. Soviel zum Thema TCP und UDP. Machen wir mal weiter...


      Die ausgehenden Dienste interessieren uns nicht, denn wenn wir nichts rein lassen, kann auch nichts nach außen. Das kann man mit einem Haus vergleichen: Wenn ihr die Türen offen lasst und die Diebe rein kommen bzw. könnten, können sie euch etwas klauen. Somit wäre der Gegenstand dann auch nicht mehr im Haus, sondern irgendwo anders. Würdet ihr die Türen zuschließen, hätte der Dieb keine Chance ins Haus rein zu kommen und somit kann auch nichts aus dem Haus gelangen. (Abgesehen davon, wenn sie ein paar Fensterscheiben zerstören... :D) ;)


      Eine SSH-Verbindung ist eine Shell-basierte Remote-Verbindung, die von eurem lokalen Rechner auf einen Zielrechner des Ports 22 (= Standardport) aufgebaut wird. Somit kann zum Beispiel von Nürnberg aus auf den Rechner in China zugegriffen werden, sodass ihr ihn administrieren könnt. ;)
      Für weitere Details siehe auch bei Wikipedia: Wikipedia | SSH (Secure Shell)


      HINWEIS: NICHT Copy & Pasten! Unter Umständen sperrt ihr euch komplett vom System aus und kommt nur noch lokal - also wenn ihr direkt davor sitzt - oder per VNC-Konsole rein. Darum bitte sehr gut drauf aufpassen, was ihr macht!


      Eine VNC-Konsole ist übrigens das hier: Wikipedia | VNC (Virtual Network Computing)


    • Was ist iptables?
      Da wir das ganze auf einem Linux System machen, benutzen wir einfach die integrierte Firewall des Linux Kernels, welche ab dem Kernel 2.4 vorhanden ist. Um die Firewall zu verwalten, benutzen wir das Linux Paket "iptables".


      iptables ist ein Administrationstool für die IPv4 Paketfilterung und NAT. Es ist also keine eigenständige Firewall. Es ist nur ein Tool, das die Firewall "steuert" bzw. konfiguriert. ;)


      • Was ist IPv4?
        "Internetprotokoll Version 4" ist ein Protokoll für die Pakete, die über unser Netzwerk versendet und empfangen werden. Der Nachfolgender nennt sich übrigens "IPv6" und wird derzeit immer und immer mehr verwendet.


        Da das Thema jedoch zu komplex zum Erklären ist, verweise ich hier einfach auf die Wikipedia Seite. Wen es also interessiert und sich dazu mehr anschauen möchte, guckt sich das ganze bitte hier an: Wikipedia | IPv4


      • Was bedeutet "Paketfilterung"?
        Das bedeutet nichts anderes als: Wir schauen uns ein eingehendes bzw. ausgehendes Paket an und filtern es. Sprich wir entscheiden, was damit passiert. Wird es weitergeleitet? Wird es einfach ignoriert? Wird es verworfen und dem Absender wird Bescheid gegeben? Und und und...


        Das ist das, was wir für dieses Tutorial jetzt brauchen und verwenden werden. :)


        Weitere Details findet ihr wieder auf Wikipedia: Wikipedia | Paketfilter


      • Was bedeutet "NAT"?
        Das ist für uns irrelevant, da wir das nicht nutzen werden. Prinzipiell bedeutet es aber nicht mehr als, dass bestimmte Paketinformationen - auch Adressinformationen genannt - durch andere ersetzt werden, um verschiedene Netze zu verbinden. Du hast Daheim sicherlich einen "Router" stehen. "NAT" ist ein Teil, den dein Router für dich bzw. dein komplettes privates Netz übernimmt.


        Für weitere Informationen gibt es wieder Wikipedia: Wikipedia | NAT (Network Address Translation)


    • Was ist eine Firewall?
      Gut... Dann kommen wir zum Begriff "Firewall". Was ist eine Firewall eigentlich? Eine Firewall ist eine Art Schutzwand, die anhand von Paketfilterungen z.B. bestimmte Pakete durchlässt und andere nicht. So kann man sich zum Beispiel gegen Hacker und Angriffen schützen. Mit einer Firewall kann man auch einfache Zugriffe wie "Personen aus dem Netz Zuhause" dürfen meine Webseite sehen, während alle anderen, die nicht in dem Netz sind das nicht dürfen.


      Wichtig ist, dass eine Firewall keine Angriffe oder bösartige bzw. nicht erlaubte Zugriffe erkennt. Sie hat einfach eine vom Administrator - also dir - vorgefertige Liste mit Regeln, welche sie für jedes einzelne Paket abarbeitet. Sollte bei dieser Liste nur irgendeine Regel falsch, nicht zutreffend oder fehlend sein, wird das Paket entsprechend weitergeleitet bzw. -verarbeitet. Das heißt, dass durch Fehlkonfigurationen in der Firewall auch nicht gewollte Pakete ins Netzwerk bzw. zum Server gelangen.


      So kann es auch passieren, dass man bei Fehlkonfigurationen komplett vom System ausgesperrt wird und die Regeln erst wieder anpassen bzw. löschen muss. Anpassen und löschen ist leicht gesagt... Dazu muss man erstmal physisch vor dem Rechner stehen oder eine VNC-Konsole zur Verfügung haben. Ansonsten sieht es da schlecht aus. ;)


      Gut... Wer hierzu gerne noch mehr Informationen hätte, kann sich die schönen Bilder und Texte auf Wikipedia anschauen: Wikipedia | Firewall :D


    • Konfiguration der Firewall
      Nochmal als extrem wichtigen Hinweis, falls den ganzen schönen Text oben keiner gelesen hat:

      • Es werden Standardports und Beispiel IP Adressen verwendet
      • NICHT Copy & Pasten
        Ihr sperrt euch unter Umständen vom kompletten System aus!


      Dann fangen wir mal an...


      Schaut euch als aller erstes die Ports an, die euer TeamSpeak 3 Server aktuell verwendet. Das kann man zum Beispiel mit dem nachfolgenden Befehl auf einer Linux Konsole mit root Rechten tun:

      Code
      1. netstat -tulpen | grep -i ts3server


      Somit hat man zum Beispiel so eine Ausgabe:

      Code
      1. $ netstat -tulpen | grep -i ts3server
      2. tcp 0 0 0.0.0.0:30033 0.0.0.0:* LISTEN 2003 4760 2513/ts3server_linu
      3. tcp 0 0 0.0.0.0:10011 0.0.0.0:* LISTEN 2003 7754 2513/ts3server_linu
      4. udp 0 0 0.0.0.0:9987 0.0.0.0:* 2003 7751 2513/ts3server_linu
      5. udp 0 0 0.0.0.0:9988 0.0.0.0:* 2003 6868 2513/ts3server_linu


      Wie hier gut zu sehen ist, sieht man, dass folgende Ports verwendet werden:

      • TCP 30033
      • TCP 10011
      • UDP 9987
      • UDP 9988


      Wie wir wissen oder bei TeamSpeak.com nachschauen können, stehen die Ports für folgende Dienste des TeamSpeak 3 Servers:

      • TCP 30033 = TeamSpeak Avatar
      • TCP 10011 = TeamSpeak ServerQuery
      • UDP 9987 = Voiceport für die Sprachübertragung von TeamSpeak
      • UDP 9988 = Weiterer Voiceport für die Sprachübertragung von TeamSpeak


      Diese Informationen speichern wir uns jetzt so, wie es in der letzten Liste da steht, in ein beliebiges neues/leeres Text-Dokument.

    • 4. Weiterführende Konfiguration der Firewall
      Es gibt noch zwei weitere Ports, die der TeamSpeak 3 Server unter Umständen benötigt: Den "Accounting" Port. Bei jedem Start des TeamSpeak 3 Servers, überprüft der Server deine Lizenz und übermittelt diese Information an den Accounting-Server von TeamSpeak.com. Sollte diese Verbindung nicht zustande kommen, kann es sein, dass es zu Problemen kommt. Da es eine ausgehende Verbindung ist, sollte der Port uns eigentlich nicht interessieren. Es kann jedoch sein, dass TeamSpeak dem Accounting-Server sagt, dass sie jetzt ein paar Informationen zum Server haben möchten und dann sollten wir diese Verbindung natürlich zulassen. Daher nehmen wir auch diesen Port vorsichtshalber in die Regeln der Firewall auf. :)


      Wie gesagt: Den Port sieht man nur beim Serverstart kurz und dann ist er wieder weg... Laut TeamSpeak.com lautet der Port jedoch "TCP 2008". Also: Auch diesen Port mit in das Dokument! ;)


      Der zweite Port ist der TCP Port 41144, welcher für das TSDNS vom TeamSpeak 3 Server benötigt wird. Wer "TSDNS" nicht verwendet, kann den Port auch einfach weglassen. Wer es nutzt, sollte es in das Dokument übernehmen.


      Gut. Soviel zu den TeamSpeak 3 Server Diensten. Wie zum Anfang des Tutorials bereits erwähnt, erlauben wir auch den SSH-Zugriff, wenn einer existiert. Da Server normalerweise via SSH administriert werden, nehmen wir das auch mit auf.


      Auch hier gilt: Schauen wir einmal nach, auf welchem Port SSH lauscht:

      Code
      1. $ netstat -tulpen | grep -i ssh


      Somit erhalten wir eine Beispielsausgabe wie diese hier:

      Code
      1. $ netstat -tulpen | grep -i sshtcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 5565 1564/sshdtcp6 0 0 :::22 :::* LISTEN 0 5567 1564/sshd


      Somit notieren wir uns wieder folgendes im Dokument:

      • TCP 22 = SSH


      Gut. Somit haben wir auch bereits alles, um alle TeamSpeak 3 Server Dienste, sowie den SSH-Zugriff erlauben zu können. Euer Dokument sollte nun wie folgt aussehen - nur mit entsprechend passenden Ports natürlich:


      Okay... Dann loggen wir uns doch mal als root auf dem Linux Server ein und erstellen ein neues Shell-Dokument namens "firewall.sh", welches folgendes beinhaltet:

      Shell-Script
      1. #!/bin/bash# About: Firewall Regeln fuer iptablesiptables -Fiptables -Xiptables -N DENYiptables -A DENY -p tcp -m tcp -m limit --limit 30/sec --limit-burst 100 -m comment --comment "Anti-DoS" -j REJECT --reject-with tcp-resetiptables -A DENY -m limit --limit 30/sec --limit-burst 100 -m comment --comment "Anti-DoS" -j REJECT --reject-with icmp-proto-unreachableiptables -A DENY -m comment --comment "Alles andere ignorieren" -j DROPiptables -N SERVICESiptables -A SERVICES -p tcp -m tcp --dport 53 -m comment --comment "Erlaube: DNS" -j ACCEPTiptables -A SERVICES -p udp -m udp --dport 53 -m comment --comment "Erlaube: DNS" -j ACCEPTiptables -A SERVICES -p tcp -m tcp --dport 22 -m comment --comment "Erlaube: SSH-Zugriff" -j ACCEPTiptables -A SERVICES -j RETURNiptables -N TEAMSPEAKiptables -A TEAMSPEAK -p tcp -m tcp --dport 2008 -m comment --comment "Erlaube: TeamSpeak Accounting" -j ACCEPTiptables -A TEAMSPEAK -p udp -m udp --dport 9987 -m comment --comment "Erlaube: TeamSpeak Voiceport" -j ACCEPTiptables -A TEAMSPEAK -p udp -m udp --dport 9988 -m comment --comment "Erlaube: TeamSpeak Voiceport" -j ACCEPTiptables -A TEAMSPEAK -p tcp -m tcp --dport 10011 -m comment --comment "Erlaube: TeamSpeak ServerQuery" -j ACCEPTiptables -A TEAMSPEAK -p tcp -m tcp --dport 30033 -m comment --comment "Erlaube: TeamSpeak Avatar" -j ACCEPTiptables -A TEAMSPEAK -p tcp -m tcp --dport 41144 -m comment --comment "Erlaube: TeamSpeak TSDNS" -j ACCEPTiptables -A TEAMSPEAK -j RETURNiptables -A INPUT -i lo -m comment --comment "Erlaube: Loopback" -j ACCEPTiptables -A INPUT -m state --state RELATED,ESTABLISHED -m comment --comment "Erlaube: Related und Established Verbindungen" -j ACCEPTiptables -A INPUT -m comment --comment "Erlaube Standard Dienste" -j SERVICESiptables -A INPUT -m comment --comment "Erlaube TeamSpeak Dienste" -j TEAMSPEAKiptables -A INPUT -p icmp -m comment --comment "Erlaube: ICMP" -j ACCEPTiptables -A INPUT -m comment --comment "Ignoriere alles andere" -j DENYiptables -P INPUT DROP


      So... Zur Erklärung der "firewall.sh":

      • Alles was in Anführungszeichen steht, ist ein entsprechender Kommentar zur einzelnen Regel
      • iptables -F und iptables -X löschen als erstes alle Regeln und Ketten (= Chains) aus der Firewall raus, sodass die Firewall wie "neu" aufgesetzt ist.
      • iptables -N TEAMSPEAK erstellt eine neue Kette mit dem Namen "TEAMSPEAK". Hier werden alle Regeln für den TeamSpeak 3 Server reingepackt, um eine bessere Übersicht bei zu behalten und um andere Regeln nicht aus versehen so leicht kaputt machen zu können
      • iptables -A TEAMSPEAK -p [...] erstellt eine neue Regel für die Kette "TEAMSPEAK", welche am Ende der Kette "angehangen" (engl. append) wird ("-p tcp" steht dann entsprechend für das Protokoll, das verwendet wird - hier z.B. für "TCP")
      • ACCEPT bedeutet für eine Regel, dass das Paket passieren darf
      • DROP bedeutet für eine Regel, dass das Paket einfach ignoriert wird und keine Rückmeldung an die Quelle gesendet wird
      • REJECT bedeutet für eine Regel, dass das Paket verworfen wird und ein "Fehlerpaket" an die Quelle gesendet wird
      • RETURN bedeutet nichts anderes als "Zurück zur vorherigen Kette und schau dir die folgenden Ketten/Regeln an"
      • iptables -P INPUT DROP bedeutet, dass die allgemeine Regel für die komplette Kette "DROP" ist - so braucht man nicht tausende von Regeln für "DROP" erstellen
      • ICMP sind Ping-Pakete, welche auch nicht anders ausgenutzt werden könnten, daher kann man diese ruhig erlauben ;)
      • Zusätzlich erlauben wir noch "DNS" für die Auflösung von Namen wie "example.com" zur dazugehörigen IP-Adresse "93.184.216.119" (als Beispiel)
      • Zusätzlich erlauben wir noch "related" und "established" Verbindungen, sprich alle Verbindungen, die bereits bestehen oder mit einer anderen Verbindung verknüpft sind
      • Wer mehr als 30 Verbindungen pro Sekunde aufbaut, wird automatisch geblockt, da das nicht normal ist - siehe "Anti-DoS" Kommentar
      • Alle anderen Pakete, die auf keine Regel zutreffen werden einfach ignoriert :)


      Ich hoffe, ich habe alles wichtige erklärt und aufgezählt... Solltet ihr dennoch weitere Fragen zu den Regeln haben, beantworte ich diese natürlich gerne. :)


      So, um die Regeln jetzt auch verwenden zu können, müssen wir noch zwei Linux Pakete installieren: "iptables" und "iptables-persistent"


      Das geht zum Beispiel so:

      Code
      1. aptitude install iptables iptables-persistent


      "iptables" ist unser Administrationstool und "iptables-persistent" sorgt dafür, dass nach einem System-Neustart die Regeln automatisch wieder aktiv sind.


      Sobald beides installiert ist, führen wir folgendes aus, um die Regeln erstmal zu setzen:
      "firewall.sh" ausführbar machen:

      Code
      1. chmod +x firewall.sh


      Regeln setzen:

      Code
      1. ./firewall.sh


      Wenn keine einzigste Meldung ausgegeben wurde, war alles erfolgreich. Das Ergebnis kann man sich auch nochmal mit dem Befehl "iptables -L" anschauen:

      Code
      1. $ iptables -LChain INPUT (policy DROP)target prot opt source destinationACCEPT all -- anywhere anywhere /* Erlaube: Loopback */ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED /* Erlaube: Related und Established Verbindungen */SERVICES all -- anywhere anywhere /* Erlaube Standard Dienste */TEAMSPEAK all -- anywhere anywhere /* Erlaube TeamSpeak Dienste */ACCEPT icmp -- anywhere anywhere /* Erlaube: ICMP */REJECT all -- anywhere anywhere reject-with icmp-port-unreachableDENY all -- anywhere anywhere /* Ignoriere alles andere */Chain FORWARD (policy ACCEPT)target prot opt source destination...


      Wenn da viel "Zeug" drin steht und ihr die Kette "TEAMSPEAK" seht, passt alles. Funktioniert auch noch alles ordnungsgemäß? Versucht doch mal eine neue Verbindung zum TeamSpeak 3 Server auf zu bauen...


      Sollte alles funktionieren, können wir die Regel dauerhaft speichern, sodass sie nach einem System-Neustart auch automatisch wieder neugeladen werden:

      Code
      1. /etc/init.d/iptables-persistent save


      bzw. ab Debian 8:

      Code
      1. /etc/init.d/netfilter-persistent save


      Sieht dann so aus:

      Code
      1. $ /etc/init.d/iptables-persistent save
      2. [ ok ] Saving rules... IPv4... IPv6...done.


      Die Speicherung der Regeln findet ihr übrigens in den Dateien wieder:

      • /etc/iptables/rules.v4 (für IPv4)
      • /etc/iptables/rules.v6 (für IPv6)


      Wenn das getan ist, habt ihr eure Firewall erfolgreich konfiguriert. Das schöne an der Datei "firewall.sh" ist das, dass ihr sie nach belieben anpassen und erweitern könnt. Nach jeder Änderung müsst ihr dann nur nochmal "./firewall.sh" und "/etc/init.d/iptables-persistent save" ausführen, um die Änderungen auch aktiv zu speichern. ;)


    Gut, das war es dann auch schon wieder. Ich hoffe, ich konnte jemanden weiterhelfen. :)

  • Ich hätte da noch eine kleine erweiterung (ich hoffe, dass es nicht schon vorher von der Firewall Ignoriert wird, da ja sonst der rest auf DROP steht):


    Zitat

    iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
    #Neue Verbindungen auf SYN überprüfen, wenn nicht, dann DROPPEN


    Zitat

    iptables -A INPUT -f -j DROP
    #Erzwinge packetprüfung auf Bruchstücke


    Zitat

    iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
    #Fehlerhafte Packete DROPPEN


    Zitat

    iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
    #NULL packete DROPPEN


    Bin gespannt auf deine Meinung, ob diese 4 Regeln auch noch zusätzlich helfen können.

  • Sehr interessante Regeln, die durchaus Sinn machen. Ob sie jetzt spürbar helfen, kann ich leider nicht sagen. Das müsste man mal explizit testen.


    Aber prinzipiell würde ich sie mal mit reinpacken. Ich würde sie in die Chain DENY unter die beiden Anti-DoS Regeln packen. Wenn es nämlich ein DoS ist, wird er erst ausführlichst durch deine Regeln untersucht und später von den beiden Anti-DoS Regeln verworfen, was ziemlich blöd ist, da deine CPU dadurch umsonst gearbeitet hat. Daher erst auf DoS prüfen und danach entsprechend detaillierter untersuchen, sowie aussortieren. ;)


    Super Regeln - vielen Dank dafür! :)


    PS: Da sieht man auch mal wieder, was man alles mit iptables basteln kann. :)

  • Kein Problem, dafür ist dieses tolle Forum ja da :D


    Ich hätte da evtl. noch einen besseren DDoS Schutz anstatt deine 2 Zeilen am Anfang in deinem Script, kann man ja auch folgende nehmen:

    Code
    1. iptables -I INPUT -p tcp --dport $your_ts_port -m state --state NEW -m recent --set
    2. iptables -I INPUT -p tcp --dport $your_ts_port -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP


    ich weiß aber nicht, ob man die Regeln auch auf alle Ports zuweisen kann also ohne "--doport PORT"


    Denn diese blocken einen nicht so schnell rauß, wie deine 2 Regeln, die die Packete prüfen und zählen, ist zwar nett aber da komm ich nie per SSH rein. Wie hast du das gelöst?

  • Ich hätte da evtl. noch einen besseren DDoS Schutz anstatt deine 2 Zeilen am Anfang in deinem Script


    Die 2 Zeilen mögen vielleicht besser sein aber bringen tun Sie bei einem richtigen Angriff jetztendlich nichts.
    Das Thema DDoS wird ja momentan ohne Ende Diskutiert... Ich behaupte ja das du seitens von Software nicht viel erreichen kannst wenn richtige Angriffe kommen. Denn dann wird es so sein das eher deine Leitung verstopft ist und der Traffic gar nicht mehr zum Server vordringen kann. Und was nützt dir dann dieser Code? Nicht viel behaupte ich...

  • Ich hätte da evtl. noch einen besseren DDoS Schutz anstatt deine 2 Zeilen am Anfang in deinem Script


    Meine beiden Regeln ist kein DDoS Schutz, sondern ein DoS Schutz. Die helfen nur gegen einen Angriff vom selben Rechner. Bei mehreren wird das zwar ebenfalls helfen, aber wie @Pagian schon gesagt hat, kann man sich vor DDoS eben nicht wirklich bzw. kaum schützen. Wenn die Leitung zum Server hin schon voll ist, dann ist die eben voll. Da hilft auch keine Firewall am Server mehr. ;)


    Ich behaupte aber, dass meine beiden Regeln effektiver und einfacher als deine sind. Müsste man aber auch mal testen.^^


    [...] deine 2 Regeln, die die Packete prüfen und zählen, ist zwar nett aber da komm ich nie per SSH rein. Wie hast du das gelöst?


    Mit einer Regel, die explizit SSH Verbindungen erlaubt, sodass die DoS Regeln garnicht erst drauf zutreffen. ;)

    Code
    1. iptables -A SERVICES -p tcp -m tcp --dport 22 -m comment --comment "Erlaube: SSH-Zugriff" -j ACCEPT


    Du musst den Aufbau der Regeln in der richtigen Reihenfolge habe, denn ein Paket durchläuft einfach eine strikte Reihenfolge und die erste zutreffende Regel für das Paket wird genutzt. Wenn danach noch eine kommt, die ebenfalls zutreffen würde, würde das Paket diese Regel nie erreichen, da es davor bereits aus dem "Fluss gezogen" wird.

  • Mir ist eben noch etwas eingefallen:


    die ganzen Regeln mit ip6tables nochmals einfügen, garantiert dann auch, dass die DoS Angriffe reduziert werden die von IPv6-Adressen kommen.
    Da iptables und ip6tables ja 2 verschiedene Firewalls sind ;-)

  • Hi,


    hab mir diesen Beitrag durchgelesen und finde es super, dass du dein Wissen so teils.


    Da ich mich jedoch nicht so gut mit iptables auskenne und irgendwie kompliziert finde, würde ich gerne wissen ob man dies nicht auch mit ufw realisieren könnte.


    Dies soll auch ein Bitte sein, uns (all den da draußen die unsicher ihren TS3 betreiben und mir) eine Anleitung an die Hand zu geben die das Leben schöner macht. :D

  • Hallo,


    danke für das Feedback! :)


    ufw ist eine zusätzliche Software, die hintenrum die Regeln für iptables baut. Somit ist es also auch damit möglich, Firewall-Regeln zu verwalten.


    Leider kenne ich die Software nicht, wodurch ich mich erstmal einlesen und etwas rumprobieren muss. Aber eventuell kommst du mit dieser Anleitung hier bereits weiter und kannst uns dann ein Tutorial darüber verfassen. Wenn es in Ordnung ist, würden wir es dann auch in unsere FAQ mit aufnehmen. :)


    Neben ufw gibt es auch noch andere solcher Tools. Hier mal eine Liste der wohl bekanntesten und meist genutzten Softwares:

    • shorewall
      Shorewall allows firewall/gateway requirements to be described using
      entries in a set of configuration files. It reads those configuration
      files and, with the help of the iptables utility, configures
      netfilter to match these requirements.


      Shorewall supports a wide range of router/firewall/gateway applications,
      traffic shaping and almost every type of VPN.

    • pyroman
      Pyroman is a firewall tool written in Python for complex networks,
      but it can of course also handle simple single-host-single-link setups.
      .
      Interesting features:
      * Fast, due to use of iptables-restore for mass setting of rules
      * Rollback to previous firewall configuration on errors
      * Safety options to prevent mistakes in configuration (success confirmation
      prompt and/or scripted external verification)
      * Detailed error reporting
      * Lots of verification checks done before execution
      * Powerful yet clean configuration files (in Python and/or XML)
      * Designed for multiple hosts, firewalls, networks
      * Consistent firewalls for IPv4 and IPv6
      .
      Pyroman is inspired by Shorewall and FireHOL, but tries to improve upon them
      with respect to performance and ease of configuration.
      .
      Pyroman currently only configures iptables/netfilter firewalls, it does
      not include configuration utilities for setting up VPN or traffic shaping.
    • firestarter
      Firestarter is a complete firewall tool for Linux machines. It
      features an easy to use firewall wizard to quickly create a
      firewall. Using the program you can then open and close ports
      with a few clicks, or stealth your machine giving access only
      to a select few. The real-time hit monitor shows attackers
      probing your machine.
      .
      Firestarter is no longer developed and is missing some critical
      features such as IPv6 support, so users may be advised to look
      into more modern alternatives such as gufw.
    • firehol
      Generates generic firewalls with an extremely simple but powerful
      configuration language, enabling you to design any kind of local
      or routing stateful packet filtering firewall with ease.
      .
      Firehol does not support ipv6.
  • Code
    1. root@debian: /home/root # /etc/init.d/iptables-persistent save
    2. -bash: /etc/init.d/iptables-persistent: Datei oder Verzeichnis nicht gefunden


    iptables und iptables-persistent wurden installiert, alles ohne eine Fehlermeldung.


    Nun wird mir aber gesagt, dass die Datei oder das Verzeichnis nicht vorhanden sind.


    System ist ein Linux Debian 8 (Jessie) 64-bit minimal.


    Könnte mir da wer weiterhelfen?


    Da ich den Beitrag nicht bearbeiten kann:


    Die Datei iptables-persistent gibt es nicht mehr unter Debian 8 (Jessie), die Datei heißt nun netfilter-persistent.


    Info: iptables-persistent service has been split+renamed in debian 8 (jessie) · Issue #66 · example42/puppet-iptables · GitHub

  • Die Datei iptables-persistent gibt es nicht mehr unter Debian 8 (Jessie), die Datei heißt nun netfilter-persistent.


    Info: iptables-persistent service has been split+renamed in debian 8 (jessie) · Issue #66 · example42/puppet-iptables · GitHub


    Vielen Dank, @Punisher.biz! Ich habe dies in meinem Beitrag oben als Info mit eingepflegt.

  • @Sebbo hast du eventuell auch etwas sinnvolles gegen Portscans (z.b. nMap)?


    Würde diese gerne unterbinden, habe bereits mir ein paar Dinge durchgelesen und ausprobiert, bin aktuell hier gelandet:



    Dieser bringt jedoch leider nichts, ich habe danach erfolgreich meinen Server nach offenen Ports scannen können (nMap - Kali Linux).


    Die Regeln stehen vor den #Service Regeln.


    Gruß
    Punisher

  • Deine Regeln machen doch auch nichts, außer bei Treffern etwas in die Log-Datei zu schreiben. ;)


    Probier doch sowas hier mal:

    Code
    1. iptables -N BLACKLIST
    2. iptables -A BLACKLIST -m recent --name portscan --rcheck --seconds 86400 -j DROP
    3. iptables -A BLACKLIST -j RETURN


    Die Regel sperrt Portscans für 24 Stunden. Die Chain habe ich "BLACKLIST" genannt, weil ich persönlich da dann einfach alles rein tun würde, was man eben gerne mal blacklisten möchte. ;)

  • Leute, echt mal. Von solchen Aussagen sollte man sich nicht verrückt machen lassen. Es gibt gute Einsatzzwecke für eine Firewall auf dem System selbst, auch wenn manch einer behaupten mag, dass dem nicht so ist.


    Die Sicherheit von Services kann durch eine Firewall verbessert werden. Wenn ein Dienst von sich aus keine Unterstützung für einen "Slow-Mode", o.ä. bietet, kann man diesen mit einer Firewall nachrüsten. Sicherheitslücken in den Services selbst sind leider nicht so einfach abzusichern, aber das ist auch nicht der Sinn einer Firewall.


    Um es einmal aus meiner Sicht zu sagen, benötige ich eine Firewall für die folgenden Funktionen:
    1. logisches trennen von Netzwerken
    2. sperren von Zugriffen auf Services von bestimmten Netzwerken, falls es die Software selbst nicht unterstützt
    3. temporäre Sperrungen, bzw. implementieren eines "Slow-Modes", um gewisse Angriffsarten zu erschweren.


    Im Optimalfall sollte man allerdings die Firewall auf einem anderen System betreiben als den Service selbst. Bei kleineren Hostern, bzw. privaten Entusiasten ist dies leider in den seltensten Fällen möglich. Daher ist es zwar nicht optimal, aber noch immer ein legitimer Teil eines Sicherheitskonzepts, Paketfilter auf den Applikationsservern zu implementieren.
    Allerdings ist es nur ein Teil, und kann nicht als alleiniges Sicherheitsmerkmal eingesetzt werden.

  • Ich glaube einfach das viele Leute denken, dass zu einer Absicherung bzw. einem sicheren System eine Firewall reicht.
    Und ich denke genau hier setzt der Punkt von denen im Forum an.
    Ich finde das Beispiel mit dem Diskettenlaufwerk dort (warum auch immer Disketten) ganz gut:


    Zitat

    Eine Firewall ist genauso nutzlos wie ein Schloß für das Diskettenlaufwerk bei einem Server im Rechenzentrum.


    Was heist hier "nutzlos"? Wenn ich irgendwo ein Schloss anbringe erhöht es erstmal meine Sicherheit (natürlich vorrausgesetzt das ich es logisch anbringe und nicht nur davor anklebe). Wenn das Schloss aber erstmal Sitzt, dann macht es das für einen nicht gelernten schon mal schwer dieses Schloss zu knacken.
    Ein Profi hingegen kommt da natürlich mit leichtigkeit durch. Hier greifen dann aber wieder ganz andere Maßnahmen die man ergreifen sollte.
    Es ist aber erstmal, wenn auch eine kleine, Sicherheit gegen erstes Eindringen!
    Vorrausgesetzt hierbei ist natürlich immer die richtige Konfiguration der Firewall (eben das richtige anbringen des Schlosses am Laufwerk).


    Es ist einfach falsch zu denken das eine Firewall den Server, den Computer, oder was auch immer gegen jeden und alles Schützt. Es schützt auch nicht 100% gegen das, wovor es eigentlich schützen sollte. Der Markt entwickelt sich in einem hohen Tempo weiter und es gibt immer was neues. Es wird nie eine Software oder auch Hardware geben die gegen alles Schützt!


    In sage in diesem Zusammenhang auch immer gerne: "Wenn dir jemand Schaden möchte, dann schafft er das auch! Es ist ganz egal wie, und wenn er zu dir nach Hause fährt und deinen Server/PC kaputt haut. Die Frage ist nur wie lange er dazu braucht und vorallem was ihm die Mühe Wert ist, dir zu Schaden."


    Ich könnte jetzt noch Stundelang über dieses Thema schreiben/diskutieren (du kennst mich punisher). Aber ich denke mal das wichtigste habe ich hier gesagt (meine Meinung!).