Page Comparison

{float:side=right|border=0|width=40%}{include:Snippet - Disclaimer}{float}
h1. Remote Access

!login-sm.png|align=left! {excerpt}As a support provider, you may need to enable remote access (RDP, SSH, etc.) to support your systems. It's important to strike the right balance between open access and strict limitations so that you can get your work done effectively while preserving security.

To maintain system security, consider these baseline recommendations.{excerpt}
\\

{div} !gtk685.png! {div2:class=gray_box2}
{div3:id=lightgreenbg}
h4. Connect to AD or LDAP for Authentication and Authorization
{float:side=right|border=none|background=#eff5d5}{tip:title=Use As Default} {tip}{float}Configure your systems to authenticate to LDAP or AD. This eases the management of authentication and authorization, and helps Tufts collect and correlate authentication events more efficiently.
\\
\\
{div3}
{div3:id=whitebg}

h4. Use Your Firewall to Require the VPN for Off-Campus Access
{float:side=right|border=none}{tip:title=Use As Default} {tip}{float}Unless direct public access is absolutely required, configure your host firewall to only allow remote access connections (like SSH and RDP) from on-campus (130.64.0.0/16). Or go one step farther and only allow the Tufts subnets you need (e.g., your own subnet, plus the VPN - which is at 130.64.26.0/23).
\\
\\
{div3}
{div3:id=lightgreenbg}

h4. Encrypt Data In Motion
{float:side=right|border=none|background=#eff5d5}{tip:title=Use As Default} {tip}{float}Use encryption for all remote access authentication. RDP and SSH are encrypted out of the box, but VNC, telnet, and others are not. If possible, only enable encrypted remote access services and turn off all unencrypted access services.
\\
\\
{div3}
{div3:id=whitebg}

h4. Stay Up-To-Date
{float:side=right|border=none}{tip:title=Use As Default} {tip}{float}It's very important to keep all of your network-available services up-to-date. If serious flaws are uncovered in your remote access program, it's update immediately or shut the service off until an update can be deployed.
\\
\\
{div3}
{div3:id=lightgreenbg}

h4. Use a Different TCP/IP Port
{float:side=right|border=none|background=#eff5d5}{note:title=Security/Usability Trade-Off} {note}{float}Depending on the kind of service you run, and the audience to which it is provided, you may be able to run your remote access service on a non-default port. This will not stop dedicated port scanners, but can remove a lot of noisy traffic just looking for open services with weak or stolen passwords. This may or may not be appropriate in your environment.
\\
\\
{div3}
{div3:id=whitebg}

h4. Run a Blacklisting Application
{float:side=right|border=none}{note:title=Security/Usability Trade-Off} {note}{float}Some services can work well with a blacklisting program to block access to source IPs with too many failed logins. One of the most common is _denyhosts_ for SSH.
\\
\\
{div3}
{div3:id=lightgreenbg}

h4. Consult With Others

Don't hesitate to consult with others who run similar environments, within UIT and across Tufts. You can also [contact UIT's Information Security team|Contact Us] at any time to discuss best practices and how they apply to the Tufts environment.
\\
\\
{div3}
{div2}
{div}