About BrianRa

@vsys_remo wrote:   So if the client uses this name but connects to an IP that is controlled by an attacked, the firewall will happily allow the connection with the rule in your screenshot. As soon as I realized how that worked this was my first thought! Fortunately our DNS is fairly secure (externally anyway).  However if a bad actor got in and started spoofing DNS internally then yes we would have problems.  Also a user that understands the vulnerability would be able to access sites that are blocked.  We do have all of the Security Profiles built and are using all but Data Filtering on this rule.   Unfortunately I don't know that DNS proxy would work internally as we are using split DNS internally for both domain and some site requests.  During our initial configuration Palo Alto implied this was not prefered due to the load it put on the firewall (this may not be correct but it has caused us to avoid it on most of our networks). “Do not own a computer; Do not power it on; and do not use one.” Morris’s Three Golden Rules of Computer Security ... View more

@vsys_remo I have included the rule.  We have tried with both Application and Service (better results for internet access in general with Services as it turns out). Yes all the log results are the results of that rule.  We removed all confidential/internal data from the excel sheet.  In that timeframe dozens of hosts had made requests to get to the site.  All the "Destination address" results are valid IPs for the dev-prod05.conferdeploy.net domain.  From what I understand the firewall checks the DNS of the requested domain/site and if they do not match blocks the request (DNS poisoning of a client can be prevented this way). [EDIT] I stand corrected.  We did not have that domain properly in the "Vendors Whitelist" like we should have.  We had a ruler higher up in the stack we were using that IS using FQDN for all CarbonBlack domains we need.  I added the dev-prod05.conferdeploy.net properly (spelling) into the custom URL Category and it is functioning properly.    FQDN - does a DNS lookup to ensure the information is correct Custom Objects -> URL Category - only checks the domain to ensure it is in the allowed/denied list (as this is SSL an invalid cert warning should popup [in a browser] or the application should [hopefully] fail due to the failed cert)   [/EDIT] ... View more

@rmfalconer I will break each one down so it makes more sense.  If you understand more than this and it is redundant I apologize but I want to make sure it is all clear.  All definitions are in reference to what I am doing with it.  A not on the ".txt" extension, this has nothing to do with linux but makes it easily Windows readable (auto opens in notepad++ for me). host = nslookup | breaks out for the new command based on the results of the previous command grep = search request based on the result of "host" command (because of the pipe) containing the word "has" awk = a programing language initiator for printing the 4th value in the string based on a space breakout >> is equl to an append at the end of file > is equal to a replace/create file rm = remove file   RUN EVERY 5 MINUTES (Done every 5 minutes to try to capture all the IPs that are available)                   host dev-prod05.conferdeploy.net | grep has | awk '{print $4}' >> dev-prod05.conferdeploy.net_BULK-IPs.txt dev-prod05.conferdeploy.net has address 52.45.174.75 dev-prod05.conferdeploy.net has address 52.2.229.136 Find all lines that contain "has" in the line Now pull out the 4th variable based on a space delimiter from each line 52.45.174.75 52.2.229.136 Paste that value at the end of the current/defined txt file   RUN EVERY 10 MINUTES (Done every 10 minutes to try to capture new IPs but there is no reason to do it as often because the likely hood of a new IP after the first hour is low)                   awk '!seen[$0]++' dev-prod05.conferdeploy.net_BULK-IPs.txt > dev-prod05.conferdeploy.net.txt Search in the defined "BULK-IPs.txt" file for a unique value Repeat this command for all lines in this file Paste that unique values into a new/overwritten defined txt file   RUN ONCE A DAY: (I chose once daily because it is easy to troubleshoot and keeps the file down to the expected 30 IPs)                   rm /dev-prod05.conferdeploy.net_BULK-IPs.txt Remove the defined "BULK-IPs.txt" file There is no reason to rm/delete the dev-prod05.conferdeploy.net.txt final product file because it is already overwritten every 10 minutes with a new file   Please let me know if any of this does not make sense and I will try to explain it. ... View more

vsys_remo thanks for the reply. We currentlly have a rule for all "non internet" users/machines that has a URL Filter and we have added a "vendor whitelist" URL Category.  The domain is in this custom list.  This rule also onlly allows SSL and HTTP applications. This is the rule that is sometimes allowing access and other times denying based on whether or not the PA knows about the IP being used.  I may be missing something you are adding but the custom URL Category list only allows me to put in domains. ... View more

Generate Time Source Destination Destination address Application Action URL 9/10/2018 10:00 Internal External 18.214.112.236 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 10:00 Internal External 34.198.54.80 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 10:00 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 10:00 Internal External 34.199.106.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 10:00 Internal External 34.192.44.112 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:59 Internal External 34.198.88.190 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:59 Internal External 34.198.88.190 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:59 Internal External 34.199.227.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.237.240.4 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.237.240.4 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.237.240.4 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.237.240.4 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.237.240.4 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 35.173.197.210 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 35.173.197.210 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.234.104.211 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:56 Internal External 34.198.54.80 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.192.44.112 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.194.166.1 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.198.88.190 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.192.210.120 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:55 Internal External 34.199.106.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:54 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:54 Internal External 52.207.81.137 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:54 Internal External 52.207.81.137 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:54 Internal External 34.197.159.199 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.199.227.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.198.54.80 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.192.44.112 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.192.44.112 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.199.227.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.194.166.1 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.194.166.1 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.192.210.120 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.199.227.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:53 Internal External 34.197.244.92 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.197.244.92 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.192.44.112 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.194.166.1 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.199.106.239 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.194.166.1 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.199.106.239 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:52 Internal External 34.192.44.112 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:51 Internal External 34.199.106.239 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:51 Internal External 34.199.106.239 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:51 Internal External 34.199.227.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:51 Internal External 34.197.244.92 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:51 Internal External 52.207.81.137 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:50 Internal External 52.207.81.137 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:50 Internal External 52.207.81.137 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.199.227.239 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.192.210.120 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.192.210.120 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.198.54.80 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.198.54.80 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.192.210.120 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 18.213.132.157 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.197.159.199 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:49 Internal External 34.199.106.239 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.194.191.180 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.238.4.33 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 35.173.197.210 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.238.4.33 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 35.173.197.210 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.238.4.33 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.206.73.176 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 18.214.112.236 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 18.214.112.236 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.194.191.180 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.238.4.33 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:48 Internal External 34.225.200.240 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:47 Internal External 34.237.240.4 ssl alert dev-prod05.conferdeploy.net 9/10/2018 9:47 Internal External 18.214.112.236 ssl block-url dev-prod05.conferdeploy.net 9/10/2018 9:47 Internal External 34.239.202.48 ssl block-url dev-prod05.conferdeploy.net ... View more

We are currently fighting a problem with the dev-prod05.conferdeploy.net domain name and our firewall rules.  When doing a DNS lookup on this domain devices return 8 IPs.  However this domain has at any given time 30 IP entries (based on the monitoring script I wrote that resets every 24 hours).  If you work with firewalls (or any device) you know that they only do a DNS lookup every so often then cache the results.  This is a problem when a PC/Server can do the same lookup and come up with 22 IPs the firewall does not know about. We are seeing the firewall allowing and rejecting the same domain name because it does not know the IPs the client is trying to reach (see the excel document).  This would be fairly simple (though clunky) to either tell the firewall to check a FTP file with the list of IPs in it for that domain or just enter all the IPs into a firewall rule and ignore the DNS but over the last couple of months monitoring dev-prod05.conferdeploy.net the IPs have changed.  This is the reason I set the script to reset every 24 hours. What are people doing to combat this problem?  Other sites do not present in this manner.  Is this a security thing for CB Defense (so many IPs its hard to take down)?  Or a misconfiguration on the DNS that shows all the current IPs regardless of the region your IP is in?   This can be tested at any time by opening the command line and typing “ nslookup dev-prod05.conferdeploy.net ” (Windows) 4 or 5 times in a row.  Each time 8 IPs will present and each time there will be IPs that were not listed in the previous lookup.   Our specs: Palo Alto Firewalls (8.x) Windows 7/10 desktops Windows 2012/2016 servers   Linux scripts: RUN EVERY 5 MINUTES                   host dev-prod05.conferdeploy.net | grep has | awk '{print $4}' >> dev-prod05.conferdeploy.net_BULK-IPs.txt RUN EVERY 10 MINUTES                   awk '!seen[$0]++' dev-prod05.conferdeploy.net_BULK-IPs.txt > dev-prod05.conferdeploy.net.txt RUN ONCE A DAY:                   rm /dev-prod05.conferdeploy.net_BULK-IPs.txt ... View more

Glad to hear it went well for you @jsalmans. Yeah, we were warned about them not being able to sync more than one major revision apart.  Did you notice any session drops when you forced the fail over from 8.0 to 7.0?   Brian ... View more

The second thing has to do with an odd internally built HA active/passive system we are using that we had to shoe horn into doing what we want.  The bottom line "I think" is that when we failed over from Primary to Secondary and did not fail back this system lost connectivity.  Not because the failover caused the session to become invalid but "we think" the system is doing more than checking session state.  I don't have details yet but "I think" it is doing not only a session state check but also a physical check on the path it is taking between active/passive devices.  It is checking something on the physical side (MAC or something else) and if this changes the "we think" the session is no longer considered valid.  Where this became a problem is that historically we have done reboots and Primary failed to Secondary then after the reboot Secondary failed to Primary as Secondary was then updated and rebooted in turn.  This process meant that the Secondary firewall was only the active one for 5-6 minutes.  We believe the failover state of the system we are working with is closer to 10 minutes so when we made this change and did not fail back over to Primary the system did not see a recovery of the session in time (no hardware match??) and failed over to the passive remote system.  "We think" the system either did not create a new session as the old session was invalid or the time out for creating a new session does not match the failover timeout.  We will clearly need to do more testing.  As a network engineer I don't really have any involvement in this system (till it breaks, lol) or in how it was built.  I may or may not have an update on this, I'm not sure if it matters to other organizations as this was internally built.   Brian ... View more

Ok, as promised we did do some firewall upgrades this week and here are our thoughts. First we updated one of our remote sites from 7.1.10 to 8.0.7 (PA-3020).  We did this by upgrading to 8.0.0 then rebooting and upgrading to 8.0.7.  We have not found any problems with.  Both before and after Panorama pushed without problems.  This site has: MPLS, IPSEC VPNs, LDAP, Security/NAT/PBF rules, virtual and physical interfaces. This site does not have Global Protect configured or HA.   We later upgraded our passive HA firewall to 8.0.7 (PA-3020).  As this was a secondary firewall we upgraded directly to 8.0.7 (not recommended for some firewall versions but the PA-3000 series was not in that list so we tested it).  It upgraded fine and we were able to push configs from Panorama after the upgrade without problems.  After confirming everything was still present and correct we failed over from our Primary HA 7.1.10 to the Secondary HA 8.0.7 without problems. This site has: MPLS, IPSEC VPNs, LDAP, Security/NAT/PBF rules, HA (active/passive), GP Portal/Gateway, virtual and physical interfaces.   We learned two things but only one of them I think will apply to anyone else. There is a setting that specifically relates to AD users prefix while using LDAP lookups (we think this only affected GP connections but are not 100% sure). Device -> Authentication Profile -> <Auth_Profile> -> User Domain = <domain> In this field we had previously entered the DOMAIN.local the new value must just be DOMAIN in the sense that you would type DOMAIN\USER.  The problem we found is that in 7.1 (and older) the user would authenticate and the DOMAIN would be added, no problems here everything was happy.  After upgrading to 8.0 we found that the system had now changed to take the literal prefix and was now showing users as DOMAIN.local\USER.  They would still connet through GP however every rule in the firewall that had a user based restriction/requirement would now reject these users.  DOMAIN.local\USER was not valid anywhere.   Brian ... View more

Has anyone opened a support case on this?  It may be a bug they need to look into. Could be versions with specific configs that are not working together.  That kind of stuff happens sometimes.   Brian ... View more

@jdprovine, in many ways that is the positive and negative to Palo Alto.  There are many pieces that can be configured and often there is more than one way to put them together.  Thats great for this specific thing or that but at the same time it makes it very difficult to create that standard config that you can just pass off to the next guy.  He probably did something different.   @Mick.Ball, the only suggestion I can make on using more than one internal device check is to configure both the IPV4 and IPV6 devices.  It let me configure both but we are not currently using V6 internally so I can not test the functionality for you.   Overall we have found the internal vs external configuration works very well (aside from the network swaps previously mentioned).  We have actually found the majority of our GP VPN client problems come from the actual client install itself having problems.  It will either not install properly the first time or something later (we can only assume) messes up the install when it is either installed or updated (new program, updated program, windows update, etc).   Brian ... View more

@mcjyrnnwould you try this rule for me.  You should not actually need two rules.  By adding both to the source and destination it allows any of the networks to ping eachother. You can even copy one of the rules and modify it below the two existing.  Please also use just the applications I had.  RDP is something I would not allow both directions on all IPs.  However ICMP, PING, and TraceRoute should not be a problem for testing. (Yes I did paint hack it ; )   The reasoning for traceroute, like previously mentioned, is to check to make sure the traffic is symetrical and not returning a different route (ping often doesn't mind this) or that it isn't trying to go out a different gateway and getting lost in space.   Brian ... View more

Ryan,   We had pushed these components from Panorama so I am not sure exactly what is supposed to synchronized in Devices -> Setup in an H/A pair.  I do know that the entire Setup portion is separate from the production config as it is the management plane.   Brian ... View more

Thanks @Mick.Ball, I wasn't trying to argue I was confirming everything you had said.  That is actually a very good differentiation.  We allow them to sleep then hibernate.  When they come back up the laptop thinks nothing has changed, checks its network and corrects.  GP does not always update when the interface updates.  This is where the rediscover network comes in. I am not saying by any means this is a large problem, just one it is better to be aware of.  Initially we received quite a few calls because "it takes forever to come back up".  The GP VPN works much better than many others I have used.   Brian ... View more