About EdwinD

In an attempt to understand MineMeld better, I have made multiple attempts at setting up a simple DShield configuration.   At some point or another I have had a configuration where indicators age out from either the miner, the aggregator or the output node.   I believe it was when I used the Hail a TAXII miner the indicators eventually age out of the miner itself.   Before I opened this discussion I spent a lot of time in this forum, in the KB articles as well as looking at the discussions at the source repo. I discovered that I want to use the an age_out default of null and sudden_death of true: age_out: default: null sudden_death: true interval: 300   With my currently configuration I have the entire DShield list in my DShield specific miner and aggregator.    For testing, I have a simple html text output node using this aggregator.  The indicators are currently all listed in this output node.  The output is simple IP ranges, formatted like the DShield feed located here: http://panwdbl.appspot.com/   I have MineMeld TAXII output node with this same aggregator as the input.   This TAXII node is feeding into ProofPoint TRAP (Threat Response Auto Pull).   ProofPoint lists 0 indicators in this TAXII feed.    For what it is worth, I have several other MineMeld output nodes which are working.  The difference is that the majority of these originate from MineMeld TAXII miners mining STIX from other TAXII feeds.  Unlike the raw DShield text block list miner, these other miners of STIX data have timestamps which are correctly updating at each poll.         In prior configurations I would see the DShield indicators age out after almost exactly an hour, almost exactly after 24 hours or 30 days.   I believe part of this is explained based on differences between having the configuration setup as production versus experimental.   I believe another reason for this is because I previously had age out set to first seen + 30 days.   I believe my current problem is that the TAXII node is creating artificial first seen, last seen and age out timestamps based upon when I first setup this instance of DShield within MineMeld.  So while the indicators are in the MineMeld TAXII node, these dates are telling ProofPoint that these indicators are aged out.   I believe what I need is a way to update the last seen and age out timestamps within the miner itself.   I specify the miner because I desire a more complex setup.  If I want several  aggregators making use of the DShield miner as an input then I need the miner to be resolving this issue.   I think..  I'm not entirely sure my analysis is accurate.   Any and all help is appriciated.   Thank you.        ... View more

>> whitelist some IPs from the indicators extraced from syslog? While not excluding them at the time of extract.  Not all feeds should have these whitelist entries excluded from their final output. ... View more

I believe I see what I had wrong.    Because I hwave whitelist_prefixes set to wl, the processor name itself must also begin with wl.  I had only named the miner begining with wl.   So, I configured a processor with a name begining with wl and bound it to two inputs, the wl miner containing my RFC1918 addresses along with my syslog+7 days miner.  This worked.   Within this same config I have an identical processer with the exception of the name, it does not start with wl.  The output node is identical except it points to this processor.  This one has the RFC1918 addresses.   The point being that with only the name of the processor changing I can see the whitelist working.     I think the following is the relevant config.   I have 300+  lines in the config ATM, so I'm not posting it all.   The end result in this case is that I have PanOS syslog output feeding into MineMeld while whitelisting RFC1918 addresses.  Longer term I could use external dynamic IPv4 lists, such as a list of CloudFlare addresses,  as a feed into a whitelist that I aggregate against the PanOS syslog entries to generate output feeds that I can use in specific dynamic PanOS firewall rules.  After enough hits from an IP, if it isn't on a known list, completely block that IP at every firewall at all locations for a period of time.  This is just one example of many I'm considering.   syslogMiner7Days: inputs: [] output: true prototype: minemeldlocal.syslogMiner7Days aggregatorIPv4GenericStaticWhiteList: inputs: - wlWhiteListIPv4 output: true prototype: stdlib.aggregatorIPv4Generic wlWhiteListIPv4: inputs: [] output: true prototype: stdlib.listIPv4Generic localSyslog7Days: inputs: - syslogMiner7Days - wlWhiteListIPv4 output: true prototype: stdlib.localSyslog wlListIPv4Generic-testingWhiteList20171222b: inputs: - wlWhiteListIPv4 - syslogMiner7Days output: true prototype: stdlib.aggregatorIPv4Generic feedIPv4TestingWhiteList: inputs: - wlListIPv4Generic-testingWhiteList20171222b output: false prototype: minemeldlocal.feedIPv4TestingWhiteList    ... View more

No, although I do have a WildFireEvent miner cloned from localDB as per the article "Using-MineMeld-as-a-Incident-Response-Platform".   Is localDB what I should be using?          ... View more

I backreved to 8.0.4-5 due to issues with 8.0.5-7 including the one you mention.   There is also another issue which appears to affect a machine based on the XML parser installed, I think.  On one machine I have this setup   UserIDAgentConfig.xml   <include-exclude-settings> <net-entry name="Misc4" include="0" address="172.16.4.0/24"/> </include-exclude-settings>   Whereas on the other I have this   <include-exclude-settings> <net-entry name="Misc4" include="0" address="172.16.4.0/24"/> <include-exclude-settings/>   The difference is in where the / is located in the closure.   Copying the settings from one machine to another causes the service to crash with the following errors in UaDebug.log.  My real list has around 30  lines.  I ended up copying the UserIDAgentConfig.xml from one machine to the other and then manually changing where the closing / is located, which worked.     12/22/17 12:18:15:399[Error 2378]: getaddrinfo error: The specified class was not found. !!!! 12/22/17 12:18:15:399[Error 726]: Failed to setup listening sockets 12/22/17 12:18:15:399[Error 753]: Start service failed due to start device link failure! 12/22/17 12:18:15:399[Error 2165]: Start error -1!! 12/22/17 12:18:15:399[Error 764]: Device listening thread stops timeout! 12/22/17 12:18:15:399[ Info 2010]: Service stopped.   I spent a lot of time figuring this one out.   Hopefully this helps someone else. ... View more

FWIW: regarding this vulnerability, I recently upgraded an HA pair of PA-3050's running 7.0.18 to 7.0.19.   I'm experiencing some issues with SSH connections.  I do not know if this is related or not.   I've also been running into errors causing commit failures.   These are errors I've never seen before though is reminiscent of a problem I recall from the PanOS 4.x days.   I would post the message had I not since cleared the logs.   What I've noticed is this:  LAN->DMZ SSH sessions are being dropped even though the destination IP is whitelisted.   This destination has decryption disabled by the destination IP address.  After many attempts to resolve the issue, SSH began working after I removed all security profiles from the security policy for this destination. LAN->WWW sFTP sessions are being dropped.  The destination is whitelisted and has SSL decryption disabled.  In this case there is no decryption profile assigned to the SSH proxy decryption policy rule.   After many attempts I was able to get this working within the latest version of WinSCP by turning on SSH decryption at the firewall.  Yes, enable decryption.   Yes, this is sFTP and not FTPs.  FileZilla still does not work.   It begins cipher exchange and then the connection drops.   From very limited testing, AIX sFTP does work as does Ubuntu sFTP.   The destination is secure2<.>benefitfocus<.>com on port 22.    The site is apparently running a version of GlobalSCAPE Enhanced File Transfer Server from 2007 (v. 5.1).   This may not be applicable to 8.0.6 and I am not 100% positive that this is a PanOS issue.   ... View more

If I  understand this issue correctly, the problem is that the PanOS 4.x cannot handle the SNI extension that is part of TLS. Amazon Cloudfront added SNI support March 2014.   Amazon CloudFront Adds SNI Custom SSL and HTTP to HTTPS Redirect Features I can't whitelist  the entire Cloudfront range; that would be a very bad thing.  It seems like it could become a big deal. It appears that PanOS 5.0.7 added basic support for SNI.   I suppose it it time for me to upgrade off of the 4.x branch. --- Q. What is the difference between SNI Custom SSL and Dedicated IP Custom SSL of Amazon CloudFront? Dedicated IP Custom SSL allocates dedicated IP addresses to serve your SSL content at each CloudFront edge location. Because there is a one to one mapping between IP addresses and SSL certificates, Dedicated IP Custom SSL works with browsers and other clients that do not support SNI. Due to the current IP address costs, Dedicated IP Custom SSL is $600/month prorated by the hour. SNI Custom SSL relies on the SNI extension of the Transport Layer Security protocol, which allows multiple domains to serve SSL traffic over the same IP address by including the hostname viewers are trying to connect to. As with Dedicated IP Custom SSL, CloudFront delivers content from each Amazon CloudFront edge location and with the same security as the Dedicated IP Custom SSL feature. SNI Custom SSL works with most modern browsers, including Chrome version 6 and later (running on Windows XP and later or OS X 10.5.7 and later), Safari version 3 and later (running on Windows Vista and later or Mac OS X 10.5.6. and later), Firefox 2.0 and later, and Internet Explorer 7 and later (running on Windows Vista and later). Older browsers that do not support SNI cannot establish a connection with CloudFront to load the HTTPS version of your content. SNI Custom SSL is available at no additional cost beyond standard CloudFront data transfer and request fees. Q. What is Server Name Indication? Server Name Indication (SNI) is an extension of the Transport Layer Security (TLS) protocol. This mechanism identifies the domain (server name) of the associated SSL request so the proper certificate can be used in the SSL handshake. This allows a single IP address to be used across multiple servers. SNI requires browser support to add the server name, and while most modern browsers support it, there are a few legacy browsers that do not. For more details see the SNI section of the CloudFront Developer Guide or the SNI Wikipedia article . ... View more

The DNS entry app-assets.plangrid.com cnames to dogqy6r8czetd.cloudfront.net which points to IPs in Cloudfront. The DNS entry app.plangrid.com cnames to gifu-9754.herokussl.com which cnames to elb037100-1517692282.us-east-1.elb.amazonaws.com which points to IPs in Amazon AWS. Both of these use the exact same RapidSSL wildcard certificate. The problem appears somehow related to https://dogqy6r8czetd.cloudfront.net/    With decryption turned on, I can't access this.  With decryption disabled I can. Is this a bug in PanOS 4.1.16?   Or could this be related to SSL Decryption for Some Site Shows as Not Trusted ?? Could someone else running PanOS 4.1.16 with full decryption enabled see if they can connect to https://dogqy6r8czetd.cloudfront.net/  please? ... View more

For what it is worth, my Palo Alto Firewall 2050 running 4.1.16 has the same issue that you describe bgranholm. When I click on the login link on sap.com, the link directs me to https://accounts.sap.com/saml2/idp/sso/accounts.sap.com which is obviously an SAML2 SSO redirect.  This never completes. dreputi's method might work depending on where the SSL is failing at.  I suppose one could alternatively create a decryption policy rule to exclude decryption of 155.56.59.145, as that is where accounts.sap.com resolves.   If this works for you, it would allow you to decrypt other aspects of SAP without decryption the SAML server.  I would advise against a FQDN decryption rule and I will mention that this IP will likely change in the future; you will need to keep the decryption rule updated. In either case, you may need to this command from the CLI to make the change effective: debug dataplane reset ssl-decrypt certificate-cache       And then you may need to restart your Internet browser. Edwin ... View more