ssh with X11 forwarding across firewall
Jyri Kaljundi
On Fri, 21 Feb 1997, Rachel Lau wrote:
> I'd like to configure the firewall to allow ssh X11 forwarding,
> that means I need to open port 22 and 600x range, since all
> ssh traffic is encrypted, will I explose to any kind of risk?
You don't have to open the usual X ports on your firewall (6000-6063). All
the X traffic will go over the SSH connections thus using only port 22 for
all the communications.
Jüri Kaljundi
j...@stallion.ee
Stallion Ltd.
Rachel Lau
I'd like to configure the firewall to allow ssh X11 forwarding,
that means I need to open port 22 and 600x range, since all
ssh traffic is encrypted, will I explose to any kind of risk?
Any comments is welcomed!
Rachel
Jay Vassos-Libove
[ Remove "*" from e-mail address before replying! Spam bait. *sigh* ]
You must be careful in opening port 22 connections. We allow connections
from the outside through our firewall to port 22 on any internal machine,
because we control the internal machines and know that port 22 will
either hold an SSH listener, or nothing.
The converse, however, is untrue, and we do not permit connections out
from our network to port 22 on remote nodes.
More specifically, we permit TCP connections from any port outside to
port 22 on any internal node. That's the only firewall rule we have
relating to SSH. We do not permit any internal port to send TCP
packets to any external node on port 22 ... because someone could
easily have their telnet client bind to port 22 on the their external
host and then just telnet in. That would be allowed by the converse
rule.
(Someone stop me if I'm wrong?)
Instead, what I've tried - and so far failed to accomplish - for outgoing
SSH connections from our protected network, is to use the ssh client's
proxy setup to connect through the telnet proxy on our firewall. The
result is a connection which immediately drops, because something in the
telnet proxy is injecting garbage characters in to SSH's data stream.
Has anyone gotten the UNIX ssh client's proxy setup to work through a
TIS FireWall ToolKit tn-gw proxy?
Thanks
In article <Pine.GSO.3.95.970222190443.18689A-100000@nebula>,
j...@stallion.ee (Jyri Kaljundi) writes:
> On Fri, 21 Feb 1997, Rachel Lau wrote:
>
>> I'd like to configure the firewall to allow ssh X11 forwarding,
>> that means I need to open port 22 and 600x range, since all
>> ssh traffic is encrypted, will I explose to any kind of risk?
>
> You don't have to open the usual X ports on your firewall (6000-6063). All
> the X traffic will go over the SSH connections thus using only port 22 for
> all the communications.
>
> Jüri Kaljundi
> j...@stallion.ee
> Stallion Ltd.
>
>
--
Jay Vassos-Libove
Senior Software Engineer +1 (770) 552-0543 (home)
Computer Generation, Inc. +1 (404) 705-2867 (work)
libove*@*compgen.com postmaster*@*compgen.com webmaster*@*compgen.com
[ Remove "*" from e-mail address before replying! Spam bait. *sigh* ]
Jim Small
Jay Vassos-Libove wrote:
>
> [ Remove "*" from e-mail address before replying! Spam bait. *sigh* ]
>
> You must be careful in opening port 22 connections. We allow connections
> from the outside through our firewall to port 22 on any internal machine,
> because we control the internal machines and know that port 22 will
> either hold an SSH listener, or nothing.
If someone is on the outside and does a ssh connection into your
machine, they can just as easily redirect anything they like
More importantly, if ANY TCP connection can be created in ANY direction,
you can allow/redirect any traffic you want. (that's just the way things
are, and yes, I've written code to allow this, (in java, so it's
portable :-))
Jay Vassos-Libove
Yes, generally true. However, if ICMP redirects are turned off,
to prevent an existing connection from going somewhere else, (though
I can't see how that would help an attacker anyway, since we're
talking about using SSH here), and if the SSH Daemons inside the
protected network will NOT permit password authentication, then I
feel pretty safe with this setup.
Separately, I'm still hoping that someone has a way to UNIX SSH client
proxy out through TIS FWTK firewall??
Jay
In article <3315AD0C...@vc.net>,
Jim Small <jsm...@vc.net> writes:
> Jay Vassos-Libove wrote:
>>
>> You must be careful in opening port 22 connections. We allow connections
>> from the outside through our firewall to port 22 on any internal machine,
>> because we control the internal machines and know that port 22 will
>> either hold an SSH listener, or nothing.
>
> If someone is on the outside and does a ssh connection into your
> machine, they can just as easily redirect anything they like
>
> More importantly, if ANY TCP connection can be created in ANY direction,
> you can allow/redirect any traffic you want. (that's just the way things
> are, and yes, I've written code to allow this, (in java, so it's
> portable :-))
>
> http://www.nethole.com
--
Jay Vassos-Libove
Senior Software Engineer +1 (770) 552-0543 (home)
Computer Generation, Inc. +1 (404) 705-2867 (work)
libove*@*compgen.com postmaster*@*compgen.com webmaster*@*compgen.com
michael shiplett
"jv" == Jay Vassos-Libove <libove> writes:
jv> You must be careful in opening port 22 connections. We allow
jv> connections from the outside through our firewall to port 22 on
jv> any internal machine, because we control the internal machines and
jv> know that port 22 will either hold an SSH listener, or nothing.
jv> The converse, however, is untrue, and we do not permit connections
jv> out from our network to port 22 on remote nodes.
Are you trying to hide the addresses of your internal machines? If
not, why do you care what is listening on the outside? It seems as if
you're firewalling the outside.
michael
Perry E. Metzger
Jay Vassos-Libove writes:
> More specifically, we permit TCP connections from any port outside to
> port 22 on any internal node. That's the only firewall rule we have
> relating to SSH. We do not permit any internal port to send TCP
> packets to any external node on port 22 ... because someone could
> easily have their telnet client bind to port 22 on the their external
> host and then just telnet in. That would be allowed by the converse
> rule.
>
> (Someone stop me if I'm wrong?)
It appears that you are having some issues with understanding how to
properly configure a packet filtering firewall. Among other things, it
appears you aren't distinguishing between incoming and outgoing
connections. Note that allowings someone from the inside to ssh out
cannot be a threat in the way you list if you aren't permitting
incoming connections.
I would suggest that you spend some more time studying the issues in
question.
Perry
Jay Vassos-Libove
I won't be as rude to Perry as he was to me.
I have no trouble whatsoever understanding the issues of configuring
a firewall/packet filter.
I do, however, operate under the constraint that the (rather old)
firewall setup we have does not distinguish, at the configuration
level, between incoming and outgoing (that is, between originating
and continuing packets of) connections. It is possible that the
packet filter could be patched to provide this functionality, but
I'm loathe to make that kind of change, as it may open up new
security holes through new bugs. Certainly, the packet filter
and/or firewall could be updated or replaced, but that requires
much time and money, neither of which I'm permitted at the moment
by the pursestring holders of the company. Our firewall does
work and does protect us, and ssh is not a high priority for us
at this time, so I am seeking simple answers to the current
configuration, not large or expensive changes.
Given that restriction, my descriptions are perfectly reasonable.
Please, don't question someone's understanding in belittling ways
if you aren't completely sure of their situation.
Back to the issue at hand: Given the somewhat dated nature of
my firewall, which prevents me from permitting outbound initiated
TCP connections to SSH ports on foreign nodes due to the inability
of the packet filter to distinguish between TCP packets initiating
and continuing a TCP connection...
Has anyone got the UNIX SSH client's proxy facility working through
a TIS FWTK tn-gw?
Thanks again...
In article <1997022823...@jekyll.piermont.com>,
Michael Richardson
On 6 Mar 1997 18:20:49 GMT, Jay Vassos-Libove <lib...@compgen.com> wrote:
>by the pursestring holders of the company. Our firewall does
>work and does protect us, and ssh is not a high priority for us
I can't see how your firewall does anything at all.
Certainly, you allow no outgoing web traffic, except by
proxy. If you are willing to install things like http-gw, then
I suggest that you close the SSH port, and use SOCKS.
>TCP connections to SSH ports on foreign nodes due to the inability
>of the packet filter to distinguish between TCP packets initiating
>and continuing a TCP connection...
The only systems I know that are this simple are routers.
So, how do you do WWW? Or do you?
>Has anyone got the UNIX SSH client's proxy facility working through
>a TIS FWTK tn-gw?
tn-gw is the wrong choice. plug-gw works, but only to one destination.
You need an ssh proxy, which hasn't been written yet, but the 2.0 SSH
protocol may make this easier to do.
--
:!mcr!: | Network security consulting and
Michael Richardson | contract programming
WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">m...@sandelman.ottawa.on.ca</A>. PGP key available.
Jay Vassos-Libove
[ Remove "*" from e-mail address before replying! Spam bait. *sigh* ]
In article <slrn5hvnh...@amaterasu.sandelman.ottawa.on.ca>,
m...@amaterasu.sandelman.ottawa.on.ca (Michael Richardson) writes:
> I can't see how your firewall does anything at all.
> Certainly, you allow no outgoing web traffic, except by
> proxy. If you are willing to install things like http-gw, then
> I suggest that you close the SSH port, and use SOCKS.
The firewall does quite a lot. It is combined (in the older style,
of more than one single box doing all the work) with a pair of
Cisco routers with filters engaged, and with several proxy programs.
We have outgoing telnet, FTP, web, and other traffic, through the
proxies, access controlled by both the proxy programs' wrappers
and the three firewalls (the gateway system itself and the two
Cisco routers' filtering mechanisms).
We have an SSL gateway, but no SOCKS gateway. Can SOCKS be generically
used with SSH? That could be a solution. Please elaborate! Thanks!
>>TCP connections to SSH ports on foreign nodes due to the inability
>>of the packet filter to distinguish between TCP packets initiating
>>and continuing a TCP connection...
>
> The only systems I know that are this simple are routers.
> So, how do you do WWW? Or do you?
See above. This is an old Linux machine, surrounded by Ciscos.
>>Has anyone got the UNIX SSH client's proxy facility working through
>>a TIS FWTK tn-gw?
>
> tn-gw is the wrong choice. plug-gw works, but only to one destination.
> You need an ssh proxy, which hasn't been written yet, but the 2.0 SSH
> protocol may make this easier to do.
Why is tn-gw "wrong"? Certainly, it is a bit of a hack, but if it
can be made to establish a completely 8-bit clear connection, then it
seems that it ought to work, with the SSH client proxy code.
When might we see the 2.0 SSH protocol? Is there some specific
discussion that we can find, now, while it is still in development,
on the subject of proxying the SSH connection?
Thanks!
Matthia...@softcon.de
>a TIS FWTK tn-gw?
tn-gw is the wrong choice. plug-gw works, but only to one destination.
You need an ssh proxy, which hasn't been written yet, but the 2.0 SSH
protocol may make this easier to do.
We're using ssh-1.2.17 together with the plug-gw of TIS fwtk.
All incoming ssh requests are routed to one host in our LAN
and all outgoing requests are using specific ports (one port
for each destination). I configured plug-gw's for the ports
in the inetd.conf and set permissions in the fwtk-table.
The lines in the netperm-table plug than each port to the
port 22 of the destination. Works fine. You just say:
$ ssh firewall-host -p 1000x -l xxxxx
$ ssh firewall-host -p 1000y -l yyyyy
matthias
--
firm: matthia...@sisis.de [voc:+49-89-61308-351, fax: +49-89-61308-188]
priv: gu...@thias.muc.de
WWW: http://www.sisis.de/~guru/ OR http://www.guug.de/GUUG/firmen/apitz/
April 19, 1997, will be day #10,000 since the Unix epoch of 1 January 1970.
Will anyoune remember Win95 after the next 10,000 days?
Mark Henderson
--N9G5IMxoKFntn=h2
Michael Richardson writes:
> On 6 Mar 1997 18:20:49 GMT, Jay Vassos-Libove <lib...@compgen.com> wrote:
> tn-gw is the wrong choice. plug-gw works, but only to one destination.
> You need an ssh proxy, which hasn't been written yet, but the 2.0 SSH
> protocol may make this easier to do.
You can use ssl-gw or the version of http-gw included with the 2.0
beta fwtk as they both support the CONNECT method. If you're not
using the 2.0 fwtk yet, you can get ssl-gw from
ftp://ftp.edelweb.fr/pub/contrib/fwtk
The following script (ssh-tunnel.pl) from a previous post to this
list... (credit is in comments).
#!/usr/local/bin/perl5
#
# ssh-tunnel.pl
#
# Usage: ssh-tunnel.pl ssl-proxy port destination_host port
#
# This script can be used by ssh as a "ProxyCommand" to
# traverse a www-proxy/firewall that supports the http CONNECT
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
#
# Example, connect to host named "remote" outside of your firewall:
#
# $ ssh remote -o'ProxyCommand ssh-tunnel.pl www-proxy 80 remote 22'
#
# Better yet, insert the ProxyCommand definition for host "remote" in
# your $HOME/.ssh/config file:
#
# .
# .
# Host remote
# ProxyCommand /usr/local/bin/ssh-tunnel.pl www-proxy 80 %h %p
# .
# .
#
# Written by Urban Kaveus <ur...@statt.ericsson.se>
require 'sys/socket.ph';
# Parse command line arguments
if ( $#ARGV != 3 ) {
print STDERR "Usage: $0 ssl-proxy port destination port\n";
exit(1);
}
$sslproxy = shift;
$proxyport = shift;
$destination = shift;
$destport = shift;
# Set up network communication
($protocol) = (getprotobyname("tcp"))[2];
($proxyip) = (gethostbyname($sslproxy))[4];
$localaddr = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);
socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
die("Failed to create cocket");
bind (PROXY, $localaddr) or
die("Failed to bind socket");
connect (PROXY, $proxyaddr) or
die("Failed to connect to $sslproxy port $proxyport");
# Force flushing of socket buffers
select (PROXY); $| = 1;
select (STDOUT); $| = 1;
# Send a "CONNECT" command to proxy:
print PROXY "CONNECT $destination:$destport HTTP/1.0\r\n\r\n";
# Wait for HTTP status code, bail out if you don't get back a 2xx code.
$_ = <PROXY>;
($status) = (split())[1];
die("Received a bad status code \"$status\" from proxy server")
if ( int($status/100) != 2 );
# Skip through remaining part of MIME header
while(<PROXY>) {
chomp; # Strip <LF>
last if /^[\r]*$/; # Empty line or a single <CR> left
}
# Start copying packets in both directions.
if($child = fork) { # Parent process
while (sysread(STDIN,$_,4096)) {
print PROXY;
}
sleep 2;
kill(15,$child) if $child;
}
else { # Child process
while (sysread(PROXY,$_,4096)) {
print STDOUT;
}
}
--N9G5IMxoKFntn=h2
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
iQCVAwUBMyEReKWYCYyyZn7/AQEo1gP8DxQgeoBby8kFomYDUtSpJWgiHIC2XRYo
zEm7Mvxe5Tvm0gfta8RnTR6GQjxpteBhPL8WuhITyFWpQ/RTX7VHxyU+GgAmIRHs
UlAPoBZVOEwyIZtVHsib/fxpZ27yrrCOQHqTAeB/c343xElbftdhE7AlznAhgwjt
9Dz9RQt1uHs=
=7amN
-----END PGP SIGNATURE-----
--N9G5IMxoKFntn=h2--
Jay Vassos-Libove
[ Remove "*" from e-mail address before replying! Spam bait. *sigh* ]
Thanks to the two respondants who offered very specific and functional
answers to my problem of outbound SSH connections through an old
firewall which can not distinguish between the initial packet and
future packets of a TCP circuit.
The two responses were:
Mark Henderson <m...@squirrel.com>
who provided a PERL script to work through an SSL gateway, and
Sten kalenda <st...@twinfo.nl>
who provided a modified tn-gw, which required a dummy account
on the firewall.
The SSL solution was preferable to me for two reasons:
1. I already have an SSL gateway on the firewall/gateway machine, and
2. I don't like the idea of dummy accounts - there's always the
possibility of a system (or system manager!) bug making this a
security hole
Thanks also to all those who participated in the discussion. Yes,
I know that I could upgrade my firewall/gateway system to a version
which understands the difference between initiating and continuing
TCP packets... but I could also upgrade it to a complete commercial
solution. Either one takes time and money, and the project lacks
that priority at this time. It works, even if it isn't as functional
as I might like, and security is far more important than minor
functionality.
Again, thanks to all