DOCSLIB.ORG

Secure FTP Overview

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Secure FTP Overview 1. April 2009 Martin Trinkler Agenda Supported FTP security functions by z/OS FTP Client with SOCKS proxy protocol Secure Sockets Layer/Transport Layer Security (SSL/TLS) Application Transparent-TLS (AT-TLS) IP Security (IPSec) Kerberos security Configuration of FTP native TLS security Firewall Restrictions Related publications Q & A © Company Insurance Zurich 3/9/2009 Secure FTP Overview 2 Supported FTP security functions by z/OS sFTP (OpenShell procedure) FTP Client with SOCKS proxy protocol Secure Sockets Layer/Transport Layer Security (SSL/TLS) Application Transparent-TLS (AT-TLS) IP Security (IPSec) Kerberos security © Company Insurance Zurich 3/9/2009 Secure FTP Overview 3 sFTP (OpenShell procedure) The SSH File Transfer Protocol (sometimes called Secure File Transfer Protocol or SFTP) is a network protocol that provides file transfer and manipulation functionality over any reliable data stream. It is typically used with version two of the SSH protocol (TCP port 22) to provide secure file transfer and not using FTP protocols as described in RFC959 and its related RFCs. FTP with SOCKS proxy protocol The FTP client has to access the FTP server indirectly by passing through a SOCKS proxy server. The client must use the SOCKS protocol to successfully navigate through the proxy server. The client must be able to determine which servers it must contact using the SOCKS protocol. These servers are specified in a SOCKS configuration file that the client reads to make this determination. The SOCKSCONFIGFILE statement in the client’s FTP.DATA file is used to point the client to the configuration file where these servers are identified © Company Insurance Zurich 3/9/2009 Secure FTP Overview 5 Configuration example FTP.DATA statement SOCKSCONFIGFILE Config File: SOCKD @=192.168.20.11 172.14.0.0/16 DIRECT 10.0.0.0/8 DIRECT 0.0.0.0 0.0.0.0 Secure Sockets Layer/Transport Layer Security (SSL/TLS) 1/2 SSL/TLS provides: – data privacy – data integrity – server and client authentication based upon a Public Key Infrastructure (PKI) method PKI requires a server generated public/private key pair used during negotiations. PKI requires that data encrypted with the public key be decrypted by only the private key and vice versa. This is called an asymmetric encryption method because different keys are used at each end of the secure connection © Company Insurance Zurich 3/9/2009 Secure FTP Overview 7 Secure Sockets Layer/Transport Layer Security (SSL/TLS) 2/2 PKI method of encryption is used for SSL parameter negotiations The most important items negotiated is the encryption algorithm to be used during data transmission The algorithm chosen will be one that uses the same key at each end of the secure connection (symmetric encryption) © Company Insurance Zurich 3/9/2009 Secure FTP Overview 8 SSL Handshake 1/3 Secure Sockets Layer/Transport Layer Security 1. The client sends a CLIENT_HELLO command to the server, which includes: • The highest SSL and TLS version supported by the client. • Ciphers supported by the client. The ciphers are listed in order of preference. • Data compression methods that are supported by the client. • The session ID. If the client is starting a new SSL session, the session ID is 0. • Random data that is generated by the client for use in the key generation process. 2. The server sends a SERVER_HELLO command to the client, which includes: • The SSL or TLS version that will be used for the SSL session. • The cipher that will be used for the SSL session. • Data compression method that will be used for the SSL session. SSL Version 3 and TLS have no compression algorithms defined at this time. • The session ID for the SSL session. • Random data that is generated by the server for use in the key generation process. © Company Insurance Zurich 3/9/2009 Secure FTP Overview 9 SSL Handshake 2/3 Secure Sockets Layer/Transport Layer Security 3. The server sends CERTIFICATE command. This command includes the server's certificate and, optionally, a chain of certificates beginning with the certificate of the certificate authority (CA) that assigned the server's certificate. 4. The server sends SERVER_DONE command. This command indicates that the server has completed this phase of the SSL handshake. If client authentication will be performed, additional commands flow between the client and the server following the SERVER_DONE command. 5. The client sends CLIENT_KEY_EXCHANGE command. This command contains the premaster secret that was created by the client and was then encrypted using the server's public key. Both the client and the server generate the symmetric encryption keys on their own using the premaster secret and the random data that is generated from the SERVER_HELLO and CLIENT_HELLO commands. 6. The client sends CHANGE_CIPHER_SPEC command. This command indicates that the contents of subsequent SSL record data sent by the client during the SSL session will be encrypted. The 5-byte SSL record headers are never encrypted. 7. The client sends FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the client and the server up to this point. This command is sent to validate that none of the commands sent previously, which flow between the client and the server unencrypted, were altered in flight. © Company Insurance Zurich 3/9/2009 Secure FTP Overview 10 SSL Handshake 3/3 Secure Sockets Layer/Transport Layer Security 8. The server sends CHANGE_CIPHER_SPEC command. This command indicates that all subsequent data sent by the server during the SSL session will be encrypted. 9. The server sends FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the server and the client up to this point. © Company Insurance Zurich 3/9/2009 Secure FTP Overview 11 Server authentication Secure Sockets Layer/Transport Layer Security Server authentication is the minimum amount of security provided by SSL The server sends its public key, a signature and additional information so the client can confirm the identity of the server The complete package is called a digital certificate which conforms to the X.509 standard. A certificate can be self-signed or created by a well-known Certificate Authority (CA) Most client key rings have been primed with several well-known CA’s certificates The self-signed certificate needs to be added to the client’s list of signer certificates The gskkyman utility or RACF Common Keyring support can be used to manage the keys and certificates. © Company Insurance Zurich 3/9/2009 Secure FTP Overview 12 Client authentication Secure Sockets Layer/Transport Layer Security Client authentication provides additional authentication and access control by checking client certificates at the server. The server authenticates the client by receiving the client’s certificate during the SSL handshake Three different levels of client authentication are available. Level 1 – Client authentication is done by SSL using a gskkyman or a RACF key ring. – The CA certificate in RACF must be set to TRUST and connected to the appropriate RACF key ring Level 2 – Additionally to level 1 authentication the client certificate must be registered with RACF and mapped to a user ID. Level 3 – Authentication provides, in addition to level 1 and level 2 support, the capability to restrict access to the server based on the user ID returned from RACF – The SERVAUTH RACF class is used to restrict access to the server based on client user ID © Company Insurance Zurich 3/9/2009 Secure FTP Overview 13 Encryption algorithms Secure Sockets Layer/Transport Layer Security After authentication is performed, the client and server must agree on a symmetric encryption method and generate a single encryption key to use for data encryption using the PKI method of encryption. During the SSL handshake the client sends a list of encryption algorithms it is willing to use. The server submits its list and the SSL subsystem picks an algorithm all parties support. Once the symmetric encryption algorithm and a single encryption key are chosen, all data exchanges use this algorithm and key instead of the PKI method of encryption System SSL uses the Integrated Cryptographic Service Facility (ICSF) if it is available. ICSF provides hardware cryptographic support which will be used instead of the System SSL software algorithms. © Company Insurance Zurich 3/9/2009 Secure FTP Overview 14 FTP with AT-TLS security support 1/2 Application Transparent TLS (AT-TLS) provides TLS support for existing clear-text socket applications without requiring any application changes. AT-TLS support is policy-driven and is managed by a Policy Agent. The FTP server and client can use AT-TLS to manage TLS security. FTP is a controlling AT-TLS application which means that the application starts and stops security on the connection, through the AT-TLS mechanism FTP relies on the definition of AT-TLS policies that Policy Agent downloads into the TCP/IP stack © Company Insurance Zurich 3/9/2009 Secure FTP Overview 15 FTP with AT-TLS security support 2/2 AT-TLS has considerable advantages over standard TLS/SSL for the FTP environment: Certificate labels, thus eliminating the need to rely only on the presence of a default certificate in a key ring Certificate revocation lists (CRLs) Support SSL Session Key Refresh Trace decrypted SSL data for FTP in a data trace Receive more detailed diagnostic messages in syslogd © Company Insurance Zurich 3/9/2009 Secure FTP Overview 16 FTP with IPSec IPSec is a suite of protocols and standards defined by the Internet Engineering Task Force (IETF) to provide an open architecture for security at the IP networking layer of TCP/IP. It is the most commonly used protocol for implementing a Virtual Private Network (VPN).
Recommended publications
  • Secure Shell Encrypt and Authenticate Remote Connections to Secure Applications and Data Across Open Networks

    Secure Shell Encrypt and Authenticate Remote Connections to Secure Applications and Data Across Open Networks

    Product overview OpenText Secure Shell Encrypt and authenticate remote connections to secure applications and data across open networks Comprehensive Data security is an ongoing concern for organizations. Sensitive, security across proprietary information must always be protected—at rest and networks in motion. The challenge for organizations that provide access to applications and data on host systems is keeping the data Support for Secure Shell (SSH) secure while enabling access from remote computers and devices, whether in a local or wide-area network. ™ Strong SSL/TLS OpenText Secure Shell is a comprehensive security solution that safeguards network ® encryption traffic, including internet communication, between host systems (mainframes, UNIX ™ servers and X Window System applications) and remote PCs and web browsers. When ™ ™ ™ ™ Powerful Kerberos included with OpenText Exceed or OpenText HostExplorer , it provides Secure Shell 2 (SSH-2), Secure Sockets Layer (SSL), LIPKEY and Kerberos security mechanisms to ensure authentication security for communication types, such as X11, NFS, terminal emulation (Telnet), FTP support and any TCP/IP protocol. Secure Shell encrypts data to meet the toughest standards and requirements, such as FIPS 140-2. ™ Secure Shell is an add-on product in the OpenText Connectivity suite, which encrypts application traffic across networks. It helps organizations achieve security compliance by providing Secure Shell (SSH) capabilities. Moreover, seamless integration with other products in the Connectivity suite means zero disruption to the users who remotely access data and applications from web browsers and desktop computers. Secure Shell provides support for the following standards-based security protocols: Secure Shell (SSH)—A transport protocol that allows users to log on to other computers over a network, execute commands on remote machines and securely move files from one machine to another.
  • Telnet Client 5.11 Ssh Support

    Telnet Client 5.11 Ssh Support

    TELNET CLIENT 5.11 SSH SUPPORT This document provides This document describes how to install and configure SSH support in Wavelink Telnet Client 5.11. information on the SSH support available in Telnet Client 5.11 OVERVIEW OF SSH SUPPORT Secure Shell (SSH) is a protocol developed for transmitting private information over the Internet. SSH OVERVIEW encrypts data that is transferred over the Telnet session. • Overview of SSH The Telnet Client supports SSH version 1 and 2 and will automatically select the most secure protocol Support that the SSH server supports. • Installing Windows SSH Support This document describes the following: • Configuring the host • Installing Windows SSH support utility profile for SSH • Configuring the host profile for SSH support support • Deploying Windows • Deploying Windows SSH support to the device through Avalanche or ActiveSync SSH Support • Revision History INSTALLING WINDOWS SSH SUPPORT Installing SSH support is a two-step process. First, install SSH support on the PC from which you will deploy Telnet. Once you install SSH support on the PC, use Avalanche or ActiveSync to deploy the utility to the device. To install SSH support on your PC: 1. Obtain the installation executable for SSH support. NOTE: To obtain the Wavelink SSH support utility install, go to http://www.wavelink.com/downloads/ files/sshagreement.aspx. 2. Install SSH support on the PC from which you will deploy the Telnet Client. CONFIGURING THE HOST PROFILE FOR SSH SUPPORT SSH support is configured from the Host Profiles window of the configuration utility. NOTE: SSH is only an active option if SSH support has been installed on the PC running the Telnet Client configuration utility.
  • Networking Telnet

    Networking Telnet

    IBM i Version 7.2 Networking Telnet IBM Note Before using this information and the product it supports, read the information in “Notices” on page 99. This edition applies to IBM i 7.2 (product number 5770-SS1) and to all subsequent releases and modifications until otherwise indicated in new editions. This version does not run on all reduced instruction set computer (RISC) models nor does it run on CISC models. This document may contain references to Licensed Internal Code. Licensed Internal Code is Machine Code and is licensed to you under the terms of the IBM License Agreement for Machine Code. © Copyright International Business Machines Corporation 1998, 2013. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Telnet................................................................................................................... 1 What's new for IBM i 7.2..............................................................................................................................1 PDF file for Telnet........................................................................................................................................ 1 Telnet scenarios...........................................................................................................................................2 Telnet scenario: Telnet server configuration.........................................................................................2 Telnet scenario: Cascaded Telnet
  • SOCKS Protocol Version 6

    SOCKS Protocol Version 6

    SOCKS Protocol Version 6 draft-olteanu-intarea-socks-6-08 Vladimir Olteanu IETF 106 What’s new ● DNS provided by SOCKS ● Options for Happy Eyeballs at the proxy Clients need DNS-like features ● A and AAAA – LD_PRELOAD for non-SOCKS-aware apps: gedaddrinfo() separate from connect() – Happy Eyeballs: need to do queries separately ● TXT – ESNI ● MX, Service Binding, etc. – <Insert future use case here> Providing DNS-like features ● Individual SOCKS options (removed in -08) – Have to keep up with use cases – Duplicate DNS functionality – Until -07: A, AAAA, PTR ● Having the client use DNS – Hard to convey policies: resolver IPs, plaintext / over TLS / over HTTPS etc., maybe credentials, etc. – Provide a DNS proxy Why not separate DNS from SOCKS? Client Proxy Server HTTP/SOCKS :1080 HTTP :80 DNS :53 Why not separate DNS from SOCKS? Client Proxy Server HTTP/SOCKS :1080 HTTP :80 DNS :53 WHICH TOR CIRCUIT? ● Need context for DNS query – Otherwise: privacy leaks, suboptimal CDN use DNS provided by SOCKS ● Clients make CONNECT request to 0.0.0.0:53 – Proxy needn’t provide a valid bind address ● Plaintext DNS over SOCKS (opt. over TLS) – TCP by default: SOCKS + UDP more cumbersome to use ● Implementation in Sixtysocks – Run separate DNS proxy locally – Translate 0.0.0.0:53 to 127.0.0.1:53 Happy Eyeballs ● RFC 8305: resolve and connect to a server using both IPv4 and IPv6, keep only one connection – Failover from IPv6 to IPv4 – Better responsiveness if one is faster ● Clients can implement Happy Eyeballs locally – Have DNS + CONNECT Happy Eyeballs:
  • New Techniques to Enhance the Capabilities of the Socks Network Security Protocol

    New Techniques to Enhance the Capabilities of the Socks Network Security Protocol

    NEW TECHNIQUES TO ENHANCE THE CAPABILITIES OF THE SOCKS NETWORK SECURITY PROTOCOL Mukund Sundararajan and Mohammad S. Obaidat Computer Science Department, Monmouth University, West Long Branch, NJ, U.S.A. Keywords: Security protocols for computer networks, SOCKS, telecommunications, multicast, UDP tunneling. Abstract: SOCKS is an industry standard network security protocol used in private networks to allow secure traversal of application layer traffic through the boundaries of the network. Standardized by IETF in Request for Comments (RFC) 1928 (Leech et al., 1996) as SOCKS Version 5, this protocol has found widespread use in various security frameworks to allow a variety of application layer protocols to securely traverse a firewall. This paper is the result of research performed on the usability of the protocol in application domains such as multicast. We discuss some of the shortcomings of the SOCKS protocol and provide a framework and the methods for enhancing the capabilities of the protocol in areas such as multicast and advanced TCP and UDP capabilities not addressed by the current standard of the protocol. The methods proposed are being implemented in a reference implementation by the authors. 1 INTRODUCTION Operating in a client server mode, application nodes or computers within a SOCKS protected In today’s global and geographically dispersed network are ‘socksified’ by a socks client library that organizational world, network security is a key provides a transparent abstraction layer between the concern to organizations and individuals. With application and the kernel socket library and hides advances in technology, most of today’s the implementation details of the socks protocol from organizations have their key resources and data the application.
  • NBAR2 Standard Protocol Pack 1.0

    NBAR2 Standard Protocol Pack 1.0

    NBAR2 Standard Protocol Pack 1.0 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 © 2013 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 1 CHAPTER 2 BGP 3 BITTORRENT 6 CITRIX 7 DHCP 8 DIRECTCONNECT 9 DNS 10 EDONKEY 11 EGP 12 EIGRP 13 EXCHANGE 14 FASTTRACK 15 FINGER 16 FTP 17 GNUTELLA 18 GOPHER 19 GRE 20 H323 21 HTTP 22 ICMP 23 IMAP 24 IPINIP 25 IPV6-ICMP 26 IRC 27 KAZAA2 28 KERBEROS 29 L2TP 30 NBAR2 Standard Protocol Pack 1.0 iii Contents LDAP 31 MGCP 32 NETBIOS 33 NETSHOW 34 NFS 35 NNTP 36 NOTES 37 NTP 38 OSPF 39 POP3 40 PPTP 41 PRINTER 42 RIP 43 RTCP 44 RTP 45 RTSP 46 SAP 47 SECURE-FTP 48 SECURE-HTTP 49 SECURE-IMAP 50 SECURE-IRC 51 SECURE-LDAP 52 SECURE-NNTP 53 SECURE-POP3 54 SECURE-TELNET 55 SIP 56 SKINNY 57 SKYPE 58 SMTP 59 SNMP 60 SOCKS 61 SQLNET 62 SQLSERVER 63 SSH 64 STREAMWORK 65 NBAR2 Standard Protocol Pack 1.0 iv Contents SUNRPC 66 SYSLOG 67 TELNET 68 TFTP 69 VDOLIVE 70 WINMX 71 NBAR2 Standard Protocol Pack 1.0 v Contents NBAR2 Standard Protocol Pack 1.0 vi CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 NBAR2 Standard Protocol Pack Overview The Network Based Application Recognition (NBAR2) Standard Protocol Pack 1.0 is provided as the base protocol pack with an unlicensed Cisco image on a device.
  • Configuration and Management Suite Volume 2: Proxies and Proxy Services

    Configuration and Management Suite Volume 2: Proxies and Proxy Services

    Blue Coat® Systems ProxySG® Appliance Configuration and Management Suite Volume 2: Proxies and Proxy Services Version SGOS 5.3.x Volume 2: Proxies and Proxy Services Contact Information Blue Coat Systems Inc. 420 North Mary Ave Sunnyvale, CA 94085-4121 http://www.bluecoat.com/support/contactsupport http://www.bluecoat.com For concerns or feedback about the documentation: [email protected] Copyright© 1999-2008 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other means without the written consent of Blue Coat Systems, Inc. All right, title and interest in and to the Software and documentation are and shall remain the exclusive property of Blue Coat Systems, Inc. and its licensors. ProxyAV™, CacheOS™, SGOS™, SG™, Spyware Interceptor™, Scope™, ProxyRA Connector™, ProxyRA Manager™, Remote Access™ and MACH5™ are trademarks of Blue Coat Systems, Inc. and CacheFlow®, Blue Coat®, Accelerating The Internet®, ProxySG®, WinProxy®, AccessNow®, Ositis®, Powering Internet Management®, The Ultimate Internet Sharing Solution®, Cerberian®, Permeo®, Permeo Technologies, Inc.®, and the Cerberian and Permeo logos are registered trademarks of Blue Coat Systems, Inc. All other trademarks contained in this document and in the Software are the property of their respective owners. BLUE COAT SYSTEMS, INC. DISCLAIMS ALL WARRANTIES, CONDITIONS OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON SOFTWARE AND DOCUMENTATION FURNISHED HEREUNDER INCLUDING WITHOUT LIMITATION THE WARRANTIES OF DESIGN, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL BLUE COAT SYSTEMS, INC., ITS SUPPLIERS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY EVEN IF BLUE COAT SYSTEMS, INC.
  • Guidelines for the Secure Deployment of Ipv6

    Guidelines for the Secure Deployment of Ipv6

    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
  • Secure Shell (SSH)

    Secure Shell (SSH)

    Secure SHell (SSH) © André Zúquete Advanced Network Security SSH (Secure SHell, RFC 4251): Goals An application and a secure communication protocol over TCP/IP Allows the establishment of secure remote sessions Replacing insecure telnet/rlogin sessions Allows the multiplexing of many data flows over a secure session Secure tunneling Security mechanisms Confidentiality and integrity control Including data flow hiding Key distribution Session key Mutual authentication Server host (or server) Client user © André Zúquete Advanced Network Security SSH: Exploitation Secure remote logins Instead of telnet/rlogin Secure remote command execution Instead of rsh/rcmd/rexec Secure file transfer and backup Secure FTP / Secure copy Port forwarding and tunneling For adding security to multiple data flows through a single SSH session © André Zúquete Advanced Network Security SSH: History Created by Tatu Ylönen First version released in 1995 Second version released in 1998 Not compatible with the previous one Björn Grönvall developed OSSH in 1999 From the last open source release of SSH OpenBSD launched the OpenSSH project (www.openssh.org ) Extending OSSH © André Zúquete Advanced Network Security SSH: Architecture Client-server architecture Server usually on port 22 Services include login, ftp, file copy and TCP tunneling © André Zúquete Advanced Network Security SSH: Protocols Transport Layer Protocol (RFC 4253) Key distribution Session key computing with ephemeral DH values Server authentication With pre-distributed,
  • What Is SOCKS?

    What Is SOCKS?

    Version 2.0 What is SOCKS? An explanation of the SOCKS protocol and application proxy gateway systems B. Scott Wilson, CISSP IBM Global Services, Network Services What is SOCKS? ! SOCKS is a generic proxy protocol for TCP/IP-based networking applications. ! The SOCKS protocol provides a flexible framework for developing secure communications by easily integrating other security technologies. 2 How does it Work? ! When an application client needs to connect to an application server, the client machine connects to a SOCKS proxy server. The proxy server connects to the application server on behalf of the client, and relays data between the client and the application server. ! For the application server, the proxy server is the client. 3 The SOCKS Protocol ! SOCKS version 5 is an IETF approved standard protocol implementation (RFC 1928). ! SOCKS includes two components, the SOCKS server and the SOCKS client. The SOCKS server is implemented at the application layer, while the SOCKS client is implemented between the application and transport layers (see next slide). ! The basic purpose of the protocol is to enable hosts on one side of a SOCKS server to gain access to hosts on the other side of a SOCKS Server, without requiring direct “IP-reachability”. 4 SOCKS and the OSI Layer Model 5 Functions of SOCKS ! The SOCKS protocol performs four functions: " Making connection requests " Setting up proxy circuits " Relaying application data " Performing user authentication (optional) 6 Features of SOCKS ! Transparent network access across multiple proxy servers ! Easy deployment of authentication and encryption methods ! Rapid deployment of new network applications ! Simple network security policy management 7 Benefits of SOCKS ! A single communication protocol authenticates users and establishes the communication channel ! SOCKS is application independent ! Can be used with either UDP or TCP based protocols; even supports redirection of ICMP! ! Bi-directional support and intrinsic NAT, for added security and anti-spoofing.
  • Table of Contents I. Introduction A. What Is the Internet

    Table of Contents I. Introduction A. What Is the Internet

    Table of Contents I. Introduction a. What is the Internet …………………………………………………….... 3 b. Why do you need to be anonymous in the internet? ………………… 3 II. The ways for determining you on the internet …………………………. 7 a. IP Address …………………………………………………………………. 7 b. Cookies …………………………………………………………………… 7 c. Browser …………………………………………………………………… 8 d. JavaScript, ActiveX, and Flash Support ………………………………. 8 III. Who and why is it necessary to be anonymous in the internet …… 9 IV. Top 10 Frequently Asked Questions about Internet Security ……... 11 V. VPN …………………………………………………………………………… 16 a. What is VPN ……………………………………………………………... 16 b. How VPN does helps in internet security? ……….….….….….….…. 16 c. The other uses and advantages of using VPN …..….….….….….….…. 16 d. How VPN does operate? ……….….….….….….….….….….….….….….. 17 e. VPN Protocols ….….….….….….….….….….….….….….….….………. 17 i. OpenVPN ….….….….….….….….….….….….….….….….……… 17 ii. PPTP ….….….….….….….….….….….….….….….….….……...... 18 iii. L2TP ….….….….….….….….….….….….….….….….….………… 18 iv. Single ….….….….….….….….….….….….….….….….….……… 19 v. Double ….….….….….….….….….….….….….….….….….……… 19 vi. Triple ….….….….….….….….….….….….….….….….….………… 19 f. Table: Comparison of VPN Protocols ….….….….….….….….….………. 19 g. The Best VPN Protocol ….….….….….….….….….….….….….….……… 20 VI. SOCKS ………….….….….….….….….….….….….….….….….….….……… 21 a. What is SOCKs? ………….….….….….….….….….….….….….….…… 21 b. What are uses of SOCKs? ……….….….….….….….….….….….………. 21 c. How SOCKs does operate? …….….….….….….….….….…..….……….. 22 d. SOCKS Specifications …..….….….….….….….….….….….….….………
  • Use Putty to Establish a Telnet Connection to ENE Through GNE

    Use Putty to Establish a Telnet Connection to ENE Through GNE

    Use PuTTY to Establish a Telnet Connection to ENE Through GNE Document ID: 66069 Contents Introduction Prerequisites Requirements Components Used Conventions Background Information Topology Procedure GNE Configuration PuTTY Establish a Telnet Session with the ENE Establish a Telnet Session to an ML Series Card on the ENE Related Information Introduction This document describes how you can establish a Telnet connection to the End−point Network Element (ENE) or the Multi−Layer (ML) Series cards on the ENE through a Gateway Network Element (GNE) from external networks. In order to do so, you can use PuTTY, which is an application that supports SOCKS version 5. The GNE serves as an intermediary for connection with the ENEs. The GNE functions as a proxy firewall and an IP−address multiplexer, which allows connections to ENEs from areas outside internal networks. Prerequisites Requirements Cisco recommends that you have knowledge of these topics: • Cisco ONS 15454 • Cisco ONS 15454 ML−Series Ethernet Cards • SOCKS Components Used The information in this document is based on these software and hardware versions: • Cisco ONS 15454 version 4.6.x • Cisco ONS 15454 version 5.x The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command. Conventions Refer to Cisco Technical Tips Conventions for more information on document conventions. Background Information SOCKS is an IETF (Internet Engineering Task Force) approved standard (RFC 1928) generic, proxy protocol for TCP/IP−based networking applications.