Ubuntu Server Firewall mit Iptables
Guten Morgen Forum,
Möchte gerne einen kleinen Server laufen lassen. Auf dem Server passiert nicht viel. Das einzige was ich sag mal größeres was drauf läuft ist ein VPN Exitpoint.
Habe mir jetzt eine Firewall mit IPtables erstellt. Wäre es möglich das da jemand ansehen kann und mir ggf. Änderungen oder Tipps geben kann.
Die Firewall sollten natürlich sicher sein und die Reihenfolge sollte auch stimmen.
Server: Ubuntu Server LTS 16.04.3
Natürlich wird auch ein SSH-Key erstellt, SSH-Port geändert usw. aber, mir geht es um die Iptables das die Stimmen.
Vieleb dank.
Gruß
GoogleBot
Möchte gerne einen kleinen Server laufen lassen. Auf dem Server passiert nicht viel. Das einzige was ich sag mal größeres was drauf läuft ist ein VPN Exitpoint.
Habe mir jetzt eine Firewall mit IPtables erstellt. Wäre es möglich das da jemand ansehen kann und mir ggf. Änderungen oder Tipps geben kann.
Die Firewall sollten natürlich sicher sein und die Reihenfolge sollte auch stimmen.
Server: Ubuntu Server LTS 16.04.3
Natürlich wird auch ein SSH-Key erstellt, SSH-Port geändert usw. aber, mir geht es um die Iptables das die Stimmen.
#!/bin/bash
IPTABLES="/sbin/iptables"
# Defaults for rate limiting
#------------------------------------------------------------------------------
RLIMIT="-m limit --limit 1/s --limit-burst 30"
# Default policies.
#------------------------------------------------------------------------------
# Drop everything by default.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
# Set the nat/mangle/raw tables' chains to ACCEPT
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P INPUT ACCEPT
$IPTABLES -t mangle -P FORWARD ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT
$IPTABLES -t mangle -P POSTROUTING ACCEPT
# Cleanup.
#------------------------------------------------------------------------------
# Delete all
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
# Delete all
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -X
# Zero all packets and counters.
$IPTABLES -Z
$IPTABLES -t nat -Z
$IPTABLES -t mangle -Z
# Custom user-defined chains.
#------------------------------------------------------------------------------
# Only allows RELATED ICMP types
$IPTABLES -N RELATED_ICMP
$IPTABLES -A RELATED_ICMP -p icmp --icmp-type destination-unreachable -j ACCEPT
$IPTABLES -A RELATED_ICMP -p icmp --icmp-type time-exceeded -j ACCEPT
$IPTABLES -A RELATED_ICMP -p icmp --icmp-type parameter-problem -j ACCEPT
$IPTABLES -A RELATED_ICMP -j DROP
# Make It Even Harder To Multi-PING
$IPTABLES -A INPUT -p icmp -m limit --limit 1/s --limit-burst 2 -j ACCEPT
$IPTABLES -A OUTPUT -p icmp -j ACCEPT
# Only allow the minimally required/recommended parts of ICMP. Block the rest.
#------------------------------------------------------------------------------
# Allow all ESTABLISHED ICMP traffic.
$IPTABLES -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT $RLIMIT
$IPTABLES -A OUTPUT -p icmp -m state --state ESTABLISHED -j ACCEPT $RLIMIT
# Allow some parts of the RELATED ICMP traffic, block the rest.
$IPTABLES -A INPUT -p icmp -m state --state RELATED -j RELATED_ICMP $RLIMIT
$IPTABLES -A OUTPUT -p icmp -m state --state RELATED -j RELATED_ICMP $RLIMIT
# Allow incoming ICMP echo requests (ping), but only rate-limited.
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT $RLIMIT
# Allow outgoing ICMP echo requests (ping), but only rate-limited.
$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT $RLIMIT
# Drop any other ICMP traffic.
$IPTABLES -A INPUT -p icmp -j DROP
$IPTABLES -A OUTPUT -p icmp -j DROP
$IPTABLES -A FORWARD -p icmp -j DROP
# Selectively allow certain special types of traffic.
#------------------------------------------------------------------------------
# Allow loopback interface to do anything.
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
# Allow incoming connections related to existing allowed connections.
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow outgoing connections EXCEPT invalid
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Miscellaneous.
#------------------------------------------------------------------------------
# Explicitly drop invalid incoming traffic
$IPTABLES -A INPUT -m state --state INVALID -j DROP
# Drop invalid outgoing traffic, too.
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP
# If we would use NAT, INVALID packets would pass - BLOCK them anyways
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
# Selectively allow certain outbound connections, block the rest.
#------------------------------------------------------------------------------
# Erlaube ausgehende DNS Anfragen. Few things will work without this.
$IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
# Erlaube ausgehende OpenVPN Anfragen.
$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
# Erlaube ausgehende SMTP Anfragen.
$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
# Erlaube ausgehende "submission" (RFC 2476) Anfragen.
$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 587 -j ACCEPT
# Erlaube ausgehende SSH Anfragen.
$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 666 -j ACCEPT
# Erlaube ausgehende FTP Anfragen.
$IPTABLES -A OUTPUT -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -p tcp -m tcp --dport 20 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
# Routuing
#------------------------------------------------------------------------------
# OpenVPN
$IPTABLES -A FORWARD -m physdev --physdev-in eth0 --physdev-out tun0 -j ACCEPT
$IPTABLES -A FORWARD -m physdev --physdev-in tun0 --physdev-out eth0 -p tcp --dport 443 -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to 111.222.333.444
$IPTABLES -I FORWARD -s 10.8.0.0/24 -j ACCEPT
$IPTABLES -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# Selectively allow certain inbound connections, block the rest.
#------------------------------------------------------------------------------
# Erlaube eingehende OpenVPN Anfragen.
$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
# Erlaube eingehende SSH Anfragen.
$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 666 -j ACCEPT
# Explicitly log and reject everything else.
#------------------------------------------------------------------------------
# Use REJECT instead of REJECTLOG if you don't need/want logging.
$IPTABLES -A INPUT -j REJECT
$IPTABLES -A OUTPUT -j REJECT
$IPTABLES -A FORWARD -j REJECT
# Exit gracefully.
#------------------------------------------------------------------------------
exit 0
Vieleb dank.
Gruß
GoogleBot
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 349580
Url: https://administrator.de/contentid/349580
Ausgedruckt am: 25.11.2024 um 05:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
sieht eigentlich recht sauber aus, allerdings würde ich dir empfehlen sowas lieber in ferm zu verwalten. Es macht vieles einfacher und stellt sicher, dass die Regeln so aussehen, wie sie aussehen sollen.
Was bei dir zum beispiel ein Problem ist:
1. Führst du das Script 2 mal aus, gibt es mehr regeln als nötig und vermutlich einige doppelt.
2. Failed ein Befehl in dem Script bekommst du es nicht/nur bedingt mit. (abhilfe schafft hier "set -e" wenn es schnell gehen muss oder ein sauberes error handling)
Stellt sich nur noch die Frage, warum externes SMTP erlaubt ist? Besteht da eine echte notwendigkeit? Systemmails solltest du über Submission woanders los werden und und sonst kein Port 25 brauchen.
Zuletzt noch den SSH port. Der sollte aus diversen Gründen NICHT geändert werden. Wenn du ihn schließen willst, um neverige ssh attacken los zu werden, empfehle ich blocklist in einem ipset. Das schmeißt das in der Regel schonmal weg. Ansonsten ist portknocking das mittel der Wahl.
Einige Gründe warum das ändern des SSH ports eher suboptimal ist: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-por ...
Alles in allem aber ein solides Setup.
Gruß
Chris
PS: Ansonsten solltest du auch mal Shellcheck drüber laufen lassen. Das wird dir ein paar typische Fehler in schellscripten anzeigen, die ich auch in deinem Fall sehe ;) (Auch wenn sie nicht zwangsläufig die Nutzbarkeit beeinflussen)
sieht eigentlich recht sauber aus, allerdings würde ich dir empfehlen sowas lieber in ferm zu verwalten. Es macht vieles einfacher und stellt sicher, dass die Regeln so aussehen, wie sie aussehen sollen.
Was bei dir zum beispiel ein Problem ist:
1. Führst du das Script 2 mal aus, gibt es mehr regeln als nötig und vermutlich einige doppelt.
2. Failed ein Befehl in dem Script bekommst du es nicht/nur bedingt mit. (abhilfe schafft hier "set -e" wenn es schnell gehen muss oder ein sauberes error handling)
Stellt sich nur noch die Frage, warum externes SMTP erlaubt ist? Besteht da eine echte notwendigkeit? Systemmails solltest du über Submission woanders los werden und und sonst kein Port 25 brauchen.
Zuletzt noch den SSH port. Der sollte aus diversen Gründen NICHT geändert werden. Wenn du ihn schließen willst, um neverige ssh attacken los zu werden, empfehle ich blocklist in einem ipset. Das schmeißt das in der Regel schonmal weg. Ansonsten ist portknocking das mittel der Wahl.
Einige Gründe warum das ändern des SSH ports eher suboptimal ist: https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-por ...
Alles in allem aber ein solides Setup.
Gruß
Chris
PS: Ansonsten solltest du auch mal Shellcheck drüber laufen lassen. Das wird dir ein paar typische Fehler in schellscripten anzeigen, die ich auch in deinem Fall sehe ;) (Auch wenn sie nicht zwangsläufig die Nutzbarkeit beeinflussen)
Irgendwie der selbe Schmuh wie hier
Iptables Firewall
Anderer Nick, selber User, der Code lässt eigentlich keine Zweifel ...?!
Iptables Firewall
Anderer Nick, selber User, der Code lässt eigentlich keine Zweifel ...?!
Moin,
Letztlich musst du entscheiden, was für dich das machbarste ist. Scripte pflegen oder 3 Zeilen config.
Nein :D Wie gesagt, finde ich es viel zu umständlich es in dieser Art zu konfigurieren. Ferm, oder mit Ansible, puppet, o.Ä. gemangedes UFW oder firewallctl, sind wesentlich effektiver und weniger fehleranfällig.
Wenn du Beispiele für Fermconfigs suchst, empfehle ich https://debops.org/ die sehr professionelle ferm regeln in ihre playbooks packen, die man gewiss auch adaptieren kann, wenn man nicht alles selbst schreiben will.
Gruß
Chris
Zitat von @GoogleBot:
- Ja, an ferm habe ich auch schon gedacht. Muss mich damit mal auseinander setzen.
- Ein Kollege meint warum ich es nicht die UFW von Ubuntu benutze.
Leider bin ich nicht so ein freund von ihr. Klar, es basiert auch auf Iptables nur einfacher zu Verwalten.
Oder was meinst du?
Ferm ist vom Handling her anders als ufw. Ich bin selbst auch kein großer Fan von ufw aber es funktioniert. Wenn du allerdings deine Firewall regeln managen willst, würde ich ferm vorziehen, einfach weil es nach unix manier einfach nur das anpassen von ein paar files ist und man damit über ein ferm.d/ Verzeichnis sehr schön generische Firewall regeln für alle Applicationen die man so hat, hinbekommt und managen kann.- Ja, an ferm habe ich auch schon gedacht. Muss mich damit mal auseinander setzen.
- Ein Kollege meint warum ich es nicht die UFW von Ubuntu benutze.
Leider bin ich nicht so ein freund von ihr. Klar, es basiert auch auf Iptables nur einfacher zu Verwalten.
Oder was meinst du?
Letztlich musst du entscheiden, was für dich das machbarste ist. Scripte pflegen oder 3 Zeilen config.
- Zu SSH habe ich auch an Fail2ban gedacht aber, bin auch für neues Offen.
Das ist natürlich ohnehin ein muss. Ich würde kein SSH ohne Fail2ban oder SSHguard. Allerdings würde ich dennoch Fail2Ban vorziehen.- Dann würdest du das Script vorerst so benutzen wollen?
Nein :D Wie gesagt, finde ich es viel zu umständlich es in dieser Art zu konfigurieren. Ferm, oder mit Ansible, puppet, o.Ä. gemangedes UFW oder firewallctl, sind wesentlich effektiver und weniger fehleranfällig.
Wenn du Beispiele für Fermconfigs suchst, empfehle ich https://debops.org/ die sehr professionelle ferm regeln in ihre playbooks packen, die man gewiss auch adaptieren kann, wenn man nicht alles selbst schreiben will.
Gruß
Chris