Published on Apr 02, 2024
As Internet access becomes increasingly inexpensive and available, it has become a viable replacement for traditional couriers, telephone, and fax, as well as remote dial-up access to a company’s internal computer resources.
One of the biggest challenges in using the Internet to replace more traditional communications is security. In the past, companies have maintained their own modem bank dial-up access to company resources so that critical data wasn’t being transmitted over the public network. Modem banks are expensive to maintain and don’t scale well. In a large company, long distance charges for road warriors alone can make this an expensive solution.
Confidentiality: The transmitted data must not be readable by unauthorized parties on the network. Confidentiality is achieved through encryption.
Integrity: Unauthorized parties must not be able to modify the data without detection. Integrity is achieved by using checksum values, which allow detection of tampering attempts at the receiving end.
Authentication: Both parties of the communication must be able to identify each other reliably, so that no one can masquerade as the other party. Authentication can be implemented by using challenge passwords, for example. However, the strongest authentication is achieved through public-key cryptography and digital signatures.
Secure Shell is a protocol that provides authentication, encryption and data integrity to secure network communications. Implementations of Secure Shell offer the following capabilities: a secure command-shell, secure file transfer, and remote access to a variety of TCP/IP applications via a secure tunnel. Secure Shell client and server applications are widely available for most popular operating systems.
Port forwarding is a powerful tool that can provide security to TCP/IP applications including e-mail, sales and customer contact databases, and in-house applications. Port forwarding, sometimes referred to as tunneling, allows data from normally unsecured TCP/IP applications to be secured. After port forwarding has been set up, Secure Shell reroutes traffic from a program (usually a client) and sends it across the encrypted tunnel, then delivers it to a program on the other side (usually a server). Multiple applications can transmit data over a single multiplexed channel, eliminating the need to open additional vulnerable ports on a firewall or router.
For some applications, a secure remote command shell isn’t sufficient and graphical remote control is necessary. Secure Shell’s port forwarding capabilities can be used to create an encrypted tunnel over which an application can be run. Virtual Network Client, a cross platform GUI remote control application is a good example. Now we are going to tell about tunneling or port forwarding in detail.
Conference attendees at public PCs. Travelers using a hotel or airport wireless LAN. Day extenders logging back into work at night. Teleworkers conducting business from home. All of these workers can increase business efficiency by leveraging the public Internet to stay connected. But what are the risks?
Consider a teleworker using the Internet to access e-mail (see figure). When the worker’s client sends mail, messages are relayed to an SMTP server. When the client reads mail, message headers and bodies are downloaded from a POP or IMAP server. Anyone anywhere in this path through the Internet can use a sniffer to capture not only cleartext message bodies, but also e-mail addresses, user names, and passwords.
Armed with this stolen data, a passive attacker can replay original or modified messages, even send them to other destinations. By actively masquerading as a legitimate e-mail client or server, a “man in the middle” (Mit M) attacker can intercept and drop messages, or insert new forged messages.
Mail-specific security measures like PGP and S/MIME encrypt and digitally sign message bodies, but leave cleartext message headers. Furthermore, they do nothing to protect the mail server from attack. Mail servers listening to well-known SMTP, POP, and IMAP ports are easily discovered by port scans. Hackers can use an open server to relay spam or tie up the server with denial-of-service (DoS) attacks. By “fingerprinting” the server, they can exploit known vulnerabilities in the server’s operating system or email software. Leaving this mission-critical resource wide open to Internet access is clearly unwise. Tunneling with Secure Shell can help by eliminating open ports, blocking unauthorized users, and ensuring the privacy and integrity of all SMTP, POP, and IMAP traffic exchanged between mail clients and servers.
Application streams are tunneled over Secure Shell by forwarding individual TCP ports. In this section, we focus on local port-forwarding: tunnels initiated by the Secure Shell client. This direction is far more common than remote port-forwarding: tunnels initiated by the Secure Shell server. When a local port is forwarded, SecureCRT (the Secure Shell client) listens to a specified TCP port on the local host. VShell (the Secure Shell server) opens a TCP connection to the remote host where the server application is actually running.
• The localhost refers to the application client's host; remotehost refers to the application server's host. Typically, if localhost is not specified, it defaults to the SecureCRT host. If remotehost is not specified, it defaults to the VShell host.
• The localport refers to the port that the application client sends to and SecureCRT listens to. The remoteport refers to the port that VShell sends to and the application server listens to. In most cases, the localport can be any arbitrary, unused port on the localhost. The remoteport must be the IANAassigned "well-known" listening port for the application being tunneled.
To use the port-forward, the client application must be reconfigured to connect to localhost:localport instead of remotehost:remoteport. Packets sent by the client to localhost:localport are intercepted by SecureCRT or another SSH client, localhost:localport are intercepted by SecureCRT or another SSH client, encrypted, and tunneled through the Secure Shell connection to Vshell or another SSH server. On receipt, VShell decrypts these packets, relaying them as cleartext through the TCP connection to the server at remotehost:remoteport. Local port-forwarding for e-mail is illustrated in Figure.
Traffic in transit between SecureCRT and VShell is cryptographically protected. However, traffic between VShell and the remote host is not. Typically, VShell is located inside the network perimeter, behind a firewall. The firewall is configured to permit Secure Shell, but not the tunneled application protocols (in this example, SMTP, POP, and IMAP). In essence, this configuration relies on the firewall to protect cleartext traffic and inside servers on the trusted LAN. When the LAN cannot be trusted or Intranet servers are at a premium, VShell can run on the same machine as the server application. In this case, there is no need to specify a remote host in the portforward – SecureCRT and VShell interact with client/server applications on each local host. Application packets are protected end-to-end; cleartext is never sent over the network.
The Secure Shell technology provides you with network security tools that help compliment your system and data security. With Secure Shell, remote connections are encrypted and the administrators can decide which means of authentication they require. Additionally, Secure Shell enables you to create secure remote backups and tunnel other TCP-based traffic. Using Secure Shell ensures that your mission-critical data is safe from eavesdropping while traversing the Internet and the users of the data are strongly authenticated. The SSH2 protocol provides robust security services over TCP transport layer. These include strong, secure authentication methods, data confidentiality, and integrity. Secure Shell products utilize this security layer to provide tools like interactive and scripted command-line access and file transfer capabilities. There is a family of end-user binary products, which are widely used by system and network administrators today.
J. Simmons, "The Subliminal Channels in the U.S. Digital Signature Algorithm (DSA)." Proceedings of the Third Symposium on: State and Progress of Research in Cryptography, Rome: Fondazione Ugo Bordoni, 1993.
• K. W. Campbell and M. J. Wiener, "DES Is Not a Group," Advances in Cryptology CRYPTO `92 Proceedings, Springer-Verlag.
• James Bamford's book, The Puzzle Palace (Penguin), for an investigative history of the NSA.
• S.M. Bellovin, “Security problems in the TCP/IP protocol suite”, S.M. Bellovin, AT&T Bell Laboratories, Murray Hill, New Jersey 07974
| Are you interested in this topic.Then mail to us immediately to get the full report.
email :- contactv2@gmail.com |
