search

oasis-tcs / openc2-apsc-stateless-packet-filter

OASIS OpenC2 TC: A GitHub repository is to provide configuration management and to aid in the development of the first generation OpenC2 firewall profile
https://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter
Other
6 stars 10 forks source link

Support multiple IP addresses, ports #118

Open alevere opened 4 years ago

alevere commented 4 years ago

Presently, the SLPF expects a pair of IP addresses and ports. However, the majority of firewalls/slpfs support a list for each field. E.g. allows IPv4-a and IPv4-b to talk to IPv4-c on ports 80,443. I propose that we extend the SLFP to support this use case. I believe this applies to ipv4_net, ipv4_connection, ipv6_net, and ipv6_connection.

Vasileios-Mavroeidis commented 4 years ago

Super useful, but we move out of the concept of atomic commands? I want to hear opinions.

Maybe the possibility of a specification that allows pushing multiple commands in one array would enable this capability and still keeping the commands atomic. We could even have a requirement that the commands in the array should be of the same type, such as IPv4 connection and not a sophisticated COA. I have also described this HERE, for those that want to have a look.

jmbrule commented 4 years ago

Sounds logical to me. I think the original idea was you could issue a deny to a range of IP addresses with the ipv*_net command, but it is limited in that all the addresses have to be a continuous range rather than an unrestricted set. If it is normal for modern firewalls to accept a discontinuous set of addresses to allow (or deny) then it makes sense to do so.

jmbrule commented 4 years ago

In the context of "but we move out of the concept of atomic commands?". You could make the case that deny /31 is no less 'atomic' than deny [1.1.1.1 and 1.1.1.2]. I think we are good with supporting a single action and a list of targets. Thoughts?

Vasileios-Mavroeidis commented 4 years ago

I'm just saying that as far as I know an IP range (populated as CIDR) will be treated as one command at the actuator side whereas multiple targets (of the same type) would still need to be executed separately at the actuator's side.

If we support doing this in all IP targets that we have, we are less granular. We hypothesize that all the IPs specified in the IPv4 or v6 connection are submitted having also the same ports specified.

Doing it only for the IPv4_net and IPv6_net as you propose Joe is ok and it makes sense if we do not care about what I described in the first sentence of my answer. For the IPv4 and 6 connection objects, we can add the ability of specifying multiple ports. So IPs for the ipv_net object and ports for the ipv_connection.

Makes sense? This also minimizes the issued commands, so fewer network resources are needed.

jmbrule commented 4 years ago

The notion of an IPv*_net was me being lazy, not me proposing an 'generic ip_net target that includes all versions). I should have said "... wiht the ipv4_net (or ipv6_net) ...". Was not my intent to make a less granular via some sort of wildcard target