BIND DNS per Fail2Ban absichern

Brainfood

Member
Vorweg:
# !!! WARNING !!!
# Since UDP is connectionless protocol, spoofing of IP and immitation
# of illegal actions is way too simple. Thus enabling of this filter
# might provide an easy way for implementing a DoS against a chosen
# victim. See
# fail2ban + dns = fail - nion's blog
# Please DO NOT USE this jail unless you know what you are doing.

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:

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 !
 

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:

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.
 

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
 

Werbung

Top