Saturday, May 17, 2014

M0n0Wall Firewall Penetration Testing

The type and scope of the penetration test will determine the need for being stealthy during a penetration test. The reasons to avoid detection while testing are:·One of the benefits would include testing the equipment that is supposedly protecting the network. Another could be that your client would like to know just how long it would take the Information Technology team to respond to a targeted attack on the environment. You will also need to understand the automated methods of detection such as web applications, network, and host-based intrusion detection systems that are in place to avoid triggering alerts.



Note: - When pentested with the target, take the time to validate that it is not some sort of honeypot that has been set up to trigger alerts when abnormal traffic or activity is detected! No sense in walking into a trap set by a clever administrator.



Lab preparation:
This is critical to being able to learn and practice the latest and greatest techniques as the excellent minds in the security research field continue to surprise us with new vulnerabilities and possible attack vectors. This article cannot cover every possible method of testing a network, but building the labs is an attempt at adding long lasting value that will hopefully lead to a lifetime of the "hacker mentality". 

If you continue to build out your personal lab and increase the difficulty of the practice challenges that you set for yourself you will quickly become comfortable with testing any sort of environment.

Kali Linux, m0n0wall firewall, and Metasploitable virtual machines should be configured in the following manner:


We use virtualbox for our lab preparation.



Kali Linux guest machine configuration:
This machine will need to be connected to the 192.168.20.0/24 subnet. In the Oracle VM VirtualBox Manager console highlight the Kali Linux and select the Settings option from the top navigation bar. Ensure that only one network adapter is enabled. The adapter should use the Vlan2 internal network option. 



Metasploitable guest machine configuration:
The Metasploitable machine will be used as the target. It needs to be configured to connect to VLAN1, which is an internal network. To create an internal network you will need to manually select VLAN1 into the network configuration screen in the Oracle VM VirtualBox Manager. Your settings should be similar to the following:


M0n0wall guest machine configuration:
Configuring our firewall is a little bit complicated. It needs to be able to route restrictive traffic from the VLAN1 network to the VLAN2 subnet. There are several configuration changes we will need to make to ensure this works properly.



Our firewall guest machine will use three network adapters. One will be used for the NET, VLAN1 segment and the other for the VLAN2 segment. NET will be treated as an untrusted wide area network.


  • In VirtualBox use the following settings to set up a new guest machine:

    • Name: M0n0wall_Base_Install
    • OS Type: BSD/FreeBSD 
    • Memory: 128 MB  
    • Virtual Hard Disk: Start-up Disk checked, Create New Hard Disk selected 
    • Create New Virtual Disk: VDI 
    • Virtual Disk Storage Details: Dynamically Allocated 
    • Virtual disk file location and size: (Locate in a folder to be used for future labs), 200 MB in size

Network Adapter should be similar to the following:
·    Network Adapter 1 should be configured to use NAT which will be our WAN connection.
·    Network Adapter 2 needs to be configured for the Internal Network name VLAN1 which will represent our LAN connection and.
·    Network Adapter 3 should be set up at Internal Network name VLAN2 and will be tied to our internal network (the OPT device).
Now start m0n0wall guest machine. M0n0Wall will need to be installed on the new VirtualBox Machine.

·         Choose the 7) Install on Hard Drive option


When asked which hard drive to install on, choose your hard drive (in this case it is ad0).


·     Reboot when prompted and ensure that the system is booting from the hard disk install rather than the ISO (remove ISO file from cd/dvd device).



Now that M0n0Wall has been installed we must configure the interfaces:
·   Choose 1) Interfaces: assign network ports and press Enter.
·   When prompted with a listing of available interfaces continue by setting up your VLANs. Press y to continue.
Continue through the creation process for each adapter. In this case our lnc0 adapter is assigned to VLAN 1, lnc1 and lnc2 to VLAN 3.These VLANs can be any unused number between 1 and 4094. 




When determining the LAN interface name choose the adapter that is assigned to VLAN1, the WAN adapter should be assigned to the NAT adapter, and the VLAN2 adapter should be assigned as the OPT device.


·     Reboot the firewall to save your changes.



The firewall has been installed on our hard drive and the adapters have been assigned to VLANs. Now we need to set up the LAN IP address and connect to the web interface for further configuration.
·   - Select option 2) Set up LAN IP address and press Enter to continue.

- When prompted type the IP address you would like your LAN to use. We will   choose 192.168.10.1

- Next is applying LAN subnet, in this case we set to 24.

- Next is asking for DHCP server on LAN. Type y for enable, now apply start ip address and end ip address range as shown bellow.



Now boot Kali Linux and set manually ip address. As the m0n0wall machine will need to be our router as well, we need to set it up as the default gateway as shown bellow.


 
We can now boot up another Kali Linux on the VLAN1 internal network and connect to the web interface of the firewall by first setup a new IP address on the appropriate range and then directing our web browser to http://192.168.10.1. Default username, password is admin and mono respectively.


We need to set up our other interfaces to perform the tasks we have in mind which is to provide the 192.168.10.0/24 subnet with a firewalled route to our vulnerable host which will be located at 192.168.10.2 (connect a Metasploitable machine to VLAN2).

Select the OPT1 interface from the navigation menu on the left of the screen and enable it by checking the appropriate box. Leave the Bridge with option as none and type the IP address for this interface: 192.168.10.1. Ensure that the drop down lists 24. Click on the Save button after applicable changes have been made as shown bellow. 



We can enable the DHCP server on the OPT1 interface. Choose DHCP server on the left navigation menu and chose the OPT1 tab under Services: DHCP server. Check the box that enables the DHCP service on this port and enter the Range as 192.168.10.2 to 192.168.10.254. After your changes have been selected click on the Save button to continue.



Choose Firewall | Rule on the left navigation menu. By default the WAN interface should be blocked from connecting internally as there are not pre established rules that allow any traffic through. We go to edit menu (e).


And uncheck Block private networks. Apply the Changes and return to Firewall | Rules.


For testing purpose, we will go to OPT1 tab and enable ports 80, 443, 21, 22, and allow ICMP. Add the rules as follows:
       Click the Firewall Rules option in the left-hand navigation bar and select the OPT1 tab. Selecting the icon that looks like a plus (+) symbol within a circle will bring you to the screen that allows new rules to be configured. Click on this icon to continue.
 -> Use the following rule settings to enable ICMP pass-through:
  •             Action: Pass
  •             Interface: OPT1
  •             Protocol: ICMP
  •             All others: Default
-> Click on the Save button at the bottom of the screen.
-> Click on the Apply Changes button at the top of the screen.



·         Use the following rule settings to enable HTTP pass-through.

o   Action: Pass

o   Interface: OPT1

o   Protocol: TCP

o   Destination port range: HTTP
Continue adding ports until the configuration matches the following:


At this point any machine connected to VLAN1 can communicate through the open ports as well as ping machines on the VLAN2 segment as can be seen in the following screenshot 



Stealth scanning through the firewall:
Firewalls are a great security mechanism when used in conjunction with other security controls; however, they must be properly maintained and monitored to be truly effective. There are several mechanisms that can be used to attempt to bypass these devices.
It is important to know where you are being blocked when scanning. When testing through a firewall it may become difficult to prepare a stealthy attack if you do not have all of the information. Remember that tools such as Firewalker or Hping can assist with determining where the block occurs and if the port is truly available or jus
t closed.

T
raceroute to find out if there is a firewall:
Sometimes we can use traceroute to see the path to the target system. Let's take a look aatt open raceroute from VLAN1 to VLAN2.


Looking at this result we can see that the first hop goes through our gateway at 192.168.20.1 before being routed to the host. 

Finding out if the firewall is blocking certain ports using Hping
Hping2 and Hping3 are included as part of the Kali Linux distribution. It can be accessed via the GUI navigation bar Applications | Kali Linux | Information Gathering | Live Host Identification | Hping3. It can also be invoked at the command line by simply typing: hping3. 


Hping3 is a powerful tool that can be used for various security testing tasks. The following syntax can be used to find open ports while remaining fully in control of your scan. 


This command allowed us to perform a SYN scan starting at port 1 and incrementing for 80 steps.

Depending on the firewall configuration it may also be possible to send spoofed packets. During a test it is beneficial to ensure that the configuration does not allow for this behavior to occur. Hping is perfectly suited for this task. The following is an example of how you may test if the firewall allows this traffic to pass:

Hping3 –c 10 -S –spoof 192.168.10.2 -p 80 10.10.10.2


This command will spoof 10 packets from 192.168.10.2 to port 80 on 10.10.10.2. This is the basis for an idle scan and if successful would allow you to hping the 192.168.10.2 machine to look for an increase in the IP sequence number.


In this case we could enable monitoring on them0n0wall machine to emulate what this traffic looks like to a network administrator reviewing the logs. Challenge yourself to create and monitor different packets and uses of Hping so that you can gain a good understanding of the traffic flow. The best means of remaining undetected while testing is to fully understand the technology that is being used.

Take a look at the logs generated from a scan and keep in mind that due to the amount of traffic involved even secured networks will sometimes only log and trigger events based on denied traffic.

 

Nmap
firewalk script:
One of the easiest methods to test open ports on a firewall is to simply use the firewalking script for Nmap. To test the open firewall ports you will need a host behind the firewall as the target. We invoke nmap, use the script option, and choose the firewalk script. We then provide the input that firewalk needs by performing a traceroute to 192.168.10.2 which we know is behind our target firewall.



We were able to determine which ports on the firewall were open (21, 22, 80, and 443). It may be easier to manually verify if there are any common ports open on the firewall and then try to scan using one of the well-known ports.

These tools use TTL to determine if a port is open or not and as our gateway is on the same machine as our firewall and router the results are varied and obscured.


Idle scans remain the best method of determining what is behind a properly locked down firewall.

Avoiding IDS:
In a secured environment you can count on running into IDS and IPS. The IDS will need to be properly updated, monitored, and used in the proper locations. A penetration tester will be expected to verify that the IDS's are working properly in conjunction with all other security controls to properly protect the environment.
            The primary method of bypassing any IDS is to avoid signatures that are created to look for specific patterns. These signatures must be fine-tuned to find only positively malicious behavior and should not be so restrictive that alerts are triggered for normal traffic patterns.
            Over the years, the maturity level of these signatures has increased significantly, but a penetration tester or knowledgeable attacker will be able to use various means to bypass even the most carefully crafted signatures. In this section, we review some of the methods that have been used by attackers in the wild.



Canonicalization:
Canonicalization refers to the act of substituting various inputs for the canonical name of a file or path. This practice can be as simple as substituting hexadecimal representations ASCII text values. Here is an example of an equivalent string:
·         String A in Hex: "54:68:69:73:20:69:73:20:61:20:73:74:72:69:6e:67"
·         String A in text: "This is a string"
·       String A in ASCII: "084 104 105 115 032 105 115 032 097 032 115 116 114 105 110 103"


By taking advantage of the fact there are sometimes literally thousands of combinations possible for a single URL. To put this into perspective, let's take a look at the address we can use to get from our browser to our local Apache server:

http://2130706433/

Luckily, this address confuses our Apache server. And give following message:



The previous request attempted to load the local page at 127.0.0.1.

Let's see what occurs when we try to load the remote m0n0wall administration console in the same manner:

http:// 3232238082/

Here we are warned by the web server hosting the m0n0wall administrative console that a potential DNS Rebind attack occurred:


In the console, pings one of the addresses we listed above: 


As we can see, the IP address resolved properly and we receive our replies as expected. This very same concept is key when trying to bypass an IDS rule. If the type of IDS can be determined, then it should be possible to get the signatures. When reviewing these signatures you would look for opportunities to obscure the URLs, filenames, or other path information enough that it is able to bypass the existing ruleset.

4 comments:

Anonymous said...

Mastering Kali Linux for Advanced Penetration Testing - chapter 8

Anonymous said...

Mastering Kali Linux for Advanced Penetration Testing - chapter 8

Frogy said...

@Anonymous Thank you for providing source since it was a guest post, I was not aware if any instance of this article has been taken exactly in the same manner from any book.

I appreciate your efforts. Thanks once again. Have a good day.

Anonymous said...

Damn I 've made a mistake it was: Advanced Penetration Testing For Highly-Secured Environments - chapter 8.