Backtrack 5 : Information Gathering : Network Analysis : Identify Live Hosts : pbnj

PBNJ is made ip of two commands which are scanpbnj and outputpbnj. The manpages for both scanpbnj and outputpbnj are located in collapsed tables at the bottom of this post in case you want more details. When you run scanpbnj it technically a script that runs nmap and dumps the results to a database. The scanpbnj command will store results in various database formats including CSV, MySQL, PostgreSQL, and SQLite. Once the results are stored you can pull the results from the database using outputpbnj which can output report style results in CSV format, tab delimited format, or HTML format. Continue reading below for more details regarding outputpbnj and scanpbnj on Backtrack Linux 5 r2.

PBNJ: scanpbnj Details:

As noted above scanpbnj simply runs nmap with a default set of nmap switches that can be modified though and then stores those nmap results to a database. I will list a couple examples of how to use scanpbnj to output results to a SQLite database as well as a CSV file. It should be noted that if you want to use scanpbnj to output results to a CSV file on Backtrack Linux you will need to install a package as described in this article. The first example below shows a basic scanpbnj command that outputs results for a couple IP addresses to a SQLite database.

The below output shows the list of IP addresses in a file named “iplist” being fed to scanpbnj in all of the below examples.

List Of IP Addresses Used In All PBNJ Examples Below:

Here is a brief explanation of the switches used with the scanpbnj command in the example below.

PBNJ: Explanation Of Switches Used With scanpbnj First Example Below:

• -i iplist: The -i switch allows you to point to a list of IP addresses in a file
• -p: Ping sweep every target and then only scan the targets that are alive
• –dir /pbnjdir: Specifies the directory of the CSV or SQLite database file as well as the location of the -i file
• –test 10: Provides detailed output to the screen, helpful in examples or when debugging issues

PBNJ: Use scanpbnj To Output Results nmap Scan Results To SQLite:

As you can see above two of the four IP addresses responded to the ping sweep so only two IP’s were scanned with nmap. Using the “–test 10” command line configuration option spits out useful information like the location of the nmap, which is /usr/local/bin/nmap, that scanpbnj uses and the nmap switches used for the scan, which in this case were “Scan Args are -vv -O -P0 -sSV -p 1-1025”. You can above that there are a couple ports open on each of the alive IP addresses and those results are now stored in a SQLite database file. If you were to continue to run scanpbnj on a regular basis results would be updated if things change and then you could use outputpbnj to run reports on the SQLite database file.

PBNJ: Output scanpbnj Results To CSV File On Backtrack Linux:

One way that I find scanpbnj to be more useful since I don’t typically continue scanning the same network over and over is to output the scanpbnj results directly to a CSV file to analyze. To do this you first need to modify the scanpbnj config.yaml file located in your home directory under the .pbnj-2.0/ folder. If you were logged in as root the full path to the pbnj config.yaml file would be the same as the below example output.

PBNJ: Path To PBNJ config.yaml File When Run As Root:

The default contents of the config.yaml file are similar to the below except instead of “db: CSV” the default setting is “db: SQLite” which is commented out right above the CSV setting. Below is the output of the config.yaml file after I modified it to output results to CSV instead of the default SQLite database.

PBNJ: Modified pbnj config.yaml File To Output Results To CSV:

Now if you were to run the exact same command as the first example the results would be output to CSV files instead of a SQLite database. Just to provide details of how results look in CSV instead of the SQLite database we will go ahead and run scanpbnj exactly like the first example with only the config.yaml file modified.

PBNJ: Use scanpbnj To Output Results nmap Scan Results To CSV Files:

As you can see above the output is exactly the same as when the results were dumped to SQLite however this time instead of a data.dbl file the results are dumped to two CSV files named machine and services. The machine CSV includes the IP of the device, the hostname if available, the Operating System if available, and a couple different timestamps. The services CSV file includes the service, the state of the service, the service port, the service protocol, the service version, the service banner, and a couple timestamps. Examples of each of these files are listed below.

PBNJ: Example scanpbnj Output To machines CSV File:

PBNJ: Example scanpbnj Output To services CSV File:

I really like the CSV output as it is the easiest for me to manipulate for reports, etc. without having to mess with using outputpbnj to extract the database from either a SQLite, Mysql, or PostgreSQL database. The unfortunate part about dumping to CSV files is I don’t see (it is possible I am missing this) how the devices in the machines CSV file are tied to services in the services CSV file. I would however prefer MySQL or PostgreSQL if I were using scanpbnj to run a nightly scan via a cronjob or something similar.

Now that we have the basics of scanpbnj down lets move on to a quick outputpbnj example. In the below example I have switched the config.yaml file back to “db: SQLite” to show a couple real world examples of how outputpbnj is useful. First however we show outputpbnj with the –list switch to show each of the preconfigured output reports available using outputpbnj.

**Note** The outputpbnj command is broken on Backtrack 5 R2 but can easily be fixed by following the instructions here.

PBNJ: List Of outputpbnj Queries Available:

Now below we show three of the above queries being used with outputpbnj.

PBNJ: Use outputpbnj To Extract scanpbnj Results From SQLite Database File:

Above we show three different outputs using the outputpbnj command. This is slick because if you had scanpbnj running in a cron and then followed that up by outputpbnj running in cron as well you could easily get a nightly email report of devices on your network along with the services that those devices are running. The switches are fairly easy above but just remember when using outputpbnj to specify the database file using –data.

Click on either scanpbnj man page or outputpbnj man page below to view the entire manpage for each PBNJ application below.

[expand title=”scanpbnj man page“]
SCANPBNJ.MAN.1(1p) User Contributed Perl Documentation SCANPBNJ.MAN.1(1p)

NAME
ScanPBNJ – a program for running Nmap scans and storing the results in
a PBNJ 2.0 database.

SYNOPSIS
scanpbnj [Options] {target specification}

DESCRIPTION
ScanPBNJ performs an Nmap scan and then stores the results in
a database. The ScanPBNJ stores information about the machine that has
been scanned. ScanPBNJ stores the IP Address, Operating System,
Hostname and a localhost bit. The localhost bit, is simply a single
bit which is 1 when the target machine is localhost, otherwise it is
0. It also stores two timestamps for the machine table. The first is
a human readable version and the second is the unix time. Both of
these timestamp correspond to the first time that the machine was
scanned.

ScanPBNJ stores information about the services that are found to be
running on the target machine. ScanPBNJ stores typical information
about the service, by storing the port and protocol. Also, ScanPBNJ
stores version, product and service state information about each
service. The service state can either be up or down. Two timestamps
are also inserted for each instance of every service. The first is a
human readable version and the second is the unix time. Both of
these timestamp correspond to the time that the service was scanned.

This tool can give an admin a clear network layout with of
all the machines with all the services they are running.

Apart of PBNJ 2.0 suite of tools to monitor changes on a network.

OPTIONS
Usage: scanpbnj [Options] {target specification}

Target Specification:
Can be a IP Address, hostname, network etc.
Ex: microsoft.com, 10.0.0.0/24, 192.168.1.1, 10.0.0.0-100
-i –iplist Scan using a list of IPs from a file
-x –xml Parse scan/info from Nmap XML file

Scan Options:
-a –args Execute Nmap with args (needs quotes)
-e –extraargs Add args to the default args (needs quotes)
–inter Perform scan with non default interface
-m –moreports Add ports to scan ex: 8080 or 3306,5900-5910
-n –nmap Path to Nmap executable
-p –pingscan Ping Target then scan the alive host(s)
–udp Add UDP to the scan arguments
–rpc Add RPC to the scan arguments
-r –range Ports for scan [def 1-1025]

–diffbanner Parse changes of the banner

Config Options:
-d –dbconfig Config for results database [def config.yaml]
–configdir

Directory for the database config file–data SQLite Database override [def data.dbl]
–dir

Directory for SQLite or CSV files [def .]General Options:
–nocolors Don’t Print Colors
–test Testing information
–debug Debug information
-v –version Display version
-h –help Display this information

Send Comments to Joshua D. Abraham ( jabra at ccs.neu.edu )

THINGS TO NOTE
* ScanPBNJ requires root privileges to perform a scan.

* If you do not pass a specific ports range, 1-1025 is used.

* If there are configs in the current directory, they are used
instead of those in the user’s config directory.

* ScanPBNJ does not modify previous database entries. It simply
inserts new information when a change is found.

* One thing that should be done when performing scans is to make
sure to use the same ports or you will get false positives.

EXAMPLE SINGLE SCAN
1) Scan a class B network on ports 1-9000

sudo ./scanpbnj -r 1-9000 10.0.0.0/16

2) Scan an IP Address on ports 1-9000

sudo ./scanpbnj -r 1-9000 10.0.0.100

EXAMPLE AUTOMATED SCANS
The following examples can be added to /etc/crontab

1) Scan a Class C network every 2 hours

30 */2 * * * root scanpbnj 10.0.0.

2) Scan a Class C network everyday at 2:30

30 2 * * * root scanpbnj 10.0.0.

TARGET SPECIFICATION
The target specified is a typical method of probing the network.
Therefore, any of the following can be used:
(e.g. 10.0.0.1, 10.0.0.1-254, 10.0.0.0/24 or 10.0.0.).
The first example is simply an IP address. The second example is
the scanning of a range. The third is a range in CIDR notation.
The fourth example is the IP with the star which specifies to scan
255 hosts. This is the same format that Nmap uses with the only
exception being the on the last octet. This is needed because it
needs to not interpret the star when it is being executed.

Another option, is to use a hostname or domain name. ScanPBNJ will
then resolve the name to the correct IP address. If you pass a
debug flag with level 1 or greater, ScanPBNJ will display what IP
address, the hostname resolved too.

-i Scan using a list of IPs from a file
The iplist option is useful when you have a specific list of IPs to
scan. This will perform a full scan of the IPs that are specified.
This option is similar to using -sL with Nmap. The results of
the scan are inserted into the database.

-x Parse scan/info from Nmap XML file
This option is useful when you can’t perform the scan yourself or
you don’t want ScanPBNJ to perform the scan. Another situation where
this is useful, is if you have an XML file that was done in the past
and you want to extract information from it, possibly to compare
with what is currently being run on the target. ScanPBNJ parses the
Nmap XML file and extracts the information about the host(s) and
service(s) then inserts the results into the database.

SCAN OPTIONS
-a –args
** NOTE ** This option needs quotes around the passed arguments

This option will bypass the default arguments that are used in
scanning with Nmap. This can be used to do a particular type of scan
that is not possible by simply adding extra arguments. For example,
if you want to only scan UDP ports and still do version
identification and OS detection, you would do so using the following
notation:

sudo scapbnj -a “-A -O -sU” localhost

-e –extraargs
** NOTE ** This option needs quotes around the passed arguments

This option will add additional arguments onto the default scan
arguments. This is most useful in doing scans where time optimization
is needed. Therefore, these arguments will be added and then used in
the scan.

–inter
This option sets an alternative interface for performing the scan.
This is useful when you have multiple interfaces on a machine
with restrictions on which devices can access certain IP or IP ranges.

-m –moreports This options adds additional ports to the range of ports to scan.
Individual port numbers are OK, as are ranges separated by a
hyphen (e.g. 1-1023,5800,5900,8080).

For example:

sudo scanpbnj -m 7000-7500,8080 localhost

This scan would scan the default range as well 7000-7500 and 8080.

-n –nmap
Use an alternative Nmap rather than Nmap located in the your path.
This is useful if you have multiple version of Nmap installed on
a system or if you are testing a new version of Nmap. Remember that if
you are using a newly compiled version of Nmap that you need to
export NMAPDIR to the location that Nmap was compiled in. Thus, if
you have compiled Nmap in your homedir, use the following notation:

export NMAPDIR=$HOME/nmap-VERSION/

sudo scanpbnj -n $HOME/nmap-VERISON/ localhost

-p Ping Target then scan the host(s) that are alive
The ping scan is a useful method of only scanning the host that are
responding to ICMP echo requests. This scan basically takes the host
that respond to ICMP echo requests and then performs a scan only on
those hosts. Therefore, no time is wasted in scanning hosts that do
not respond. The results of the scan are then inserted into the
database.

–udp Add UDP to the scan arguments
Perform a UDP scan, in addition to the default scan.

sudo scanpbnj –udp localhost

If you want to only perform a UDP scan you need to set the specific
arguments for the scan.

sudo scanpbnj -a “-vv -O -P0 1-1025 -sVU” localhost

–rpc Add RPC to the scan arguments
Perform a RPC scan in addition to the default scan.

sudo scanpbnj –udp localhost

If you want to only perform a RPC scan you need to set the specific
arguments for the scan.

sudo scanpbnj -a “-vv -O -P0 1-1025 -sVR” localhost

-r –rangePorts for scan [default 1-1025]

This option specifies which ports you want to scan and overrides the
default. Individual port numbers are OK, as are ranges separated by a
hyphen (e.g. 1-1023,5800,5900,8080 ).

Thus, a scan like this is ok.

sudo scanpbnj -r 22,25,80,100-200 localhost

Also, if you have leave off the number after the hyphen it will scan
all from the start port to 65535.

For example:

sudo scanpbnj -r 22,25- localhost

–diffbanner
Parse changes of the banner

This options enables ScanPBNJ to do comparisons on the banner. The
reason this is not on by default is that it could show changes in
services that are not are important to the user. However, this option
is useful to a security professional who is looking for any changes
that occur so that they can be verified.

DATABASE OPTIONS
-d –dbconfig
Config for results database [default config.yaml]

This option is used to specify an alternative config.yaml file.

–configdir

Directory for Config file [default . ]This option is used to specify an alternative directory for the
config.yaml file.

–data
SQLite Database override [default data.dbl ]

This option is used when you want to change the name of the SQLite
database file that is generated.

–dir

Directory for SQLite or CSV files [default . ]This option is used when you want the database to be generated in a
different directory.

GENERAL OPTIONS
–nocolors
The default results from ScanPBNJ print the useful changes with colors
This options will simply not print the colors.

–test
Increases the Test level, causing ScanPBNJ to print testing information
about the scan in progress. Using the Test level is mostly only using
for testing. This will also print the debugging information so it can
get rather lengthy. The greater the Test level the more output will be
given.

This option is also used for reporting bugs. All bug reports should
be submitted using –test 1 and an additional report may be needed
depending on the issue.

–debug
Increases the Debug level, causing ScanPBNJ to print more information
about the scan in progress. Nmap scanning arguments are shown as well
as the ip address if you are scanning a domain name. This option is
used to give the user more information about what the scanner is doing.
The higher the debug level the more output the user will receive.

-v –version
Prints the ScanPBNJ version number and exits.

-h –help
Prints a short help screen with the command flags. Running ScanPBNJ
without any arguments does the same thing.

DEFAULT SCAN
Here are the default arguments that are used during a default scan:

-vv -O -P0 -sSV -p 1-1025

FILES
PBNJ’s data files are stored in ScanPBNJ and OutputPBNJ. When either
of these programs is run the configuration files will be generated
for the user if they don’t already exists and placed in the
$HOME/.pbnj-2.0 directory. Again, if there is a configuration file
in the current directory it is used instead of the version in the
configuration directory.

$HOME/.pbnj-2.0/config.yaml – holds settings for connecting to
the database which store the information from PBNJ scans.

$HOME/.pbnj-2.0/query.yaml – lists all queries that can be used to
retrieve information from the database. Also, includes the name and
description for each query. This is only generated when you executed
OutputPBNJ.

For Windows, the pbnj-2.0 config directory is in the APPDATA
directory, which contains both config.yaml and query.yaml. Depending
on your environment, the APPDATA directory may be a different location
from other environments. Therefore, when the configs are executed for
the first time they will display the path where the configs were
generated.

FEATURE REQUESTS
Any feature requests should be reported to the online
feature-request-tracking system available on the web at :
http://sourceforge.net/tracker/?func=add&group_id=149390&atid=774489
Before requesting a feature, please check to see if the features has
already been requested.

BUG REPORTS
Any bugs found should be reported to the online bug-tracking system
available on the web at :
http://sourceforge.net/tracker/?func=add&group_id=149390&atid=774488.
Before reporting a bug, please check to see if the bug has already been
reported.

When reporting PBNJ bugs, it is important to include a reliable way to
reproduce the bug, version number of PBNJ and Nmap, OS
name and version, and any relevant hardware specs. And of course,
patches to rectify the bug are even better.

SUPPORTED DATABASES
The following databases are supported:

* SQLite [default]
* MySQL
* Postgres
* CSV

DATABASE SCHEMA
The following is the SQLite version of the database schema:

CREATE TABLE machines (
mid INTEGER PRIMARY KEY AUTOINCREMENT,
ip TEXT,
host TEXT,
localh INTEGER,
os TEXT,
machine_created TEXT,
created_on TEXT);
CREATE TABLE services (
mid INTEGER,
service TEXT,
state TEXT,
port INTEGER,
protocol TEXT,
version TEXT,
banner TEXT,
machine_updated TEXT,
updated_on TEXT);

SEE ALSO
outputpbnj(1), genlist(1), nmap(1)

AUTHORS
Joshua D. Abraham ( jabra at ccs.neu.edu )

LEGAL NOTICES
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details at
http://www.gnu.org/copyleft/gpl.html, or in the COPYING file included
with PBNJ.

It should also be noted that PBNJ has occasionally been known to
crash poorly written applications, TCP/IP stacks, and even operating
systems. While this is extremely rare, it is important to keep in
mind. PBNJ should never be run against mission critical systems
unless you are prepared to suffer downtime. We acknowledge here that
PBNJ may crash your systems or networks and we disclaim all liability
for any damage or problems PBNJ could cause.

perl v5.10.1 2011-08-19 SCANPBNJ.MAN.1(1p)
[/expand]

[expand title=”outputpbnj man page“]
OUTPUTPBNJ.MAN.1(1p) User Contributed Perl Documentation OUTPUTPBNJ.MAN.1(1p)

NAME
OutputPBNJ – a program to query a PBNJ 2.0 database.

SYNOPSIS
outputpbnj [Query Options] [Database Options] [General Options]

DESCRIPTION
OutputPBNJ uses a query yaml config file to execute queries against
the PBNJ 2.0 database. OutputPBNJ returns the result in various
output types (csv, tab and html).

Apart of PBNJ 2.0 suite of tools to monitor changes on a network.

OPTIONS
Usage: outputpbnj [Query Options] [Config Options] [General Options]
Query Options:
-q –query Perform sql query
-t –type Output Type [csv,tab,html]
-f –file Store the result in file otherwise stdout
–both Print results and store them in a file
–dir

Store the result in this directory [def .]-l –lookup Lookup description based on name
–list List of names and descriptions
-n –name Lookup all the names
-d –desc Lookup all the descriptions
-s –sql Lookup all the sql queries

Config Options:
–qconfig Config of sql queries [def query.yaml]
–dbconfig Config for accessing database [def config.yaml]
–dbdir

Directory for Config file [def .]–dataSQLite Database override [def data.dbl]

General Options:
–test Test Level
–debug Verbose information
-v –version Display version
-h –help Display this information

Send Comments to Joshua D. Abraham ( jabra at ccs.neu.edu )

THINGS TO NOTE
* OutputPBNJ requires root privileges to query a database that is
owned by root. Thus, if you are scanning with ScanPBNJ you will need
to run OutputPBNJ with root privileges to access the database.

* If there are configs in the current directory, they are used
instead of those in the user’s config directory.

Query Options
-q –query Perform sql query
This option is where the actual query is specified. Therefore, once
you know the query you wish to use simply pass it as an argument to
this option.

-t –type Output Type [csv,tab,html]
This options is used to specify which output format you wish to use.
For example, if you would like to have output that you can show
someone else the CSV format is useful because you can simply pull the
file into OpenOffice Calc or Excel as it is a comma delimited file.

-f –file
This option is used to specifiy output to a file rather than standard
output. This is useful if you want to grow the results of queries as
the result will be added onto the end of the file.

–both
This option is used when you want both output to standard output, as
well as to a file. This will save the result to a file if you are
having the result sent to the screen or piped to your email which you
may or may not disregard.

–dir

Store the result in this directory [default .] 

This option is used with the writing to a file. This option will 

store the file in a alternative directory than the current directory.-l –lookup
This options is used to lookup the description of a specific query.
This will return the description of the query.

–list List of names and descriptions
This option is used to return a list of all the queries with the
names and descriptions. This is very useful when you are starting to
use OutputPBNJ or using a new query config.

-n –name
This option is used to print the all the query names.

-d –desc
This option is used to print the all the query descriptions. This is
useful to find out all the queries do.

-s –sql
This option is used to print the all the queries. This is useful for
developing new queries based on other queries.

Config Options
–qconfig
Config of sql queries [default query.yaml]

This option is used to specify an alternative query.yaml file.

–dbconfig
Config for accessing results database [default config.yaml]

This option is used to specify an alternative config.yaml file.

–dbdir

Directory for Config file [default .]This option is used to specify an alternative directory for the
config.yaml file.

GENERAL OPTIONS
–test
Increases the Test level, causing OutputPBNJ to print testing
information about the Query. Using the Test level is mostly only
using for testing. This will also print the debugging information so
it can get rather lengthy. The greater the Test level the more output
will be given.

This option is also used for reporting bugs. All bug reports should
be submitted using –test 1 and an additional report may be needed
depending on the issue

–debug
Increases the Debug level, causing OutputPBNJ to print more
information about the query in progress. The higher the debug leve
the more output the user will receive.

-v –version
Prints the OutputPBNJ version number and exits.

-h –help Display this information
Prints a help screen with the command flags.
Running OutputPBNJ without any arguments does the same thing.

FILES
PBNJ’s data files are stored in ScanPBNJ and OutputPBNJ. When either
of these programs is run the configuration files will be generated
for the user if they do not already exists and placed in the
$HOME/.pbnj-2.0 directory. Again, if there is a configuration file in
the current directory it is used instead of the version in the
configuration directory.

$HOME/.pbnj-2.0/config.yaml – holds settings for connecting to the
database which store the information from PBNJ scans.

$HOME/.pbnj-2.0/query.yaml – lists all queries that can be used to
retrieve information from the database. Also, includes the name and
description for each query. This is only generated when you executed
OutputPBNJ.

For Windows, the pbnj-2.0 config directory is in the APPDATA
directory, which contains both config.yaml and query.yaml. Depending
on your environment, the APPDATA directory may be a different location
from other environments. Therefore, when the configs are executed for
the first time they will display the path where the configs were
generated.

QUERY
The query.yaml file contains the list of various names, descriptions
and sql queries that can be executed by OutputPBNJ.

Here is one example:

– name: vulnssh
desc: list all of the services that have old ssh running
sql: |-
select S.updated_on,M.ip,S.service,S.port,S.version from services
as S, machines as M where service=’ssh’ and state=’up’ and
version!=’4.1p1′

This examples shows how the name, description and sql are layed out in
the yaml format. Therefore, we know the name of the query is vulnssh
and it’s purpose is to list SSH servers which are not running
a version 4.1p1. It is very easy to create another script that would
check for the latest version of a given service and therefore the
user would be able to verify that that particular service needed to
be updated on the machine that was scanned.

FEATURE REQUESTS
Any feature requests should be reported to the online
feature-request-tracking system available on the web at:
http://sourceforge.net/tracker/?func=add&group_id=149390&atid=774489
Before requesting a feature, please check to see if the features has
already been requested.

BUG REPORTS
Any bugs found should be reported to the online bug-tracking system
available on the web at :
http://sourceforge.net/tracker/?func=add&group_id=149390&atid=774488.
Before reporting bugs, please check to see if the bug has already been
reported.

When reporting PBNJ bugs, it is important to include a reliable way
to reproduce the bug, version number of PBNJ and Nmap, OS
name and version, and any relevant hardware specs. And of course,
patches to rectify the bug are even better.

SUPPORTED DATABASES
The following databases are supported:

* SQLite [default]
* MySQL
* Postgres
* CSV

DATABASE SCHEMA
The following is the SQLite version of the database schema:

CREATE TABLE machines (
mid INTEGER PRIMARY KEY AUTOINCREMENT,
ip TEXT,
host TEXT,
localh INTEGER,
os TEXT,
machine_created TEXT,
created_on TEXT);
CREATE TABLE services (
mid INTEGER,
service TEXT,
state TEXT,
port INTEGER,
protocol TEXT,
version TEXT,
banner TEXT,
machine_updated TEXT,
updated_on TEXT);

SEE ALSO
scanpbnj(1), genlist(1), nmap(1)

AUTHORS
Joshua D. Abraham ( jabra at ccs.neu.edu )

LEGAL NOTICES
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details at
http://www.gnu.org/copyleft/gpl.html, or in the COPYING file included
with PBNJ.

It should also be noted that PBNJ has occasionally been known to crash
poorly written applications, TCP/IP stacks, and even operating systems.
While this is extremely rare, it is important to keep in mind. PBNJ
should never be run against mission critical systems unless you are
prepared to suffer downtime. We acknowledge here that PBNJ may crash
your systems or networks and we disclaim all liability for any damage
or problems PBNJ could cause.

perl v5.10.1 2011-08-19 OUTPUTPBNJ.MAN.1(1p)
[/expand]