openssh bugs - Mar 2007 - [Bug 1295] [PATCH] Transparent proxy support on Linux

http://bugzilla.mindrot.org/show_bug.cgi?id=1295

           Summary: [PATCH] Transparent proxy support on Linux
           Product: Portable OpenSSH
           Version: 4.6p1
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: luca.barbieri at gmail.com


This patch adds transparent proxy support on Linux.

You can then run `ssh -D $port` and use `iptables -t nat -A OUTPUT -p
tcp -d $dest -j REDIRECT --to-ports $port` to tunnel all TCP
connections to host $dest via the ssh tunnel.

Please apply, since this functionality is quite useful and cannot be
efficiently obtained otherwise.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #1 from luca.barbieri at gmail.com  2007-03-12 11:24 -------
Created an attachment (id=1249)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1249&action=view)
Patch




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #1249 is|0                           |1
           obsolete|                            |




------- Comment #2 from dtucker at zip.com.au  2007-03-12 13:29 -------
Created an attachment (id=1250)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1250&action=view)
Remove auto-generated files from diff

The bulk of the diff (99.7%, by my calculations :-) is noise from
automatically generated files.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #3 from luca.barbieri at gmail.com  2007-03-12 13:48 -------
Sorry, I had filtered it myself but uploaded the wrong file.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #1250 is|0                           |1
           obsolete|                            |




------- Comment #4 from dtucker at zip.com.au  2007-03-12 23:39 -------
Created an attachment (id=1251)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1251&action=view)
Move Linux code to port-linux.c, add OpenBSD pf rdr support

I like this idea, and I've extended it a bit:
* added autoconf support
* moved linux/netfilter-specific code into openbsd-compat/port-linux.c
* added support for OpenBSD pf "rdr" rules
* made it easy to add new redirection interfaces.

On OpenBSD, you can use something like the following in pf.conf:

tun_net="192.168.34.0/24"
rdr pass on lo0 proto tcp from any to $tun_net -> 127.0.0.1 port 1080
pass out quick route-to (lo0 127.0.0.1) from any to $tun_net

(the route-to is needed because pf rdr rules don't apply to outbound
packets, so without it you can't redirect locally originated
connections).

For anyone wondering how this compares to the tun(4) interface that's
already there: it's less flexible (TCP only, requires good name
resolution on the client end) but doesn't require privilege on the
server (or anything other than standard port forwarding) and doesn't
suffer from the TCP-over-IP-over-TCP performance potential problems (ie
stacked retransmits when the link experiences packet loss).

For the truly twisted: you can also achieve something similar to this
patch *without* special kernel support (other than ppp/slip) if you
build slirp socksified and point it to a DynamicForward.  (I've
actually done this, but it turns out I wasn't the first to think of it.
 I dunno if I'm disappointed or relieved :-)




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #5 from djm at mindrot.org  2007-03-16 00:23 -------
Nice idea, but why does this need to be in ssh (which would need to
then run as root) and not some little "nat-to-socks" tool, or just as
a
mode to netcat? That way it would not bloat ssh, and could also be used
to automatically Tor-ify applications.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #6 from dtucker at zip.com.au  2007-03-16 00:56 -------
(In reply to comment #5)
> Nice idea, but why does this need to be in ssh (which would need to
> then run as root)
It doesn't necessarily need to run as root.

On Linux, it doesn't require any privilege at all.

On OpenBSD, it needs write access to /dev/pf (I asked the pf guys if
there was another way to do it but there wasn't).  You could make it
setgid, and you could mitigate by opening /dev/pf early then revoking
privileges and keeping the descriptor open.
> and not some little "nat-to-socks" tool, or just as a
> mode to netcat? That way it would not bloat ssh, and could also be
> used to automatically Tor-ify applications.
Now that might be worth investigating.  I looked for such a tool but
didn't find one (not that it means it doesn't exist, just that I
didn't
find it).




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #7 from luca.barbieri at gmail.com  2007-03-16 12:08 -------
Because this avoids the extra overhead and hassle of the nat-to-socks
application.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1295





------- Comment #8 from dtucker at zip.com.au  2007-04-10 10:06 -------
(In reply to comment #7)
> Because this avoids the extra overhead and hassle of the nat-to-socks
> application.
A separate nat-to-socks application does have some advantages, though. 
You could open the tunnels on demand, and you could use different
tunnels based on different conditions (eg: target, current location on
the network).  Both of those are things that would be useful to me.

Going back to comment #6, there's another way it could be done on
OpenBSD without running sshd as root: you could use a setuid/setgid
helper to return an open descriptor on /dev/pf.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.