Hi werte Community,
lasst euch bitte nicht von der Fülle des Textes abschrecken, dies ist nur mein Standpunkt zu dem Thema und bitte um Rückmeldung ob ich damit alleine bin oder ihr es anders macht
in letzter Zeit habe ich des öfteren gelesen (und auch im Freundeskreis ein paar Diskussionen zu dem Thema gehabt), dass manche User alle Ports bis auf ein paar bestimmte auf ihren Root-Servern blockieren. Freigegeben sind dann quasi nur 21, 80, 443 und was sie sonst noch brauchen.
Nun will ich hier nicht über die User herziehen, ich möchte auch keinen angreifen weil er so was macht. Aber ich verstehe einfach nicht, was es bringen soll (ausser Problemen wenn man mal was neues installiert) die Ports via iptables oder Konsorten generell zu blockieren.
Ich habe selbst mehrere Rootserver die ich verwalte und auf keiner ist eine Firewall aktiv. Trotzdem würde ich diese als sicher bezeichnen, da ich diverse (sinnvollere) andere Maßnahmen zur Absicherung getroffen habe.
Mir erschließt es sich einfach nicht, warum man sowas tun sollte. Wenn an einem Port kein Programm lauscht, dann ist dieser Port dicht. Egal ob mit einer Firewall gesichert oder nicht, durch den Port kommt kein Angreifer rein.
Nun könnte man meinen, dass mit den iptables verhindert wird, dass Schadprogramme Ports öffnen und so den Angreifer reinlassen können. Dies mag zwar schon stimmen, jedoch ist es dann auch schon zu spät dies zu blocken. Sobald ein Angreifer mal soweit ist, Befehle auszuführen, ist es nur noch eine Frage der Zeit bis er sich einen dauerhaften Zugang beschafft hat.
Das erst was ein Angreifer mit einem Server macht sobald er Zugriff auf die Shell hat / eigene Befehle ausführen kann, ist sich root Zugang zu beschaffen (die Kiste "rooten"). Sobald er root-Rechte hat ist es egal was ihr für eine Firewall installiert habt oder welche iptables-Regeln festgelegt sind. Der Angreifer löscht diese einfach und schon kann er eigene Server drauf laufen lassen, wenn er möchte. Da offene Ports aber schneller auffallen verändert dieser meist einfach nur ein paar Konfiguraitonsdateien, um zum Beispiel Mails über den Server verschicken zu können.
Viel wichtiger als stundenlanges konfigurieren einer Firewall (und sich dann darauf zu verlassen) finde ich die Konfiguration der Dienste. Diese sind und bleiben nämlich das Einfallstor #1. Was hilft es den SSH-Port nur für das /24 Netz des heimischen ISP freizuschalten wenn auf dem Webspace ein verwundbares PHP-Script liegt? Wenn man sich dann darauf verlässt, dass die iptables Regel reicht, dann täuscht man sich. Ein einfaches fail2ban Script um Bruteforce-Angriffe auf SSH abzuwehren ist schnell eingerichtet und verrichtet seine Aufgabe zuverlässig. Ausserdem sorgen die regelmäßigen Benachrichtigungen auch für eine Art Beweis, dass der Server noch sicher ist.
Abschließend bin ich der Meinung, dass Firewalls und iptables-Regeln für die Sicherheit nur Snake-Oil sind und keinen Mehrwert bieten.
Das waren mal ein paar Gedanken, direkt ausm Kopf runtergeschrieben. Wie steht ihr zu dem Thema, was haltet ihr von den Firewalls?
Grüße,
BK
lasst euch bitte nicht von der Fülle des Textes abschrecken, dies ist nur mein Standpunkt zu dem Thema und bitte um Rückmeldung ob ich damit alleine bin oder ihr es anders macht
in letzter Zeit habe ich des öfteren gelesen (und auch im Freundeskreis ein paar Diskussionen zu dem Thema gehabt), dass manche User alle Ports bis auf ein paar bestimmte auf ihren Root-Servern blockieren. Freigegeben sind dann quasi nur 21, 80, 443 und was sie sonst noch brauchen.
Nun will ich hier nicht über die User herziehen, ich möchte auch keinen angreifen weil er so was macht. Aber ich verstehe einfach nicht, was es bringen soll (ausser Problemen wenn man mal was neues installiert) die Ports via iptables oder Konsorten generell zu blockieren.
Ich habe selbst mehrere Rootserver die ich verwalte und auf keiner ist eine Firewall aktiv. Trotzdem würde ich diese als sicher bezeichnen, da ich diverse (sinnvollere) andere Maßnahmen zur Absicherung getroffen habe.
Mir erschließt es sich einfach nicht, warum man sowas tun sollte. Wenn an einem Port kein Programm lauscht, dann ist dieser Port dicht. Egal ob mit einer Firewall gesichert oder nicht, durch den Port kommt kein Angreifer rein.
Nun könnte man meinen, dass mit den iptables verhindert wird, dass Schadprogramme Ports öffnen und so den Angreifer reinlassen können. Dies mag zwar schon stimmen, jedoch ist es dann auch schon zu spät dies zu blocken. Sobald ein Angreifer mal soweit ist, Befehle auszuführen, ist es nur noch eine Frage der Zeit bis er sich einen dauerhaften Zugang beschafft hat.
Das erst was ein Angreifer mit einem Server macht sobald er Zugriff auf die Shell hat / eigene Befehle ausführen kann, ist sich root Zugang zu beschaffen (die Kiste "rooten"). Sobald er root-Rechte hat ist es egal was ihr für eine Firewall installiert habt oder welche iptables-Regeln festgelegt sind. Der Angreifer löscht diese einfach und schon kann er eigene Server drauf laufen lassen, wenn er möchte. Da offene Ports aber schneller auffallen verändert dieser meist einfach nur ein paar Konfiguraitonsdateien, um zum Beispiel Mails über den Server verschicken zu können.
Viel wichtiger als stundenlanges konfigurieren einer Firewall (und sich dann darauf zu verlassen) finde ich die Konfiguration der Dienste. Diese sind und bleiben nämlich das Einfallstor #1. Was hilft es den SSH-Port nur für das /24 Netz des heimischen ISP freizuschalten wenn auf dem Webspace ein verwundbares PHP-Script liegt? Wenn man sich dann darauf verlässt, dass die iptables Regel reicht, dann täuscht man sich. Ein einfaches fail2ban Script um Bruteforce-Angriffe auf SSH abzuwehren ist schnell eingerichtet und verrichtet seine Aufgabe zuverlässig. Ausserdem sorgen die regelmäßigen Benachrichtigungen auch für eine Art Beweis, dass der Server noch sicher ist.
Abschließend bin ich der Meinung, dass Firewalls und iptables-Regeln für die Sicherheit nur Snake-Oil sind und keinen Mehrwert bieten.
Das waren mal ein paar Gedanken, direkt ausm Kopf runtergeschrieben. Wie steht ihr zu dem Thema, was haltet ihr von den Firewalls?
Grüße,
BK
