SOCKS for PROXY Socks Is a Universal Proxy Protocol for TCP and UDP That Allows Internal Hosts to Securely Pass the Firewall and Authenticates Users

Total Page:16

File Type:pdf, Size:1020Kb

SOCKS for PROXY Socks Is a Universal Proxy Protocol for TCP and UDP That Allows Internal Hosts to Securely Pass the Firewall and Authenticates Users LINUXCOVERSYSADMIN USERSTORY SchlagwortSchlagwortSocks v5 sollte sollte hier hier stehen stehen Schlagwort sollte hier stehen COVER STORY Examining the generic Socks version 5 proxy protocol SOCKS FOR PROXY Socks is a universal proxy protocol for TCP and UDP that allows internal hosts to securely pass the firewall and authenticates users. This article describes the latest version of the Socks proxy protocol and shows how to implement it. BY THOMAS KUHN AND ACHIM LEITNER any firewall admins allow known as a Socks server) authenticates nection uses port 1080 by default. The direct access to the Web from the client and authorizes the client for client sends a Negotiation packet sug- Mthe internal network but are access, sets up the connection to the tar- gesting a few authentication methods more restrictive with other services such get server, and transparently forwards (number in NMETHODS and methods in as FTP or SMTP. They rightfully argue any data sent or received. METHODS). that filter rules that allow a minimum of If the proxy accepts the request (step 2 services and ports are easier to track and Intermediate in Figure 2), it uses a Server Negotiation manage. Application Level Gateways Normally, client applications need to packet to tell the client its preferred (ALGs) provide even more granular con- have integrated Socks support to be able authentication method (METHODS with trol and are typically implemented as to use the proxy, as Socks does affect the exactly one entry). The proxy then pro- proxies (Figure 1a). However, the appli- way protocols interact. However, a wrap- ceeds to authenticate the client (step 3). cation firewall needs a proxy for each per can add Socks support to binaries The exact procedure at this step depends service. using LD_PRELOAD technology. To do on the selected method. The Socks protocol [2] (RFC 1928, Fig- this, the wrapper implements a custom- The client then sends a request to the ure 1b) treads a path between the state- ized socket library. proxy stating which service it requires ful packet filter and the ALG. Socks is The name Socks is derived from (target address DST.ADDR and target implemented in the Dante package [1], Socket, the original working title was port DST.PORT). The Socks proxy evalu- for example. The generic Socks proxy SOCK-et-S. There are two main versions: ates the request, based on the client ID technology leaves the firewall in control Socks v4 and v5. Both protocols insert and the target address, taking an access of applications, separating networks in themselves into the OSI model between control list into consideration in a style the Transport Layer and giving clients a the Transport and Application layers. typical of firewalls. If the client is fixed request port (typically 1080). Version 4 is restricted to handling con- not allowed the type of Clients formulate Socks nection requests, honoring Proxy rules, access it has requested, requests, specifying target and forwarding application data. It does the Socks proxy servers and services not provide any kind of authentication drops the con- (such as HTTP, and is restricted to TCP. Socks v5 adds nection to SMTP, or FTP). robust authentication mechanisms and the client. The Socks extends support to UDP. proxy (also Roundabout Route In a typical Socks scenario, the client might want to access the HTTP service provided by a server on an external net- work. The procedure is shown in Figure 2, the data format in Figure 3, and the field contents are shown in Table 1. The client starts by opening a TCP connection to the Socks proxy (1); the con- www.sxc.hu 62 ISSUE 56 JULY 2005 WWW.LINUX - MAGAZINE.COM Schlagwort sollte hierSocks stehen v5 COVERSYSADMIN STORY request. The client then uses a Bind request within a second connection to SMTP Configuration S1 ask the Socks proxy to open a port for C1 FTP the incoming data connection. Configuration S2 S3 The proxy sends two replies in IRQ Configuration C2 response. The first contains the port and S4 DNS Configuration address at which the Socks server will Intranet Internet Application Level Gateway listen for the incoming connection. The proxy does not send the second reply Figure 1a: If the firewall is implemented as an application level gateway, it separates the inter- until the target server opens a connec- nal and external networks at application level. However, it then needs a proxy for each proto- tion. When this happens, the proxy’s col. reply contains the source address and source port the target machine used to open a connection to it. Finally, the S1 Port 1080 proxy forwards the data from the exter- C1 nal server to the internal client. S2 If you want Socks to act as a UDP S3 proxy, the client first needs to use TCP to C2 S4 contact the proxy and authenticate (Fig- Configuration Intranet Internet ure 4). The CMD it stipulates in this case Socks Proxy is the third value in Table 1: UDP Associ- Figure 1b: In contrast to an ALG, Socks assumes the role of a generic proxy, accepting s con- ate. As the client will actually be using nections for any application protocols on port 1080, authenticating clients, and authorizing UDP to transmit data later on, it needs to transfers. tell the proxy where these packets will be coming from. To do so, the client In any other case, it replies with one or nection from a target server. This sce- adds its own address and port to the multiple server reply packets. nario might seem back-to-front, but it is DST.ADDR and DST.PORT fields. quite normal in the case of the FTP pro- The proxy then opens an internal UDP Addressed tocol in active mode. With FTP, and fol- relay port, allowing the client to send Socks requests and replies can contain lowing best client-server traditions, the packets to the outside world. The client different types of addresses. The proto- client first establishes a connection to reads the address and port for the relay col supports IPv4 and IPv6 addresses, the FTP server; this is known as the con- from the server’s reply to the UDP Asso- along with domain names. The latter trol connection. Whenever a file needs ciate request: BND.PORT and BND. removes the need for the client to per- to be transferred, the server establishes a ADDR. And this is where the client has form a DNS lookup, and the internal net- data connection back to the client. Prior to send any UDP packets destined for the work does not need to resolve external to this, the client needs to tell the server external network. The client wraps its DNS names. which address and port the server own UDP packets in a UDP Request Depending on the client request type, should use. Again, this information is (Figure 3 bottom). The UDP Relay stays that is, depending on the value of CMD sent across the control channel. open for as long as the client keeps the (Figure 2 and Table 1), the address authenticated TCP connection up. details in the Socks server reply have a Upside-Down World different significance. A reply to a CON- Socks can selectively allow this type of Authentic NECT request contains the BND.PORT connection into the internal network. The authentication method can also pro- and BND.ADDR, that is the address at The client opens the control channel to vide trust and integrity between the cli- which the proxy has connected the tar- the server by sending a normal Connect ent and the proxy. The authentication get server. The BND.ADDR address is typically 1. Client Negotiation 6. Server Request not identical to the Socks server address, 2. Server Negotiation Socks Port Bind Port to which the client sent the original 3. Authentication Protocol 1080 7. Server Response request. This constellation, which is 4. Client Request referred to as a multi-homed Socks 5. Server Reply server, is typical of a Socks firewall that 8. Data 8. Data connects two networks. After a success- Client Server ful Connect command, the client and Configuration target server can communicate transpar- Intranet Internet Socks Proxy ently through the proxy; Socks simply forwards any data. Figure 2: When establishing a Socks v5 connection, the client starts by sending a negotiation The client sends a BIND request to packet to the Socks proxy (1). The client authenticates (3); the proxy then establishes the indicate that it expects an incoming con- connection to the target server (6) and forwards data (8). WWW.LINUX - MAGAZINE.COM ISSUE 56 JULY 2005 63 COVERSYSADMIN STORY SchlagwortSocks v5 sollte hier stehen Schlagwort sollte hier stehen COVER STORY Dante is developed by a Norwegian con- Client Negotiation VER NMETHOD METHODS sultancy called Inferno Nettverk A/ S, Client Socks- 1 1 1-255 Server who also have commercial modules for Server Negotiation bandwidth control and port/ forwarding VER METHODS Client Socks- Server 1 1 monitoring. Client Request This said, the free version is typically VER CMD RSVATYP DST.ADDR DST.PORT Client Socks- variable 2 fine for most tasks. Besides providing Server 1 1 1 1 Socks and MSproxy services, it can also Server Reply VER REP RSV ATYP BND.ADDR BND.PORT act as a HTTP proxy, authenticate users Client Socks- variable 2 Server 1 1 1 1 based on usernames and passwords, or UDP-Request via Pluggable Authentication Module. RSV FRAGATYP DST.ADDR DST.PORT DATA Client Socks- 2 1 1 variable 2 variable Server Support for interface names in the con- figuration file allows it to support DHCP. Figure 3: Socks version 5 uses five packet types: Client Negotiation, Server Negotiation, Client Request, Server Reply, and UDP Request.
Recommended publications
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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
    [Show full text]
  • 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:
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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,
    [Show full text]
  • 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.
    [Show full text]
  • 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 …..….….….….….….….….….….….….….………
    [Show full text]
  • 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.
    [Show full text]