About Steve-Phillips

I note that the http://panwdbl.appspot.com/ feeds including the http://feeds.dshield.org/block.txt feed have gone offline and return a 404 error.   This is a shame, as blocking the DShield Top 20 was a very good security measure.   Does anyone know of an alternative feed for the DShield Top 20 suitable for use with the Palo Alto firewall, or know where I could find some (Python) code to do the file conversion that I could host?   Thanks, Steve ... View more

@Remo,   Great, many thanks for that explanation, most useful in increasing my knowledge of the Palo Alto firewall.   Cheers, Steve ... View more

Hi @Remo,   Many thanks for your reply.   Following on from what you have said, and so I and perhaps others can understand this a bit better, an example phishing email I have received is as follows:   Receive Time 2019/03/18 14:44:58   WildFire Analysis Summary   Link Information URL hxxps://remove_me_walimusacco.com//dhlserver/DHL/portal/?email=enquiries@my_domain.co.uk   SHA-256 691ec4a0d6d24af2fe6f0e2715c11c8bcef7ad72f2d43c859f19a9ac93ecb8dc   SHA1 4516f515484f4ae98d09de7b1ce309024abf6fe0   MD5 31aff8cb2eed386d168d700aa0b0bba2   First Seen Timestamp 2019-03-18 14:45:46 UTC   Verdict phishing     Receive Time 2019/03/18 14:48:21 Details: Threat/Content Type wildfire ID 1238713750 Severity high Repeat Count 1 File Type email-link File Name hxxps://remove_me_walimusacco.com//dhlserver/DHL/portal/?email=enquiries     Would this sequence of events demonstrate the following was true:   - Our Palo Alto firewall recieved the phishing email at 14:44:58 and sent the email to WildFire.  As the email phishing URL was not currently known, the email was allowed.   - From the WildFire Analysis Summary, WildFire accepted the email for processing at 14:45:46, and our Palo Alto firewall was the first WildFire Palo Alto to see this particular phishing URL.   - After several minutes of processing, at 14:48:21, the email was determined to be a phishing email and set as such in WildFire.   - Any other Palo Alto firewall using WildFire would block that phishing email from that point in time onwards.   Is the above a reasonable summary of the events as detailed above?   Can I further conclude that if I have only seen WildFire phishing verdict as "allow", that all of our detected phishing emails are "first seen" phishing emails, otherwise I would have seen a blocked phishing email?   Thanks, Steve   Reason for editing: Obsfucation of malicious URL's ... View more

Using the packet capture is a VERY good idea, many thanks for that.  I shall investigate and report back in due course.   Thanks again.   Regards, Steve ... View more

Very good point, I have changed this to %USERINPUT%. I have been experimenting with many combinations, that just happened to be the one it was left on, which was not the best choice.   Thanks, Steve ... View more

Mick,   Many thanks for your reply. I have been working on this problem for a month now, and I am still no further forward.  I have our Palo Alto reseller support team working on this, but so far thay have not been able to work out what is  going wrong, so I thought I would continue with this post.   I have settled on LDAP and I can successfully get a user authenticated when using the command line test, as long as the Authentication Profile Allow List is set to "All" (why this is the case is a mystery):   admin@PaloAlto> test authentication authentication-profile "Remote Access Users - LDAP" username zzztest password Enter password : Target vsys is not specified, user "zzztest4" is assumed to be configured with a shared auth profile. Do allow list check before sending out authentication request... name "zzztest4" is in group "all" Authentication to LDAP server at 10.10.10.10 for user "zzztest" Egress: 10.10.10.110 Type of authentication: plaintext Starting LDAP connection... Succeeded to create a session with LDAP server DN sent to LDAP server: CN=zzzTest,OU=Test,OU=Users,DC=domain,DC=co,DC=uk User expires in days: never Authentication succeeded for user "zzztest" admin@PaloAlto>   However, if I then attempt to log in to the GlobalProtect portal using the same user, I receive an "Authentication failure: Invalid username or password".   When this occurs, if I use the "tail follow yes mp-log authd.log" command to examine the authentication logs, I see the following:   2018-07-12 15:23:58.420 +0100 Error:  _get_auth_prof_detail(pan_auth_util.c:1060): non-admin user thru Global Protect "zzztest" does NOT have auth profile 2018-07-12 15:23:58.420 +0100 Error:  pan_get_authprofile_n_setting(pan_auth_util.c:1123): Failed to get authentication profile for non-admin user thru Global Protect "zzztest" 2018-07-12 15:23:58.420 +0100 failed authentication for user 'zzztest'.  Reason: Authentication profile not found for the user. From: <external IP>. 2018-07-12 15:23:58.421 +0100 Error:  _authenticate_initial(pan_auth_state_engine.c:2518): Failed to get authentication profile 2018-07-12 15:23:58.421 +0100 Error:  pan_auth_request_process(pan_auth_state_engine.c:3324): _authenticate_initial() 2018-07-12 15:23:58.421 +0100 Error:  _taskq_worker(pan_taskq.c:622): Error executing tasks process fn   I do have an Authentication Profile named "Remote Access Users - LDAP" with the following settings: Type: LDAP Login Attribute: sAMAccountName User Domain: <blank> Username Modifier: %USERINPUT%@%USERDOMAIN% Allow List: All   This Authentication Profile is then referenced in both the GlobalProtect > Gateway authentication settings and in the GlobalProtect > Portal authentication settings.    Also, as the Allow List is set to "All", surely this means that any user would match this Authentication Profile?   Any advice on this is much appreciated!   Thanks, Steve       ... View more

BPry, many thanks for the reply.   Indeed, that is rather a lot of questions, I realise that after I posted and read it all back.   All I was really after was a pointer to which stone I should step on first (the most appropriate authentication method) and work my way forward from there.   As you suggest, I'll approach support and see what I can learn from there.   Many thanks, Steve ... View more

Dear BPry,   Many thanks for your reply and theory for why the email was allowed despite being malicious.   I have captured the timestamps of the Wildfire evets here, in case that helps accurately diagnose the issue:       WildFire Analysis Summary   File Information File Type JAVA JAR   File Signer   SHA-256 149862f4894c9dba2b21b507fa7bde835e6a6a44e35040331c5ab1de3ec4027d   SHA1 b8aed21b09bda3f02c54c53267ba696a1286e092   MD5 0ecacad6f88e1ddb859e881c1662b4a9   File Size 556535 bytes   First Seen Timestamp 2018-01-26 06:28:06 UTC   Verdict malware     Does this information give more visibility to the issue?   Many thanks, Steve   ... View more

Dear BPry, many thanks for your reply.   I have checked the Anti-Virus profile that is assigned to the applicable rule (Internet to Email Gateway) and the WildFire action is set to "reset-both" for all the listed decoders, including smtp, as can be seen here:     It would therefore seem that some other setting is at play here that is not immediately obvious.   I have examined the WildFire Analysis security profile, but this is set to analyze any file type and any application, so there does not appear to be a applicable setting here:     I'll continue to investigate..   Regards, Steve                       ... View more