Eigene Server-Adressen in den Firewall-Regeln aufführen?

    In einem anderen Thema zur Konfiguration der Firewall wurde vorgeschlagen, die eigenen IP-Adressen (IPv4/IPv6) des Servers in den Regeln bei den Destination(s) bzw. Source(s) (IPs / Netzwerke) einzutragen.

    Ist das nicht überflüssig? Schließlich gilt die Firewall ja explizit für ein bestimmtes Interface bei dem MAC-Adresse und IP-Adressen feststehen. Mal abgesehen von speziellen Konfigurationen, bei denen mehrere IPv4 bzw. IPv6-Adressen auf dem selben Interface liegen (gibt es das bei netcup überhaupt?) scheint mir das im Allgemeinen überspezifiziert zu sein.

    Streng genommen steht die MAC-Adresse fest, für welche IP-Adressen Pakete eintreffen, ist innerhalb des gleichen Subnetzs ein völlig anderes Thema. Ich empfehle an dieser Stelle u.a. diesen Lesestoff: https://en.wikipedia.org/wiki/Host_model

    Wenn Du mehrere IPv4/IPv6 Adressen hast und/oder z.B. das Cloud vLAN verwendest (oder ein VPN), kann es schon Sinn machen, das explizit anzugeben, um bestimmten Angriffsszenarien vorzubeugen. Wobei ich persönlich das dann eher in einer Firewall in meinem Gastsystem (z.B. iptables/nftables bei Linux) so streng konfigurieren würde. Ich sehe die vorgelagerte Firewall von netcup da eher nur als grobe Vorfilterung, damit man es im SCP nicht unnötig kompliziert macht. Aber das muss jeder für sich entscheiden.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 (23. Dezember 2025 um 11:37)

    Danke, sehr interessant!

    Bei VPN sieht die netcup-Firewall ja nur den (meistens UDP)-Traffic mit den Adressen der VPN-Endpunkte, nicht aber den Traffic innerhalb des Tunnels. Was könnte man also bzgl. VPN noch sinnvoll filtern?

    P.S.: Den ersten Satz deiner Antwort könntest Du noch etwas „aufräumen“.

    Zitat von Zierleiste

    P.S.: Den ersten Satz deiner Antwort könntest Du noch etwas „aufräumen“.

    Ich meinte, dass ein Nachbar im gleichen Netzwerk (= anderer vServer Kunde) Deinem vServer beliebige Pakete schicken kann. Solange die MAC-Adresse stimmt, könnten so auch Pakete z.B. für private Adressbereiche bei Dir landen und je nach Konfiguration in Deinem System quasi ungeprüft akzeptiert werden. Dadurch wäre es möglich, dass jemand auf interne Dienste zugreift, die z.B. eigentlich nur über ein VPN erreichbar sein sollten. Dienste explizit auf einer bestimmten Schnittstelle lauschen zu lassen, reicht bei einer Standardkonfiguration oftmals nicht aus.

    (Ob das von irgendeinem System bei netcup herausgefiltert oder erkannt wird, weiß ich nicht. Könnte natürlich sein, glaube ich aber eher nicht.)

    Deshalb schadet es meiner Meinung nach nicht, wenn man die eigene(n) IP-Adresse(n) bei einer Firewall explizit angibt. Da das im SCP aber schnell mühsam werden kann, würde ich das innerhalb des vServers umsetzen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von KB19

    Wenn Du mehrere IPv4/IPv6 Adressen hast und/oder z.B. das Cloud vLAN verwendest (oder ein VPN), kann es schon Sinn machen, das explizit anzugeben

    Nur zur Info die Firewall im SCP greift beim VLAN nicht. Wollte ich nur mal erwähnen.

    Zitat von https://helpcenter.netcup.com/de/wiki/server/firewall

    Werden VLANS von der Firewall unterstützt?
    Da es sich um einen internen und keinen externen Traffic handelt, kann die Firewall nicht für vLANs konfiguriert werden. Verwende hierfür eine Lösung auf Betriebssystemebene.

    KB19 Da hast Du mir ja schönen "Lesestoff" gegeben! ;)

    Gegen das IP-Spoofing sollte es eigentlich schon im Hypervisor entsprechende Maßnahmen geben, siehe beispielsweise:

    https://debiandev.de/aktuelles/prox…indern-qemu-kvm und

    https://pve.proxmox.com/pve-docs/chapter-pve-firewall.html#pve_firewall_ipfilter_section

    Wobei offen ist, ob ein Rootserver bei netcup wirklich auf KVM / QEMU basiert und die o.g. Einstellungen aus dem SCP korrekt angewendet werden.

    Wie sich das bei einem vServer verhält, wäre dann eine weitere Frage. Vielleicht könnten die Moderatoren dazu ein Feedback geben.

    Unabhängig davon sollte man sich als Betreiber eines Servers natürlich nicht (nur) auf externe Sicherheitsmaßnahmen verlassen, sondern auch eigene Sicherheitsmaßnahmen treffen. IP-Spoofing ist darüber hinaus nicht das einzige Thema, das relevant ist.

    Ich konnte keine offizielle Doku dazu finden, lediglich die Info, dass KVM für Rootserver benutzt wird. QEMU vermute ich, da das Paket qemu-guest-agent installiert wird bzw. im SCP auch ein Hinweis darauf erscheint, wenn der Server nicht läuft. Wenn Du einen Link hast, wo netcup das offiziell dokumentiert hat, dann würde ich mich über das Teilen freuen.

    Zitat von philw95

    Nur zur Info die Firewall im SCP greift beim VLAN nicht.

    Eh nicht, aber bei Paketen auf der öffentlichen Schnittstelle, die z.B. eine RFC1918 Adresse als Destination haben.

    Zitat von Zierleiste

    […] IP-Spoofing […]

    Die eigene Source-Adresse muss der Absender nicht unbedingt fälschen, das kann ruhig eine öffentliche IPv4-Adresse sein, die ihm regulär zugewiesen ist. Unerwünschte Pakete mit RFC1918-Adressen als Destination trudeln hier auf der öffentlichen Schnittstelle jedenfalls massenhaft ein...

    Bei den Antwortpaketen würde ich mich dann auch nicht darauf verlassen, womit die wirklich rausgehen. Besonders wenn ein NAT im Spiel ist. (Docker & Co. lassen grüßen.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    daq4th Dass KVM eingesetzt wird, steht ja auf der netcup-Webseite deutlich dabei: https://www.netcup.com/de/server/root-server, mir ging es da mehr um das Detail "QEMU".

    Zitat von KB19

    Unerwünschte Pakete mit RFC1918-Adressen

    Entsprechende Firewall-Regeln evaluiere ich gerade auf unserer Testumgebung und werde sie dann sukzessive auf unsere netcup-Server ausrollen.

    Nachtrag: Interessanter Artikel zum Thema "Martians Among Us: Observing Private or Reserved IPs on the Public Internet": https://arxiv.org/html/2501.16805v1