Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Geraete abschotten bei VPN Fritz!Box zu Fritz!Box
3 views
Skip to first unread message
Alexander Goetzenstein
Jan 11, 2024, 6:15:44 PM1/11/24
to
Hallo,
hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
Verbindung nach außen aufbauen.
Ursprünglich war ich davon ausgegangen, dass das jeweils andere über das
VPN erreichbare private Netz nicht mit dem Internet gleichgesetzt wird,
aber so einfach ist das mit der Fritz!Box wohl nicht. Mein bisheriger
Stand: Entweder komplette Freigabe des Internet für die Geräte, oder sie
sind nicht über das VPN erreichbar.
Jetzt bin ich auf den Gedanken verfallen, einzelne IPs in die Liste
erlaubter IP-Adressen einzutragen, aber so einfach geht das wohl nicht.
Zuerst muss wohl ein Verbindungsversuch stattfinden, der dann von der
Fritz!Box registriert wird und in eine Liste aufgenommen wird; in dieser
Liste kann man diese dann auswählen und freigeben. Habe ich das richtig
verstanden?
Wenn das so ist, scheitere ich daran, das Gerät eine solche Verbindung
aufzubauen. Zwar habe ich ssh-Zugang zum Gerät, doch ein ping ist nicht
möglich:
> alex@ds1815:~$ ping -c 3 192.168.22.100
> ping: socket: Operation not permitted
Was könnte ich noch versuchen?
--
Gruß
Alex
hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
Verbindung nach außen aufbauen.
Ursprünglich war ich davon ausgegangen, dass das jeweils andere über das
VPN erreichbare private Netz nicht mit dem Internet gleichgesetzt wird,
aber so einfach ist das mit der Fritz!Box wohl nicht. Mein bisheriger
Stand: Entweder komplette Freigabe des Internet für die Geräte, oder sie
sind nicht über das VPN erreichbar.
Jetzt bin ich auf den Gedanken verfallen, einzelne IPs in die Liste
erlaubter IP-Adressen einzutragen, aber so einfach geht das wohl nicht.
Zuerst muss wohl ein Verbindungsversuch stattfinden, der dann von der
Fritz!Box registriert wird und in eine Liste aufgenommen wird; in dieser
Liste kann man diese dann auswählen und freigeben. Habe ich das richtig
verstanden?
Wenn das so ist, scheitere ich daran, das Gerät eine solche Verbindung
aufzubauen. Zwar habe ich ssh-Zugang zum Gerät, doch ein ping ist nicht
möglich:
> alex@ds1815:~$ ping -c 3 192.168.22.100
> ping: socket: Operation not permitted
Was könnte ich noch versuchen?
--
Gruß
Alex
Marco Moock
Jan 12, 2024, 1:48:43 AM1/12/24
to
Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
> kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
> Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
> bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
> Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
> Verbindung nach außen aufbauen.
Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
> kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
> Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
> bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
> Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
> Verbindung nach außen aufbauen.
Problem erstmal erstickt.
An den Tunnelendpunkten dann ebenfalls nur Routing da hin, wo du es
willst.
Die FB ist aber vermutlich das falsche Gerät dafür.
Helmut Harnisch
Jan 12, 2024, 3:17:11 AM1/12/24
to
Am 12.01.2024 um 07:48 schrieb Marco Moock:
> Die FB ist aber vermutlich das falsche Gerät dafür.
Dafür wäre wohl ein Router mit vLan Möglichkit geeigneter.
> Die FB ist aber vermutlich das falsche Gerät dafür.
Alexander Goetzenstein
Jan 12, 2024, 4:26:32 AM1/12/24
to
Hallo,
Am 12.01.24 um 07:48 schrieb Marco Moock:
den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
beschneiden.
> An den Tunnelendpunkten dann ebenfalls nur Routing da hin, wo du es
> willst.
> Die FB ist aber vermutlich das falsche Gerät dafür.
Die Fritz!Boxen sind vorgegeben.
--
Gruß
Alex
Am 12.01.24 um 07:48 schrieb Marco Moock:
> Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
>
>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
>> kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
>> Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
>> bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
>> Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
>> Verbindung nach außen aufbauen.
>
> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
> Problem erstmal erstickt.
wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber für
>
>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins Internet
>> kommen sollen. Es soll für diese beiden Geräte also ein geschlossenes
>> Intranet eingerichtet werden, in dem nur sie sich gegenseitig (und ein
>> bestimmter PC im dem einen LAN zum Zugriff des Interfaces im Browser).
>> Weder dürfen die Geräte sonst von außen erreichbar sein noch selbst
>> Verbindung nach außen aufbauen.
>
> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
> Problem erstmal erstickt.
den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
beschneiden.
> An den Tunnelendpunkten dann ebenfalls nur Routing da hin, wo du es
> willst.
> Die FB ist aber vermutlich das falsche Gerät dafür.
--
Gruß
Alex
Marco Moock
Jan 12, 2024, 5:02:05 AM1/12/24
to
Am 12.01.2024 um 10:26:29 Uhr schrieb Alexander Goetzenstein:
> Am 12.01.24 um 07:48 schrieb Marco Moock:
> > Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
> >
> >> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> >> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
> >> Internet kommen sollen. Es soll für diese beiden Geräte also ein
> >> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
> >> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
> >> des Interfaces im Browser). Weder dürfen die Geräte sonst von
> >> außen erreichbar sein noch selbst Verbindung nach außen aufbauen.
> >
> > Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
> > das Problem erstmal erstickt.
>
> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber für
> den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
> wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
> beschneiden.
Die Route sieht dann so aus:
> Am 12.01.24 um 07:48 schrieb Marco Moock:
> > Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
> >
> >> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> >> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
> >> Internet kommen sollen. Es soll für diese beiden Geräte also ein
> >> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
> >> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
> >> des Interfaces im Browser). Weder dürfen die Geräte sonst von
> >> außen erreichbar sein noch selbst Verbindung nach außen aufbauen.
> >
> > Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
> > das Problem erstmal erstickt.
>
> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber für
> den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
> wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
> beschneiden.
fd00:abcd::/64 via 2001:db8::3 dev vpn0.
Damit wird nur das Netz fd00:abcd::/64 durch den Tunnel geroutet.
Das an beiden Endpunkten, damit Änderungen auf der einen Seite nicht
ausreichend sind, um E2E über den Tunnel zu routen.
Das verhindert aber nicht, dass jemand manuell eine Standardroute (oder
weitere Routen) setzen kann.
Wird die Route vom VPN-Client automatisch gesetzt?
Anton Berg
Jan 12, 2024, 5:02:51 AM1/12/24
to
Hallo,
Am 12.01.2024 um 10:26 schrieb Alexander Goetzenstein:
> Am 12.01.24 um 07:48 schrieb Marco Moock:
Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
vielleicht für das angeschlossene Gerät "Internetzugang sperren"
(unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
anlegen (Internet - Filter - Zugangsprofile).
Käme auf einen Versuch an... und mit einer pfsense, OPNsense
oder was auch immer wäre das "geradliniger" lösbar, wie Marco
und Helmut schon bemerkten.
Und gib nicht zu viel auf den Ping, die FB ist über VPN etwas...
ähm... "eigen". ;-)
--
Gruß Anton
Am 12.01.2024 um 10:26 schrieb Alexander Goetzenstein:
> Am 12.01.24 um 07:48 schrieb Marco Moock:
>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
>> Problem erstmal erstickt.
>
> Die Fritz!Boxen sind vorgegeben.
>> Problem erstmal erstickt.
>
Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
vielleicht für das angeschlossene Gerät "Internetzugang sperren"
(unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
anlegen (Internet - Filter - Zugangsprofile).
Käme auf einen Versuch an... und mit einer pfsense, OPNsense
oder was auch immer wäre das "geradliniger" lösbar, wie Marco
und Helmut schon bemerkten.
Und gib nicht zu viel auf den Ping, die FB ist über VPN etwas...
ähm... "eigen". ;-)
--
Gruß Anton
Alexander Goetzenstein
Jan 12, 2024, 10:10:22 AM1/12/24
to
Hallo,
Am 12.01.24 um 11:02 schrieb Anton Berg:
mehr erreichbar ist.
> Und gib nicht zu viel auf den Ping, die FB ist über VPN etwas...
> ähm... "eigen". ;-)
Wie ich das verstehe, wird ping von den NASen nicht zugelassen, das
kommt gar nicht erst bis zur FB. Aber ich habe ssh versucht: das
funktionierte auch erst, nachdem ich das NAS ins Internet gelassen habe.
Irgendwie scheint mir, dass ich von einem VPN eine leicht abweichende
Vorstellung habe von dem, was die Fritz!Boxen das machen. Wer recht hat,
weiß ich nicht -immerhin sitzen bei AVM Profis, ich bin bestenfalls Amateur.
--
Gruß
Alex
Am 12.01.24 um 11:02 schrieb Anton Berg:
> Hallo,
>
> Am 12.01.2024 um 10:26 schrieb Alexander Goetzenstein:
>> Am 12.01.24 um 07:48 schrieb Marco Moock:
>>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
>>> Problem erstmal erstickt.
>>
>> Die Fritz!Boxen sind vorgegeben.
>
> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
> anlegen (Internet - Filter - Zugangsprofile).
beides hat zur Folge, dass das Gerät auch aus dem anderen Netz nicht
>
> Am 12.01.2024 um 10:26 schrieb Alexander Goetzenstein:
>> Am 12.01.24 um 07:48 schrieb Marco Moock:
>>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist das
>>> Problem erstmal erstickt.
>>
>> Die Fritz!Boxen sind vorgegeben.
>
> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
> anlegen (Internet - Filter - Zugangsprofile).
mehr erreichbar ist.
> Und gib nicht zu viel auf den Ping, die FB ist über VPN etwas...
> ähm... "eigen". ;-)
kommt gar nicht erst bis zur FB. Aber ich habe ssh versucht: das
funktionierte auch erst, nachdem ich das NAS ins Internet gelassen habe.
Irgendwie scheint mir, dass ich von einem VPN eine leicht abweichende
Vorstellung habe von dem, was die Fritz!Boxen das machen. Wer recht hat,
weiß ich nicht -immerhin sitzen bei AVM Profis, ich bin bestenfalls Amateur.
--
Gruß
Alex
Alexander Goetzenstein
Jan 12, 2024, 10:12:29 AM1/12/24
to
Hallo,
Am 12.01.24 um 11:02 schrieb Marco Moock:
> Das an beiden Endpunkten, damit Änderungen auf der einen Seite nicht
> ausreichend sind, um E2E über den Tunnel zu routen.
>
> Das verhindert aber nicht, dass jemand manuell eine Standardroute (oder
> weitere Routen) setzen kann.
>
> Wird die Route vom VPN-Client automatisch gesetzt?
Die Routen werden in der Fritz!Box gesetzt, in den NASen habe ich (noch)
nichts dazu gefunden. Die übernehmen wohl nur, was die FB ihnen vorsetzt.
--
Gruß
Alex
Am 12.01.24 um 11:02 schrieb Marco Moock:
> Am 12.01.2024 um 10:26:29 Uhr schrieb Alexander Goetzenstein:
>
>> Am 12.01.24 um 07:48 schrieb Marco Moock:
>>> Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
>>>
>>>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
>>>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
>>>> Internet kommen sollen. Es soll für diese beiden Geräte also ein
>>>> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
>>>> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
>>>> des Interfaces im Browser). Weder dürfen die Geräte sonst von
>>>> außen erreichbar sein noch selbst Verbindung nach außen aufbauen.
>>>
>>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
>>> das Problem erstmal erstickt.
>>
>> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber für
>> den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
>> wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
>> beschneiden.
>
> Die Route sieht dann so aus:
> fd00:abcd::/64 via 2001:db8::3 dev vpn0.
>
> Damit wird nur das Netz fd00:abcd::/64 durch den Tunnel geroutet.
hier gibt's nur IPv4.
>
>> Am 12.01.24 um 07:48 schrieb Marco Moock:
>>> Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
>>>
>>>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
>>>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
>>>> Internet kommen sollen. Es soll für diese beiden Geräte also ein
>>>> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
>>>> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
>>>> des Interfaces im Browser). Weder dürfen die Geräte sonst von
>>>> außen erreichbar sein noch selbst Verbindung nach außen aufbauen.
>>>
>>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
>>> das Problem erstmal erstickt.
>>
>> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber für
>> den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste nicht,
>> wie ich das ändern kann, ohne die Funktion der übrigen Geräte zu
>> beschneiden.
>
> Die Route sieht dann so aus:
> fd00:abcd::/64 via 2001:db8::3 dev vpn0.
>
> Damit wird nur das Netz fd00:abcd::/64 durch den Tunnel geroutet.
> Das an beiden Endpunkten, damit Änderungen auf der einen Seite nicht
> ausreichend sind, um E2E über den Tunnel zu routen.
>
> Das verhindert aber nicht, dass jemand manuell eine Standardroute (oder
> weitere Routen) setzen kann.
>
> Wird die Route vom VPN-Client automatisch gesetzt?
nichts dazu gefunden. Die übernehmen wohl nur, was die FB ihnen vorsetzt.
--
Gruß
Alex
Marco Moock
Jan 12, 2024, 11:23:57 AM1/12/24
to
Am 12.01.2024 um 16:12:26 Uhr schrieb Alexander Goetzenstein:
> Hallo,
>
> Am 12.01.24 um 11:02 schrieb Marco Moock:
> > Am 12.01.2024 um 10:26:29 Uhr schrieb Alexander Goetzenstein:
> >
> >> Am 12.01.24 um 07:48 schrieb Marco Moock:
> >>> Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
> >>>
> >>>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> >>>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
> >>>> Internet kommen sollen. Es soll für diese beiden Geräte also ein
> >>>> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
> >>>> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
> >>>> des Interfaces im Browser). Weder dürfen die Geräte sonst von
> >>>> außen erreichbar sein noch selbst Verbindung nach außen
> >>>> aufbauen.
> >>>
> >>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
> >>> das Problem erstmal erstickt.
> >>
> >> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber
> >> für den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste
> >> nicht, wie ich das ändern kann, ohne die Funktion der übrigen
> >> Geräte zu beschneiden.
> >
> > Die Route sieht dann so aus:
> > fd00:abcd::/64 via 2001:db8::3 dev vpn0.
> >
> > Damit wird nur das Netz fd00:abcd::/64 durch den Tunnel geroutet.
>
> hier gibt's nur IPv4.
Ändert nichts daran, geht mit IPv4 genauso.
> Hallo,
>
> Am 12.01.24 um 11:02 schrieb Marco Moock:
> > Am 12.01.2024 um 10:26:29 Uhr schrieb Alexander Goetzenstein:
> >
> >> Am 12.01.24 um 07:48 schrieb Marco Moock:
> >>> Am 12.01.2024 um 00:15:42 Uhr schrieb Alexander Goetzenstein:
> >>>
> >>>> hier habe ich zwei NAS-Geräte, die über ein VPN (IP-Sec) zweier
> >>>> Fritz!Boxen miteinander kommunizieren sollen, aber nicht ins
> >>>> Internet kommen sollen. Es soll für diese beiden Geräte also ein
> >>>> geschlossenes Intranet eingerichtet werden, in dem nur sie sich
> >>>> gegenseitig (und ein bestimmter PC im dem einen LAN zum Zugriff
> >>>> des Interfaces im Browser). Weder dürfen die Geräte sonst von
> >>>> außen erreichbar sein noch selbst Verbindung nach außen
> >>>> aufbauen.
> >>>
> >>> Dann würde ich hier ein VPN ohne Standardroute aufbauen, damit ist
> >>> das Problem erstmal erstickt.
> >>
> >> wie meinst Du das? Das VPN hat natürlich seine eigene Route, aber
> >> für den Rest der LANs gibt es natürlich Standardrouten. Ich wüsste
> >> nicht, wie ich das ändern kann, ohne die Funktion der übrigen
> >> Geräte zu beschneiden.
> >
> > Die Route sieht dann so aus:
> > fd00:abcd::/64 via 2001:db8::3 dev vpn0.
> >
> > Damit wird nur das Netz fd00:abcd::/64 durch den Tunnel geroutet.
>
> hier gibt's nur IPv4.
> > Das an beiden Endpunkten, damit Änderungen auf der einen Seite nicht
> > ausreichend sind, um E2E über den Tunnel zu routen.
> >
> > Das verhindert aber nicht, dass jemand manuell eine Standardroute
> > (oder weitere Routen) setzen kann.
> >
> > Wird die Route vom VPN-Client automatisch gesetzt?
>
> Die Routen werden in der Fritz!Box gesetzt, in den NASen habe ich
> (noch) nichts dazu gefunden. Die übernehmen wohl nur, was die FB
> ihnen vorsetzt.
Wenn das nicht geht, musst du damit leben oder andere Geräte anschaffen.
Michael Schwingen
Jan 12, 2024, 11:39:28 AM1/12/24
to
On 2024-01-12, Marco Moock <mm+s...@dorfdsl.de> wrote:
>
> Dann muss an der FB die Route geändert werden.
Ich denke nicht, daß das hilft. Wenn die beiden NAS jeweils im lokalen Netz
>
> Dann muss an der FB die Route geändert werden.
stehen, gilt auch die Defaultroute des Netzes für die - wenn Du die änderst,
kommen auch alle anderen Geräte nicht mehr ins Internet.
Man braucht entweder ein getrenntes IP-Netz für die NAS-Boxen (dann kann man
dieses getrennte Netz ohne Defaultroute aufsetzen, und tunneln, muss aber
sehen, wie man vom lokalen PC da drankommt), oder Firewallregeln, die dem
NAS den Zugang über die Defaultroute verbieten.
Bei beidem bin ich skeptisch, daß das mit einer Fritzbox geht.
cu
Michael
--
Some people have no respect of age unless it is bottled.
Christian Garbs
Jan 13, 2024, 5:04:43 AM1/13/24
to
Mahlzeit!
Alexander Goetzenstein <alexander_g...@web.de> wrote:
> Irgendwie scheint mir, dass ich von einem VPN eine leicht abweichende
> Vorstellung habe von dem, was die Fritz!Boxen das machen. Wer recht hat,
> weiß ich nicht -immerhin sitzen bei AVM Profis, ich bin bestenfalls Amateur.
Aber Fritz!Boxen sind Consumer-Geräte. Als Amateur ist es durchaus
realistisch, dass Du mehr willst, als sie können ;-)
Hier macht ein sowieso laufender lokaler Server DNS, Routing, VPN
usw., der hat eine zweite Netzwerkkarte, an der ausschließlich die
Fritz!Box hängt. Damit bin ich so flexibel, wie ich Linux-Software
auftreiben kann. Die Fritz!Box macht effektiv das, was früher ein
reines DSL-Modem gemacht hat: nur die Verbindung ins Internet (plus
Telefonanlage und Gäste-WLAN).
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
post tenebras lux. post fenestras tux.
Alexander Goetzenstein <alexander_g...@web.de> wrote:
> Irgendwie scheint mir, dass ich von einem VPN eine leicht abweichende
> Vorstellung habe von dem, was die Fritz!Boxen das machen. Wer recht hat,
> weiß ich nicht -immerhin sitzen bei AVM Profis, ich bin bestenfalls Amateur.
realistisch, dass Du mehr willst, als sie können ;-)
Hier macht ein sowieso laufender lokaler Server DNS, Routing, VPN
usw., der hat eine zweite Netzwerkkarte, an der ausschließlich die
Fritz!Box hängt. Damit bin ich so flexibel, wie ich Linux-Software
auftreiben kann. Die Fritz!Box macht effektiv das, was früher ein
reines DSL-Modem gemacht hat: nur die Verbindung ins Internet (plus
Telefonanlage und Gäste-WLAN).
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
post tenebras lux. post fenestras tux.
Anton Berg
Jan 13, 2024, 6:54:27 AM1/13/24
to
Am 12.01.2024 um 16:10 schrieb Alexander Goetzenstein:
>> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
>> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
>> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
>> anlegen (Internet - Filter - Zugangsprofile).
>
> beides hat zur Folge, dass das Gerät auch aus dem anderen Netz nicht
> mehr erreichbar ist.
Ich hatte sowas befürchtet - die FB ist halt gut für die üblichen
>> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
>> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
>> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
>> anlegen (Internet - Filter - Zugangsprofile).
>
> beides hat zur Folge, dass das Gerät auch aus dem anderen Netz nicht
> mehr erreichbar ist.
Consumer-Ansprüche, habe selber eine, aber die macht nur Telefon und
die Internetverbindung, alles andere passiert dahinter.
Hast du schon probiert, den Internetzugang für die Geräte zwar
freizugeben, aber über Internet - Filter - Listen eine Whitelist
für die Gegenseite zu erstellen und per Profil zuzuweisen?
--
Gruß Anton
Alexander Goetzenstein
Jan 15, 2024, 4:44:07 AM1/15/24
to
Hallo,
Am 13.01.24 um 12:54 schrieb Anton Berg:
da müsste ich die IP-Liste bearbeiten, was mir nicht gelingt: ich kann
nur vorhandene Einträge auswählen, keine neuen manuell hinzufügen. Und
"natürlich" enthält die Liste keinen einzigen Eintrag, den ich auswählen
könnte.
--
Gruß
Alex
Am 13.01.24 um 12:54 schrieb Anton Berg:
nur vorhandene Einträge auswählen, keine neuen manuell hinzufügen. Und
"natürlich" enthält die Liste keinen einzigen Eintrag, den ich auswählen
könnte.
--
Gruß
Alex
Anton Berg
Jan 15, 2024, 11:56:35 AM1/15/24
to
Am 15.01.2024 um 17:27 schrieb Markus Ermert:
> Spielereien wirklich benötigt, gibt es denn?
Vielleicht z.B. das, was Alexander zu erreichen beabsichtigt? :-)
Oder konkrete Vorstellungen zu "wer darf wann wie was wohin?".
Das mag unüblich sein, aber als Spielerei würde ich es wenigstens
nicht in jedem Fall abtun.
--
Gruß Anton
> Anton Berg <m...@me.invalid> wrote:
>> Ich hatte sowas befürchtet - die FB ist halt gut für die üblichen
>> Consumer-Ansprüche
>
> Welche unüblichen Consumer-Ansprüche, die man als Verbraucher jenseits von
>> Ich hatte sowas befürchtet - die FB ist halt gut für die üblichen
>> Consumer-Ansprüche
>
> Spielereien wirklich benötigt, gibt es denn?
Vielleicht z.B. das, was Alexander zu erreichen beabsichtigt? :-)
Oder konkrete Vorstellungen zu "wer darf wann wie was wohin?".
Das mag unüblich sein, aber als Spielerei würde ich es wenigstens
nicht in jedem Fall abtun.
--
Gruß Anton
Jörg Tewes
Jan 15, 2024, 2:22:08 PM1/15/24
to
Alexander Goetzenstein schrieb:
Was für eine Fritzbox hast du denn, das du keine Geräte hinzufügen
kannst, die noch keinen Kontakt zur Fritzbox hatten? Bei mir steht
unter Einstellungen --> Heimnetz --> Netzwerk ganz unten Geräte
hinzufügen und darunter als Erklärung
"Sie können Netzwerkgeräte hinzufügen, denen eine feste IP-Adresse
zugewiesen werden soll und die bisher noch keinen Kontakt zur
FRITZ!Box hatten."
--
Bye Jörg
Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei
denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn
Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der
Tür hängen?
kannst, die noch keinen Kontakt zur Fritzbox hatten? Bei mir steht
unter Einstellungen --> Heimnetz --> Netzwerk ganz unten Geräte
hinzufügen und darunter als Erklärung
"Sie können Netzwerkgeräte hinzufügen, denen eine feste IP-Adresse
zugewiesen werden soll und die bisher noch keinen Kontakt zur
FRITZ!Box hatten."
--
Bye Jörg
Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei
denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn
Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der
Tür hängen?
Thomas Einzel
Jan 15, 2024, 3:07:19 PM1/15/24
to
Am 15.01.2024 um 17:27 schrieb Markus Ermert:
> Anton Berg <m...@me.invalid> wrote:
> Anton Berg <m...@me.invalid> wrote:
>> Am 12.01.2024 um 16:10 schrieb Alexander Goetzenstein:
>>>> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
>>>> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
>>>> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
>>>> anlegen (Internet - Filter - Zugangsprofile).
>>>
>>> beides hat zur Folge, dass das Gerät auch aus dem anderen Netz nicht
>>> mehr erreichbar ist.
>>
>> Ich hatte sowas befürchtet - die FB ist halt gut für die üblichen
>>>> Schuss ins Blaue - ohne dass ich das praktisch probiert hätte:
>>>> vielleicht für das angeschlossene Gerät "Internetzugang sperren"
>>>> (unter Heimnetz - Netzwerk) oder ein entsprechendes Profil dafür
>>>> anlegen (Internet - Filter - Zugangsprofile).
>>>
>>> beides hat zur Folge, dass das Gerät auch aus dem anderen Netz nicht
>>> mehr erreichbar ist.
>>
>> Ich hatte sowas befürchtet - die FB ist halt gut für die üblichen
>> Consumer-Ansprüche
>
> Welche unüblichen Consumer-Ansprüche, die man als Verbraucher jenseits von
> Spielereien wirklich benötigt, gibt es denn?
Welche "unüblichen Consumer Ansprüche" würdest du denn überhaupt gelten
>
> Welche unüblichen Consumer-Ansprüche, die man als Verbraucher jenseits von
> Spielereien wirklich benötigt, gibt es denn?
lassen?
Konfigurierbare Paketfilter-/Firewallregeln (minimal Ziel und Port) -
vermutlich nicht.
Wirkliche VLAN Konfiguration - vermutlich nicht.
WPAx-Enterprise Auth (ext.) - vermutlich nicht.
Also?
--
Thomas
Marco Moock
Jan 15, 2024, 3:22:48 PM1/15/24
to
Am 15.01.2024 um 21:07:15 Uhr schrieb Thomas Einzel:
> Welche "unüblichen Consumer Ansprüche" würdest du denn überhaupt
> gelten lassen?
> Konfigurierbare Paketfilter-/Firewallregeln (minimal Ziel und Port) -
> vermutlich nicht.
Hat die FB nicht sowas?
> Welche "unüblichen Consumer Ansprüche" würdest du denn überhaupt
> gelten lassen?
> Konfigurierbare Paketfilter-/Firewallregeln (minimal Ziel und Port) -
> vermutlich nicht.
> Wirkliche VLAN Konfiguration - vermutlich nicht.
> WPAx-Enterprise Auth (ext.) - vermutlich nicht.
Thomas Einzel
Jan 15, 2024, 3:33:14 PM1/15/24
to
und sich in die Konfiguration dieser einarbeiten. Seine Anforderungen
sind erfüllbar (ob sie sinnvoll sind, muss er als Anforderer und
Bezahler selber einschätzen).
BTW: Mein Consumer Netzwerk könnte ich mit einer Fritzbox auch nicht
betreiben. Aber: aktuelle Fritzboxen sind sozusagen das kleinste Übel
und für viele Privatanwender erfüllen sie deren Anforderungen.
--
Thomas
Alexander Goetzenstein
Jan 15, 2024, 4:13:43 PM1/15/24
to
Hallo,
Am 15.01.24 um 20:22 schrieb Jörg Tewes:
offenbar liegt hier ein Missverständnis vor: ich wollte die zugelassenen
IPs der Gegenstellen in die Liste erlaubter IP-Adressen (Internet →
Filter → Listen → Erlaubte IP-Adressen: bearbeiten) eintragen.
So langsam dämmert mir, wie das vielleicht gemeint sein könnte: wenn ich
in Erlaubte Internetseiten: bearbeiten Domains eingetragen habe, Ziele
in diesen Domains aber mit ihrer IP statt mit Namen angesprochen werden,
werden sie in der Liste aufgeführt, und dann könnte ich sie markieren.
Oder so ähnlich. Da aber die Geräte, die miteinander reden sollen, nicht
über (Domain-) Namen aufgelöst werden, sondern bereits ausschließlich
per IP-Adresse angesprochen werden, tauchen sie in dieser Liste nicht
auf, können also auch nicht markiert werden. Ist das so in etwa richtig?
--
Gruß
Alex
Am 15.01.24 um 20:22 schrieb Jörg Tewes:
IPs der Gegenstellen in die Liste erlaubter IP-Adressen (Internet →
Filter → Listen → Erlaubte IP-Adressen: bearbeiten) eintragen.
So langsam dämmert mir, wie das vielleicht gemeint sein könnte: wenn ich
in Erlaubte Internetseiten: bearbeiten Domains eingetragen habe, Ziele
in diesen Domains aber mit ihrer IP statt mit Namen angesprochen werden,
werden sie in der Liste aufgeführt, und dann könnte ich sie markieren.
Oder so ähnlich. Da aber die Geräte, die miteinander reden sollen, nicht
über (Domain-) Namen aufgelöst werden, sondern bereits ausschließlich
per IP-Adresse angesprochen werden, tauchen sie in dieser Liste nicht
auf, können also auch nicht markiert werden. Ist das so in etwa richtig?
--
Gruß
Alex
Alexander Goetzenstein
Jan 15, 2024, 4:26:26 PM1/15/24
to
Hallo,
Am 15.01.24 um 17:56 schrieb Anton Berg:
Spiel ist das auch nicht, auch nichts wirklich hochtrabendes, sondern
etwas, was Einem in jedem halbwegs ernsthaften Computermagazin geraten
wird: Datensicherung nach 3-2-1-Regel bei Abschottung der
Datensicherungsgeräte gegenüber dem Internet. Man möge mich korrigieren,
aber mir kommt es so vor, als wenn ich mit gröberen
Implementierungsfehlern kämpfe. Intranet ist Intranet und Internet ist
Internet -das scheint hier fälschlicherweise in einen Topf geworfen
worden zu sein. Damit muss ich nun irgendwie zurechtkommen und eine
Konfiguration finden, mit der ich das halbwegs hinbekomme.
BTW: Ich habe auch schon versucht, die integrierte Firewall der NASse zu
nutzen, aber da sind die (offenbar gewollten) Fehler noch größer:
nachdem ich alles so zugekleistert hatte, dass ich nur noch mit einem PC
zur Verwaltung dran kam und die Geräte nur noch sich selbst und die FB
für NTP sehen dürfte, meldeten die NASse neue Betriebssystemversionen
und konnten diese auch herunterladen und installieren sowie (getrennt
davon) Apps aktualisieren. Und genau das ist, was unter keinen Umständen
passieren darf. Offenbar setzt diese Firewall heimlich und nicht
änderbar Erlaubnisse zum Nachhausetelefonieren -eigentlich unfassbar. Es
geht also nicht anders als den Verkehr von außerhalb der NASse zu sperren.
--
Gruß
Alex
Am 15.01.24 um 17:56 schrieb Anton Berg:
etwas, was Einem in jedem halbwegs ernsthaften Computermagazin geraten
wird: Datensicherung nach 3-2-1-Regel bei Abschottung der
Datensicherungsgeräte gegenüber dem Internet. Man möge mich korrigieren,
aber mir kommt es so vor, als wenn ich mit gröberen
Implementierungsfehlern kämpfe. Intranet ist Intranet und Internet ist
Internet -das scheint hier fälschlicherweise in einen Topf geworfen
worden zu sein. Damit muss ich nun irgendwie zurechtkommen und eine
Konfiguration finden, mit der ich das halbwegs hinbekomme.
BTW: Ich habe auch schon versucht, die integrierte Firewall der NASse zu
nutzen, aber da sind die (offenbar gewollten) Fehler noch größer:
nachdem ich alles so zugekleistert hatte, dass ich nur noch mit einem PC
zur Verwaltung dran kam und die Geräte nur noch sich selbst und die FB
für NTP sehen dürfte, meldeten die NASse neue Betriebssystemversionen
und konnten diese auch herunterladen und installieren sowie (getrennt
davon) Apps aktualisieren. Und genau das ist, was unter keinen Umständen
passieren darf. Offenbar setzt diese Firewall heimlich und nicht
änderbar Erlaubnisse zum Nachhausetelefonieren -eigentlich unfassbar. Es
geht also nicht anders als den Verkehr von außerhalb der NASse zu sperren.
--
Gruß
Alex
Marco Moock
Jan 16, 2024, 12:19:46 AM1/16/24
to
Am 15.01.2024 um 22:26:24 Uhr schrieb Alexander Goetzenstein:
> Intranet ist Intranet und Internet ist Internet -das scheint hier
> fälschlicherweise in einen Topf geworfen worden zu sein. Damit muss
> ich nun irgendwie zurechtkommen und eine Konfiguration finden, mit
> der ich das halbwegs hinbekomme.
In den wenigsten Netzen kann internes Netz und Internet gut getrennt
> Intranet ist Intranet und Internet ist Internet -das scheint hier
> fälschlicherweise in einen Topf geworfen worden zu sein. Damit muss
> ich nun irgendwie zurechtkommen und eine Konfiguration finden, mit
> der ich das halbwegs hinbekomme.
werden.
Updates sind da nur eine der nervigen Dauerbaustellen.
> BTW: Ich habe auch schon versucht, die integrierte Firewall der NASse
> zu nutzen, aber da sind die (offenbar gewollten) Fehler noch größer:
> nachdem ich alles so zugekleistert hatte, dass ich nur noch mit einem
> PC zur Verwaltung dran kam und die Geräte nur noch sich selbst und
> die FB für NTP sehen dürfte, meldeten die NASse neue
> Betriebssystemversionen und konnten diese auch herunterladen und
> installieren sowie (getrennt davon) Apps aktualisieren. Und genau das
> ist, was unter keinen Umständen passieren darf. Offenbar setzt diese
> Firewall heimlich und nicht änderbar Erlaubnisse zum
> Nachhausetelefonieren -eigentlich unfassbar. Es geht also nicht
> anders als den Verkehr von außerhalb der NASse zu sperren.
Updates sollte man trotzdem machen, Sicherheitslücken und Bugs
existieren.
Alexander Goetzenstein
Jan 16, 2024, 2:13:48 AM1/16/24
to
Hallo,
Am 16.01.24 um 06:19 schrieb Marco Moock:
> Updates sind da nur eine der nervigen Dauerbaustellen.
Das ist nicht nervig, ich halte die Möglichkeit (nicht korrekte Updates
selbst) für hochgefährlich.
> Von solchen Geräten würde ich mich trennen.
In zehn Jahren vielleicht -wenn ich dann welche finde, von denen ich das
vorher weiß.
> Updates sollte man trotzdem machen, Sicherheitslücken und Bugs
> existieren.
Wenn die Umgebung sicher abgeschottet ist, ist das durchaus verzichtbar.
Und wenn ich ein Update machen will, kann ich es offline einspielen oder
eigens dafür kurz die Verbindung herstellen. Aber ich muss sie für einen
sicheren Betrieb verlässlich kappen können.
--
Gruß
Alex
Am 16.01.24 um 06:19 schrieb Marco Moock:
> In den wenigsten Netzen kann internes Netz und Internet gut getrennt
> werden.
warum dieses?
> werden.
> Updates sind da nur eine der nervigen Dauerbaustellen.
selbst) für hochgefährlich.
> Von solchen Geräten würde ich mich trennen.
vorher weiß.
> Updates sollte man trotzdem machen, Sicherheitslücken und Bugs
> existieren.
Und wenn ich ein Update machen will, kann ich es offline einspielen oder
eigens dafür kurz die Verbindung herstellen. Aber ich muss sie für einen
sicheren Betrieb verlässlich kappen können.
--
Gruß
Alex
Marco Moock
Jan 16, 2024, 2:21:01 AM1/16/24
to
Am 16.01.2024 um 08:13:45 Uhr schrieb Alexander Goetzenstein:
> Am 16.01.24 um 06:19 schrieb Marco Moock:
> > In den wenigsten Netzen kann internes Netz und Internet gut getrennt
> > werden.
>
> warum dieses?
Weil die meisten Systeme in bestimmten Fällen mit der Außenwelt
> Am 16.01.24 um 06:19 schrieb Marco Moock:
> > In den wenigsten Netzen kann internes Netz und Internet gut getrennt
> > werden.
>
> warum dieses?
kommunizieren müssen.
> > Updates sind da nur eine der nervigen Dauerbaustellen.
>
> Das ist nicht nervig, ich halte die Möglichkeit (nicht korrekte
> Updates selbst) für hochgefährlich.
kann.
Die Erfahrung zeigt, dass das ne schlechte Idee ist, weil $irgendwann
ein gehackter Rechner in einem solchen Netz unterwegs sein wird und
sich sowas dann wunderbar ausbreiten kann.
> > Von solchen Geräten würde ich mich trennen.
>
> In zehn Jahren vielleicht -wenn ich dann welche finde, von denen ich
> das vorher weiß.
> > Updates sollte man trotzdem machen, Sicherheitslücken und Bugs
> > existieren.
>
> Wenn die Umgebung sicher abgeschottet ist, ist das durchaus
> verzichtbar.
In welchen Szenarien funktioniert sowas in der Praxis?
Es wird der Tag kommen, an dem in dieses abgeschottete Netz Daten rein-
oder rausmüssen und ab da hast du diese Abschotttung nicht mehr.
Jetzt kommt einer mit seinem verseuchten Windows-Laptop und die Kacke
ist am Dampfen. Passiert öfter mal.
> Und wenn ich ein Update machen will, kann ich es offline
> einspielen
> oder eigens dafür kurz die Verbindung herstellen.
> Aber ich muss sie für einen sicheren Betrieb verlässlich kappen können.
solche Software gar nicht einsetzen.
Anton Berg
Jan 16, 2024, 12:46:36 PM1/16/24
to
Am 15.01.2024 um 22:26 schrieb Alexander Goetzenstein:
> Spiel ist das auch nicht, auch nichts wirklich hochtrabendes, sondern
> etwas, was Einem in jedem halbwegs ernsthaften Computermagazin geraten
> wird: Datensicherung nach 3-2-1-Regel bei Abschottung der
> Datensicherungsgeräte gegenüber dem Internet.
Richtig - leider folgen auf die schlauen Ideen oft keine konkreten
> Spiel ist das auch nicht, auch nichts wirklich hochtrabendes, sondern
> etwas, was Einem in jedem halbwegs ernsthaften Computermagazin geraten
> wird: Datensicherung nach 3-2-1-Regel bei Abschottung der
> Datensicherungsgeräte gegenüber dem Internet.
Hilfen zur Umsetzung. Manches ist auch nicht trivial, manches schon.
Simples Beispiel: wenn ich Daten vom PC sichern will, z.B. auf ein
NAS, kann ich entweder die Daten vom PC dorthin schieben, brauche
dort also Schreibrechte. Eine wildgewordene oder bösartige Software
hat die auch - und kann meine Sicherung damit schreddern.
Alternative: ich lasse das Sicherungsgerät die Daten vom PC holen,
nutze dazu einen User, der keinerlei Rechte auf der NAS hat,
schon habe ich die gleiche Aufgabe erheblich sicherer gelöst,
da nichts und niemand vom PC aus an die NAS-Daten kommt.
(Ja, fürs ggf. erforderliche Recovery kann ich analog vorgehen.)
Das hat jetzt nur noch am Rande mit der Ursprungsfrage zu tun...
zeigt aber, wie wichtig strukturiertes Überlegen ist. Dann erkennt
man z.B. auch, dass es oft wenig bringt, einem Gerät zu sagen:
"Das darfst du nicht" - wenn das nächste Update das aushebelt.
Sage ich aber Gerät A (Router, Switch...) was Gerät B (z.B. NAS)
darf und was nicht, kann sich die NAS auf den Kopf stellen und mit
den Platten wackeln, aber sie wird z.B. nicht heimtelefonieren
können. :-)
--
Gruß Anton
Alexander Goetzenstein
Jan 16, 2024, 4:57:30 PM1/16/24
to
Hallo,
Am 16.01.24 um 18:46 schrieb Anton Berg:
Frage zu tun hat: nächtens beendet mein Server die Dienste für die
Clients, schließt alle Netzwerkinterfaces und startet eines, das
exklusiv nur per Kabel (ohne Switch oder sonstiges dazwischen) mit dem
NAS#1 verbunden ist. Über wol fährt dieses NAS#1 dann hoch, über sshfs
und ecryptfs wird die Datensicherung darauf geschrieben, das NAS#1
heruntergefahren, die Verbindung dorthin beendet. Anschließend werden
die Netzwerkinterfaces zum LAN wieder hochgefahren und die Dienste
gestartet. Zur Datensicherungszeit ist es also unmöglich, dass jemand
von außen irgendeinen Einfluss darauf nimmt. Viel sichereres ist mir bis
dahin nicht eingefallen. Vielleicht noch, die Datensicherung in einer VM
von einer DVD-ROM zu starten, um auszuschließen, dass jemand das
Server-OS infiltriert hat und so bereits das erste Backup manipuliert
-schaunmermal.
Mein Ansinnen ist nun, dieses NAS#1 auf das NAS#2 an einem entfernten
Standort (also außer Haus) regelmäßig zu spiegeln. Diesen Vorgang möchte
ich vergleichbar absichern, damit es ebenso unmöglich ist, das Backup zu
stören (verschlüsseln, verfälschen, löschen...). Dazu werden NAS#1 und
NAS#2 gestartet, verbinden sich miteinander, übertragen die Daten, und
fahren wieder herunter. Und diese Verbindung will ich sicher isolieren,
so dass niemand, auch nicht $böserHacker, der viel, viel schlauer ist
als ich, dazwischenfunken kann. Ein möglicher Weg wäre bspw. die
Verbindung zum Hersteller zu kapern, die für Updates vorgesehen ist und
offenbar durch die in den NASen eingebaute Firewall nicht unterbunden
werden kann. Am einfachsten und sichersten erscheint mir daher, die
Verbindung ins Internet komplett zu sperren -was aber nicht möglich ist,
wenn ein VPN die Geräte verbinden soll. Irgendwie ist das ein Bruch in
der Logik, finde ich.
> Das hat jetzt nur noch am Rande mit der Ursprungsfrage zu tun...
> zeigt aber, wie wichtig strukturiertes Überlegen ist. Dann erkennt
> man z.B. auch, dass es oft wenig bringt, einem Gerät zu sagen:
> "Das darfst du nicht" - wenn das nächste Update das aushebelt.
Nicht nur das: es besteht ja auch noch die Möglichkeit, dass ein überaus
gewitzter $böserHacker ein manipuliertes "Systemupdate" unterschiebt. Da
ein solches Update aber angesichts der Abwesenheit relevanter Fehler und
der Abschottung der Umgebung nicht notwendig wäre, könnte -und sollte-
ich auf Updates verzichten und brauche gar keinen Kontakt zum Hersteller
der NASen.
Ich will mir nicht irgendwann den Spruch anhören müssen "kein Backup -
kein Mitleid!" -auf die Datensicherung muss ich mich jederzeit verlassen
können.
> Sage ich aber Gerät A (Router, Switch...) was Gerät B (z.B. NAS)
> darf und was nicht, kann sich die NAS auf den Kopf stellen und mit
> den Platten wackeln, aber sie wird z.B. nicht heimtelefonieren
> können. :-)
Das kommt noch hinzu: ich kann kaum bis gar nicht kontrollieren, was da
alles über den großen Teich gefunkt wird. Da die interne NAS-Firewall
das nicht zuverlässig blockt, wie mir ein Update trotz restriktivster
Einstellung bewies, muss das von außen geschehen. Und dafür sehe ich in
erster Linie die Router -also die FRITZ!Boxen- in der Pflicht. Ich will
mir nicht extra zig Geld, Platz, Mühe und Strom verbrauchende
Gerätschaften anschaffen und betreiben müssen, nur weil die FRITZ!Box
ihre Aufgabe in meinen Augen suboptimal versieht.
So langsam komme ich zu der Einsicht, dass da am FRITZ!OS etwas getan
werden muss. Mal sehen, ob AVM sich zugänglich zeigt. Ansonsten finde
ich die Dinger ja schon klasse.
--
Gruß
Alex
Am 16.01.24 um 18:46 schrieb Anton Berg:
> Simples Beispiel: wenn ich Daten vom PC sichern will, z.B. auf ein
> NAS, kann ich entweder die Daten vom PC dorthin schieben, brauche
> dort also Schreibrechte. Eine wildgewordene oder bösartige Software
> hat die auch - und kann meine Sicherung damit schreddern.
>
> Alternative: ich lasse das Sicherungsgerät die Daten vom PC holen,
> nutze dazu einen User, der keinerlei Rechte auf der NAS hat,
> schon habe ich die gleiche Aufgabe erheblich sicherer gelöst,
> da nichts und niemand vom PC aus an die NAS-Daten kommt.
> (Ja, fürs ggf. erforderliche Recovery kann ich analog vorgehen.)
eigentlich ein kleiner Exkurs, der eigentlich nicht direkt mit meiner
> NAS, kann ich entweder die Daten vom PC dorthin schieben, brauche
> dort also Schreibrechte. Eine wildgewordene oder bösartige Software
> hat die auch - und kann meine Sicherung damit schreddern.
>
> Alternative: ich lasse das Sicherungsgerät die Daten vom PC holen,
> nutze dazu einen User, der keinerlei Rechte auf der NAS hat,
> schon habe ich die gleiche Aufgabe erheblich sicherer gelöst,
> da nichts und niemand vom PC aus an die NAS-Daten kommt.
> (Ja, fürs ggf. erforderliche Recovery kann ich analog vorgehen.)
Frage zu tun hat: nächtens beendet mein Server die Dienste für die
Clients, schließt alle Netzwerkinterfaces und startet eines, das
exklusiv nur per Kabel (ohne Switch oder sonstiges dazwischen) mit dem
NAS#1 verbunden ist. Über wol fährt dieses NAS#1 dann hoch, über sshfs
und ecryptfs wird die Datensicherung darauf geschrieben, das NAS#1
heruntergefahren, die Verbindung dorthin beendet. Anschließend werden
die Netzwerkinterfaces zum LAN wieder hochgefahren und die Dienste
gestartet. Zur Datensicherungszeit ist es also unmöglich, dass jemand
von außen irgendeinen Einfluss darauf nimmt. Viel sichereres ist mir bis
dahin nicht eingefallen. Vielleicht noch, die Datensicherung in einer VM
von einer DVD-ROM zu starten, um auszuschließen, dass jemand das
Server-OS infiltriert hat und so bereits das erste Backup manipuliert
-schaunmermal.
Mein Ansinnen ist nun, dieses NAS#1 auf das NAS#2 an einem entfernten
Standort (also außer Haus) regelmäßig zu spiegeln. Diesen Vorgang möchte
ich vergleichbar absichern, damit es ebenso unmöglich ist, das Backup zu
stören (verschlüsseln, verfälschen, löschen...). Dazu werden NAS#1 und
NAS#2 gestartet, verbinden sich miteinander, übertragen die Daten, und
fahren wieder herunter. Und diese Verbindung will ich sicher isolieren,
so dass niemand, auch nicht $böserHacker, der viel, viel schlauer ist
als ich, dazwischenfunken kann. Ein möglicher Weg wäre bspw. die
Verbindung zum Hersteller zu kapern, die für Updates vorgesehen ist und
offenbar durch die in den NASen eingebaute Firewall nicht unterbunden
werden kann. Am einfachsten und sichersten erscheint mir daher, die
Verbindung ins Internet komplett zu sperren -was aber nicht möglich ist,
wenn ein VPN die Geräte verbinden soll. Irgendwie ist das ein Bruch in
der Logik, finde ich.
> Das hat jetzt nur noch am Rande mit der Ursprungsfrage zu tun...
> zeigt aber, wie wichtig strukturiertes Überlegen ist. Dann erkennt
> man z.B. auch, dass es oft wenig bringt, einem Gerät zu sagen:
> "Das darfst du nicht" - wenn das nächste Update das aushebelt.
gewitzter $böserHacker ein manipuliertes "Systemupdate" unterschiebt. Da
ein solches Update aber angesichts der Abwesenheit relevanter Fehler und
der Abschottung der Umgebung nicht notwendig wäre, könnte -und sollte-
ich auf Updates verzichten und brauche gar keinen Kontakt zum Hersteller
der NASen.
Ich will mir nicht irgendwann den Spruch anhören müssen "kein Backup -
kein Mitleid!" -auf die Datensicherung muss ich mich jederzeit verlassen
können.
> Sage ich aber Gerät A (Router, Switch...) was Gerät B (z.B. NAS)
> darf und was nicht, kann sich die NAS auf den Kopf stellen und mit
> den Platten wackeln, aber sie wird z.B. nicht heimtelefonieren
> können. :-)
alles über den großen Teich gefunkt wird. Da die interne NAS-Firewall
das nicht zuverlässig blockt, wie mir ein Update trotz restriktivster
Einstellung bewies, muss das von außen geschehen. Und dafür sehe ich in
erster Linie die Router -also die FRITZ!Boxen- in der Pflicht. Ich will
mir nicht extra zig Geld, Platz, Mühe und Strom verbrauchende
Gerätschaften anschaffen und betreiben müssen, nur weil die FRITZ!Box
ihre Aufgabe in meinen Augen suboptimal versieht.
So langsam komme ich zu der Einsicht, dass da am FRITZ!OS etwas getan
werden muss. Mal sehen, ob AVM sich zugänglich zeigt. Ansonsten finde
ich die Dinger ja schon klasse.
--
Gruß
Alex
Anton Berg
Jan 17, 2024, 12:50:31 AM1/17/24
to
Am 16.01.2024 um 22:57 schrieb Alexander Goetzenstein:
> eigentlich ein kleiner Exkurs, der eigentlich nicht direkt mit meiner
> Frage zu tun hat:
> ...
> eigentlich ein kleiner Exkurs, der eigentlich nicht direkt mit meiner
> Frage zu tun hat:
stimmt, war von mir auch als Gedankengang gemeint, dass man leicht mal
was übersehen könnte, wenn man in einem Problem feststeckt.
Bei 2 NASen und dem, was du schreibst, habe ich allerdings schon den
Eindruck, dass du das ganz gut durchdacht hast und umsetzen kannst.
> Das kommt noch hinzu: ich kann kaum bis gar nicht kontrollieren, was da
> alles über den großen Teich gefunkt wird. Da die interne NAS-Firewall
> das nicht zuverlässig blockt, wie mir ein Update trotz restriktivster
> Einstellung bewies, muss das von außen geschehen.
> Und dafür sehe ich in
> erster Linie die Router -also die FRITZ!Boxen- in der Pflicht.
Produkte für die typische Kunden-Zielgruppe betrachtet. Und genau
da habe ich so meine Zweifel...
> Ich will mir nicht extra zig Geld, Platz, Mühe und Strom verbrauchende
> Gerätschaften anschaffen und betreiben müssen, nur weil die FRITZ!Box
> ihre Aufgabe in meinen Augen suboptimal versieht.
ganz gut zielführend... ja, Mühe zum Einarbeiten braucht es sicher,
auch ein paar Watt Strom, bei Platz und Geld kann ich dich beruhigen:
brauchbare Geräte gibt es gebraucht oft für mittlere zweistellige
Beträge, APU (Alix) und Securepoint Black Dwarf seien hier mal nur
als Beispiel genannt. Und Platz brauchen die auch nicht viel.
Letztlich bringt es viel mehr Möglichkeiten, evtl. (je nach
deinem aktuellen Wissen) einiges an Verständnisgewinn und wenn man
Netzwerk spannend findet, kann es sogar Spaß machen.
> So langsam komme ich zu der Einsicht, dass da am FRITZ!OS etwas getan
> werden muss. Mal sehen, ob AVM sich zugänglich zeigt. Ansonsten finde
> ich die Dinger ja schon klasse.
wirklich sehr gut zu gebrauchen.
--
Gruß Anton
Marco Moock
Jan 17, 2024, 3:23:23 AM1/17/24
to
Ein VPN-Tunnel ist nix anderes als ein spezielles Interface.
I.d.R. werden da IP-Adressen festgelegt, es wären aber auch ganz andere
Protokolle denkbar.
Wenn jetzt eine Standardroute in dieses Interface gesetzt wird,
passiert genau das, was du nicht willst.
Abhilfe: Dafür sorgen, dass diese Route nicht gesetzt wird.
Wenn die FB das nicht unterstützt, ist das für deinen Anwendungsfall
einfach das falsche Gerät.
Nimm einen Linux-Rechner dafür oder Cisco, da hast du diese Optionen.
> > Das hat jetzt nur noch am Rande mit der Ursprungsfrage zu tun...
> > zeigt aber, wie wichtig strukturiertes Überlegen ist. Dann erkennt
> > man z.B. auch, dass es oft wenig bringt, einem Gerät zu sagen:
> > "Das darfst du nicht" - wenn das nächste Update das aushebelt.
>
> Nicht nur das: es besteht ja auch noch die Möglichkeit, dass ein
> überaus gewitzter $böserHacker ein manipuliertes "Systemupdate"
> unterschiebt. Da ein solches Update aber angesichts der Abwesenheit
> relevanter Fehler und der Abschottung der Umgebung nicht notwendig
> wäre, könnte -und sollte- ich auf Updates verzichten und brauche gar
> keinen Kontakt zum Hersteller der NASen.
Admins sind damit aber schon heftig auf die Schnauze gefallen, weil die
früher abgeschotteten Systeme dann doch nicht mehr abgeschottet waren.
> Ich will mir nicht irgendwann den Spruch anhören müssen "kein Backup -
> kein Mitleid!" -auf die Datensicherung muss ich mich jederzeit
> verlassen können.
Software, die dann nach nem Jahre kein Update mehr bekommt. Auch im
Hinblick auf Jahr-2038-Fehler, Pufferüberläufe & Co.
> > Sage ich aber Gerät A (Router, Switch...) was Gerät B (z.B. NAS)
> > darf und was nicht, kann sich die NAS auf den Kopf stellen und mit
> > den Platten wackeln, aber sie wird z.B. nicht heimtelefonieren
> > können. :-)
>
> Das kommt noch hinzu: ich kann kaum bis gar nicht kontrollieren, was
> da alles über den großen Teich gefunkt wird. Da die interne
> NAS-Firewall das nicht zuverlässig blockt, wie mir ein Update trotz
> restriktivster Einstellung bewies, muss das von außen geschehen. Und
> dafür sehe ich in erster Linie die Router -also die FRITZ!Boxen- in
> der Pflicht.
Geräte, gibt es gebraucht billig, da hast du solche Möglichkeiten.
> Ich will mir nicht extra zig Geld, Platz, Mühe und Strom
> verbrauchende Gerätschaften anschaffen und betreiben müssen, nur weil
> die FRITZ!Box ihre Aufgabe in meinen Augen suboptimal versieht.
diesen Bedarf nicht, die kümmern sich i.d.R. nicht darum, dass Geräte
nach Hause telefonieren.
Auch Routing und Firewall sind da Themen, die über "Das Kind soll ab 23
Uhr nicht mehr ins Internet" selten hinausgehen.
> So langsam komme ich zu der Einsicht, dass da am FRITZ!OS etwas getan
> werden muss.
Schaffe dir die für deinen Anwendungsfall passenden Geräte an.
Axel Berger
Jan 17, 2024, 4:07:00 AM1/17/24
to
Marco Moock wrote:
> Die FB ist als Consumer-Gerät gedacht. Normaler Nutzer der FB haben
> diesen Bedarf nicht, die kümmern sich i.d.R. nicht darum, dass Geräte
> nach Hause telefonieren.
Sie hat genau dafür eine Ein-Klick-Lösung. Soweit erkennbar
funktionmiert die auch zuverlässig. Alles, was das weite Netz nicht
braucht, bekommt die hier verpaßt, selbst kleine ESphomeplatinen, die
ich selbst programmiert habe und die das m.E. ohnehin nicht können.
Sachen wie der Drucker bekommen die Sperre sowieso. Beim Raspberry mit
Home Assistant traue ich mich nicht, keine Ahnung was in dessen Linux
dann kaputtgeht.
--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --
> Die FB ist als Consumer-Gerät gedacht. Normaler Nutzer der FB haben
> diesen Bedarf nicht, die kümmern sich i.d.R. nicht darum, dass Geräte
> nach Hause telefonieren.
Sie hat genau dafür eine Ein-Klick-Lösung. Soweit erkennbar
funktionmiert die auch zuverlässig. Alles, was das weite Netz nicht
braucht, bekommt die hier verpaßt, selbst kleine ESphomeplatinen, die
ich selbst programmiert habe und die das m.E. ohnehin nicht können.
Sachen wie der Drucker bekommen die Sperre sowieso. Beim Raspberry mit
Home Assistant traue ich mich nicht, keine Ahnung was in dessen Linux
dann kaputtgeht.
--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --
Alexander Goetzenstein
Jan 18, 2024, 10:56:36 AM1/18/24
to
Hallo,
Am 17.01.24 um 10:06 schrieb Axel Berger:
--
Gruß
Alex
Am 17.01.24 um 10:06 schrieb Axel Berger:
> Marco Moock wrote:
>> Die FB ist als Consumer-Gerät gedacht. Normaler Nutzer der FB haben
>> diesen Bedarf nicht, die kümmern sich i.d.R. nicht darum, dass Geräte
>> nach Hause telefonieren.
>
> Sie hat genau dafür eine Ein-Klick-Lösung. Soweit erkennbar
> funktionmiert die auch zuverlässig.
was genau meinst Du?
>> Die FB ist als Consumer-Gerät gedacht. Normaler Nutzer der FB haben
>> diesen Bedarf nicht, die kümmern sich i.d.R. nicht darum, dass Geräte
>> nach Hause telefonieren.
>
> Sie hat genau dafür eine Ein-Klick-Lösung. Soweit erkennbar
> funktionmiert die auch zuverlässig.
--
Gruß
Alex
Axel Berger
Jan 18, 2024, 12:39:24 PM1/18/24
to
Alexander Goetzenstein wrote:
> was genau meinst Du?
Am bequemsten erreichbar als:
Internet --> Filter --> Parental Controls
Dort die zweite Spalte, Block resp. Unblock.
Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
verbinden.
> was genau meinst Du?
Am bequemsten erreichbar als:
Internet --> Filter --> Parental Controls
Dort die zweite Spalte, Block resp. Unblock.
Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
verbinden.
Alexander Goetzenstein
Jan 18, 2024, 3:03:45 PM1/18/24
to
Hallo,
Am 18.01.24 um 18:39 schrieb Axel Berger:
das VPN nicht mehr.
--
Gruß
Alex
Am 18.01.24 um 18:39 schrieb Axel Berger:
> Alexander Goetzenstein wrote:
>> was genau meinst Du?
>
> Am bequemsten erreichbar als:
>
> Internet --> Filter --> Parental Controls
>
> Dort die zweite Spalte, Block resp. Unblock.
>
> Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
> Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
> den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
> verbinden.
achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
>> was genau meinst Du?
>
> Am bequemsten erreichbar als:
>
> Internet --> Filter --> Parental Controls
>
> Dort die zweite Spalte, Block resp. Unblock.
>
> Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
> Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
> den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
> verbinden.
das VPN nicht mehr.
--
Gruß
Alex
Axel Berger
Jan 18, 2024, 3:53:43 PM1/18/24
to
Alexander Goetzenstein wrote:
> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
> das VPN nicht mehr.
Tja, so ist das Leben. Ich will ein Schloß, das kein Einbrecher jemals
> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
> das VPN nicht mehr.
öffnen kann, aber der Schlüsseldienst, wenn ich ihn mal brauche, muß es
in fünf Minuten schadenfrei aufbekommen und teuer darf das auch nicht
sein.
Auf ist auf und zu ist zu. Alles andere hat den Wert eines Schildes
"Eingang nur für Befugte."
Michael Schwingen
Jan 18, 2024, 4:41:15 PM1/18/24
to
On 2024-01-18, Axel Berger <Sp...@Berger-Odenthal.De> wrote:
> Alexander Goetzenstein wrote:
>> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
>> das VPN nicht mehr.
>
> Tja, so ist das Leben. Ich will ein Schloß, das kein Einbrecher jemals
> öffnen kann, aber der Schlüsseldienst, wenn ich ihn mal brauche, muß es
> in fünf Minuten schadenfrei aufbekommen und teuer darf das auch nicht
> sein.
Nun ja - das ist halt der Unterschied zwischen einem Consumer-Router mit
> Alexander Goetzenstein wrote:
>> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
>> das VPN nicht mehr.
>
> Tja, so ist das Leben. Ich will ein Schloß, das kein Einbrecher jemals
> öffnen kann, aber der Schlüsseldienst, wenn ich ihn mal brauche, muß es
> in fünf Minuten schadenfrei aufbekommen und teuer darf das auch nicht
> sein.
einfacher Bedienung und einer professionellen Lösung ;-)
Der Wunsch ist verständlich, und es gibt reichlich Router, die das können -
das günstigste wäre irgendwas OpenWRT-basiertes.
Ich kann aber auch verstehen, daß AVM diese Komplexität ihrer Zielgruppe
nicht zumuten möchte. AVM hat sich halt grob auf "ein LAN, ein Gastnetz,
minimale Netzwerkkopplung per VPN" als sinnvolle Menge für ihre Kunden
festgelegt.
> Auf ist auf und zu ist zu. Alles andere hat den Wert eines Schildes
> "Eingang nur für Befugte."
festlegen können, wer mit wem kommunizieren kann, incl. VPN. Ein globaler
Schalter "an" oder "aus" pro Station reicht da nicht.
Ich habe hier:
- Hauptnetz für die Rechner/Server. Auch da gibt es aber Geräte (wie mein
HP-Drucker), die keinen Internet-Zugang haben.
- IoT-Netz (incl. WLAN) für Shelly & Co. Darf mit meinem MQTT-Server und
meinem NTP-Server reden, aber nicht ins Internet. Meine Rechner dürfen
aber die Weboberfläche der IoT-Geräte aufrufen.
- WLAN-Gastnetz. Darf ins Internet, aber sonst nirgendwohin.
- AV-Netz für Fernseher/Receiver. Darf mit meinem Medienserver reden, aber
nicht ins Internet
- ein VPN für Fernwartung. Da dürfen nur bestimmte Rechner an beiden Enden
miteinander reden, sonst nichts.
Das ist auch mit jedem halbwegs gescheiten Paketfilter problemlos
abzubilden, sprengt aber den Rahmen, den eine einfach bedienbare Oberfläche
die die Fritzbox bietet.
Michael Schwingen
Jan 18, 2024, 4:47:21 PM1/18/24
to
On 2024-01-18, Alexander Goetzenstein <alexander_g...@web.de> wrote:
>> Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
>> Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
>> den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
>> verbinden.
>
> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
> das VPN nicht mehr.
Eine Idee:
>> Diese Geräte können keine Verbindung aus dem LAN heraus mehr aufnehmen.
>> Ich traue AVM zu, daß das auch zuverlässig ist. Das ist hier gesetzt für
>> den Drucker und Elmente der Home Automation, die sich per LAN oder WLAN
>> verbinden.
>
> achso, das. Ja, richtig, das funktioniert -aber dann funktioniert auch
> das VPN nicht mehr.
Konfigurier' die NAS-Boxen nicht auf DHCP, sondern auf feste Adressen. Dann
entweder kein Defaultgateway eintragen oder eine ungültige (nicht benutzte)
Adresse im LAN. Optional dito für den DNS-Server, falls nicht gebraucht.
Für die Adressen hinter dem VPN dann jeweils statische Routen auf den NAS.
Voila: kein Internetzugriff. Hängt halt an der Konfiguration des NAS und
nicht wie eigentlich gewünscht am zentralen Paketfilter, aber daß das NAS
nach einem Update die korrekte Adresse des Default-Gateways rät und
einträgt, ist eher unwahrscheinlich.
Wenn das bei AVM geht, könnte man den DHCP-Server zusätzlich noch so
einstellen, daß das NAS explizit *keine* Adresse bekommt, wenn es aus
Versehen auf DHCP-Betrieb zurückfällt.
Axel Berger
Jan 19, 2024, 3:06:24 AM1/19/24
to
Michael Schwingen wrote:
> Nein. Wenn man mehrere Netzsegmente hat, will man natürlich einzeln
> festlegen können, wer mit wem kommunizieren kann, incl. VPN. Ein globaler
durch" ist einfach. Eine Kontrolle, die nur Befugte durchläßt, bietet
immer eine Möglichkeit, sich als genau dieser Befugte auzugeben. Das
kann sicher genug sein, aber nie so sicher wie der aus der Buchse
gezogene Stecker.
> mit jedem halbwegs gescheiten Paketfilter problemlos abzubilden,
Eben.
> Nein. Wenn man mehrere Netzsegmente hat, will man natürlich einzeln
> festlegen können, wer mit wem kommunizieren kann, incl. VPN. Ein globaler
> Schalter "an" oder "aus" pro Station reicht da nicht.
Dann wird man aber wieder angreifbar. Eine Betonmauer "hier kommt keiner
durch" ist einfach. Eine Kontrolle, die nur Befugte durchläßt, bietet
immer eine Möglichkeit, sich als genau dieser Befugte auzugeben. Das
kann sicher genug sein, aber nie so sicher wie der aus der Buchse
gezogene Stecker.
> mit jedem halbwegs gescheiten Paketfilter problemlos abzubilden,
Michael Schwingen
Jan 20, 2024, 4:15:39 AM1/20/24
to
On 2024-01-19, Axel Berger <Sp...@Berger-Odenthal.De> wrote:
>> Nein. Wenn man mehrere Netzsegmente hat, will man natürlich einzeln
>> festlegen können, wer mit wem kommunizieren kann, incl. VPN. Ein globaler
>> Schalter "an" oder "aus" pro Station reicht da nicht.
>
> Dann wird man aber wieder angreifbar. Eine Betonmauer "hier kommt keiner
> durch" ist einfach. Eine Kontrolle, die nur Befugte durchläßt, bietet
> immer eine Möglichkeit, sich als genau dieser Befugte auzugeben.
Tja. Wenn das Dein Ansatz ist, lautet die einzige Lösung "kein Netzwerk" -
>> Nein. Wenn man mehrere Netzsegmente hat, will man natürlich einzeln
>> festlegen können, wer mit wem kommunizieren kann, incl. VPN. Ein globaler
>> Schalter "an" oder "aus" pro Station reicht da nicht.
>
> Dann wird man aber wieder angreifbar. Eine Betonmauer "hier kommt keiner
> durch" ist einfach. Eine Kontrolle, die nur Befugte durchläßt, bietet
> immer eine Möglichkeit, sich als genau dieser Befugte auzugeben.
also das Backup per berittenem Boten zum anderen NAS bringen.
Die Lösung mit mehreren Sicherungsschichten, die hier gewünscht war (NAS nur
per VPN gekoppelt, sämtliche andere Kommunikation verboten) ist trotzdem
deutlich besser - da brauchst Du mehrere Fehler, um angreifbar zu sein:
- Paketfilter kaputt, so daß Zugriff aus/ins Internet möglich ist
- Sicherheitslücke im NAS, die das Teil überhaupt angreifbar macht
Axel Berger
Jan 20, 2024, 6:13:27 AM1/20/24
to
Michael Schwingen wrote:
> also das Backup per berittenem Boten zum anderen NAS bringen.
Genau. Genauer die Backupplatte vor der Überragung nach draußen von
> also das Backup per berittenem Boten zum anderen NAS bringen.
einem Gerät auf ein anderes umstecken. Wer das oft braucht, kann es mit
Relais automatisieren.
Thomas Hochstein
Jan 20, 2024, 12:30:03 PM1/20/24
to
Alexander Goetzenstein schrieb:
> nächtens beendet mein Server die Dienste für die
> Clients, schließt alle Netzwerkinterfaces und startet eines, das
> exklusiv nur per Kabel (ohne Switch oder sonstiges dazwischen) mit dem
> NAS#1 verbunden ist. Über wol fährt dieses NAS#1 dann hoch, über sshfs
> und ecryptfs wird die Datensicherung darauf geschrieben, das NAS#1
> heruntergefahren, die Verbindung dorthin beendet. Anschließend werden
> die Netzwerkinterfaces zum LAN wieder hochgefahren und die Dienste
> gestartet. Zur Datensicherungszeit ist es also unmöglich, dass jemand
> von außen irgendeinen Einfluss darauf nimmt.
Ich verstehe, ehrlich gesagt, den Sinn dahinter nicht, es sei denn, Du
hältst das NAS für inhärent unsicher. Ansonsten kann man sich den ganzen
Quatsch sparen und einfach das Backup laufen lassen. Gegen einen
Angreifer, der Kontrolle über den Server erlangt hat, hilft das eh nichts;
der kann dann dennoch auf das NAS zugreifen. (Ja, gut, es hilft gegen
gescriptete Lösungen, die dann das NAS vermutlich nicht - auf Anhieb -
finden.) Insgesamt finde ich die Lösung eher skurril: sie betreibt einen
erheblichen, im Durchschnitt nicht notwendigen Aufwand, ohne aber
tatsächlich Sicherheit gegen gezielte Angriffe zu bieten.
> nächtens beendet mein Server die Dienste für die
> Clients, schließt alle Netzwerkinterfaces und startet eines, das
> exklusiv nur per Kabel (ohne Switch oder sonstiges dazwischen) mit dem
> NAS#1 verbunden ist. Über wol fährt dieses NAS#1 dann hoch, über sshfs
> und ecryptfs wird die Datensicherung darauf geschrieben, das NAS#1
> heruntergefahren, die Verbindung dorthin beendet. Anschließend werden
> die Netzwerkinterfaces zum LAN wieder hochgefahren und die Dienste
> gestartet. Zur Datensicherungszeit ist es also unmöglich, dass jemand
> von außen irgendeinen Einfluss darauf nimmt.
hältst das NAS für inhärent unsicher. Ansonsten kann man sich den ganzen
Quatsch sparen und einfach das Backup laufen lassen. Gegen einen
Angreifer, der Kontrolle über den Server erlangt hat, hilft das eh nichts;
der kann dann dennoch auf das NAS zugreifen. (Ja, gut, es hilft gegen
gescriptete Lösungen, die dann das NAS vermutlich nicht - auf Anhieb -
finden.) Insgesamt finde ich die Lösung eher skurril: sie betreibt einen
erheblichen, im Durchschnitt nicht notwendigen Aufwand, ohne aber
tatsächlich Sicherheit gegen gezielte Angriffe zu bieten.
Alexander Goetzenstein
Jan 23, 2024, 9:08:43 AM1/23/24
to
Hallo,
Am 20.01.24 um 12:13 schrieb Axel Berger:
existierende Malware speziell für NASe, zum anderen durch die
Beobachtung, dass deren Firewall offenbar heimliche Lücken enthält.
> Ansonsten kann man sich den ganzen
> Quatsch sparen und einfach das Backup laufen lassen. Gegen einen
> Angreifer, der Kontrolle über den Server erlangt hat, hilft das eh nichts;
Zum einen ist der Server ohne Zugang von und nach außen (geprüft), zum
anderen ist er zur Zeit der Datensicherung komplett offline. Dennoch
könnte z.B. über die Clients Schaden an den Daten entstehen, der durch
die Datensicherung aufgefangen werden soll. Folglich ist die Sicherheit
und Verlässlichkeit der Datensicherung wichtig.
> der kann dann dennoch auf das NAS zugreifen.
Nicht direkt, und dann ist er auch noch offline.
> (Ja, gut, es hilft gegen
> gescriptete Lösungen, die dann das NAS vermutlich nicht - auf Anhieb -
> finden.)
Einen anderen Weg als gescriptete Angriffe sehe ich nicht -jedenfalls
solange die NASe selbst nicht von außen erreichbar und damit angreifbar
sind. Und da sind wir jetzt endlich wieder beim Thema: die NASe müssen
miteinander verbunden sein, dürfen jedoch keinesfalls mit dem Internet
eine Verbindung aufnehmen können.
> Insgesamt finde ich die Lösung eher skurril: sie betreibt einen
> erheblichen, im Durchschnitt nicht notwendigen Aufwand, ohne aber
> tatsächlich Sicherheit gegen gezielte Angriffe zu bieten.
Sicherlich ist es ein höherer Aufwand als weithin üblich, dennoch sehe
ich ihn als erforderlich an (leider passt die Datenmenge nicht mal eben
auf eine USB-Platte). Alles Abweichen davon -gewissermaßen als
Mindeststandard- rechtfertigt ein Schulterzucken mit "kein Backup - kein
Mitleid", also einen Satz, den ich mir nie anhören müssen möchte.
--
Gruß
Alex
Am 20.01.24 um 12:13 schrieb Axel Berger:
> Ich verstehe, ehrlich gesagt, den Sinn dahinter nicht, es sei denn, Du
> hältst das NAS für inhärent unsicher.
dass diese NASe nicht sicher sind, ist erwiesen. Zu einen durch
> hältst das NAS für inhärent unsicher.
existierende Malware speziell für NASe, zum anderen durch die
Beobachtung, dass deren Firewall offenbar heimliche Lücken enthält.
> Ansonsten kann man sich den ganzen
> Quatsch sparen und einfach das Backup laufen lassen. Gegen einen
> Angreifer, der Kontrolle über den Server erlangt hat, hilft das eh nichts;
anderen ist er zur Zeit der Datensicherung komplett offline. Dennoch
könnte z.B. über die Clients Schaden an den Daten entstehen, der durch
die Datensicherung aufgefangen werden soll. Folglich ist die Sicherheit
und Verlässlichkeit der Datensicherung wichtig.
> der kann dann dennoch auf das NAS zugreifen.
> (Ja, gut, es hilft gegen
> gescriptete Lösungen, die dann das NAS vermutlich nicht - auf Anhieb -
> finden.)
solange die NASe selbst nicht von außen erreichbar und damit angreifbar
sind. Und da sind wir jetzt endlich wieder beim Thema: die NASe müssen
miteinander verbunden sein, dürfen jedoch keinesfalls mit dem Internet
eine Verbindung aufnehmen können.
> Insgesamt finde ich die Lösung eher skurril: sie betreibt einen
> erheblichen, im Durchschnitt nicht notwendigen Aufwand, ohne aber
> tatsächlich Sicherheit gegen gezielte Angriffe zu bieten.
ich ihn als erforderlich an (leider passt die Datenmenge nicht mal eben
auf eine USB-Platte). Alles Abweichen davon -gewissermaßen als
Mindeststandard- rechtfertigt ein Schulterzucken mit "kein Backup - kein
Mitleid", also einen Satz, den ich mir nie anhören müssen möchte.
--
Gruß
Alex
Alexander Goetzenstein
Jan 23, 2024, 9:16:43 AM1/23/24
to
Hallo,
Am 18.01.24 um 22:47 schrieb Michael Schwingen:
deshalb, weil die Route eben über dieselbe IP der FRITZ!Box läuft wie
der Internetverkehr -sonst könnte die FRITZ!Box kein VPN stellen. Oder
so ähnlich.
Vielleicht läuft es bei WireGuard anders; soweit ich sehe, wird ja eine
eigene IP zugewiesen, die nicht die der FRITZ!Box ist. Das kann ich hier
allerdings nicht ausprobieren, da eine der beiden FRITZ!Boxen kein
WireGuard anbietet. Eine solche Investition könnte ich vielleicht bei
der Chefin noch durchbekommen, aber nur, wenn ich vorher sicher weiß
(sprich: garantieren kann), dass es dann wie gewünscht funktioniert.
--
Gruß
Alex
Am 18.01.24 um 22:47 schrieb Michael Schwingen:
> Konfigurier' die NAS-Boxen nicht auf DHCP, sondern auf feste Adressen. Dann
> entweder kein Defaultgateway eintragen oder eine ungültige (nicht benutzte)
> Adresse im LAN. Optional dito für den DNS-Server, falls nicht gebraucht.
>
> Für die Adressen hinter dem VPN dann jeweils statische Routen auf den NAS.
>
> Voila: kein Internetzugriff.
das habe ich längst getan, es funktioniert aber auch nicht. Vermutlich
> entweder kein Defaultgateway eintragen oder eine ungültige (nicht benutzte)
> Adresse im LAN. Optional dito für den DNS-Server, falls nicht gebraucht.
>
> Für die Adressen hinter dem VPN dann jeweils statische Routen auf den NAS.
>
> Voila: kein Internetzugriff.
deshalb, weil die Route eben über dieselbe IP der FRITZ!Box läuft wie
der Internetverkehr -sonst könnte die FRITZ!Box kein VPN stellen. Oder
so ähnlich.
Vielleicht läuft es bei WireGuard anders; soweit ich sehe, wird ja eine
eigene IP zugewiesen, die nicht die der FRITZ!Box ist. Das kann ich hier
allerdings nicht ausprobieren, da eine der beiden FRITZ!Boxen kein
WireGuard anbietet. Eine solche Investition könnte ich vielleicht bei
der Chefin noch durchbekommen, aber nur, wenn ich vorher sicher weiß
(sprich: garantieren kann), dass es dann wie gewünscht funktioniert.
--
Gruß
Alex
Michael Schwingen
Jan 23, 2024, 10:44:41 AM1/23/24
to
On 2024-01-23, Alexander Goetzenstein <alexander_g...@web.de> wrote:
>> Konfigurier' die NAS-Boxen nicht auf DHCP, sondern auf feste Adressen. Dann
>> entweder kein Defaultgateway eintragen oder eine ungültige (nicht benutzte)
>> Adresse im LAN. Optional dito für den DNS-Server, falls nicht gebraucht.
>>
>> Für die Adressen hinter dem VPN dann jeweils statische Routen auf den NAS.
>>
>> Voila: kein Internetzugriff.
>
> das habe ich längst getan, es funktioniert aber auch nicht. Vermutlich
> deshalb, weil die Route eben über dieselbe IP der FRITZ!Box läuft wie
> der Internetverkehr -sonst könnte die FRITZ!Box kein VPN stellen. Oder
> so ähnlich.
Dann hast Du die Routen auf dem NAS falsch gesetzt. Da darf *keine*
>> Konfigurier' die NAS-Boxen nicht auf DHCP, sondern auf feste Adressen. Dann
>> entweder kein Defaultgateway eintragen oder eine ungültige (nicht benutzte)
>> Adresse im LAN. Optional dito für den DNS-Server, falls nicht gebraucht.
>>
>> Für die Adressen hinter dem VPN dann jeweils statische Routen auf den NAS.
>>
>> Voila: kein Internetzugriff.
>
> das habe ich längst getan, es funktioniert aber auch nicht. Vermutlich
> deshalb, weil die Route eben über dieselbe IP der FRITZ!Box läuft wie
> der Internetverkehr -sonst könnte die FRITZ!Box kein VPN stellen. Oder
> so ähnlich.
Defaultroute auf die Fritzbox aktiv sein. Ja, das erfordert, daß man alle
Routen manuell setzt. Eine Route, die nur das Netz des entfernten NAS
als Ziel enthält, erlaubt keinen Internetzugriff.
Marco Moock
Jan 23, 2024, 11:15:03 AM1/23/24
to
Am 23.01.2024 um 15:44:38 Uhr schrieb Michael Schwingen:
> Dann hast Du die Routen auf dem NAS falsch gesetzt. Da darf *keine*
> Defaultroute auf die Fritzbox aktiv sein. Ja, das erfordert, daß man
> alle Routen manuell setzt. Eine Route, die nur das Netz des
> entfernten NAS als Ziel enthält, erlaubt keinen Internetzugriff.
Das ist dann die Frage der VPN-Software, denn diese setzt i.d.R. die
> Dann hast Du die Routen auf dem NAS falsch gesetzt. Da darf *keine*
> Defaultroute auf die Fritzbox aktiv sein. Ja, das erfordert, daß man
> alle Routen manuell setzt. Eine Route, die nur das Netz des
> entfernten NAS als Ziel enthält, erlaubt keinen Internetzugriff.
Routen.
Michael Schwingen
Jan 23, 2024, 1:33:09 PM1/23/24
to
On 2024-01-23, Marco Moock <mm+s...@dorfdsl.de> wrote:
>> Dann hast Du die Routen auf dem NAS falsch gesetzt. Da darf *keine*
>> Defaultroute auf die Fritzbox aktiv sein. Ja, das erfordert, daß man
>> alle Routen manuell setzt. Eine Route, die nur das Netz des
>> entfernten NAS als Ziel enthält, erlaubt keinen Internetzugriff.
>
> Das ist dann die Frage der VPN-Software, denn diese setzt i.d.R. die
> Routen.
Äh - wie jetzt?
>> Dann hast Du die Routen auf dem NAS falsch gesetzt. Da darf *keine*
>> Defaultroute auf die Fritzbox aktiv sein. Ja, das erfordert, daß man
>> alle Routen manuell setzt. Eine Route, die nur das Netz des
>> entfernten NAS als Ziel enthält, erlaubt keinen Internetzugriff.
>
> Das ist dann die Frage der VPN-Software, denn diese setzt i.d.R. die
> Routen.
Ich dachte, Du benutzt das VPN zwischen den Fritzboxen?
Wenn Du die beiden NAS-Boxen selber als VPN-Endpunkt benutzt, sieht das
anders aus, ja. Aber: in dem Fall ist der VPN-Endpunkt des anderen NAS je
prinzipiell nur über's Internet erreichbar, das kannst Du also nicht
abklemmen.
Du brauchst einen VPN-Router ausserhalb des NAS. Dann hast Du auf dem NAS
aber wieder die Kontrolle über die Routen (wenn die Software da
einigermassen was taugt).
Marco Moock
Jan 23, 2024, 3:11:34 PM1/23/24
to
Am 23.01.2024 um 18:33:07 Uhr schrieb Michael Schwingen:
> Äh - wie jetzt?
> Ich dachte, Du benutzt das VPN zwischen den Fritzboxen?
Dann muss genau da die Route entsprechend gesetzt werden, dass eben nur
> Äh - wie jetzt?
> Ich dachte, Du benutzt das VPN zwischen den Fritzboxen?
das jeweils andere Netz über den Tunnel geht und keine Defaultroute.
Michael Schwingen
Jan 26, 2024, 2:44:42 PM1/26/24
to
On 2024-01-23, Marco Moock <mm+s...@dorfdsl.de> wrote:
>> Äh - wie jetzt?
>> Ich dachte, Du benutzt das VPN zwischen den Fritzboxen?
>
> Dann muss genau da die Route entsprechend gesetzt werden, dass eben nur
> das jeweils andere Netz über den Tunnel geht und keine Defaultroute.
Reden wir aneinander vorbei?
>> Ich dachte, Du benutzt das VPN zwischen den Fritzboxen?
>
> Dann muss genau da die Route entsprechend gesetzt werden, dass eben nur
> das jeweils andere Netz über den Tunnel geht und keine Defaultroute.
Ich verstehe das so: Du hast ein VPN zwischen den 2 Fritzboxen. Auf den
Fritzboxen gibt es jeweils eine Defaultroute, die ins Internet zeigt - die
wirst Du nicht los.
Du hast auf dem NAS eine Defaultroute, die auf die Fritzbox zeigt. *Die*
muss weg, und wenn die weg ist, kann das NAS keine Ziele ausserhalb des
lokalen Netzes mehr ansprechen.
Danach legst Du auf dem NAS eine Route an, die als Ziel das
entfernte VPN-Netz enthält und auf die Fritzbox als Gateway zeigt.
0 new messages