IP Address Basics

What is IP
An IP address is a number that uniquely identifies every host on an IP network. IP addresses operate at the Network layer of the TCP/IP protocol stack, so they are independent of lower-level Data Link layer MAC addresses, such as Ethernet MAC addresses.
IP addresses are 32-bit binary numbers, which means that theoretically, a maximum of something in the neighborhood of 4 billion unique host addresses canexist throughout the Internet. However, due to the enormous growth of the Internet and the resulting depletion of the address space, a new addressing system (IPv6), using 128 bits for the address, was developed. You’d think that would be enough, but TCP/IP places certain restrictions on how IP addresses are allocated. These restrictions severely limit the total number of usable IP addresses, and today, about half of the total available IP addresses have already been assigned. The Internet Assigned Numbers Authority (IANA) manages the IP address space allocations globally. IANA works in cooperation with five Regional Internet Registries (RIRs) to allocate IP address blocks to Local Internet Registries (Internet service providers) and other entities. However, new techniques for working with IP addresses have helped to alleviate this problem, and a new standard for 128-bit IP addresses (known as IPv6) is on the verge of winning acceptance.
Understanding IP Adress
IP stands for Internet Protocol, and its primary purpose is to enable communications between networks. As a result, a 32-bit IP address actually consists of two parts:
The network ID (or network address) identifies the network on which a host computer can be found.
The host ID (or host address) identifies a specific device on the network indicated by the network ID.
Most of the complexity of working with IP addresses has to do with figuring out which part of the complete 32-bit IP address is the network ID and which part is the host ID. The original IP specification uses a system called address classes to determine which part of the IP address is the network ID and which part is the host ID. A newer system, known as classless IP addresses (IP6) is rapidly taking over the address classes system.
IPv4 addresses are usually represented in dot-decimal notation (four numbers, each ranging from 0 to 255, separated by dots, e.g. 208.77.188.166). Each part represents 8 bits of the address, and is therefore called an octet. In less common cases of technical writing, IPv4 addresses may be presented in hexadecimal, octal, or binary representations. When converting, each octet is usually treated as a separate number. In dotted-decimal notation, each group of eight bits, known as an octet, is represented by its decimal equivalent. For example, consider the following
binary IP address:
11000000101010001000100000011100
The dotted-decimal equivalent to this address is:
192.168.136.28
Here, 192 represents the first eight bits (11000000), 168 the second set of eight bits (10101000), 136 the third set of eight bits (10001000), and 28 the last set of eight bits (00011100). This is the format in which you’ll usually see IP addresses represented.

COMMON SSH USES

SSH was originally designed as a replacement for less-secure Unix commands. Telnet, FTP, rlogin, rcp, and rsh provide login access, file transfer functionality, and remote command execution, but they transmit passwords in plaintext. The systems are also vulnerable to TCP hijacking (and UDP hijacking, in the case of FTP). SSH provides all of these functionalities over an encrypted channel. For example, the OpenSSH client, ssh, supports command-line options for performing these operations. SSH also provides support for arbitrary port forwarding and automated system usage.
Remote Login
Using OpenSSH’s ssh without any command options provides a login prompt. The basic usage is ssh hostname or ssh user@hostname. These commands establish an SSH tunnel to the server, hostname, using the account name user. When creating a command-line shell, the SSH client provides both application layer and presentation layer functionality.
Remote Command Execution
The OpenSSH client permits operating similar to the BSD remote-shell command, rsh. After specifying the user and hostname, any other options are treated as a command. The command is executed immediately after logging in. For example, the command ssh user@hostname ls will remotely log in to hostname as user and execute the command ls. The file streams STDIN, STDOUT, and STDERR (standard input, output, and error) are passed across the SSH tunnels, so the output from ls is transmitted back to the client. Specifying no command is the same as specifying the user’s login shell.
File Transfers
There are two methods for performing SSH file transfers. The first method uses remote command execution. In effect, the tunnel is used to pass the file. The second method uses SSH subsystems. The SSH server permits the execution of well-defined applications. This is similar to the Unix inetd system, where different network ports are used to run different applications.
Port Forwarding
Although SSH forwards streams such as STDIN, STDOUT, and STDERR, it can
also forward TCP ports. Using the OpenSSH options -R and -L, a port on the local
system can be passed to the remote end, and vice versa.
Automated Systems
SSL is commonly used by automated systems for establishing secure connections. However, SSL has many limitations when used by automated systems. For example, SSL clients are vulnerable to MitM attacks, DNS poisoning, and risks from handling invalid certificates.
In simple you can say that SSH can be used for the following purposes:

• for login to a shell on a remote host (replacing Telnet and rlogin)
• for executing a single command on a remote host (replacing rsh)
• for copying files from a local server to a remote host.
  
• in combination with SFTP, as a secure alternative to FTP file transfer
• in combination with rsync to backup, copy and mirror files efficiently and securely
• for port forwarding or tunneling a port (not to be confused with a VPN which routes packets between different networks or bridges two broadcast domains into one.).
• for using as a full-fledged encrypted VPN. Note that only OpenSSH server and client supports this feature.
• for forwarding X11 through multiple hosts
• for browsing the web through an encrypted proxy connection with SSH clients that support the SOCKS protocol.
• for automated remote monitoring and management of servers
• for securely mounting a directory on a remote server as a filesystem on a local computer using SSHFS.

Secure Shell or SSH

Secure Shell or SSH is a point-to-point tunneling protocol that is designed to pass encrypted traffic between two specific hosts. Along with tunneling traffic at the presentation layer, SSH also can provide application layer functionality, including a login shell similar to telnet (over the encrypted tunnel), and FTP-type services. The sftp system is an implementation of an FTP-like protocol over SSH. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception.
The SSH protocol addresses each of the basic security concepts. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. Note that SSH is a protocol that can be used for many applications. Some of the applications may require features that are only available or compatible with specific SSH clients or servers. For example, using the SSH protocol to implement a VPN is possible, but presently only with the OpenSSH server and client implementation.
Confidentiality: Each SSH connection is encrypted, preventing an eavesdropper from viewing information. For added security, SSH periodically reexchanges keys to ensure that a compromise of one set of keys does not compromise the entire session. In contrast, CTCP, IPsec, and IPv6 only exchange keys at the beginning of the connection.
Authentication: Before establishing a connection, the client must authenticate the server and the server must authenticate the client. Client authentication can be any combination of certificates (keys), passwords, or digital tokens. Although SSH is usually used with one-part authentication (a password or a key), it can support two- and three-part authentication systems. The server only uses a certificate to authenticate with the client.
Authorization: SSH limits the traffic that can enter the tunnel and can restrict how data exits the tunnel. For remote login access, SSH restricts authorization to the user’s login privileges.
Integrity: SSH uses encryption and cryptographic checksums to validate each packet. Any packet that fails an integrity check is viewed as an attack, which terminates the connection.
Nonrepudiation: Each packet is cryptographically signed using an HMAC, ensuring that the data actually came from the sender. SSH has three primary uses: establish a secure network tunnel, provide a VPN with port-forwarding characteristics, and supply application-layer login functionality.

SSL Communication Flow

The different negotiations used by SSL, including cryptographic algorithms, key exchanges, and certificates, are performed concurrently.
Step 1: The client sends a hello record that includes the version of SSL being used (usually TLS 1.0), a list of viable cipher specifications, and a random challenge.
Step 2: The server responds with the selected cipher set and either a server certificate
(server-side certificate) or part of a key exchange. The server may also request a certificate from the client (client-side certificate). The server generates a response to the random challenge that can be validated by the client. This allows the client to identify the server—preventing potential MitM attacks between the client and the server. This does not validate the server; it only prevents a MitM from hijacking the established connection.
Step 3: If the server provides a certificate, then the client contacts a certificate authority (CA) and validates the certificate. Although it is considered secure for the client to validate the certificate, there is nothing in SSL requiring certificate validation. Contacting a CA can add time to the initial connection. If speed is an issue, then the client may choose to not validate the server’s certificate. In addition, some cipher sets, such as SSL3-NULL-MD5 and SSL3-RC4-MD5, do not require a server certificate.
Step 4: The client responds to the server, initiating a key exchange. If a clientside certificate is available, then the client may provide it. (If the server requests a client-side certificate, then one must be provided.) If the server provides a certificate, then the client also provides a message encrypted with the certificate. Similar to Step 2, this allows the server to identify but not validate the client.
Step 5: If the client provides a certificate to the server, then the server may contact a CA to authenticate the client. As with Step 3, the server is not required to validate the client, but servers usually validate client-side certificates.
Step 6: The server sends an encrypted handshake to complete the validation process. At this point, the negotiations and exchanges are complete; the clientand server are both authenticated and validated. An attacker cannot act as a MitM or impersonate the client and server. All further communication uses the agreed upon symmetrical encryption algorithm, which is seeded with the negotiated key exchange values.

Simple TLS handshake

A simple connection example , illustrating a full handshake, follows:

• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
• The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite, and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).
• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
• The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.)
• The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".
• The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol, and has type 20, and not 22.
• Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
• The server will attempt to decrypt the client's Finished message, and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
• Finally, the server sends a ChangeCipherSpec and its encrypted Finished message, and the client performs the same decryption and verification.
• At this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will be encrypted.

What is The Secure Socket Layer (SSL)

The Secure Socket Layer (SSL) protocol provides a framework for passing information through an authenticated and encrypted tunnel. Each SSL connection defines a point-to-point tunnel between a client and a server. The SSL protocol operates within the presentation layer and allows the client and server to negotiate authentication, encryption, and checksum algorithms.
The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet. SSL operates in modular fashion. It is extensible by design, with support for forward and backward compatibility and negotiation between peers. SSL, by itself, is a system for negotiating protocols. SSL does not provide security nor natively include cryptography; there is no security from SSL by itself. The security in SSL comes from the negotiated protocols. For example, the client may support DES, 3DES, and AES encryption, whereas the server supports 3DES and RC2. Using SSL, both systems can negotiate communication using their common 3DES encryption algorithm. A variety of authentication, encryption, and checksum functions may be incorporated into SSL. SSL is used to tunnel plaintext data through an encrypted tunnel. Application-layer protocols that normally transmit unencrypted data gain encryption, authentication, validation, and nonrepudiation by using SSL. For example, the Web uses HTTP for transmitting and receiving HTML data normally via plaintext transfers. HTTP over SSL is called HTTPS. It uses SSL to encrypt the Web requests and replies. HTTPS is the most common use of SSL. Other uses include stelnet and sftp—telnet and FTP over SSL. Because SSL is a presentation-layer protocol, any application-layer protocol
may use SSL. Although most SSL-enabled applications explicitly link to an SSL library,stand-alone SSL applications can proxy application data through an SSL connection. Example generic proxies include s_client and s_server from OpenSSL, and the stand-alone Stunnel application (http://www.stunnel.org/).
Several versions of the protocols are in wide-spread use in applications like web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).
SSL v2 is flawed in a variety of ways:
* Identical cryptographic keys are used for message authentication and encryption.
* MACs are unnecessarily weakened in the "export mode" required by U.S. export restrictions (symmetric key length was limited to 40 bits in Netscape and Internet Explorer).
* SSL v2 has a weak MAC construction and relies solely on the MD5 hash function.
* SSL v2 does not have any protection for the handshake, meaning a man-in-the-middle downgrade attack can go undetected.
* SSL v2 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL v3 fixes this problem by having an explicit closure alert).
* SSL v2 assumes a single service, and a fixed domain certificate, which clashes with the standard feature of virtual hosting in webservers. This means that most websites are practically impaired from using SSL. TLS/SNI fixes this but is not deployed in webservers as yet.