• Choose a category
• All
• Classic-Fiction

Remote shell tools are similar to remote control tools except that they are limited to command-line or text-only interaction. Common examples of this include Telnet and Secure Shell (SSH). Telnet should be avoided completely because it offers no security or encryption. Telnet can be deployed securely within a Secure Sockets Layer (SSL) tunnel, but doing so is often too involved for most situations, especially since SSH can be easily installed and offers greater protection than Telnet via SSL. SSH provides encryption for both authentication and data communications.

If you will be using remote control/remote shells tools, enable and require any and all security features available for the product employed. Limit the use of remote control tools over the Internet. Limit who can use these tools, and monitor when and why they are used.

Virtual Private Networks

Using virtual private networks (VPNs) is usually a more secure option for remote access than dial-up connections. However, to support VPNs you need an Internet connection on your LAN. If the Internet connection is controlled so that it is only used for VPN links, most of the security issues with Internet connectivity are eliminated. However, if both VPN and general Internet communications are to be supported, a more extensive security solution is required.

VPN security is usually a factor of solution selection and configuration. There are three widely used VPN protocols: Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and Internet Protocol Security (IPSec). PPTP is often considered a default to use if you are communicating with systems that don’t support L2TP or IPSec. If you don’t need it for this purpose, PPTP should be avoided due to the vulnerabilities and weak encryption it employs. You should use L2TP alone (without IPSec) when a dial-up link is involved in the VPN, which usually means the remote client is connecting to an ISP via dial-up, and then establish the VPN link across the resultant pathway. IPSec should be employed if broadband connections are present throughout the pathway between the LAN VPN server and the remote client.

Always enable only the strongest authentication and data encryption supported; avoid pre-shared keys and relying on unique session keys and certificates. While the client is connected to the VPN, prevent any other form of communication from occurring over the Internet link. Force periodic reauthentication during the VPN session to check for and prevent hijacking.

Directory Services Protection

As a network user, there is not much you can do to improve or change the security of the directory services deployed. However, you can ensure that you don’t become a tool for an attacker bent on compromising your organization’s security:

■ Ensure that your client is using the most secure form of authentication encryption supported by both your client and the authentication servers.

■ Use encrypted software and protocols whenever possible, even for internal communications.

■ Change your password according to the company’s password policy.

■ Use a 16+ character password that is unique for each account.

■ Never write your password down, or if you do, divide it up into several pieces and store each in a different secure location (such as a home safe, a gun cabinet, a chemical supply locker, or safety deposit box).

■ Never share your password or your logon session with another person; this includes your friends, spouse, and children.

■ Verify that your client always interacts with an authentication server during the network logon process and does not use cached credentials.

■ Every single time, just before you log on to the network, double-check that a hardware keystroke catcher has not been surreptitiously installed (see the KeyKatcher at www.thinkgeek.com).

■ Allow all approved updates and patches to be installed onto your client.

■ Ensure that all company data is copied back to a central file server before disconnecting from