This appendix presents various questions you’re likely to be asked by prospective employers when you interview for a job position after completion of CEH. These questions tend to test the overall security aptitude as well as the technical competence of the candidate.

What is the difference between encoding, encryption, and hashing?

The purpose of encoding is to transform data so that it can be properly (and safely) consumed by a different type of system, e.g. binary data being sent over email, or viewing special characters on a web page. The goal is not to keep information secret, but rather to ensure that it’s able to be properly consumed.
The purpose of encryption is to transform data in order to keep it secret from others, e.g. sending someone a secret letter that only they should be able to read, or securely sending a password over the Internet. Rather than focusing on usability, the goal is to ensure the data cannot be consumed by anyone other than the intended recipient(s).

Hashing serves the purpose of ensuring integrity, i.e. making it so that if something is changed you can know that it’s changed. Technically, hashing takes arbitrary input and produce a fixed-length string that has the following attributes:

The same input will always produce the same output.
Multiple disparate inputs should not produce the same output.
It should not be possible to go from the output to the input.
Any modification of a given input should result in drastic change to the hash.

https://danielmiessler.com/study/encoding-encryption-hashing-obfuscation/

-----------

What is the difference between proxy, firewall, IDS, and IPS?

Firewall - A device or application that analyzes packet headers and enforces policy based on protocol type, source address, destination address, source port, and/or destination port. Packets that do not match policy are rejected.
Intrusion Detection System - A device or application that analyzes whole packets, both header, and payload, looking for known events. When a known event is detected a log message is generated detailing the event.
Intrusion Prevention System - A device or application that analyzes whole packets, both header, and payload, looking for known events. When a known event is detected the packet is rejected.

The functional difference between an IDS and an IPS is a fairly subtle one and is often nothing more than a configuration setting change. For example, in a Juniper IDP module, changing from Detection to Prevention is as easy as changing a drop-down selection from LOG to LOG/DROP. At a technical level, it can sometimes require a redesign of your monitoring architecture.

Given the similarity between all three systems, there has been some convergence over time. The Juniper IDP module mentioned above, for example, is effectively an add-on component to a firewall. From a network flow and administrative perspective, the firewall and IDP are functionally indistinguishable even if they are technically two separate devices.

A firewall (usually) sits at the network perimeter of the system, whereas an IDS/IPS can not only work at the network level, but also work at the host level. Such IDS/IPS systems are called host-based IDS/IPS. They can monitor and take action against running processes, suspicious log-in attempts, etc. Examples include OSSEC and osquery. Perhaps anti-virus software can also be considered as a kind of IDS/IPS.
A firewall is probably easier to understand and to be deployed. It can also work on its own. But an IDS/IPS is more complex and probably needs to be integrated with other services. For example, the outcome of IDS will go into SIEM for correlation analysis, for human analysts, etc.
At least for "traditional" firewall, the core is a rule-based engine. But IDS/IPS might also use anomaly-based detection based methods to detect intrusion.

https://security.stackexchange.com/questions/44931/difference-between-ids-and-ips-and-firewall

--------------

How does asymmetric encryption work?

How does SSL work?

What is TLS and how is it different from SSL?

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is "SSL 3.1". TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say "SSL/TLS".

HTTPS is HTTP-within-SSL/TLS. SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts. HTTP is a protocol for sending requests and receiving answers, each request and answer consisting of detailed headers and (possibly) some content. HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".

To explain the acronyms:

"SSL" means "Secure Sockets Layer". This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).
"TLS" means "Transport Layer Security". The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" (and published as a RFC). It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.
"HTTPS" is supposed to mean "HyperText Transfer Protocol Secure", which is grammatically unsound. Nobody, except the terminally bored pedantic, ever uses the translation; "HTTPS" is better thought of as "HTTP with an S that means SSL". Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.

https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https

So then, should I choose TLS or SSL?

If you are configuring a server, you must install software that supports the latest versions of the TLS standard, and configure it properly. This ensures that the connections that your users make are as secure as possible. Using an excellent security certificate will also help a lot — e.g. one with 2048+ bit keys, Extended Validation, etc. You should avoid using SSL v3 and should use only strong ciphers, especially if compliance of any kind is required.

If you are configuring a program (especially an email program) and have the option to connect securely via SSL or TLS, you should feel free to choose either one…. as long as it is supported by your server.

Note: many web browsers have special preference areas that allow you specifically enable/disable SSL v2, SSL v3, TLS v1.0, etc. In these cases you are actually telling the browser what versions of these security protocols you will allow your browser to use when establishing secure connections. We recommend turning off SSL v2 and SSL v3 (they provide no real security). Some web sites may support SSL v3 only; if you encounter one of these … please let them know that they are seriously behind the time and doing themselves and their visitors a serious disservice by pretending to provide safety while actually only providing broken, ancient encryption.

https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

Can you name a critical vulnerability found in SSL during recent times?

POODLE (CVE-2014-3566)

The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack was published in October 2014 and takes advantage of two factors. The first is the fact that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems, and the second factor is a vulnerability that exists in SSL v3.0 which is related to Block Padding.

The Client initiates the Handshake and sends the list of the supported SSL/TLS versions. An attacker intercepts the traffic, performing a Man-in-The-Middle (MiTM) attack, and impersonates the Server until the Client agrees to downgrade the connection to the vulnerable SSL 3.0.

Now that the connection between Client and Server is established on a vulnerable SSL version, the attacker can perform the actual POODLE attack. The vulnerability exists in Cipher Block Chaining mode. Since Block Ciphers have fixed length, if the data in the last block is not a multiple of its size, then padding is added to fill the extra space. One of the problems is that padding value is ignored by the server and checks only if padding length is correct as well as Message Authentication Code (MAC) of the plaintext. That means the receiver (Server) cannot verify if padding value has been modified.

https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/

What is port scanning? How can port scanning be prevented? • What is a man-in-the-middle attack? Can it be prevented? • What is the difference between false positive and false negative? • What does the term “defense in depth” mean? • What is a stateful inspection by a firewall? • What is a DMZ? Which systems should be placed in DMZ?
https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/

------

Is SSH completely secure?

Nothing is "completely safe"; the question is whether it adds any additional risks.

The SSH protocol sends the client's public key encrypted, only after it has negotiated a symmetric session encryption key with the server. So an adversary that eavesdrops on the connection doesn't learn the client's public key. This means that publishing it does give the adversary an extra piece of information they wouldn't have otherwise.

But what can the adversary do with that additional information? Well, this all hinges on whether the attacker can break RSA. Let's consider two subcases. (I'll assume that both the server and the client's RSA keys are large enough to be secure in the first place—2048 bits or more.)

The adversary has a general attack on RSA that requires knowledge of the public key

By general attack, I mean one that breaks RSA irrespective of what key you use. For example, this would be something like an efficient algorithm for solving the RSA problem (e.g., a polynomial-time prime factorization algorithm) or by building a practical quantum computer.

In this case it doesn't matter whether you publish your client public key or not, because SSH and every other application that uses RSA would be completely broken. So no additional risk.

The attacker has an attack against a subset of "weak" RSA public keys

This is a real-life problem. There are some systems that, because of faulty key generation algorithms or faulty random number generators, choose RSA keys that are actually vulnerable to attack. The most notable example is that the Debian GNU/Linux distribution shipped with a weak random number generator for nearly two years (September 2006 to May 13th, 2008). A 2011 survey of 7.1 million RSA keys in the public Internet found that about 0.4% of 1024 RSA public keys they saw were weak.

If your client public key is such a weak key and you publish it, then an attacker who obtains it may be able to tell so and exploit this fact. They would then be able to log in to the SSH servers that you use that key to authenticate to. That would indeed be an additional risk.

If your server has such a weak public key, then that server is insecure; an attacker can eavesdrop on the connections, which allows them to learn your public key anyway. So, in this case, there's no additional risk.

Conclusion

The additional risk from publishing your SSH client public key is small but not zero. The biggest risk is that your client public key is a weak one, something caused by faulty software. If you're going to publish a client public key you might want to take steps to make sure your key isn't a weak. For example:

Check your public key against a weak key tester tool
Generate your client keypair on a system where you've done due diligence to make sure that it won't give you weak keys. For example:
- Apply all security patches to your operating system, particularly those that address issues with its random number generator, SSH, or any libraries that SSH depends on.
- Take measures to ensure that the system has access to a good entropy source. (Complicated topic.)

edited Feb 7 at 2:15

answered Feb 7 at 1:56

Luis Casillas

What is BYOD and what are the common security concerns associated with it?
What are the different layers of the OSI model? Explain each layer in brief.

What are honeypots? • How do you keep yourself updated with the latest trends in Information Security? • Which OS do you feel is more secure, Linux or Windows? • How does Kerberos work? • What is a zero-day vulnerability? Can it be prevented? • What is a rainbow table attack? How can it be prevented? • What is the difference between a hub, switch, and router?
What are some common security concerns in Cloud computing? • What is the difference between vulnerability assessment and penetration testing? • What are the high-level steps to perform vulnerability assessment and penetration testing? • What tools do you normally use for vulnerability assessment and penetration testing? Which tool you find the best and why? • Is it possible to hack into a system without using any tool? • What is the difference between active and passive information gathering? • How does HTTPS make a website secure? • What is a SQL injection attack? What are its types? • What is a XSS attack? What are its types? • What is CSRF? How can you prevent it? • What is the difference between white box application security testing and black box application security testing? • What standards do you refer to for web application security and related vulnerabilities? • Will a Layer 3 firewall be useful in protecting the web application against common attacks? If yes, then to what extent? • How does HTTP handle state? • How do you identify that an application is vulnerable to blind SQL injection attack? • What are the top five mobile application security threats? • What is the difference between a standard, a policy, and a procedure? • Name a vulnerability for each OSI layer.

© Sagar Ajay Rahalkar 2016 187 S.A. Rahalkar, Certified Ethical Hacker (CEH) Foundation Guide , DOI 10.1007/978-1-4842-2325-3

Nexus

Interview Questions - CEH

Recent Posts

Facebook