AW: [suse-security] Port forwarding problem
Hi John, first of all thx for your reply. Well, there's nothing wrong with my rules. Except your remarks on stateful inspection. I do need the seperate NAT rule for outbound traffic otherwise it would be natted to eth0 which then would cause errors on senders firewall (packets are sent to "eth1" (DMZ) address but response will come through "eth0" (FW) address). As expected that's all a "nice hidden security feature" of IIS ;-) No, just kidding. IIS is set up to look for "index.asp" pages if a directory is requested, e.g. "http://our.host:50003/directory". It works for requests on port 80 but not for requests on any other port. Having a detailed look at the packets I saw that suddenly requests are "mangled" to port 80. And these requests are not allowed. So if we put "http://our.host:50003/directory/index.asp" it works as expected. Don't ask me why, I don't mind. I search support.microsoft.com but found nothing mentioned concerning this treatment. I know why I like Apache so much, but that's off topic :-) Have fun, Oliver
-----Ursprüngliche Nachricht----- Von: John Trickey [mailto:lists@g4rev.supanet.com] Gesendet: Dienstag, 4. März 2003 12:59 An: suse-security@suse.com Betreff: Re: [suse-security] Port forwarding problem
Hi Oliver,
I have a firewall problem I have resigned on. I hope there's someone out there who can help me and explain what's wrong.
I do not see much wrong with this.
iptables -A PREROUTING -t nat -p tcp -s 0.0.0.0/0 -d IP_DMZHOST --dport PORTFW -j DNAT --to-destination IP_LAN:80
I have used almost identical rules. I do not bother with -s "any" as its assumed if omitted and I use --to just because its shorter :-). So functionally, there is no difference.
There are 2 areas that may be causing you grief.
1) Have you set up the forward table? You will need iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 -j ACCEPT and also its inverse.
Personally I prefer connection tracking so you can do iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 \ -m state --state NEW -j ACCEPT with a global iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED -j ACCEPT for the return.
2) Have you prevented the return packets from being masqueraded? If not they will be leaving your firewall with a source IP of IP_eth0. You need something like: iptables -t nat -A POSTROUTING -o eth0 -s IP_DMZ -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
"firewalled" or "proxied" connections. Therefore I put the following rule in place which should SNAT the specific traffic coming from IIS.
iptables -I POSTROUTING -t nat -s IP_LAN -d ! 10.0.0.0/8 -j SNAT --to-source IP_DMZHOST
I need "-d ! 10.0.0.0/8" option because of our IPSec VPN. But after applying this rule nothing works.
I'm not surprised. By adding this rule you would be creating a separate NAT entry for the outbound traffic.
In my opinion there must be a general "design" mistake I have made. But I don't know which
I think its only an omission. If you're still stuck, come back to me on the list. Don't use direct mail as this address is a spam trap which throws non list mail straight into /dev/null.
John
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Oliver, That's strange as IIS should have no sight of the original dport. All it should see is a connection to port 80. Hmm, I have IIS running here (ARRGH!) - play time :-) Another possibility is to run squid as a reverse proxy/accelerator. If the DMZ host runs Linux, put it there otherwise you could put it on the firewall but that would lessen its security. The iptables solution still leaves your IIS server open to all the nasty exploits if the bandits find it on your DMZ port. With a squid proxy you terminate the session at the proxy. Squid will then establish a connection to the IIS server and make the request. There is an option to provide URL tranlation between the two sides using a program which simply reads STDIN and puts the translation to STDOUT. You can use this to prevent unacceptable URLs from being passed. I have done this with 2.5 and it will even work where the WAN side is SSL if you install a cert for squid. John
first of all thx for your reply. Well, there's nothing wrong with my rules. Except your remarks on stateful inspection. I do need the seperate NAT rule for outbound traffic otherwise it would be natted to eth0 which then would cause errors on senders firewall (packets are sent to "eth1" (DMZ) address but response will come through "eth0" (FW) address). As expected that's all a "nice hidden security feature" of IIS ;-) No, just kidding. IIS is set up to look for "index.asp" pages if a directory is requested, e.g. "http://our.host:50003/directory". It works for requests on port 80 but not for requests on any other port. Having a detailed look at the packets I saw that suddenly requests are "mangled" to port 80. And these requests are not allowed. So if we put "http://our.host:50003/directory/index.asp" it works as expected. Don't ask me why, I don't mind. I search support.microsoft.com but found nothing mentioned concerning this treatment. I know why I like Apache so much, but that's off topic :-)
Have fun,
Oliver
-----Ursprüngliche Nachricht----- Von: John Trickey [mailto:lists@g4rev.supanet.com] Gesendet: Dienstag, 4. März 2003 12:59 An: suse-security@suse.com Betreff: Re: [suse-security] Port forwarding problem
Hi Oliver,
I have a firewall problem I have resigned on. I hope there's someone out there who can help me and explain what's wrong.
I do not see much wrong with this.
iptables -A PREROUTING -t nat -p tcp -s 0.0.0.0/0 -d IP_DMZHOST --dport PORTFW -j DNAT --to-destination IP_LAN:80
I have used almost identical rules. I do not bother with -s "any" as its assumed if omitted and I use --to just because its shorter :-). So functionally, there is no difference.
There are 2 areas that may be causing you grief.
1) Have you set up the forward table? You will need iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 -j ACCEPT and also its inverse.
Personally I prefer connection tracking so you can do iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 \ -m state --state NEW -j ACCEPT with a global iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED -j ACCEPT for the return.
2) Have you prevented the return packets from being masqueraded? If not they will be leaving your firewall with a source IP of IP_eth0. You need something like: iptables -t nat -A POSTROUTING -o eth0 -s IP_DMZ -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
"firewalled" or "proxied" connections. Therefore I put the following rule in place which should SNAT the specific traffic coming from IIS.
iptables -I POSTROUTING -t nat -s IP_LAN -d ! 10.0.0.0/8 -j SNAT --to-source IP_DMZHOST
I need "-d ! 10.0.0.0/8" option because of our IPSec VPN. But after applying this rule nothing works.
I'm not surprised. By adding this rule you would be creating a separate NAT entry for the outbound traffic.
In my opinion there must be a general "design" mistake I have made. But I don't know which
I think its only an omission. If you're still stuck, come back to me on the list. Don't use direct mail as this address is a spam trap which throws non list mail straight into /dev/null.
John
participants (2)
-
John Trickey -
Schoenwaelder Oliver