IPtables redirection

[Verwijderd]

Na veel proberen nog steeds niet wat ik wil voor elkaar.

Ik wil een poort redirection van buiten naar binnen, waarbij de oorspronkelijke poort niet benaderbaar is van buiten maar wel lokaal.

Intern (lo interface) http op poort 80 en extern benaderbaar via poort 300 iod.

Deze link heeft me wel aardig op weg geholpen:
http://www.go2linux.org/i...ept-email-on-another-port

[blaataaps]

Wat heb je geprobeerd en waarom werkte dat niet? En probeer je niet een poort te forwarden die gefirewalled is door je provider?

[ Voor 43% gewijzigd door blaataaps op 25-09-2007 21:46 ]

[deadinspace]

Ik vind het in zo'n geval makkelijker om een service op meerdere poorten tegelijk te laten luisteren, en dan de poorten die je van buitenaf niet benaderbaar wil hebben te firewallen.

[Verwijderd]

deadinspace schreef op dinsdag 25 september 2007 @ 22:06:
Ik vind het in zo'n geval makkelijker om een service op meerdere poorten tegelijk te laten luisteren, en dan de poorten die je van buitenaf niet benaderbaar wil hebben te firewallen.

Dit is een beetje het idee, echter beperk ik me liever tot de firewall

[Verwijderd]

blaataaps schreef op dinsdag 25 september 2007 @ 21:45:
Wat heb je geprobeerd en waarom werkte dat niet? En probeer je niet een poort te forwarden die gefirewalled is door je provider?

Ik heb geprobeerd wat in de link staat, plus een beetje zelf aan de haal. Maar iptables is bijzonder ondoorzichtig (en dat voor iemand die ISA server snapt )

Nu staan poort INPUT 80 en 1977 open, ik heb een redirect van 80 naar 1977. Nu is HTTP op beide poorten te benaderen. Leuk en nu?
Weghalen van de input 80 is geen optie, dus ik moet alleen poort 80 exclusief toestaan van de redirect rule iod.

[Verwijderd]

kick

[Mitch]

waarom gebruik je de loopback interface en waarom heb je de iptables howto niet doorgewerkt ?
Iptables is niet ondoorzichtig, maar je moet je wel even inlezen in de manier waarop het werkt.

[ Voor 12% gewijzigd door Mitch op 27-09-2007 11:59 ]

[Mathijs1]

bekijk eens http://iptables-tutorial....et/iptables-tutorial.html en let op de -sport en -dport arguments. Hier kun je dus een TCP rule aanmaken met als source poort 1977 en als destination port 80.

[Verwijderd]

Bedankt voor hints….. MAAR ik zoek echt niet iemand die me kan vertellen waar ik een howto kan vinden. Internet is mijn wel bekend.
Ik heb een idee waar ik graag een antwoord voor zoek, je kunt/wilt helpen met beantwoorden of niet.

[ Voor 98% gewijzigd door Verwijderd op 27-09-2007 13:23 ]

[Zwerver]

Verwijderd schreef op donderdag 27 september 2007 @ 13:17:
Bedankt voor hints….. MAAR ik zoek echt niet iemand die me kan vertellen waar ik een howto kan vinden. Internet is mijn wel bekend.
Ik heb een idee waar ik graag een antwoord voor zoek, je kunt/wilt helpen met beantwoorden of niet.

offtopic:
Het lijkt erop dat je niet goed gezocht hebt, want het is een heel bekend probleem waarvan de antwoorden op internet duidelijk te vinden zijn. Het heeft dus niks met willen/kunnen helpen te maken volgens mij.

Even heel concreet je probleem, je hebt een http server draaien op je servertje en je wil die bereikbaar hebben op port 300 (extern). Intern is in jou geval alleen op de lo (dus vanaf je server zelf) en wil je op port 80 hebben? Correct?

Gebruik je apache: applicatie op port 300 en port 80 laten draaien en in je firewall alle verkeer naar port 80 op je externe interface blokkeren.

Simpelste manier. Lastig doen? Dan ga je port 300 redirecten naar de lo interface port 80 (geen idee of dat uberhaupt kan, maar goed) en dat zou dan ongeveer zo moeten:

code:

iptables -t nat -A PREROUTING -p tcp --dport 300 -j REDIRECT --to-ports 80

Daarnaast moet je dan nog steeds port 80 op je externe interface blokken.

[Ultraman]

Ik vind IPTables echt niet ondoorzichtig. Wennen is het zeker, maar zodra je weet hoe het werkt dan krijg je een vrij goede indruk van wat er precies met het verkeer gebeurd en dus hoe het afgehandeld wordt.
Nou heb ik hier een servertje draaien die het internet routeert met de nodige portforwards op het moment, die ik eigenlijk wil gaan centraliseren op die bak, maar dat is even andere koek.
Die tutorial die je zelf al geeft, met het REDIRECT target, leek mij in eerste instantie de aangewezen kandidaat voor dit klusje. Zoiets als:

code:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 1977

Maar blijkbaar doet het niet precies wat jij wilt.
Nou zit ik me af te vragen hoe je netwerksituatie is en wat er dus precies moet gebeuren.
Teken het desnoods even uit, accurate plaatjes van een netwerk in combinatie met wat tekstuele uitleg geeft mijzelf vaak twee keer beter beeld van de situatie dan enkel een kort lapje puur tekst met blaat zeg maar.
Wil je verkeer naar die firewallPC zelf al redirecten of naar een PC er achter bijvoorbeeld?

Zwerver was me al voor \o/
Ik moet F5en voordat ik een post ga schrijven

[ Voor 9% gewijzigd door Ultraman op 27-09-2007 14:13 ]

[Verwijderd]

Concreet, apache port 80 op port 1977 draaien met behulp van iptables. Waarbij port 80 niet meer toegankelijk is. Config van apache en ev andere appl wil ik niet aanpassen. Server heeft één nic met één ip adres, LAMP configuratie. Geen lan of nat clients achter dat ding.

Dit had ik gisteren uitgevonden, met internet en howtos. Maar je raad het al, doet niet wat ik wil.
Het zal iets stoms kunnen zijn, of een hele andere aanpak nodig hebben.

code:

-A PREROUTING -p tcp -m tcp ! -i lo --dport 1977 -j REDIRECT --to-ports 80
-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 80
[knip]
-A INPUT -p tcp -i eth0 --dport 80 -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

offtopic
ik heb best gezocht en geprobeerd voor ik posten

[ Voor 16% gewijzigd door Verwijderd op 27-09-2007 14:05 ]

[blaataaps]

Waarom post je niet de hele configuratie, en heb je al met -I ipv -A geprobeerd? En zijn de regels die je post ook incompleet, want PREROUTING zit volgens mij in de nat table. Zo te zien is regel 5 na regel 4 al nutteloos, iptables is first-match namelijk.

[ Voor 22% gewijzigd door blaataaps op 27-09-2007 14:09 ]

[Zwerver]

Verwijderd schreef op donderdag 27 september 2007 @ 14:01:
Concreet, apache port 80 op port 1977 draaien met behulp van iptables. Waarbij port 80 niet meer toegankelijk is. Config van apache en ev andere appl wil ik niet aanpassen. Server heeft één nic met één ip adres, LAMP configuratie. Geen lan of nat clients achter dat ding.

Dit had ik gisteren uitgevonden, met internet en howtos. Maar je raad het al, doet niet wat ik wil.
Het zal iets stoms kunnen zijn, of een hele andere aanpak nodig hebben.

code:

-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 80
[knip]

offtopic
ik heb best gezocht en geprobeerd voor ik posten

Wat wil je met die regel die ik nu heb laten staan bereiken? Wat denk je dat ie doet uberhaupt?

[Verwijderd]

Of die drop nutteloos ...... hierbij de rest van code

code:

cat /etc/sysconfig/iptables
# Generated by iptables-save v1.3.5 on Tue Sep 25 04:43:56 2007
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp ! -i lo --dport 1977 -j REDIRECT --to-ports 80
-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 80
COMMIT
# Completed on Tue Sep 25 04:43:56 2007
# Generated by iptables-save v1.3.5 on Tue Sep 25 04:43:56 2007
*mangle
:PREROUTING ACCEPT [11:1218]
:INPUT ACCEPT [11:1218]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10:3813]
:POSTROUTING ACCEPT [11:3845]
COMMIT
# Completed on Tue Sep 25 04:43:56 2007
# Generated by iptables-save v1.3.5 on Tue Sep 25 04:43:56 2007
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
# Accept traffic with the ACK flag set
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
# Allow incoming data that is part of a connection we established
-A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow data that is related to existing connections
-A INPUT -m state --state RELATED -j ACCEPT
# Accept responses to DNS queries
-A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j DROP
# Accept responses to our pings
-A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
# Accept notifications of unreachable hosts
-A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
# Accept notifications to reduce sending speed
-A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
# Accept notifications of lost packets
-A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
# Accept notifications of protocol problems
-A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
# Allow connections to our SSH server
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -i eth0 --dport 80 -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1977 -j ACCEPT
COMMIT
# Completed on Tue Sep 25 04:43:56 2007

[Verwijderd]

Zwerver schreef op donderdag 27 september 2007 @ 14:12:
[...]

Wat wil je met die regel die ik nu heb laten staan bereiken? Wat denk je dat ie doet uberhaupt?

Ergens gelezen dat het netjes was een OUTPUT te maken na een redirect, maar vraag me niet waarom..

Ergens -> http://en.wikipedia.org/wiki/Iptables

[ Voor 9% gewijzigd door Verwijderd op 27-09-2007 14:19 ]

[Verwijderd]

Pak tcpdump er eens bij. Hang dit aan je externe interface. Kijk waar het verkeer naartoe gaat. Gaat dit naar localhost of ergens anders naartoe? Hang daarna tcpdump aan je lo0 en herhaal deze stappen. Hoe wordt de verbinding op dit moment door je firewall heen gerouteert?

Sowiso is het mij vrij onduidelijk wat je nou wel en niet werkend hebt. Tevens, wat is het probleem wat je probeert op te lossen?

[Verwijderd]

Dit gebeurt er als ik http://server:1977 http://server:80 benader

Met de drop 80 rule kan ik niet bij 1977 en 80, zonder die rule kan ik beide benader.

code:

tcpdump -i eth0 port ! 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:32:25.112855 IP 192.168.0.159.4221 > 192.168.0.200.http: S 3124623723:3124623723(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:25.113251 IP 192.168.0.200.32875 > 192.168.0.1.domain:  17686+ PTR? 200.0.168.192.in-addr.arpa. (44)
14:32:25.127097 IP 192.168.0.1.domain > 192.168.0.200.32875:  17686 NXDomain 0/1/0 (121)
14:32:25.127176 IP 192.168.0.200.32875 > 192.168.0.1.domain:  35794+ PTR? 159.0.168.192.in-addr.arpa. (44)
14:32:25.144933 IP 192.168.0.1.domain > 192.168.0.200.32875:  35794 NXDomain* 0/1/0 (141)
14:32:25.145014 IP 192.168.0.200.32875 > 192.168.0.1.domain:  33776+ PTR? 1.0.168.192.in-addr.arpa. (42)
14:32:25.157778 IP 192.168.0.1.domain > 192.168.0.200.32875:  33776 NXDomain 0/1/0 (119)
14:32:27.047349 IP 192.168.0.159.4222 > 192.168.0.200.tcoaddressbook: S 1178912744:1178912744(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:28.054369 IP 192.168.0.159.4221 > 192.168.0.200.http: S 3124623723:3124623723(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:29.913761 IP 192.168.0.159.4222 > 192.168.0.200.tcoaddressbook: S 1178912744:1178912744(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:30.113482 arp who-has 192.168.0.1 tell 192.168.0.200
14:32:30.113622 arp reply 192.168.0.1 is-at 00:19:5b:95:b6:fa (oui Unknown)
14:32:31.175327 arp who-has 192.168.0.20 (Broadcast) tell 192.168.0.1
14:32:31.175462 IP 192.168.0.200.32875 > 192.168.0.1.domain:  28049+ PTR? 20.0.168.192.in-addr.arpa. (43)
14:32:31.195593 IP 192.168.0.1.domain > 192.168.0.200.32875:  28049 NXDomain* 0/1/0 (120)
14:32:34.069948 IP 192.168.0.159.4221 > 192.168.0.200.http: S 3124623723:3124623723(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:35.929298 IP 192.168.0.159.4222 > 192.168.0.200.tcoaddressbook: S 1178912744:1178912744(0) win 64512 <mss 1460,nop,nop,sackOK>
14:32:45.760389 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 101
14:32:45.760514 IP 192.168.0.200.32875 > 192.168.0.1.domain:  39693+ PTR? 250.255.255.239.in-addr.arpa. (46)
14:32:45.778303 IP 192.168.0.1.domain > 192.168.0.200.32875:  39693 NXDomain 0/1/0 (103)
14:32:52.805696 IP 192.168.0.200.ntp > chime5.surfnet.nl.ntp: NTPv4, Client, length 48
14:32:52.805826 IP 192.168.0.200.32875 > 192.168.0.1.domain:  63457+ PTR? 130.167.171.194.in-addr.arpa. (46)
14:32:52.821858 IP chime5.surfnet.nl.ntp > 192.168.0.200.ntp: NTPv4, Server, length 48
14:32:52.828878 IP 192.168.0.1.domain > 192.168.0.200.32875:  63457* 1/3/2 (179)
14:32:59.042296 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 283
14:32:59.050080 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 335
14:32:59.056520 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 349
14:32:59.062894 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 347
14:32:59.070206 IP 192.168.0.20.http-alt > 239.255.255.250.ssdp: UDP, length 292
14:33:01.003044 arp who-has 192.168.0.159 (Broadcast) tell 192.168.0.1
14:33:31.179789 arp who-has 192.168.0.20 (Broadcast) tell 192.168.0.1

[Verwijderd]

Ik weet niet of netfilter het kan, maar probeer de onderstaande twee regels eens? Op dit moment komt verkeer binnen op eth0:1977, en dat redirect naar eth0:80. Op het moment dat jij poort 80 dichtzet, dan werkt de redirect rule ook niet meer. Op het moment dat je eth0:1977 redirect naar lo0:80, dan zou het wel moeten werken, mits je rules hebt die poort 80 toestaan op lo0.

code:

-A PREROUTING -p tcp -m tcp ! -i lo --dport 1977 -j REDIRECT --to-ports 127.0.0.1:80
-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 127.0.0.1:80

Nogmaals, geen idee of netfilter dit kan. PF kan dit iig wel

offtopic:
en het volgende geeft iets duidelijkere tcpdump output
tcpdump -ni eth0 port 1977 or port 80

[ Voor 9% gewijzigd door Verwijderd op 27-09-2007 14:50 ]

[Verwijderd]

Verwijderd schreef op donderdag 27 september 2007 @ 14:49:

code:

-A PREROUTING -p tcp -m tcp ! -i lo --dport 1977 -j REDIRECT --to-ports 127.0.0.1:80
-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 127.0.0.1:80

Nogmaals, geen idee of netfilter dit kan. PF kan dit iig wel

Geen error, maar ook geen resultaat.
Met ipf zou ik er ook wel uitkomen, daarom kan er met mijn kop niet bij dat het niet wil werken......

[Verwijderd]

Zie je nu ook dat packets naar 127.0.0.1 geredirect worden of eindigen ze nog steeds op eth0?

[Verwijderd]

15:16:48.150249 IP 192.168.0.159.varadero-1 > 192.168.0.200.http: S 3488500576:3488500576(0) win 64512 <mss 1460,nop,nop,sackOK>
15:16:49.837147 IP 192.168.0.159.varadero-2 > 192.168.0.200.tcoaddressbook: S 273106967:273106967(0) win 64512 <mss 1460,nop,nop,sackOK>
15:16:51.129026 IP 192.168.0.159.varadero-1 > 192.168.0.200.http: S 3488500576:3488500576(0) win 64512 <mss 1460,nop,nop,sackOK>
15:16:52.838976 IP 192.168.0.159.varadero-2 > 192.168.0.200.tcoaddressbook: S 273106967:273106967(0) win 64512 <mss 1460,nop,nop,sackOK>
15:16:57.164148 IP 192.168.0.159.varadero-1 > 192.168.0.200.http: S 3488500576:3488500576(0) win 64512 <mss 1460,nop,nop,sackOK>
15:16:58.773521 IP 192.168.0.159.varadero-2 > 192.168.0.200.tcoaddressbook: S 273106967:273106967(0) win 64512 <mss 1460,nop,nop,sackOK>


jammer

[Verwijderd]

Zou je ons een plezier willen doen en de -n flag mee willen geven aan tcpdump? De port namen worden dan niet geresolved, waardoor wij gewoon zien hoe het verkeer loopt zonder dat we in /etc/services hoeven te kijken

Overigens denk ik wel dat hier je probleem zit. Eg, ff uitzoeken hoe je netfilter zover kan krijgen dat ie naar localhost redirect. Ter info (en om alle netfilter homies hier te dissen ), hieronder de statements die dit doen onder PF:

code:

rdr pass inet proto tcp from any to $ext_nic port 1977 -> 127.0.0.1 port 80

[ Voor 5% gewijzigd door Verwijderd op 27-09-2007 15:22 ]

[Verwijderd]

Die -n zit erin : tcpdump -ni eth0 port 1977 or port 80

ipf : rdr ed1 mijipadres/32 port 1977 -> 127.0.0.1 port 180 tcp (ik had iets meer verwacht van de netfilter, of ben al verpest en te oud om te leren)

[ Voor 54% gewijzigd door Verwijderd op 27-09-2007 15:33 ]

[Verwijderd]

Probeer dit eens:

code:

-A PREROUTING ! -i lo0 -p tcp --dport 1977 -j DNAT --to localhost:80

offtopic:
Met dank aan tehmaze

[Verwijderd]

:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp ! -i lo --dport 1977 -j DNAT --to-destination 127.0.0.1:80
-A OUTPUT -p tcp -m tcp --dport 1977 -j REDIRECT --to-ports 127.0.0.1:80
COMMIT

Gedaan, niet echt de oplossing