BIND DNS per Fail2Ban absichern

Dieses Thema im Forum "Tipps - Tricks - Mods" wurde erstellt von Brainfood, 16. Okt. 2012.

  1. Brainfood

    Brainfood Member

    Vorweg:
    Ich habe eine zeitlang Public Resolver betrieben, diese Kisten sind jetzt nur noch als Authoritative DNS Server für ihre jeweiligen Domains zuständig,

    DNS Amplification scheint irgendwie zum neuen Volkssport ausgebrochen zu sein und erzeugt bei mir täglich ein 500 MB Syslog rauschen, dad geht mir auf die Eier ...

    vi / etc / fail2ban / jail.conf

    Code:
    ### ### ### PLITC ### ### ###
    [named-refused-udp]
    
    enabled  = true
    port     = domain,953
    protocol = udp
    filter   = named-refused
    logpath  = /var/log/syslog
    bantime  = 31536000
    maxretry = 99
    ### ### ### PLITC ### ### ###
    
    [named-refused-tcp]
    
    enabled  = true
    port     = domain,953
    protocol = tcp
    filter   = named-refused
    logpath  = /var/log/syslog
    bantime  = 31536000
    maxretry = 25
    
    # EOF
    Logauszug:

    Code:
    Oct 13 19:06:12 ns1-plitc named[2602]: client 108.162.203.21#62259: query (cache) 'irishindependentescorts/A/IN' denied
    
    oder
    
    Oct 16 10:50:29 ns1-plitc named[25294]: client 93.114.45.212#80: query (cache) 'isc.org/ANY/IN' denied
    Diese Kasperköppe von Home | CloudFlare | The web performance & security company sollten etwas mehr ihre Kisten überprüfen ...

    Wer gelegentliche DNS-Checks wie z.B. über Pingdom Tools fährt, kann diese IPs permanent freischalten ...
     
    Zuletzt bearbeitet: 16. Okt. 2012
  2. mare

    mare Member

    Sorry, aber ich wäre da bischen Vorsichtiger.
    Die Funktion einer Amplification hast du schön beschrieben.
    Die "IP" zu sperren bringt auch den gewünschten Erfolg.

    ABER: Die Angriffe kommen "nicht" von dieser IP sondern diese IP ist das pot. Opfer !
     
  3. Brainfood

    Brainfood Member

    Das doch Quatsch:

    Code:
    Oct 16 10:50:29 ns1-plitc named[25294]: client 93.114.45.212#80: query (cache) 'isc.org/ANY/IN' denied
    ns1-plitc = mein NS

    client = CLIENT !!!

    Query = mein Cache

    isc.org/ANY/IN' denied = Ziel: "isc.org" Abfrage: "dig ANY" im Netz: "IN"ternet lehnt mein Server ab = denied

    Mein NS ist nur Mittelsmann ... er wird dabei zum "multiplexen" von kurzen Anfragen ... um ... lange Antworten zu bekommen = Traffic Erhöhung des Opfers = missbraucht ...

    Mach mal ein:

    Code:
    dig NS isc.org
    oder

    Code:
    nslookup -q=NS isc.org
    Die IPs der Ziele sind nicht die IP des "clients" (Angreifers)

    Bei ner TCP Verbindung ... ist es klar definierbar der Angreifer ... zumal einige IPs aus den Pools ... Minunten später nen SSH Login versuchen ...

    Code:
    Oct 16 15:10:34 ns1-plitc sshd[30507]: Invalid user 1 from 101.95.48.20
    Oct 16 15:10:34 ns1-plitc sshd[30507]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.95.48.20 
    Oct 16 15:10:36 ns1-plitc sshd[30507]: Failed password for invalid user 1 from 101.95.48.20 port 17435 ssh2
    Oct 16 15:10:39 ns1-plitc sshd[30509]: Invalid user a from 101.95.48.20
    Oct 16 15:10:39 ns1-plitc sshd[30509]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.95.48.20 
    Oct 16 15:10:41 ns1-plitc sshd[30509]: Failed password for invalid user a from 101.95.48.20 port 54082 ssh2
    Oct 16 15:10:43 ns1-plitc sshd[30511]: Invalid user aaa from 101.95.48.20
    Oct 16 15:10:43 ns1-plitc sshd[30511]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.95.48.20 
    Oct 16 15:10:45 ns1-plitc sshd[30511]: Failed password for invalid user aaa from 101.95.48.20 port 49758 ssh2
    Wie gesagt: beim UDP Ban bin ich vorsichtiger und pflege wöchentlich, nach manueller Prüfung, die Sperradressen ein ...
     
    Zuletzt bearbeitet: 16. Okt. 2012
  4. mare

    mare Member

    Bei den UDP Anfragen ist der "Client" meisten das Opfersystem da dein Server dann die riesen Antwort (z.B. any isc.org) and den "Client" schickt. Was nützt es dem Angreifer die Antwort selbst "abzubekommen".

    Bei den TCP Querys hast du natürlich Recht. Dort ist Client=Angreifer und es geht darum den Ziel DNS zu überlasten.
     
  5. Brainfood

    Brainfood Member

    so kommen wir der Sache näher ...

    ich spreche die ganze zeit von tcp ...

    wie gesagt: udp ip spoofing ist eine andere Herangehensweise ...

    ich mappe einfach per iptables: alle named-tcp ban = named-udp ban
     

Diese Seite empfehlen