Open claudijd opened 6 years ago
While the whitelist/blacklist language is fairly natural to me, it does make me question some expectations. For example, it's not obvious whether specifying a blacklist of ports would mean that any ports found to be open and not in the blacklist would be considered okay. I'd like to propose a couple of things here:
PortWhiteList
with OpenPorts
, PortBlackList
with ClosedPorts
, SocketWhiteList
with AllowedConnections
and (hypothetically) SocketBlackList
with ForbiddenConnections
.Open
and Closed
sections.My argument for 1 is that the wording makes the intention a bit clearer. I personally have to do a mental translation from "whitelist" to "allowed" and "blacklist" to "disallowed," so I prefer to skip that step if possible.
As for 2, I think that requiring both sections will make it absolutely clear what the expectations are. It was initially unclear to me whether I should expect ports determined to be open and not on the blacklist to be acceptable. When a blacklist and whitelist are both present, it seems a bit more natural to assume that
It's a tiny bit frustrating to have to think in terms of set theory. I might even suggest doing away with these two lists and advocate for something like this:
Expectations:
- 22: open
- 80: open
- 443: open
- 5900: closed
- *: closed
In this case, it's easier to require that an "open / closed" policy be made explicit for every possible port. It feels less ambiguous and more straightforward to me.
Another thing you'll probably want to support are port ranges and maybe even port lists for expressiveness.
Expectations:
- 22, 2222: closed # SSH
- 80, 443: open # HTTP(S)
- "40000-60000": open # FTP?
Is this supposed to be described as .yml
@andrewkrug ultimately, probably JSON, I feel like that's a small detail relative to what it should contain.
PerspectiveID
?@jjvb...
1.) A PerspectiveID is a unique identifier for a perspective. A perspective is basically a unique source and target(s) pairing. Example: A target may look different from the internet than from say a trusted IP range and the perspective and associated policy that we might run on that perspective's scan result data may be different.
2.) I'm assuming you mean policy defaults, as of yet, I have not defined any defaults. In fact, I have just this proposal of format and no code to interpret written yet. We could easily have defaults, though I'm not sure what a sane default would look like as the policy seems opinionated based on view.
3.) There is not concept of a rule set, but if you are talking perspective to target mapping, that would be the perpective ID. The agent would emit output that contains the results and the perspective that result is for. We'd then have post processing that overlays our policy expectations per perspective and determines if we have an out of policy situation and escalates.
@claudijd I liked your initial suggestion. One thing I'd say is, do we need to specify which protocol a particular port corresponds to (tcp or udp)? Looking at the example I see port 500, which is likely a IKE protocol for VPN connections and is UDP, but the policy does not specify this (Does it have to?)
I also like @zsck's suggestion of below, it feels easier to read and understand:
Expectations:
- 22: open
- 80: open
- 443: open
- 5900: closed
- *: closed
We could also represent an allowed socket connection in that format, e.g. 192.168.1.1:25: open
(we could use another delimiter for port status to avoid confusion).
1.) A PerspectiveID is a unique identifier for a perspective. A perspective is basically a unique source and target(s) pairing. Example: A target may look different from the internet than from say a trusted IP range and the perspective and associated policy that we might run on that perspective's scan result data may be different. 3.) There is not concept of a rule set, but if you are talking perspective to target mapping, that would be the perpective ID. The agent would emit output that contains the results and the perspective that result is for. We'd then have post processing that overlays our policy expectations per perspective and determines if we have an out of policy situation and escalates.
Ok, yeah that makes perfect sense but the PerspectiveID
as a UUID seems like it may be a convoluted way to accomplish this. I wonder if you can have PerspectiveName
with a more human friendly value, as these will be distinct scanners that will be treated as pet servers, right?
As well, I wonder if you can completely remove the idea of a PerspectiveID
by having configuration files that are scanner specific that match IP ranges with rules? Or will scanners potentially support multiple perspectives?
Lastly, I don't think my above opinions are blockers by any means. Just thoughts on how to structure the configuration to make it easier to understand.
2.) I'm assuming you mean policy defaults, as of yet, I have not defined any defaults. In fact, I have just this proposal of format and no code to interpret written yet. We could easily have defaults, though I'm not sure what a sane default would look like as the policy seems opinionated based on view.
Ok sounds good, just wanted to check. In my humble opinion, I would not have defaults and require a configuration to be written OR have the default be "no ports are open".
@caggle @claudijd
One thing I'd say is, do we need to specify which protocol a particular port corresponds to (tcp or udp)? Looking at the example I see port 500, which is likely a IKE protocol for VPN connections and is UDP, but the policy does not specify this (Does it have to?)
What would be the behavior if no protocol is listed? It means both TCP and UDP? There is some mapping within nmap-agent
that says "X port maps to X protocol"?
We have used a similar pattern as this to define external policy in the DC's and Offices, so there is a precedent here, but sharing some rough ideas on how we can expand on this policy expectation definition to support more complex, but still relatively simple policy expectations to help define scan visibility as an effective unit-test framework, but still keep it human readable/writeable.