Tectia ConnectSecure can be used to transparently tunnel FTP traffic, as well as TN3270 connections from a Windows workstation, to the mainframe. Also other applications can be tunneled.
The following examples show how to restrict tunneling services for certain groups and how to deny terminal and file transfer services.
Please see Defining Subconfigurations for information on user-specific configurations if more fine-grained control is needed over the services.
Transparent tunneling with ConnectSecure uses only local tunnels (port forwarding). The tunnels are established based on the configuration of the application being tunneled. Please see the Tectia ConnectSecure Administrator Manual for details on the tunneling principles.
The following configuration options of Tectia Server for IBM z/OS will deny remote port
forwarding and allow local port forwarding for all users for example to
http://webserver.example.com
or
https://webserver.example.com
.
AllowTcpForwarding yes ForwardACL deny remote .* .* ForwardACL allow local .* .*\.example\.com%(80|443)
The format for the value of the ForwardACL
option is
the following:
(allow|deny) (local|remote) user-pat forward-pat [originator-pat]
user-pat
is used to match the client user, in the
same way as in the UserSpecificConfig
option.
With local port forwarding, forward-pat
is a pattern
of format host-id[%port]
. host-id
will
match with the target host of the forwarding, in the same way as in the
AllowHosts
option. port
will match the
target port. If the client attempts to open the forwarding using a DNS name,
the IP is looked up from the DNS, which will be used to match the
pattern.
Note that the ForwardACL
forward pattern defined with
a DNS name does not match if the tunneled application uses IP addresses
instead of DNS names for connections. The forward pattern defined with an IP
address will match to both.
With local port forwarding, originator-pat
will match
the originator address that the client has reported. However, restrictions
based on the source address of local port forwarding are normally not
reliable because the client can forge the source address.
originator-pat
should be used only if the client can be
trusted (for example, if it is administered by yourself).
If you specify any allow directives, all forwardings in that class (local or remote) not specifically allowed will be denied. If a forwarding matches both allow and deny directives, the forwarding will be denied.
Also, if you have specified any of the options
{Allow,Deny}TcpForwardingFor{Users,Groups}
or
AllowTcpForwarding
, and the forwarding for the user is
disabled with those options, an allow directive will not re-enable the
forwarding for the user.
The following example denies all forwarding for the
sftpusers
group. Other users are denied remote forwarding.
User root
is allowed all local forwarding. User
tunnelu
is allowed local forwarding only to the Telnet port
(23) of addresses *.example.com
, and the forwarding must
originate from the client machine local address
(127.0.0.1
), it cannot be forwarded from a third host (this
assumes that the client machines are trusted).
AllowTcpForwarding yes DenyTcpForwardingForGroups sftpusers ForwardACL deny remote .* .* ForwardACL allow local root .* ForwardACL allow local tunnelu .*\.example\.com%23 127.0.0.1
See Restricting User Logins for more information on the egrep regular expression syntax used in configurations.
Note that the users with terminal (shell) access are restricted only in the Tectia Server for IBM z/OS configuration and can, for example, set up their own port forwardings. See Restrictions to System Administration for more information.