How to Use Firewalk on Kali

Today, we’re going to be running through a Firewalk tutorial using Kali Linux. But first, we need to understand what Firewalk does and why it’s important for hackers and penetration testers. Basically, Firewalk is a penetration tool that can be used for reconnaissance by helping a pentration tester or hacker discover what IP protocols are permitted through a network device. The network device in question could be almost anything, including (but certainly not limited to) a home wireless router, an enterprise-class router, or just about anything with a hardware or software firewall.

Naturally, I’m sure you see the value in being able to poke and prod firewalls with a reconnaissance tool to see what can get through. It works by sending TCP and UDP packets using the specified protocol and port number, but it has a TTL (Time To Live) value one hop further than the device in question. For instance, if I was testing a firewall that was 3 hops away, the TTL of the packets would be set to 4.

As a side note, understand that TTL is the number of hops a packet can be forwarded by computers and networking devices before they are discarded. Each time a packet travels through a device, such as a router, the TTL value is decremented by 1. The TTL mechanism helps prevent looping flaws in the TCP/IP model and a whole range of attacks. Many of these flaws (which are similar to broadcast storms) are outside the scope of this guide, but know that there are some strange looping errors that essentially allow immortal packets to multiply and completely break an entire network. The TTL value thwarts these issues. While the maximum TTL value is 255, most operating systems use a value much smaller than that (usually in the 32-64 hop range).

Anyway, the goal is to receive an ICMP message. As you may know, ICMP (Internet Control Messaging Protocol) facilitates pings with the echo-request and echo-reply operations. However, today we’re more interested in the ICMP_TIME_EXCEEDED message. You see, we will only receive this message if the device we’re testing (such as a firewall) permits the traffic, and then the packets exceed their TTL value on the other side of the firewall and die. On the other hand, we’ll know if a firewall blocked the traffic type we’re testing if we don’t receive any message at all.

Identifying Network Devices

At this point, you might be wondering how on Earth we’re supposed to know if a router or firewall is in our path to the Internet. First of all, one of them has to be in your path if your accessing the public Internet from a private network. Regardless, you may want to test various networking devices on your local network. Consider a hacker or penetration tester who has access to a corporate network.

The first stage of testing would likely involve putting out ‘feelers’ to sense other devices on the network. For instance, it’s likely that a hacker or penetration tester would use various types of scanners to identify other active hosts. Perhaps they would then use NMAP to locate other devices and see what type of device they are. There is one major difference between using NMAP as a portscanner and Firewalk, however.

The distinction is extremely important, so take notes. When using a portscanner like NMAP, you are testing to see which services are running on an individual host or subnet. For instance, I can see if host 192.168.1.254 is accepting connections on ports 20 and 21, which would indicate an FTP service is running.

However, when using Firewalk, you’re really testing to see what traffic can pass through a device; not what ports are actually open on the device in question. As such, it is a much more useful tool than NMAP for testing firewalls.

Also, in some cases, it may not be necessary to use NMAP to identify devices. Furthermore, note that the final destination doesn’t even need to be reached, since the ultimate goal of this tool is simply to see if an individual protocol will be forwarded by a networking device. If you wanted to, you could simply run a traceroute to see a list of all the layer 3 forwarding devices between you and the ultimate destination.

What Are Layer 4 Protocols, and Why Do They Matter to Penetration Testers?

I would hope that, as I.T. and network engineers who want to become hackers and penetrations testers, that you already have a firm grasp on the OSI model. If you don’t, go ahead and take the time to research it a bit, since we can’t get into it today as it is far outside the scope of this guide an immensely complex.

Nevertheless, I would like to draw your attention to layer 4 of the OSI model. I mentioned already that Firewalk tests to see which layer 4 protocols can pass through a networking device, such as a firewall. So…what about all the higher level protocols? Remember that layer 4 of the OSI model is the Transport layer, and includes popular transport protocols such as TCP, UDP, IPX/SPX, Fiber Channel, RTP, and SCTP.

Naturally, TCP and UDP are the most popular and widely used layer 4 protocols. Nevertheless, I would like to point out that Firewalk does have tools and mechanisms to set different flags within the IP header, so you can test higher level protocols. That is, it won’t only check whether a layer 4 protocol (such as TCP) is forwarded, but rather how TCP is forwarded and what different types of TCP data are permitted.

So, naturally, you can test individual ports or entire ranges of ports. This allows you to poke the firewall and see what common services are blocked and which are permitted, such as HTTP, HTTPS, FTP, TFTP, DNS, SSH, TelNET, and any other service you can think of.

Firewalk Syntax and Options

Firewalk has a fairly basic command structure as follows:

firewalk [options] firewall_or_device_address metric

Furthermore, the options you can append to the command are as follows:

-d 1-65535 (34434) – This value indicates the initial destination port during the ramping phase, when Firewalk is trying to determine what value to set for the TTL.

-h – View the help screen.

-i interface_name – Specifies which interface to run Firewalk on. However, if you only have one active interface, you don’t need to supply this information.

-n – Tells Firewalk to not resolve hostnames to IP addresses using DNS. Doing so can drastically speed up a scan by circumventing length DNS timeouts.

-P 1-2000 (0) – Builds a ‘pause’ into the scanning phase, which is good because it prevents the scan from flooding the network and drawing too much attention to yourself – which is critical for hackers to maintain a low profile.

-p TCP, UDP (UDP) – Specifies which protocol you would like to test.

-r – RFC 793 support. This flag is actually quite complicated, and a lot happens in the background during the scan, so we will disregard this option for today. You are, of course, encouraged to research it further, but just know that it deals with the inner working of SYNs/ACKs.

-S 1-65535 – This option helps you to specify multiple ports in a single scan so you don’t have to run tens, or even hundreds of scans to test all the necessary ports. You can enter in lists or ranges of ports. Ranges are separated by dashes while lists of ports are delimited by commas.

-s 1-65535 (53) – This value specifies the source port for the scan.

-T 1-2000 (2) – This sets the timeout value for the packet read. Setting this to a lower value can speed up the scanning procedure, because it determines how long Firewalk waits before timing out.

-t 1-25 (1) – This value indicates the initial TTL. You can set a TTL value instead of needing to run through the ramping phase if you already know how many hops away your target is.

-v – Dumps program version and exit.

-x expire vector (1) – The expire vector is the number of hops that the scanning probes will expire, past the gateway host. The binding hop count is the hop count of the gateway + the expire vector.

Usage Tutorial

So now we understand what Firewalk is, what it does, and how it works. It’s finally time to look at a n example of the syntax to see how we can poke and prod a firewall to see what traffic is permitted and which traffic is blocked. Consider the following example:

firewalk -S1-53 -i eth0 -n -pTCP 10.10.1.1 10.10.0.1

I know that when we put it all together, it can look a little intimidating. So, let’s run through exactly what this command does one option at a time. First of all, note that this operation is going to scan to see if ports 1-53 are permitted through the host’s interface with the address 10.10.1.1. In our example, 10.10.1.1 is the device that is being scanned, such as a firewall.

Also, note that the command specifies TCP traffic. And lastly, we want to check if the host 10.10.0.1 has the ability to send the traffic (on ports 1-53) through the firewall. If you want to check what common ports are available in a new environment, you would simply specifiy your port range (perhaps 1-1024, since these are well-known ports), and set the last IP address to one within your subnet.

Final Thoughts

Firewalk is a tremendously useful information gathering tool that will take a lot of the guesswork out of wondering whether or not your traffic is hitting the correct target or server. For instance, if you wanted to use Dotdotpwn to fuzz an HTTP server but kept receiving errors or timeouts, it could be because a firewall or router is blocking your traffic. You could simply use Firewalk to verify whether or not that data is permitted through the networking device.

Lastly, from a penetration testing perspective, this tool is incredibly useful for validation and verification. For instance, corporations frequently impose firewall policies regarding what traffic types shouldn’t be allowed through. This tool will help double check that the firewall rules are configured appropriately.

SSH for Penetration Testing

SSH stands for Secure shell and works on Port 22 . As penetration testers we are aware of the uses and power of SSH on remote access of systems . During Penetration testing SSH might come handy as a powerful tool .

This post will explain some of the techniques that can be used during a penetration test .

Local Forwarding using SSH

Sometimes we come across scenarios where we need the services on the remote host accessible to the host via Local Network . Root is required .

ssh -L 127.0.0.1:10521:127.0.0.1:1521 user@192.168.1.10

~/.ssh/config:

LocalForward 127.0.0.1:10521 127.0.0.1:1521

Remote Forwarding using SSH

Well this technique is complete opposite of the previous one . Remote forwarding on using SSH comes to rescue in those penetration testing scenarios where we need the services on a local machine / Local Network accessible to remote host via a remote listener . This might sound odd … why would I want my machine accessible on a remote host , but lets face it , we all need to expose a service that lets us download our penetration testing tools.

For the practical information here is an example :

The SSH server will be able to access TCP port 80 on SSH client by connecting to 127.0.0.1:8000 on the SSH Server .

ssh -R 127.0.0.1:8000:127.0.0.1:80 192.168.1.10

~/.ssh/config:

RemoteForward 127.0.0.1:8000 127.0.0.1:80

SOCKS Proxy using SSH

Here we set up a SOCKS Proxy on 127.0.0.1:8000 that lets you pivot through the Remote Host 192.168.1.10

 ssh -D 127.0.0.1:8000 192.168.1.10

~/.ssh/config:

Host 192.168.1.10
DynamicForward 127.0.0.1:8000

X11 Forwarding using SSH

If your SSH client is also an X-Server then you can launch X-clients (e.g. Firefox) inside your SSH session and display them on your X-Server. This works well with from Linux X-Servers and from cygwin‘s X-server on Windows.

SSH -X 10.0.0.1
SSH -Y 10.0.0.1 # less secure alternative - but faster

~/.ssh/config:

ForwardX11 yes
ForwardX11Trusted yes # less secure alternative - but faster

SSH Authorized Keys :

SSH stands for Secure Shell … well to be secure , its always advisable to use Keys for encrypting the SSH communication . This helps to avoid unwanted hosts to take advantage of the penetration test and keep the penetration testing secure .

That being said , it is a good practice to add an authorized_keys file that will allow you to log in using an SSH key .

Authorized_keys File : This file is present in the User’s Home Directory on the SSH server . This file basically holds the public keys of the users allowed to login into that user account of SSH Server .

For this the first step is to Generate PUBLIC KEY / PRIVATE KEY pairs .

sh-keygen -f mysshkey
cat mykey.pub # to copy this to authorized_keys

To connect to the Remote host using the authorized key :

ssh -i mykey user@10.0.0.1

Some Cool SSH Configuration Tweeks

Finally here are some cool modifications you can do to your SSH Client system , this will make it easier to use other penetration testing tools that are using SSH .

Host 10.0.0.1
Port 2222
User ptm
ForwardX11 yes
DynamicForward 127.0.0.1:1080
RemoteForward 80 127.0.0.1:8000
LocalForward 1521 10.0.0.99:1521

#Please Share and Comment if you like this Post .

NMAP Scanning Tutorial : Firewall and IDS Evasion

NMAP Scanning Tutorial : Bypassing the Firewalls and IDS/IPS

This post is for penetration testers that face issues with scanning the Corporate networks with firewalls deployed and are unable to bypass the Firewall or an IDS/IPS .

Firewall is generally a software or hardware to protect private network from public network.This is a trouble maker for the Penetration testers as they are not able to bypass this added layer of security .

Well the good news here is that we can use Nmap options to bypass the firewalls , IDS/IPS .

If a penetration tester can bypass firewall then half game is won for the penetration tester. In this tutorial you will learn how to bypass and test firewall using the NMAP options.

NMAP options to Bypass the Firewall :

• -f (fragment packets):

This option is to make it harder to detect the packets. By specifying this option once, Nmap will split the packet into 8 bytes or less after the IP header. This makes the detection of Nmap sent packets difficult .

• –mtu:

With this option, you can specify your own packet size fragmentation. The Maximum Transmission Unit (MTU) must be a multiple of eight or Nmap will give an error and exit. This helps in Firewall Evasion .

• -D (decoy):

By using this option, Nmap will send some of the probes from the spoofed IP addresses specified by the user. The idea is to mask the true IP address of the user in the logfiles. The user IP address is still in the logs. You can use RND to generate a random IP address or RND:number to generate the <number> IP address. The hosts you use for decoys should be up, or you will flood the target. Also remember that by using many decoys you can cause network congestion, so you may want to avoid that especially if you are scanning your client network.

• –source-port <portnumber> or –g (spoof source port):

This option will be useful if the firewall is set up to allow all incoming traffic that comes from a specific port.

• –data-length:

This option is used to change the default data length sent by Nmap in order to avoid being detected as Nmap scans.

• –max-parallelism:

This option is usually set to one in order to instruct Nmap to send no more than one probe at a time to the target host.

• –scan-delay <time>:

This option can be used to evade IDS/IPS that uses a threshold to detect port scanning activity. Setting the Scan delay is always a good idea when you want to evade any security device .

Sources : Nmap.org

http://nmap.org/book/man-bypass-firewalls-ids.html

Penetration Testing in Secure Environments

Penetration testing involves identification of the services running on a host and find and exploit vulnerabilities in theses services sometimes referred to as daemons .

Vulnerabilities is just a weakness in the computer systems that the attacker can take the advantage of . The Act of identifying the specific vulnerabilities in a computer system / Computer network is called Vulnerability Assessment . But in corporate environments that are secured with the Firewalls / IDS / IPS and other devices that prevent the penetration testers for further assessing the vulnerabilities .

In this post we will see how to perform penetration testing in a environment that has been secured by a firewall .

The First Step here is going to be to check the IP level connectivity between the attacker and the Target .

ping <target-ip>

If you get a ping response that means the target system is alive and we can further proceed to identifying what ports are open on the Target . But before that we must know what network devices our packet passes through before it reaches the Target system.

For this the Traceroute Utility comes handy ,

traceroute <target-ip>

In case of a firewall deployed , you are likely to see more “ * ” than IP addresses which is an indication that a firewall has been deployed on the network . You might not find any results for a traceroute in a scenario where the firewall is deployed .

To our rescue comes the Nmap Firewalk Script .

NMAP supports scripts that are run by NSE : Nmap Scripting Engine .

To bypass the firewall use the NMAP FIREWALK Script .

Here we use the firewalk script for Nmap in conjunction with traceroute .

nmap --script=firewalk --traceroute <target-ip>

Once this is done , we are aware what is the network architecture , we can proceed to perform an advanced port scan on the network . To do this we use : HPING 3 .

Hping 3 is a command line packet analyser / assembler used for Firewall Testing , Advanced Port Scanning , Manual Path MTU Dicovery and lots of other interesting things .

root@kali:~# hping3 -h
usage: hping3 host [options]
  -h  --help      show this help
  -v  --version   show version
  -c  --count     packet count
  -i  --interval  wait (uX for X microseconds, for example -i u1000)
      --fast      alias for -i u10000 (10 packets for second)
      --faster    alias for -i u1000 (100 packets for second)
      --flood      sent packets as fast as possible. Don't show replies.
  -n  --numeric   numeric output
  -q  --quiet     quiet
  -I  --interface interface name (otherwise default routing interface)
  -V  --verbose   verbose mode
  -D  --debug     debugging info
  -z  --bind      bind ctrl+z to ttl           (default to dst port)
  -Z  --unbind    unbind ctrl+z
      --beep      beep for every matching packet received


hping3 -S <target-ip> -c 100 -p ++1