All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Schulman <andrex-cmaem7PIVQQM4YKboWzA4l6hYfS7NtTn@public.gmane.org>
To: netfilter-wool9L35kiczKOhml7GhPkB+6BGkLq7r@public.gmane.org
Subject: Re: Blocking source ports after REDIRECT
Date: Wed, 14 Apr 2004 13:03:38 -0400	[thread overview]
Message-ID: <MPG.1ae738f53f9a4d349896ad@localhost> (raw)
In-Reply-To: 407D69F3.8050105@turton.co.za

> I am running an untrusted web/app server and mail server on a Linux 
> server, and choose to run then as non-root.  The apps must therefore use 
> ports other than the well-known privileged ones.  I have set up iptables 
> to redirect client requests addressed to the well-known ports to the 
> ports that these apps open, e.g.
>  25 -> 8025
>  80 -> 8080
> 110 -> 8110
> This works fine.  Out of obsessive neatness rather than for any good 
> technical reason I would like to block direct access to the apps through 
> their non-privileged (8xxx) ports.  When I insert a filter command to do 
> this, it blocks the redirected traffic as well.  Does anyone have a 
> suggestion for me?  The commands are listed below, with the one that 
> breaks connectivity commented out with ##
> 
> Regards
> Trevor Turton
> 
> #!/bin/bash
> ###############################################################################
> # This script redirects various well-known services to local 
> unprivileged ports
> # and block the other privileged ports.
> # 2004-04-13 Trevor Turton
> ###############################################################################
> #
> # turn on IP forwarding:
> #
> echo 1 > /proc/sys/net/ipv4/ip_forward
> #
> # redirect well-known services' ports to local unprivileged ports
> #
> /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 25  -j 
> REDIRECT --to-ports 8025
> /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80  -j 
> REDIRECT --to-ports 8080
> /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 110 -j 
> REDIRECT --to-ports 8110
> /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 443 -j 
> REDIRECT --to-ports 8443
> #
> # accept traffic addressed to the serviced tcp ports
> #
> /sbin/iptables -A INPUT -p tcp --dport 22  -j ACCEPT
> /sbin/iptables -A INPUT -p tcp --dport 25  -j ACCEPT
> /sbin/iptables -A INPUT -p tcp --dport 80  -j ACCEPT
> /sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
> /sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT
> #
> # filter out traffic to remaining privileged tcp ports
> #
> /sbin/iptables -A INPUT -p tcp -i eth0 --dport 0:1023 -j DROP
> ## the following command blocks -eth0 --dport 25,80,110,443 as well!!
> ## /sbin/iptables -A INPUT -p tcp -i eth0 --dport 8000:8443 -j DROP
> #
> # accept traffic to serviced udp port (dns)
> #
> /sbin/iptables -A INPUT -p udp --dport 53  -j ACCEPT
> #
> # filter out traffic to remaining privileged udp ports
> #
> /sbin/iptables -A INPUT -p udp -i eth0 --dport 0:1023 -j DROP

See if this makes sense:

Your port REDIRECTion happens in the PREROUTING table, _before_ the 
packets reach the INPUT table.  See the diagram at 
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-
6.html.  So your INPUT rules never match: by the time a packet addressed 
to, say, port 110 arrives there, its destination port has already been 
changed to 8110.  So the ACCEPT rule on port 110 doesn't match.  Instead 
the packet falls through to your DROP rule, where it gets clobbered.



  reply	other threads:[~2004-04-14 17:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-14 16:42 Blocking source ports after REDIRECT Trevor Turton
2004-04-14 17:03 ` Andrew Schulman [this message]
2004-04-14 17:04 ` Antony Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MPG.1ae738f53f9a4d349896ad@localhost \
    --to=andrex-cmaem7pivqqm4ykbowza4l6hyfs7nttn@public.gmane.org \
    --cc=netfilter-wool9L35kiczKOhml7GhPkB+6BGkLq7r@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.