Re: nc in inetd - under which account?

2017-06-08 Thread Stuart Henderson
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?

2017-06-07 Thread Ax0n
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?

2017-06-07 Thread Marko Cupać
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?

2017-06-06 Thread Stuart Henderson
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?

2017-06-06 Thread Ax0n
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?

2017-06-06 Thread Maximilian Pichler
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?

2017-06-06 Thread Marko Cupać
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?

2017-06-06 Thread Theo de Raadt
> 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.