Egress vs P2P
Last updated
Last updated
There are two kinds of C2 profiles - egress profiles that talk directly out of the target network or peer-to-peer (p2p) profiles that talk to neighboring agents.
The default profile and the HTTP profile are both examples of egress profiles. They talk directly out of the target network. Egress profiles have associated Docker containers that allow you to do the translation between your special sauce c2 profile and the normal RESTful web requests to the main Apfell server. More information on how this works and how to create your own can be found here: C2 Related Development.
Peer-to-peer profiles are a bit different. They don't talk directly out to the internet; instead, they talk to each other. The standard scenario is to have at least one agent with both an egress profile and a p2p profile which acts as a relay point for all of the other agents that only have p2p profiles. Within Apfell, you can make this distinction by flipping a switch on a c2 profile to indicate that it's a p2p profile:
When you toggle this to true, a new row with a new button will appear. This next toggle is referring to how messages are routed in the P2P profile. "Server Routed" refers to the scenario where agents only know about their directly connected neighbors, so it's up to the "Server" to recursively craft a message that each agent can decrypt, read, pass along to a neighbor, which then in turn decrypts the message, reads it, and passes it along to one of its neighbors. When this toggle is off, that means that the P2P mesh will handle its own routing. This is when the agents have their own way of routing messages between them that might periodically update, might be self recovering, or might be optimize over time. You can think of this like how normal networking is done with various network layer protocols.
When you create a P2P profile, there is no associated Docker container. This is because the special sauce P2P messages will never be seen by Apfell; instead, there's always at least one egress profile that'll be relaying these messages. To represent this, the Docker light for a P2P profile is always blue.
P2P profiles announce their connections to Apfell via P2P Connections. When Apfell gets these messages, it can start mapping out what the internal mesh looks like. To help view this from an operator perspective, there are two additional views on the main Callbacks page.
This view uses a D3 force directed graph to illustrate the connections between the agents. There's a central "Apfell Server" node that all egress agents connect to. When a route is announced, the view is updated to move one of the callbacks to be a child of another callback.
This view uses a D3 tree to illustrate the connections between the agents. There's a root "Apfell Server" node, and all other nodes are children off of that one. You can "right click" any node that has a light blue circle around it to hide or expand the tree from that point. If a node has a red circle around it, then it is high integrity, and if it has a yellow circle, then it's been removed from the table view. The reason these "removed" nodes can still be shown is when one node in a chain is removed, but there are still active nodes further down in the chain that still need to be shown.
