Something strange happened to my VM setup on my laptop yesterday. I was unable to connect to the PA GUI all of a sudden. The VM booted up fine and I could log on via the CLI and checking the management interface I had the correct IP address which was still set to 192.168.1.222 to check this use the following command on the CLI.
#show interface management
Thinking that something became corrupt with the VM I started to check all the settings and everything checked out ok there, nothing obvious had changed. Since it was a lab environment I decided to fully remove my Palo Alto VM from VM Workstation and to start over again.
Well that didn’t help I had the same issue, VM boots fine, I can log into the CLI fine, this time I got a different IP address as by default the management interface is set to DHCP and I was given the IP address of 192.168.1.17 but when trying to connect to it via https it would timeout. mmmm what gives?
I then tried to ping it from the windows command line and got back ‘Destination Host Unreachable’, time to check the windows route table to see if the IP address was in the routing table. It wasn’t ! This is a problem.
To check the routing table on Windows use the following command from the command line.
#route PRINT -4
It will show all the IPv4 addresses in the routing table. No IP address 192.168.1.17 so I added it into the routing table using:
#route ADD 192.168.1.17 255.255.255.0 192.168.1.1
BINGO I am able to connect via the GUI again. When on the GUI I changed the management interface IP back to 192.168.1.222 and committed the change. I then added in the 192.168.1.222 address into the Windows routing table this time using the -p option which stands for Persistent so when I reboot my laptop that route will remain in the routing table!
This is a quick fix for now and allows me to continue to use the Palo Alto NGFW in my lab setup however I’m not sure how this issue came about, it is something I will look into further.
If anybody else has come across this issue and what caused it please let me know in the comments !
With IPv4 networks NAT is fundamental for it to work without it not a whole lot of devices would be able to surf the internet. For example your broadband connection uses NAT. You are assigned a public IPv4 address from your ISP on your WAN interface of your modem which allows you to surf the internet, within your LAN (home) all the devices you have attached to your WiFi network are assigned an address most likely from the 192.168.1.0/24 range which is from the private class C subnet range. These private IP addresses are not allowed out on the public internet and if you tried to use an address from a private IP address range your ISP will have an ACL blocking its use.
The job of NAT is to translate your private IP address that has been assigned by your modem at home to your PC for example and change the IP address to its public IP address before it leaves your modem.
If we take the following example:
Your PC as been given the IP address of 192.168.1.7 and you want to surf the Internet. Before you can do that NAT has to step in and change your private IP address to its public IP address using NAT or more specific PAT which is a form of NAT which stands for Port Address Translation which allows all the private IP addresses on your LAN to be translated to the single public IP address using port numbers to keep track of the different sessions from the devices in your LAN.
So NAT will translate the source IP address in the packet from 192.168.1.7 to 159.17.5.1 before sending the packet out its WAN interface towards its destination on the Internet. It will keep track of this translation in its NAT table:
192.168.1.7:80 = 159.17.5.1:8000
This mapping allows the return traffic to go back to the PC that started the session. If a second PC on the LAN went out to the internet and had an IP address of 192.168.1.10 it will also be tracked in the NAT table:
192.168.1.7:80 = 159.17.5.1:8000
192.168.1.10:80 = 159.17.5.1:8001
The second entry has a different port number assigned to it and this is how NAT/PAT keeps track of which traffic belongs to which IP address on the LAN.
Configuring NAT on the PA-NGFW
Here I will configure NAT/PAT on the NGFW to demonstrate how it is done.
NAT is configured under the Policies Tab on the left hand side panel select NAT and then click the Add button at the bottom to get started.
A new window will pop up asking for General information, give it a meaningful name and description then click the Original Packet tab.
Under Original Packet I’ve added the following:
Under Source Zone I’ve added the Internal zone, Destination Zone will be the Internet zone and I’ve selected the Destination Interface as the Interface that I configured as the Internet interface which as an IP address 192.168.1.250. Ok so 192.168.1.250 isn’t a public IP address but in my lab environment my modem is also doing NAT to a real public IP address before any traffic is sent. So for this lab I am pretending that 192.168.1.250 is a public IP address and it will translate IP address in the 10.1.1.0/24 network to 192.168.1.250 and my home modem will then translate the 192.168.1.250 again to a real public IP address. Hope that is clear enough. Ok back to the configuration under Source Address I selected the Object I created in an earlier lab called ‘Internal 10.1.1.0 subnet’. The Destination Address will be left to ‘Any’.
Next is the Translation piece so click on Translate Packet.
I have selected the Dynamic IP and Port as the translation type as I am using PAT. The Address Type is ‘Interface Address’ and I have selected the ethernet1/1 interface which is the Internet interface and the only IP address that is associated with that interface is 192.168.1.250. Next thing to do is click Ok and that is NAT/PAT configured. Don’t forget to commit the configuration for it to take affect.
To check that it is working I have started up the Windows 10 Virtual Machine I have as part of the lab. It is configured with the IP address of 10.1.1.25. I went to http://www.paloaltonetworks.com as you can see below it was successful.
This verifies a few things that I have done in the past blog posts. It verifies that traffic from the Internal zone is allowed out the Internet zone. It also verifies that the DNS, SSL protocols are allowed based on the security policy.
We can verify that NAT is working by looking at the NAT translation rule and see the hit count has increased to 985 meaning that it is working. I can’t show you this in the logs as I don’t have the license for that but will add one and show how that is done.
In my last post I covered Zones, Virtual Routers and Interfaces and how they all come together to form a basic configuration. As discussed traffic from one zone going to a different zone is denied by default, traffic going to and from the same zone called intra-zone is allowed by default. In this lab I am going to allow traffic from the windows machine out onto the internet and to do that we have to set up a security policy to allow that to happen.
Lab Objective:
Set up the windows machine on the 10.1.1.0/24 network to go from its zone ‘Internal’ to the ‘Internet’ zone and allow access to the following protocols:
DNS port 53 (UDP)
HTTP port 80 (TCP)
HTTPS (SSL) port 443 (TCP)
This will allow the Windows PC onto the web and able to browse. Simply allowing HTTP and HTTPS wouldn’t be enough as DNS is involved when using the web to translate the human readable URL address such as https://www.paloaltonetworks.com to an IP address that will be then used to send the traffic towards the website.
Log into the PA GUI and select the Policies Tab.
Here we have the two default policies ‘Intrazone-default’ and ‘Interzone-default’. The Intrazone policy allows traffic to flow from the same zones and the Interzone policy denies traffic to flow from different zones. If you scroll over to the far right of the policies you’ll see ‘Action’ set to Allow and Deny for each one.
We need to add our own policy here to allow traffic from the Internal zone to the Internet zone and to specify the protocols we want the user to be able to access. Click on ‘Add’ to get started.
The first tab is called General and here we give the policy some meaning by naming it and giving it a description of what it is used for. Also you select the Rule Type since I am going between different zones I have selected ‘interzone’ as the Rule Type.
Next click on the Source tab.
Under Source Zone click on Add and select the zone you want to match on i.e. sourced from and select Internal. Under Source Address on the right side of the window I have the option to allow Any traffic from the Internal zone OR I can match a specific subnet or IP address. I could have multiple subnets that are part of my internal zone so this allows me to get more granular and select which subnet should have access out onto the Internet. To make things easier down the line I can setup an Object just for that 10.1.1.0/24 subnet and reuse it elsewhere in the configuration for other policies I might setup later.
I’ve selected Add and I get this list of IP address ranges, I could simply type in the network address I want to use but I’ll set up an object instead. To do that you need to click on the New Address button at the bottom. A new window pops up shown below.
Enter in a name for the object here I am using ‘Internal 10.1.1.0 subnet’ and I have selected the IP Netmask as the type since I am configuring a subnet. Click on OK and the object will be added to the configuration.
I am going to skip the User Tab here as I don’t have any User-ID setup yet. The User tab can be used to identify a specific user on the network and to just lock it down to that particular user. So onto the Destination tab.
In the destination tab I am selecting the zone that I want to allow the traffic to flow to. In my case it is the Internet zone. On the right of the window it is set to Any which is fine as we are going out onto the internet and I don’t want to start restricting what parts of the internet the user can or can’t get to.
Next is the Application tab and here I am going to specify what applications or protocols that users are allowed to use from the Internet 10.1.1.0/24 subnet. As part of the lab brief we said we wanted the users to be able to browse the internet so that means allowing DNS, HTTPS (SSL) and HTTP.
Click on Add and add ssl for HTTPS traffic, DNS and web-browsing for HTTP.
The last step is to select Actions.
This is where you want to select what action to take against the policy we just created and since I want to allow the traffic that is what I’ve selected.
Click on Ok and the the policy will be created and added to the policy configuration. As shown here.
The policy is as follows:
IF source zone is Internal AND from the 10.1.1.0/24 subnet going to the destination zone Internet AND using applications SSL, HTTP, DNS ALLOW the traffic.
Now our users on the 10.1.1.0/24 network have access to the internet, you might be thinking how does the return traffic get back to the users since we haven’t configured a policy for traffic from the Internet zone to the Internal zone? The NGFW is a stateful firewall which means it remembers the sessions from the ‘Internal to Internet policy’ and allows the return traffic back in without having to setup another policy for that to be allowed.
Lastly don’t forget to commit the configuration for it to become active on the firewall.
In this post I want to talk about zones and what they are used for in a Palo Alto NGFW. Zones are used to group interfaces together that are part of the same business function on the NGFW. For example you might have two departments, one is Finance and the other is IT. Because the information within the Finance part of the network is highly sensitive you do not want your users from the IT department having access to that part of the network. With zones you can put them into separate zones and build policies around them. By default interfaces within the same zone can communicate with each other but interfaces in different zones cannot for that to happen you will need to configure a policy to allow users or a group of users to go from one zone to another such as IT to Finance and visa-versa. This is the first line of defense in stopping attackers moving laterally across your network.
Configuring Zones
I am going to setup 3 zones and assign interfaces to those zones. The 3 zones will be:
Internal
Servers
Internet
On the PA GUI click on the Network tab and on the left hand side select Zones. Click on Add.
Give your zone a name “Internal” and the type in this case is Layer 3. The other options are Layer 2, Tap, Vwire and tunnel.
Continue adding the remaining zones Internet and Servers.
Virtual Router
What is a virtual router? On the Palo Alto NGFW you can split the Firewall into virtual “mini” firewalls it can be used to keep different parts of the business separated or if you have different customers that you provide services to you can give them a virtual firewall with their own interfaces, zones, policies. You can add virtual routers or just use the default virtual router. To add a virtual router click on Network and on the left hand side click on Virtual Router and Add.
Here I have added a new Virtual Router and called it VR-1.
Interfaces and bringing it all together
The last thing to do is to assign the interfaces to the different zones and the virtual router.
Still under Network click on interfaces on the left hand side to get started. Select Layer 3 as the Interface type and add a comment. Under “assign interface to” select VR-1 as the Virtual Router and Internet as the Security Zone.
Click on IPv4 tab and enter the IP address here I am using 192.168.1.250/24 then click on Ok.
Once you have all the interfaces configured along with their IPv4 addresses you need to commit the configuration for it to become active. When the configuration is committed you will end up with the interfaces active as shown below.
What better way to get to know the Palo Alto Security Operating Platform than installing it on your laptop and using it. Here is the lab I have setup on my laptop. You can also do this in the cloud using AWS for example as the image I am using is the VM-Series from Palo Alto that is built for protecting your cloud infrastructure but for now I am going to be running it locally on my laptop. I’ll set it up in the cloud on AWS in another blog post.
Palo Alto VM-Series in VMWare Workstation Pro
To do this you’ll need the Palo Alto VM-Series image from Palo Alto, VMware Workstation Pro software to run the Palo Alto VM-Series image on and also a Window 10 image again used within VMware. I’m using the PA-VM-ESX-8.1.0.vmx image here.
Once you have the PA VM-Series image file downloaded you’ll need to install it into VMware Workstation Pro, you can use a 30 day evaluation of the Workstation Pro software but after that you’ll have to buy a license if you would like to continue using it. The same goes for the Windows 10 image you’ll need to add it into VMware Workstation.
I’ve also setup some extra VMnets so I can connect up the topology as shown above this can be done via Edit–>Virtual Network Editor. Click on Change Settings (Admin level is required here) and then click on Add Network. One thing I did was deselected the option to use local DHCP as I wanted to add my own IP addresses as such:
vmnet 1 : 10.1.1.0 255.255.255.0
vmnet 2: 10.2.2.0 255.255.255.0
vmnet 3: 10.3.3.0 255.255.255.0
vmnet 4: 10.4.4.0 255.255.255.0
Although I’m not using all of these from the start it is good to have them configured if I want to connect another network into my lab. Next thing to do is to power up the VM-Series NGFW once booted you’ll get prompted to enter in a username and password which is admin/admin by default.
Also during bootup you’ll see a DHCP message with the IP address that has been assigned to the management interface, in my case it was 192.168.1.101 to log into the GUI just open up a browser and type in the address in the address field as https://192.168.1.101 note you’ll get a warning about the site not being trusted as it is a self-signed certificate just click on Advanced and add it as an exception and it will load the GUI login page, again the username and password is the same here admin/admin.
I am officially certified as a Junior Penetration Tester with eLearnSecurity. I must say I found their training to be excellent. Up until now most of the certification exams I’ve done have been from Cisco. I had never heard of eLearnSecurity until I came across them on the techexams.net forums. I wanted to get into Penetration Testing for some time now as I had always been interested in how someone could break into a network or system. In the past, I have built my own PC and installed numerous OS systems directly on the hard drive or virtually using VMWare to test different things out and to see how they worked so Penetration Testing was a good fit for me I guess as I liked tinkering with things.
So what do you learn in the course? You can find the course at eLearnSecurity and a breakdown of each section and what modules they cover.
The first section is an introduction to networking, web applications and penetration testing. The second section is programming again this is an overview and doesn’t go too deep into it the programming languages covered are C++ and Python. The three section is all about penetration testing and the different phases of a penetration test. You also learn what tools to use here. And for me, the best part of the course is the access you get to the labs where you can learn how to use the tools, here you really get to know how to use them, nothing beats hands-on learning in my opinion.
In the exam, you get access to the exam lab for 3 days. You are given an exam guide and some information about the network you are going to be pen testing. You have 20 questions to answer based on the exam objectives. You need to gain access to servers, PCs, websites using all the tools and techniques you learned during your studies. Having access to the lab for 3 days is probably a bit too generous as it only took me 4-5hrs to gain access to the systems and find the answers to the questions. I must say I really enjoyed the exam as it was all hands on which is much better than 60-70 multiple choice questions like most of the Cisco exams I’ve done apart from the T-SHOOT exam for the CCNP R&S cert another exam I really enjoyed.
I would fully recommend eLearnSecurity as their course material is great and up to date with the latest tools and exploits. Next, I am going to tackle the PTPv5 course and exam to take my Pen Testing skills to the next level.
If you would like to practice using NMAP commands, the nmap organization has made available a test site at scanme.nmap.org. You can use this as your target when learning how to use nmap.
Here I’m running a scan against the website scanme.nmap.org and piping it to a file. The results of the scan are shown below.
Just don’t run continuous scans against the site, after all, it is a shared resource.
This is a continuation of my previous post, NMAP and fping deep dive in that post I talked about fping and NMAP and how they worked at a basic level as NMAP, in particular, has a lot more parameters that you can use depending on the task at hand.
In this post I want to cover more of NMAPs capabilities and what commands we could use to discover more about the network and what potential vulnerabilities these hosts might have that could be used to exploit them.
In the last post we found out what hosts were alive on the network and we also found out what ports were open on those hosts. The next step is to find out what OS they’re running or at least get the best guess as to what it might be.
I am going to use the -sV (version) option and also the -O (OS fingerprinting option) to get more detail on the hosts. You don’t want to blindly attack a network without gathering all the information possible about your target or you run the risk of causing the target to crash because you ran the wrong tool against it. Information gathering is one of the most important parts of penetration testing.
As Abraham Lincoln once said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
The first command to run is the -sV command that will give us more information on the ports that are open and what version the service is running.
The administrator might have changed the port to a non-standard port as is the case for the host at 10.142.111.213. You can see the port is 81 but the service using that port is HTTP which is usually on port 80 also if you remember this is the host that did not respond to the ping sweep when using fping.
To build on this we can now run the -O command with nmap. This command will send special probes to try and figure out what OS is running, for example, IIS, Apache?
The command is $:nmap -O 10.142.111.1,6,48,96,99,100,213
Here instead of using /24 I am only running the OS scan on the hosts we already know are alive on the network, this saves us a lot of time as I am only concentrating the scan on specific hosts.
From the output you can see that host at 10.142.111.48 is a Windows XP machine. From this, we could start to look for vulnerabilities on Windows XP for the services they’re running.
To summarise we started off not knowing what IP addresses were alive for this we used the fping tool and also nmap -sn command. We then ran more nmap commands to figure out what ports were open and also the versions of those open ports. Lastly, we ran the OS fingerprint command to try to figure out what OS the hosts were using.
NMAP and fping are used for scanning and OS footprinting of a network during the information gathering phase of a penetration test.
It is always good to know how to use these tools but also to understand what they’re doing and how they work at a deeper level. So with that in mind, I am going to run these tools and at the same time capture what is going on the wire using Wireshark.
First, let us see how fping works vs the same scan ran using nmap and why the results might be different.
I will run fping on the 10.142.111.0/24 network to see what hosts are alive. The command I will use is. #>fping -a -g 10.142.111.0/24 2>/dev/null
What are the additional parameters of -a and -g doing? The -a parameter is used to only report back hosts that are alive and the -g parameter is telling fping that it should carry out a ping sweep and not just a normal ping against one host. The 2>/dev/null parameter at the end of the command is sending err-out messages to the bit bucket so they’re not displayed while running the command.
After running the command we get the following 7 hosts responding to the ping sweep. Now I will run the same scan but this time using the nmap tool.
The nmap tool is a very powerful tool and it has a lot more capabilities compared to fping. To run the same scan that we did previously but now using nmap we run:
#>nmap -sn 10.142.111.0/24
The -sn parameter is requesting nmap to scan the subnet for hosts that are alive.
With the nmap scan we get back 8 hosts that are alive on the network vs the 7 reported by fping. That extra host is 10.142.111.213 but why? Let us take a closer look at what fping is doing vs nmap using the -sn parameter.
fping will first send out arp requests for each host on the subnet it is scanning. If a host replies to the arp request with its MAC address fping will then take that IP address and send an ICMP echo request message to it (ping).
Shown above are the arp request and the arp reply. Next the fping tool sends an ICMP echo request to 10.142.111.213. But if you look at the capture there is no response found! This host has probably been set up to not respond to ICMP messages.
If you compare this to one of the hosts that did reply the output would look like this with an echo request and an echo reply.
So the reason that fping does not show the 10.142.111.213 in its scan results is down to the fact that the host is configured not to respond to the ICMP ping request which is perfectly normal and is a good security practice.
On the other hand, nmap reported it to be alive this is because the nmap -sn scan only sends arp requests out and if a host replies to it with its MAC address nmap marks that host to be alive.
As mentioned earlier nmap is a powerful tool. Let us look at what other scans it can do. Now we know what hosts are alive on the network but that is all we know which lets face it isn’t that much. To see what services (daemons) are running on these hosts we can run another command using nmap.
The command is #>nmap -sS 10.142.111.0/24
The -sS parameter is telling nmap to perform a TCP SYN scan which is a stealthier scan because it does not complete a TCP 3-way handshake. When a client wants to communicate with a web server, for example, it first completes a TCP 3-way handshake and then it will start exchanging data. This is usually logged by the web server daemon that a new connection has been made which is bad news for us as it might alert a sysadmin that someone is scanning their network.
A TCP 3-way handshake looks like this.
When running the TCP SYN scan instead of completing the 3-way handshake nmap will send an RST message in reply to the servers SYN/ACK message as shown below. This stops the connection completing and also from the web server daemon logging the connection.
The result of the nmap TCP SYN scan is shown below. It goes through each IP address and sends a SYN message to each well-known port to see if the server will reply with a SYN/ACK message meaning that the port is open or a RST/ACK message meaning that the port is closed. For the IP of 10.142.11.1 ports 22, 53 and 80 are all open.
That is it for now. I’ll go through more of the capabilities of nmap such as OS fingerprinting in my next post.
You should NEVERrun any of the tools that are shown on my blog or on any of the IP addresses I’ve used for illustrative purposes without proper authorisation to do so.
So you want to see what hosts are alive on a network that you have been asked to Pen Test. After you’ve done some reconnaissance you have an IP range of 100.10.0.0/16 that is used by the network in question. There are a couple of tools that will do the job for us here, they are fping and nmap. The focus of this blog post will be the fping tool a separate blog post will show the nmap tool.
fping is a ping sweep tool. If we were to try and test each of the IP addresses in the 100.10.0.0/16 range using traditional ping it would take a very long time.
fping is installed by default on Kali Linux if you are running a different flavour of Linux you can run the apt-get command to install it.
#sudo apt-get install fping
To use fping it is straightforward. I will use my own local Wifi address range to test what addresses are alive in the 192.168.88.0/24 range.
#fping -a -g 192.168.88.0/24
the -a option is used to only show addresses that are alive.
the -g option tells the tool that it is a ping sweep that needs to be carried out instead of a traditional ping test.
As you can see there are many IP addresses in use from that range. This is very useful information as we now know what IP addresses have been assigned to a device in the network they might be servers or hosts more on how to find that out in the next blog post using the nmap tool.
Note when using the fping tool on a LAN or WLAN you are connected to you will get [ICMP Host Unreachable] messages for IP addresses that aren’t in use. If you do not want to see these displayed in the output you can send the standard out errors to /dev/null using the following command.
#fping -a -g 192.168.88.0/24 2>/dev/null
In my next blog post, I will show you a very very powerful tool called nmap that does the same as fping and a lot lot more.
