Closed EmilioPanti closed 4 years ago
@cl-mitre can you comment?
hi @EmilioPanti nice to hear from you! I haven't seen any movement on this comment, so I'll start dropping some answers:
1, 2, 3: @brianedmonds90 made some modifications to handle some of this logic recently. I think he was noticing some similar things. let's see if he can chime in on these, but I know the exlude_existing function was dropped as part of the simplifying here.
@EmilioPanti Good questions. We are attempting to provide some flexible 'fact requirement modules' in order to allow the ability designer to describe what behavior they wish to prevent when facts are grounded. Check out the no_backwards_movement module which is best used on hostnames. You can see how this is applied to an ability here. If you want to manage IP addresses and lateral movement, and you find that one of our requirement modules doesn't suit your needs out of the box, you can always write your own. The entire operation object is passed into the requirement modules, so you should have all the information that you need to prune links that have some fact combination that isn't desirable, whether that be lateral movement to existing IP addresses, duplicate hostnames, etc.
Does that help?
@EmilioPanti Also, I think a decent approach to allowing the user to decide whether multiple agents should be allowed on the same host would be to allow the planner modules (sequential in stockpile, for example) to pass a boolean parameter into the planning_svc's get_links() function that specifies whether links = await self.remove_links_missing_requirements(links, operation)
is called in the base_planning_svc or not. I'm not sure how we would expose that on the front-end, but I like giving that option to the planner module.
circling back to this, as we've been been expanding our agents/connection options/etc lately.
we've settled into agents being quick & easy to write and the C2 server supplies "contact points" for agents to connect to via different protocols, such as HTTP, TCP, UDP, HTML, web sockets, etc.
this gives the agent author quite a bit of control over how they want to connect to caldera and how they want to design their agent. this intersects with this topic, allowing multiple agents per host. caldera accepts a beacon from anywhere and returns a server-side generated "paw" now, instead of it being generated on the agent side.
our current strategy is to let agent authors build their own controls for multi-agent handling, as it can be difficult to control server-side (as many things, such as hostname, can be spoofed - or there may be duplicate hostnames in different environments, etc.).
one neat example of this is the "manual" weather app agent. 1) go to localhost:8888/weather 2) type 'caldera' on your keyboard and a hidden page will be displayed behind the weather app 3) you'll see that you have a fully functioning agent with a paw 4) if you refresh the page, the paw remains the same (1 agent on the host) but you can clear your browser cache to get a different paw if you'd like, or open a new browser app entirely to keep both active.
The goal is to push the handling of the multi agent into the agent authors, as i think it's a better fit there.
Hi, I am studying the latest stable version 2.4 and would like to better understand the management of multiple agents on the same host. To prevent backwards lateral movement you call the
_exclude_existing()
function in the app/utility/base_planning_svc.py file:Remarks: