New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transparent SSH SOCKS proxy for Qubes #1536
Comments
Hi, Actually I have a working solution for this.
My intention was not to make a failsafe/anti leaking setup - but it is completely depends on the actual iptables rules. |
The current ipmlementation of qubes-firewall service are dropping the user changes ONLY in filter table, but leaving (saving) the nat table:
This makes really hard to implement any custom rulesets needed such a service. because if it is calling the /rw/config/qubes-firewall-user-script There will be duplicated user defined rules/chains - unless I hack it around in that script... @marmarek Is there any reason for this behavior? Why not drop all the rules and recreate them from scratch? |
This is one of the reason for discussion on new firewall API on qubes-devel. |
@Zrubi, are you still working on this (or plan to)? (Asking for tracking purposes.) |
I'm not planning to work on this. Mainly because I don't believe in "leak prof" things the mass are "needs" (referring to a "leakproof" VPN hacks) Currently I have a working transparent sock proxy solution but that is not worth publishing until the Qubes new firewall API is not released. The current Qubes firewall scripts may breaking/not refreshing the custom firewall rules. |
Understood. Thanks! |
Hi, I used this tutorial https://linuxaria.com/article/redirect-all-tcp-traffic-through-transparent-socks5-proxy-in-linux |
It's very important for my purposes. Thank you in advance. |
P. S. I am not really understand about it. |
Can it help me https://www.qubes-os.org/doc/network-bridge-support/ ? |
I would suggest taking a look at Qubes VPN documentation: https://www.qubes-os.org/doc/vpn/ It's not the same but you can get a feel for how traffic can be transparently routed through a proxyVM using iptables and learn about aspects that are specific to Qubes. Then, you'll need to move redsocks redirection from nat:OUTPUT to nat:PREROUTING and set up appropriate forwarding / dns rules. |
@hollyboy: Please do not hijack GitHub issues for personal tech support. Please send a message to the |
As I mentioned earlier, I have a working transparent SOCKS proxy solution based on redsocks: Now I'm created an .rpm package because there was no pre-build binary distributed jet for fedora. Sending the SRPM package to qubes-devel. This is building fine under F24, and F23 |
For being very fail-closed, you can use SSH's ProxyCommand option to invoke a qrexec service in a separate domain, which allows you to set the NetVM of the ProxyVM to By far the most flexible and accident-proof solution I've found. edit: for bonus leak-proofness, you can even make the ProxyVM actually be a NetVM so that you can't accidentally give it a NetVM. |
Redsocks seems to be in Debian repository, so there seems to be no need to compile it unless you insist on Fedora. This way, you also get security updates. How do you configure iptables for redsocks? EDIT: It seems that this is a good startpoing: https://gist.github.com/afriza/1097210 EDIT2: Hmm, not so easy. It does not affect the connected VMs and it is not much suitable for firewall script. BTW, I've seen NetworkManager-SSH that is available in both Debian and Fedora repository. But this does not use SOCKS. It uses TUN/TAP over SSH. Its practical downside is that it has some requirements on the SSH server and the documentation requires root. So, it is not as easy solution as it looks. |
On 02/11/2018 05:56 PM, Vít Šesták wrote:
Redsocks seems to be in Debian repository, so there seems to be no need
to compile it unless you insist on Fedora. This way, you also get
security updates.
How do you configure iptables for redsocks?
iptables -I INPUT -i vif+ -p tcp --dport <redsocks port> -j ACCEPT
iptables -t nat -I PREROUTING -p tcp -d <target destination> -j REDIRECT
--to-port <redsocks port>
where <redsocks port> defined in the actual redsocks config,
and <target destination> is the network range you can reach via parent
parent proxy defined in redsocks
with this rules, all the forwarded tcp packets matching the <target
destination> will be passed to the local redsocks instance.
BTW, I've seen NetworkManager-SSH
<https://github.com/danfruehauf/NetworkManager-ssh> that is available in
both Debian and Fedora repository. But this does not use SOCKS. It uses
TUN/TAP over SSH. Its practical downside is that it has some
requirements on the SSH server and the documentation requires root. So,
it is not as easy solution as it looks.
I'm already talked with the author.
TLDR;
the current solution is forced by the limitation of NetworkManager.
He may try to redesign it to support SOCKS proxies as well.
danfruehauf/NetworkManager-ssh#41
danfruehauf/NetworkManager-ssh#66
…--
Zrubi
|
@Zrubi, would you mind packaging your contribution following our new package contribution procedure? |
this project work for me https://github.com/hexstore/qubes-proxy |
Community Dev: @Zrubi
PoC: https://groups.google.com/d/msgid/qubes-devel/d9731ee0-e89b-75e2-f024-83e59d02d8c8%40zrubi.hu
Hi. I'd like to implement a transparent SOCKS proxy for Qubes using SSH.
This way a user can transparently tunnel all traffic from a particular AppVM through another server, without having to configure a VPN or worry about a fail-open setup.
I think it should work roughly as follows:
The user creates the proxyvm and enables the qubes-ssh-proxy service:
In the template, the user installs the ssh proxy:
In the proxyVM, the user configures the ssh proxy:
The user adds the ssh public key from the previous step to their
.authorized_keys
file on the server.The user sets the new ProxyVM as the NetVM for some AppVM. All TCP traffic from the AppVM is sent through the ssh tunnel and all UDP traffic is dropped.
Internally, ssh is run as a systemd service, so that restarting on failure, logging, etc. all happens automatically, and iptables sends incoming traffic through the tunnel.
Next, it would be good to automate the setup using the configuration management, so that a user just has to input
user@hostname
and they're given the generated ssh key to add to the server.The text was updated successfully, but these errors were encountered: