OK, so if you populate the source with 1.2.3.4 and if the dest address is empty, (and treating unpopulated fields as ‘any’ is typical) then you end up with a
situation where
Deny {ip_conn{src_ip=1.2.3.4}} is going to block everything because you implied an ‘OR any ip address…
Do we provide usage guidance in the SLPF (the burden is on the actuator vendors to map src or dst for the block and ignore empty fields). Do we reintroduce the
ip_addr as the target for tipping point and create two profiles? Another approach?
From: Brule, Joseph M
Sent: Wednesday, January 30, 2019 10:50 AM
To: 'openc2-lang@lists.oasis-open.org' <openc2-lang@lists.oasis-open.org>; 'openc2-actuator@lists.oasis-open.org' <openc2-actuator@lists.oasis-open.org>
Subject: FW: ipconn vs ipaddr
I forwarded this email to both the AP SC and the Lang SC distribution lists. Applies to both subcommittees and need everyone’s perspectives.
Thoughts?
From: Everett, Alex D <alex.everett@unc.edu>
Sent: Wednesday, January 30, 2019 9:58 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; 'duncan sfractal.com' <duncan@sfractal.com>
Subject: [Non-DoD Source] ipconn vs ipaddr
Joe/Duncan:
For my use case to work in the slpf to only use the ipconn option, there needs to be a new row added to ip-connection such as
addr, IP-Net, 0..1, ip address in either source or destination, expressed in CIDR must be unpopulated if either src_addr or dst_addr are populated. An entry without a mask is treated
as a single host.
We also need to fix IP-Addr, as that is useless without the CIDR mask.
Why?
Some popular devices (e.g. cisco, tippingpoint) actually block on source OR dest.
Palo Alto is the outlier that actually can support blocking just on source, or dest, or both using rules.
As ip-conn is written today, these devices could not use the slpf.
If you issued a command to block src address 1.1.1.1, these devices dont do that.
What they would do is block any packet with a source or dest of 1.1.1.1
Sincerely,
Alex