4. SSL Forward Proxy Using an Internal PKI Subordinate CA
So most companies prefer to centralise their certificates using their internal PKI. I’m going to show you in this lecture how to create a CA certificate for your Palo Alto Firewall from your internal PKI. and I am creating it using the Windows 2012 server. I’ll open the management console, click files add, remove, snap in, add the certificate templates, click Add, and then click Okay. And I’m going to find the subordinate certificate authority. Right-click on it, then choose Duplicate template. This is the template I’m going to be using to create a subordinate CA for the Palo Alto Firewall. This way, it is part of the chain of your internal organization’s PKI infrastructure. I’m going to call it Palo Alto Firewall CA under general. And under the validity period, you can change the validity period issuance requirement. You can make it require management approval, which is recommended since this is supported by CA. But in our case here, I’m not going to check that security. You have to make sure that the user who is going to request this certificate is allowed to enrol enrollment. So I’m a part of the main admin, and it’s allowed enrollment, and then I click okay.
And then you’re going to go to Certificates of Authority and click on certificate templates. I’m going to create a new certificate template to issue. I’m going to find the certificate template that I just created, Palo Alto Firewall CA, and click okay. So now it’s part of the CA template and my certificate template that can be issued by the certificate enrollment system. And I’m going to go to the Palo Alto file here and generate a certificate. I’m going to specify the external authority and give it a name: PKI internal PKA, common name. I’m going to call it Lab Internal Two. Just differentiate it and then generate. You can add more variables here. Now that this is generated, I’m going to click on it and then say “export,” and basically it’s exporting the CSR. So I’m going to save that file here and then open it up in a notepad.And then I’m going to go to the Windows 2012 enrollment. It’s on this local server here. Certsrv will request my username and password. I’m going to choose “Request Certificate,” an advanced certificate request. Paul Altos Firewall C is the template I’m going to paste in the CSR here and then click submit. Once it’s submitted, I have it. Now you need to make the certificate name the same as what you have here. So it’s called labpica.
I’m going to specify import and then choose a certificate file. It doesn’t like the name. Allow me to rename it PKI cert before clicking OK; I am unable to extract the certificate. It needs to be in base 64 encoding. Let me save it again. That was created. So I am basically getting a subordinated CA certificate from my internal PKI. And if the internal PKI root CA is trusted by the clients, then the clients will basically be automatically configured for me, right? I don’t need to add anything else. So it’s part of your PKI infrastructure. So now that I’ve created that, I’m going to go here and uncheck “trust” and then go to the new certificate and say “forward trust certificate.” So I changed it to the internal PCI issued and then clicked “commit.” And now I’m going to go to Google.com. Well, the problem here is that this browser does not have the CA as part of the trusted CA. In my case, I’m going to go ahead and open up that certificate and make it trusted locally on the browser. So I’ll open it up, I’ll go to Options > Advanced View Certificates, import this certificate, and then go under Authorities and import that. There you go.
Here it is. So now Firefox shouldn’t complain when I do that. Okay, open Firefox again, and now it’s happy. Click here to see more information. It was issued by Lab Internal too. If I open Internet Explorer, I don’t have this issue because Internet Explorer is part of the Windows settings. And if you have a CE infrastructure, the clients trust this certificate of authority. and Internet Explorer will not complain. As far as I can tell, no complaints were received. This was not something I needed to add to Internet Explorer. I’m in the wrong browser. Internet Explorer automatically understood it. If I go to [email protected], I see that the certificate was issued by WDCA. When I click “view certificate,” I see that this is the CA that I have on the Pal Altofiwall that issued the www.dot.yahoo.com. And the certification path shows me the Lab internal two, which is the certificate on the Pal Alto Firewall, and the Labad CA, which is the root certificate. The certification path is validated, and everything is okay there. So in the case of Internet Explorer, I didn’t need to make any additional settings, but in the case of Firefox, I needed to add this manually.
5. SSL Forward Proxy Blocking Threats in Encrypted Traffic – Demo
So now that we are decrypting the traffic, we can actually look at vulnerabilities in viruses and spyware for encrypted traffic. So I’m going to show you an example of how to test that out. I’m going to go to www.google.com.com to search for the ER car test file. SSL-encrypted URL filtering is the policy. Let’s check the policy. And it is this policy that is causing people to lose trust in application security. I’m going to specify applicationany here and then action the outbound profile group. Let’s take a look at the Outbound profile group. Outbound A profile group is a profile group.
The profile group includes up-bound file policy and data filtering. So click okay, let’s commit that, and we’re going to download this file one more time. Okay, we’ll try it one more time. And you see here that it’s blocked because it was identified as malicious. And this is https: So let’s go and find this. It was called “URL filtering malware.” It’s under the URL. Filtering blocks URLs. So it’s getting blocked under the block URL, which is not what I’m really intending to do. So let me remove the URL filtering policy and try it again without the URL filtering policy. I’m going to go back to trust and trust here, and I’m going to change it from a group to profiles and antivirus upon average protection upon IPS anti-spyware upon spyware, which you are filtering, and leave it alone.
Fire blocking up on a fire policy after a wildfire and then changing it to remove the oil filtering to see if it shows up under viruses, which it should. Okay, so now let’s try downloading again. With this error category of malware, you’re attempting to gain access to a web page. So let’s see what was detected. Oh, I need to put this policy up top here. It was violating this policy. So I’m moving it up, and I’m going to go ahead and commit and try it again because I don’t want it to get caught by the RL filtering. I want to get caught by the actual antivirus. So I removed the oral filtering. Let me confirm that it downloaded the files. Let’s see what we see here. Under the monitor thread, it’s detected as a medium EI card test file. Let’s look at the actual log to verify that it’s a portfolio. Yeah, it’s portfolio three. So it encrypted the traffic, detected the file, and since it’s medium, it didn’t block it. So I’m going to change “medium” to “block” in my policy. I’ll go to the antivirus outbound avert objects. I’m going to change it to drop.
Because HTTP is considered both HTTPS and HTTP, I’m changing it to block. I’m trying to download the file one more time to prove to you guys that it’s working. Basically, when you decrypt the traffic, if somebody tries to download a malware file, it’s going to block it. So, now that it’s been blocked and attempted to download it, it basically detected it as a virus or spyware because I changed my policy to deny even anything under the AV policy and I specified to block anything under HTTP to drop it. Action drop. Let me download a different file here from the internet. So if I do that, I’ll be downloading another Excel file; if I download this, it will be fine. didn’t block it. Nothing is under threat. So when I changed my policy to “drop” instead of “alert,” it basically dropped. That proves to us that the actual firewall is in the middle of the traffic, decrypting it and detecting any malicious traffic. And that’s the benefit of doing SSL through a proxy.
6. SSL Inbound Inspection
In this lecture, we will look at how to configure the Paul All firewall to do SSL inbound inspection. This basically entails you providing the existing certificate that runs on your public web servers or your servers that you’re hosting on your DMZ. You need to export the certificate along with the private key for those servers and then import them into the Palo Alto Firewall. The Palo Alto Firewall, armed with the certificate and the private key, will be able to listen in on the conversation going to the servers, decrypt the traffic, determine if there are any vulnerabilities, and do the threat prevention like it should on encrypted traffic.
So it does the decryption by having the same certificate you would have on your servers. Show you this on the most commonly used web server, which is the IS server. You can export the certificate by going to the server name and then clicking on “Server Certificates,” and then use the certificate. Highlight the certificate that’s used by the server and choose export. Provide a name for the file. I’m going to give it a name here, “Certis,” and click “Open.” Then provide a password, and then click okay. So that will export the certificate. Now you go to Palo Alto and import that certificate, browse to the folder where it’s downloaded, and then provide a name. Import the private key. Well, this is PKCS 12, which has the private key, and then provide the password that you provided when you exported it from the IRS. And then click okay. So now you see the IRS certificate here.
The next step you have to do is create a decryption profile if you’d like. I’d like to create a separate decryption profile, and perhaps you can specify some of the settings, such as SSL protocol settings, and then click OK. Okay, do it for differentiation between the different profiles. Then you proceed to policy decryption. This traffic is coming in from the outside to the public IP address of the firewall server on port 443, which then nets it to the IRS server on port 443. So I’m going to add a policy for decryption. Give it a name and specify it. The source of the IIS decryption will be untrusted; the destination will be trusted or untrusted. Because the traffic comes in first on the public interface, it gets decrypted, netted, and sent to the trust side. For the trust interface, it could be the DMZ. If the server sits on an internal DMZ service URL, I’m going to specify the service port. I’m adding port 844-3244-3 in my case. So I’m going to specify service 8443. That’s the destination port. And then under options decrypt, we’re going to choose SSL inbound inspection, select the certificate that you imported, and then choose the decryption profile that you created, and then click OK.
So now any traffic coming in from the outside to the IS server going to port 8443 is going to get decrypted with IS decrypt. The next step is the security policy. I’m going to allow this. Traffic is currently not allowed. So I have the rule named “RDP to Windows.” It’s probably not a good name. This will be called Windows Server. and I’m going to specify that service. Eight, four, three. Then there was the action, the same action. And then, on the net policy, I need to create an ad for that traffic to the port. Currently, I have port 3389 (destination) added to the server. I’m going to add port 8443 to get the destination added to port 443. original packet coming from the untrustworthy destination zone. Untrust. then the destination address. That’s the public IP address of my firewall. And then the service specifies the 8443 translated packet. We’re going to do destination address translation and specify the IP address of the server and the port. So now that all those changes are done, I’m going to go ahead and commit. commit and then close.
So now I’m going to my server, and I’m getting an error because this certificate is internal. And now I see the IS server. And the key here is to go back to the firewall and determine if the traffic was decrypted. Going back to the firewall, I know the exact source. So I’m going to refresh here to make sure I got the session. And I’m going to click on the magnifying glass. And you see here that the traffic was decrypted. So if you look at the flags, you see the traffic was decrypted. The Palo Alto would have the same certificate as well as a copy of your public servers’ certificate. And then you configure the decryption policy to use the certificates for the different servers you have on the public network serving public users. And then it will be able to decrypt the traffic this way.
