Tipps & Tricks: Linux absichern mit den iptables
- Thread starter JackCarver
- Start date
Moin,
in shorewall sind das ein paar Ein-Dreizeiler:
zones (drei Zonen: der Rechner selbst ist fw, das Netz des Providers ist net und vpn ist alles hinter dem vpn-Tunnel):
interfaces (über welche interfaces sind die Zonen angebunden):
Policy (wie wird zwischen den Zonen geblockt; hier: freier Zugang vom Rechner ins vpn, alles andere geblockt):
und rules (hier stehen die Ausnahmen zur obigen Policy, also die vpn-ports werden ins Provider Netz durchgelassen):
shorewall start erzeugt und aktiviert dann ähnliche iptables rules, wie oben, allerdings ist die shorewall syntax viel verständlicher und auch leichter zu erweitern, wie man oben sieht. Den ganzen Wust mit related/established usw. regelt shorewall automagisch, es sei denn man will das auch noch selbst anders konfigurieren. Dann sollte man allerdings tiefe Netzwerkkenntnisse besitzen.
Erreichbarkeit von DNS usw. ist dann nur noch durch den VPN-Tunnel möglich, bricht der zusammen, dann geht erstmal gar nichts mehr, bis man shorewall stop eingibt.
Muß jeder selbst wissen, aber nachdem ich mich vor 10 Jahren mal kurz mit iptables 'rumgeschlagen habe, benutze ich seitdem shorewall.
in shorewall sind das ein paar Ein-Dreizeiler:
zones (drei Zonen: der Rechner selbst ist fw, das Netz des Providers ist net und vpn ist alles hinter dem vpn-Tunnel):
Code:
fw firewall
net ipv4
vpn ipv4
Code:
net eth0 detect dhcp,norfc1918,blacklist
vpn tun0 detect routeback
Code:
fw vpn ACCEPT
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT $LOG
Code:
ACCEPT fw net udp 149,150,151,1149,1150,1151shorewall start erzeugt und aktiviert dann ähnliche iptables rules, wie oben, allerdings ist die shorewall syntax viel verständlicher und auch leichter zu erweitern, wie man oben sieht. Den ganzen Wust mit related/established usw. regelt shorewall automagisch, es sei denn man will das auch noch selbst anders konfigurieren. Dann sollte man allerdings tiefe Netzwerkkenntnisse besitzen.
Erreichbarkeit von DNS usw. ist dann nur noch durch den VPN-Tunnel möglich, bricht der zusammen, dann geht erstmal gar nichts mehr, bis man shorewall stop eingibt.
Muß jeder selbst wissen, aber nachdem ich mich vor 10 Jahren mal kurz mit iptables 'rumgeschlagen habe, benutze ich seitdem shorewall.
Ja Frank, das mag sich in einfachen Fällen die Waage halten, aber wenn man mehrere Interfaces, vpns, wlans, snat + dnat usw. hat, möchte ich das nicht mit iptables machen müssen. Meine rules Datei hat über 200 Einträge bei nur 8 zonen... das wird dann sehr unübersichtich mit iptables. Ab drei Interfaces lohnt es sich auf jeden Fall.PP Frank said:Erstmal Danke für diese Anleitungen. Sehr schön. Das wird sicher vielen Nutzern helfen.
@theoth
Wenn man erstmal IPTables kann, sieht shorewall plözlich so kompliziert aus
JackCarver
Well-known Member
@theoth:
In der Regel haben User genau 2 wichtige Interfaces, die leaken können und das ist eth0 und wlan0. Es mag sicher welche geben, die 2 Netzwerkkarten oder mehrere WLAN Sticks installiert haben, aber das seh ich als die absolute Ausnahme.
Die SNATs, DNATs haben auf nem Einzelplatzrechner in der Regel auch nix zu suchen, das ist Sache für nen Linux Router, und die virtuellen Adapter für zb VPN, sprich tun0-n werden hier ebenfalls nicht geblockt bzw berücksichtigt, da man in den allermeisten Fällen ja nur die Leaks direkt übern Router verhindern möchte. Alles was zb übers tun Interface läuft, läuft über den VPN Server.
So das Tool ist nun um das Speichern der Regeln über den Systemstart hinaus erweitert, ich werde es in Kürze im ersten Posting verlinken mit Screenshots dazu und kurzer Erklärung.
Dann melde ich das hier an.
Edit:
Das Tool richtet sich in erster Linie an Leute, die eine simple Möglichkeit suchen über wenige Klicks ne FW Lösung angepasst an PP zu starten oder bei Bedarf zu beenden. Es soll kein Ersatz für Profis sein, die sich sowieso mit shorewall/iptables und Co auskennen, die wissen ja was sie tun.
Bei Bedarf kann ich das auch noch erweitern, dass zb der ssh Port frei bleibt, für ssh Verbindungen ohne VPN.
In der Regel haben User genau 2 wichtige Interfaces, die leaken können und das ist eth0 und wlan0. Es mag sicher welche geben, die 2 Netzwerkkarten oder mehrere WLAN Sticks installiert haben, aber das seh ich als die absolute Ausnahme.
Die SNATs, DNATs haben auf nem Einzelplatzrechner in der Regel auch nix zu suchen, das ist Sache für nen Linux Router, und die virtuellen Adapter für zb VPN, sprich tun0-n werden hier ebenfalls nicht geblockt bzw berücksichtigt, da man in den allermeisten Fällen ja nur die Leaks direkt übern Router verhindern möchte. Alles was zb übers tun Interface läuft, läuft über den VPN Server.
So das Tool ist nun um das Speichern der Regeln über den Systemstart hinaus erweitert, ich werde es in Kürze im ersten Posting verlinken mit Screenshots dazu und kurzer Erklärung.
Dann melde ich das hier an.
Edit:
Das Tool richtet sich in erster Linie an Leute, die eine simple Möglichkeit suchen über wenige Klicks ne FW Lösung angepasst an PP zu starten oder bei Bedarf zu beenden. Es soll kein Ersatz für Profis sein, die sich sowieso mit shorewall/iptables und Co auskennen, die wissen ja was sie tun.
Bei Bedarf kann ich das auch noch erweitern, dass zb der ssh Port frei bleibt, für ssh Verbindungen ohne VPN.
JackCarver
Well-known Member
Das aktualisierte Prog ist nun verlinkt. Dazu bitte nochmal den Quote Kasten lesen
JackCarver
Well-known Member
Noch was in eigener Sache:
Ich konnte das Programm unter Debian Wheezy und Min 16 testen, Ubuntu werd ich demnächst zum Testen installieren, hab es aber zur Zeit nicht am Laufen.
Evtl gibt es ja jemand mit Ubuntu, der das mal testen will. Würde mich über Feedback freuen.
Ich konnte das Programm unter Debian Wheezy und Min 16 testen, Ubuntu werd ich demnächst zum Testen installieren, hab es aber zur Zeit nicht am Laufen.
Evtl gibt es ja jemand mit Ubuntu, der das mal testen will. Würde mich über Feedback freuen.
JackCarver
Well-known Member
Mal was zum Thema DNS und VPN, da das mE viele nicht so wirklich verstehen. Es ist nicht Aufgabe der Firewall festzulegen wie sich der Rechner zum DNS Server verbindet, es ist Aufgabe der Firewall den Port 53 UDP zu blocken oder freizulassen.
Unter Linux regelt eine ganz bestimmte Datei den DNS Server und das ist die /etc/resolv.conf. Das was in dieser Datei eingetragen ist wird von Linux als DNS Server verwendet.
Nun wird dort in der Regel zum Systemstart die Router-IP eingetragen sein, zumindest bei Verwendung des Network Managers wird diese IP bei Systemstart dort automatisch eingetragen.
Und jetzt wird das ganze interessant:
Verbindet man sich nun zu nem VPN Server wird nahezu jeglicher Traffic durch den Tunnel geleitet, mit 2 Ausnahmen:
1, Verbindungen zur VPN IP gehen nicht durch den Tunnel, was allein deswegen so sein muss, dass überhaupt ne Verbindung zustande kommt.
2, Verbindungen zu LAN IPs gehen ebenfalls nicht durch den Tunnel was ja sonst auch schlecht wäre.
Das bedeutet nun ganz einfach, dass wenn NACH erfolgter VPN Verbindung als DNS Server in der /etc/resolv.conf immer noch die Router-IP steht hat man ein DNS Leak!
Nun würde es in dem Fall auch nix bringen mit ner FW stumpf den UDP 53 zu blocken, da in dem Fall dann gar nix mehr geht.
Es ist also wichtig, dass NACH erfolgter VPN Verbindung in eben dieser Datei NICHT die Router-IP steht sondern die eines öffentlichen DNS Servers, denn in genau diesem Fall geht jeglicher DNS Traffic durch den Tunnel und es wäre hier auch kompletter Blödsinn den UDP 53 zu blocken, da sowieso alles durch den Tunnel geht was NICHT im LAN steht.
Damit dieser Supergau also ausbleibt verwendet man entweder den Network Manager zur VPN Einwahl, da dieser den von PP gepushten DNS einträgt oder man installiert das Paket resolvconf, das das Dank der dafür angepassten PP ovpn Dateien auch regelt.
Dann kann man auch OpenVPN von der Konsole starten und es gibt kein DNS Leak.
Unter Linux regelt eine ganz bestimmte Datei den DNS Server und das ist die /etc/resolv.conf. Das was in dieser Datei eingetragen ist wird von Linux als DNS Server verwendet.
Nun wird dort in der Regel zum Systemstart die Router-IP eingetragen sein, zumindest bei Verwendung des Network Managers wird diese IP bei Systemstart dort automatisch eingetragen.
Und jetzt wird das ganze interessant:
Verbindet man sich nun zu nem VPN Server wird nahezu jeglicher Traffic durch den Tunnel geleitet, mit 2 Ausnahmen:
1, Verbindungen zur VPN IP gehen nicht durch den Tunnel, was allein deswegen so sein muss, dass überhaupt ne Verbindung zustande kommt.
2, Verbindungen zu LAN IPs gehen ebenfalls nicht durch den Tunnel was ja sonst auch schlecht wäre.
Das bedeutet nun ganz einfach, dass wenn NACH erfolgter VPN Verbindung als DNS Server in der /etc/resolv.conf immer noch die Router-IP steht hat man ein DNS Leak!
Nun würde es in dem Fall auch nix bringen mit ner FW stumpf den UDP 53 zu blocken, da in dem Fall dann gar nix mehr geht.
Es ist also wichtig, dass NACH erfolgter VPN Verbindung in eben dieser Datei NICHT die Router-IP steht sondern die eines öffentlichen DNS Servers, denn in genau diesem Fall geht jeglicher DNS Traffic durch den Tunnel und es wäre hier auch kompletter Blödsinn den UDP 53 zu blocken, da sowieso alles durch den Tunnel geht was NICHT im LAN steht.
Damit dieser Supergau also ausbleibt verwendet man entweder den Network Manager zur VPN Einwahl, da dieser den von PP gepushten DNS einträgt oder man installiert das Paket resolvconf, das das Dank der dafür angepassten PP ovpn Dateien auch regelt.
Dann kann man auch OpenVPN von der Konsole starten und es gibt kein DNS Leak.
JackCarver
Well-known Member
Freut mich Ich werd noch ne Statusanzeige dazu basteln, so zum abrunden.
Ich werd noch ne Statusanzeige dazu basteln, so zum abrunden.
JackCarver
Well-known Member
Erste Version mit Statusanzeige ist eingestellt unter dem Qt 5 Link, die Qt 4 folgt noch
JackCarver
Well-known Member
Zur Version (nun 1.0) ist eine Möglichkeit zur Ausnahme der ssh und IPsec Ports dazugekommen, dadurch kann man trotz aktiver FW auch ohne OpenVPN ne ssh bzw IPsec Verbindung starten.
JackCarver
Well-known Member
Die Ubuntu Version ist nun auch online
theundertaker
Member
ich bin jetzt leider nicht so der linux-experte, aber könnte man deine iptables-regeln auch für einen raspberry pi verwenden (also ohne dem ersten teil) ? ich würde diesen gerne als internetgateway + openvpn für mein lan benutzen (2 netzwerkanschlüsse).
aber im moment fehlt mir ein wenig der plan dazu
aber im moment fehlt mir ein wenig der plan dazu
JackCarver
Well-known Member
Nein, diese Regeln sind nicht für einen Router geschrieben, für nen Router benötigst du die sogenannte FORWARD Kette der iptables. Der Router muss ja in der Regel nicht selbst gegen IP Leaks geschützt werden, sondern die Rechner dahinter. Prinzipiell sollte es genügen, wenn du bei allen Regeln OUTPUT bzw INPUT durch FORWARD ersetzt.
Du erlaubst damit dem Pi als Gateway das forwarden der Ports von OpenVPN für die Rechner hinter dem Pi rein und rausgehend und verbietest das forwarden durch andere Ports in und aus deinem LAN.
Für einen Internetgateway musst du den Pi dann allerdings noch für NAT konfigurieren, diese Regeln sind nur die Firewallkomponente, Der Pi hat 2 Netzwerkanschlüsse, also wahrscheinlich 1 mit Verbindung zu deinem DSL Router und 1 die dein LAN/WLAN verbindet.
Da das ja idR 2 unterschiedliche Netze sind, muss der Pi die IPs der anfragenden Rechner mit seiner IP, mit der er Zugriff auf den DSL Router hat NATen, dann geht der Traffic sauber raus und ebenso wieder rein.
Dasselbe wenn der Pi per OpenVPN verbunden ist, dann muss er die IPs der anfragenden Rechner durch seine OpenVPN IP NATen, damit die Rechner im LAN Zugriff auf das OpenVPN Netz erhalten.
Edit:
Die Erlaubnisregeln fürs LAN brauchst du dann natürlich nicht, du sperrst ja nur die FORWARD Kette am Ende, wogegen INPUT/OUTPUT frei bleiben.
Du erlaubst damit dem Pi als Gateway das forwarden der Ports von OpenVPN für die Rechner hinter dem Pi rein und rausgehend und verbietest das forwarden durch andere Ports in und aus deinem LAN.
Für einen Internetgateway musst du den Pi dann allerdings noch für NAT konfigurieren, diese Regeln sind nur die Firewallkomponente, Der Pi hat 2 Netzwerkanschlüsse, also wahrscheinlich 1 mit Verbindung zu deinem DSL Router und 1 die dein LAN/WLAN verbindet.
Da das ja idR 2 unterschiedliche Netze sind, muss der Pi die IPs der anfragenden Rechner mit seiner IP, mit der er Zugriff auf den DSL Router hat NATen, dann geht der Traffic sauber raus und ebenso wieder rein.
Dasselbe wenn der Pi per OpenVPN verbunden ist, dann muss er die IPs der anfragenden Rechner durch seine OpenVPN IP NATen, damit die Rechner im LAN Zugriff auf das OpenVPN Netz erhalten.
Edit:
Die Erlaubnisregeln fürs LAN brauchst du dann natürlich nicht, du sperrst ja nur die FORWARD Kette am Ende, wogegen INPUT/OUTPUT frei bleiben.
anonymous1
Member
HI, Super Arbeit. Ich würde auch gerne das Skript nutzen. allerdings will ich gerne das die Verbindung zu verschiedenen Webseiten (Onlineshops, Onlinebanking...) am VPN vorbeigeleitet wird. So das ich diesen nicht immer manuell beeenden muss wenn ich entsprechende Seiten aufrufe. Nur habe ich leider keine Ahnung von iptables. Kannst du mir nen beispiel posten?
JackCarver
Well-known Member
Da musst du sowohl an den iptables Regeln als auch am Routing was anpassen. Wenn dein Shop zb die IP Adresse 1.2.3.4 hat, dann musst du zum einen ne Ausnahme in den iptables hinzufügen:
iptables -t filter -A OUTPUT -o wlan0 -p tcp -d 1.2.3.4 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i wlan0 -p tcp -s 1.2.3.4 -m state --state ESTABLISHED,RELATED -j ACCEPT
Routing:
ip route add 1.2.3.4 via 192.168.0.1 dev wlan0
Gesetzt den Fall deine Gateway IP ist 192.168.0.1, sonst anpassen und dein Interface ist wlan0
Damit erlaubst du Verbindungen zu und von genau diesem Server in der Firewall ohne OpenVPN und zum anderen setzt du zu genau diesem Server ne Route an OpenVPN vorbei.
Das ganze klappt allerdings nur, wenn der Content der Website nicht auf unterschiedlichen Servern etc liegt, sonst musst du diese ebenfalls ausnehmen.
iptables -t filter -A OUTPUT -o wlan0 -p tcp -d 1.2.3.4 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i wlan0 -p tcp -s 1.2.3.4 -m state --state ESTABLISHED,RELATED -j ACCEPT
Routing:
ip route add 1.2.3.4 via 192.168.0.1 dev wlan0
Gesetzt den Fall deine Gateway IP ist 192.168.0.1, sonst anpassen und dein Interface ist wlan0
Damit erlaubst du Verbindungen zu und von genau diesem Server in der Firewall ohne OpenVPN und zum anderen setzt du zu genau diesem Server ne Route an OpenVPN vorbei.
Das ganze klappt allerdings nur, wenn der Content der Website nicht auf unterschiedlichen Servern etc liegt, sonst musst du diese ebenfalls ausnehmen.
anonymous1
Member
wo muss ich das routing anpassen? einfach mit ins iptables skript schreiben? ich nutze debian wheezy. un klappt das auch beim abruf von emails wenn ich einfach die pop bzw imap server als ausnahmen hinzufüge? meine mails rufe ich mit icedove ab.
JackCarver
Well-known Member
Den Routing Befehl kannst du mit in das Skript schreiben, der wird dann nach oder vor der iptables Regeln ausgeführt, ganz wie du das willst. Das klappt bei allen Servern, deren IP Adressen du als Ausnahme bei den iptables Regeln hinzufügst und auch die Routing Tabelle mit deren IPs anpasst.
anonymous1
Member
HI,
Heute habe ich endlich mal Zeit IP-Tables einzurichten.
Von der funktion her ist es irrelevant ob der Routing befehl nach oder vor der Regel ausgeführt wird?
In folgender Regel ist wlan0 als Interface angegeben.
Mein Interface ist allerding eth0.
wlan nutze ich nicht.
Das heist, dass ich die regeln mit wlan0 als Interface aus dem Skript löschen kann?
iptables -t filter -A OUTPUT -o wlan0 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Und noch eine Frage zu diese Regel
iptables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
iptables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
Ist mit 192.168.0.0/16 meine Gateway IP gemeint?
Wenn ja muss ich diese anpassen da ich eine andere verwende.
Und ist mit /16 der Port gemeint? Falls ich diesen auch anpassen muss, weiss ich nicht wie ich rausfinde welchen ich eintragen muss.
Danke schonmal
Heute habe ich endlich mal Zeit IP-Tables einzurichten.
Von der funktion her ist es irrelevant ob der Routing befehl nach oder vor der Regel ausgeführt wird?
In folgender Regel ist wlan0 als Interface angegeben.
Mein Interface ist allerding eth0.
wlan nutze ich nicht.
Das heist, dass ich die regeln mit wlan0 als Interface aus dem Skript löschen kann?
iptables -t filter -A OUTPUT -o wlan0 -p udp -m multiport --dports 1149,1150,1151,53,149,150,151 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Und noch eine Frage zu diese Regel
iptables -t filter -A OUTPUT --dst 192.168.0.0/16 -j ACCEPT
iptables -t filter -A INPUT --src 192.168.0.0/16 -j ACCEPT
Ist mit 192.168.0.0/16 meine Gateway IP gemeint?
Wenn ja muss ich diese anpassen da ich eine andere verwende.
Und ist mit /16 der Port gemeint? Falls ich diesen auch anpassen muss, weiss ich nicht wie ich rausfinde welchen ich eintragen muss.
Danke schonmal