About jhopple

@reaper Thanks ... View more

@reaper That's kind of the direction I was leaning (ref typo on guide) That's also how I thought the trailing / was interpreted (ref hard stop). I still felt inclined to write out the logic (based on the doc said) even though it seemed ridiculous. For a brief moment I thought maybe y'all had a magical parser that could distinguish between a domain/sub-domain and a tld. Lasted about as long as it took to write out the first reference to ".download". So now the only question I have is this: If I request approval to have "*.domain/" added to block list, can I use you as an authoritative source and if download.windowsupdate.com gets blocked are you willing to take the heat? (That last bit is joke) ... View more

@reaper Something you mentioned in a similar thread seems applicable here. Below is a summary of the solution you provided. By adding ".com/" to the block list you will: Block all domains with a .com tld Still be able to access www.com.uk (Ref. https://live.paloaltonetworks.com/t5/Management-Articles/URL-filtering-with-domain-name-patterns/tac-p/185289#M4808) The solution implies the following: If you want to block the .com tld Then you should add "*.com/" to the block list If you add "*.com/" to the block list Then www.com.uk will not be blocked Following that logic: If "*.com/" blocks the .com tld Then "*.download/" blocks the .download tld If "*.com/" does not block www.com.uk Then "*.download/" does not block download.windowsupdate.com That means your solution should solve my problem. Decided to double check the admin guide which says, "Further, to block access to a domain suffix such as paloaltonetworks.com.au, you must add an entry with a slash ( / ) at the end. In this example, you would add *.paloaltonetworks.com/ to the block list." That implies: If you want to block paloaltonetworks.com.au Then you must add "*.paloaltonetworks.com/" to the block list If "*.paloaltonetworks.com/" will block paloaltonetworks.com.au Then "*.paloaltonetworks.com/" will block paloaltonetworks.com.uk If "*.paloaltonetworks.com/" will block paloaltonetworks.com.uk Then "*.www.com/" will block www.com.uk If "*.www.com/" will block www.com.uk Then "*.*.com/" will block www.com.uk So now we're getting into nested wildcards so I refered to a Management Article that says, "The asterisk (*) wildcard does not respect the period (.) as a delimiter and will continue as a wildcard until a subdomain, domain or top level domain is matched. *.*.sub3.com will match sub1.sub2.sub3.com. However, this should be avoided as a best practice as nested asterisks can create a performance impact on the device. Instead, as a best practice you can use: *.sub3.com. This will match sub1.sub2.sub3.com" (Ref. https://live.paloaltonetworks.com/t5/Management-Articles/Nested-Wildcard-in-URLs-May-Severely-Affect-Performance/ta-p/61323) So, picking up where we left off and keeping that in mind: If "*.www.com/" will block www.com.uk Then "*.*.com/" will block www.com.uk If "*.*.com/" will block www.com.uk Then "*.com/" will block www.com.uk If "*.com/" will block www.com.uk I ran this thing to the ground on my scratch pad but I'll stop here. At this the assumed logic from the admin guide contradicts the assumed logic of your solution from the other thread. I would very much like to know: If your solution is actually valid If there was a typo in the admin guide ... View more

@lmori I'm running  VERSION: 0.9.44.post1 (AF) ... View more

@vsys_remo the recommendation to "simply block" those three Threat IDs is somewhat misleading and subject to misinterpretation. Your response makes it sound like blocking those three Threat IDs would address any crypto mining concerns. However, the IDs referenced are only applicable to CoinHive. While those IDs are relevant, especially in regards to the post by @reaper , they do not really address the question of "will we see a Palo Alto URL category for crypto mining ?" which technically extends to mining pools and any other site dedicated to mining (exchanges, how tos, etc). ... View more

Any updated thoughts on this? Still getting the internal server error on STAXX. Still no update from STAXX forum either. ... View more

Recently encountered the exact same issue regarding TLD blocks. Can anyone from PAN comment on why this is happening? According to the docs, there is an implied /* at the end of an entry. If that's the case, the entry *.download should not block *.download.windowsupdate.com, but it does. Like @mbrownnyc mentioned, manually adding the /* doesn't resolve the issue. ... View more

@lmori   Log from staxx can be found here   https://forum.anomali.com/t/minemeld-feed-returns-internal-server-error/1301/6 ... View more

I'm still not having any luck connecting to the MM TAXII feed from STAXX. Additionally, is there any way to try out that external extension from the Autofocus hosted version of MM? ... View more

@lmori thanks but unfortunately I'm using the MM app in AutoFocus so I don't think that would work. ... View more

@lmori I can understand the issue with reproducing since it seems to be heavily tied to STAXX. Is there an unofficial guestimate on when a hot fix will be pushed? Any possible unofficial/unsupported work arounds in the mean time? ... View more

@vedd3r I noticed in another thread that you're using MineMeld and STAXX. Have you by chance had any luck ingesting a MineMeld taxii feed into STAXX? ... View more

@lmori   Sorry for the delayed response, I keep forgetting to check the forum while working on this. I'm currently using the hosted version of MineMeld (Autofocus app). How do I pull these specific logs? I attempted to access the log dashboard and search for " minemeld-web.log" but it did not return any results.  ... View more

Not yet, s ince the last STAXX update, I'm no longer getting the internal server error. However, I am now getting an HTTP/1.1 401 UNAUTHORIZED error. To recap, the same feed URL and credentials work fine from other TAXII clients/servers. ... View more

I'm trying to ingest a TAXII feed from MineMeld into STAXX. After following the guidance found in multiple posts across the community, I'm still unable to get the feed to work. I've tried various tags (anonymous, any, custom) and I've tried both a "feed" user and an admin user for authentication purposes in STAXX. The errors I keep receiving are below:   [2017-08-28 07:52:33,742] [ERROR] STAXX: Failed to get_feeds for site https://[REMOVED].paloaltonetworks-app.com/taxii-discovery-service, response: None [2017-08-28 07:52:33,742] [ERROR] HTTP/1.1 500 INTERNAL SERVER ERROR Traceback (most recent call last):   File "taxii_stix.py", line 789, in get_feeds   File "taxii_stix.py", line 708, in get_version_url   File "taxii_stix.py", line 745, in discover_version   File "taxii_stix.py", line 733, in discovery_generic   File "taxii_stix.py", line 509, in make_request Exception: HTTP/1.1 500 INTERNAL SERVER ERROR [2017-08-28 07:52:33,742] [ERROR] Discovery failed. ... View more