Re: nc in inetd - under which account?
On 2017-06-07, Marko Cupać wrote: > Now as for relayd, I never used it. If someone gave me working example > and an explanation why it is better than my current solution, I'd be > glad to switch, and pass the word around :) When your proxy is nc run from inetd, you have to fork when answering each connection, and the timeout handling using -w is a complete bodge. relayd uses a pool of pre-forked processes (quicker connection setup), and once the connection is setup "socket splicing" is used so shunting packets between connections is more efficient (zero copy). But unless you need relayd features (adjusting tcp parameters, checking that backends are up, etc) it's lighter-weight again to just keep it in the kernel by using PF as I described.
Re: nc in inetd - under which account?
First result on Google for "relayd example" seems to be pretty thorough. https://calomel.org/relayd.html On Wed, Jun 7, 2017 at 7:51 AM, Marko Cupać wrote: > On Tue, 6 Jun 2017 12:05:10 -0500 > Ax0n wrote: > > > Also, this seems like something that, depending on where the > > destination servers are, could be handled easily with PF by itself, > > or with the help of relayd, with a lot less hassle. > > Perhaps I didn't explain what I use this for. I have a vlan on private > subnet, which has no access to other private vlans - it can contact > only Internet hosts. One of "Internet" hosts is actually IP alias on > external interface of my OpenBSD firewall, which redirects (rdr-to) > internal host on my LAN: > > pass in on $if_ext inet proto tcp from any to $pub_srv port $web \ >rdr-to $priv_srv > > Now, as redirection happens to packets which are incoming to external > interface, above rule does not hit for packets coming from internal > vlan. > > That's why I combine pf redirection on internal interface to > loopback: > pass in quick on $if_int inet proto tcp from to $pub_srv \ >port 80 rdr-to 127.0.0.1 port 20080 > pass in quick on $if_int inet proto tcp from to $pub_srv \ >port 443 rdr-to 127.0.0.1 port 20443 > > ... and proxy these packets with nc from inetd: > 127.0.0.1:20080 stream tcp nowait _nc_proxy /usr/bin/nc \ >srv-http -w 20 PRI.VAT.EAD.DR 80 > 127.0.0.1:20443 stream tcp nowait _nc_proxy /usr/bin/nc \ >srv-https -w 20 PRI.VAT.EAD.DR 443 > > I know that simple rdr on internal interface doesn't work out of the > box - I would probably need some kind of NAT, as LAN server wouldn't > return packet to firewall from where it was redirected - it would try > to contact LAN client directly, and fail (isolated VLAN). > > Now as for relayd, I never used it. If someone gave me working example > and an explanation why it is better than my current solution, I'd be > glad to switch, and pass the word around :) > > Thank you all for tips and hints. > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > > Marko Cupać > https://www.mimar.rs/ > >
Re: nc in inetd - under which account?
On Tue, 6 Jun 2017 12:05:10 -0500 Ax0n wrote: > Also, this seems like something that, depending on where the > destination servers are, could be handled easily with PF by itself, > or with the help of relayd, with a lot less hassle. Perhaps I didn't explain what I use this for. I have a vlan on private subnet, which has no access to other private vlans - it can contact only Internet hosts. One of "Internet" hosts is actually IP alias on external interface of my OpenBSD firewall, which redirects (rdr-to) internal host on my LAN: pass in on $if_ext inet proto tcp from any to $pub_srv port $web \ rdr-to $priv_srv Now, as redirection happens to packets which are incoming to external interface, above rule does not hit for packets coming from internal vlan. That's why I combine pf redirection on internal interface to loopback: pass in quick on $if_int inet proto tcp from to $pub_srv \ port 80 rdr-to 127.0.0.1 port 20080 pass in quick on $if_int inet proto tcp from to $pub_srv \ port 443 rdr-to 127.0.0.1 port 20443 ... and proxy these packets with nc from inetd: 127.0.0.1:20080 stream tcp nowait _nc_proxy /usr/bin/nc \ srv-http -w 20 PRI.VAT.EAD.DR 80 127.0.0.1:20443 stream tcp nowait _nc_proxy /usr/bin/nc \ srv-https -w 20 PRI.VAT.EAD.DR 443 I know that simple rdr on internal interface doesn't work out of the box - I would probably need some kind of NAT, as LAN server wouldn't return packet to firewall from where it was redirected - it would try to contact LAN client directly, and fail (isolated VLAN). Now as for relayd, I never used it. If someone gave me working example and an explanation why it is better than my current solution, I'd be glad to switch, and pass the word around :) Thank you all for tips and hints. -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: nc in inetd - under which account?
On 2017-06-06, Marko Cupać wrote: > Hi, > > For a few years I have been running nc from inetd together with pf > redirect rules to reach LAN servers via their public IP adresses from > LAN: > > # cat /etc/inetd.conf > 127.0.0.1:20080 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 80 > 127.0.0.1:20443 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 443 > > Now that proxy user is gone in 6.1, what would be appropriate account to > run nc under? Is nobody OK? Something else? > > Or is there a better way to accomplish this? There's no need to do this in userland, a combination of nat-to and rdr-to works fine for this. Check faq/pf/rdr.html if you need hints.
Re: nc in inetd - under which account?
Also, this seems like something that, depending on where the destination servers are, could be handled easily with PF by itself, or with the help of relayd, with a lot less hassle. On Tue, Jun 6, 2017 at 11:23 AM, Maximilian Pichler wrote: > On Tue, Jun 6, 2017 at 11:06 AM, Marko Cupać wrote: > > On Tue, 06 Jun 2017 08:18:15 -0600 > > "Theo de Raadt" wrote: > >> Never reuse a user intended for another purpose. > >> > >> Take a glance at the ptrace manual page. > > > I have read ptrace manual. But I guess I need to read much MUCH more if > > I want to comprehend it :) > > I'm guessing the point here is that ptrace can be used to eavesdrop on > processes of the same user id. So if the proxy user got compromised, > an attacker could not just kill the nc processes, but also read the > data they are forwarding. > >
Re: nc in inetd - under which account?
On Tue, Jun 6, 2017 at 11:06 AM, Marko Cupać wrote: > On Tue, 06 Jun 2017 08:18:15 -0600 > "Theo de Raadt" wrote: >> Never reuse a user intended for another purpose. >> >> Take a glance at the ptrace manual page. > I have read ptrace manual. But I guess I need to read much MUCH more if > I want to comprehend it :) I'm guessing the point here is that ptrace can be used to eavesdrop on processes of the same user id. So if the proxy user got compromised, an attacker could not just kill the nc processes, but also read the data they are forwarding.
Re: nc in inetd - under which account?
On Tue, 06 Jun 2017 08:18:15 -0600 "Theo de Raadt" wrote: > > For a few years I have been running nc from inetd together with pf > > redirect rules to reach LAN servers via their public IP adresses > > from LAN: > > > > # cat /etc/inetd.conf > > 127.0.0.1:20080 stream tcp nowait proxy /usr/bin/nc nc -w 20 > > PR.IV.AT.E 80 127.0.0.1:20443 stream tcp nowait proxy /usr/bin/nc > > nc -w 20 PR.IV.AT.E 443 > > > > Now that proxy user is gone in 6.1, what would be appropriate > > account to run nc under? Is nobody OK? Something else? > > > > Or is there a better way to accomplish this? > > A user of your own you create. > > Never reuse a user intended for another purpose. > > Take a glance at the ptrace manual page. > Thank you for your help. I created dedicated user for this purpose, taking _ftp_proxy as starting point: _nc_proxy:*:20080:20080::0:0:NC Proxy Daemon:/nonexistent:/sbin/nologin I have read ptrace manual. But I guess I need to read much MUCH more if I want to comprehend it :) Best regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: nc in inetd - under which account?
> For a few years I have been running nc from inetd together with pf > redirect rules to reach LAN servers via their public IP adresses from > LAN: > > # cat /etc/inetd.conf > 127.0.0.1:20080 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 80 > 127.0.0.1:20443 stream tcp nowait proxy /usr/bin/nc nc -w 20 PR.IV.AT.E 443 > > Now that proxy user is gone in 6.1, what would be appropriate account to > run nc under? Is nobody OK? Something else? > > Or is there a better way to accomplish this? A user of your own you create. Never reuse a user intended for another purpose. Take a glance at the ptrace manual page.