{"id":14025,"date":"2025-10-14T13:27:56","date_gmt":"2025-10-14T11:27:56","guid":{"rendered":"https:\/\/webhosting.de\/firewall-regeln-webserver-iptables-ufw-praxisbeispiele-securehost\/"},"modified":"2025-10-14T13:27:56","modified_gmt":"2025-10-14T11:27:56","slug":"%d0%bf%d1%80%d0%b0%d0%b2%d0%b8%d0%bb%d0%b0-%d0%b1%d1%80%d0%b0%d0%bd%d0%b4%d0%bc%d0%b0%d1%83%d1%8d%d1%80%d0%b0-%d0%b2%d0%b5%d0%b1-%d1%81%d0%b5%d1%80%d0%b2%d0%b5%d1%80-iptables-ufw-%d0%bf%d1%80%d0%b0","status":"publish","type":"post","link":"https:\/\/webhosting.de\/ru\/firewall-regeln-webserver-iptables-ufw-praxisbeispiele-securehost\/","title":{"rendered":"\u041f\u0440\u0430\u0432\u0438\u043b\u0430 \u0431\u0440\u0430\u043d\u0434\u043c\u0430\u0443\u044d\u0440\u0430 \u0434\u043b\u044f \u0432\u0435\u0431-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432: \u041f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u043f\u0440\u0438\u043c\u0435\u0440\u044b \u0434\u043b\u044f iptables \u0438 UFW"},"content":{"rendered":"<p><strong>Firewall iptables<\/strong> und UFW steuern, welche Verbindungen ein Webserver akzeptiert und welche ich blockiere \u2013 das entscheidet \u00fcber Angriffsfl\u00e4che und Ausf\u00e4lle. In diesem Praxisartikel zeige ich klare Regeln, sichere Defaults und getestete Befehle f\u00fcr SSH, HTTP(S), Datenbanken, Logging, IPv6 und Docker \u2013 direkt einsetzbar auf produktiven Hosts.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Die folgenden Stichpunkte geben mir eine schnelle Orientierung, bevor ich mit der Konfiguration starte.<\/p>\n<ul>\n  <li><strong>Restriktiv<\/strong> starten: Default-Deny f\u00fcr eingehend, gezielt \u00f6ffnen<\/li>\n  <li><strong>SSH<\/strong> zuerst erlauben: Zugang nicht riskieren<\/li>\n  <li><strong>UFW<\/strong> als Oberfl\u00e4che: einfache Syntax, iptables im Hintergrund<\/li>\n  <li><strong>Logging<\/strong> aktivieren: Regeln pr\u00fcfen, Angriffe erkennen<\/li>\n  <li><strong>Persistenz<\/strong> sicherstellen: Regeln \u00fcber Neustarts erhalten<\/li>\n<\/ul>\n\n<h2>Grundlagen: iptables und UFW im \u00dcberblick<\/h2>\n<p>Ich setze auf <strong>iptables<\/strong>, wenn ich feine Kontrolle \u00fcber Pakete, Chains und Matches brauche. UFW nutze ich, wenn ich schnell verl\u00e4ssliche Regeln anwenden will, die intern als iptables-Regeln landen [1]. So kombiniere ich einfache Befehle mit der Kraft des Linux-Netfilters, ohne mich in Details zu verlieren. F\u00fcr Webserver bedeutet das: Ich baue einen klaren Filter vor Apache, Nginx oder Node, damit nur gew\u00fcnschter Traffic ankommt [2]. Diese Trennung reduziert Angriffsfl\u00e4chen und l\u00e4sst Angriffe h\u00e4ufiger ins Leere laufen.<\/p>\n<p>Beide Tools erg\u00e4nzen sich und ich entscheide situativ, welches passt. UFW punktet mit sauberer Lesbarkeit, gerade auf Ubuntu und Debian [3]. iptables gibt mir erweiterte Optionen, etwa bei NAT, spezifischen Interfaces und komplexen Matches. Wichtig: Ich dokumentiere meine Regeln knapp, damit Wartung sp\u00e4ter leicht f\u00e4llt. Wer das Sicherheitskonzept vertiefen will, findet eine verst\u00e4ndliche Einf\u00fchrung hier: <a href=\"https:\/\/webhosting.de\/firewall-digitaler-schutzschild-netzwerke-webseiten\/\">Firewall als Schutzschild<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall-webserver-setup-6842.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Startkonfiguration: Default-Policies sicher setzen<\/h2>\n<p>Ich beginne mit <strong>Default<\/strong>-Policies: Eingehend blockieren, ausgehend erlauben. So verhindere ich, dass neue Dienste ungewollt erreichbar sind. Loopback lasse ich immer zu, damit interne Prozesse stabil arbeiten. Bestehende Verbindungen akzeptiere ich, um Abbr\u00fcche zu vermeiden. Diese Reihenfolge minimiert Fehler beim Aktivieren der Firewall [2][5].<\/p>\n<p>Mit UFW setze ich die Basis mit wenigen Befehlen. Ich pr\u00fcfe anschlie\u00dfend den Status im Detail, um Tippfehler sofort zu bemerken. Bei besonders sensiblen Hosts schr\u00e4nke ich auch ausgehende Ports ein. Damit senke ich das Risiko von Datenabfluss, falls ein Dienst kompromittiert wurde. Die folgenden Befehle setze ich h\u00e4ufig ein:<\/p>\n<pre><code># UFW: Standardregeln\nsudo ufw default deny incoming\nsudo ufw default allow outgoing\n\n# Alternativ strengere Outbound-Policy\nsudo ufw default deny outgoing\nsudo ufw allow out 53\nsudo ufw allow out 80\nsudo ufw allow out 443\n\n# Status pr\u00fcfen\nsudo ufw status verbose\n<\/code><\/pre>\n\n<h2>Stateful Filtering: Zust\u00e4nde und Reihenfolge<\/h2>\n<p>Ein sauberer Paketfluss steht und f\u00e4llt mit <strong>Conntrack-Zust\u00e4nden<\/strong>. Ich akzeptiere etablierte Verbindungen zuerst, verwerfe ung\u00fcltige Pakete fr\u00fch und lasse Loopback offen. Das reduziert Last und verhindert Seiteneffekte durch sp\u00e4te Drops. F\u00fcr iptables setze ich die Reihenfolge bewusst:<\/p>\n<pre><code># iptables: solide Basis\niptables -P INPUT DROP\niptables -P FORWARD DROP\niptables -P OUTPUT ACCEPT\n\n# Loopback immer erlauben\niptables -A INPUT -i lo -j ACCEPT\niptables -A OUTPUT -o lo -j ACCEPT\n\n# Bestehende\/zugeh\u00f6rige Verbindungen zulassen\niptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\n\n# Ung\u00fcltige Pakete fr\u00fch verwerfen\niptables -A INPUT -m conntrack --ctstate INVALID -j DROP\n<\/code><\/pre>\n<p>Mit UFW werden ESTABLISHED\/RELATED intern bereits ber\u00fccksichtigt. Ich achte zus\u00e4tzlich darauf, ob ich lieber <strong>DROP<\/strong> (still) oder <strong>REJECT<\/strong> (aktiv, schnelleres Failover) verwende. F\u00fcr interne Netze bevorzuge ich REJECT, im Public-Netz meist DROP.<\/p>\n\n<h2>Essenzielle Regeln f\u00fcr Webserver: SSH, HTTP und HTTPS<\/h2>\n<p>Ich schalte <strong>SSH<\/strong> zuerst frei, sonst sperre ich mich leicht aus. Danach erlaube ich HTTP und HTTPS, damit der Webserver erreichbar ist. Ich setze nur die Ports, die ich wirklich brauche. Sp\u00e4ter erg\u00e4nze ich optional Ratenbegrenzung oder Fail2ban, um brutale Anmeldeversuche zu d\u00e4mpfen. Jede \u00c4nderung kontrolliere ich sofort mit Status- oder List-Kommandos.<\/p>\n<p>Die Kommandos daf\u00fcr halte ich simpel. UFW bietet sprechende Aliase f\u00fcr Webports, was die Lesbarkeit erh\u00f6ht. Mit iptables kann ich pr\u00e4zise Ports und Protokolle setzen. Ich speichere iptables-Regeln im Anschluss, damit sie den Neustart \u00fcberstehen. Hier die minimalen Schritte:<\/p>\n<pre><code># SSH\nsudo ufw allow 22\niptables -A INPUT -p tcp --dport 22 -j ACCEPT\n\n# HTTP\/HTTPS\nsudo ufw allow http\nsudo ufw allow https\niptables -A INPUT -p tcp --dport 80 -j ACCEPT\niptables -A INPUT -p tcp --dport 443 -j ACCEPT\n<\/code><\/pre>\n\n<h2>SSH absichern: Begrenzen und gezielt \u00f6ffnen<\/h2>\n<p>Zus\u00e4tzlich zur Freigabe d\u00e4mpfe ich Angriffe mit <strong>Rate-Limiting<\/strong> oder Whitelists. UFW bringt einen einfachen Schutz mit:<\/p>\n<pre><code># SSH-Rate-Limiting (UFW)\nsudo ufw limit 22\/tcp comment \"SSH Rate Limit\"\n<\/code><\/pre>\n<p>Mit iptables setze ich feinere Limits. Das verhindert massives Durchprobieren von Passw\u00f6rtern, ohne legitime Admins auszuschlie\u00dfen:<\/p>\n<pre><code># SSH: Verbindungsversuche pro Quelle begrenzen\niptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set\niptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP\n<\/code><\/pre>\n<p>Wo m\u00f6glich, erlaube ich SSH nur von <strong>Admin-IP-Adressen<\/strong> und arbeite mit SSH-Keys. Ein Portwechsel ist kein Ersatz f\u00fcr Sicherheit, kann aber Rauschen reduzieren. Ich dokumentiere die Ausnahmen und pr\u00fcfe sie regelm\u00e4\u00dfig.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall_webserver_meeting_3784.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Datenbanken absichern und IP-Quellen beschr\u00e4nken<\/h2>\n<p>Datenbankports \u00f6ffne ich nie global, sondern nur <strong>lokal<\/strong> oder f\u00fcr definierte Quell-IP-Adressen. So verhindere ich, dass Scanner offene MySQL-, PostgreSQL- oder MongoDB-Ports finden. F\u00fcr lokale Apps gen\u00fcgt 127.0.0.1 als Ziel, externe Admin-Zugriffe steuere ich strikt per IP. \u00c4nderungen dokumentiere ich kurz, etwa im Server-Wiki. Das spart mir Zeit bei Audits.<\/p>\n<p>Die folgenden Beispiele nutze ich h\u00e4ufig in Projekten. Jede erlaubte IP pr\u00fcfe ich vorab auf Korrektheit. UFW erlaubt eine saubere \u201cfrom-to\u201d-Notation, iptables setzt dieselbe Logik technisch um. F\u00fcr tempor\u00e4re Wartungsfenster nutze ich zus\u00e4tzliche Allow-Regeln und l\u00f6sche sie danach. So bleibt die Oberfl\u00e4che klein:<\/p>\n<pre><code># Nur lokal: MySQL\nsudo ufw allow from 127.0.0.1 to any port 3306\niptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT\n\n# Einzelne IP erlauben\nsudo ufw allow from 203.0.113.10\niptables -A INPUT -s 203.0.113.10 -j ACCEPT\n\n# Port f\u00fcr spezifische IP freigeben\nsudo ufw allow from 10.1.2.3 to any port 4444\niptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT\n\n# Bekannte Angreifer blockieren\nsudo ufw deny from 192.0.2.24\niptables -A INPUT -s 192.0.2.24 -j DROP\n<\/code><\/pre>\n\n<h2>Logging, Interfaces und IPv6 sauber behandeln<\/h2>\n<p>Ich schalte <strong>Logging<\/strong> ein, um Regeln zu verifizieren und auff\u00e4lligen Traffic zu erkennen. Level \u201con\u201d in UFW reicht f\u00fcr die meisten Hosts, h\u00f6here Level nutze ich nur gezielt. Logs werte ich mit journalctl, fail2ban oder SIEM-Tools aus. So erkenne ich Muster von Scans oder Brute-Force-Versuchen. Bei Auff\u00e4lligkeiten passe ich Regeln zeitnah an [2].<\/p>\n<p>Regeln binde ich oft an ein bestimmtes <strong>Interface<\/strong>, etwa eth0 in Public-Netzen. So verhindere ich, dass interne Netze unn\u00f6tig betroffen sind. UFW kann \u201callow in on eth0 to any port 80\u201d, iptables nutzt -i f\u00fcr Eingangsinterfaces. F\u00fcr IPv6 pr\u00fcfe ich die Aktivierung in \/etc\/default\/ufw auf \u201cIPV6=yes\u201d und nutze ip6tables f\u00fcr native Regeln [2]. Diese Trennung vermeidet L\u00fccken bei dual-stack-Hosts.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall-webserver-iptables-ufw-4273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ICMP und ICMPv6: Erreichbarkeit ohne L\u00fccken<\/h2>\n<p>Ich lasse notwendige <strong>ICMP<\/strong>-Typen zu, damit Path MTU Discovery, Timeouts und Diagnose funktionieren. ICMP ist kein Feind, sondern Kern des IP-Protokolls. Ich begrenze nur \u00fcberm\u00e4\u00dfige Echos.<\/p>\n<pre><code># IPv4: Echo begrenzen, wichtige ICMP-Typen erlauben\niptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5\/second --limit-burst 20 -j ACCEPT\niptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT\niptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT\n\n# UFW: ICMP allgemein erlauben (Feintuning in before.rules m\u00f6glich)\nsudo ufw allow in proto icmp\n<\/code><\/pre>\n<p>Unter <strong>IPv6<\/strong> ist ICMPv6 absolut notwendig (Neighbor Discovery, Router Advertisement). Ich erlaube die Kern-Typen und begrenze Echo-Requests:<\/p>\n<pre><code># IPv6 (ip6tables)\nip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT\nip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbor-solicitation -j ACCEPT\nip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbor-advertisement -j ACCEPT\nip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5\/second --limit-burst 20 -j ACCEPT\n<\/code><\/pre>\n\n<h2>Outbound-Restriktion und NAT\/Masquerading richtig nutzen<\/h2>\n<p>Ausgehenden Traffic beschr\u00e4nke ich, wenn ich <strong>Risikoprofil<\/strong> und Compliance sch\u00e4rfen will. Ich erlaube DNS und HTTPS, alles andere blocke ich bis auf definierte Ziele. Das reduziert exfiltrierte Daten, sollte ein Dienst gekapert sein. F\u00fcr Applikationen mit Update- oder API-Bedarf lege ich definierte Ausnahmen an. Ich dokumentiere diese Ausnahmen sauber und pr\u00fcfe sie regelm\u00e4\u00dfig.<\/p>\n<p>F\u00fcr Routing-Setups nutze ich NAT\/Masquerading \u00fcber UFW-Before-Rules oder roh mit iptables. Dabei achte ich auf die Reihenfolge der Chains, damit Pakete korrekt umgeschrieben werden. Nach \u00c4nderungen teste ich Konnektivit\u00e4t und Latenzen. Bei Produktivsystemen plane ich ein Wartungsfenster und sichere die Konfiguration. So halte ich die Netzpfade nachvollziehbar [7].<\/p>\n\n<h2>Outbound-Details: Systemdienste und Protokolle<\/h2>\n<p>Bei strikter Outbound-Policy erlaube ich gezielt <strong>DNS<\/strong> (53\/udp), <strong>HTTPS<\/strong> (443\/tcp) und bei Bedarf <strong>NTP<\/strong> (123\/udp). F\u00fcr Mail-Server erg\u00e4nze ich 25\/tcp und 587\/tcp. Domainbasierte Ausnahmen l\u00f6se ich nicht auf Paketebene, sondern \u00fcber Proxys oder Applikationslogik.<\/p>\n<pre><code># UFW: typische Systemdienste\nsudo ufw allow out 123\/udp  # NTP\nsudo ufw allow out 25\/tcp   # SMTP - nur wenn Mail-Server\nsudo ufw allow out 587\/tcp  # Submission - nur wenn n\u00f6tig\n\n# iptables: gezieltes Allow\niptables -A OUTPUT -p udp --dport 123 -j ACCEPT\niptables -A OUTPUT -p tcp --dport 25 -j ACCEPT\niptables -A OUTPUT -p tcp --dport 587 -j ACCEPT\n<\/code><\/pre>\n\n<h2>Docker und Firewalls: Fallstricke vermeiden<\/h2>\n<p>Docker setzt eigene <strong>iptables<\/strong>-Regeln, die meine Policy beeinflussen k\u00f6nnen. Ich pr\u00fcfe deshalb die NAT- und FORWARD-Ketten nach jedem Compose- bzw. Daemon-Start. Exponierte Ports gebe ich bewusst frei und meide \u201c-p 0.0.0.0:PORT\u201d. Stattdessen binde ich sie an die Management-IP oder den Reverse-Proxy. So bleibt der Angriffsvektor kleiner und besser sichtbar [1].<\/p>\n<p>Ich halte Host-Firewalls trotz Docker aktiv. Zus\u00e4tzlich kontrolliere ich Security-Gruppen auf der Infrastruktur-Ebene, falls vorhanden. Bei Konflikten zwischen UFW und Docker nutze ich dokumentierte Workarounds oder setze Regeln in DOCKER-USER. Wichtig ist eine klare Zust\u00e4ndigkeit: Host blockt grunds\u00e4tzlich, Container \u00f6ffnen nur explizit. Diese Ordnung verhindert unbewusste Freigaben.<\/p>\n<pre><code># DOCKER-USER: globale Host-Policy vor Docker-Regeln durchsetzen\niptables -N DOCKER-USER 2>\/dev\/null || true\niptables -I DOCKER-USER -s 192.0.2.24 -j DROP\niptables -A DOCKER-USER -j RETURN\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall_webserver_nacht_4927.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>UFW-Feineinstellungen: Reihenfolge, Profile und Routed-Traffic<\/h2>\n<p>Wenn Pr\u00e4zision z\u00e4hlt, nutze ich \u201c<strong>insert<\/strong>\u201d, \u201c<strong>numbered<\/strong>\u201d und App-Profile. So halte ich die Regelreihenfolge sauber und nutze getestete Service-Definitionen.<\/p>\n<pre><code># Reihenfolge steuern\nsudo ufw insert 1 deny in from 198.51.100.0\/24\n\n# Nummerierte Ansicht und gezieltes L\u00f6schen\nsudo ufw status numbered\nsudo ufw delete 3\n\n# App-Profile (z. B. Nginx Full)\nsudo ufw app list\nsudo ufw app info \"Nginx Full\"\nsudo ufw allow \"Nginx Full\"\n\n# Routed Traffic standardm\u00e4\u00dfig blockieren (Forwarding)\nsudo ufw default deny routed\n<\/code><\/pre>\n<p>Komplexere Ausnahmen hinterlege ich in <em>before.rules<\/em> bzw. <em>after.rules<\/em>. Dort kann ich ICMP-Feintuning oder NAT exakt platzieren, ohne die Lesbarkeit der Standardregeln zu verlieren.<\/p>\n\n<h2>Persistente Regeln: Speichern und Wiederherstellen<\/h2>\n<p>Mit UFW sind Regeln <strong>persistent<\/strong> und \u00fcberstehen Reboots automatisch. Das vereinfacht Administration deutlich auf Debian\/Ubuntu-Hosts. Bei iptables speichere ich die Regeln nach \u00c4nderungen und spiele sie beim Start wieder ein. Daf\u00fcr nutze ich iptables-save\/restore oder netfilter-persistent. Ohne diese Schritte verliere ich sonst \u00c4nderungen nach einem Neustart [5].<\/p>\n<p>Ich teste Persistenz planvoll: Reboot einplanen, danach Status pr\u00fcfen. Stimmen Z\u00e4hler und Chains, ist die Konfiguration solide. Fehlen Regeln, korrigiere ich den Ladepfad im Init- bzw. Systemd-Kontext. Diese Routine verhindert \u00dcberraschungen w\u00e4hrend Wartungen. Dokumentation und Backup der Regeldateien runden das Vorgehen ab.<\/p>\n<pre><code># Debian\/Ubuntu: Persistenz f\u00fcr iptables\nsudo apt-get install -y iptables-persistent\nsudo netfilter-persistent save\n\n# Manuell sichern\nsudo iptables-save | sudo tee \/etc\/iptables\/rules.v4\nsudo ip6tables-save | sudo tee \/etc\/iptables\/rules.v6\n\n# Wiederherstellen (bei Bedarf)\nsudo iptables-restore &lt; \/etc\/iptables\/rules.v4\nsudo ip6tables-restore &lt; \/etc\/iptables\/rules.v6\n<\/code><\/pre>\n\n<h2>Leistung und Schutz: Limits, Sets und Kernel-Tuning<\/h2>\n<p>Bei hoher Last reduziere ich Regelanzahl und nutze gezielte <strong>Rate-Limits<\/strong>. F\u00fcr gro\u00dfe Blocklisten arbeite ich mit ipset, um Nachschlagezeiten zu verk\u00fcrzen. Zus\u00e4tzlich setze ich systemnahe Schutzmechanismen:<\/p>\n<pre><code># SYN-Flut eind\u00e4mmen (Kernel)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\n# HTTP-Verbindungsrate pro Quell-IP begrenzen (Beispiel)\niptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW \n  -m hashlimit --hashlimit-name http_rate --hashlimit-above 50\/second \n  --hashlimit-burst 100 --hashlimit-mode srcip -j DROP\n<\/code><\/pre>\n<p>Ich behalte die Gr\u00f6\u00dfe der <strong>Conntrack-Tabelle<\/strong> im Blick. Bei vielen gleichzeitigen Verbindungen erh\u00f6he ich nf_conntrack_max, teste aber vorher die Auswirkungen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall_regeln_schreibtisch_2847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Management, Tests und Fehlervermeidung<\/h2>\n<p>Ich lasse <strong>SSH<\/strong> immer zuerst zu, bevor ich \u201cdeny incoming\u201d aktiviere. Danach teste ich aus einer zweiten Session, ob der Zugang stabil bleibt. Jede neue Regel pr\u00fcfe ich mit \u201cufw status verbose\u201d oder \u201ciptables -L -v\u201d. So erkenne ich Trefferz\u00e4hler und sehe, ob Pakete in der erwarteten Chain landen. Backup der Firewall-Dateien setze ich vor gr\u00f6\u00dferen Umbauten an.<\/p>\n<p>F\u00fcr ganzheitliche Sicherheit kombiniere ich die Firewall mit H\u00e4rtungsschritten am System. Dazu z\u00e4hlen sichere SSH-Settings, Patch-Management und minimale Dienste. Einen praxisnahen Leitfaden nutze ich gerne als Checkliste: <a href=\"https:\/\/webhosting.de\/server-hardening-linux-tipps-sicherheit-protection-compliance\/\">Server-Hardening f\u00fcr Linux<\/a>. Ich wiederhole diese Pr\u00fcfungen regelm\u00e4\u00dfig und halte mich an feste Wartungsfenster. Das h\u00e4lt meine Server zuverl\u00e4ssig in Form.<\/p>\n\n<h2>Erweiterte Tests und Beobachtung<\/h2>\n<p>Ich pr\u00fcfe die Au\u00dfenwirkung mit <strong>Port-Scans<\/strong> aus einem externen Netz und verifiziere intern offene Sockets. Logs beobachte ich anfangs engmaschig, um Fehlschl\u00fcsse fr\u00fch zu erkennen.<\/p>\n<pre><code># Offenliegende Sockets\nss -lntup\n\n# iptables-\u00dcbersicht kompakt\nsudo iptables -S\nsudo iptables -L -v -n\n\n# UFW: ausf\u00fchrlicher Status und Logs\nsudo ufw status verbose\njournalctl -k | grep -i ufw\n\n# Externe Pr\u00fcfung (aus anderem Host\/Netz)\nnmap -Pn -p 22,80,443 &lt;HOST&gt;\n<\/code><\/pre>\n<p>F\u00fcr risikoreiche \u00c4nderungen plane ich eine <strong>R\u00fcckfallebene<\/strong> ein. Ich arbeite im Screen\/Tmux und setze falls n\u00f6tig einen zeitgesteuerten R\u00fcckbau, falls ich mich aussperre. Nach erfolgreichem Test hebe ich die R\u00fcckfallaktion wieder auf.<\/p>\n<pre><code># Beispiel: automatisches Deaktivieren als Notanker (vorsichtig verwenden)\necho \"ufw disable\" | at now + 2 minutes\n# Nach erfolgreichem Test wieder l\u00f6schen: atrm &lt;job-id&gt;\n<\/code><\/pre>\n\n<h2>Vergleich Hosting-Anbieter: Firewall-Integration im Fokus<\/h2>\n<p>Bei Hosting setze ich auf <strong>Sicherheit<\/strong> nahe an der Plattform. Individuelle Policies, schnelle Regel-Deployments und gutes Monitoring zahlen sich aus. In aktuellen Vergleichen \u00fcberzeugt webhoster.de mit sauber integrierten Firewall-Optionen und flotter Unterst\u00fctzung. Wer Panel-Setups bevorzugt, profitiert von einer klaren Anleitung zur <a href=\"https:\/\/webhosting.de\/plesk-firewall-konfigurieren-schritt-fuer-schritt-schutz-anleitung-guardian\/\">Plesk-Firewall<\/a>. Die folgende Tabelle ordnet zentrale Kriterien ein.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Anbieter<\/th>\n      <th>Firewall-Integration<\/th>\n      <th>Performance<\/th>\n      <th>Support<\/th>\n      <th>Platzierung<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>webhoster.de<\/td>\n      <td>individuell konfig.<\/td>\n      <td>sehr hoch<\/td>\n      <td>top<\/td>\n      <td><strong>1<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Anbieter B<\/td>\n      <td>Standard<\/td>\n      <td>hoch<\/td>\n      <td>gut<\/td>\n      <td>2<\/td>\n    <\/tr>\n    <tr>\n      <td>Anbieter C<\/td>\n      <td>Standard<\/td>\n      <td>gut<\/td>\n      <td>befriedigend<\/td>\n      <td>3<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/10\/firewall-webserver-setup-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxisbeispiele: Von Test zur Produktivregel<\/h2>\n<p>Ich beginne jedes Regel-Set im <strong>Screen<\/strong> oder in einer zweiten SSH-Session. So kann ich mich bei Fehlbedienung noch retten. Erst wenn ein Test-Host sauber l\u00e4uft, \u00fcbernehme ich Regeln in Produktion. R\u00fcckweg-Regeln und ein Rollback-Plan geben mir zus\u00e4tzlich Sicherheit. Am Ende dokumentiere ich \u00c4nderungen knapp im Change-Log.<\/p>\n<p>F\u00fcr Webserver nutze ich wiederkehrende Bausteine: SSH erlauben, HTTP\/S freigeben, interne Ports lokal binden, Logging an, ICMP begrenzen, \u00fcberfl\u00fcssige Protokolle blocken. Danach k\u00fcmmere ich mich um IPv6-Spiegelregeln, damit keine L\u00fccke bleibt. Docker-Ketten pr\u00fcfe ich immer separat, weil sie eigene Pfade setzen. Abschlie\u00dfend validiere ich Zugriffe \u00fcber externe Checks und Monitoring. So bleibt die Oberfl\u00e4che sauber und nachvollziehbar [1][2].<\/p>\n\n<h2>Zusammenfassung f\u00fcr Admins<\/h2>\n<p>Mit klaren <strong>Regeln<\/strong> und wenigen Befehlen sichere ich Webserver verl\u00e4sslich ab. Default-Deny eingehend, SSH zuerst, HTTP\/S freigeben \u2013 das bildet die stabile Basis. Datenbankports nur lokal oder per Whitelist, Logging aktiv, IPv6 beachten, Docker-Ketten pr\u00fcfen. Persistente Speicherung und regelm\u00e4\u00dfige Tests verhindern b\u00f6se \u00dcberraschungen. Diese Routine h\u00e4lt Dienste erreichbar und reduziert Risiken sp\u00fcrbar.<\/p>\n<p>Ob ich UFW nutze oder direkt iptables: Entscheidend ist eine klare, sparsame Policy. Ich dokumentiere kurz, verifiziere regelm\u00e4\u00dfig und halte Ausnahmen klein. Outbound-Restriktion stoppt unn\u00f6tige Verbindungen und begrenzt Schaden bei Kompromittierung. Mit ge\u00fcbtem Blick auf Logs erkenne ich Anomalien schneller und reagiere passend. So bleibt der Webserver belastbar und die Angriffsfl\u00e4che klein.<\/p>","protected":false},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u0430\u044f \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u0440\u0430\u0432\u0438\u043b \u0431\u0440\u0430\u043d\u0434\u043c\u0430\u0443\u044d\u0440\u0430 \u0434\u043b\u044f \u0432\u0435\u0431-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 - \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u043f\u0440\u0438\u043c\u0435\u0440\u044b iptables \u0438 UFW \u0434\u043b\u044f \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438.<\/p>","protected":false},"author":1,"featured_media":14018,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-14025","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1813","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"firewall iptables","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"14018","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/14025","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/comments?post=14025"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/14025\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media\/14018"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media?parent=14025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/categories?post=14025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/tags?post=14025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}