iptables-skript, Verbesserungsvorschläge

Dieses Thema im Forum "Firewalls" wurde erstellt von C:S, 06.03.2009.

  1. C:S

    C:S Foren As

    Dabei seit:
    21.01.2009
    Beiträge:
    76
    Zustimmungen:
    0
    Moin,
    also habe die Tage die Logfiles meines debian-etch-Root-servers mal näher studiert, und doch ziemlich viele dfind scans, ssh Angriffe und dergleichen gefunden. Daher habei ich den ssh-port mal von 22 weg bewegt, und mir mein iptables-skript nochmal angeschaut und leicht verändert.
    Ich wollte euch jetzt mal bitten einen Blick auf das Skript zu werfen, und mir eure Verbesserungsvorschläge zu schreiben, bin für alle Tipps dankbar!

    Der Root Server ist auf mehreren IPs ansprechbar (eine Hauptip + Subnetzwerk). Wird von 3 Personen genutzt, jede hat ihre eigene Ip, und Webserver und Mailzugang. Auf einer ip läuft noch ein Teamspeak-Server.
    Code:
    #!/bin/bash
    # Skript /etc/network/if-pre-up.d/iptables-up fuer Debian
    
    IPTABLES=/sbin/iptables
    
    #Mal durchspülen...
    $IPTABLES -F
    $IPTABLES -t mangle -F
    
    # Setzen der Default-Policies
    $IPTABLES -P INPUT DROP
    $IPTABLES -P FORWARD DROP
    $IPTABLES -P OUTPUT DROP
    
    # Kette, in die zu blockende IPs reinkommen
    $IPTABLES -F blockips
    $IPTABLES -X blockips
    $IPTABLES -N blockips
    
    $IPTABLES -A INPUT -j blockips
    $IPTABLES -A OUTPUT -j blockips
    
    
    #Ungültige Pakete verwerfen
    $IPTABLES -A INPUT -m state --state INVALID -j DROP
    
    #Bestehende Verbindungen erlauben
    $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    
    #HTTP
    $IPTABLES -A INPUT -p tcp --dport 80 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 80 -j ACCEPT
    
    #HTTPS
    $IPTABLES -A INPUT -p tcp --dport 443 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 443 -j ACCEPT
    
    #SMTP
    $IPTABLES -A INPUT -p tcp --dport 25 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 25 -j ACCEPT
    
    #SSH
    $IPTABLES -A INPUT -p tcp --dport 2222 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 2222 -j ACCEPT
    
    #FTP (nur für apt-get)
    $IPTABLES -A OUTPUT -p tcp --dport 20:21 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 1024:65535 -j ACCEPT
    
    #IMAPS
    $IPTABLES -A INPUT -p tcp --dport 993 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 993 -j ACCEPT
    
    #POP3S
    $IPTABLES -A INPUT -p tcp --dport 995 -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 995 -j ACCEPT
    
    #TEAMSPEAK (soll nur auf einer IP erreichbar sein)
    $IPTABLES -A INPUT -p tcp --dport 14534 -d ***.***.***.*** -j ACCEPT
    $IPTABLES -A INPUT -p udp --dport 8767:8770 -d ***.***.***.*** -j ACCEPT
    $IPTABLES -A OUTPUT -p tcp --sport 14534 -s ***.***.***.*** -j ACCEPT
    $IPTABLES -A OUTPUT -p udp --sport 8767:8770 -s ***.***.***.*** -j  ACCEPT
    
    #loopback
    $IPTABLES -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
    $IPTABLES -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
    
    #Ping
    $IPTABLES -A INPUT -p icmp --icmp-type 8 -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp --icmp-type 8 -j ACCEPT
    $IPTABLES -A OUTPUT -p icmp --icmp-type 0 -j ACCEPT
    
    #DNS
    $IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
    $IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
    
    #NMAP-Scans verhindern
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG --log-prefix "NMAP-XMAS SCAN:" --log-tcp-options --log-ip-options --log-level debug
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
    
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "NMAP-NULL SCAN:" --log-tcp-options --log-ip-options --log-level debug
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP
    
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j LOG --log-prefix "SYN/RST SCAN:" --log-tcp-options --log-ip-options --log-level debug
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
    
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG --log-prefix "SYN/FIN SCAN:" --log-tcp-options --log-ip-options --log-level debug
    $IPTABLES -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
    
    #zu blockende IPs werden geladen (Kette 'blockips')
    #momentan scannt das Script hier nur den apache-error log durch und liest alle ips von diversen dfind scans ein, um diese dann zu sperren
    /opt/firewall/refreships.sh
    
    Hier noch was iptables -L ausspuckt:
    Code:
    Chain INPUT (policy DROP)
    target     prot opt source               destination
    blockips   all  --  anywhere             anywhere
    DROP       all  --  anywhere             anywhere            state INVALID
    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:smtp
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2222
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:imaps
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:pop3s
    ACCEPT     tcp  --  anywhere             [HOST].[SERVER_SUB_IP]  tcp dpt:14534
    ACCEPT     udp  --  anywhere             [HOST].[SERVER_SUB_IP]  udp dpts:8767:8770
    ACCEPT     all  --  localhost            localhost
    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
    ACCEPT     udp  --  anywhere             anywhere            udp spt:domain
    
    Chain FORWARD (policy DROP)
    target     prot opt source               destination
    
    Chain OUTPUT (policy DROP)
    target     prot opt source               destination
    blockips   all  --  anywhere             anywhere
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:www
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:https
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:smtp
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:2222
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:ftp-data:ftp
    ACCEPT     tcp  --  anywhere             anywhere            tcp spts:1024:65535
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:imaps
    ACCEPT     tcp  --  anywhere             anywhere            tcp spt:pop3s
    ACCEPT     tcp  --  [HOST].[SERVER_SUB_IP]   anywhere            tcp spt:14534
    ACCEPT     udp  --  [HOST].[SERVER_SUB_IP]   anywhere            udp spts:8767:8770
    ACCEPT     all  --  localhost            localhost
    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request
    ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply
    ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain
    
    Chain blockips (2 references)
    target     prot opt source               destination
    DROP       all  --  195.153.113.140      anywhere
    DROP       all  --  graphics.djmixed.com  anywhere
    DROP       all  --  pd9569fb3.dip0.t-ipconnect.de  anywhere
    DROP       all  --  38107.vs.webtropia.com  anywhere
    DROP       all  --  wpc1409.amenworld.com  anywhere
    DROP       all  --  64.32.4.250          anywhere
    DROP       all  --  66-221-254-44.static.propagation.net  anywhere
    DROP       all  --  ns.fx3767-dedic1.hosting-ie.com  anywhere
    DROP       all  --  s210.silver.fastwebserver.de  anywhere
    DROP       all  --  escr-motorsport.de   anywhere
    DROP       all  --  s15283345.onlinehome-server.info  anywhere
    DROP       all  --  aveva.ru             anywhere
    DROP       all  --  91.139.170.170       anywhere
    DROP       all  --  92.48.106.120        anywhere
    
    
    
    CS:~$ iptables -t mangle -L
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination
    LOG        tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG LOG level debug tcp-options ip-options prefix `NMAP-XMAS SCAN:'
    DROP       tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
    LOG        tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE LOG level debug tcp-options ip-options prefix `NMAP-NULL SCAN:'
    DROP       tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
    LOG        tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN,RST LOG level debug tcp-options ip-options prefix `SYN/RST SCAN:'
    DROP       tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN,RST
    LOG        tcp  --  anywhere             anywhere            tcp flags:FIN,SYN/FIN,SYN LOG level debug tcp-options ip-options prefix `SYN/FIN SCAN:'
    DROP       tcp  --  anywhere             anywhere            tcp flags:FIN,SYN/FIN,SYN
    
    
    
    Schomal Danke fürs Drüberschaun,
    Gruß, CS
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. defcon

    defcon Kaiser
    Moderator

    Dabei seit:
    22.08.2005
    Beiträge:
    1.486
    Zustimmungen:
    1
    Ort:
    Bruchsal
    Hm, was bringt das wenn du "pd9569fb3.dip0.t-ipconnect.de" blockst?
    Das sind doch eh dynaische IPs die sich nach einer Zwangstrennung ändern.

    Falls ich da was missverstehe, bitte Aufklärung.
     
  4. C:S

    C:S Foren As

    Dabei seit:
    21.01.2009
    Beiträge:
    76
    Zustimmungen:
    0
    Ja, also dass diese ip gesperrt wird kommt von einem Skript, das den apache error log nach "w00t" scannt, und die jeweiligen ips dann über iptables sperrt. Dass da mal ne dynamische dabei ist, ist klar, aber oft werden eben auch server wie "66-221-254-44.static.propagation.net" gesperrt.

    Aber habt ihr sonst nichts iwie zu beanstanden? Wie schauen denn eure iptables aus, falls ihr einen server betreibt?
    Gruß, CS
     
  5. #4 amöbe, 07.03.2009
    Zuletzt bearbeitet: 07.03.2009
    amöbe

    amöbe Tripel-As

    Dabei seit:
    21.01.2007
    Beiträge:
    188
    Zustimmungen:
    0
    Dein Problem ist nur auf kurz oder lang, wenn du immer solche Dinge wie "pd9569fb3.dip0.t-ipconnect.de" sperrst, die von einem Telekom-Kunden an den nächsten weitergegeben werden, hast du auf kurz oder lang nicht nur den "w00t"-Menschen geblockt, sondern seine ganze Stadt bzw. den Bereich in dem die Telekom solche IPs vergibt. Da könnte sich ganzschön was ansammeln...
     
  6. C:S

    C:S Foren As

    Dabei seit:
    21.01.2009
    Beiträge:
    76
    Zustimmungen:
    0
    und was schlägst du vor? Wie kann ich das verhindern?
    pd9569fb3.dip0.t-ipconnect.de ist glaub ich gar keine dynamischer hostname...
     
  7. amöbe

    amöbe Tripel-As

    Dabei seit:
    21.01.2007
    Beiträge:
    188
    Zustimmungen:
    0
    Vielleicht so etwas wie eine Lebensdauer? Nach einer Woche löschen oder so...
     
  8. #7 Clownish, 07.03.2009
    Clownish

    Clownish none

    Dabei seit:
    22.05.2006
    Beiträge:
    62
    Zustimmungen:
    0
    Meiner Meinung nach macht so ein "Rundumschlag" kaum Sinn. Wie schon erwähnt wurde, werden dynamische IP's der ISP's weitergereicht, es könnte also durchaus vorkommen das du "Unschuldige" sperrst. Für einzellne Dienste wie ssh mag sowas ja sinnvoll sein (z.B per DenyHosts [1]), aber sonst würde ich einfach schauen das meine Services immer auf dem aktuellen Stand sind und zumindest das hirnlose Scannen nach "Webexploits" als Hintergrundrauschen ignorieren.

    [1] http://denyhosts.sourceforge.net/
     
  9. C:S

    C:S Foren As

    Dabei seit:
    21.01.2009
    Beiträge:
    76
    Zustimmungen:
    0
    okay, also dann muss ich mir das mit dem ip-sperren nochmal überlegen. Abgesehen davon, irgendwelche Ideen für Verbesserungen? Wie gesagt, würde mich sehr interessieren wie bei anderen Servern das iptables skript ausschaut!
     
  10. #9 DMM23, 25.08.2009
    Zuletzt bearbeitet: 25.08.2009
    DMM23

    DMM23 Doppel-As

    Dabei seit:
    11.07.2007
    Beiträge:
    131
    Zustimmungen:
    0
    Ort:
    Hannover
    ich bin mir nicht ganz sicher, verkrafte auch kritik.
    du erwähntest, dass du ports verändert hast, weil du oft angriffe auf diese bekommen hast wie zb. ssh. stimmt so oder ?
    ist doch eigendlich hose wie jacke welchen port du nimmst, wenn es wer auf dich abgesehn hat dann scannt er die kompletten ports von dir und merkt natürlich das ssh mit port 22 auf einen anderen port gewechselt ist.

    *edit* andernfalls bitt eich um aufklärung, weil ich auch immer andere ports gewählt habe und mich damit sicherer geglaubt habe. bis mir ein arbeitskollege das gegenteil bewiesen hat mit ein zwei programmen.
     
  11. #10 HeadCrash, 25.08.2009
    HeadCrash

    HeadCrash Routinier

    Dabei seit:
    16.05.2009
    Beiträge:
    482
    Zustimmungen:
    1
    Ort:
    Bayern
    Moin,

    Wenn ein komplett Portscan gefahren wird ist das klar Jacke wie Hose. Nur es dauert ein bisschen länger 65k Ports abzuklappern anstelle der ersten 1024 (well known).
    Plus mit jedem Port den man scant ist die gefahr höher das eine Firewall was merkt und einen Aussperrt

    mfg
    HeadCrash
     
  12. DMM23

    DMM23 Doppel-As

    Dabei seit:
    11.07.2007
    Beiträge:
    131
    Zustimmungen:
    0
    Ort:
    Hannover
    also macht es doch sinn einen 4-stilligen port zu wählen ,für paranoide menschen ?
     
  13. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  14. #12 C:S, 25.08.2009
    Zuletzt bearbeitet: 25.08.2009
    C:S

    C:S Foren As

    Dabei seit:
    21.01.2009
    Beiträge:
    76
    Zustimmungen:
    0
    ja, also bei mir wars ja ssh, das ich von 22 auf 2222 geändert hatte. Ich hatte mir nämlich meine Logs angeschaut (logwatch sei dank) und habe eben festgestellt, dass da auf meinen ssh server gebruteforced wurde, und das nicht zu knapp. Hier mal eine Übersicht des SSH-Logs, als SSH noch auf 22 lief (ich hab leider keinen Detaillierten Bericht mehr, da sähe man wunderschön wie alle möglichen Namen und Passwort kombinationen ausprobiert werden ;-):
    Code:
    root@****:~# logwatch --service sshd --range today --detail 1
    
    ################### Logwatch 7.3.6+cvs20080702-debian (07/02/08) ####################
    Processing Initiated: Tue Mar  3 17:17:51 2009
    Date Range Processed: today
    ( 2009-Mar-03 )
    Period is day.
    Detail Level of Output: 1
    Type of Output/Format: stdout / text
    Logfiles for Host: sven
    ##################################################################
    
    --------------------- SSHD Begin ------------------------
    
    Illegal users from:
    58.211.82.139: 2 times
    78.46.51.40 (static.40.51.46.78.clients.your-server.de): 200 times
    78.107.128.250: 20 times
    193.206.43.77 (TRAP11.medicina.uniba.it): 60 times
    200.76.209.156 (dedint-200-76-209-156.mexdf.axtel.net): 42 times
    201.116.210.150 (mail.secomex.com.mx): 378 times
    
    Locked account login attempts:
    mysql : 6 Time(s)
    postfix : 1 Time(s)
    sshd : 3 Time(s)
    
    Users logging in through sshd:
    C:S:
    ***.***.110.0 (****): 1 time
    ***.***.100.231 (****): 1 time
    ***.***.101.35 (****): 1 time
    
    **Unmatched Entries**
    reverse mapping checking getaddrinfo for dedint-200-76-209-156.mexdf.axtel.net [200.76.209.156] failed - POSSIBLE BREAK-IN ATTEMPT! : 107 time(s)
    
    ---------------------- SSHD End -------------------------
    
    
    ###################### Logwatch End #########################
    
    Wie man sieht, sind das nicht gerade wenige Angriffe pro Tag gewesen. Die können zwar nicht wirklich durchkommen, da man sich nur mit Keyfiles einloggen kann, aber um den Server zu entlasten habe ich den Port einfach verlegt. Und jetzt habe ich gar keine Angriffe mehr. Das sind also einfach nur Bots, die lauter Server abgraßen, in der Hoffnung irgendwo ne Schwachstelle zu finden.
    Von daher finde ich, dass das nicht nur was für paranoide Menschen ist ;-)

    Ich finde, es macht schon irgendwo Sinn, weil du dadurch eben den schnellen Bruteforce Atacken entgehst. Allerdings dürften die natürlich auch so kein allzu Großes Problem sein, wenn alles richtig eingestellt ist.

    Gruß, C:S
     
  15. #13 DMM23, 25.08.2009
    Zuletzt bearbeitet: 25.08.2009
    DMM23

    DMM23 Doppel-As

    Dabei seit:
    11.07.2007
    Beiträge:
    131
    Zustimmungen:
    0
    Ort:
    Hannover
    wie du schon erwähnt hattest. authentifizierung und brutforce attacken werden einem nicht gefährlich.

    *in welcher zeile werden denn die IPs von angreifern gesperrt und nach blockip verschoben ? oder ist das ein seperates script ?*
     
Thema:

iptables-skript, Verbesserungsvorschläge

Die Seite wird geladen...

iptables-skript, Verbesserungsvorschläge - Ähnliche Themen

  1. iptables-Skript

    iptables-Skript: Hi, ich würde gerne einen Debian-Server neben dem NAT-Routing auch noch einige Sicherheitsmaßnahmen für ein extra WLAN-Interface übernehmen...
  2. Verbesserungsvorschläge?

    Verbesserungsvorschläge?: Hallo zusammen, da ich gerade ein paar Dateien auslagern wollte auf ein neues LVM und nicht wusste, wie gross es sein muss, wollte ich die Grösse...
  3. mein script "ncprof" -> verbesserungsvorschläge

    mein script "ncprof" -> verbesserungsvorschläge: ich hab mir nen script gebastelt und hätte gerne verbesserungsvorschläge was man anders machen könnte :) vielleicht kann es sogar der eine oder...
  4. verbesserungsvorschläge für specfile zum rpm-bau

    verbesserungsvorschläge für specfile zum rpm-bau: hallo allerseits :) , ich habe mich nun mit dem paketbau von rpms beschäftigt und schon einige selber zusammengebaut. die funktionieren bei mir...