Tag: cybersecurity

NAT – Network Address Translation

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:

41381

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.

Step1_NAT

A new window will pop up asking for General information, give it a meaningful name and description then click the Original Packet tab.

Step2_NAT

Under Original Packet I’ve added the following:

Step3_NAT

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.

Step4_NAT

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.

windows10

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.

NAT_Working

Any questions leave a comment.

Security Policy Lab

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.

step1_policy

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.

Step2_source

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.

Step3_Object

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.

Step4_object

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.

step5_destination

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.

step6_apps

Click on Add and add ssl for HTTPS traffic, DNS and web-browsing for HTTP.

The last step is to select Actions.

step7_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.

Step8_finish

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.

Getting into the Zone

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.

 

 

NMAP and fping deep dive

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.

fping

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.

nmapscan

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).

arpcapture

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.

icmpnoresponse

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.

normalreply

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.

TCP3WAY

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.

TCPRST

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.

nmap_sS_scan

That is it for now. I’ll go through more of the capabilities of nmap such as OS fingerprinting in my next post.