Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IPv4-Portforwarding an mehrere Ziele abhängig von der externen Client-IPv4-Adresse
32 views
Skip to first unread message
Andreas Meile
Apr 15, 2013, 10:41:44 AM4/15/13
to
Hallo zusammen
Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen m嚙編sen bzw.
von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
gibt es daf嚙緝 nur in beschr嚙緯kter Zahl und jeder auch hinter fixen
IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
k嚙緯nen.
Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
192.168.1.1
Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
$ ssh 192.0.2.47
auf den Server 192.168.1.198 gelangen, w嚙篁rend der Client 203.0.113.57
(Standort C) beim selben
$ ssh 192.0.2.47
dagegen auf Server 192.168.1.203 gelangt
=> Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
203.0.113.57, die auf Port 22 bei 192.0.2.47 zugreifen m嚙編sen.
Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
unterst嚙緣zen so etwas?
Andreas
--
Teste die PC-Sicherheit mit www.sec-check.net
Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen m嚙編sen bzw.
von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
gibt es daf嚙緝 nur in beschr嚙緯kter Zahl und jeder auch hinter fixen
IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
k嚙緯nen.
Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
192.168.1.1
Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
$ ssh 192.0.2.47
auf den Server 192.168.1.198 gelangen, w嚙篁rend der Client 203.0.113.57
(Standort C) beim selben
$ ssh 192.0.2.47
dagegen auf Server 192.168.1.203 gelangt
=> Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
203.0.113.57, die auf Port 22 bei 192.0.2.47 zugreifen m嚙編sen.
Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
unterst嚙緣zen so etwas?
Andreas
--
Teste die PC-Sicherheit mit www.sec-check.net
Juergen P. Meier
Apr 15, 2013, 11:52:56 AM4/15/13
to
Andreas Meile <use...@andreas-meile.ch>:
Diese speziele Form von NAPT kann u.A. z.B. Linux Netfilter (DNAT),
Check Point Firewall/VPN/UTM-1 (Firewall Blade), Cisco ASA
(kombiniertes explizites Policybasiertes PAT, version 8.2 oder
hoeher benoetigt) und vermutlich auch einige andere...
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
> unterstï¿œtzen so etwas?
Alles, was Linux Netfilter mit frei konfigurierbarem iptables (und den
noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
> SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen mï¿œssen bzw.
> von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
> gibt es dafï¿œr nur in beschrï¿œnkter Zahl und jeder auch hinter fixen
> IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
> kï¿œnnen.
Diese speziele Form von NAPT kann u.A. z.B. Linux Netfilter (DNAT),
Check Point Firewall/VPN/UTM-1 (Firewall Blade), Cisco ASA
(kombiniertes explizites Policybasiertes PAT, version 8.2 oder
hoeher benoetigt) und vermutlich auch einige andere...
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
Alles, was Linux Netfilter mit frei konfigurierbarem iptables (und den
noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
Ansgar -59cobalt- Wiechers
Apr 15, 2013, 12:01:01 PM4/15/13
to
Andreas Meile <use...@andreas-meile.ch> wrote:
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber
> mehrere SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen
> müssen bzw. von aussen erreichbar erreichbar, jedoch muss von aussen
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber
> mehrere SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen
> jeder Client (diese gibt es dafür nur in beschränkter Zahl und jeder
> auch hinter fixen IPv4-Adressen) nur immer auf seinen spezifischen
> SSH-Server zugreifen können.
>
> Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
>
> Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
> 192.168.1.1
> Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
>
> Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
> $ ssh 192.0.2.47
> auf den Server 192.168.1.198 gelangen, während der Client 203.0.113.57
> Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
>
> Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
> 192.168.1.1
> Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
>
> Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
> $ ssh 192.0.2.47
> (Standort C) beim selben
> $ ssh 192.0.2.47
> dagegen auf Server 192.168.1.203 gelangt
> => Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
> droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
> 203.0.113.57, die auf Port 22 bei 192.0.2.47 zugreifen müssen.
> $ ssh 192.0.2.47
> dagegen auf Server 192.168.1.203 gelangt
> => Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
> droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
>
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
> unterstützen so etwas?
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
Grob geschätzt: gar keine.
cu
59cobalt
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
Juergen Ilse
Apr 16, 2013, 2:49:33 AM4/16/13
to
Hallo,
Andreas Meile <use...@andreas-meile.ch> wrote:
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
> SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen mï¿œssen bzw.
AFAIK keine (obwohl so etwas denkbar waere, aber der Anwendungsfall duerfte
zu exotisch sein). Warum nicht *verschiedene* (non-Standard) Ports auf die
Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
guration auf den jeweiligen Hosts erledigen? Das geht mit fast jedem
aktuellen "SOHO-Router" ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Andreas Meile <use...@andreas-meile.ch> wrote:
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
> von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
> gibt es dafï¿œr nur in beschrï¿œnkter Zahl und jeder auch hinter fixen
> IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
> kï¿œnnen.
>
> Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
>
> Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
> 192.168.1.1
> Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
>
> Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
> $ ssh 192.0.2.47
> auf den Server 192.168.1.198 gelangen, wï¿œhrend der Client 203.0.113.57
> Einfaches Modellbeispiel mit IPv4-Adressen nach RFC 5737:
>
> Standort A: Besitzt 192.0.2.47 vom ISP, NAT-Firewall besitzt intern
> 192.168.1.1
> Dort laufen zwei Systeme 192.168.1.198 und 192.168.1.203
>
> Ziel: Der Client 198.51.100.11 (Standort B) soll bei einem
> $ ssh 192.0.2.47
> (Standort C) beim selben
> $ ssh 192.0.2.47
> dagegen auf Server 192.168.1.203 gelangt
> => Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
> droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
> 203.0.113.57, die auf Port 22 bei 192.0.2.47 zugreifen mï¿œssen.
> $ ssh 192.0.2.47
> dagegen auf Server 192.168.1.203 gelangt
> => Alle anderen externen Quelladressen mit Zielport 22 soll die Firewall
> droppen, es gibt also keine weiteren Clients ausser 198.51.100.11 und
>
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
> unterstï¿œtzen so etwas?
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
AFAIK keine (obwohl so etwas denkbar waere, aber der Anwendungsfall duerfte
zu exotisch sein). Warum nicht *verschiedene* (non-Standard) Ports auf die
Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
guration auf den jeweiligen Hosts erledigen? Das geht mit fast jedem
aktuellen "SOHO-Router" ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Juergen Ilse
Apr 16, 2013, 3:25:45 AM4/16/13
to
Hallo,
Juergen P. Meier <nospa...@jors.net> wrote:
> Andreas Meile <use...@andreas-meile.ch>:
>> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
>> SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen mï¿œssen bzw.
>> von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
>> gibt es dafï¿œr nur in beschrï¿œnkter Zahl und jeder auch hinter fixen
>> IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
>> kï¿œnnen.
> Diese speziele Form von NAPT kann u.A. z.B. Linux Netfilter (DNAT),
Wer eine solche Frage stellt, duerfte evt. beim zusammenstricken mittels
netfilter u.U. so seine Probleme haben, deswegen habe ich das nicht erwaehnt.
> Check Point Firewall/VPN/UTM-1 (Firewall Blade),
Duerfte eher kein "SOHO-Bereich" mehr sein ...
> Cisco ASA (kombiniertes explizites Policybasiertes PAT, version 8.2 oder
> hoeher benoetigt)
Ist auch eher jenseits von "SOHO" ... Geht das tatsaechlich nicht vor 8.2?
Muesste ich dann noch einmal nachlesen. Aber ab 8.3 ist bzgl. NAT und PAT
ohnehin alles voellig anders als vorher, da hat Cisco in der Richtung *alles*
*voellig* umgekrempelt und *voellig* *inkompatibel* veraendert. Nicht, dass
das neue schlechter waere (eigentlich ist es sogar besser), aber das erfordert
im Zweifelsfall ein voelliges neuschreiben des entsprechenden Teils der
Konfiguration. In einem Fall hat die automatische Konvertierung der NAT-
uns STATIC-Konfiguration einer Firewall (mit reichlich NAT- und PAT-Regeln)
bei der "automatischen Konvertierung auf das neue Format" die Kleinigkeit
von ueber 1100 (!!!) NAT-Regeln erzeugt, ein manuellen neuschreiben blieb
dann bei ca. 130 statt dieser ca. 1100 Regeln (immer noch viel, aber
zumindest noch halbwegs ueberschaubar, im Gegensatz zu den automatisch
generierten mehr als 1000 Regeln). Abgesehen von irgendwelchen Trivial-
Faellen scheint die "automatische Konvertierung" da nur einen Riesenhaufen
unuebersichtlichen Muell zu erzeugen, so dass man bei einem solchen Umstieg
auf die neuere Firmware doch besser diesen Teil der Konfiguration komplett
neu schreibt.
> und vermutlich auch einige andere...
Vermutlich. Nur vermutlich eher weniger im "SOHO-Bereich"
>> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
>> unterstï¿œtzen so etwas?
> Alles, was Linux Netfilter mit frei konfigurierbarem iptables (und den
> noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
> chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
> scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
... und der Rest duerfte fuer den 08/15 User eher schwer bis gar nicht
in dieser Hinsicht zu konfigurieren sein, weil es doch eher eine tiefere
Einarbeitung erfordern wuerde ...
Juergen P. Meier <nospa...@jors.net> wrote:
> Andreas Meile <use...@andreas-meile.ch>:
>> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
>> SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen mï¿œssen bzw.
>> von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
>> gibt es dafï¿œr nur in beschrï¿œnkter Zahl und jeder auch hinter fixen
>> IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
>> kï¿œnnen.
> Diese speziele Form von NAPT kann u.A. z.B. Linux Netfilter (DNAT),
netfilter u.U. so seine Probleme haben, deswegen habe ich das nicht erwaehnt.
> Check Point Firewall/VPN/UTM-1 (Firewall Blade),
> Cisco ASA (kombiniertes explizites Policybasiertes PAT, version 8.2 oder
> hoeher benoetigt)
Muesste ich dann noch einmal nachlesen. Aber ab 8.3 ist bzgl. NAT und PAT
ohnehin alles voellig anders als vorher, da hat Cisco in der Richtung *alles*
*voellig* umgekrempelt und *voellig* *inkompatibel* veraendert. Nicht, dass
das neue schlechter waere (eigentlich ist es sogar besser), aber das erfordert
im Zweifelsfall ein voelliges neuschreiben des entsprechenden Teils der
Konfiguration. In einem Fall hat die automatische Konvertierung der NAT-
uns STATIC-Konfiguration einer Firewall (mit reichlich NAT- und PAT-Regeln)
bei der "automatischen Konvertierung auf das neue Format" die Kleinigkeit
von ueber 1100 (!!!) NAT-Regeln erzeugt, ein manuellen neuschreiben blieb
dann bei ca. 130 statt dieser ca. 1100 Regeln (immer noch viel, aber
zumindest noch halbwegs ueberschaubar, im Gegensatz zu den automatisch
generierten mehr als 1000 Regeln). Abgesehen von irgendwelchen Trivial-
Faellen scheint die "automatische Konvertierung" da nur einen Riesenhaufen
unuebersichtlichen Muell zu erzeugen, so dass man bei einem solchen Umstieg
auf die neuere Firmware doch besser diesen Teil der Konfiguration komplett
neu schreibt.
> und vermutlich auch einige andere...
>> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
>> unterstï¿œtzen so etwas?
> Alles, was Linux Netfilter mit frei konfigurierbarem iptables (und den
> noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
> chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
> scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
in dieser Hinsicht zu konfigurieren sein, weil es doch eher eine tiefere
Einarbeitung erfordern wuerde ...
Lutz Donnerhacke
Apr 16, 2013, 3:39:45 AM4/16/13
to
* Andreas Meile wrote:
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
> unterstützen so etwas?
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
BTDT:
- ASA5505 mit OS >= 8.3
- Linux mit handgeschriebene IPFW-Regeln
Lutz Donnerhacke
Apr 16, 2013, 3:41:55 AM4/16/13
to
* Juergen Ilse wrote:
> Ist auch eher jenseits von "SOHO" ... Geht das tatsaechlich nicht vor 8.2?
Doch, aber das ist "static ... access-list ..." oder "nat ... access-list
> Ist auch eher jenseits von "SOHO" ... Geht das tatsaechlich nicht vor 8.2?
... outside" mehr als krank.
Lutz Donnerhacke
Apr 16, 2013, 3:43:47 AM4/16/13
to
* Andreas Meile wrote:
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
> unterst�tzen so etwas?
> Frage: Welche Hardware-Firewalls/Breitbandrouter im SOHO-Bereich
BTDT:
- ASA5505 mit OS >= 8.3
Juergen Ilse
Apr 16, 2013, 5:58:12 AM4/16/13
to
Hallo,
Das ist aber doch bei 8.2 noch genauso. Erst ab 8.3 hat man doch die "neue
NAT-Syntax", oder?
NAT-Syntax", oder?
Juergen P. Meier
Apr 16, 2013, 6:05:30 AM4/16/13
to
Juergen Ilse <jue...@usenet-verwaltung.de>:
MIt 8.2 (und vorher) geht das zwar auch, aber die Konfig ist
<<<CENSORED>>>
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> * Juergen Ilse wrote:
>>> Ist auch eher jenseits von "SOHO" ... Geht das tatsaechlich nicht vor 8.2?
>>
>> Doch, aber das ist "static ... access-list ..." oder "nat ... access-list
>> ... outside" mehr als krank.
>>
>
> Das ist aber doch bei 8.2 noch genauso. Erst ab 8.3 hat man doch die "neue
> NAT-Syntax", oder?
Ja, mein Fehler. Ich meinte 8.3 im urspruenglichen Posting.
>> * Juergen Ilse wrote:
>>> Ist auch eher jenseits von "SOHO" ... Geht das tatsaechlich nicht vor 8.2?
>>
>> Doch, aber das ist "static ... access-list ..." oder "nat ... access-list
>> ... outside" mehr als krank.
>>
>
> Das ist aber doch bei 8.2 noch genauso. Erst ab 8.3 hat man doch die "neue
> NAT-Syntax", oder?
MIt 8.2 (und vorher) geht das zwar auch, aber die Konfig ist
<<<CENSORED>>>
Stefan Krister
Apr 16, 2013, 9:22:47 AM4/16/13
to
Hi Andreas,
Andreas Meile schrieb am 15.04.2013 16:41:
>
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
> SSH-Server hinter dem NAT, welche auf dem gleichen Port laufen mï¿œssen bzw.
fli4l kann das. Lï¿œuft auf aller halbwegs modernen Intel-Hardware. Ich
hab hier in der Firma 4 Alix Boards (+ Gehï¿œuse, + CF-Karte, + teils
WLAN) am laufen und z. T. ï¿œhnliche Regeln (nur der Mailprovider darf
SMTP an den Exchange machen ...) konfiguriert.
Das Regelwerk wird bei fli4l dann in etwa so aussehen:
PF_PREROUTING_1='prot:tcp quelle1 dynamic:22 DNAT:ziel1'
PF_PREROUTING_1='prot:tcp quelle2 dynamic:22 DNAT:ziel2'
...
Ein anderes Anwendungsbeispiel sieht man hier:
http://www.fli4l.de/sonstiges/projekte/
MfG
Stefan
Andreas Meile schrieb am 15.04.2013 16:41:
>
> Folgendes Problemstellung: vom ISP nur 1 fixe IPv4-Adresse, aber mehrere
> von aussen erreichbar erreichbar, jedoch muss von aussen jeder Client (diese
> gibt es dafï¿œr nur in beschrï¿œnkter Zahl und jeder auch hinter fixen
> IPv4-Adressen) nur immer auf seinen spezifischen SSH-Server zugreifen
> kï¿œnnen.
fli4l kann das. Lï¿œuft auf aller halbwegs modernen Intel-Hardware. Ich
hab hier in der Firma 4 Alix Boards (+ Gehï¿œuse, + CF-Karte, + teils
WLAN) am laufen und z. T. ï¿œhnliche Regeln (nur der Mailprovider darf
SMTP an den Exchange machen ...) konfiguriert.
Das Regelwerk wird bei fli4l dann in etwa so aussehen:
PF_PREROUTING_1='prot:tcp quelle1 dynamic:22 DNAT:ziel1'
PF_PREROUTING_1='prot:tcp quelle2 dynamic:22 DNAT:ziel2'
...
Ein anderes Anwendungsbeispiel sieht man hier:
http://www.fli4l.de/sonstiges/projekte/
MfG
Stefan
Andreas Meile
Apr 23, 2013, 4:40:34 AM4/23/13
to
Hallo J�rgen
"Juergen P. Meier" <nospa...@jors.net> schrieb im Newsbeitrag
news:28942.13187...@news.jors.net...
meinem Umfeld l�uft.
=> Dort lassen sich im Web-GUI unter "Incoming" problemlos zwei
Firewall-Regeln platzieren, welche denselben Zielport verwenden, man muss
einfach bei beiden Regeln bei "Incoming Filter" ein "Allow" setzen, bei
beiden Regeln das "Any" entfernen und die jeweils gew�nschten Aussenstellen
IPv4-Adressen bzw. -bereiche setzen.
=> Danach funktioniert ein "ssh -l user ziel.example.com" von aussen wie
gew�nscht und "bef�rdert" einem abh�ngig von der externen IPv4-Adresse auf
den gew�nschten Host.
Hinweis: Die Firmware bei Watchguard basiert meines Wissen letztendlich auch
auf Linux.
Ansonsten werde ich diesen Punkt bei der M0n0wall[1] einmal noch anschauen.
Andreas
[1] http://www.m0n0wall.ch
"Juergen P. Meier" <nospa...@jors.net> schrieb im Newsbeitrag
news:28942.13187...@news.jors.net...
> Alles, was Linux Netfilter mit frei konfigurierbarem iptables (und den
> noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
> chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
> scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
Vorhin erfolgreich selber getestet: Watchguard Firebox X Edge, welche in
> noetigen Match- und NAT-Modulen) erlaubt. Insbesondere musst du eigene
> chains in den Filter- und Nat-Tabellen anlegen koennen. Damit
> scheiden einige wenige Linux-basierte Systeme mit restriktivem UI aus.
meinem Umfeld l�uft.
=> Dort lassen sich im Web-GUI unter "Incoming" problemlos zwei
Firewall-Regeln platzieren, welche denselben Zielport verwenden, man muss
einfach bei beiden Regeln bei "Incoming Filter" ein "Allow" setzen, bei
beiden Regeln das "Any" entfernen und die jeweils gew�nschten Aussenstellen
IPv4-Adressen bzw. -bereiche setzen.
=> Danach funktioniert ein "ssh -l user ziel.example.com" von aussen wie
gew�nscht und "bef�rdert" einem abh�ngig von der externen IPv4-Adresse auf
den gew�nschten Host.
Hinweis: Die Firmware bei Watchguard basiert meines Wissen letztendlich auch
auf Linux.
Ansonsten werde ich diesen Punkt bei der M0n0wall[1] einmal noch anschauen.
Andreas
[1] http://www.m0n0wall.ch
Andreas Meile
Apr 23, 2013, 5:01:46 AM4/23/13
to
Hallo Jürgen
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb im Newsbeitrag
news:516cf47d$0$16557$7b62...@news1.net.de...
Hersteller mitgeteilt hat, dass sich in der aktuellen Softwareversion der
Standardport nicht ändern lässt. Weil dort schon heute ein Linux mit einem
"beschränkt sichtbaren" SSH von aussen läuft, welches aber nichts mit dem
geplanten NAS zu tun hat (das NAS soll übrigens Datenreplikation machen für
jemand, der mit dem bestehenden Linux nichts zu tun hat), liegt die Idee für
ein statisches NAT nahe, welches anhand der externen IPv4-Adresse
entscheidet, auf welche interne RFC 1918-IPv4-Adresse der SSH-Zugriff
erfolgen soll, womit der Internet-Anschluss nicht unnötig um weitere fixe
IPv4-Adressen aufgerüstet werden muss (welche bekanntlich inzwischen ein
knappes Gut geworden sind).
Ein Test auf einer Watchguard Firebox X Edge war bereits erfolgreich. Mit
IPv6 erübrigt sich dieses Problem dann hoffentlich, weil es dann wieder mehr
als genügend weltweit eindeutige IP-Adressen selbst im dort kleinsten
/64er-Subnetz gibt.
Andreas
PS: Danke noch an alle übrigen Antworten.
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb im Newsbeitrag
news:516cf47d$0$16557$7b62...@news1.net.de...
> Warum nicht *verschiedene* (non-Standard) Ports auf die
> Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
> Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
> ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
> guration auf den jeweiligen Hosts erledigen?
Zielsystem der geplanten Anwendung ist übrigens ein NAS, wo mir der
> Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
> Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
> ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
> guration auf den jeweiligen Hosts erledigen?
Hersteller mitgeteilt hat, dass sich in der aktuellen Softwareversion der
Standardport nicht ändern lässt. Weil dort schon heute ein Linux mit einem
"beschränkt sichtbaren" SSH von aussen läuft, welches aber nichts mit dem
geplanten NAS zu tun hat (das NAS soll übrigens Datenreplikation machen für
jemand, der mit dem bestehenden Linux nichts zu tun hat), liegt die Idee für
ein statisches NAT nahe, welches anhand der externen IPv4-Adresse
entscheidet, auf welche interne RFC 1918-IPv4-Adresse der SSH-Zugriff
erfolgen soll, womit der Internet-Anschluss nicht unnötig um weitere fixe
IPv4-Adressen aufgerüstet werden muss (welche bekanntlich inzwischen ein
knappes Gut geworden sind).
Ein Test auf einer Watchguard Firebox X Edge war bereits erfolgreich. Mit
IPv6 erübrigt sich dieses Problem dann hoffentlich, weil es dann wieder mehr
als genügend weltweit eindeutige IP-Adressen selbst im dort kleinsten
/64er-Subnetz gibt.
Andreas
PS: Danke noch an alle übrigen Antworten.
Juergen Ilse
Apr 23, 2013, 6:20:29 AM4/23/13
to
> "Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb im Newsbeitrag
> news:516cf47d$0$16557$7b62...@news1.net.de...
>> Warum nicht *verschiedene* (non-Standard) Ports auf die
>> Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
>> Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
>> ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
>> guration auf den jeweiligen Hosts erledigen?
> Zielsystem der geplanten Anwendung ist übrigens ein NAS, wo mir der
> Hersteller mitgeteilt hat, dass sich in der aktuellen Softwareversion der
> Standardport nicht ändern lässt.
Das ist doch erst einmal kein Hindernis, solange man die IP-Adressranges
> news:516cf47d$0$16557$7b62...@news1.net.de...
>> Warum nicht *verschiedene* (non-Standard) Ports auf die
>> Ports 22 der beteiligten Geraete forwarden, von aussen eben mit Angabe des
>> Zielports im ssh-Aufurf zugreifen und das filtern, dass auf jedem Host nur
>> ssh-Connections von bestimmten remote-IPs angenmommen werden, durch Konfi-
>> guration auf den jeweiligen Hosts erledigen?
> Zielsystem der geplanten Anwendung ist übrigens ein NAS, wo mir der
> Hersteller mitgeteilt hat, dass sich in der aktuellen Softwareversion der
> Standardport nicht ändern lässt.
beschraenken kann, die per ssh darauf zugreifen duerfen. Falls das nicht
geht, wird man eben irgendwo davor (ggfs. auf dem "NAT-DEVICE", dass die
Portumsetzung macht) filtern muessen ...
> Weil dort schon heute ein Linux mit einem "beschränkt sichtbaren" SSH
> von aussen läuft,
> welches aber nichts mit dem geplanten NAS zu tun hat (das NAS soll
> übrigens Datenreplikation machen für jemand, der mit dem bestehenden
> Linux nichts zu tun hat), liegt die Idee für ein statisches NAT nahe,
> welches anhand der externen IPv4-Adresse entscheidet, auf welche
> interne RFC 1918-IPv4-Adresse der SSH-Zugriff erfolgen soll, womit der
> Internet-Anschluss nicht unnötig um weitere fixe IPv4-Adressen
> aufgerüstet werden muss (welche bekanntlich inzwischen ein knappes
> Gut geworden sind).
doch verschiedene Ports auch tun, die dann intern auf den ssh-Port ver-
schiedener interner RFC1918-Adressen weitergeleitet werden.
> Ein Test auf einer Watchguard Firebox X Edge war bereits erfolgreich. Mit
> IPv6 erübrigt sich dieses Problem dann hoffentlich, weil es dann wieder mehr
> als genügend weltweit eindeutige IP-Adressen selbst im dort kleinsten
> /64er-Subnetz gibt.
IPv6 existieren (und ich nicht so recht weiss, ob ich mich darueber eher
freuen oder eher aergern soll ...).
0 new messages