![]() |
![]() |
| Home | What's New | Products | Download | Purchase | Support | About Us | Contact |
|
|
|
I need to better control access to my server. To better control access to your server, you can use a combination of access control and connection and port-forwarding filters. First, access control. VShell® lets you control access to your server based on the users and groups already defined for your UNIX system. You can control access to logon, shell, SFTP, remote execution, port forwarding and remote port forwarding. Access control is defined by an option called "AccessControl" in the vshelld_config file. In the following example, only the systems administrator is given access to the shell, SFTP access is restricted to user "alice" and groups "ops" and "faculty", and port forwarding access is granted to users "alice" and "bob" but denied to user "root". This information can be described in a table like the one below.
In VShell, the same information is conveyed more succinctly in an access control list like the one following.
AccessControl {
Shell {
AllowUsers{ admin } #Allow vshell acces to admin
DenyUsers{ root } #Deny shell access to root
}
SFTP {
AllowUsers{ alice } #Allow SFTP access to alice
AllowGroups{ ops, faculty } #Allow SFTP access to ops and faculty
DenyUsers{ root } #Deny SFTP access to root
DenyGroups{ wheel } #Deny SFTP access to wheel
}
RemoteExecution{
AllowUsers{ admin } #Allow remote execution to admin
DenyUsers{ root } #Deny remote execution to root
}
PortForwarding{
AllowUsers{ bob, alice } #Allow port forwarding to bob and alice
DenyUsers{ root } #Deny port forwarding to root
}
}
When you use an access control list, any user not explicitly allowed access to a function would be implicitly denied by default. Therefore, in the above example, the user "root" did not have to be explicitly denied port forwarding, only "bob" and "alice" would be allowed access to that function. One reason to explicitly deny access to a user is because that if, in the future, that user becomes a member of a group that is allowed access, the user will still be denied because a deny takes precedence over an allow. The next part of the control equation can be connection filters. Connection filters are also a configuration option defined in vshelld_config. Connection filters allow you to allow or deny connections from specific hosts and IP addresses. In the following example, the host "remotehost.isp.com" and the domain "trusted.com" are allowed to connect while the host at IP address "192.0.0.1" is denied.
ConnectionFilterTable {
{host remotehost.isp.com, access allow, comment "remote users access"}
{domain *.trusted.com, access allow, comment "allows connections from trusted.com"}
{IP 192.0.0.1, access denied, comment "denies connections from 192.0.0.1"}
}
Filter lists that include domain or hostname entries will cause vshelld to perform a reverse DNS lookup. If this lookup fails, the connection is denied. Warning! Hostname and domain entries rely on DNS lookup and should be used with care. DNS is an unsecure service and could be used as part of an attack on your system. You may want to use IP addresses instead. A third part of the control equation is port-forwarding filters. Port-forwarding filters are another configuration option defined in vshelld_config. Port-forwarding filters allow you to limit server access by specified hosts or IP addresses. The following example allows port-forwarding access to any port in the isp.com domain, and only allows access to port 80 on www.trusted.com.
PortForwardFilterTable {
{domain *.isp.com, port 0, access allow,
comment "allow port forwarding to any port in the isp.com domain"}
{host www.trusted.com, port 80, access allow,
comment "only allow port forwarding to port 80 on www.trusted.com"}
}
Each of these options by itself enhances control over access to your server. Together, they add layers of protection. An access control list grants access to the users and groups that you want to use your server and blocks those that you don’t. Connection filters then shield your server even more by controlling the hosts and domains that can connect to it. And finally, port-forward filters limit the access your approved users have to other hosts. In our examples above, only the users "bob" and "alice" are allowed to connect to your server (via a trusted connection) and port forward through your server; and then, only to the specified ports on approved hosts. For detailed information on access lists and filters, refer to the vshelld_config (5) man page.
|
| Products | Downloads | Purchase | Support | About Us | |
|---|---|---|---|---|---|
| VShell Server | VShell Server | Buy Direct | Evaluation | Contact | |
| SecureCRT | SecureCRT | License Pricing | Updates Policy | Press Releases | |
| SecureFX | SecureFX | About Encryption Export | FAQs | What's New | |
| VanDyke ClientPack | VanDyke ClientPack | Orders FAQ | Tips & How-Tos | Customer Stories | |
| Beta Software | Beta Software | Resellers | Forums | Secure Solutions | |
|
Site Map | Legal Notices | Privacy Policy | Refund Policy VShell, SecureCRT, SecureFX, Entunnel, CRT, and AbsoluteFTP are trademarks or registered trademarks of VanDyke Software, Inc. in the United States and/or other countries. All other trademarks or registered trademarks are the property of their respective owners. Copyright © 1995 - VanDyke Software, Inc. All rights reserved. |
|||||