This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About tingmy
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About tingmy
02-28-2023
4Posts
0Likes
1Solution
Feb 28, 2023Last Visited
User
Activity
User
Profile
Latest posts by tingmy
| Subject | Views | Posted |
|---|---|---|
| 238 | 02-23-2023 05:52 PM | |
| 289 | 02-22-2023 11:52 PM | |
| 1580 | 07-15-2021 08:26 AM | |
| 1660 | 07-13-2021 03:31 AM |
User Badges
Community Statistics
| Member Since | 07-13-2021 03:12 AM |
| Date Last Visited | 02-28-2023 03:03 AM |
| Posts | 4 |
02-23-2023
05:52 PM
We are an intermediary security group, so we do not have access to the XDR admin portal. During troubleshooting of end users' issues in previous versions, we find it more convenient to get the users themselves to check the policy profile names on their endpoints, as opposed to emailing the XDR admin.
Before version 7.6.x, it was possible to check the log files directly. During version 7.7.x, we can get the users to generate support files themselves. After version 7.7.x, the support files are encrypted, and require the XDR admins to generate the archive password.
... View more
02-22-2023
11:52 PM
As different Cortex XDR Policy profiles can be pushed to different users, it is sometime required to find out what is the current XDR Policy Profile used by a particular endpoint.
If the endpoint has local administrator privilege, we could just search in the *.ldb files in the following folder for the name of the profile used. C:\ProgramData\Cyvera\LocalSystem\Persistence\agent_settings.db\
The pattern to look for is in JSON like below: "mpm":"Xxxxx","agset":"Xxxxxxxxxxxxxxx","restr":"Xxxxxxxxxxxxx","name":"Xxxxxxxxxxxxxx","epm":"Xxxxxx","exceptions":"Xxxxxx)"
If the endpoint does not have local administrator privilege, there seems to be no legitimate method to find current XDR Policy Profile used.
Before version 7.8, we could at least "Generate Support File" on the XDR client and find the *.ldb files in the generated archive file. But newer versions of XDR after 7.8 encrypts the generated support file.
Does anyone know if it is possible to find out the current XDR Policy Profile used by a particular client endpoint without local administrator privilege?
... View more
- Tags:
- XDR
07-15-2021
08:26 AM
There are only 3 places in the firewall GUI for my PA-220 that I can reasonable add in the exclusion for my scanner's IP as shown below: NETWORK -> Network Profiles -> Zone Protection -> (My Profile Name) -> Zone Protection Profile (Reconnaissance Protection) -> SOURCE ADDRESS EXCLUSION NETWORK -> Zones -> (My Zone Name that use ZONE PROTECTION PROFILE) -> User Identification ACL -> EXCLUDE LIST NETWORK -> Zones -> (My Zone Name that use ZONE PROTECTION PROFILE) -> Device-ID ACL -> EXCLUDE LIST Unfortunately, adding my scanner's IP to these 3 places did not resolve the issue. Fortunately, I noticed the following setting: NETWORK -> Network Profiles -> Zone Protection -> (My Profile Name) -> Zone Protection Profile (Flood Protection) -> SYN Action: SYN Cookies Activate: 0 Someone had set "Activate" to 0, which is too low. After I changed it to 25,000 as per the PA recommendation, I no longer encounter the problem of every port responding to SYN or CONNECT scan as open.
... View more
07-13-2021
03:31 AM
Hi folks, When I perform a nmap port scan on my IP range protected by Palo Alto Firewall, almost every port responded to SYN scan. This is a known issue, as I found: Port scan report shows all TCP ports are open https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgRCAS If I want to successfully perform a port scan, the only solution seems to be to disable SYN flood protection. Do anyone know if there is anyway to "whitelist" a source IP, so a particular IP can perform port scan without interference from the flood protection component, but still enable flood protection to the general public? I have been told that Palo Alto tech support informed us that there is no way to "whitelist" a source IP for port scan, and the only resolutions are: Disable SYN flood protection. Change the Action from SYN Cookie to Random Early Drop. Increase the threshold for activation. I just wanted to pick the brains of the community to see if there is any other way to perform port scan on the firewall without disabling flood protection completely.
... View more
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks