A web company is looking to implement an intrusion detection and prevention system into their deployed
VPC. This platform should have the ability to scale to thousands of instances running inside of the VPC.
How should they architect their solution to achieve these goals?
A.
Configure an instance with monitoring software and the elastic network interface (ENI) set to promiscuous
mode packet sniffing to see an traffic across the VPC.
B.
Create a second VPC and route all traffic from the primary application VPC through the second VPC where the
scalable virtualized IDS/IPS platform resides.
C.
Configure servers running in the VPC using the host-based ‘route’ commands to send all traffic through the
platform to a scalable virtualized IDS/IPS.
D.
Configure each host with an agent that collects all network traffic and sends that traffic to the IDS/IPS platform
for inspection.
A
B
Only D is possible, the rest are not allowed in AWS – promiscuous mode, route all traffic between VPCs, host base route command sending traffic through the platform (AWS)
i agree.
if you choose option D then how can IPS part work? I’m confusing
I would go with option C
Sorry, It would be B.
A – promiscuous mode is not allowed
C – there is no ‘route’ command
D – The company need IPS so agent will not work
Do you install the agent on thousands of instances running?
b
I go for D.
Support Document Reference
https://awsmedia.s3.amazonaws.com/SEC402.pdf
Hey diibn,
Are you confused here, the ans is strictly B only, as u might have known this similar set of question which acloudguru left us !! IDS/IPS elements can be supplemented in AWS using only third-party softwares and AWS uses IDS and IPS in their data centre not on the services they provide (bit confusing??) hahaha , though we need to manipulate our infrastructure with their recommendations ! so
A- not at all possible
C- childish
D- this is a pre-run case (will not suitable here)
yeah so B, yeah it is possible to address this concern with routing the traffic to second VPC where the actual IDS/IPS platform resides.
I think answer B ( VPC peering )
D is wrong, because “thousands of instances running” !!
B is correct.
http://quicktechie.com/cs/q-a/16-solution-architect-associate-level-questions/255-a-web-company-is-looking-to-implement-an-intrusion-detection-and-prevention-system-into-their-deployed-vpc-this-platform-should-have-the-ability-to-scale-to-thousands-of-instances-running-inside-of-the-vpc-how-should-they-architect-their-solution-to-achie
It’s D.
A. Not possible to set an instance’s NIC into promiscuous mode.
B. Incorrect… VPC peering connections are not “transitive”, i.e. you cannot pass traffic through a VPC peering connection into another VPC, and then have that other VPC send the traffic to some third VPC, or the Internet, or a VPN, or a direct connect circuit. (I would assume AWS does not allow redistribution of routes from one VPC’s back-end VRF into another VPC’s back-end VRF, unless it is that first VPC’s CIDR block? Someone from AWS would have to chime in here, and they’re probably not going to tell us.)
C. This one is incorrect because adding static routes on an instance won’t affect the routing from any point after the packet leaves the instance’s NIC. AWS will check the destination IP address in the packet header and forward according to the VPC routing table’s routes. You’d need to make routing changes in the VPC route table for that instance’s traffic to get sent through another device (e.g. NAT gateway, VPN instance, or security proxy in this case). (You could tunnel/proxy the traffic over through the IPS tier by changing the destination IP address in the IP header of the packet before it left the instance. But choice C did not state anything about doing anything like that. It just said add a static route on the instance, which does not change the destination IP address in the IP header of the packet.)
D. Correct, this is the standard approach, and is definitely scalable.
I agree
Answer is D
I agree.
Routing traffic to another VPC, will just break the application. As the traffic will not come back!
B. correct
two VPC is not problem.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html
Transitive Peering has more than 3 VPCs
http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/invalid-peering-configurations.html#transitive-peering.
There are only two VPCs in the text.
Near the end of the VPC peering guide, there is a section on invalid configurations. Look at “Edge to Edge Routing Through a Gateway or Private Connection”. You can’t hop from one VPC to another and then hop across a gateway connected to the 2nd VPC.
Picture a VPC router as a virtual thing that sits at the perimeter. It has internal interfaces for each subnet in the VPC. Everything else is an external interface (virtual gateway, internet gateway, peering connections, end points). Traffic can’t come in an external interface and go out another one. It can go from outside the VPC into the VPC, inside the VPC to inside or inside out.
I would go with D for a simple reason scalability and much lesser complexity
With D the computing is distributed (HIPS)
While B the traffic goes through a set of IDPS servers in some another VPC (As much as I know IDPS does not alter the IP packet and either stays in promiscuos or transparent mode) hence option B is ruled out) Please pay close attention to routing and how are you going to achieve things here.
Which IP will the traffic destined to (IDPS or Apps)
How will the traffic get redirected to IDPS, who will do the redirection
D
D, is standard and pretty much scalable.