Certified Ethical Hacker guideStudy & preparation
CEH IDS vs IPS vs Firewalls: Match the Control to the Scenario
Distinguish intrusion detection, attempted prevention, and network or host traffic filtering with four original CEH study cases and a method for reviewing mistakes.
Short answer
An IDS detects possible incidents; an IPS can attempt to stop them; a firewall restricts traffic between networks or to and from a host, as described in NIST's guidance. For CEH scenarios, identify the action and result stated: an alert alone proves neither prevention nor a successful compromise. A blocked flow also needs context, because traffic filtering and intrusion prevention can both restrict traffic.
Which CEH topic includes these controls?
An intrusion detection system (IDS) detects possible incidents; an intrusion prevention system (IPS) can attempt to stop them; a firewall restricts network or host traffic. NIST's guidance distinguishes these roles, while EC-Council places related material in the CEH blueprint's Network and Perimeter Hacking domain.
CEH Exam Blueprint v5.0, checked November 3, 2026, assigns 30 questions to that domain. Six belong to the broader Evading IDS, Firewalls, and Honeypots subdomain. That does not mean six questions exclusively test IDS versus IPS, or that the blueprint specifies how often any particular distinction appears.
Use the CEH exam blueprint guide for the full allocation. For this topic, practice explaining the control's stated behavior before choosing its label. The following comparison is a study aid based on NIST's concepts, not a description of actual exam questions.
| Observation in the scenario | Best-supported role | Conclusion the observation does not establish |
|---|---|---|
| A monitor flags possible intrusion activity; no blocking action is described | Intrusion detection | The traffic was stopped or a compromise succeeded |
| A control detects possible intrusion activity and explicitly stops the associated flow | Intrusion prevention in that case | Every future incident will be prevented |
| A rule restricts traffic crossing between networks | Network firewall filtering | The rule identified an intrusion |
| A rule on one computer restricts that computer's traffic | Host firewall filtering | The rule protects every other computer's traffic |
The distinction depends on both why the control acts and what it does. “Blocked” alone is insufficient to identify an IPS: a firewall rule can also restrict traffic.
What does an IDS observation establish?
An IDS observation establishes that the system detected signs of a possible incident. NIST's glossary describes intrusion detection and prevention in terms of monitoring and analysis for possible incidents. The word possible matters: an alert is not automatically proof that an attacker succeeded.
Keep three statements separate when you read a question:
- The monitor identified suspicious activity.
- A control stopped the activity.
- An attacker achieved a particular result.
A scenario can establish the first without establishing the other two. If it only describes an alert, do not add a blocking action or a successful compromise to make your preferred answer fit. Equally, the absence of a stated block does not prove that no other control intervened; it means that outcome is not supplied.
Write a short evidence statement, such as “the monitor raised an alert; the outcome is unspecified.” This makes it easier to reject an answer that goes beyond the facts given. For broader question practice, full CEH prep planned for launch includes 1,800 questions across nine domains.
How does IPS behavior differ?
Prevention adds an attempt to stop the possible incident. NIST's descriptions support that capability, not a guarantee of success in every situation. Separate what a control can attempt from what the scenario says actually happened.
If the description says a control attempted to stop a suspicious flow, attempted prevention is established. If it explicitly says the flow was stopped, the stated intervention succeeded in that instance. Neither wording supports a claim that all attacks are prevented or that the environment is free of compromise.
Detection and prevention can overlap. A description may include both identifying possible intrusion activity and taking action against it. Do not assume that the presence of an alert excludes prevention, or that a product name alone establishes every action it performed.
Use the same evidence discipline for other network topics. The CEH sniffing and session-hijacking guide distinguishes observed traffic from a demonstrated session takeover. Here, the corresponding distinction is between detecting activity and establishing an intervention.
How do network and host firewalls differ?
NIST SP 800-83 Revision 1 distinguishes network firewalls, which restrict traffic between networks, from host firewalls, which restrict an individual host's traffic. The scope of the rule is the useful clue. Ask what traffic crosses the boundary being controlled.
A rule between two networks supports the network-firewall role. A rule applied on one computer to that computer's traffic supports the host-firewall role. Do not extend a host rule's stated scope to the entire network, or assume that a permitted connection has been proven harmless.
The roles can overlap with other security functions, so avoid treating these labels as promises about every product. When a question asks specifically about filtering traffic according to a boundary rule, answer that behavior. When it describes detection of a possible intrusion followed by intervention, account for both actions.
The NIST publication dates to July 2013 and was checked November 3, 2026. Its stable definitions support this comparison; they do not establish current product rankings or settings. For broader term review, full CEH prep planned for launch includes 500 flashcards. In your own notes, pair each term with its role and its limits.
Which clue decides each original scenario?
These four fictional cases are editorial study exercises. For each, identify the decisive phrase before reading the explanation.
Case 1: An alert without a reported block
A monitoring component reports possible intrusion activity. The exercise provides an alert record but no record of a blocking action or confirmed unauthorized access.
Clue and role: The supplied evidence is an alert. Intrusion detection is the supported role.
Nearest wrong inference: “The incident was prevented.” Nothing in the case establishes prevention. “The host was compromised” also adds an unreported outcome.
Next review action: Rewrite your answer using only the supplied result: possible intrusion activity was detected. Mark prevention and compromise as unknown.
Case 2: Detection followed by an explicit stop
A control identifies possible intrusion activity and intervenes. The exercise explicitly states that the associated flow was stopped by that intervention.
Clue and role: Detection followed by a stated successful intervention supports intrusion prevention in this case.
Nearest wrong inference: “The control guarantees that the network cannot be compromised.” One stopped flow establishes neither universal protection nor the outcome of other activity.
Next review action: Change the sentence to “the control attempted to stop the flow.” Notice that the role remains prevention, but successful blocking is no longer established.
Case 3: A rule between networks
Traffic crosses from one network to another. A boundary control denies traffic that the stated filtering rule does not permit. The case reports no intrusion analysis.
Clue and role: The decision applies a traffic rule between networks. Network firewall filtering is the supported role.
Nearest wrong inference: “Anything that blocks traffic must be an IPS.” The case establishes policy filtering, without establishing intrusion detection.
Next review action: Underline the boundary and rule. Compare this case with Case 2: the reason for acting, rather than the word denies alone, distinguishes the descriptions.
Case 4: A rule on one host
A rule on a workstation restricts that workstation's traffic. Nothing states that it controls traffic for other devices.
Clue and role: The rule's scope is the individual host. Host firewall filtering is the supported role.
Nearest wrong inference: “Every device on the network receives the same protection.” That extends the rule beyond its stated scope.
Next review action: Write “this workstation's traffic” beside the answer. Then explain what evidence would be needed to classify a rule as filtering between networks instead.
How should you revisit a mistaken answer?
Use a small error log with three entries: the observation, the role it supports, and the extra conclusion you added. This is an editorial study method, not an official CEH scoring rule.
If your mistake concerns whether access was established, review the CEH vulnerability, access, and malware distinctions. If you understand each term but struggle to justify a choice, use the practice-test readiness guide to organize further review.
Try the 20 free CEH practice questions and apply the observation–role–limit method wherever it fits. The free set is not a promise of questions on this particular subdomain. Add unresolved distinctions to the free CEH study planner. Keep eligibility and purchase decisions separate by checking the CEH cost and requirements guide before booking.
For a broader rehearsal, full CEH prep planned for launch includes a 125-question mock exam. Use practice to identify concepts that need another explanation; it does not establish your official exam result.
Finish by rewriting one missed case so that only a single clue changes. Explain whether that change affects the control's role, the demonstrated outcome, or its scope. If you can justify the difference without adding unstated facts, move to a fresh case.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.