A company has a 40Gbps network that uses a network tap to inspect the traffic using an IDS. The IDS usually performs normally except when the servers are downloading patches from their local update…

Question

Options

• AConfiguring the IDS to ignore traffic from 10.10.10.139
• BUsing PF_RING offload to filter out "host 10.10.10.139 and port 443"
• CAdding a "dst host 10.10.10.139" BPF on the tap
• DScheduling a cron job to stop the IDS service during the patch window

• A
  5% (1)
• B
  5% (1)
• C
  80% (16)
• D
  10% (2)

Explanation

Adding a Berkeley Packet Filter (BPF) of 'dst host 10.10.10.139' directly on the network tap is the best approach. The tap hardware still captures all traffic on the wire (preserving full network visibility at the physical layer), but only traffic destined to 10.10.10.139 is forwarded to the IDS. The high-volume patch download responses originate from 10.10.10.139 (source = 10.10.10.139), so they do not match the 'dst host' filter and never reach the IDS, eliminating the overload. Option A (configuring IDS to ignore the host) still sends all traffic to the IDS before filtering - it doesn't reduce the tap feed load. Option B (PF_RING) works at the kernel level but filters out both directions of traffic to/from that host on port 443, removing more visibility than necessary. Option D (cron job to stop IDS) completely eliminates IDS visibility during the patch window, which is a security gap.

No community discussion yet for this question.