لطفا منتظر باشید ...
Chapter 12: Tying Everything Together—Firewalk
Chapter 9. This tool enables the user to determine TCP and UDP access control lists on arbitrary Internet gateways. As we will see, you build Firewalk by using several of the techniques and components that we profile in this book. The first version of Firewalk, released in Fall 1998, had few changes up until now. Since its release, Firewalk has encountered widespread use by security teams worldwide and was the subject of articles by renowned security organizations such as The System Administration and the Networking and Security (SANS) Institute, as well as being profiled in books such as Hacking Exposed (Third Edition, Osborne McGraw-Hill, 2001). According to a June 2000 poll, Firewalk is considered one of the top 50 security tools in use today.This chapter covers Firewalk in detail, from development to deployment, including a detailed code walkthrough with high-level flowcharts. While we briefly mentioned and showed Firewalk in the beginning of this book, the version of Firewalk profiled here is new and completely overhauled for presentation in this chapter. This chapter expects the reader to be familiar with the IP expiry technique and fire walking method discussed in Chapter 9.
The Genesis of a Network Security Tool
As we mentioned in the beginning of this book, Firewalk developed purely out of necessity. It was designed to bridge the gap that existed between what was conventionally possible by using the traceroute tool and what we, as security consultants, needed to accomplish. What follows is the basic development process for Firewalk 5.0 as it pertains to the modular model of network security tools and how it fits into the software development lifecycle.
Requirements
The development process began as many do: on the whiteboard. We started by brainstorming the requirements that we felt were needed for the as-yet-undeveloped tool. On a macroscopic scale, the tool would be somewhat comparable to traceroute but with much added functionality. With that in mind, we set ourselves to defining more stringent requirements:
Protocol ACL scanning. The main rationale behind the development of the tool was to create a facility that would enable a security analyst to determine which protocols a filtering target gateway would permit to pass. As it turns out, this function is basically an amalgamation of the port scanning and IP expiry techniques seen in Chapter 9.
Port scanning on metric. A value-added feature would be for the tool to perform some level of port scanning on the hosts behind the target gateway.
Small and simple. At the end of the day, the tool should not be too complex to use or understand. It should have a simple command line and a shallow learning curve.
Portability. The tool should be portable to all popular platforms that security consultants use. This feature is made possible through the use of the modular model.
Reliable performance on unstable networks. The tool needed to produce consistent, or at least predictable, results in the event of network issues such as malfunctioning routers, which might exhibit closed-loop failure styles, busy routers, asymmetrical routes, and so on.
Verbose reporting. The tool should have multiple reporting formats-one optimized for human analysis and another for easy integration into automation scripts. The obvious choice at this point would probably be something XML-based.
Analysis and Design
After defining initial requirements, it was time to refine and prioritize them based on development timeframes, scope, and the expected environment of the tool:
Protocol ACL scanning. Definitely, this top priority was the main reason for developing the tool in the first place. Firewalk would not be Firewalk without this core capability.
Reliable performance on unstable networks. Reliability and robust behavior was also a primary concern because the tool was going to be deployed across the Internet. A tool that does not perform consistently or handle fringe cases has a limited utility.
Portability. It is also important for the tool to compile on different platforms. Security consultants are notoriously religious about their chosen platforms, and the tool should be built with this in mind.
Port scanning on metric. We decided that this function was a great value-added feature, but due to persnickety protocol issues, metric port scanning is not always possible (see the following section for more information).
Verbose reporting. Upon re-examination, multiple reporting formats were picked as an ancillary requirement that would be built in "perhaps at some point."
Small and simple. First and foremost, the tool needs to be functional and robust. Building a simple tool that is predominantly user-friendly is secondary to functionality.After the requirements were listed, analyzed, and prioritized, the modular model of network security tools as introduced in Chapter 1 was applied. From the requirements, the list of techniques formed.
Firewalk and the Modular Model
A breakdown of Firewalk's architecture using the modular model is shown in Figure 12.1.
Figure 12.1: Firewalk
Technique Layer
We see that Firewalk is built by using the packet-sniffing, port-scanning, and IP expiry techniques. Packet sniffing is required to read in and filter all of the responses from the network. Port scanning is needed to not only scan the target gateway but also potentially scan the metric. IP expiry is used for both the ramping phase to determine the binding host and also to perform the scanning.
Component Layer
We also note that these techniques require the libpcap, libnet, and libdnet components. The libpcap and libnet components are directly related to the packet-sniffing, port-scanning, and IP expiry techniques while the libdnet role is a bit less obvious. The libdnet component provides the vital capability to enable Firewalk to build and send packets at the MAC layer by providing portable ARP cache and route table functionality. This feature is important because it enables us to maintain our No. 3 priority of portability (to understand why, see the section in Chapter 3 on Libnet Wire Injection Methods).
Control Layer
Finally, the control layer contains all of the mundane control logic, house keeping, reporting, and analysis details.
Classification
While the packet-sniffing technique binds the tool to the passive reconnaissance class, the port-scanning and IP expiry techniques bind the tool to the active reconnaissance class (which, as we have seen in earlier chapters, takes precedence).
