Introduction - Building.Open.Source.Network.Security.Tools.Components.And.Techniques [Electronic resources] نسخه متنی

Introduction

Open-source network security tools come in all shapes and sizes. At one end of the spectrum, you have small and tight programs such as Julian Assange's venerable but still useful Strobe TCP port scanner, and at the other end you have large and complex applications such as Renaud Deraison's full-featured Nessus security scanner. Maybe you have come across something like Marty Roesch's production-quality Snort Network Intrusion Detection System or possibly found a never-quite-got-off-the-ground tool like the author's TracerX enhanced Traceroute program. Some tools have intuitive and easy-to-navigate graphical interfaces, such as Gerald Combs' slick Ethereal network protocol analyzer, while others such as Fyodor's ubiquitous Nmap network scanner have a cryptic set of command-line argument mnemonics (granted, there is also a graphical front-end available). There are tools that are so well written and that fit such a perfect niche that you find yourself wondering why someone did not come up with them years ago. Perfect examples are Dug Song's Dsniff network traffic manipulation suite and his nifty Fragroute IP fragmentation attack tool. But what if you needed a tool that did not exist? Eventually, all tools available to you will prove to be lacking in some area, whether it is additional functionality, a specific feature, or a narrower scope. In these cases, having the capability to build your own tool is extremely beneficial. Anecdotally, this situation is exactly what led to the development of Firewalk, a tool for performing gateway portscans.

In 1998, I worked with a colleague, David Goldsmith, to perform a network penetration test for a company with a reasonably deep network. As a matter of best practice, one of the first things that we did was attempt to enumerate devices across their network. We had an internal IP address, so we started with a UDP-based Traceroute scan.

Traceroute is an active reconnaissance network security tool employing the IP expiry technique designed to map out all intermediate routers en route to a particular destination host. We began our Traceroute as follows:

tradecraft:∼> traceroute -n 10.0.14.1
traceroute to 10.0.14.1 (10.0.14.1), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.540 ms 0.394 ms 0.397 ms
2 10.0.1.1 (10.0.1.1) 2.455 ms 2.479 ms 2.512 ms
3 10.0.2.1 (10.0.2.1) 4.812 ms 4.780 ms 4.747 ms
4 10.0.3.1 (10.0.3.1) 5.010 ms 4.903 ms 4.980 ms
5 10.0.4.1 (10.0.4.1) 5.520 ms 5.809 ms 6.061 ms
6 10.0.5.1 (10.0.5.1) 9.584 ms 21.754 ms 20.530 ms
7 10.0.6.1 (10.0.6.1) 89.889 ms 79.719 ms 85.918 ms
8 10.0.7.1 (10.0.7.1) 92.605 ms 80.361 ms 94.336 ms
9 * * *
10 * * *

This Traceroute brought us eight hops from our starting point to the edge of their network but stopped short at what appeared to be a restrictive border firewall at 10.0.7.1. The firewall apparently blocked most traffic, but we knew that there was a primary DNS server somewhere inside the network and that DNS queries to UDP port 53 would be allowed. Because we could control the starting destination port number and we knew that it was eight hops to the firewall and three probes were being sent per round, we could deterministically control the port number of the Traceroute packet that reached the firewall with the following formula:

(target_port - (number_of_hops * num_of_probes)) - 1
tradecraft:∼> traceroute -n -p‘echo "53 - (8 * 3) - 1" | bc’ 10.0.14.1
traceroute to 10.0.14.1 (10.0.14.1), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.501 ms 0.399 ms 0.395 ms
2 10.0.1.1 (10.0.1.1) 2.433 ms 2.940 ms 2.481 ms
3 10.0.2.1 (10.0.2.1) 4.790 ms 4.830 ms 4.885 ms
4 10.0.3.1 (10.0.3.1) 5.196 ms 5.127 ms 4.733 ms
5 10.0.4.1 (10.0.4.1) 5.650 ms 5.551 ms 6.165 ms
6 10.0.5.1 (10.0.5.1) 7.820 ms 20.554 ms 19.525 ms
7 10.0.6.1 (10.0.6.1) 88.552 ms 90.006 ms 93.447 ms
8 10.0.7.1 (10.0.7.1) 92.009 ms 94.855 ms 88.122 ms
9 10.0.8.1 (10.0.8.1) 101.163 ms * *
10 * * *

This enabled us to get one hop behind the firewall. Due to the fact that Traceroute kept incrementing the destination port after it hit the 10.0.8.1 hop, nine hops were as far as we could get before the packets were denied by the firewall. This UDP destination port incrementing is an artifact from when the original Traceroute code was written years ago; older UNIX kernels would not permit an application programmer to modify IP header fields like the IP ID field that would enable the programmer to more easily identify returned packets. That Traceroute limitation prompted a simple but effective "static patch" to the sourcecode that stopped this incrementing of the destination port. Thus, we simply had to call Traceroute with a target destination port and specify the static port flag:

tradecraft:∼> traceroute -S -p53 10.0.14.1
traceroute to 10.0.14.1 (10.0.14.1), 30 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 0.516 ms 0.396 ms 0.390 ms
2 10.0.1.1 (10.0.1.1) 2.516 ms 2.476 ms 2.431 ms
3 10.0.2.1 (10.0.2.1) 5.060 ms 4.848 ms 4.721 ms
4 10.0.3.1 (10.0.3.1) 5.019 ms 4.694 ms 4.973 ms
5 10.0.4.1 (10.0.4.1) 6.097 ms 5.856 ms 6.002 ms
6 10.0.5.1 (10.0.5.1) 19.257 ms 9.002 ms 21.797 ms
7 10.0.6.1 (10.0.6.1) 84.753 ms * *
8 10.0.7.1 (10.0.7.1) 96.864 ms 98.006 ms 95.491 ms
9 10.0.8.1 (10.0.8.1) 94.300 ms * 96.549 ms
10 10.0.9.1 (10.0.9.1) 101.257 ms 107.164 ms 103.318 ms
11 10.0.10.1 (10.0.10.1) 102.847 ms 110.158 ms *
12 10.0.11.1 (10.0.11.1) 192.196 ms 185.265 ms *
13 10.0.12.1 (10.0.12.1) 168.151 ms 183.238 ms 183.458 ms
14 10.0.13.1 (10.0.13.1) 218.972 ms 209.388 ms 195.686 ms
15 10.0.14.1 (10.0.14.1) 236.102 ms 237.208 ms 230.185 ms

The patched code succeeded in bringing us all the way inside their network, enumerating all hosts up to the target IP address. At this point, we began to wonder about what other ports and transport protocols the firewall would pass and wanted to use the same technique of sending an elicit packet and looking for a terminal packet, but we had reached the wall (so to speak) with Traceroute.

At that point, we were less concerned with intermediate hops between us and our target because we wanted to try other ports and other protocols, but traceroute was just not really designed for this type of activity. This additional functionality that we needed was not available in any existing tool, so from that we began development of the Firewalk active reconnaissance network security tool.

Firewalk attempts to determine what transport protocols a given network gateway (router or firewall) will pass. Firewalk is another implementation of the IP expiry technique that works by sending out TCP or UDP packets with an IP TTL of one greater than the targeted gateway. If the gateway permits the traffic, it will forward the packets to the next hop where they will expire and elicit an ICMP time exceeded message. If the gateway host does not permit the traffic, it will likely drop the packets on the floor and we will see no response. To get the correct IP TTL that will result in expired packets one beyond the gateway, Firewalk needs to ramp up hop counts. It performs this task in the same manner that Traceroute works. Once Firewalk has the gateway hopcount (at that point, the scan is said to be bound), it can begin our scan. A sample execution of Firewalk across the same network performing a small UDP scan to see what other ports were open is as follows:

tradecraft:∼> firewalk -n -S53, 135–139,111,161 10.0.8.1 10.0.10.1
HOTFOOT through 10.0.8.1 (using 10.0.10.1 as a metric).
Ramping phase source port: 53, destination port: 33434
UDP-based scan. Using strict RFC adherence.
(1) TTL: 1 - expired [10.0.0.1]
(2) TTL: 2 - expired [10.0.1.1]
(3) TTL: 3 - expired [10.0.2.1]
(4) TTL: 3 - expired [10.0.3.1]
(5) TTL: 3 - expired [10.0.4.1]
(6) TTL: 3 - expired [10.0.5.1]
(7) TTL: 3 - expired [10.0.6.1]
(8) TTL: 3 - expired [10.0.7.1]
(9) TTL: 3 - expired [10.0.8.1]
Binding host reached.
Scanning phase bound at 9 hops.
port 53 open (expired) [10.0.9.1]
port 135 *
port 136 *
port 137 *
port 138 *
port 139 *
port 111 open (expired) [10.0.9.1]
port 161 open (expired) [10.0.9.1]
Total packets sent:                 17
Total packets errors:                0
Total packets caught:               24
Total packets caught of interest:   12
Total ports scanned:                 8
Total ports open:                    3
Total ports unknown:                 0

From this scan, we learned that of the eight UDP ports scanned, only three ports 53 (DNS), 111 (RPC), and 161 (SNMP) were passed by the 10.0.8.1 firewall. This information was good for the engagement that we could never have gotten with Traceroute alone. Much more detailed information on active reconnaissance tools, IP expiry techniques, and Firewalk will appear in later chapters.

This book is here to help you learn how to build your own network security tools for your own purposes. You will learn the following:

A multi-layered model for describing network security tools

The ins and outs of several specific security-related components

How to combine these components into several useful network security techniques

Four different classifications for network security techniques

How to combine techniques to build network security tools

How We Organized This Book

Chapters 1–7 cover the Network Security Tool Paradigm and all of the building blocks, or components, available to the reader. Chapter 1 lays out a modular model that we will use to tie the book together. Each chapter from 2–7 is devoted to a different component that we will discuss in detail, covering native datatypes and exported functions. We took great care to add value to each chapter above and beyond that which is ostensibly available in existing manual pages and documentation. Each chapter ends with a small sample program that illustrates core functionality of that component. The components covered in these chapters are:

Libpcap: Chapter 2

Libnet: Chapter 3

Libnids: Chapter 4

Libsf: Chapter 5

Libdnet: Chapter 6

OpenSSL: Chapter 7

Chapter 8–11 cover several techniques that are built from the components. Each chapter in this section will cover techniques in each of the four classifications in detail, including sample code:

Passive Reconnaissance Techniques: Chapter 8

Active Reconnaissance Techniques: Chapter 9

Attack And Penetration Techniques: Chapter 10

Defensive Techniques: Chapter 11

Chapter 12 is devoted to using the model, code, and concepts covered in the first sections to build a complete and fully functional network security tool in Firewalk 5.0.

You can download all of the code in this book from the companion Web site of this book at http://www.wiley.com/compbooks/schiffman.