Any filter (path_filter, command_line_filter, regmod_filter, etc.) will be interpreted as a regex if it is prefixed with rx| or rxi|. rxi indicates case insensitive regex
For all path filters (path_filters, filemod_filters, non_binary_filemod_filters), globbing expression is also supported. It will be detected automatically by existence of either * or ? character, and will convert all path to Unix format before matching.
For example, filter **/notepad.exe will match "c:\windows\system32\notepad.exe"
Additionally, for all event filters, replace-type regex is also supported, in which case event will not be excluded, but its value will be replaced.
For replacements, syntax to use is rr|@...@... or rri|@...@... (for case insensitive replacement)
where: @ is arbitrary symbol that will server as a delimiter between search and replace string. Any character can be used instead, as long as it is not needed inside the find/replace rule
rx|.* - excludes all events of given typefoo - excludes only events whose value is exactly foorx|^foo$ - Same as above, but using regex - excludes only events whose value is exactly foorri|@[0-fa-f]{8}-[0-fa-f]{4}-[0-fa-f]{4}-[0-fa-f]{4}-[0-fa-f]{12}@<GUID> - replaces any guid (case insensitive) in event with the word <GUID>Legacy ingress filters (5.2 version) will be imported to this data model when found on the system one-time (and identified with some predefined legacy id) and then renamed (.61_upgrade suffix appended). Reference to the ingress filter will also be removed from the cb.conf file (IngressFilterConfigFile property).
In case of cluster, only ingress filter on the master node will be migrated into new model, assuming that filters should be configured the same on each node. Release notes should call that out.
Legacy filter will be imported as series of new filters with unique ids:
Event type ignore filters will only be partially migrated, mapping only types supported by the new ingress filters. This means, we will migrate filters for regmod, netconn, filemod, modload, moduleload (synonym for modload), crossprocopen, remotethread (NOTE: the latter two will apply to all crossproc events) but not childproc, process, module, procstart, procend, processblock, tamper, procmeta, emetmitigation since they don’t have representation in new ingress filters.
All examples here use curl, with raw API call. Note that api token needs to be replaced with actual token used on your server.
Let’s import legacy ingress filter (type of filter used in 5.2 and earlier versions of CB Response). Note that there can only be one legacy filter (spread over one or more filter objects as noted before), and importing will simply overwrite it.
curl -XPUT -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" -H "Content-Type: application/json" "https://localhost/api/v1/ingress_whitelist/legacy" -k --data "@/etc/cb/ingressFilter.json"
Current legacy filter can be reviewed
curl -XGET -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" "https://localhost/api/v1/ingress_whitelist/legacy" -k
Example Response:
{
"filterProcMd5s": [
"9de093dfc1216704ce1b7025b0a93aa3",
"fa9e0665912d2190a1494a4b08569fdc",
"fa3df983922312523c5923af8f47a1c8"
],
"filterProcAndChildPaths": [
"c:\\windows\\system32\\csrss.exe"
]
}
Let’s check all filters we have installed. In this case, we got back two filters corresponding to our legacy filter and one new filter
curl -XGET -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" "https://localhost/api/v1/ingress_whitelist" -k
Example Response:
[
{
"md5_filters": [
"9de093dfc1216704ce1b7025b0a93aa3",
"fa9e0665912d2190a1494a4b08569fdc",
"fa3df983922312523c5923af8f47a1c8"
],
"create_user_id": 1,
"name": "Legacy ingress filter for processes",
"modify_user_id": 1,
"global": true,
"enabled": true,
"modify_timestamp": "2017-03-09T09:12:43.127Z",
"create_timestamp": "2017-03-09T09:04:13.309Z",
"filter_all_events": true,
"descendant_filtering_level": 0,
"hit_rate": 0.0,
"id": "legacy-filter-process"
},
{
"create_user_id": 1,
"name": "Legacy ingress filter for processes and children",
"modify_user_id": 1,
"global": true,
"enabled": true,
"modify_timestamp": "2017-03-09T09:12:43.127Z",
"create_timestamp": "2017-03-09T09:04:13.309Z",
"filter_all_events": true,
"descendant_filtering_level": 1,
"hit_rate": 0.0,
"id": "legacy-filter-process-child",
"path_filters": [
"c:\\windows\\system32\\csrss.exe"
]
},
{
"modify_timestamp": "2017-03-01T19:04:57.225Z",
"create_user_id": 1,
"description": "New filter test",
"modify_user_id": 1,
"sensor_ids": [
1
],
"enabled": true,
"id": "test1",
"filter_on_sensor": false,
"filter_on_server": true,
"create_timestamp": "2017-03-01T19:04:57.192Z",
"filter_all_events": true,
"md5_filters": [
"aca5cbbad69e24b8445b9c8633bf66e8"
],
"hit_rate": 0.0,
"internal": false,
"name": "test"
}
]
This filter will cause all events from process *\unimportant.exe to be ignored on all windows sensors in groups 1 and 2. Note that system uses default settings for some parameters that were not provided, such as enabled=True, descendant_filtering_level=0 and filter_all_events=True
curl -XPOST -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" -H "Content-Type: application/json" "https://localhost/api/v1/ingress_whitelist" -k -d '
[
{
"id":"test2",
"global": false,
"group_ids": [1, 2],
"os_mask":1,
"path_filters":["*\\unimportant.exe"]
}
]'
Example Response:
["test2"]
Let’s modify newly added filter to filter out additional process
curl -XPUT -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" "https://localhost/api/v1/ingress_whitelist/test2" -k -d '
{
"os_mask":1,
"global": false,
"group_ids": [1, 2],
"path_filters":["*\\unimportant.exe", "*\\really_unimportant.exe"]
}'
Let’s view filter we just changed
curl -XGET -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" "https://localhost/api/v1/ingress_whitelist/test2" -k
Example Response:
{
"create_user_id": 1,
"global": false,
"group_ids": [1, 2],
"path_filters": [
"*\\unimportant.exe",
"*\\really_unimportant.exe"
],
"modify_user_id": 1,
"create_timestamp": "2017-03-10T13:44:54.455Z",
"modify_timestamp": "2017-03-10T13:44:54.479Z",
"id": "test2",
"hit_rate": 0.1,
"os_mask": 1
}
Notice addition of the hit rate field, telling us that 10% of events were discarded for this filter in the past 15 minutes
Finally, let’s delete newly added filter
curl -XDELETE -H "X-Auth-Token: b201b7c1e6c5acf45cc5b55dd22464ca504af6e4" "https://localhost/api/v1/ingress_whitelist/test2" -k