![\"MySQL](\"https:\/\/www.cisilino.com\/wp-content\/uploads\/2026\/10\/mysql-5-7-docker-nftables-absichern.webp\")
<\/figure>\nEine so alte Version direkt auf dem Host zu installieren, bringt mehrere Probleme. Die offiziellen Repositories aktueller Distributionen bieten sie nicht mehr an. Pakete von Drittanbietern k\u00f6nnen mit dem Rest des Systems in Konflikt geraten, und ein OS-Update k\u00f6nnte sie zerst\u00f6ren.<\/p>\n
Wir haben uns deshalb entschieden, sie in einem Docker-Container zu isolieren<\/strong>. Der Host bleibt sauber und aktuell, die Datenbankversion ist festgelegt und reproduzierbar. Daten und Konfiguration liegen in einem Ordner, der sich leicht sichern und verschieben l\u00e4sst.<\/p>\n Dieser Artikel erz\u00e4hlt, wie wir sie eingerichtet haben und vor allem, auf welche Hindernisse wir unterwegs gesto\u00dfen sind. Es sind die unbeabsichtigte Freigabe des Ports 3306 und ein iptables-Fehler beim Neustart. Dazu kam das Schreiben einer Firewall mit nftables<\/strong>, die nur autorisierte IPs durchl\u00e4sst.<\/p>\n Hinweis:<\/strong> MySQL 5.7 hat im Oktober 2023 das Ende des Supports (EOL) erreicht und erh\u00e4lt keine Sicherheitspatches mehr. Es ist eine \u00dcbergangsl\u00f6sung: Das Ziel bleibt die Migration auf MySQL 8.x oder MariaDB. Gerade deshalb ist es umso wichtiger, es nicht offen zu lassen.<\/p>\n<\/blockquote>\n Die Datei Sch\u00fctzen Sie sie mit Einige Entscheidungen, die man beachten sollte.<\/p>\n Die Zeile Das Heimt\u00fcckischste ist, dass Docker seine eigenen Regeln direkt in die Firewall des Kernels schreibt und diese vor denen von UFW oder firewalld ausgewertet werden. Eine aktive Firewall gen\u00fcgt nicht<\/strong>: Der Port bleibt erreichbar. Die Docker-Dokumentation beschreibt dieses Verhalten unter Packet filtering and firewalls<\/a>.<\/p>\n Die m\u00f6glichen Wege sind.<\/p>\n F\u00fcr Fall 4 braucht man eine Firewall, die den Verkehr der von Docker ver\u00f6ffentlichten Ports korrekt filtert.<\/p>\n Nachdem wir die Firewall angefasst hatten, lieferte Der Fehler h\u00e4ngt nicht vom Compose ab: Die Kette Unsere Dieser Befehl l\u00f6scht alle<\/strong> nftables-Tabellen, auch die von Docker angelegten. Au\u00dferdem enthielt die Datei eine statische Kopie der Docker-Regeln, mit von Hand eingetragenem Bridge-Namen ( Goldene Regel:<\/strong> Mit Docker verwendet man in der nftables-Datei kein Das Prinzip: Die von Docker ver\u00f6ffentlichten Ports werden mit DNAT umgeschrieben und dann vom Host an den Container weitergeleitet, durchlaufen also die Kette Um fremde Tabellen nicht anzufassen, verwenden wir das Muster Wie die Schutzregel funktioniert.<\/p>\n Kompatibilit\u00e4t:<\/strong> In einer ersten Version verwendeten wir Halten Sie eine zweite SSH-Sitzung als Reserve offen, dann.<\/p>\n Damit es beim Booten geladen wird, stellen Sie sicher, dass der Dienst aktiv ist ( Um es dauerhaft zu machen, aktualisieren Sie auch das Set in der Datei.<\/p>\n Vom autorisierten Server.<\/p>\n Von jeder anderen IP.<\/p>\n Auf dem Server muss der Z\u00e4hler der Drop-Regel bei jedem nicht autorisierten Versuch wachsen.<\/p>\n Die Firewall ersetzt nicht die Berechtigungen der Datenbank. Legen Sie den Benutzer mit auf die IP des Clients beschr\u00e4nktem Host an.<\/p>\n Gelingt die TCP-Verbindung, MySQL antwortet aber Haben Sie Fragen oder eine andere L\u00f6sung f\u00fcr dasselbe Problem? Schreiben Sie es in die Kommentare. Zum Thema MySQL und Debian lesen Sie auch: MySQL startet nach dem Debian-12-Upgrade nicht mehr<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" So betreiben Sie MySQL 5.7 in Docker auf einem modernen Server, ohne es dem Internet auszusetzen: docker-compose, geschlossener Port und nftables-Firewall.<\/p>\n","protected":false},"author":1,"featured_media":759,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[363],"tags":[310,330,294,314],"class_list":["post-275","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-datenbanken","tag-docker-de","tag-firewall-de","tag-mysql-de","tag-nftables-de"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
\n1. Ordnerstruktur<\/h2>\n
\/opt\/mysql57\/\n\u251c\u2500\u2500 docker-compose.yml\n\u251c\u2500\u2500 .env\n\u251c\u2500\u2500 conf.d\/ # configurazioni personalizzate (my.cnf aggiuntivi)\n\u251c\u2500\u2500 data\/ # dati del database (volume persistente)\n\u2514\u2500\u2500 logs\/\n<\/code><\/pre>\n.env<\/code> enth\u00e4lt die Zugangsdaten, damit sie nicht im Compose landen.<\/p>\nTZ=Europe\/Rome\nMYSQL_ROOT_PASSWORD=una_password_molto_lunga_e_casuale\nMYSQL_DATABASE=nome_db\nMYSQL_USER=nome_utente\nMYSQL_PASSWORD=altra_password_robusta\n<\/code><\/pre>\nchmod 600 .env<\/code>.<\/p>\n2. Die docker-compose.yml<\/h2>\n
services:\n mysql57:\n image: mysql:5.7\n container_name: mysql57\n restart: unless-stopped\n env_file:\n - .env\n ports:\n - \"3306:3306\"\n environment:\n TZ: \"${TZ:-Europe\/Rome}\"\n MYSQL_ROOT_PASSWORD: \"${MYSQL_ROOT_PASSWORD}\"\n MYSQL_DATABASE: \"${MYSQL_DATABASE}\"\n MYSQL_USER: \"${MYSQL_USER}\"\n MYSQL_PASSWORD: \"${MYSQL_PASSWORD}\"\n command:\n - --default-authentication-plugin=mysql_native_password\n volumes:\n - .\/data:\/var\/lib\/mysql\n - .\/conf.d:\/etc\/mysql\/conf.d:ro\n - .\/logs:\/var\/log\/mysql\n healthcheck:\n test: [\"CMD-SHELL\", \"mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD --silent\"]\n interval: 20s\n timeout: 5s\n retries: 10\n start_period: 45s\n ulimits:\n nofile:\n soft: 65535\n hard: 65535\n<\/code><\/pre>\n\n
restart: unless-stopped<\/code><\/strong>: Die Datenbank startet nach einem Neustart des Servers von selbst wieder.<\/li>\n$$<\/code> sorgt daf\u00fcr, dass die Variable im Container und nicht von Compose aufgel\u00f6st wird).<\/li>\nulimits nofile<\/code><\/strong>: vermeidet den Fehler \u201etoo many open files\u201c unter Last.<\/li>\n<\/ul>\n3. Erstes Problem: Der Port von MySQL 5.7 in Docker ist f\u00fcr die ganze Welt offen<\/h2>\n
- \"3306:3306\"<\/code> entspricht 0.0.0.0:3306:3306<\/code>: Docker ver\u00f6ffentlicht den Port auf allen Schnittstellen<\/strong> des Hosts, auch der \u00f6ffentlichen.<\/p>\n\n
\"127.0.0.1:3306:3306\"<\/code>, wenn die Datenbank nur vom Host oder \u00fcber einen SSH-Tunnel genutzt wird.<\/li>\n4. Zweites Problem: iptables-Fehler beim Start<\/h2>\n
docker compose up<\/code>.<\/p>\nfailed to create network mysql57_default: Error response from daemon:\nFailed to Setup IP tables: Unable to enable ACCEPT OUTGOING rule:\n(iptables failed: iptables --wait -t filter -A DOCKER-FORWARD -i br-... -j ACCEPT:\niptables: No chain\/target\/match by that name.\n<\/code><\/pre>\nDOCKER-FORWARD<\/code> (in neueren Docker-Versionen eingef\u00fchrt) existierte nicht mehr. Sie war von etwas gel\u00f6scht worden, das die Regeln nach<\/strong> dem Start des Daemons bereinigt hatte. Ein Neustart von Docker (systemctl restart docker<\/code>) legt sie neu an, doch das Problem kehrt zur\u00fcck, bis der wahre Schuldige beseitigt ist.<\/p>\nDer Schuldige:
flush ruleset<\/code><\/h3>\n\/etc\/nftables.conf<\/code> begann mit.<\/p>\nflush ruleset\n<\/code><\/pre>\nbr-278550235c3f<\/code>) und Container-IP (172.18.0.2<\/code>). Der Bridge-Name \u00e4ndert sich jedoch jedes Mal, wenn das Compose-Netzwerk neu erstellt wird. Die Kopie war also sofort veraltet, und die Tabelle ip nat<\/code> geriet in Konflikt mit der von Docker verwalteten.<\/p>\nflush ruleset<\/code> und kopiert keine seiner Regeln. Man verwaltet nur seine eigene Firewall, in eigenen Tabellen.<\/p>\n5. Die Firewall mit nftables f\u00fcr MySQL 5.7 in Docker<\/h2>\n
forward<\/code><\/strong>, nicht input<\/code>. Eine Regel drop<\/code> in einer eigenen Kette forward<\/code> mit etwas niedrigerer Priorit\u00e4t (also zuerst ausgewertet) verwirft das Paket unabh\u00e4ngig von den accept<\/code>-Regeln von Docker.<\/p>\ntable ...<\/code> + delete table ...<\/code>: Es macht die Datei ohne Fehler und ohne flush<\/code> wiederholt ausf\u00fchrbar.<\/p>\n\/etc\/nftables.conf<\/code>.<\/p>\n#!\/usr\/sbin\/nft -f\n\n# NIENTE \"flush ruleset\": cancellerebbe anche le tabelle di Docker\n\n# ---------------- firewall host ----------------\ntable inet filter\ndelete table inet filter\n\ntable inet filter {\n\n chain input {\n type filter hook input priority filter; policy drop;\n ct state established,related accept\n iifname \"lo\" accept\n ip6 nexthdr icmpv6 accept\n iifname \"enp7s0\" accept # rete privata\n ip saddr 203.0.113.20 tcp dport 22 accept # SSH da host fidato\n ip saddr 203.0.113.30 tcp dport 22 accept # SSH da VPN\n ip saddr 203.0.113.20 icmp type echo-request accept\n tcp dport { 80, 443 } accept\n }\n\n chain output {\n type filter hook output priority filter; policy accept;\n }\n}\n\n# ---------------- guardia MySQL (porta pubblicata da Docker) ----------------\ntable ip mysql_guard\ndelete table ip mysql_guard\n\ntable ip mysql_guard {\n set allowed {\n type ipv4_addr\n flags interval\n elements = {\n 203.0.113.10 # phpMyAdmin\n }\n }\n\n chain forward {\n type filter hook forward priority filter - 5; policy accept;\n iifname \"enp7s0\" accept\n ct status dnat tcp dport 3306 ip saddr @allowed accept\n ct status dnat tcp dport 3306 counter drop\n }\n}\n<\/code><\/pre>\n\n
ct status dnat<\/code> w\u00e4hlt nur Pakete aus, die durch DNAT gelaufen sind, also die f\u00fcr die von Docker ver\u00f6ffentlichten Ports bestimmten.<\/li>\nallowed<\/code> ist; die zweite verwirft alle anderen und z\u00e4hlt sie (counter<\/code>).<\/li>\n127.0.0.1<\/code>) und Verkehr zwischen Containern im selben Netzwerk l\u00e4uft nicht \u00fcber das Forward des Routers und wird daher nicht ber\u00fchrt.<\/li>\n<\/ul>\n\n
ct original proto-dst 3306<\/code>, aber einige Versionen von nft<\/code> antworten mit \u201eCan’t parse symbolic invalid expressions\u201c<\/em>. Im Hook forward<\/code> ist das DNAT bereits erfolgt und der Container-Port entspricht dem ver\u00f6ffentlichten (3306:3306<\/code>). Daher ist tcp dport 3306<\/code> zusammen mit ct status dnat<\/code> gleichwertig und funktioniert \u00fcberall. \u00c4ndern Sie das Mapping (z. B. 3307:3306<\/code>), muss die Regel an den internen Port angepasst werden.<\/p>\n<\/blockquote>\n\u00c4nderungen anwenden, ohne sich auszusperren<\/h3>\n
nft -c -f \/etc\/nftables.conf # solo verifica della sintassi\nnft delete table ip nat # una tantum: elimina la vecchia copia statica\nnft -f \/etc\/nftables.conf\nsystemctl restart docker # Docker ricrea le sue tabelle pulite\ncd \/opt\/mysql57 && docker compose up -d\n<\/code><\/pre>\nsystemctl enable --now nftables<\/code>) und dass \/etc\/nftables.conf<\/code> kein flush ruleset<\/code> enth\u00e4lt.<\/p>\nIPs zur Laufzeit verwalten<\/h3>\n
nft add element ip mysql_guard allowed { 203.0.113.50 }\nnft delete element ip mysql_guard allowed { 203.0.113.50 }\n<\/code><\/pre>\n6. \u00dcberpr\u00fcfung<\/h2>\n
nc -zv IP_PUBBLICO_DB 3306 # deve rispondere \"succeeded\"\n<\/code><\/pre>\nnmap -Pn -p 3306 IP_PUBBLICO_DB # deve risultare \"filtered\" \/ timeout\n<\/code><\/pre>\nnft list chain ip mysql_guard forward\nss -tlnp | grep 3306\n<\/code><\/pre>\n7. Zweite Barriere: die MySQL-Benutzer<\/h2>\n
CREATE USER 'pma_user'@'203.0.113.10' IDENTIFIED BY 'password_robusta';\nGRANT ALL ON nome_db.* TO 'pma_user'@'203.0.113.10';\nFLUSH PRIVILEGES;\n<\/code><\/pre>\nAccess denied<\/code>, liegt das Problem hier und nicht in der Firewall.<\/p>\n8. Was man sich zu MySQL 5.7 in Docker merken sollte<\/h2>\n
\n
input<\/code> oder forward<\/code>), ist der Schl\u00fcssel zu allem.<\/li>\nflush ruleset<\/code><\/strong> auf einem Host mit Docker; verwenden Sie eigene Tabellen.<\/li>\n.\/logs<\/code> und erw\u00e4gen Sie, die Passw\u00f6rter zu \u00e4ndern<\/strong>, vor allem das von root.<\/li>\n