• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

iptables konfigurieren

Webslave

New Member
Hallo,

ich suche ein gut beschriebenes, deutsches Tutorial welches sich mit der Einrichtung von iptables, wenn möglich unter debian befasst.

Vielen Dank und Grüße,
Webslave
 
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
 
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
 
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.

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?
 
...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.
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
Zusätzlich ist natürlich SSH so konfiguriert, dass kein Root-Login möglich und nur PublicKey-Authentication erlaubt ist.
 
Back
Top