Credentials map in report page shouldn't show linux nodes

[MaorCore]

Describe the bug The credentials map component in the security report page shouldn't show linux nodes in it since the map documents lateral movement using Pass-The-Hash credentials and this is not relevant for linux machines.

To Reproduce Steps to reproduce the behavior:

1. Configure the Monkey to attack or scan a linux machine
2. Run the monkey
3. Look for the credentials map in the bottom of the security report page
4. The linux machine should be there as a node.

Expected behavior The map should show only windows nodes

[ShayNehmad]

Requirements

The generalization of this feature's requirement is SERVER SIDE FILTERING based on CLIENT SIDE REQUIREMENTS of the data in the netmap.

There are 3 client side instances of the netmap: a) Infection Map page, b) "The Network from the Monkey's Eyes" map in the report, c) and the PTH map.

For the PTH map we need to filter Linux nodes. But implementing this in such a way that will enable filtering in the other maps as well and in a dynamic manner so that the implementation will be independent from the specific filters seems to be the most extensible way to do so. Why? It will enable easy development of filtering in the "infection map" page (for example, hide all nodes whose name starts with "bla", or hide all unexploited machines, etc...). Also, if we add a new exploit for which a map is relevant, like PTH. Or maybe a map of all monkeys which used exploit XYZ. etc etc...

DDR of solution

1. Add the nodes, edges and monkeys to the Models class. (2)
2. Replace direct calls to mongo with DAL calls via mongoengine (1)
3. Add 3 possible get URL params: node_filter, monkey_filter, edge_filter. The URL for PTH map for example will be: 1.1.1.1:5000/api/netmap?node_filter={'os':'Windows'}&monkey_filter={'os':'Windows'}. (2)
4. Translate JSON parameters (dynamically) to mongoengine filtering. This will require clever use of .exclude. and will require extensive error handling (for bad filters). (3)
5. Cover new logic with UTs. (1)

@danielguardicore

[danielguardicore]

Why are we making the filter very generic?

[ShayNehmad]

@danielguardicore 3 main reasons, by importance:

1. OCP - This will adhere strongly to OCP. If we would like to add another map which is only relevant for exploit X (just like PTH) or add filters to the regular infection map (which I think is a cool possible improvement to the map, stuff like see only linux nodes or nodes named X or nodes that we got to via exploit Y...) this lays the infrastructure for that. It will be easy to add these features in a matter of hours without any changes to the back-end - just add URL parameters from the UI.
2. Testability - It will be significantly easier to test the filter if it's generic and decoupled from the specific exploit logic.
3. Cohesion with #210 - this will enable us to move more parts to using the DAL in a rather elegant way, instead of cluttering the DAL with specific implementations for specific cases.

It does carry a few costs, mainly the cost of another "mechanism" in the backend; we will need to parse the JSON parameter and translate it to a DAL request. I think it won't be too hard but I don't know how to implement it.

[ShayNehmad]

@itaymmguardicore Summery of conversation:

• The filtering ought to be FRONT-END and not BACK-END since it will be faster and almost always it will be a subset of all data.
• The easiest solution is to add filtering in pth_report.py line 219 where we already have a specific request for PTH. THIS IS WHAT WE CHOSE IN THE END
• Refactoring NodeService and other parts to mongoengine and covering with UTs is still very welcome.
• We need to add the "views"/"filters" buttons issue to the backlog, seems like a good feature to have.