Infor

Question 1

Contract Fraud

Question 2

SSL

Question 3

Rama Database

Question 4

SQLite

Question 5

Access Control

Question 6

Authorization

Question 7

SSH - Secure Shell Protocol

Answer 7

The Secure Shell Protocol is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution. SSH applications are based on a client–server architecture, connecting an SSH client instance with an SSH server. Wikipedia

Purpose: secure connection, remote access
Port(s): 22

OSI layer: Transport layer through application layer

SSH, or Secure Shell, is a remote administration protocol that allows users to control and modify their remote servers over the Internet. The service was created as a secure replacement for the unencrypted Telnet and uses cryptographic techniques to ensure that all communication to and from the remote server happens in an encrypted manner. It provides a mechanism for authenticating a remote user, transferring inputs from the client to the host, and relaying the output back to the client.

Question 8

Web Serves

Question 9

Version to Version

Question 10

There are three different encryption technologies used by SSH:

Answer 10

Symmetrical encryption
Asymmetrical encryption
Hashing.

Question 11

SSH - Symmetrical Encryption

Answer 11

Symmetrical encryption is often called shared key or shared secret encryption. There is usually only one key that is used, or sometimes a pair keys where one key can easily be calculated using the other key.
Symmetric keys are used to encrypt the entire communication during a SSH Session. Both the client and the server derive the secret key using an agreed method, and the resultant key is never disclosed to any third party. The process of creating a symmetric key is carried out by a key exchange algorithm. What makes this algorithm particularly secure is the fact that the key is never transmitted between the client and the host. Instead, the two computers share public pieces of data and then manipulate it to independently calculate the secret key. Even if another machine captures the publically shared data, it won’t be able to calculate the key because the key exchange algorithm is not known.
It must be noted, however, that the secret token is specific to each SSH session, and is generated prior to client authentication. Once the key has been generated, all packets moving between the two machines must be encrypted by the private key. This includes the password typed into the console by the user, so credentials are always protected from network packet sniffers.
A variety of symmetrical encryption ciphers exist, including, but not limited to, AES (Advanced Encryption Standard), CAST128, Blowfish etc. Before establishing a secured connection, the client and a host decide upon which cipher to use, by publishing a list of supported cyphers in order of preference. The most preferred cypher from the clients supported cyphers that is present on the host’s list is used as the bidirectional cypher.
For example, if two Ubuntu 14.04 LTS machines are communicating with each other over SSH, they will use aes128-ctr as their default cipher.

Question 12

SSH - Asymmetric Encryption

Answer 12

Unlike symmetrical encryption, asymmetrical encryption uses two separate keys for encryption and decryption. These two keys are known as the public key and the private key. Together, both these keys form a public-private key pair.
The public key, as the name suggest is openly distributed and shared with all parties. While it is closely linked with the private key in terms of functionality, the private key cannot be mathematically computed from the public key. The relation between the two keys is highly complex: a message that is encrypted by a machine’s public key, can only be decrypted by the same machine’s private key. This one-way relation means that the public key cannot decrypt its own messages, nor can it decrypt anything encrypted by the private key.
The private key must remain private i.e. for the connection to be secured, no third party must ever know it. The strength of the entire connection lies in the fact that the private key is never revealed, as it is the only component capable of decrypting messages that were encrypted using its own public key. Therefore, any party with the capability to decrypt publically signed messages must possess the corresponding private key.
Unlike the general perception, asymmetrical encryption is not used to encrypt the entire SSH session. Instead, it is only used during the key exchange algorithm of symmetric encryption. Before initiating a secured connection, both parties generate temporary public-private key pairs, and share their respective private keys to produce the shared secret key.
Once a secured symmetric communication has been established, the server uses the clients public key to generate and challenge and transmit it to the client for authentication. If the client can successfully decrypt the message, it means that it holds the private key required for the connection. The SSH session then begins.

Question 13

SSH - One way Hashing

Answer 13

One-way hashing is another form of cryptography used in Secure Shell Connections. One-way-hash functions differ from the above two forms of encryption in the sense that they are never meant to be decrypted. They generate a unique value of a fixed length for each input that shows no clear trend which can exploited. This makes them practically impossible to reverse. It is easy to generate a cryptographic hash from a given input, but impossible to generate the input from the hash. This means that if a client holds the correct input, they can generate the crypto-graphic hash and compare its value to verify whether they possess the correct input.
SSH uses hashes to verify the authenticity of messages. This is done using HMACs, or Hash-based Message Authentication Codes. This ensures that the command received is not tampered with in any way.
While the symmetrical encryption algorithm is being selected, a suitable message authentication algorithm is also selected. This works in a similar way to how the cipher is selected, as explained in the symmetric encryption section.
Each message that is transmitted must contain a MAC, which is calculated using the symmetric key, packet sequence number, and the message contents. It is sent outside the symmetrically encrypted data as the concluding section of the communication packet.

Question 14

How Does SSH Work with These Encryption Techniques?

Answer 14

The way SSH works is by making use of a client-server model to allow for authentication of two remote systems and encryption of the data that passes between them.
SSH operates on TCP port 22 by default (though this can be changed if needed). The host (server) listens on port 22 (or any other SSH assigned port) for incoming connections. It organizes the secure connection by authenticating the client and opening the correct shell environment if the verification is successful.
The client must begin the SSH connection by initiating the TCP handshake with the server, ensuring a secured symmetric connection, verifying whether the identity displayed by the server match previous records (typically recorded in an RSA key store file), and presenting the required user credentials to authenticate the connection.
There are two stages to establishing a connection: first both the systems must agree upon encryption standards to protect future communications, and second, the user must authenticate themselves. If the credentials match, then the user is granted access.

Question 15

Session Encryption Negotiation

Answer 15

When a client tries to connect to the server via TCP, the server presents the encryption protocols and respective versions that it supports. If the client has a similar matching pair of protocol and version, an agreement is reached and the connection is started with the accepted protocol. The server also uses an asymmetric public key which the client can use to verify the authenticity of the host.
Once this is established, the two parties use what is known as a Diffie-Hellman Key Exchange Algorithm to create a symmetrical key. This algorithm allows both the client and the server to arrive at a shared encryption key which will be used henceforth to encrypt the entire communication session.
Here is how the algorithm works at a very basic level:
Both the client and the server agree on a very large prime number, which of course does not have any factor in common. This prime number value is also known as the seed value.
Next, the two parties agree on a common encryption mechanism to generate another set of values by manipulating the seed values in a specific algorithmic manner. These mechanisms, also known as encryption generators, perform large operations on the seed. An example of such a generator is AES (Advanced Encryption Standard).
Both the parties independently generate another prime number. This is used as a secret private key for the interaction.
This newly generated private key, with the shared number and encryption algorithm (e.g. AES), is used to compute a public key which is distributed to the other computer.
The parties then use their personal private key, the other machine’s shared public key and the original prime number to create a final shared key. This key is independently computed by both computers but will create the same encryption key on both sides.
Now that both sides have a shared key, they can symmetrically encrypt the entire SSH session. The same key can be used to encrypt and decrypt messages (read: section on symmetrical encryption).
Now that the secured symmetrically encrypted session has been established, the user must be authenticated.

Question 16

SSH - Authenticating the User

Answer 16

The final stage before the user is granted access to the server is authenticating his/her credentials. For this, most SSH users use a password. The user is asked to enter the username, followed by the password. These credentials securely pass through the symmetrically encrypted tunnel, so there is no chance of them being captured by a third party.
Although passwords are encrypted, it is still not recommended to use passwords for secure connections. This is because many bots can simply brute force easy or default passwords and gain access to your account. Instead, the recommended alternative is SSH Key Pairs.
These are a set of asymmetric keys used to authenticate the user without the need of inputting any password.

Question 17

How to Use PuTTY (SSH Terminal)

Answer 17

SSH, or Secure Shell, is a secure protocol for connecting to a remote server. To establish an SSH connection, you will need an SSH client app like PuTTY.
In this guide, you will learn how to use PuTTY SSH terminal to connect to your hosting account or to a VPS server. That way, you can access and manage your remote machine by executing various commands.
Requirements For Set Up

Next, you will need a bit of information before you can begin using PuTTY. You will need:
Server IP Address
SSH port
SSH username
SSH password

Question 18

How to Use PuTTYgen

Answer 18

PuTTYgen is a tool that creates public and private key pairs. PuTTY stores these key authentications in its .ppk format files. With Windows, you will use the PuTTYgen.exe graphical tool, while with Linux you will use the command line.
To begin, locate PuTTY and open PuTTYgen.
To create a new key pair, click the Generate button near the bottom and begin to move your mouse around within the window. Continue moving your mouse until the green progress bar is full.
It is recommended to use a passphrase as well as saving your private key.

Question 19

Install Public Key on Server

Answer 19

To grant access to an account, you will need to add the new public key to the file named ~/.ssh/authorized_keys.

First, install the public key. Then, log into your server and locate the authorized_keys file. Edit the file and insert the new public key into the file. Save the file and test to see if the login works.

Question 20

How to Use SFTP (SSH File Transfer Protocol)

Answer 20

FTP is the standard method of transferring files or other data between computers, but it’s becoming more and more outdated in today’s security-conscious environment. Fortunately, that’s where SFTP comes in, which is particularly useful for VPS hosting users.
In this guide, we’re going to show how to use SFTP for secure file transfer, talk about some other useful commands and elaborate more on how it works.

Question 21

What is SFTP?

Answer 21

SFTP, or SSH File Transfer Protocol for short, is a much more secure way to move files. Using the SSH protocol, it supports encryption and other security methods used to better protect file transfers. It’s the only secure file transfer protocol that protects against attacks at any point in the data transfer process, making it the preferred protocol.
During file transfer, all of the data is divided into packets and sent through a single secure connection.
Sensitive information will be encrypted and made unreadable when being transferred between the client and the server. In other words, the original content (plaintext) will be replaced by an incoherent string of characters (ciphertext).
Only the recipient with the required decryption key will be able to see the original content. This prevents any unauthorized access during file transfer.
Regular file transfer protocol (FTP) has two different channels to exchange data — the command channel and the data channel. In contrast, SFTP has only one encrypted channel where the data is exchanged in encrypted, formatted packets.

Question 22

SSH?

Answer 22

SSH is the tool of choice for system admins and is used throughout traditional and virtual datacenter environments to enable secure remote access to Unix, Linux and sometimes Windows systems. You can think of the SSH key, which enables this remote access, as a “Swiss Army Knife” for IT teams in that it helps administrators and developers authenticate to systems, build authentication into systems and applications and encrypt the resulting traffic between its users and systems.

During the authentication process, these SSH keys often establish direct, privileged or root access to a variety of critical systems, effectively turning these cryptographic assets into privileged credentials. SSH keys are granted the same access as passwords, but when most people think about securing their privileged credentials, they forget about SSH keys. As a result, these keys can easily fall into the wrong hands and, instead of protecting access to important assets, these keys can become “virtual skeleton keys.” To make matters worse, when an attacker gains access to one privileged SSH key, she or he can access every SSH key stored on that machine and spider the entire company network, often gaining access to all company data. As few as five to 20 unique SSH keys can grant access to an entire enterprise through transitive SSH key trust, providing attackers with privileged access to the organization’s most sensitive systems and data.

Question 23

Four SSH vulnerabilities you should not ignore:

Answer 23

SSH Key Tracking Troubles.
When it Comes to SSH Keys, Sharing Isn’t Caring.
Static SSH Keys, Because “Ain’t Nobody Got Time for Rotation!”
Embedded SSH Keys – The Ones No One Wants to Mess With

Question 24

SSH Key Tracking Troubles

Answer 24

It’s not uncommon for a typical large enterprise with 10,000+ servers to have more than one million SSH keys – making it incredibly difficult, if not impossible, to find and manage each key. Organizations typically accumulate large numbers of SSH keys because end users can create new SSH keys (credentials) or even duplicate them without oversight, unlike certificates or passwords. Once a large number of SSH keys are built up over time, an organization could, for example, easily lose track of these credentials when development servers are migrated into production environments (assuming the development environment credentials are not scrubbed) or when employees leave the company and their keys are not changed. The result? SSH keys left unaccounted for can provide attackers with long-term privileged access to corporate resources. If attackers gain access to a key that is never revoked or rotated, the attackers could have a permanent network entry point and impersonate the user that the SSH key originally belonged to.

Question 25

When it Comes to SSH Keys, Sharing Isn’t Caring.

Answer 25

For the sake of efficiency, SSH keys are often shared or replicated across a common group of employees or servers and infrastructure components. As noted above, as a result of SSH key duplication, as few as five to 20 unique keys can grant access to all machines throughout an enterprise. This approach may make IT teams’ jobs easier in the short-term, but it also makes attackers’ lives easier in the long-term. SSH key duplication creates complicated, many-to-many private public key mappings that significantly reduce security because it is difficult to rotate and revoke a single key without breaking untold other SSH key relationships that share the same key fingerprint. SSH key sharing is also dangerous because it reduces auditability and nonrepudiation.

Question 26

Static SSH Keys, Because “Ain’t Nobody Got Time for Rotation!”

Answer 26

It’s easy to see how rotating one million plus SSH keys would be a logistical nightmare. Many IT administrators and security professionals rarely change and re-distribute keys for fear that a critical component or employee may be forgotten (which could mean anything from a simple inconvenience for a single employee to a major company-wide system outage). These factors typically result in a surge of static SSH keys, opening the door for attackers to compromise an unchanged key, use it to move laterally through the enterprise and gain permanent, unauthorized access to sensitive data and assets.

Question 27

Embedded SSH Keys – The Ones No One Wants to Mess With.

Answer 27

SSH keys are frequently embedded within applications or scripts. Administrators are often fearful of changing them as they do not understand the code the keys are embedded in or are strongly discouraged from rotating them because of the level of coordination required to prevent system outages. As a result, static SSH keys embedded in applications, code and scripts can lead to persistent backdoors for attackers.

Question 28

SSH keys

Answer 28

can present a tremendous opportunity for hackers to gain privileged access to networks, stay connected, impersonate legitimate users, hide their activity with encryption and move freely. To learn about SSH key challenges and best practices for mitigating associated risks while improving your overall security posture, visit our website. And to learn more about our comprehensive secrets management tool to help secure SSH keys, credentials and other secrets used by applications and machines,

Question 29

Confirm that the following key criteria are addressed:

Answer 29

● Lifetime of SSH user keys is limited.
● Key algorithms should be standard. Leading practices recommend the following algorithms: Rivest-Shamir-Adleman (RSA) or Elliptic Curve Digital Signature Algorithm (ECDSA).
● Key lengths should be standard. Leading practices recommend the following key lengths:
— if RSA is used, minimum length of 2048.
— if ECDSA is used, minimum length of 256.
● SSH keys are rotated and reissued on a regular basis.Frequency of key rotation is based on the sensitivity of the associated account.

Question 30

the old versions of OpenSSH had a user enumeration flaw. (This bug is now officially CVE-2018-15473.)

Answer 30

A user enumeration flaw is where a system will admit to you whether a username is valid without making you login first.

By trying to login to OpenSSH using a deliberately malformed network packet, you’d expect an error message to come back – but, until this code change, OpenSSH would come back slightly sooner if the username was invalid than if you’d used a genuine name.

Technically, that’s not supposed to happen – in fact, for decades, starting long before 2000, there’s been a school of thought that says you should always pop up username/password prompts in as an inseperable pair, and never tell the user which one was wrong in the event of a failed login.

You’re supposed to say “invalid username and/or password”, or just “bad luck, start again from the top”, treating both the username and the password as though they’re secret data.