iptables konfigurieren
- Thread starter Webslave
- Start date
wstuermer
Active Member
Und wers gern Klicki-Bunti mag:
Firewall Builder
Firewall Builder
Ein Standardwerk zum Thema ist Ralf Spennebergs Buch "Linux Firewalls mit iptables&Co", die meisten Kapitel sind zur Zeit online als PDF erhältlich unter: Linux Bücher: OpenSource Training Ralf Spenneberg
Das hier im Forum schon öfters empfohlene Werk "Linux-Server mit Debian GNU/Linux" enthält ebenfalls ein Kapitel über iptables.
Das hier im Forum schon öfters empfohlene Werk "Linux-Server mit Debian GNU/Linux" enthält ebenfalls ein Kapitel über iptables.
Danke soweit erstmal.
Ich habe jetzt nochmal bisschen rumgestöbert hab oftmals gelesen das iptables allein kein Sinn macht... in wiefern ist da was dran?
Was für Absicherungen sind außer mod-security für einen Web/Rootserver noch von Vorteil?
SSH ist bereits abgesichert und liegt auf einem anderen Port.
Danke + Grüße,
Webslave
Ich habe jetzt nochmal bisschen rumgestöbert hab oftmals gelesen das iptables allein kein Sinn macht... in wiefern ist da was dran?
Was für Absicherungen sind außer mod-security für einen Web/Rootserver noch von Vorteil?
SSH ist bereits abgesichert und liegt auf einem anderen Port.
Danke + Grüße,
Webslave
Hi,
um es gleich mal vorne weg zu sagen, eine Firewall macht bei einem Webserver nur bedingt Sinn, es kommt hierbei auf deinen Server bzw. die von die angebotenen Dienste an. Wenn du alle Dienste die nach aussen hin geöffnet sind, d.h. nach extern gebunden sind auch anbieten möchtest, dann brauchst du auch keine Firewall. Höchstens für die OUTPUT CHAIN, damit mögliche Sicherheitslücken in deinen Skripten nicht ausgenutzt werden können um beispielsweise von einem anderen Systeme irgendwelche Skripte zu laden, die dein System vollständig kompromitieren.
Ein zweiter Anwendungsfall wäre, wenn du beispielsweise angegriffen wirst, Pakete des Angreifers sofort zu droppen bevor Sie bei mod_securtiy oder Konsorten ankommen. Denkbar sind auch Anti-DoS Masnahmen via connection-limit/burst-limit.
Was ich damit sagen möchte ist, dass es immer auf den speziellen Fall und die von deinem System angebotenen Dienste ankommt. Man kann nicht pauschal sagen, ob es Sinn macht eine Firewall zu aktivieren.
Offtopic: Dieses verlegen des SSH Port's ist sicher eine geeignete Methode um wirklich rudimentäre Skripts abzuhalten eine Dictonary-Attack's o.ä. zu starten, aber um wirklich sicher zu gehen kann ich dir nur empfehlen einfach komplett auf PublicKey Authentication umzuschalten, dann brauchst du dir um solche Dinge erst gar keinen Kopf machen.
Stephan
um es gleich mal vorne weg zu sagen, eine Firewall macht bei einem Webserver nur bedingt Sinn, es kommt hierbei auf deinen Server bzw. die von die angebotenen Dienste an. Wenn du alle Dienste die nach aussen hin geöffnet sind, d.h. nach extern gebunden sind auch anbieten möchtest, dann brauchst du auch keine Firewall. Höchstens für die OUTPUT CHAIN, damit mögliche Sicherheitslücken in deinen Skripten nicht ausgenutzt werden können um beispielsweise von einem anderen Systeme irgendwelche Skripte zu laden, die dein System vollständig kompromitieren.
Ein zweiter Anwendungsfall wäre, wenn du beispielsweise angegriffen wirst, Pakete des Angreifers sofort zu droppen bevor Sie bei mod_securtiy oder Konsorten ankommen. Denkbar sind auch Anti-DoS Masnahmen via connection-limit/burst-limit.
Was ich damit sagen möchte ist, dass es immer auf den speziellen Fall und die von deinem System angebotenen Dienste ankommt. Man kann nicht pauschal sagen, ob es Sinn macht eine Firewall zu aktivieren.
Offtopic: Dieses verlegen des SSH Port's ist sicher eine geeignete Methode um wirklich rudimentäre Skripts abzuhalten eine Dictonary-Attack's o.ä. zu starten, aber um wirklich sicher zu gehen kann ich dir nur empfehlen einfach komplett auf PublicKey Authentication umzuschalten, dann brauchst du dir um solche Dinge erst gar keinen Kopf machen.
Stephan
Hab ich beides gemacht... also auf einen anderen Port gelegt und mit PublicKey Auth.
Naja ich meine eben was ich noch machen kann um eben Angriffe auch auf Scripte abzuwehren?
Die beste Absicherung von SSH und anderen administrativen oder nicht genutzten Diensten auf einem v/Root-Server liegt meiner Meinung nach darin, einem Angreifer keine Antwort zu geben, also mit Hilfe von iptables unerwünschte Pakete zu DROPen. Ohne iptables kann ein Angreifer aus den Fehlermeldungen ableiten, ob SSH auf dem abgefragten Port läuft, ob PublicKey Auth oder Passwörter verwendet werden, vielleicht kann er auch Rückschlüsse auf die verwendete Linux-Disitribution ziehen.
Ich habe jetzt seit einem Monat einen vServer, in der Zeit gab es 22.688 erfolglose Versuche, einen SSH-Benutzer und Passwort zu erraten, alleine 6.000mal für root. Die meisten Hackversuche kommen anscheinend aus Russland und China.
Aus dem Adressbereich meines Internetproviders gab es keinen einzigen Zugriffsversuch. Daher habe ich vor, SSH mit folgender iptables-Regel abzusichern, die nur Zugriffe über meinen Provider mit dem (fiktiven) Adressbereich 47.11/16 = 47.11.*.* erlaubt:
Code:
-A RH-Firewall-1-INPUT -s 47.11/16 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -j DROP