![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Vorige: Network Address Translation] [Inhoud] [Volgende: Shortcuts om Regelsets aan te maken]
Laten we naar een voorbeeld kijken:
rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20
Deze lijn leidt TCP poort 80 (web server) verkeer om naar een machine binnen het netwerk op 192.168.1.20. Dus, zelfs al staat 192.168.1.20 achter uw gateway en binnen uw netwerk, dan kan de buitenwereld hem toch bereiken.
Het from any to any gedeelte van de bovenstaande rdr lijn kan erg nuttig zijn. Als u weet welke adressen of subnets toegang zouden mogen hebben tot de webserver op poort 80, kan u ze hier beperken:
rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \
192.168.1.20
Dit zal alleen het opgegeven subnet omleiden. Merk op dat dit impliceert dat u verschillende binnenkomende hosts naar verschillende machines achter de gateway kan omleiden. Dit kan erg nuttig zijn. U zou bijvoorbeeld gebruikers op remote sites toegang tot hun eigen desktop computers kunnen verlenen met dezelfde poort en hetzelfde IP adres op de gateway zolang u het IP adres kent van waar ze zullen verbinden:
rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \
192.168.1.20
rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \
192.168.1.22
rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \
192.168.1.23
Een bereik van poorten kan ook omgeleid worden binnen dezelfde regel:
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 6000
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 7000:*
Deze voorbeelden tonen dat poorten 5000 tot 5500 inbegrepen omgeleid worden naar 192.168.1.20. In regel #1 wordt poort 5000 omgeleid naar 5000, 5001 naar 5001, etc. In regel #2 wordt het gehele poortbereik omgeleid naar 6000. En in regel #3 wordt poort 5000 omgeleid naar 7000, 5001 naar 7001, etc.
De enige uitzondering op deze regel is wanneer het pass sleutelwoord gebruikt wordt binnen de rdr regel. In dit geval zullen de omgeleide pakketten "stateful" recht doorheen de filtermotor passeren: de filterregels zullen niet geëvalueerd worden voor deze pakketten. Dit is een handige shortcut om te vermijden pass filterregels toe te voegen voor iedere omleidingsregel. Beschouw het als een normale rdr regel (zonder pass sleutelwoord) geassocieerd met een pass filterregel met het keep state sleutelwoord. Als u echter meer specifieke filteropties zoals synproxy, modulate state, enz. wil inschakelen, zal u nog steeds een specifieke pass regel moeten gebruken aangezien deze opties niet binnen omleidingsregels passen.
Besef ook dat aangezien vertaling gebeurt vóór filtering, de filtermotor het vertaalde pakket zal zien zoals het er uitziet nadat zijn bestemmings-IP adres en/of bestemmingspoort veranderd werden in het omleidingsadres/poort gespecificeerd in de rdr regel. Beschouw het volgende scenario:
Omleidingsregel:
rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \
-> 192.168.1.5 port 8000
Pakket vóór het verwerken van de rdr regel:
Pakket ná het verwerken van de rdr regel:
De filtermotor zal het IP pakket zien zoals het er uitziet nadat de vertaling gebeurd is.
Deze risico's kunnen geminimaliseerd worden door het extern toegankelijke systeem stevig opgesloten te houden op een afzonderlijk netwerk. Dit netwerk wordt vaak een Demilitarized Zone (DMZ) of een Private Service Network (PSN) genoemd. Op deze manier, als de webserver gecompromitteerd wordt, kunnen de effecten beperkt worden tot het DMZ/PSN netwerk door voorzichtig filteren van het verkeer toegelaten naar en vanaf het DMZ/PSN.
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80
Maar wanneer de omleidingsregel getest wordt vanaf een client op de LAN, werkt het niet. De reden is dat omleidingsregels alleen van toepassing zijn op pakketten die langs de gespecificeerde interface ($ext_if, de externe interface, in het voorbeeld) passeren. Verbinden met het externe adres van de firewall vanaf een host in de LAN, betekent echter niet dat de pakketten werkelijk langs zijn externe interface zullen passeren. De TCP/IP stack op de firewall vergelijkt het bestemmingsadres van binnenkomende pakketten met zijn eigen adressen en aliast en detecteert verbindingen naar zichzelf zodra ze de interne interface voorbij zijn. Zulke pakketten gaan niet fysisch langs de externe interface, en de stack simuleert zulke doorgang op geen enkele manier. Dus, PF ziet deze pakketten nooit op de externe interface, en de omleidingsregel, die de externe interface specificeert, is niet van toepassing.
Een tweede omleidingsregel toevoegen voor de interne interface heeft ook niet het gewenste effect. Wanneer de lokale client verbindt naar het externe adres van de firewall, zal het initiële pakket van de TCP handdruk ("handshake") de firewall bereiken langs de interne interface. De omleidingsregel is niet van toepassing en het bestemmingsadres wordt vervangen door dat van de interne server. Het pakket wordt terug via de interne interface doorgestuurd en bereikt de interne server. Maar het bronadres werd niet vertaald, en bevat nog steeds het adres van de lokale client, dus de server stuurt zijn antwoorden rechtstreeks naar de client. De firewall ziet het antwoord nooit en krijgt niet de kans om de vertaling netjes om te keren. De client ontvangt een antwoord van een bron die hij nooit verwachtte en laat het vallen. De TCP handdruk mislukt dan en er kan geen verbinding opgericht worden.
Toch is het vaak wenselijk voor clients in de LAN om te verbinden met dezelfde interne server als externe clients en om dit transparant te doen. Er zijn verscheidene oplossingen voor dit probleem:
Het is mogelijk om DNS servers te configureren om opzoekingen van lokale hosts verschillend te beantwoorden dan externe opzoekingen zodat de lokale clients het adres van de interne server zullen ontvangen tijdens de naamvertaling. Ze zullen dan rechtstreeks met de lokale server verbinden, en de firewall is hier helemaal niet bij betrokken. Dit reduceert lokaal verkeer omdat pakketten niet doorheen de firewall gezonden moeten worden.
Een bijkomende netwerkinterface toevoegen aan de firewall en de lokale server vanuit het netwerk van de client verplaatsen naar een specifiek netwerk (DMZ) laat de omleiding toe van verbindingen van lokale clients op dezelfde manier als de omleiding van externe verbindingen. Het gebruik van afzonderlijke netwerken heeft verscheidene voordelen, waaronder het verbeteren van de veiligheid door de server te isoleren van de overblijvende lokale hosts. Als de server (die in ons geval bereikbaar is vanaf het Internet) ooit gecompromitteerd wordt, hij heeft geen rechtstreekse toegang tot de andere hosts aangezien alle verbindingen via de firewall moeten.
Een algemene TCP proxy kan ingesteld worden op de firewall, die ofwel luistert op de poort die doorgestuurd moet worden, ofwel verbindingen op de interne interface omleidt naar de poort waarop hij luistert. Wanneer een lokale client verbindt met de firewall, aanvaardt de proxy de verbinding, richt een tweede verbinding op met de interne server, en stuurt gegevens door tussen deze twee verbindingen.
Eenvoudige proxies kunnen aangemaakt worden met inetd(8) en nc(1). De volgende /etc/inetd.conf entry creëert een luisterende socket verbonden aan het loopback adres (127.0.0.1) en poort 5000. Verbindingen worden doorgestuurd naar poort 80 op server 192.168.1.10.
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80
De volgende omleidingsregel stuurt poort 80 op de interne interface door naar de proxy:
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000
Met een bijkomende NAT regel op de interne interface kan de ontbrekende vertaling van het bronadres die hierboven beschreven werd, bereikt worden.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if
Dit zal ervoor zorgen dat het initiële pakket van de client opnieuw vertaald wordt wanneer het terug doorgestuurd wordt via de interne interface, waarbij het bronadres van de client vervangen wordt door het interne adres van de firewall. De interne server zal terug antwoorden naar de firewall, die allebei NAT en RDR vertalingen kan omkeren bij het doorsturen naar de lokale client. Deze constructie is eerder complex aangezien ze twee afzonderlijke toestanden ("states") creëert voor elke gereflecteerde verbinding. Er moet zorg voor gedragen worden om te vermijden dat de NAT regel op ander verkeer van toepassing wordt, bijvoorbeeld verbindingen die van externe hosts komen (door andere omleidingen) of van de firewall zelf. Merk op dat de rdr regel hierboven er voor zal zorgen dat de TCP/IP stack de pakketten ziet aankomen op de interne interface met een bestemmingsadres binnen het interne netwerk.
In het algemeen worden beter de voorheen vermelde oplossingen gebruikt.
[Vorige: Network Address Translation] [Inhoud] [Volgende: Shortcuts om Regelsets aan te maken]
![[terug]](../../../images/back.gif){kind=small}
www@openbsd.org