Schutz vor unerlaubten Zugriff mit Hilfe von iptables

Hallo, falls du dich fragst, ob wir Teamspeak 5 Beta Keys haben, nein diese haben wir nicht und erhalten auch keine von Teamspeak. LG dein TScon Team
  • Mir ist gerade beim durchlesen was aufgefallen ;)


    Vorerst ich arbeite nicht direkt mit Iptables und das was mir durch den Kopf geht könnte also falsch sein dann bitte mich einfach mal aufklären ;)


    Code
    1. iptables -A DENY -p tcp -m tcp -m limit --limit 30/sec --limit-burst 100 -m comment --comment "Anti-DoS" -j REJECT --reject-with tcp-reset
    2. iptables -A DENY -m limit --limit 30/sec --limit-burst 100 -m comment --comment "Anti-DoS" -j REJECT --reject-with icmp-proto-unreachable


    Wäre es nicht besser wenn hier anstatt ein "REJECT" genutzt wird ein "DROP" an dieser Stelle?
    Sonst muss der Server auf jedes Paket dass als "DoS" erkannt wurde eine Antwort gesendet werden und das wird möglicherweise den Server unter anderem auch noch belasten.
    Weiters die Limits
    Sind die nicht ein wenig großzügig eingestellt worden?


    Derzeit nutze ich ein Limit bei mir von 10 und Burst von 15 und hatte ehrlich gesagt noch keine Probleme
    Läuft ein Webserver + TeamSpeak Server drauf

  • Code
    1. #blacklist
    2. iptables -A INPUT -s xxx.80.xxx.192/15 -j DROP


    Die IP-Range geht von xxx.80.xxx.192 bis hin zu xxx.80.xxx.207


    Muss ich da jetzt /16 oder /15 angeben? Es ist ja ein /16er Netz, aber die 192 ist ja nun schon mit angegeben, da bin ich mir etwas unsicher.


    Anyone?^^

  • Wie kommst du da auf /15 oder /16.


    Wenn ich mir das anschaue, wäre das eher /28
    Der Bereich 192.168.0.192 - 192.168.0.207 wird durch 192.168.0.192/28 beschrieben, um hier mal ein konkretes Beispiel zu nennen.


    /15 wäre eher 192.168.0.0 - 192.169.255.255
    /16 wäre dann 192.168.0.0 - 192.168.255.255


    Dazu bitte einmal die CIDR-Notation genauer betrachten, um die Definition besser verstehen zu können
    Classless Inter-Domain Routing – Wikipedia

  • Die X sollen nur die IP "zensieren". Anders so:


    xxx.80.124.192 bis xxx.80.124.207


    Wäre dementsprechend was für ein Netz?


    Gnarf.


    Oh, alles klar. Gut, jetzt gerafft + habe es falsch dargestellt bzw. die "Zensierung" war doof.


    xxx.80.124.192-xxx.80.124.207


    Wenn ich eine Range von xxx.80.124.192 bis xxx.80.124.207 blockieren möchte, dann muss ich eben xxx.80.124.192-xxx.80.124.207, richtig?


    Code
    1. #blacklistiptables -A INPUT -s xxx.80.124.192-xxx.80.124.207 -j DROP


    Jetzt verstehe ich dass mit den /16 etc. auch :genius:


    https://www.ripe.net/images/IPv4CIDRChart_2015.jpg


    oder eben auch /28,


    Code
    1. #blacklistiptables -A INPUT -s xxx.80.124.192/28 -j DROP


    Wenn ich das jetzt richtig verstanden habe.

  • Wäre es nicht besser wenn hier anstatt ein "REJECT" genutzt wird ein "DROP" an dieser Stelle?
    Sonst muss der Server auf jedes Paket dass als "DoS" erkannt wurde eine Antwort gesendet werden und das wird möglicherweise den Server unter anderem auch noch belasten.


    Ich bin der Meinung, dass REJECT besser ist als DROP. Ist aber denke ich auch Ansichtssache.

    • REJECT: Antwortet mit "rejected" auf das Paket. Gegenüber weis sofort, dass hier irgendwas ist und es auch antwortet. Es können schneller mehr Verbindungen aufgebaut werden.
    • DROP: Verwirft das Paket und antwortet nicht. Gegenüber wartet auf eine Antwort, was unter Umständen lange dauert. Es stapeln sich langsam neue offene Verbindungen mit Timeouts.

    So oder so: Es kommt mehr oder weniger auf das selbe raus. Bei beidem werden neue Verbindungen aufgebaut. Beim einen schnell und kurz. Beim anderen dafür langsam und viele. So oder so werden am Ende Ressourcen belegt.


    Der andere Punkt für "REJECT" ist der, dass ich gerne schnell überprüfen möchte, ob ein neu freigegebener Port erreichbar oder nicht ist, ohne dass ich immer auf eventuelle Timeouts warten muss. ;)


    Hier noch ein netter Beitrag dazu: firewalls - Benefits of REJECT over DROP on a single PC - Information Security Stack Exchange

    Weiters die Limits
    Sind die nicht ein wenig großzügig eingestellt worden?


    Derzeit nutze ich ein Limit bei mir von 10 und Burst von 15 und hatte ehrlich gesagt noch keine Probleme
    Läuft ein Webserver + TeamSpeak Server drauf


    Das kommt auf die Anwendungen und deren Einstellungen bzgl. des Traffics an. Diese Werte sind ein gutes Mittelmaß. Man kann diese natürlich noch höher oder auch niedriger setzen. Auf was genau, muss man aber selbst herausfinden.

  • Kann mir jemand verraten, wie ich eine gewisse File, oder gar ganze Ordner, in die .sh mit aufnehmen kann, damit diese nicht Drölfmillionen Zeilen lang ist?


    Da ich heute mal diverse ASN Files erstellt habe, mit den Ranges von Hetzner, OVH, Fsit und noch einigen mehr. Dementsprechend sind da ziemlich viele IP-Ranges drin :/

  • Hallo, wie sieht das ganze mit IPv6 aus? Kann man das Script komplett übernehmen?
    Nur halt mit ip6tables arbeiten?


    //EDIT:


    Hab es ausprobiert

    Code
    1. ip6tables v1.4.14: unknown reject type "icmp-proto-unreachable"
    2. Try `ip6tables -h' or 'ip6tables --help' for more information.


    Kam dabei raus. Und keine Verbindung mehr über IPv6

  • Anstelle von den normalen Befehlen um neue Rules hinzuzufügen wie hier:


    iptables -A INPUT -p tcp --dport 80 -j ACCEPT


    einfach von iptables in ip6tables ändern:


    ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT


    Falls gewünscht erstelle ich auch gerne hier mal eine Anleitung zum richtigen konfigurieren von Iptables :D

  • Ich hab mir mal selbst was gebastelt, wie sieht das Script aus?
    Läuft alles eigentlich.


    IPv4

    Shell-Script
    1. #!/bin/bash# About: Firewall Regeln fuer iptablesiptables -Fiptables -Xiptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -A INPUT -i lo -j ACCEPTiptables -A INPUT -p tcp --dport 80 -j ACCEPT # HTTPiptables -A INPUT -p tcp --dport 25847 -j ACCEPT # SSHiptables -A INPUT -p udp --dport 1337 -j ACCEPT # Voiceportiptables -A INPUT -p tcp --dport 2008 -j ACCEPT # Accountingiptables -A INPUT -p tcp --dport 10011 -j ACCEPT # ServerQueryiptables -A INPUT -p tcp --dport 30033 -j ACCEPT # Avatariptables -A INPUT -p tcp --dport 41144 -j ACCEPT # TSDNSiptables -A INPUT -p icmp -j ACCEPTiptables -A INPUT -p tcp -m limit --limit 30/sec --limit-burst 100 -j REJECT --reject-with tcp-resetiptables -A INPUT -m limit --limit 30/sec --limit-burst 100 -j REJECT --reject-with icmp-port-unreachableiptables -A INPUT -j DROPiptables -A FORWARD -j REJECTiptables -A OUTPUT -j ACCEPT


    IPv6

  • Deine Skripte sehen in Ordnung und sauber aus. :)


    Ich persönlich nutze dafür nur ein Skript, weil man sonst beim anderen meist was vergisst, zu konfigurieren, wenn man was ändert. So hat man ein Skript und führt alle Regeln für IPv4 und IPv6 aus. :)

    Shell-Script
    1. #!/bin/bashiptables_commands=(iptables ip6tables)for iptables_command in ${iptables_commands[@]}; do ${iptables_command} -A INPUT -p tcp --dport 80 -j ACCEPT # HTTP ... ${iptables_command} -A INPUT -p tcp --dport 25847 -j ACCEPT # SSHdone/etc/init.d/netfilter-persistent save


    Und wenn man IPv4/-v6 spezifische Regeln hat, wie z.B. ICMP, dann kann man das so lösen:

    Shell-Script
    1. #!/bin/bash
    2. if [[ "${iptables_commands}" == "iptables" ]]; then
    3. ${iptables_commands} -A INPUT -p icmp -m comment --comment "Erlaube: ICMP" -j ACCEPT
    4. else
    5. ${iptables_commands} -A INPUT -p icmpv6 -m comment --comment "Erlaube: ICMP" -j ACCEPT
    6. fi