Re: bind mountd to a specified port
On Thu, 18 Oct 2012 19:11:37 +0200
"Sebastian Reitenbach" wrote:
> getting NFS through a firewall is not that trivial with mountd binding to a
> random port each time it starts.
Hi,
here is how I solved it after my proposal for a fixed-port-option was
rejected:
/etc/rc.local:
[...]
# register (random) rpc ports to pf anchor
rpcinfo -p localhost \
|awk \
'
/tcp/ \
{printf "pass in proto %s to port %d\n", $3, $4}
/udp/ \
{printf "pass in proto %s to port %d\n", $3, $4; \
printf "pass out proto %s from port %d\n", $3, $4}
' \
|pfctl -a rpc -f -
[...]
/etc/pf.conf:
# NFS
# rpc daemons use more or less random ports; they will be put into this anchor
anchor "rpc" on {tun0 lo0} from to (self)
anchor "rpc" on {tun0 lo0} from (self) to
# local daemons need access to portmap before the rpc anchor is populated
pass in on lo0 inet proto {udp tcp} from localhost to localhost port portmap
Re: bind mountd to a specified port
Am Donnerstag, 18. Oktober 2012 20:50 CEST, Bob Beck schrieb: > > Anyways, since in my case, I only need a read-only export, I can also go > > with sharing the files via http. > > Both networks that are separated with the firewall, have about the same > > trust level. > > So now someone could argue, why the hell a firewall in there at all, but > > that's a different topic ;) > > > > So let me shut up and forget about it. > > Essentially at that point, allowing the RPC range in from your http > servers to your read only NFS server across the firewall doesn't > really have any different impact than doing it only with one port. > More importantly, having the rules there saying "for NFS export" are a > nice glaring thing reminding people about the "why the hell have a > firewall there at all" issue so it could eventually be solved. > > Personally I've always done this with the read only nfs server > *outside* sharing to the http servers, and an internal server that all > the changes are made on, with a > "publish" mechanism (script, or button that runs a script, or even a > cron job) that rsync's changes from the internal server to the > external server via ssh.. > > You can then have a tiny little http server on the inside, visible > only to the inside. for your people to vet the changes before > publishing them. > > Then you only need to allow ssh outbound to rsync the content out, and > your firewall might do something meaningful :) I did not really explained my use-case in the first place, which I probably should do before I really shut up ;) What I'm doing on the NFS server is mirroring installation sources for some Linux distribution in order to have them locally available. In order to not have multiple copies for each network, I need to make them somehow available there. The firewall sits in the middle. My plan was to use export the drive read-only into the other networks, nobody needs to write on it. For my use-case, I can also use http server to accomplish the same. Why NFS in the first place? Its the same way I do it on other places, but from a Linux server, therefore I had a bit of consistency in mind, and wanted to do it the same way here. But as said, for my use case, I can also switch to http to get to the same result. thanks, Sebastian > > -Bob
Re: bind mountd to a specified port
> On Thu, Oct 18, 2012, at 12:17 PM, Theo de Raadt wrote: > > As you note, this has come up before, and the same reasons exist then > > as now. > > > > The security model makes no sense: firewall, but allow NFS. > > It may make no sense to you, but that doesn't mean it makes no sense to > everyone, especially those with setups where this is the only way to > accomplish the desired goal. Right and we should bring telnetd back, since it makes sense in some setups to accomplish the desired goal. As developers we make decisions which we believe serve our users the best. In this project that often includes blocking our users from building foolish and insecure configurations too easily. Or at all, if the configuration is particularily ridiculous. This is an policy decision that is different between OpenBSD and other operating systems. In OpenBSD, IP port randomization is a mandatory part of the system. We do not provide workarounds -- especially deep inside the RPC layer of libc. Every time those kinds of things are used by people, they are creating deep security problems way outside their scope to assess the impact. This one specific case is no different from other cases where we have make similar decisions. These decisions we make come as a package of decisions. If you don't like them, there are other operating systems to run. They come with different decisisions, once again, as a package of decisions. That's the way it is. Sorry.
Re: bind mountd to a specified port
On Thu, Oct 18, 2012, at 12:17 PM, Theo de Raadt wrote: > As you note, this has come up before, and the same reasons exist then > as now. > > The security model makes no sense: firewall, but allow NFS. It may make no sense to you, but that doesn't mean it makes no sense to everyone, especially those with setups where this is the only way to accomplish the desired goal. Put another way, it makes as much sense as firewall, but allow SMB, or even allow SSH, FTP, or HTTP. -- Shawn K. Quinn skqu...@rushpost.com
Re: bind mountd to a specified port
> Anyways, since in my case, I only need a read-only export, I can also go with > sharing the files via http. > Both networks that are separated with the firewall, have about the same trust > level. > So now someone could argue, why the hell a firewall in there at all, but > that's a different topic ;) > > So let me shut up and forget about it. Essentially at that point, allowing the RPC range in from your http servers to your read only NFS server across the firewall doesn't really have any different impact than doing it only with one port. More importantly, having the rules there saying "for NFS export" are a nice glaring thing reminding people about the "why the hell have a firewall there at all" issue so it could eventually be solved. Personally I've always done this with the read only nfs server *outside* sharing to the http servers, and an internal server that all the changes are made on, with a "publish" mechanism (script, or button that runs a script, or even a cron job) that rsync's changes from the internal server to the external server via ssh.. You can then have a tiny little http server on the inside, visible only to the inside. for your people to vet the changes before publishing them. Then you only need to allow ssh outbound to rsync the content out, and your firewall might do something meaningful :) -Bob
Re: bind mountd to a specified port
Am Donnerstag, 18. Oktober 2012 19:17 CEST, Theo de Raadt schrieb: > As you note, this has come up before, and the same reasons exist then > as now. > > The security model makes no sense: firewall, but allow NFS. Yes, its not optimal ;) Before with my search, I only found the one I pointed out, now I searched further, and I found the thread: http://old.nabble.com/mountd%3A-user-specified-port-td32147473.html#a32151940 reading up that, I see good points in the arguments from Christopher Zimmerman. Anyways, since in my case, I only need a read-only export, I can also go with sharing the files via http. Both networks that are separated with the firewall, have about the same trust level. So now someone could argue, why the hell a firewall in there at all, but that's a different topic ;) So let me shut up and forget about it. cheers, Sebastian > > > getting NFS through a firewall is not that trivial with mountd binding to a > > random port each time it starts. > > The patch below allows to specify a port which mountd will use. > > > > The idea and the patch is not from me. 99% is based on an old patch > > submitted to tech@ in 2007: > > http://old.nabble.com/-PATCH--mountd-to-listen-to-specified-port-td11075352.html > > The patch did not got much attention at that time, hope for a bit more now > > ;) > > > > Only one or two minor tweaks were necessary to bring it to compile without > > warnings. > > Tested and works well for me on i386/amd64. > > > > comments, rants or even test reports are welcome. > > > > cheers, > > Sebastian > > > > > > Index: include/rpc/svc.h > > === > > RCS file: /cvs/src/include/rpc/svc.h,v > > retrieving revision 1.12 > > diff -u -r1.12 svc.h > > --- include/rpc/svc.h 1 Sep 2010 14:43:34 - 1.12 > > +++ include/rpc/svc.h 17 Oct 2012 10:33:06 - > > @@ -305,6 +305,9 @@ > > __BEGIN_DECLS > > extern SVCXPRT *svcudp_create(int); > > extern SVCXPRT *svcudp_bufcreate(int, unsigned int, unsigned int); > > +extern SVCXPRT *svcudp_create2(int, int, u_short); > > +extern SVCXPRT *svcudp_bufcreate2(int, int, u_short, unsigned int, > > + unsigned int); > > __END_DECLS > > > > > > @@ -313,6 +316,7 @@ > > */ > > __BEGIN_DECLS > > extern SVCXPRT *svctcp_create(int, unsigned int, unsigned int); > > +extern SVCXPRT *svctcp_create2(int, int, u_short, unsigned int, unsigned > > int); > > __END_DECLS > > > > /* > > Index: lib/libc/rpc/rpc.3 > > === > > RCS file: /cvs/src/lib/libc/rpc/rpc.3,v > > retrieving revision 1.45 > > diff -u -r1.45 rpc.3 > > --- lib/libc/rpc/rpc.3 27 Sep 2012 11:31:58 - 1.45 > > +++ lib/libc/rpc/rpc.3 17 Oct 2012 10:33:11 - > > @@ -52,7 +52,7 @@ > > .\" NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > > .\" OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > .\" > > -.Dd $Mdocdate: September 27 2012 $ > > +.Dd $Mdocdate: October 15 2012 $ > > .Dt RPC 3 > > .Os > > .Sh NAME > > @@ -109,8 +109,12 @@ > > .Nm svcfd_create , > > .Nm svcraw_create , > > .Nm svctcp_create , > > +.Nm svctcp_create2 , > > .Nm svcudp_create , > > .Nm svcudp_bufcreate , > > +.Nm svcudp_bufcreate2 , > > +.Nm svcudp_create , > > +.Nm svcudp_create2 , > > .Nm xdr_accepted_reply , > > .Nm xdr_authunix_parms , > > .Nm xdr_callhdr , > > @@ -234,11 +238,19 @@ > > .Ft SVCXPRT * > > .Fn svctcp_create "int sock" "u_int send_buf_size" "u_int recv_buf_size" > > .Ft SVCXPRT * > > +.Fn svctcp_create2 "int sock" "int family" "u_short port" "u_int > > send_buf_size" "u_int recv_buf_size" > > +.Ft SVCXPRT * > > .Fn svcfd_create "int fd" "u_int sendsize" "u_int recvsize" > > .Ft SVCXPRT * > > .Fn svcudp_create "int sock" > > .Ft SVCXPRT * > > .Fn svcudp_bufcreate "int sock" "u_int sendsz" "u_int recvsz" > > +.Ft SVCXPRT * > > +.Fn svcudp_bufcreate2 "int sock" "int family" "u_short port" "u_int > > sendsz" "u_int recvsz" > > +.Ft SVCXPRT * > > +.Fn svcudp_create "int sock" > > +.Ft SVCXPRT * > > +.Fn svcudp_create2 "int sock" "int family" "u_short port" > > .Ft bool_t > > .Fn xdr_accepted_reply "XDR *xdrs" "struct accepted_reply *ar" > > .Ft bool_t > > @@ -1096,6 +1108,13 @@ > > users may specify the size of buffers; values of zero > > choose suitable defaults. > > .Pp > > +.Fn svctcp_create2 > > +supersedes > > +.Fn svctcp_create > > +function. It allows to specify address family and port number also. This > > +function accepts AF_INET and AF_INET6 address families. If port is equal > > to 0, > > +the function tries to bind socket to one of reserved ports. > > +.Pp > > .Fn svcfd_create > > will create a service on top of any open descriptor. > > Typically, this descriptor is a connected socket for a stream protocol such > > @@ -1131,6 +1150,13 @@ > > except that it allows the user to specify the maximum packet size for >
Re: bind mountd to a specified port
As you note, this has come up before, and the same reasons exist then
as now.
The security model makes no sense: firewall, but allow NFS.
> getting NFS through a firewall is not that trivial with mountd binding to a
> random port each time it starts.
> The patch below allows to specify a port which mountd will use.
>
> The idea and the patch is not from me. 99% is based on an old patch submitted
> to tech@ in 2007:
> http://old.nabble.com/-PATCH--mountd-to-listen-to-specified-port-td11075352.html
> The patch did not got much attention at that time, hope for a bit more now ;)
>
> Only one or two minor tweaks were necessary to bring it to compile without
> warnings.
> Tested and works well for me on i386/amd64.
>
> comments, rants or even test reports are welcome.
>
> cheers,
> Sebastian
>
>
> Index: include/rpc/svc.h
> ===
> RCS file: /cvs/src/include/rpc/svc.h,v
> retrieving revision 1.12
> diff -u -r1.12 svc.h
> --- include/rpc/svc.h 1 Sep 2010 14:43:34 - 1.12
> +++ include/rpc/svc.h 17 Oct 2012 10:33:06 -
> @@ -305,6 +305,9 @@
> __BEGIN_DECLS
> extern SVCXPRT *svcudp_create(int);
> extern SVCXPRT *svcudp_bufcreate(int, unsigned int, unsigned int);
> +extern SVCXPRT *svcudp_create2(int, int, u_short);
> +extern SVCXPRT *svcudp_bufcreate2(int, int, u_short, unsigned int,
> + unsigned int);
> __END_DECLS
>
>
> @@ -313,6 +316,7 @@
> */
> __BEGIN_DECLS
> extern SVCXPRT *svctcp_create(int, unsigned int, unsigned int);
> +extern SVCXPRT *svctcp_create2(int, int, u_short, unsigned int, unsigned
> int);
> __END_DECLS
>
> /*
> Index: lib/libc/rpc/rpc.3
> ===
> RCS file: /cvs/src/lib/libc/rpc/rpc.3,v
> retrieving revision 1.45
> diff -u -r1.45 rpc.3
> --- lib/libc/rpc/rpc.327 Sep 2012 11:31:58 - 1.45
> +++ lib/libc/rpc/rpc.317 Oct 2012 10:33:11 -
> @@ -52,7 +52,7 @@
> .\" NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> .\" OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> .\"
> -.Dd $Mdocdate: September 27 2012 $
> +.Dd $Mdocdate: October 15 2012 $
> .Dt RPC 3
> .Os
> .Sh NAME
> @@ -109,8 +109,12 @@
> .Nm svcfd_create ,
> .Nm svcraw_create ,
> .Nm svctcp_create ,
> +.Nm svctcp_create2 ,
> .Nm svcudp_create ,
> .Nm svcudp_bufcreate ,
> +.Nm svcudp_bufcreate2 ,
> +.Nm svcudp_create ,
> +.Nm svcudp_create2 ,
> .Nm xdr_accepted_reply ,
> .Nm xdr_authunix_parms ,
> .Nm xdr_callhdr ,
> @@ -234,11 +238,19 @@
> .Ft SVCXPRT *
> .Fn svctcp_create "int sock" "u_int send_buf_size" "u_int recv_buf_size"
> .Ft SVCXPRT *
> +.Fn svctcp_create2 "int sock" "int family" "u_short port" "u_int
> send_buf_size" "u_int recv_buf_size"
> +.Ft SVCXPRT *
> .Fn svcfd_create "int fd" "u_int sendsize" "u_int recvsize"
> .Ft SVCXPRT *
> .Fn svcudp_create "int sock"
> .Ft SVCXPRT *
> .Fn svcudp_bufcreate "int sock" "u_int sendsz" "u_int recvsz"
> +.Ft SVCXPRT *
> +.Fn svcudp_bufcreate2 "int sock" "int family" "u_short port" "u_int sendsz"
> "u_int recvsz"
> +.Ft SVCXPRT *
> +.Fn svcudp_create "int sock"
> +.Ft SVCXPRT *
> +.Fn svcudp_create2 "int sock" "int family" "u_short port"
> .Ft bool_t
> .Fn xdr_accepted_reply "XDR *xdrs" "struct accepted_reply *ar"
> .Ft bool_t
> @@ -1096,6 +1108,13 @@
> users may specify the size of buffers; values of zero
> choose suitable defaults.
> .Pp
> +.Fn svctcp_create2
> +supersedes
> +.Fn svctcp_create
> +function. It allows to specify address family and port number also. This
> +function accepts AF_INET and AF_INET6 address families. If port is equal to
> 0,
> +the function tries to bind socket to one of reserved ports.
> +.Pp
> .Fn svcfd_create
> will create a service on top of any open descriptor.
> Typically, this descriptor is a connected socket for a stream protocol such
> @@ -1131,6 +1150,13 @@
> except that it allows the user to specify the maximum packet size for sending
> and receiving UDP-based RPC
> messages instead of using the default size limit of 8800 bytes.
> +.Pp
> +.Fn svcudp_bufcreate2
> +supersedes
> +.Fn svcudp_bufcreate
> +function. It allows to specify address family and port number also. This
> +function accepts AF_INET and AF_INET6 address families. If port is equal to
> 0,
> +the function tries to bind socket to one of reserved ports.
> .Pp
> .Fn xdr_accepted_reply
> is used for encoding RPC reply messages.
> Index: lib/libc/rpc/svc_tcp.c
> ===
> RCS file: /cvs/src/lib/libc/rpc/svc_tcp.c,v
> retrieving revision 1.30
> diff -u -r1.30 svc_tcp.c
> --- lib/libc/rpc/svc_tcp.c1 Sep 2010 14:43:34 - 1.30
> +++ lib/libc/rpc/svc_tcp.c17 Oct 2012 10:33:12 -
> @@ -136,7 +136,7 @@
>
> if (sock == RPC_ANYSOCK) {
> if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
> - perro
