Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ BUG ] Import-FalconConfig fails to modify and ignores default SensorUpdatePolicy #444

Open
bk-cs opened this issue Jan 10, 2025 · 2 comments
Open

[ BUG ] Import-FalconConfig fails to modify and ignores default SensorUpdatePolicy #444

bk-cs opened this issue Jan 10, 2025 · 2 comments
Assignees
@bk-cs
Labels
bug Something isn't working fix available Self-applied fix available in issue

Comments

@bk-cs
Copy link
Collaborator

bk-cs commented Jan 10, 2025 •
edited
Loading

Describe the bug
Import-FalconConfig does not modify default SensorUpdatePolicy. Errors may also occur related to variants sensor values (like missing build, or sensor_version) or scheduler values (missing timezone).

Additional items may fail to import or fail to be modified (especially "default" policies). Users have reported that prevention policy settings were not being modified after creation.

To Reproduce
Attempt to use Import-FalconConfig to modify default SensorUpdatePolicy

Environment (please complete the following information):

  • OS: Windows 10
  • PowerShell: 5.1
  • PSFalcon: 2.2.8
@bk-cs bk-cs added the bug Something isn't working label Jan 10, 2025
@bk-cs bk-cs self-assigned this Jan 10, 2025
@bk-cs
Copy link
Collaborator Author

bk-cs commented Jan 10, 2025 •
edited
Loading

Related causes:

  • The "HomeCid" code added in the v2.2.8 release that is designed to prevent attempted modification of inherited policies is causing imports from other CIDs to be skipped when they should be properly modified
  • The variants property under SensorUpdatePolicy is not being properly updated when a variants.build value is no longer available
  • The scheduler property under SensorUpdatePolicy requires a timezone value when being submitted, but not all imports will have a value

bk-cs added a commit that referenced this issue Jan 10, 2025
@bk-cs
Issue #444
7a12123 
Updated `Compare-Setting` function to convert `scheduler` and `variants` properties under `SensorUpdatePolicy` to Json strings when capturing a modification result.

Added additional verbose messaging to indicate when...

* `ModifyDefault` or `ModifyExisting` policies have been selected for modification
* `build`, `sensor_version`, and `stage` properties have been modified under a `SensorUpdatePolicy` and under the `variants` for a `SensorUpdatePolicy`

Added check for an empty `variants` list for a `SensorUpdatePolicy` to remove `variants` from creation/modification submission.

Added check for null/empty `timezone` values under the `scheduler` property of a `SensorUpdatePolicy` to add a default value of `Etc/Universal` when no `timezone` is found in the imported policy.

Changed `SensorUpdatePolicy` modification code to better handle the `HomeCid` variable. Now instead of skipping over policies that weren't exported from the same CID they're being imported into, `HomeCid` is only used if the CID is the same. Additionally, the ID used for policy modification is assumed to be the matching ID found in the CID for policies that already exist if `new_id` isn't present (from the `Update-Id` function when the policy is created earlier in the import).

Added a check to determine if multiple default policies already exist in the CID and can't be correlated against `HomeCid`. Now the policies will be ignored and an `Ignored` result will be added to final output, since it's impossible to tell which `platform_default` policy (i.e. inherited or not-inheritied) is the right one if you're importing from a source CID that doesn't match the current CID.

Added additional result for `platform_default` policies when no changes have been made because they are identical.

Modified `FirewallPolicy` import to ensure that  a proper result was captured when `rule_group_ids` were added instead of a `Cannot bind argument to parameter 'ReferenceObject' because it is null` error due to there being no original `rule_group_ids` to compare against.
@bk-cs
Copy link
Collaborator Author

bk-cs commented Jan 10, 2025 •
edited
Loading

Several changes have been made to fix these issues for the next PSFalcon release. If you'd like to resolve it for your local module before release, you can replace public\psf-config.ps1 using the steps outlined below.

Import-Module -Name PSFalcon
$ModulePath = (Show-FalconModule).ModulePath
(Invoke-WebRequest -Uri https://raw.githubusercontent.com/CrowdStrike/psfalcon/292faa7ece10860a46a3c88429b6ca148cac7c1a/public/psf-config.ps1 -UseBasicParsing).Content > (Join-Path (Join-Path $ModulePath public) psf-config.ps1)

Please ensure that you close and re-open PowerShell and re-import the PSFalcon module before testing.

EDIT 2025-01-13: Updated to account for some additional fixes.

@bk-cs bk-cs added the fix available Self-applied fix available in issue label Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bk-cs bk-cs

Labels
bug Something isn't working fix available Self-applied fix available in issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@bk-cs