theHSB
Anmeldungsdatum: 23. September 2017
Beiträge: Zähle...
|
Hallo zusammen, fail2ban blockiert IP-Adressen anhand seiner Jails, allderdings habe ich weiterhin Zugriffe dieser IP-Adressen. Beispiel: 45.x.x.150 Diese IP sehe ich in iptables als "REJECT" iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-sasl tcp -- anywhere anywhere multiport dports smtp,urd,imap2,imap3,imaps,pop3,pop3s
fail2ban-courierauth tcp -- anywhere anywhere multiport dports smtp,urd,imap2,imap3,imaps,pop3,pop3s
fail2ban-apache tcp -- anywhere anywhere multiport dports http,https
fail2ban-pam-generic tcp -- anywhere anywhere
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain fail2ban-apache (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-courierauth (1 references)
target prot opt source destination
REJECT all -- 45.x.x.150 anywhere reject-with icmp-port-unreachable Dennoch habe ich weiterhin reihenweise Zugriffe von dieser IP in meinem Log: Oct 8 19:27:56 xxx postfix/smtpd[2447]: warning: unknown[45.x.x.150]: SASL LOGIN authentication failed: authentication failure Woran kann es liegen?
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Vorweg: Mit fail2ban habe ich bisher noch keine nennenswerte Berührung gehabt. Bitte poste hier mal die Ausgabe von iptables-save, damit wir einen vollständigeren Blick auf deine Regeln bekommen. Du hast ja mehrere Chains für fail2ban als Target in deiner INPUT Chain benannt, aber nur die Regeln für fail2ban-courierauth mitgegeben. Was steht z.B. in der vorher aufgerufenen fail2ban-sasl (dürfte aus der Ausgabe von iptables-save hervorgehen)?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! fail2ban kann ja erst NACH den Zugriffen blockieren. Es wertet die angegebenen Logdateien aus und sperrt per iptables oder route 🇬🇧 die entsprechenden IPs. Diese werden nach der konfigurierten Zeit wieder "freigegeben". Die meisten Zugriffe von solchen Kandidaten erfolgen sehr schnell aufeinander folgend, so dass die Sperrung erst nach einigen Zugriffsversuchen greift, die auch über den in maxretry eingestellten erlaubten Fehlversuchen liegen kann. Siehe auch fail2ban
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
ChickenLipsRfun2eat schrieb: fail2ban kann ja erst NACH den Zugriffen blockieren.
Das habe ich vermutet und ich denke, dass die IP deshalb auch in der courier Chain gelandet ist. Wenn die Chain leer ist, steht das Target auf RETURN, was wir in der apache Chain sehen können. Meine Annahme ist also, dass irgendwas in der sasl Chain nicht stimmen könnte, weil die vorher durchlaufen wird. Was natürlich auch sein kann und auch zu dem von dir geschriebenen passt: Die Logeinträge sind älter als die Sperrung.
|
theHSB
(Themenstarter)
Anmeldungsdatum: 23. September 2017
Beiträge: 15
|
Danke euch für die Antworten. Dass das Blocken erst nach mehreren Zugriffen stattfindet, ist mir klar. Mein Problem ist eben, dass Fail2ban die IP bereits in iptables eingetragen hat, diese IP aber weiter munter zugreifen kann. Mittlerweile musste ich den Server neu starten. Problem bleibt aber, IP wird geblockt, es gibt aber weiter Zugriffe. fail2ban blockiert die IP um 19:07 Uhr
2019-10-09 19:07:51,615 fail2ban.actions: WARNING [sasl] Ban 45.x.x.150 Sie ist in iptables gelistet (diesmal die komplette Ausgabe)
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-sasl tcp -- anywhere anywhere multiport dports smtp,urd,imap2,imap3,imaps,pop3,pop3s
fail2ban-courierauth tcp -- anywhere anywhere multiport dports smtp,urd,imap2,imap3,imaps,pop3,pop3s
fail2ban-apache tcp -- anywhere anywhere multiport dports http,https
fail2ban-pam-generic tcp -- anywhere anywhere
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain fail2ban-apache (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-courierauth (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-pam-generic (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-sasl (1 references)
target prot opt source destination
REJECT all -- x.x.x.x anywhere reject-with icmp-port-unreachable
REJECT all -- x.x.x.x anywhere reject-with icmp-port-unreachable
REJECT all -- x.x.x.x anywhere reject-with icmp-port-unreachable
REJECT all -- 45.x.x.150 anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere Ich sehe aber weiter Zugriffe von dieser IP
Oct 9 19:09:29 xxx postfix/smtpd[2560]: warning: unknown[45.x.x.150]: SASL LOGIN authentication failed: authentication failure
Oct 9 19:10:10 xxx postfix/smtpd[2560]: warning: unknown[45.x.x.150]: SASL LOGIN authentication failed: authentication failure
Oct 9 19:10:52 xxx postfix/smtpd[2503]: warning: unknown[45.x.x.150]: SASL LOGIN authentication failed: authentication failure Danke für eure Hilfe! –- Und hier noch die Ausgabe von iptables-save
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*security
:INPUT ACCEPT [1615:138676]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1425:190607]
COMMIT
# Completed on Wed Oct 9 19:13:51 2019
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*raw
:PREROUTING ACCEPT [1639:140088]
:OUTPUT ACCEPT [1426:190907]
COMMIT
# Completed on Wed Oct 9 19:13:51 2019
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*nat
:PREROUTING ACCEPT [138:7024]
:INPUT ACCEPT [125:6244]
:OUTPUT ACCEPT [77:5477]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -j MASQUERADE
COMMIT
# Completed on Wed Oct 9 19:13:51 2019
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*mangle
:PREROUTING ACCEPT [1639:140088]
:INPUT ACCEPT [1639:140088]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1434:192059]
:POSTROUTING ACCEPT [1434:192059]
COMMIT
# Completed on Wed Oct 9 19:13:51 2019
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*filter
:INPUT ACCEPT [10:767]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17:2073]
:fail2ban-apache - [0:0]
:fail2ban-courierauth - [0:0]
:fail2ban-pam-generic - [0:0]
:fail2ban-sasl - [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-sasl
-A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-courierauth
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache
-A INPUT -p tcp -j fail2ban-pam-generic
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A fail2ban-apache -j RETURN
-A fail2ban-courierauth -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -s 45.x.x.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-courierauth -j RETURN
-A fail2ban-pam-generic -j RETURN
-A fail2ban-sasl -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -s x.x.x.x/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -s 45.x.x.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-sasl -j RETURN
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Wed Oct 9 19:13:51 2019 Interessant ist, dass sowohl courierauth als auch SASL die IP blocken wollen, sie bei "iptables -L" aber nur in der sasl-chain auftaucht. Was das bedeutet, weiß ich aber nicht.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Seltsam genug. Du könntest versuchen, das Tracing zu aktivieren (siehe iptables debugging) und daraus mehr zu erfahren. Der Artikel selbst ist von 2010, wurde aber von mehreren neueren Artikeln verlinkt - sollte also mindestens ein paar gute Suchbegriffe liefern. ☺
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ist natürlich interessant, aber ich kenne mich mit iptables zu wenig aus, um die Blockmechanismen wirklich zu verstehen. Ich nutze fail2ban so, dass es über die routing-Tabelle blockt und konnte ein solches Verhalten nicht feststellen. Der Vorteil ist, dass man nicht auf eventuelle Regel-Probleme mit den eigenen iptables-rules achten muss. Wäre einen Versuch wert.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Eigentlich wollte ich hier gar nicht drauf anworten.... und eigentlich ist das schon klar, dass das nicht funktioniert, ja gar nicht funktionieren kann... ne richtige Firewall ist das ja auch nicht... die winkt ja alles durch, was nicht den paar angegebenen Ports entspricht. Das ist imho so das typische Beispiel, wo der Glauben die Fakten ersetzt, und wo am Ende möglicherweise ein ungehärtetes System im öffentlichen Netz betrieben wird. Isses quasi schon fast nen honeypot...?... keine Ahnung, man kennt den Rest ja nicht. -A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-sasl -A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-courierauth
Der Standard-SMTP-Port 587 wird gar nicht geprüft. Wegen dem Hinweis auf SASL-Auth vermute ich mal, es handelt sich um einen Mailserver, wahrscheinich also um einen eher schlecht gesichertes System. Wenn er nicht den Port des eingehenden TCP-Paketes überprüft, auf welchem Port diese IP-Adresse überhaupt verbinden will (vermutlich auf 587), ist das doch alles nur rätselraterei, warum der reject nicht funktioniert. Es würde vielleicht funktionieren, wenn man die Ports ganz entfernen würde, dann würde zumindest der fail2ban-Block klappen. Ausserdem wäre es interessant zu wissen, wer alles auf welchen Ports lauscht.
Die bessere Lösung wäre zu verstehen, was man da überhaupt tut.....
|
theHSB
(Themenstarter)
Anmeldungsdatum: 23. September 2017
Beiträge: 15
|
TomLu schrieb: Eigentlich wollte ich hier gar nicht drauf anworten.... und eigentlich ist das schon klar, dass das nicht funktioniert, ja gar nicht funktionieren kann... ne richtige Firewall ist das ja auch nicht... die winkt ja alles durch, was nicht den paar angegebenen Ports entspricht. Das ist imho so das typische Beispiel, wo der Glauben die Fakten ersetzt, und wo am Ende möglicherweise ein ungehärtetes System im öffentlichen Netz betrieben wird. Isses quasi schon fast nen honeypot...?... keine Ahnung, man kennt den Rest ja nicht. -A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-sasl -A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-courierauth
Der Standard-SMTP-Port 587 wird gar nicht geprüft. Wegen dem Hinweis auf SASL-Auth vermute ich mal, es handelt sich um einen Mailserver, wahrscheinich also um einen eher schlecht gesichertes System. Wenn er nicht den Port des eingehenden TCP-Paketes überprüft, auf welchem Port diese IP-Adresse überhaupt verbinden will (vermutlich auf 587), ist das doch alles nur rätselraterei, warum der reject nicht funktioniert. Es würde vielleicht funktionieren, wenn man die Ports ganz entfernen würde, dann würde zumindest der fail2ban-Block klappen. Ausserdem wäre es interessant zu wissen, wer alles auf welchen Ports lauscht.
Die bessere Lösung wäre zu verstehen, was man da überhaupt tut.....
Die Regeln in iptables habe ich ja nicht selbst geschrieben. Die trägt fail2ban ein, wenn es ein verdächtiges Verhalten in den Logs findet. Ich selbst habe keine Ahnung davon. Das merkwürdige ist, dass das früher alle gut funktioniert hat. Da die Einträge in iptables ja evtl. falsch sind (fehlender Port), schaue ich als nächstes ob meine Version von fail2ban evtl. veraltet ist.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
theHSB schrieb: Und hier noch die Ausgabe von iptables-save
# Generated by iptables-save v1.4.21 on Wed Oct 9 19:13:51 2019
*security
:INPUT ACCEPT [1615:138676]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1425:190607]
*raw
:PREROUTING ACCEPT [1639:140088]
:OUTPUT ACCEPT [1426:190907]
*nat
:PREROUTING ACCEPT [138:7024]
:INPUT ACCEPT [125:6244]
:OUTPUT ACCEPT [77:5477]
:POSTROUTING ACCEPT [0:0]
*mangle
:PREROUTING ACCEPT [1639:140088]
:INPUT ACCEPT [1639:140088]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1434:192059]
:POSTROUTING ACCEPT [1434:192059]
*filter
:INPUT ACCEPT [10:767]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17:2073]
Ich kann gerade nicht sagen, warum deine fail2ban-Regeln nicht vollständig wirken, allerdings solltest du parallel dazu auch mal deine kompletten Regeln mal daraufhin überprüfen, ob dein System mit den Regeln auch funktioniert, wenn du die Policies der einzelnen Chains von ACCEPT auf DROP setzt. Policies sind die letzte Aktion einer Chain, die nach allen Regeln angewandt wird. Im Falle von ACCEPT werden also alle Pakete angenommen, die es bis dahin schaffen, und bei DROP werden sie eben verworfen. Das beantwortet vielleicht nicht die ursprüngliche Frage, führt aber ggf. trotzdem zur gewünschten Wirkung.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
Cranvil schrieb: ...allerdings solltest du parallel dazu auch mal deine kompletten Regeln mal daraufhin überprüfen, ob dein System mit den Regeln auch funktioniert, wenn du die Policies der einzelnen Chains von ACCEPT auf DROP setzt.
Das sollte er keinesfalls tun... zumindest nicht ungeprüft. Greift er auf das System zusätzlich via SSH, SMB, NFS, VNC, RDT, VPN oder sonst wie zu, hat er sich komplett ausgesperrt. Wenn er drop als Policy setzt, muss er das ganze Filter-Konzept darauf ausrichten, also ausdrücklich alle erwünschten Services erlauben. Davon ist in dem Auszug oben aber nichts zu sehen. Experimente mit dem Default-Drop kann er nur wagen, wenn er direkt am Rechner sitzt, mit Bildschirm und Tastatur, keinesfalls bei dem Kenntnisstand remote.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
TomLu schrieb: Cranvil schrieb: ...allerdings solltest du parallel dazu auch mal deine kompletten Regeln mal daraufhin überprüfen, ob dein System mit den Regeln auch funktioniert, wenn du die Policies der einzelnen Chains von ACCEPT auf DROP setzt.
Das sollte er keinesfalls tun... zumindest nicht ungeprüft.
Da hast du recht, mit dem Satz habe ich nicht ausreichend deutlich gemacht, wie riskant das werden kann.
|