[HN Gopher] Restricting network access using Linux Network Names...
___________________________________________________________________
Restricting network access using Linux Network Namespaces
Author : Deeg9rie9usi
Score : 82 points
Date : 2023-05-08 12:31 UTC (10 hours ago)
(HTM) web link (blog.sigma-star.at)
(TXT) w3m dump (blog.sigma-star.at)
| kevincox wrote:
| Something I've wanted to do is run less trusted services on a
| private network but still have the reverse proxy connect to them.
| This way I can be sure that they only way to get to them from the
| outside is via the reverse proxy (which adds authentication).
| However I haven't found a decent way to manage that no network
| access paired with a loopback or similar that can be accessed by
| the reverse proxy.
| [deleted]
| troyjfarrell wrote:
| You've just described Sandstorm. Sandstorm runs instances
| (called grains) of applications in a sandbox. The application
| gets a limited file system and a Cap'n Proto RPC connection to
| the outside world over a unix socket. Sandstorm runs the HTTPS
| server, which turns requests into RPC calls. Sandstorm
| authenticates the users and provides temporary subdomains and
| frames to sandbox the HTML side of it.
|
| https://sandstorm.io/
| ranger_danger wrote:
| OP's comments are all about Sandstorm FYI
| Arnavion wrote:
| Create a veth pair. Move one end of the pair into a network
| namespace. Bind the untrusted service on that end. Have your
| proxy service connect to the other end.
| gdgghhhhh wrote:
| Just share an open FD to a socks proxy with the isolated
| service.
| kevincox wrote:
| This depends on the service itself supporting inheriting
| sockets for proxies. Is this a common feature? Some services
| do support listening socket passing which does solve my
| problem as I can make it listen on a UNIX socket mounted on
| the host and accessible to the reverse proxy but many of the
| lower quality services that I want to give this treatment to
| don't support that either.
| yrro wrote:
| Use socket activation and run your service with
| PrivateNetwork=yes
| SahAssar wrote:
| Can run it in a isolated namespace and communicate with unix
| sockets. If the service does not support listening on sockets
| you can use socat within the namespace to forward from the unix
| socket to a port on lo in the namespace. Most reverse proxies
| can forward to a unix socket.
|
| I've done similar things (and sometimes with a wireguard tunnel
| out to internet) for privacy reasons.
| zrail wrote:
| I have less trusted services all listening on my Tailscale
| network. Network ACLs can then ensure they can't talk to each
| other and the only thing that can talk to them is the reverse
| proxy.
| vaylian wrote:
| This blog post could really use a more specific (basic) example
| how to set up a virtual container network.
| Arnavion wrote:
| Search the internet for combinations of "ip link", "netns",
| "tunnel", "veth". Eg:
|
| - https://adil.medium.com/container-networking-under-the-
| hood-...
|
| - https://www.redhat.com/sysadmin/net-namespaces
| koprulusector wrote:
| This part is so cool:
|
| >Please note that network namespaces, actually Linux namespaces
| in general, have no influence on existing file handles.
| Therefore, if your application possesses a file handle to a
| socket from another network namespace, it can use it in the new
| network namespace smoothly.
|
| >This is a useful feature as it allows creating network servers
| that can serve a listening socket but are disconnected from the
| outside world. If an attacker manages to overtake the
| application, they are unable to create a new socket. Here you can
| find a sample application that outlines the idea.
| LoganDark wrote:
| I always find stuff like this cool. Being able to still use the
| resources you acquired before you dropped privileges. Some
| related concepts I also love are capabilities and CHERI[0].
|
| [0]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
| Arnavion wrote:
| As the section at the end says, socket fds work even if the
| process doesn't have access to the underlying network interface
| that they were bound from. A good use of this fact is that it's
| okay to set `PrivateNetwork=yes` for socket-activated systemd
| services.
| CoolCold wrote:
| Wait for ppl come and start claiming you are against UNIX
| philosophy and systemd fanboy :))
| trasz4 wrote:
| Socket activated services first appeared in inetd(8)
| somewhere in the eighties and is as UNIX as it gets :)
| local_crmdgeon wrote:
| I see so much discussion of preventing _local_ escalation, but at
| this point almost all my services run in VMs/on dedicated
| hardware. Superuser powers don't buy you anything extra there.
|
| What I really would like more discussed is _network_ isolation.
| You don't need root to exfiltrate tons of data.
| brasic wrote:
| See this comment: https://news.ycombinator.com/item?id=35862698
|
| If you implement socket activation and use an empty network
| namespace your service can be totally disconnected from any
| network and still handle requests (because the socket FD it
| listens on was inherited from systemd). This makes exfiltration
| much more difficult.
| fsflover wrote:
| > almost all my services run in VMs/on dedicated hardware
|
| Sounds like you could benefit from Qubes OS.
___________________________________________________________________
(page generated 2023-05-08 23:01 UTC)