Reviewing some of the Rapid7 documentation on gather data via the Rapid7 Network sensor including - 5 Ways To Get a Network Traffic Source on Your Network | Rapid7 Blog
It doesn’t seem to give any guidelines other then the collection points of data, but not really talking about potential network performance impact for the switches doing vlan spans, etc.
One of the concerns that we have for the implementation of the Rapid7 network sensor is trying to ensure that we don’t cause issues with the network switch performance.
Another potential concern is there any known issues with doing a vlan span, I.E is there any concerns with doing VLAN span if it’s multiple vlans or if there are x amount of ports associated with the vlan.
A SPAN or mirror port is out of band (not inline) and if setup with some considerations in mind it will not impact on network performance.
The issue with monitoring an entire VLAN is that it could result in a large traffic feed greater than the capacity of the sensor capture NIC. This will mean that packets will be dropped on the sensor interface and you will not have full visibility with the potential of missed detections. When monitoring VLANs, I would recommend you use a 10Gb interface minimum for capturing traffic.
If you need to monitor multiple VLANs I would recommend you start with one and then check sensor management to see what data rate are like. If you have plenty of capacity you could add another VLAN and then build on that. You do not want greater that 80% sustained traffic load on a single sensor as you will not be able to deal with traffic bursts.
Thanks for the response (and writing the referenced article), so trying to pick the appropriate VLAN for initial, I plan on targeted the VLAN that contains more of the business critical approach and systems that are less likely to have the Rapid7 agent already installed on it. Obviously file servers and other higher activity servers would have an increase of bandwidth naturally. Is there any other guidance on what types of VLANs should be targeted. I assume with the Suricata based IDS that it generally focused towards specific systems types like servers and desktops.
Hi, Any VLAN associated with internal interfaces of Firewalls are also a good source. Even if you are pulling in Firewall logs, the sensor DPI capabilities can offer additional visibility and associated detections.
The Suricata IDS is just one element of the sensor. We run a second DPI engine in parallel which focuses on certain network metadata such as DNS and DHCP queries. Once sent to the platform we combine it with similar data sourced from logs and then check it for signs of malware.
When it comes to servers you could build up a SPAN session by adding associated ports in small numbers and check what the traffic volumes look like in sensor management
@darragh_delaney : If we have deployed network sensor on virtual machine. Do we need to take monthly/weekly snapshot of the VM.
That should not be necessary. No data is stored on the VM and in a worst case situation you can replace the sensor with another and just point it at the same data source.