So wählen Sie eine effektive Firewall-Richtlinie zur Sicherung Ihrer Server aus

Einführung

Die Verwendung einer Firewall ist ebenso wichtig, intelligente Richtlinienentscheidungen zu treffen, wie die Syntax zu erlernen. Firewalls wie iptables sind darauf ausgelegt, Richtlinien durch Interpretation von Regeln, die vom Administrator festgelegt wurden, durchzusetzen. Als Administrator müssen Sie jedoch wissen, welche Arten von Regeln für Ihre Infrastruktur sinnvoll sind.

Während sich andere Anleitungen auf die Befehle konzentrieren, die zum Starten und Ausführen benötigt werden, werden wir in diesem Leitfaden einige Entscheidungen besprechen, die Sie bei der Implementierung einer Firewall treffen müssen. Diese Entscheidungen beeinflussen das Verhalten Ihrer Firewall, wie stark Ihr Server abgesichert ist und wie er auf verschiedene Bedingungen reagiert. Wir verwenden iptables als spezifisches Beispiel, aber die meisten Konzepte sind allgemein anwendbar.

Festlegen einer Standardrichtlinie

Bei der Konstruktion einer Firewall ist eine der wichtigsten Entscheidungen die Festlegung der Standardrichtlinie. Diese bestimmt, was passiert, wenn der Datenverkehr keiner anderen Regel entspricht. Standardmäßig kann eine Firewall entweder den Datenverkehr, der keiner vorherigen Regel entspricht, akzeptieren (ACCEPT) oder diesen Datenverkehr abweisen (DROP).

Standard-Drop gegenüber Standard-Accept

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

Die Alternative ist eine Standardrichtlinie von DROP. Dies bedeutet, dass der Datenverkehr, der keiner expliziten Regel entspricht, nicht erlaubt ist. Jeder einzelne Dienst muss explizit erlaubt werden, was nach einer erheblichen Menge an Konfiguration im Voraus klingen mag. Dies bedeutet jedoch, dass Ihre Richtlinie auf Sicherheit ausgerichtet ist und Sie genau wissen, was auf Ihrem Server den Datenverkehr empfangen darf. Außerdem werden fast alle vordefinierten Richtlinien diese Vorgehensweise befolgen, was bedeutet, dass Sie auf vorhandenen Standards aufbauen können.

Standard-Drop-Richtlinie gegenüber endgültiger Drop-Regel

Die Wahl einer Standard-Drop-Richtlinie führt zu einer weiteren subtilen Entscheidung. Bei Verwendung von iptables und anderen ähnlichen Firewalls kann die Standardrichtlinie mithilfe der integrierten Richtlinienfunktionalität der Firewall festgelegt werden oder durch das Hinzufügen einer generellen Drop-Regel am Ende der Liste der Regeln implementiert werden.

Der Unterschied zwischen diesen beiden Methoden liegt darin, was passiert, wenn die Firewall-Regeln geleert werden.

Wenn die eingebaute Richtlinienfunktion Ihrer Firewall auf „DROP“ eingestellt ist und Ihre Firewall-Regeln jemals geleert (zurückgesetzt) werden oder bestimmte übereinstimmende Regeln entfernt werden, werden Ihre Dienste sofort für entfernten Zugriff unzugänglich. Dies ist oft eine gute Idee, wenn eine Richtlinie für nicht kritische Dienste festgelegt wird, damit Ihr Server nicht bösartigem Datenverkehr ausgesetzt ist, wenn die Regeln entfernt werden.

Der Nachteil dieser Methode besteht darin, dass Ihre Dienste für Ihre Clients vollständig nicht verfügbar sein werden, bis Sie zulässige Regeln wiederherstellen. Sie könnten sich sogar möglicherweise selbst vom Server aussperren, wenn Sie keinen lokalen oder webbasierten Fernzugriff als Alternative haben.

Die Alternative zur Einstellung einer „Drop“-Richtlinie mit der eingebauten Richtlinienfunktionalität besteht darin, die Standardrichtlinie Ihrer Firewall auf „ACCEPT“ zu setzen und dann eine „DROP“-Richtlinie mit regulären Regeln zu implementieren. Sie können eine normale Firewall-Regel am Ende Ihrer Kette hinzufügen, die den verbleibenden, nicht übereinstimmenden Datenverkehr erfasst und ablehnt.

In diesem Fall sind Ihre Dienste bei geleerten Firewall-Regeln zugänglich, aber ungeschützt. Je nach Ihren Optionen für lokalen oder alternativen Zugriff kann dies ein notwendiges Übel sein, um sicherzustellen, dass Sie Ihren Server erneut betreten können, wenn die Regeln geleert werden. Wenn Sie sich für diese Option entscheiden, stellen Sie sicher, dass die Sammelregel immer die letzte Regel in Ihrem Regelwerk ist.

Dropping vs Ablehnen von Datenverkehr

Es gibt verschiedene Möglichkeiten, zu verhindern, dass ein Paket sein Ziel erreicht. Die Wahl zwischen diesen Methoden hat Auswirkungen darauf, wie der Client seinen Verbindungsaufbau wahrnimmt und wie schnell er feststellen kann, dass seine Anfrage nicht bedient wird.

Die erste Möglichkeit, Pakete zu verweigern, besteht darin, sie mit DROP abzulehnen. Drop kann als Standardrichtlinie oder als Ziel für Übereinstimmungsregeln verwendet werden. Wenn ein Paket abgelehnt wird, wirft iptables es einfach weg. Es sendet keine Antwort an den Client, der versucht, eine Verbindung herzustellen, und gibt keine Anzeige, dass es die betreffenden Pakete überhaupt erhalten hat. Das bedeutet, dass Clients (legitim oder nicht) keine Bestätigung über den Empfang ihrer Pakete erhalten.

Bei TCP-Verbindungsaufbauversuchen (wie Verbindungen, die von einem Webbrowser hergestellt werden) wird die Verbindung bis zum Erreichen des Timeout-Limits angehalten. Das Fehlen einer Antwort für UDP-Clients ist noch unklarer. Tatsächlich ist das Nichterhalten eines UDP-Pakets oft ein Hinweis darauf, dass das Paket akzeptiert wurde. Wenn der UDP-Client Wert auf den Empfang seiner Pakete legt, muss er sie erneut senden, um festzustellen, ob sie akzeptiert wurden, während des Transports verloren gegangen sind oder abgelehnt wurden. Dies kann die Zeit erhöhen, die ein bösartiger Akteur aufwenden muss, um Informationen über den Zustand Ihrer Server-Ports zu erhalten, kann aber auch Probleme mit legitimem Datenverkehr verursachen.

Eine Alternative zum Abwerfen des Verkehrs besteht darin, Pakete explizit abzulehnen, die nicht erlaubt sind. ICMP, oder Internet Control Message Protocol, ist ein Metaprotokoll, das im gesamten Internet verwendet wird, um Status-, Diagnose- und Fehlermeldungen zwischen Hosts als Out-of-Band-Kanal zu senden, der nicht auf herkömmlichen Kommunikationsprotokollen wie TCP oder UDP basiert. Wenn Sie das REJECT-Ziel anstelle des DROP-Ziels verwenden, wird der Verkehr abgelehnt und ein ICMP-Paket an den Absender zurückgesendet, um ihn darüber zu informieren, dass ihr Verkehr empfangen wurde, aber nicht akzeptiert wird. Es kann auch eine Statusmeldung enthalten sein, um einen Grund anzugeben.

Dies hat mehrere Konsequenzen. Vorausgesetzt, dass ICMP-Verkehr den Client erreichen kann, wird ihm sofort mitgeteilt, dass ihr Verkehr blockiert ist. Für legitime Clients bedeutet dies, dass sie sich an den Administrator wenden oder ihre Verbindungsoptionen überprüfen können, um sicherzustellen, dass sie den richtigen Port erreichen. Für bösartige Benutzer bedeutet dies, dass sie ihre Scans abschließen und die offenen, geschlossenen und gefilterten Ports in kürzerer Zeit kartieren können.

Es gibt viele Dinge zu beachten, wenn Sie sich entscheiden, ob der Verkehr abgeworfen oder abgelehnt werden soll. Eine wichtige Überlegung ist, dass der Großteil des bösartigen Verkehrs tatsächlich von automatisierten Skripten verursacht wird. Da diese Skripte in der Regel nicht überwacht werden, wird das Abwerfen von nicht legitimen Verkehr sie nicht wesentlich abschrecken und negative Auswirkungen auf legitime Benutzer haben. Mehr zu diesem Thema finden Sie auf der Website von Peter Benie.

Drop vs Reject Response Tabelle

Die Tabelle unten zeigt, wie ein Server, der durch eine Firewall geschützt ist, je nach angewandter Richtlinie auf den Zielhafen auf verschiedene Anfragen reagiert.

Client Packet Type NMap Command Port Policy Response Inferred Port State
TCP nmap [-sT | -sS] -Pn <server> Accept TCP SYN/ACK Open
TCP nmap [-sT | -sS] -Pn <server> Drop (none) Filtered
TCP nmap [-sT | -sS] -Pn <server> Reject TCP RESET Closed
UDP nmap -sU -Pn <server> Accept (none) Open or Filtered
UDP nmap -sU -Pn <server> Drop (none) Open or Filtered
UDP nmap -sU -Pn <server> Reject ICMP Port Unreachable Closed

In der ersten Spalte wird der vom Client gesendete Pakettyp angezeigt. Die zweite Spalte enthält die nmap-Befehle, die verwendet werden können, um jedes Szenario zu testen. Die dritte Spalte gibt die auf den Hafen angewandte Richtlinie an. Die vierte Spalte ist die Antwort, die der Server zurückschickt, und die fünfte Spalte ist das, was der Client über den Hafen anhand der erhaltenen Antwort ableiten kann.

ICMP-Richtlinien

Wie bei der Entscheidung, ob verworfener Datenverkehr abgelehnt oder verworfen werden soll, haben Sie die Möglichkeit, ICMP-Pakete, die für Ihren Server bestimmt sind, zu akzeptieren oder abzulehnen.

ICMP ist ein Protokoll, das für viele Dinge verwendet wird. Wie bereits erwähnt, wird es häufig zurückgesendet, um Statusinformationen über Anfragen mit anderen Protokollen zu geben. Eine seiner beliebtesten Funktionen besteht darin, Netzwerk-Pings zu senden und auf diese zu antworten, um die Verbindungsfähigkeit mit entfernten Hosts zu überprüfen. Es gibt viele andere Verwendungen für ICMP, die nicht so weit verbreitet sind, aber dennoch nützlich.

ICMP-Pakete werden nach „Typ“ und dann weiter nach „Code“ organisiert. Ein Typ gibt die allgemeine Bedeutung der Nachricht an. Zum Beispiel bedeutet Typ 3, dass das Ziel nicht erreichbar war. Ein Code wird oft verwendet, um weitere Informationen über einen Typ anzugeben. Zum Beispiel bedeutet ICMP-Typ 3 Code 3, dass der Zielport nicht verfügbar war, während ICMP-Typ 3 Code 0 bedeutet, dass das Zielnetzwerk nicht erreicht werden konnte.

Einige ICMP-Typen sind veraltet und können bedingungslos blockiert werden. Dazu gehören ICMP-Quench (Typ 4 Code 0) und alternativer Host (Typ 6). Die Typen 1, 2, 7 und Typ 15 und höher sind alle veraltet, für zukünftige Verwendung reserviert oder experimentell. Viele Upstream-Firewall-Vorlagen behandeln dies standardmäßig.

Zu blockierende Typen, abhängig von der Netzwerkkonfiguration

Einige ICMP-Typen sind in bestimmten Netzwerkkonfigurationen nützlich, sollten aber in anderen blockiert werden.

Zum Beispiel können ICMP-Redirect-Nachrichten (Typ 5) in bestimmten Netzwerkkonfigurationen nützlich sein, um eine schlechte Netzwerkarchitektur aufzuzeigen. Ein ICMP-Redirect wird gesendet, wenn eine bessere Route direkt für den Client verfügbar ist. Wenn also ein Router ein Paket empfängt, das an einen anderen Host im selben Netzwerk geroutet werden muss, sendet er eine ICMP-Redirect-Nachricht, um dem Client mitzuteilen, dass er die Pakete in Zukunft durch den anderen Host senden soll.

Dies ist nützlich, wenn Sie Ihrem lokalen Netzwerk vertrauen und ineffiziente Routing-Tabellen während der anfänglichen Konfiguration erkennen möchten. In einem nicht vertrauenswürdigen Netzwerk könnte ein bösartiger Benutzer potenziell ICMP-Umleitungen senden, um die Routing-Tabellen auf Hosts zu manipulieren.

Andere ICMP-Typen, die in einigen Netzwerken nützlich und potenziell schädlich in anderen sind, sind ICMP-Router-Ankündigungen (Typ 9) und Router-Anfragen (Typ 10). Router-Ankündigungs- und Anfragepakete werden als Teil des ICMP Internet Router Discovery Protocol (IRDP) verwendet, einem System, das es Hosts ermöglicht, beim Hochfahren oder beim Beitritt zu einem Netzwerk verfügbare Router dynamisch zu entdecken.

In den meisten Fällen ist es besser, dass ein Host statische Routen für die Gateways konfiguriert, die er verwenden wird. Diese Pakete sollten in denselben Situationen akzeptiert werden wie die ICMP-Umleitungs-Pakete. Tatsächlich sind Umleitungs-Nachrichten oft direkt nach der Entdeckung erforderlich, da der Host die bevorzugte Route für den Verkehr der entdeckten Routen nicht kennt. Wenn Sie keinen Dienst ausführen, der Router-Anfragepakete sendet oder Ihre Routen basierend auf Anzeigenpaketen modifiziert (wie z.B. rdisc), können Sie diese Pakete sicher blockieren.

Typen, die normalerweise sicher erlaubt werden können

ICMP-Typen, die normalerweise sicher erlaubt werden können, sind unten aufgeführt, aber Sie möchten sie möglicherweise deaktivieren, wenn Sie besonders vorsichtig sein möchten.

  • Typ 8 – Echo-Anforderung: Dies sind Ping-Anfragen, die an Ihren Server gerichtet sind. Es ist in der Regel sicher, diese zuzulassen (das Ablehnen dieser Pakete verbirgt Ihren Server nicht, da es viele andere Möglichkeiten für Benutzer gibt, herauszufinden, ob Ihr Host verfügbar ist), aber Sie können sie blockieren oder die Quelladressen einschränken, auf die Sie antworten möchten.
  • Typ 13 – Zeitstempel-Anforderung: Diese Pakete können von Clients verwendet werden, um Latenzinformationen zu sammeln. Sie können in einigen OS-Fingerabdrucktechniken verwendet werden, daher können Sie sie blockieren oder den Adressbereich einschränken, auf den Sie antworten.

Die unten aufgeführten Typen können in der Regel ohne explizite Regeln zugelassen werden, indem Sie Ihre Firewall so konfigurieren, dass sie auf Anfragen, die sie erstellt hat, antwortet (indem Sie das Modul conntrack verwenden, um ESTABLISHED und RELATED -Traffic zuzulassen).

  • Typ 0 – Echo-Antworten: Dies sind Antworten auf Echo-Anforderungen (Pings).
  • Typ 3 – Ziel nicht erreichbar: Legitime Ziel-nicht-erreichbar-Pakete sind Antworten auf Anfragen, die von Ihrem Server erstellt wurden und angeben, dass das Paket nicht zugestellt werden konnte.
  • Typ 11 – Zeitaufwand überschritten: Dies ist ein diagnostischer Fehler, der zurückgegeben wird, wenn ein Paket, das von Ihrem Server generiert wurde, vor Erreichen des Ziels gestorben ist, weil seine TTL-Wert überschritten wurde.
  • Typ 12 – Parameterproblem: Dies bedeutet, dass ein ausgehendes Paket von Ihrem Server fehlerhaft war.
  • Typ 14 – Zeitstempelantworten: Dies sind die Antworten auf Zeitstempelabfragen, die von Ihrem Server generiert wurden.

Das Blockieren des gesamten eingehenden ICMP-Verkehrs wird immer noch von einigen Sicherheitsexperten empfohlen, jedoch ermutigen viele Menschen jetzt intelligente ICMP-Akzeptanzrichtlinien. Diese beiden Stackexchange Threads enthalten weitere Informationen.

Verbindungsbegrenzung und Ratenbegrenzung

Für einige Dienste und Verkehrsmuster möchten Sie möglicherweise den Zugriff nur dann zulassen, solange der Client diesen Zugriff nicht missbraucht. Zwei Möglichkeiten zur Begrenzung der Ressourcennutzung sind die Verbindungsbegrenzung und die Ratenbegrenzung.

Verbindungsbegrenzung

Die Verbindungsbegrenzung kann mithilfe von Erweiterungen wie connlimit implementiert werden, um zu prüfen, wie viele aktive Verbindungen ein Client geöffnet hat. Dies kann verwendet werden, um die Anzahl der gleichzeitig erlaubten Verbindungen zu beschränken. Wenn Sie sich dafür entscheiden, Verbindungsbegrenzungen festzulegen, müssen Sie einige Entscheidungen treffen:

  • Begrenzen Sie auf einer pro-Adresse, pro-Netzwerk oder globalen Basis?
  • Passen Sie den Datenverkehr für einen bestimmten Dienst oder für den Server als Ganzes an und beschränken Sie ihn?

Verbindungen können auf Host-weise begrenzt werden, oder eine Begrenzung kann für ein Netzwerksegment festgelegt werden, indem ein Netzwerkpräfix bereitgestellt wird (wie z.B. ein IP-Adressbereich für eine gesamte Organisation). Sie können auch eine globale maximale Anzahl von Verbindungen für einen Dienst oder die gesamte Maschine festlegen. Beachten Sie, dass es möglich ist, diese zu mischen und anzupassen, um komplexere Richtlinien zur Steuerung Ihrer Verbindungszahlen zu erstellen.

Rate-Begrenzung

Die Rate-Begrenzung ermöglicht es Ihnen, Regeln zu erstellen, die die Rate oder Häufigkeit regeln, mit der der Datenverkehr von Ihrem Server akzeptiert wird. Es gibt eine Reihe verschiedener Firewall-Erweiterungen, die für die Rate-Begrenzung verwendet werden können, darunter limit, hashlimit und recent. Die Wahl der Erweiterung, die Sie verwenden, hängt weitgehend davon ab, wie Sie den Datenverkehr begrenzen möchten.

Die Erweiterung limit führt dazu, dass die betreffende Regel abgeglichen wird, bis die Grenze erreicht ist, wonach weitere Pakete verworfen werden. Eine Begrenzung wie 5/sec erlaubt es, dass 5 Pakete pro Sekunde abgeglichen werden, wonach die Regel nicht mehr übereinstimmt. Dies eignet sich gut, um eine globale Rate-Begrenzung für einen Dienst festzulegen. Sie können auch einen zusätzlichen Dienst wie Fail2ban bereitstellen, um wiederholte Verbindungsversuche zu blockieren.

Die Erweiterung hashlimit ist flexibler und ermöglicht es Ihnen, einige der Werte anzugeben, die iptables zum Hashen verwenden wird, um eine Übereinstimmung zu bewerten. Zum Beispiel kann es die Quelladresse, den Quellport, die Zieladresse, den Zielport oder eine Kombination dieser vier Werte betrachten, um jeden Eintrag zu bewerten. Es kann die Anzahl der Pakete oder die empfangenen Bytes begrenzen. Dies ermöglicht eine flexible Begrenzung der Rate pro Client oder pro Dienst.

Die Erweiterung recent fügt dynamisch IP-Adressen des Clients zu einer Liste hinzu oder überprüft sie gegen eine vorhandene Liste, wenn die Regel übereinstimmt. Dadurch können Sie Ihre Begrenzungslogik über eine Reihe verschiedener Regeln für komplexe Muster verteilen. Sie hat die Möglichkeit, eine Trefferzahl und einen Zeitbereich wie die anderen Begrenzer anzugeben, kann jedoch auch den Zeitbereich zurücksetzen, wenn zusätzlicher Datenverkehr erkannt wird, und einen Client zwingen, den gesamten Datenverkehr zu stoppen, wenn er begrenzt wird.

Monolithische vs. Kettenbasierte Verwaltung

Alle Firewall-Richtlinien für iptables und nftables basieren im Wesentlichen darauf, die integrierten Ketten zu erweitern. Zunächst bedeutet dies normalerweise, die Standardrichtlinie für die vorhandenen Ketten zu ändern und Regeln hinzuzufügen. Für komplexere Firewalls ist es oft eine gute Idee, das Verwaltungssystem zu erweitern, indem zusätzliche Ketten erstellt werden.

Benutzererstellte Ketten werden sekundär genannt und sind inhärent an ihre „Aufrufkette“ gebunden, von der sie stammen. Benutzererstellte Ketten haben keine Standardrichtlinie, daher wird ein Paket, das durch eine benutzererstellte Kette fällt, zur Aufrufkette zurückkehren und die Auswertung fortsetzen. Mit diesem Hintergrund sind benutzererstellte Ketten hauptsächlich für organisatorische Zwecke nützlich, um die Bedingungen für Regelübereinstimmungen besser wartbar zu machen und die Lesbarkeit durch Aufteilung der Übereinstimmungsbedingungen zu verbessern.

Wenn Sie feststellen, dass Sie bestimmte Übereinstimmungskriterien für eine große Anzahl von Regeln wiederholen, könnte es sinnvoll sein, eine Sprungregel mit den gemeinsamen Übereinstimmungskriterien zu einer neuen Kette zu erstellen. Innerhalb der neuen Kette können Sie diesen Satz von Regeln mit den überflüssigen Übereinstimmungskriterien hinzufügen.

Die Entscheidung, ob Sie alle Ihre Regeln in eine der integrierten Ketten zusammenfassen oder ob Sie zusätzliche Ketten erstellen und nutzen möchten, hängt davon ab, wie komplex Ihr Regelwerk ist.

Schlussfolgerung

Sie sollten nun ein besseres Verständnis für die Entscheidungen haben, die Sie treffen müssen, wenn Sie Firewall-Richtlinien für Ihre Server entwerfen. In der Regel liegt der Zeitaufwand für Firewalls schwerpunktmäßig beim initialen Setup. Auch wenn es einige Zeit und Experimente erfordern kann, um eine Richtlinie zu entwickeln, die Ihren Anforderungen am besten entspricht, werden Sie dadurch mehr Kontrolle über die Sicherheit Ihres Servers erhalten.

Wenn Sie mehr über Firewalls und iptables erfahren möchten, lesen Sie die folgenden Artikel:

Die folgenden Anleitungen können Ihnen helfen, Ihre Richtlinien umzusetzen. Wählen Sie die Anleitung aus, die zu Ihrer Firewall passt, um loszulegen:

Source:
https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secure-your-servers