Iptables User nur bestimmtes Interface erlauben
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
Iptables User nur bestimmtes Interface erlauben
Hallo,
ist es möglich einem Linux User alle Interfaces zu verbieten bis auf ein bestimmtes z.B. eth0:1? Ich sage gleich dazu das Iptables leider noch nicht mein Fachgebiet ist.
Falls jemand eine Lösungsidee hat würde mir das sehr helfen.
M.f.g. Bobbi
ist es möglich einem Linux User alle Interfaces zu verbieten bis auf ein bestimmtes z.B. eth0:1? Ich sage gleich dazu das Iptables leider noch nicht mein Fachgebiet ist.
Falls jemand eine Lösungsidee hat würde mir das sehr helfen.
M.f.g. Bobbi
Du kannst Filterregeln mit dem owner-Match auf eine bestimmte User-ID beschränken und du kannst Filterregeln auf ein bestimmtes Out-Interface beschränken.
Allerdings frage ich mich, was das genau werden soll. Output-Filterung ist ein schwieriges Terrain, weil ein lokaler Benutzer immer auch indirekte Möglichkeiten besitzt, Pakete zu erzeugen (Ping-Pakete z.B. gehören immer root, weil das Ping-Binary SUID-root ist) und außerdem verrät mir dein Erwähnen von Alias-Interfaces (veraltet und nicht empfohlen!), dass du mit deinem allgemeinen Netzwerk-Wissensstand mindestens 5 Jahre zurückhängst.
Janka
Allerdings frage ich mich, was das genau werden soll. Output-Filterung ist ein schwieriges Terrain, weil ein lokaler Benutzer immer auch indirekte Möglichkeiten besitzt, Pakete zu erzeugen (Ping-Pakete z.B. gehören immer root, weil das Ping-Binary SUID-root ist) und außerdem verrät mir dein Erwähnen von Alias-Interfaces (veraltet und nicht empfohlen!), dass du mit deinem allgemeinen Netzwerk-Wissensstand mindestens 5 Jahre zurückhängst.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
wie ich Linux foren immer liebe diese leicht arrogante Unterton der immer mitschwingt. es mag sein das ich 5 jahre zurück hänge aber da ich hier in meinem lokalen heim netz arbeite kann wohl nicht viel schief gehn.
ich möchte einen user der nur ein einziges Programm verwendet dazu zwingen eine bestimmte ip zu verwenden auch wenn in dem Programm eine andere gebunden wird.
eigentlich reicht es mir auch das es dann einfach nicht funktioniert.
gruß bobi
ich möchte einen user der nur ein einziges Programm verwendet dazu zwingen eine bestimmte ip zu verwenden auch wenn in dem Programm eine andere gebunden wird.
eigentlich reicht es mir auch das es dann einfach nicht funktioniert.
gruß bobi
ich hänge auch 5 Jahre zurück
Hallo,
ich bin nun ganz traurig, weil Deinem Zeilen entnehme, das ich auch 5 Jahre zurückhänge.... Wußte nicht, das dass nicht mehr "in" ist. Kann oder muss man den das dann extra verbieten? Wie belegt man den dann ein NIC mehrfach?
ich bin nun ganz traurig, weil Deinem Zeilen entnehme, das ich auch 5 Jahre zurückhänge.... Wußte nicht, das dass nicht mehr "in" ist. Kann oder muss man den das dann extra verbieten? Wie belegt man den dann ein NIC mehrfach?
Alias-Interfaces waren früher notwendig, weil jedes Interface nur eine IP-Adresse haben konnte. Seit mindestens(!) 5 Jahren benutzen aber fast alle Distributionen iproute2 und das zugehörige Tool "ip", um dies auch zu nutzen.
Die Alias-Funktionalität wird bei iproute2 mit dem "Label" zu jeder Adresse nachgebildet. Oder besser: Man könnte sie so nachbilden, denn die meisten Distributionen tragen keine Labels ein. Man benötigt sie nur, wenn man die veralteteten Werkzeuge "ifconfig" und "route" benutzt, die eben nur eine Adresse pro "Interface" verarbeiten können.
Benutzt man auf so einer Distribution ein unschuldiges "ifconfig", um die IP-Addresse eines Interfaces abzufragen, bekommt man nur die halbe Wahrheit mitgeteilt, nämlich nur die zuerst eingetragene Adresse, meist Link-Local (also 169.254.x.y). Man wundert sich aber, das ein Ping auf 192.168.1.1 funktioniert. Erst "ip addr show" zeigt einem alle Adressen.
Janka
Die Alias-Funktionalität wird bei iproute2 mit dem "Label" zu jeder Adresse nachgebildet. Oder besser: Man könnte sie so nachbilden, denn die meisten Distributionen tragen keine Labels ein. Man benötigt sie nur, wenn man die veralteteten Werkzeuge "ifconfig" und "route" benutzt, die eben nur eine Adresse pro "Interface" verarbeiten können.
Benutzt man auf so einer Distribution ein unschuldiges "ifconfig", um die IP-Addresse eines Interfaces abzufragen, bekommt man nur die halbe Wahrheit mitgeteilt, nämlich nur die zuerst eingetragene Adresse, meist Link-Local (also 169.254.x.y). Man wundert sich aber, das ein Ping auf 192.168.1.1 funktioniert. Erst "ip addr show" zeigt einem alle Adressen.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
Nein. So etwas wie "virtuelle IPs" gibt es nicht. Entweder der Rechner akzeptiert das Paket auf einer Adresse oder nicht. Chroots haben auch nichts mit Netzwerk zu tun, sondern sind einfach das, was sie aussagen: Changed Roots, also ein gewechseltes Wurzelverzeichnis, aus dem ein Prozess nicht wieder herauskommt.bobbigrill hat geschrieben:ich stelle mal eine andere frage vielleicht kann mir ja da einer weiterhelfen, ist es möglich das in einem chroot Container nur eine virtuelle ip zur verfügung steht?
Bei Alias-Interfaces? Dass die Dinge subtil anders funktionieren als du gedacht hast. Iptables schert sich z.B. nicht um die an IP-Adressen angebrachten Labels und damit auch nicht um "Alias-Interfaces". Du kannst dort nur echte Interface-Namen angeben und musst halt die Quell- bzw. Zieladresse einer Regel explizit benennen.und bei der Gelegenheit, ich mein ich bin ja lern willig, wo ist das Problem mit der alten Technik welche Risiken entstehen dadurch?
Deshalb: Alias-Interfaces allenfalls für Distributionen ohne iproute2 im Hinterkopf behalten.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
Du hast oben geschrieben, dass du erzwingen willst, dass Pakete eines bestimmten Nutzers immer mit einer bestimmten Absender-IP-Adresse den Rechner verlassen. Das kann man in der nat-Table des Netfilters mittels SNAT erreichen.
Siehe http://www.netfilter.org/documentation/ ... WTO-6.html
Hinweis: Diese Antwort hätte man ohne zusätzliches Nachfragen allein aus der Ursprungsfrage nicht geben können. Diese las sich nämlich so als sei Filtern gewünscht, nicht NAT. Insofern ist es schon bei der Fragestellung nicht egal, dass du eigentlich nur willst, dass es funktioniert - du musst so viele *rohe* (also von deiner eigenen Vorstellung, wie eine Lösung aussehen müsste, unabhängige) Informationen wie möglich liefern, sonst kann man dir nicht den richtigen Rat geben und es wird folglich auch nicht funktionieren. Das gilt umso mehr, je weniger du dich auskennst. Jemandem, der von Anfang an hilfreiche Nachfragen stellt und dann eine hilfreiche Antwort gibt gleich Arroganz vorzuwerfen, ist natürlich der Gipfel, aber auch typisch für eine bestimmte Art von Fragesteller. (Du kannst natürlich auch dies jetzt wieder für arrogant halten, es wird dich aber in Kommunikationsdingen nicht weiterbringen - die nächste Stufe setzt Selbstreflexion voraus.)
Janka
Code: Alles auswählen
# iptables -t nat -A POSTROUTING -m owner --uid-owner 123 -j SNAT --to-source 1.2.3.4
Hinweis: Diese Antwort hätte man ohne zusätzliches Nachfragen allein aus der Ursprungsfrage nicht geben können. Diese las sich nämlich so als sei Filtern gewünscht, nicht NAT. Insofern ist es schon bei der Fragestellung nicht egal, dass du eigentlich nur willst, dass es funktioniert - du musst so viele *rohe* (also von deiner eigenen Vorstellung, wie eine Lösung aussehen müsste, unabhängige) Informationen wie möglich liefern, sonst kann man dir nicht den richtigen Rat geben und es wird folglich auch nicht funktionieren. Das gilt umso mehr, je weniger du dich auskennst. Jemandem, der von Anfang an hilfreiche Nachfragen stellt und dann eine hilfreiche Antwort gibt gleich Arroganz vorzuwerfen, ist natürlich der Gipfel, aber auch typisch für eine bestimmte Art von Fragesteller. (Du kannst natürlich auch dies jetzt wieder für arrogant halten, es wird dich aber in Kommunikationsdingen nicht weiterbringen - die nächste Stufe setzt Selbstreflexion voraus.)
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
Wie schon gesagt, wenn der Kernel iproute2-Support hat (und das hat heutzutage praktisch jeder Distributionskernel), kann jedes Interface beliebig viele IP-Adressen haben. Alias-Interfaces werden auf Adresslabels gemappt, auf Kernel-Seite existieren Alias-Interfaces nicht. Das ist alles nur eine Krücke für ifconfig und route. Du kannst dich damit hervorragend selbst verwirren, denn nicht alle Distributionen setzen Labels für die Adressen, und diese Adressen sind dann für ifconfig und route unsichtbar.
Du musst auch nicht bestimmte Interfaces mit iproute2 einrichten - Du musst dir einfach nur angewöhnen, das Tool "ip" zu benutzen und "ifconfig" und "route" vergessen. Intern ist alles iproute2, wenn der Kernel das kann, auch wenn du ifconfig und route benutzt.
Du kannst diese Krücken natürlich trotzdem weiter benutzen, für iptables sind sie allerdings bedeutungslos. Jeder Versuch, bei iptables Alias-Interfaces dort zu verwenden, wo Interfaces erwartet werden, geht schief. Es gibt keine Fehlermeldung, die Aliasnamen werden sogar gelistet, es funktioniert nur einfach nicht. Beispiel:
Die Output-Policy ist DROP, allerdings erlaubt die einzige Regel ja angeblich allen Netzwerkverkehr, der von eth0:1 ausgeht. Man müsste also Pakete verschicken können. Pustekuchen! Ersetzt man in iptables eth0:1 hingegen durch eth0, klappt es, man kann Pakete verschicken. Und das, obwohl eth0 ja laut ifconfig gar keine Adresse hat.
Das genau ist der Schaden, den man mit ifconfig, route und Alias-Interfaces anrichten kann: Man versteht nicht, warum es nicht funktioniert.
Janka
Du musst auch nicht bestimmte Interfaces mit iproute2 einrichten - Du musst dir einfach nur angewöhnen, das Tool "ip" zu benutzen und "ifconfig" und "route" vergessen. Intern ist alles iproute2, wenn der Kernel das kann, auch wenn du ifconfig und route benutzt.
Du kannst diese Krücken natürlich trotzdem weiter benutzen, für iptables sind sie allerdings bedeutungslos. Jeder Versuch, bei iptables Alias-Interfaces dort zu verwenden, wo Interfaces erwartet werden, geht schief. Es gibt keine Fehlermeldung, die Aliasnamen werden sogar gelistet, es funktioniert nur einfach nicht. Beispiel:
Code: Alles auswählen
# ifconfig
eth0 Link encap:Ethernet Hardware Adresse 01:23:45:67:89:ab Maske:255.255.255.0
inet6 Adresse: fe80::201:41af:f58b:e43/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27833 errors:0 dropped:0 overruns:0 frame:0
TX packets:26841 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:36974761 (35.2 Mb) TX bytes:1986354 (1.8 Mb)
eth0:1 Link encap:Ethernet Hardware Adresse 01:23:45:67:89:ab
inet Adresse:192.168.178.126 Bcast:192.168.178.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
[...]
# iptables -P OUTPUT DROP
# iptables -A OUTPUT -o eth0:1 -j ACCEPT
# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 2 packets, 168 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * eth0:1 0.0.0.0/0 0.0.0.0/0
# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
Das genau ist der Schaden, den man mit ifconfig, route und Alias-Interfaces anrichten kann: Man versteht nicht, warum es nicht funktioniert.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54
Auch das VPN wird über die Output-Chain geleitet. Allerdings braucht man einen Helper, um die Verschlüsselung zu bewerkstelligen, und dieser Helper ist das Programm, das aus Kernelsicht die Pakete erzeugt. Evtl. gibt es dann mit dem owner-match Probleme, weil der relevante Teil des Helpers als root läuft. Du müsstest statt auf eth0 auf das Interface tun0 matchen, um Pakete zu erwischen, die den Rechner auf dem VPN-Wege "verlassen". Dort sollte der Eigentümer des Paketes noch intakt sein.
Jetzt schreib doch mal genau, was du eigentlich machen willst. Details bitte.
Janka
Jetzt schreib doch mal genau, was du eigentlich machen willst. Details bitte.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
-
- Beiträge: 7
- Registriert: 16. Aug 2012 0:54