Using the Network Security Toolkit

Transcription

Ronald Henderson
[email protected]
Paul Blankenbaker
[email protected]
by Ronald Henderson
by Paul Blankenbaker
Copyright © 2003, 2004 Respective Authors
This document provides guidelines for the typical usage of the Network Security Toolkit for
common problems.
Table of Contents
1. Getting Started ..................................................................................................................1
Check the System Requirements................................................................................1
Downloading And Burning The ISO Image.............................................................3
On A Linux System ............................................................................................3
On A Windows System......................................................................................5
Examine the Boot Options ..........................................................................................5
Booting .................................................................................................................5
Booting Without a DHCP Server......................................................................6
The NST_CDROM_IDE Option (ide) ..............................................................6
Using A Serial Console At Boot........................................................................6
Choose a Access Method.............................................................................................9
Console Access....................................................................................................9
Serial Port Access..............................................................................................10
Access Via ssh/putty........................................................................................10
Use the Web User Interface .............................................................................10
Bring Up a X Desktop on the Local System ..................................................10
Run a X Desktop Remotely (VNC).................................................................12
Changing the Password (nstpasswd)......................................................................14
Text Editors (vim, jed)................................................................................................15
Determine or Set the IP Address..............................................................................16
Automating Your Setup with lnstcustom ...............................................................17
Preparing a Thumb Drive for lnstcustom.....................................................18
Using lnstcustom With a Web Server............................................................19
2. The Web User Interface (WUI) .....................................................................................23
Initial Connection.......................................................................................................23
Snort In Two Clicks ....................................................................................................26
Examining Snort Results ...........................................................................................28
Probing With Nessus .................................................................................................39
Traffic Monitoring With bandwidthd72 ....................................................................49
3. NST Scripts ......................................................................................................................59
Network Time Protocol (NTP) .................................................................................59
RAM Disk Creation....................................................................................................60
MySQL .........................................................................................................................62
Snort (NST v1.0.4) ......................................................................................................65
Snort (NST v1.0.5 and Above) ..................................................................................75
Setup Snort Example: Standalone Configuration ........................................78
Setup Snort Example: Backend MySQL Snort Database With Remote IDS
Snort Probes .............................................................................................87
Nessus ........................................................................................................................101
ettercap.......................................................................................................................101
IFGraph......................................................................................................................101
Kismet ........................................................................................................................101
BandwidthD..............................................................................................................106
Nikto...........................................................................................................................106
NTop...........................................................................................................................106
setup_sendmail.........................................................................................................112
Checking sendmail Status.............................................................................114
Becoming a SMTP Server ..............................................................................118
Enabling Smart Host ......................................................................................119
4. File Systems ...................................................................................................................125
Finding Mounted File Systems...............................................................................125
Finding Unmounted Disks .....................................................................................125
Using File Systems ...................................................................................................126
Making Use of Swap Space ...........................................................................126
Mounting Local Hard Disks..........................................................................127
Mounting USB Thumb Drives ......................................................................128
iii
Making SMB (Windows Shares) ...................................................................128
Mounting NFS Drives ....................................................................................130
Loopback Tricks........................................................................................................131
Mounting A File As A Filesystem ................................................................131
Mounting a ISO Image...................................................................................133
Mounting a Initial RAM Disk .......................................................................133
Mounting A Encrypted Filesystem (**Note: Fedora Core 2 and Above
Only) .......................................................................................................134
5. System Recovery ...........................................................................................................137
Windows XP Recovery ............................................................................................137
Using a DVD+RW Drive .........................................................................................138
6. Using NST In The Wild...............................................................................................143
Overview ...................................................................................................................143
Basic Simple: 1 ..........................................................................................................143
Basic Simple: 2 ..........................................................................................................143
Mobile Wireless Monitoring ...................................................................................143
Small Business Configuration ................................................................................144
Enterprise Configuration ........................................................................................144
7. Using VPNs With NST ................................................................................................147
Overview ...................................................................................................................147
The VPN PPP Tunneled Over SSH Script: vpn-pppssh......................................147
VPN: PPP Tunneled Over SSH...............................................................................152
VPN: Tunnelling Multiple PPP Links Over SSH .................................................153
VPN: PPP Tunneled Over SSH Overhead Discussion ........................................154
VPN: PPP Tunneled Over SSH Effective Throughput Rate Discussion...........158
Effective Throughput Rate: NST Probe - NST Probe Same Fast Ethernet
LAN Segment ........................................................................................159
Effective Throughput Rate: NST Probe - NST Probe On Different Fast
Ethernet LAN Segments (2 VLANs) ..................................................162
Effective Throughput Rate: NST Probe - NST Probe On Different Fast
Ethernet LAN Segments (2 VLANs) Using a PPP Tunneled Over
SSH VPN ................................................................................................163
VPN: FreeS/WAN IPSEC........................................................................................168
8. Virtual Computing........................................................................................................171
Secure Virtual Computing ......................................................................................171
Secure Virtual Computing With Microsoft Remote Desktop (RDP).................171
9. LDAP ...............................................................................................................................173
LDAP search example .............................................................................................173
10. Serial Traffic Monitoring ...........................................................................................175
Cable Construction...................................................................................................175
Monitoring Session - Using Basic Linux Utility Programs ................................175
Monitoring Session - Using NST Utility Program: "monitor_serial" ................178
11. Global Positioning System (GPS) ...........................................................................181
GPSD ..........................................................................................................................181
12. Networking ..................................................................................................................185
Ethernet/Fast Ethernet/Gigabit Ethernet Network Cabling ............................185
iv
Chapter 1. Getting Started
This section is for those which downloaded version 1.0.6 (its still useful for 1.0.5) of
the bootable ISO image file from http://sourceforge.net/projects/nst and successfully burned it to a CDROM. If you received your ISO from some other location or
created a custom ISO from the source code it is likely that there will be discrepancies.
Check the System Requirements
The Network Security Toolkit is designed provide a large assortment of tools that
run entirely in RAM. A primary goal of the project was to provide a bootable ISO
that anyone could try booting without fear of having the contents of their hard drive
modified.
Because of this basic design decision, the Network Security Toolkit requires a fair
amount of RAM. Here are the minimum system requirements.
Table 1-1. Minimum Requirements
Component
Minimum
Recommended
Notes
CPU
Celeron
i686
It will NOT run on
a Intel 386, Intel
486, or Intel
Pentium class CPU.
It is known to work
on the Intel
Celeron (466MHz)
and above, Intel
Pentium II
(266MHz) and
above, AMD
Anthlon, AMD
Duron, and AMD
Anthlon XP.
RAM
128MB
256MB
The minimum
amount of 128MB
is only enough for
basic applications.
If you want to run
X, snort2, or any
serious set of
applications, you
will want at least
256MB of RAM. If
you have Linux
swap partitions
available and don’t
mind having the
Network Security
Toolkit make use of
them, you can use
the laddswap
command.
1
2
Component
Minimum
Recommended
Notes
Motherboard
-
-
The Network
Security Toolkit
should work on
any motherboard
which is support
by Red Hat Linux
92. However, some
newer
motherboards have
components which
we don’t have the
drivers for. You
typically get a
kernel panic at boot
time in this
situation.
Ethernet
0
2
Technically, you
could use the
Network Security
Toolkit without a
Ethernet card
installed. However,
it wouldn’t be of
much use for
networking. Two
(or more) Ethernet
ports are strongly
recommended
allowing one to be
used for general
access to the
Network Security
Toolkit and the
others to act as a
probes to monitor
network traffic
(stealth mode). The
drivers included on
the ISO may or
may not support
the Ethernet
devices in your
system (some of
the newer
motherboards have
Ethernet devices
which don’t work).
Component
Minimum
Recommended
Notes
CDROM
24X
52X
It would probably
work on a 4X
CDROM, but the
access time would
be painfully slow.
Older CDROM
drives seem to
require the
NST_CDROM_IDE
option at boot time.
Downloading And Burning The ISO Image
The downloading and burning of the Network Security Toolkit ISO involves the following:
•
Downloading the gzipped ISO image from the Files section found on the project
page at SourceForge. Look for nst-1.0.5.iso.gz in the list of files available for
download. You should be able to start downloading the ISO for the 1.0.5 release by pointing your browser at http://prdownloads.sourceforge.net/nst/nst1.0.5.iso.gz?download.
•
You may want to compare the MD5 of the nst-1.0.5.iso.gz which you downloaded against the value in the manifest3. If you have a valid copy of the Network
Security Toolkit ISO image, your MD5 checksum should match the value at the
web site.
•
You will need to uncompress the ISO image.
•
You may want to download and run the nstisopasswd-1.0.5.bash script to set the
default password in your ISO image prior to burning. I suspect that many of you
will skip this step, and later realize that you really wish you hadn’t (hope you are
using CDRW media).
Note: This feature became available in the 1.0.5 release.
•
You will then need to burn the uncompressed ISO image to a CDR or CDRW disk
using your favorite CD burning software.
On A Linux System
Assuming that you have the wget, md5sum and cdrecord commands installed
and configured on your system and that you’ve download the ISO image to the
file nst-1.0.5.iso.gz, you should be able to create your bootable CD using the
following set of commands:
[root@quesadilla root]# md5sum nst-1.0.5.iso.gz
1540d0a08c90735aae375718e35b6514 nst-1.0.5.iso.gz (1)
[root@quesadilla root]# gunzip nst-1.0.5.iso.gz
[root@quesadilla root]# wget -nH \
http://www.networksecuritytoolkit.org/nst/log/nstisopasswd-1.0.5.bash (2)
3
--13:38:19-=>
Connecting to
Proxy request
Length: 1,565
http://www.networksecuritytoolkit.org/nst/log/nstisopasswd-1.0.5.bash
‘nstisopasswd-$1.0.5.bash’
192.168.100.92:3128... connected.
sent, awaiting response... 200 OK
[text/plain]
100%[====================================>] 1,565
1.49M/s
ETA 00:00
13:38:19 (1.49 MB/s) - ‘nstisopasswd-1.0.5.bash’ saved [1565/1565]
[root@quesadilla root]# chmod +x nstisopasswd-1.0.5.bash
[pkb@localhost pkb]$ ./nstisopasswd-1.0.5.bash NEWPASS nst-1.0.5.iso (3)
... Either confirmation that new password was set, or error message ...
[root@quesadilla root]# cdrecord -v -eject blank=fast nst-1.0.5.iso (4)
Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 J?rg Schilling
TOC Type: 1 = CD-ROM
scsidev: ’0,0,0’
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.24
Using libscg version ’schily-0.7’
atapi: 1
Device type
: Removable CD-ROM
Version
: 0
Response Format: 2
Capabilities
:
Vendor_info
: ’LITE-ON ’
Identifikation : ’LTR-52327S
’
Revision
: ’QS04’
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags
: MMC-3 SWABAUDIO BURNFREE FORCESPEED
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1422080 = 1388 KB
FIFO size
: 4194304 = 4096 KB
Track 01: data
470 MB
Total size:
540 MB (53:30.69) = 240802 sectors
Lout start:
540 MB (53:32/52) = 240802 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 1
Reference speed: 0
Is not unrestricted
Is erasable
Disk sub type: Ultra High speed Rewritable media (2)
ATIP start of lead in: -11076 (97:34/24)
ATIP start of lead out: 336075 (74:43/00)
1T speed low: 16 1T speed high: 16
2T speed low: 8 2T speed high: 24
power mult factor: 4 5
recommended erase/write power: 1
A1 values: 66 4A 99
A2 values: 38 80 00
A3 values: 04 C4 A0
Disk type:
Phase change
Manuf. index: 11
Manufacturer: Mitsubishi Chemical Corporation
Blocks total: 336075 Blocks current: 336075 Blocks remaining: 95273
Forcespeed is OFF.
Starting to write CD/DVD at speed 16 in real TAO mode for single session.
Last chance to quit, starting real write
0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
Performing OPC...
Blanking PMA, TOC, pregap
Blanking time:
11.514s
4
BURN-Free is OFF.
Performing OPC...
Starting new track at sector: 0
Track 01: 470 of 470 MB written (fifo 100%) [buf 99%] 17.0x.
Track 01: Total bytes read/written: 493158400/493158400 (240800 sectors).
Writing time: 205.250s
Average write speed 15.6x.
Min drive buffer fill was 98%
Fixating...
Fixating time:
22.157s
cdrecord: fifo had 7768 puts and 7768 gets.
cdrecord: fifo was 0 times empty and 6614 times full, min fill was 89%.
[root@quesadilla root]#
Figure 1-1. Burning CDRW From ISO On Linux
(1) If the MD5 value reported doesn’t match 1540d0a08c90735aae375718e35b6514,
it probably means that the ISO image you downloaded did not come through
clean.
(2) The wget utility will not set the executable flag on the script file. We do this
ourselves so that we may invoke it.
(3) The nstisopasswd-1.0.5.bash script will only modify the contents of the ISO after
verifying that the ISO image is compatible with the script. You will see an error
message if you downloaded the incorrect version or your ISO image is corrupt.
Note: This feature became available in the 1.0.5 release.
(4) Omit the blank=fast if you are using CDR media or a fresh (already blank)
CDRW.
On A Windows System
You will need to use you web browser (Internet Explorer) to download the
nst-1.0.5.iso.gz ISO image from the Files area of the Network Security Toolkit
project at SourceForge. If you are feeling lucky, you might be able to begin the
download by clicking here4.
After downloading the ISO you will need to uncompress it using either the free gzip5
utility or popular WinZip6 utility.
You will then use a CD burning package like Roxio or Nero to burn the ISO image to
a CDR or CDRW.
Examine the Boot Options
The first time you boot from a Network Security Toolkit CDROM you should press
the SPACE BAR to prevent it from automatically booting. You only have a few seconds
(5 secs) to do this before it boots up using the default setting.
Use the F1, F2, F3, F4 and F5 keys to move between the console screens. You will
find a wealth of information as to how you can adjust the boot options for different
situations.
5
Booting
When the Network Security Toolkit ISO image was created for public distribution, we
had to guess at what settings would be the most common. We tried to provide a ISO
who’s default options would work for the majority of situations. If you determine
that our default choices don’t work for your particular situation, you will need to
specify your own boot options.
Booting Without a DHCP Server
If the network you are booting the Network Security Toolkit on does not have a
DHCP server, the default boot options won’t work. You will see errors in this situation as the Network Security Toolkit won’t be able to retrieve a IP address from a
DHCP server.
In this situation, you should specify base, mbase, serial, utils, pcmcia, or usb at
boot time. For example:
boot: mbase
The NST_CDROM_IDE Option (ide)
Probably the most common problem encountered by people trying to use the Network Security Toolkit, is due to having a CDROM drive that is not compatible with
the ide-scsi driver.
Unfortunately, it is not always apparent when this situation occurs. You may see
failure messages. You might even get to a login prompt, but not be able to enter a
password. You might see complaints about file sizes. There are a bunch of things that
can go wrong when this situation is encountered.
If you are having troubles booting with the default settings, try entering the following
at the boot prompt:
boot: ide
The above will avoid loading the ide-scsi drivers and allow many of the older
CDROM drives to work with the Network Security Toolkit. By specifying this option,
you will be unable to burn CDs (cdrecord requires the ide-scsi drivers).
You can also include the NST_CDROM_IDE with any of the alias boot options to avoid
the loading of the ide-scsi drivers. For example, if you have a old laptop which
didn’t work when the ide-scsi drivers were loaded, you could specify the following
at boot time:
boot: laptop NST_CDROM_IDE
Using A Serial Console At Boot
If the system you are using does not have a keyboard, video card, and/or monitor (i.e.
typically this is found with server systems and is referred to as a "headless configuration"), its
still possible to adjust the default boot Kernel and NST settings. If you connect a null
modem cable from the first serial port (COM:1 or ttyS0) on NST to a dumb terminal
or second computer, one can control the NST boot time environment.
You will need to use the following serial settings:
6
Table 1-2. Serial Port Settings
Baud
19200
Stop Bits
None
Data Bits
8
Stop Bits
1
Flow Control
None (minicom enabl
default - you need to
configuration to disab
Emulation
ANSI (at least for min
For example, I use the minicom program for serial communications on my Linux box.
I’ve set up a minicom configuration named server that I use when I want to monitor/adjust the Network Security Toolkit boot process for a headless or dual monitor
(i.e. both serial and console) NST system. After connecting a null modem cable between the two computers, I started up minicom on my laptop and then powered up
a headless NST server with the CDROM loaded. The following captions depict the
NST serial boot, configuration, option, help, and specification screens (note: these screens
have been captured using development versions of the Network Security Toolkit your screens may be slightly different):
[pkb@salsa html]$ minicom server
Welcome to minicom 2.00.0
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jan 25 2003, 00:15:18.
Press CTRL-A Z for help on special keys
Linux Network Security Toolkit (NST)
http://www.networksecuritytoolkit.org/
==========================(Linux Kernel: 2.4.20-30.9)==========================
Welcome to the Linux Network Security Toolkit (NST). This bootable ISO CD is
based on RedHat 9.0 Linux. The toolkit is designed to provide easy access to
best-of-breed Open Source Network Security Applications and should run on most
x86 platforms.
Default NST boot 5.0s: laptop
===============================================================================
[<^F-1> Main] [<^F-2> Configs] [<^F-3> Options] [<^F-4> Help] [<^F-5> Specs]
HIT SPACE BAR TO DISABLE AUTO-BOOT!
NST(v1.0.5): Tue Apr 20 14:18:03 UTC 2004
boot:
Figure 1-2. NST Serial Boot Screen <^F-1>
You still need to press the SPACE BAR to disable the auto boot (if you want to customize your boot options). Also, you’ll need to use Control-F-1, Control-F-2, etc instead of the function keys to toggle between the help screens.
The following captions show the available NST serial boot screens:
7
NST Kernel Boot Configurations
===============================================================================
The following NST boot configurations are provided for your convenience
when booting an NST session:
Example to boot NST with: (CDROM IDE + USB Support + DHCP-Client + SSHD):
Type: ide <Enter>
===============================================================================
[
base] - Base NST: (User input required: ramdisk_size=65536 or greater)
[
mbase] - base + ramdisk_size=65536
[ serial] - mbase + Serial Console + NST_SERIAL
[ desktop] - Default: mbase + NST_UTILS + NST_USB + NST_DHCP_SSHD + NST_HTTPD
[ laptop] - desktop + NST_PCMCIA
[ server] - desktop + Serial Console + NST_SERIAL
[ lserver] - desktop + ramdisk_size=131072 + Serial Console + NST_SERIAL
[
ide] - mbase + NST_CDROM_IDE + NST_UTILS + NST_USB + NST_DHCP_SSHD
[
utils] - mbase + NST_UTILS
[ pcmcia] - utils + NST_PCMCIA
[
usb] - utils + NST_USB
[
noapm] - server + apm=off
===============================================================================
boot:
Figure 1-3. NST Kernel Boot Configurations <^F-2>
NST Kernel Boot Options
===============================================================================
The following NST boot configurations options are supported for automatic
startup post Kernel boot:
[
NST_UTILS]
[NST_DHCP_SSHD]
[
NST_USB]
[
NST_PCMCIA]
[
NST_SERIAL]
[NST_CDROM_IDE]
[
NST_HTTPD]
[ NST_WD_WAIT]
-
Load full NST utility programs
NST_UTILS + syslogd/klogd + dhclient eth0 + sshd
NST_UTILS + syslogd/klogd + USB support
NST_UTILS + syslogd/klogd + PCMCIA support
Enable a login session on: /dev/ttyS0 (COM:1)
Use native CDROM IDE commands instead of SCSI Emulation
Start Apache Web services: httpd
Wait time in seconds for before sending a HUP signal
to the "init" process post boot (Default: 4 seconds)
===============================================================================
boot:
Figure 1-4. NST Kernel Boot Options <^F-3>
NST Kernel Boot Help
===============================================================================
- To disable the automatic boot of the NST Linux Kernel type any key within
5 seconds (Ex: hit the space bar) after the initial splash screen appears.
- To initiate a NST boot session with a preconfigured NST boot just type
the NST configuration label and hit the <Enter> key. See [<^F-2> Configs].
Example: laptop <Enter>
- To initiate a NST boot session with a preconfigured NST boot and specific
NST options just type the NST configuration label followed by any options and
then hit the <Enter> key. See the [<^F-3> Options] screen for further details.
8
Example: base NST_PCMCIA NST_USB <Enter>
- To enable the Kernel Serial Console append the following Kernel options:
Example: laptop console=tty0 console=ttyS0,19200n8 <Enter>
- To boot NST in single user mode - use Kernel parameter: "single"
Example: base single <Enter>
===============================================================================
boot:
Figure 1-5. NST Kernel Boot Help <^F-4>
NST Kernel Boot Specifications
===============================================================================
- At least 128 MBytes of RAM is recommended to run NST.
- NST kernel and initial RAM disk (initrd) boot command line parameters:
vmlnznst initrd=initrdr9.gz root=/dev/ram0 ramdisk_size=65536
- If your BIOS/CDROM doesn’t support CDROM SCSI emulation, use the option:
NST_CDROM_IDE which supports native CDROM IDE commands. The default boot
will use CDROM SCSI emulation allowing "cdrecord" usage.
- For a headless NST system, Isolinux serial output on COM:1 is enabled.
Serial params: 19200 baud, no parity, 8 data bits, Terminal Emulation: vt220
- To enable Serial Console during the NST Kernel boot, append the following
parameters to the boot command line: console=tty0 console=ttyS0,19200n8.
- By default, a login in session on /dev/ttyS0 (COM:1) is enabled.
Serial params: 19200 baud, no parity, 8 data bits, Terminal Emulation: vt220
===============================================================================
boot:
Figure 1-6. NST Kernel Boot Specifications <^F-5>
As a side note, booting via a serial console is an excellent way to capture error messages if you have a system that has trouble booting from the Network Security Toolkit
CDROM (especially if you have a kernel panic situation).
Choose a Access Method
There are many different ways to interact with the Network Security Toolkit once
you’ve booted.
Regardless of the access method you choose, you will need to login. The default login
ID is root and the default password is nst@2003. This combination is used regardless
of whether you are logging in at the console, through a ssh connection, through a
tightvnc7 connection, or via the Web User Interface. It is recommended that you use
the nstpasswd script as soon as you login to change the password (this is described
in Changing the Password (nstpasswd)).
9
Console Access
If your Network Security Toolkit system has a screen and keyboard, you will have
immediate access to a command line interface. Simply login and start using.
Serial Port Access
If you boot with the serial console enabled (this is not enabled by default), you can
use the first serial port (think /dev/ttyS0 or COM1:) as your access point. You will
need to use the same settings as described in Using A Serial Console At Boot (you can
enable hardware flow control at this point).
Access Via ssh/putty
Assuming the Network Security Toolkit was booted with a network card and the
network card drivers loaded properly, you will have access to the Network Security
Toolkit system via ssh (or putty - for Windows users). Assuming the Network Security Toolkit has a IP address of 192.168.0.17, you should be able to connect in the
following manner (NOTE: Just hit the enter key at the passphrase prompt, and then
enter your password at the password prompt):
[pkb@salsa docs]$ ssh [email protected]
Enter passphrase for key ’/home/pkb/.ssh/id_rsa’:
[email protected]’s password: nst@2003 # NOT ECHOED
Last login: Thu Apr 22 18:20:37 2004 from 192.168.0.133
=================================================
= Linux Network Security Toolkit for RedHat 9.0 =
=================================================
"nstusage" - Use this aliases to read the NST usage and notes doc...
[root@probe root]#
Figure 1-7. Using ssh
Please note, ssh access is only available if the sshd is running on the Network Security Toolkit. This should always be the case if you used the default boot settings.
Use the Web User Interface
Unless you disable it, a SSL web based interface is also enabled at boot time. You can
use any https (NOTE THE s!) capable web browser to access the Network Security
Toolkit. The web based interface provides convenient access to a subset of the tools
available - please see The Web User Interface (WUI) for additional information.
Bring Up a X Desktop on the Local System
If you have at least 256MB of RAM installed, you may want to bring up a X desktop.
The following lists the commands necessary to generate a X configuration for your
system and then start up X:
[root@probe root]# setup_x
Starting xfs:
[ OK ]
Could not find existing X configuration
Writing temporary config file to /tmp/@913.0xf86config
Trying to start X server
Waiting for X server to start...log located in /var/log/XFree86.setup.log
10
1...2...3...4...5....X server started successfully.
Writing configuration to /etc/X11/XF86Config
Removing old /etc/X11/X
Creating /etc/X11/X symlink
X Setup Finished.
You may want to review: /etc/X11/XF86Config
Use the following command to start up X:
startx
[root@probe root]# startx
XFree86 Version 4.3.0 (Red Hat Linux 9 release: 4.3.0-2.90.55)
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF]
Build Date: 12 February 2004
Build Host: porky.devel.redhat.com
Before reporting any problems, please make sure you are using the most
recent XFree86 packages available from Red Hat by checking for updates
at http://rhn.redhat.com/errata or by using the Red Hat Network up2date
tool. If you still encounter problems, please file bug reports in the
XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat
bugzilla at http://bugzilla.redhat.com
Module Loader present
OS Kernel: Linux version 2.4.20-30.9 ([email protected]) (gcc version 3.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Sat Apr 24 15:00:45 2004
(==) Using config file: "/etc/X11/XF86Config"
It should be noted that the setup_x will detect your hardware and display a graphical
selection panel allowing you to specify your X desktop resolution and color depth.
It will then exit after writing the appropriate information to /etc/X11/XF86Config.
You will then be able to bring up X with the startx command.
The following screen shot shows ethereal8, etherape9 and ipsc10 running on a Network Security Toolkit probe running X:
11
Figure 1-8. X Screenshot (Linux Desktop)
The vtwm11 window manager is used when running a X desktop. You can launch X
based applications by right clicking on the desktop to pull up a menu, or by typing
the name of the program you want to run in a xterm window.
The vtwm12 provides virtual desktop space. So, you will only see a portion of the
available desktop displayed on your screen. You should see a small black rectangle
within a larger blue rectangle at the bottom right corner of your screen. If you drag
the small black rectangle around, you can change what portion of the desktop is
visible at any point in time.
Run a X Desktop Remotely (VNC)
If you are familiar with tightvnc13 (it allows for virtual desktops), and you have a
tightvnc14 client for another system on the network, you can use a virtual desktop
to run the software on the Network Security Toolkit probe. The tightvnc15 client
software is freely available for a wide range of Operating Systems - the Windows
version is included on the Network Security Toolkit ISO - you can it from the Web
Interface).
You can start the tightvnc16 server on the Network Security Toolkit probe using the
following script (you may want to examine the script if you don’t like the screen size
and color depth we set):
[root@probe root]# setup_vnc
*** Need to start up a font server on this host...
Starting xfs:
*** Starting a vnc server on display: 6
/usr/local/bin/vncserver :6 -geometry 1280x1024 -depth 24
[
OK
]
New ’X’ desktop is probe:6
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/probe:6.log
*** Xvnc process started:
root
860
1 0 14:40 ttyp0
12
00:00:00 Xvnc :6 -desktop X -httpd /usr/share/vn
120000 -rfbauth /root/.vnc/passwd -rfbport 5906 -pn
[root@probe root]#
Assuming the Network Security Toolkit probe has a IP address of 192.168.0.131,
it is now possible to bring up a virtual desktop from a different system (you could
even use a Windows system if neccessary). Here is an example of what I would type
from my Linux laptop to connect to this virtual desktop:
[root@probe root]# vncviewer 192.168.0.131:6
VNC authentication succeeded
Desktop name "root’s X desktop (probe:6)"
Connected to VNC server, using protocol version 3.3
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
A new window pops up on my laptop providing a full X desktop running on the
Network Security Toolkit probe. You interact with this desktop in the same way as
if you were physically at the Network Security Toolkit probe. One could manage
many Network Security Toolkit probes from a single command system using this
technique.
The following shows a window on my laptop with the desktop of a remote Network
Security Toolkit system. The following screen shows several X based applications
running on the Network Security Toolkit probe (ettercap17, firefox18 and gaim).
Figure 1-9. VNC Screenshot (Linux Desktop)
For the most part, X based applications run at near native speed when using
tightvnc19 on a local network (its pretty amazing). However, over a WAN link
13
(i.e. a relative slower network connection), X based applications that do a lot of
animation (like etherape20) won’t appear to run as smoothly over tightvnc21.
The screenshot shown in Figure 1-10 is a Windows XP Professional desktop with the
Windows’s version of the vncviewer displaying the NST Probe user root’s X desktop
on virtual display: 6.
Figure 1-10. VNC Screenshot (Windows XP Professional Desktop)
Warning
You should avoid runing tightvnc22 sessions across a public network.
The information transmitted across the tightvnc23 is not encrypted. If
you need to run a tightvnc24 session across a public network, you
should read up on SSH tunneling to create a secure communications
channel between the two systems first. Tunneling tightvnc25 traffic
over a SSH link is diagrammed in Figure 8-1.
Changing the Password (nstpasswd)
If you boot the Network Security Toolkit with the default options in a networked
environment and it has the default password it won’t be very secure. This is the
default situation if you use the standard ISO image as everyone else in the world.
So, immediately after logging in, your first order of business should be to set a new
password for your Network Security Toolkit. To do this, you will want to use the
nstpasswd command. This utility sets many different passwords in a single shot. For
14
example, I can change the password to letmein with the following command (the
new password is not echoed):
[root@probe root]# nstpasswd
New NST Password:
Retype new password:
Successfully updated password for ’root’ in /etc/shadow
Successfully updated password for ’root’ in /etc/httpd/conf/htuser.nst
Successfully updated ’authorized_keys’ file for ’root’ and ’vpn’ users
Successfully updated password for ’root’ in /root/.vnc/passwd
Successfully updated password for ’root’ in /etc/samba/smbpasswd
Wed Apr 21 14:21:20 2004 Initializing gdbm databases
Wed Apr 21 14:21:20 2004 Now running as requested user ’ntop’ (100:101)
Wed Apr 21 14:21:20 2004 Admin user password has been set
Successfully updated password for ’admin’ in /var/ntop/ntop_pw.db
[root@probe root]#
Figure 1-11. Changing All of the NST Passwords
As the output above shows, many different passwords on the Network Security
Toolkit probe have been changed to my new setting letmein. From this point on
(until reboot), the new password will be required to gain access via a console, a serial
port, a ssh connection, VNC connections, the Web User Interface (WUI), etc.
If you find the Network Security Toolkit software to be useful, you’ll wish there was
a way to save the password. Unfortunately, we don’t provide this in the default ISO
image (we don’t know how to do it yet). However, expert users are encouraged to
build their own Network Security Toolkit ISO image from the source code (we do
make it easy to set your own unique password if you build from the source).
Text Editors (vim, jed)
You will most likely come across situations where you need access to a text editor.
You will find both vim (for the vi users), and jed (for the emacs users) available.
[root@probe root]# vim ~/.bashrc
# $Id: first_steps.xml,v 1.16.2.1 2004/07/16 13:33:24 rwhalb Exp $
# NST User: root bash shell settings....
# --- ----- ---- ---- ----- -----------# source global definitions...
# ------ ------ -------------if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# set options...
# --- ---------set -o ignoreeof
set -o emacs
# set up LANG env variable...
# --- -- ---- --- ----------export LANG=en_US
export LANGUAGE=en_US
export LC_ALL=en_US
:q!
15
[root@probe root]#
Figure 1-12. Using vim to Edit .bashrc
[root@probe root]# jed /etc/httpd/conf/httpd.conf
F10 key ==> File
Edit
Search
Buffers
Windows
System
Help
# $Id: first_steps.xml,v 1.16.2.1 2004/07/16 13:33:24 rwhalb Exp $
#
# Apache configuration file tweaked for a NST boot system.
#
# Mimics much of the original RedHat 9.0 initial config.
#
# Don’t give away too much information about all the subcomponents
# we are running. Comment out this line if you don’t mind remote sites
# finding out what major optional modules you are running
ServerTokens OS
# ServerRoot: The top of the directory tree under which the server’s
# configuration, error, and log files are kept.
#
# Do NOT add a slash at the end of the directory path.
ServerRoot "/etc/httpd"
#
-------+(Jed 0.99.15) Emacs: httpd.conf
(SH)
1/1037
6:10pm----------------loading
[root@probe root]#
Figure 1-13. Using jed to Edit httpd.conf
Determine or Set the IP Address
If you used the default boot options, the Network Security Toolkit system will request
a IP address from a DHCP server. The following demonstrates how one can use the
ifconfig command to determine the IP address assigned:
[root@probe root]# ifconfig eth0
eth0
Link encap:Ethernet HWaddr 00:50:2C:01:33:04
inet addr:192.168.0.138 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:135 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:23997 (23.4 Kb) TX bytes:11746 (11.4 Kb)
Interrupt:11 Base address:0xe400
[root@probe root]#
Looking at the above output, you can see that the Network Security Toolkit system
was assigned the IP address of 192.168.0.138 by the DHCP server.
If your network does not have a DHCP server, a IP address won’t be assigned automatically, and you’ll need to do it manually.
Note: If your network does not have a DHCP server running, it is recommended that you
boot the Network Security Toolkit by specifying usb at the initial boot screen.
16
The following shows how one can use the cdnet and auto_config_net192 commands
to simplify the process of manually setting a IP address of 192.168.0.211 on a
192.168.0.0/24 network:
[root@probe root]# cdnet
[root@probe network-scripts]# jed nst-eth0.192net
F10 key ==> File
Edit
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.0.211
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
GATEWAY=192.168.0.1
ONBOOT=yes
Search
Buffers
Windows
System
Help
-------+(Jed 0.99.15) Emacs: nst-eth0.192net
(Text) 4/9
3:47pm-----------Wrote 8 lines to /etc/sysconfig/network-scripts/nst-eth0.192net
[root@probe network-scripts]# auto_config_net192
***********************************************************************
*** Net driver detect/module install (phase:2 auto_modprobe_net)... ***
***********************************************************************
*** Installing driver module: "via-rhine" for network device: "VIA Technologies|VT6102
**************************************************************************
*** Configure a 192.168.1.x net on int: eth0 (phase:3 setup_net192)... ***
**************************************************************************
Configured devices:
lo eth0
Currently active devices:
Shutting down loopback interface:
[ OK ]
*** Starting network with eth0 as 192.168.0.211 on network: 192.168.0.0
Setting network parameters:
[ OK ]
Bringing up loopback interface:
[ OK ]
Bringing up interface eth0:
[ OK ]
[root@probe network-scripts]#
Figure 1-14. Setting A IP Address By Hand
If you find this process to be tedious, you should invest in a thumb drive and read
the Automating Your Setup with lnstcustom section.
Automating Your Setup with lnstcustom
This section is intended for those who are familiar with Linux based systems. If you
are just learning Linux, it is recommended that you skip this section for now and
come back to it later when you feel a bit more comfortable at the command line.
After using the Network Security Toolkit for awhile, you’ll find yourself wishing
their was a means to simplify the initialization process. If you have a thumb drive,
flash drive, floppy disk, a hard disk, or even a web server, you are in luck - the lnstcustom command can simplify your setup.
17
It should be noted, that this automation is not completely hands free. You will need
to invoke lnstcustom each time you boot, but you won’t have to type much else.
You need to be familiar with writing bash (or sh) scripts prior to doing much automating. However, the Network Security Toolkit makes an excellent environment to
hone those scripting skills.
Preparing a Thumb Drive for lnstcustom
This section is going to walk you through the creation of a simple setup.sh script
that can be used by lnstcustom to automate the following:
•
Changing the default password.
•
Starting X.
After following these steps, you should be able to boot the Network Security Toolkit,
log in, plug in your thumb drive, and type the following command:
[root@probe root]# lnstcustom test
After typing the above, you should see that the password is being changed, and after
what seems a long time, the X desktop should come up (you will be be presented with
the X configuration utility the first time invoked, but it will remember your settings
for future invocations).
For this example, I’m going to borrow my wife’s Creative Muvo Nomad MP3 player
which also acts as a standard thumb drive (do me a favor and don’t mention this to
my wife). After plugging the MP3 player into a USB port, the following commands
are entered:
[root@probe root]# mount -t vfat /dev/sda1 /mnt/memstick (1)
[root@probe root]# mkdir /mnt/nst/test (2)
[root@probe root]# jed /mnt/nst/test/setup.sh (3)
(1) This mount command will work for many thumb drives, however, you may need
to change the /dev/sda1 or vfat parameters for your thumb drive (Hint: try
"fdisk -l" for clues about the location and file system used on your thumb drive).
(2) This command creates a directory for our "test" customization. This means we
will need to specify test as the first argument to the lnstcustom command when
we want to load this custom configuration (it also means that its easy to make
many different customizations on the same thumb drive - just give each its own
unique directory name).
(3) This line is used to edit the setup.sh script. The commands we put in setup.sh
will be run each time we run the command "lnstcustom test sda1 vfat". The jed
editor was used in this example (I’m partial to the emacs key bindings - but vim
is also available).
Here are the commands we will type into the setup.sh script.
#!/bin/bash
18
printf "letmein\nletmein\n" | nstpasswd (1)
(1)
if [ -f "$NSTHOME/XF86Config" ]; then (2)
cp "$NSTHOME/XF86Config" "/etc/X11"
/etc/rc.d/init.d/xfs start
startx
else (3)
setup_x
if [ -f "/etc/X11/XF86Config" ]; then
(2)
(3)
cp "/etc/X11/XF86Config" "$NSTHOME/"
startx
fi
fi
(1) This line makes use of the printf command to print the word letmein twice
(on two separate lines). This is fed into the nstpasswd command to automate
the changing of the password. Now, I would never recommend setting a real
password to this value or in this fashion (its in plain text on your thumb drive).
However, it is still better (more secure) than having the default password that
comes on the Network Security Toolkit ISO.
(2) This section checks to see if a configuration file for X is already available on the
thumb drive. If it is, it copies it to the proper location, starts the X font server, and
then starts X.
(3) This section is run if a configuration file is needed for X in this case, we invoke
the setup_x command to configure our system, save the configuration created
(so we won’t have to next time), and then start X.
Caution
The above assumes that you will be using the X configuration on the
same system (or another system with identical hardware). NEVER use
a X configuration created for one system on a different system (you
may damage something). If you plan on using the same thumb drive
on different systems, you should create a different directory for each
system, or change the setup.sh script such that it ALWAYS invokes
setup_x before invoking startx.
After saving the file (Control-X Control-S) and leaving the editor (Ctonrol-X ControlC), we will find ourselves back at the command prompt ready to try out the customization.
[root@probe root]# umount /mnt/memstick (1)
[root@probe root]# lnstcustom test sda1 vfat (2)
... Lots of output as passwords are changed and X starts ...
(1) Before trying out our custom setup script we will umount the thumb drive (as it
wouldn’t have been mounted if we just started the system).
(2) We invoke the lnstcustom command specifying the name of the directory that
our setup.sh script can be found under and the device (sda1) and file system
type (vfat) to use to mount it with. It should be noted that the default values
are sda1 and vfat so, in this situation we could have omitted them and simply
specified: lnstcustom test.
This should be enough information to get you started in creating your own customization scripts. You can do a lot if you use your imagination and just keep adding
to your setup.sh script.
Using lnstcustom With a Web Server
Whether you are using lnstcustom with a thumb drive, hard drive, floppy or some
other type of hard disk, the basic concept and preparation is the same. However, if
you want to use the lnstcustom with a web server, there are some differences:
19
•
The entire customization directory must be archived into a single tar.gz file.
•
You won’t be able to easily write any changes back (in the previous example, the
thumb drive was able to "learn" by simply copying a configuration file if the user
adjusted it).
Assuming you still have your thumb drive mounted from the previous session, the
following is all that is required to create and install the custom configuration on a
fictional web server 192.168.0.17:
[root@probe root]# tar czf /tmp/test.tgz -C /mnt/nst test
[root@probe root]# tar tzf /tmp/test.tgz
test/
test/XF86Config
test/setup.sh
[root@probe root]# scp /tmp/test.tgz [email protected]:/var/www/html
Warning: Permanently added ’192.168.0.17’ (RSA) to the list of known hosts.
[email protected]’s password:
test.tgz
100% |*****************************| 1633
00:00
[root@probe root]#
Now that we’ve created and installed our custom setup on a web server, lets try it
out. Let’s reboot the Network Security Toolkit probe, remove the thumbdrive, log
back in, and then invoke lnstcustom in the following manner:
[root@probe root]# lnstcustom test http://192.168.0.17/test.tgz
... Lots of output - X finally comes back up ...
That’s about all there is to it. We now have our custom setup.sh script available on
the network.
Caution
You should be careful when using this method for loading Network Security Toolkit customization scripts. NEVER load someone else’s customization script as you are handing them the keys to your system. You
should also avoid placing any plain text passwords or security sensitive
data in customization scripts placed on the network (as it will probably
be possible for someone to find your files and view them).
Notes
1. http://sourceforge.net/projects/nst
2. http://prdownloads.sourceforge.net/nst/nst-1.0.5.iso.gz?download
3. http://www.networksecuritytoolkit.org/nst/log/manifest-1.0.5.html
4. http://prdownloads.sourceforge.net/nst/nst-1.0.5.iso.gz?download
5. http://www.gzip.org/
6. http://www.winzip.com/
7. http://www.tightvnc.com/
8. http://www.ethereal.com/
9. http://etherape.sourceforge.net
10. http://dag.wieers.com/packages/ipsc/
11. http://www.visi.com/~hawkeyd/vtwm.html
12. http://www.visi.com/~hawkeyd/vtwm.html
20
17. http://ettercap.sourceforge.net/
18. http://www.mozilla.org/products/firefox/
20. http://etherape.sourceforge.net
21
22
Chapter 2. The Web User Interface (WUI)
As Paul grows older, he’s come to the sad realization that his feeble mind can’t possibly keep track of all the powerful tools that are bundled on the Network Security
Toolkit CDROM. To avoid relying on memory alone, a collection of HTML pages and
CGI scripts have been created to aid in the use of the Network Security Toolkit. This
offers Paul a remote chance of making future use of some of the powerful scripts
which Ron has created.
Assuming that you’ve started up the Network Security Toolkit using the default
boot options and that it was assigned the address of 192.168.0.9, you should
be able to access the Web User Interface (WUI) by pointing your browser at
https://192.168.0.9/nstwui. NOTE the usage of https in the preceding URL as
insecure access is not permitted.
Initial Connection
The first time you connect to the Web User Interface (WUI), you will likely need
to respond to one or more dialog boxes. When using firefox1, I typically see the
following set of events:
•
A initial warning dialog indicating that the Network Security Toolkit certificate
could not be verified. This is expected as a test certificate is generated at the time
the CD is created. The warning message presented by the firefox2 browser resembles:
•
After pressing the OK button, the browser typically warns me that the security certificate presented by the Network Security Toolkit probe does not agree with the
actual IP address which the Network Security Toolkit probe has. This is to be expected as we never know what IP address the Network Security Toolkit probe may
be assigned after it boots. The dialog box which the firefox3 browser presents in
this condition resembles:
23
24
•
After pressing this OK button, the browser may want to tell me that I’ve entered
a secure web site. I don’t typically see this message as I typically configure my
browser to disable this type of alert. However, if you don’t have your browser
configured in this manner, you may be presented with a dialog box resembling:
•
Starting with release 1.0.5 of the Network Security Toolkit, authorization will be
required before allowing access to the web server (if you have a older version of the
Network Security Toolkit toolkit authorization won’t be required until you attempt
to access the WUI interface). As a result of this, I will need to authenticate myself
by specifying the appropriate user name and password as shown below:
•
At this point, I’m typically getting tired of pressing OK buttons. Fortunately, I’ve
made it to the actual home page of the Network Security Toolkit. For working
with the Web User Interface (WUI), I then select the NST WUI link from the page
shown below:
•
I’m now able to perform many different actions by clicking my way through the
links found NST Web User Interface shown below:
25
Once you’ve reached the NST Web User Interface, feel free to "click" around and
explore. You can find out a lot of information about the system as well as perform a
variety network security tests.
Snort In Two Clicks
The snort4 package at http://www.snort.org/ is a powerful intrusion detection
package and is included in the Network Security Toolkit distribution. Through a
combination of scripts and HTML pages, you can get snort6 up and running on
your network in two mouse clicks once you’ve reached the WUI.
•
26
In order to bring up snort7, you will first need to click on the Snort link which
appears in the Networking table of the WUI. Look at the row labeled Intrusion
Dectection as shown in the following:
•
To run snort8, you then press the big gray button that says Start Snort as shown
in the screen shot below:
•
That’s all there is to it. After two mouse clicks, snort9 should be starting up on
interface eth0. If things go well, you should be presented with a screen indicat27
ing that snort10 has been started in the background. As the process of starting
up snort11 also requires starting up and initializing the SQL server, it may take a
couple of minutes before its fully ready (especially if you are running it on a old
laptop like me). If you are impatient, you can click the Check Status button like a
monkey gone mad, until it indicates that snort12 is ready and running. The initial
screen shown (prior to pressing the Check Status button) resembles:
It should be noted, that we’ve only looked at starting snort13 with a minimum number of mouse clicks. A skilled reader will take the time to read the instructions shown
on the initial setup page. There you will discover that:
•
You can change what interface snort14 uses. A skilled snort15 user (Ron in my
world) prefers to run snort16 on a dedicated interface.
•
You can choose to download the most recent set of rules from the Internet instead
of using the local copy available on the CD.
•
You can run more than one instance of snort17 if your machine has multiple interfaces.
•
You can specify your own options to snort18 before it starts.
Examining Snort Results
Being able to start snort19 with just a few mouse clicks isn’t all that
impressive if you don’t realize what its doing. Fortunately, the Network
Security Toolkit comes bundled with the snort-utils-acid20 package from
http://www.andrew.cmu.edu/~rdanyliw/snort/.
28
The snort-utils-acid22 package makes it easy to examine the alerts reported by
snort23. The following will take you through the basics and get you started:
•
From the main panel of the Network Security Toolkit WUI, we will again select
the Snort link under the Networking section. Look at the row labeled Intrusion
Dectection as shown in the following:
Note: Here’s a hint for you. If you know that the snort24 database is already setup
and running on your Network Security Toolkit probe, you can go directly to the
snort-utils-acid25 interface by clicking on the ACID link. However, if you click on the
ACID link prior to setting up snort26 it won’t work.
•
Since we’ve already started snort27, there will be several new options available to
us. To access the snort-utils-acid28 interface, we need to click on the big button
labeled ACID Interface For Snort as shown below:
29
30
•
Since this is the first time we’ve attempted to use the snort-utils-acid29 interface, the database will need to be setup. To do this, we need to select the Setup
page link, from the warning page which will appear, to complete the setup process. The page which indicates this, will look similar to:
•
We now need to click on the button labeled Create ACID AG in the web page
which next appears.
•
If things go well (I’ve yet to see this fail), we should see that all of the necessary
tables for the snort-utils-acid30 interface have now been created. We then take
the link to the Main Page, which appears towards the bottom of the screen shot
shown below:
•
Once back at the main page, we will see a report of snort31 alerts which have been
triggered since we started snort32. If you are on a fairly secure local network, you
should see a minimal number of alerts.
31
•
32
If you have snort33 setup on the Network Security Toolkit to monitor your Internet
connection, you will start seeing more and more alerts show up as people come by
"knocking at your doors". If you are impatient, you should be able to make use of
the ShieldsUP! server at http://grc.com/ to trigger some additional alerts. My
firewall does not expose any ports to the Internet, so I don’t get a ton of unwanted
traffic. However, the following shows what snort35 detected over a 13 hour period
while I was working on this document:
•
The above indicated that there were a total of 45 alerts triggered. I then used the
Most frequent 5 Alerts link to see which were the most common. The following screen indicates that most of the activity was related to scanning for my existance (however it also appeared that there were some attempts to spread a WORM
as well):
33
•
34
Since I’m not as knowledgeable in the area of network security as Ron, I have
to admit that I don’t know what half of the problems reported by snort36 really
indicate. So, when I see that there were 35 alerts related to a PING CyberKit 2.2
Windows (as shown in the previous screen shot), I don’t know if I should worry
about it or not. Fortunately, the snort-utils-acid37 interface provides links to
additional information. So, by clicking on the arachNIDS link, a new window is
displayed showing that this alert is related to someone out on the Internet which
is probably using a Windows utility program to scan for computers on the Internet.
•
After closing out the window showing help information about the alert, I then
select the Home link to return to the main page. I’m a bit curious to see if most of the
attacks have originated from the same source IP address. I realize that IP addresses
can be spoofed, however, I imagine its a bit difficult to spoof an IP address at the
scanning stage of an attack. To get this information, I select the source link under
the Most frequent 15 addresses: bullet item. This appears towards the bottom
right in the window shown below:
•
The following screen shot indicates that the scans of my system were not all originating from the same system. Interestingly enough, it appears that a lot of them
35
were coming from the rr.com domain:
•
36
I then select the Home link to return to the main page. I decide to check out some
of the graphing capabilities of snort-utils-acid38, so I select the Graph Alert
Data.
•
The number of options available to the graphing of snort39 alerts can be a bit intimidating. This is what I initially see when I enter the Graph Alert Data page:
37
38
•
Fortunately, the graphing of data is very forgiving. So, for my first attempt, I set
the Chart Type to Time (day) vs. Number of Alerts, the Chart Period to 7
(a week) and fill in the Chart Begin and Chart End times. Once I’m happy with
my choices, I press the button labeled Graph Alerts shown on the screen shot
below:
•
The snort-utils-acid40 interface rewards my efforts by presenting me with a bar
chart showing the number of alerts per day. This is shown in the screen shot below:
•
The bar chart was interesting. I’m still curious about the source IP addresses of the
systems which have been scanning my firewall. I adjust the graphing options to
display this. Notice how the Minimum Threshold Value was set to 3 to limit the
chart to only source IP addresses that scanned my system at least three times:
•
The pie chart presented shows me that there were seven source IP addresses that
scanned my system at least three times. I really like how the key shows the actual
IP address associated with each pie section:
This concludes the "mini tour" of the snort-utils-acid41 interface. We’ve only
touched upon the tip of what can be done, but it should be enough to wet your
appetite.
39
Probing With Nessus
The nessus42 package at http://www.nessus.org/ is nmap44 on steroids. It can detect
the systems on your network and the ports that are open on those systems. Not only
that, it then probes those ports looking for known weaknesses and produces a nice
set of HTML reports. These graphic reports are invaluable when determining what
systems require security patches.
One should be a bit careful before blindly unleashing nessus45 on a network. While
nessus46 is more than happy to probe all of the systems in your network, I’ve found
that some of my systems do not handle the probing very well. My Linux and Windows systems all seem to survive. My LinkSys router also seemed to come through.
However, my wife’s IP phone and a old D-Link router needed to be reset after being probed by nessus47. Also, my networked printer seems to survive the nessus48
probe, but puts out 10 or so pages of garbage each time its probed.
So, in general, I’d recommend that you carefully limit the systems which you probe
on the network. Or, at a minimum, that you turn off your networked printers.
•
In order to bring up nessus49 using the Web User Interface, you will first need to
click on the Nessus link which appears in the Networking table of the WUI. Look
at the row labeled Scan as shown in the following:
Figure 2-1. Selecting nessus
•
Before running a nessus50 scan on the network, you’ll need to start the nessus51
daemon. The WUI provides two options for starting the daemon. If you select the
Start Nessus with Local Plugins, then the scans will include the information available at the time the Network Security Toolkit was built. If you press the Start Nessus with Latest Plugins, the latest set of scanning rules will be downloaded from
the nessus52 web site prior to starting the nessus53 daemon (don’t use this option
if your Network Security Toolkit probe does not have access to the Internet).
Make a decision as to whether you want the Network Security Toolkit to download
the latest nessus54 rules or not and then press one of the two buttons shown below:
40
Figure 2-2. Starting nessus daemon
•
Unfortunately, it takes a bit of time to start the nessus55 daemon. As a result, the
Network Security Toolkit probe will inform you that it is still in the progress of
bringing up the nessus56 daemon. You will need to be patient and periodically hit
your web browser’s refresh button, or click on the here link shown below until the
Network Security Toolkit probe indicates that its ready to run a nessus57 scan:
Figure 2-3. Waiting for nessus daemon to start
41
•
Eventually, you’ll find that after pressing the refresh button enough times, the
nessus58 daemon will eventually be found to be running. At this point, you’ll
be presented with a very simple interface to the nessus59 daemon. By default, it
should already have the IP address of your system filled in. If you only wanted
to scan your system, you could simply press the Start Scan button at this point in
time.
Figure 2-4. nessus ready to scan
•
42
Instead of scanning just my laptop. In this example, I’ve decided to tell nessus60
to scan the systems ranging from 192.168.0.5 to 192.168.0.12. The following shows
how I specified this range of IP addresses and the Start Scan button that needs to
be pressed to begin the scan.
Figure 2-5. nessus ready to scan
•
After pressing the Start Scan button, the Network Security Toolkit probe comes
back indicating what system(s) are being scanned and that it will take a long time.
Once again, I will need to be patient and wait for nessus61 to complete its work.
While waiting, I can click on the refresh link to check on the progress.
Figure 2-6. nessus Scan Starting
43
•
My last press of the refresh button tells me that nessus62 is still in the progress
of running its scan. These scans are very thorough and can take a LONG time
(think lunch). From the snippet shown below, I see that its running tests 107-110 on
192.168.0.12, tests 313-316 on 192.168.0.5, and tests 321-322 on system 192.168.0.11.
I also see that there are 1727 tests total that will be run against all of the systems.
Figure 2-7. nessus Scan Progress
•
44
Finally, a press of the refresh button has yielded something other than a message
telling me that the scan is still in progress. I finally have the results of my nessus63
scan available! With great excitement, I click on the Top link.
Figure 2-8. nessus Scan Complete
•
The Nessus Report tells me that nessus64 found 14 security holes!
45
Figure 2-9. Nessus Report
•
46
I wasn’t too pleased to hear that nessus65 detected 14 security holes on my network. I scrolled to the bottom of the page to find that system 192.168.0.12 had
was responsible for 10 of the security holes. I then click on the link for system
192.168.0.12 to see what security issues were found:
Figure 2-10. Nessus Results, by host
•
After clicking on the link provided by nessus66, I immediately know why there
were so many security holes found by nessus67. System, 192.168.0.12 is my Lexmark 412N laser printer. I forgot to turn it off prior to running the scan! If you’ll
remember back to the start of this section, I clearly stated that it was a bad idea to
let nessus68 scan your networked printers. Sure enough, I forgot to turn mine off
and wasted another 15 sheets of paper. After smacking myself on the forehead, I
decided to see why nessus69 thought it found a security hole at port 80.
47
Figure 2-11. Nessus Finds Hole On Printer Port 80
•
48
It appears that nessus70 was able to aquire the source code for some of the CGI
scripts used by my Lexmark printer. Currently, I don’t worry too much about the
security of this network printer (I rely on a firewall and knowing the users which
have access to it). However, if I were to be paranoid, I might consider searching
for patches, or attaching the printer to a networked Linux box instead of putting it
directly on the LAN.
Figure 2-12. Nessus Reports CGI Source Code Found
This concludes a sample session of using nessus71 from a running Network Security
Toolkit probe. It should be enough to get you started at exploring the weaknesses in
your local network. Hopefully, you will be wise and learn from my mistakes (avoid
scanning your printers).
Traffic Monitoring With bandwidthd72
The bandwidthd73 package at http://bandwidthd.sourceforge.net/ monitors the
amount of traffic being received/transmitted by specific machines and or subnets.
Once a particular machine or subnet has generated enough traffic, bandwidthd75
then provides a graph of traffic associated with the machine or subnet.
•
In order to bring up bandwidthd76 using the Web User Interface, you will first need
to click on the bandwidthd link which appears in the Networking table of the WUI.
Look at the row labeled Monitors as shown in the following:
49
Figure 2-13. Selecting bandwidthd
•
Before starting the bandwidthd77 daemon, one has the option of specifying which
network interface should be monitored as well as any particular subnets which are
to be specifically monitored.
In the setup used in this example, I have my home network connected to the Internet through a firewall/router via NAT. The eth1 interface on my Network Security
Toolkit probe is tapped into the traffic which travels between my router and the cable modem. Because of this arrangement, bandwidthd78 will show all of the traffic
from my home network under the single IP address associated with the Internet
side of my router. Since my entire network will appear as a single IP address, I
don’t have a reason at this point in time in specifying any subnet addresses.
I will need to change the interface from eth0 to eth1 before starting bandwidthd79.
50
Figure 2-14. Setting the bandwidthd Interface
•
Now that I’ve set the interface to eth1, I’m ready to press the Start bandwidthd
button to start the bandwidthd80 daemon:
Figure 2-15. Starting bandwidthd daemon
•
The bandwidthd81 daemon starts up pretty quickly (it only takes a few seconds).
So, I typically give the Network Security Toolkit probe a few seconds to get going
and then press the Check Status button.
51
Figure 2-16. Checking bandwidthd daemon
•
52
If things go well (which they should unless you specify unsupported options), one
should see the screen indicating that bandwidthd82 is running. One can jump to the
bandwidthd83 interface by clicking on the Use bandwidthd interface button.
Figure 2-17. Accessing the bandwidthd Interface
•
When you first bring up the bandwidthd84 interface, you are likely to see a nearly
blank page indicating that “bandwidthd85 is collecting data...” as shown below.
Figure 2-18. bandwidthd Collecting Data
53
•
Eventually, enough time will have pass and bandwidthd86 will display network
traffic information. When a machine or subnet generates enough traffice (think
1MB), bandwidthd87 will provide a link to a graphic chart of the traffic associated
with the machine or subnet. In the page below, I will click on the 65.29.66.13 link
to see what type of traffic was occurring:
Figure 2-19. bandwidthd Traffic Table
Actually, before clicking on the link, I’m going to investigate the 69.44.123.39 IP
address shown in the table. In catches my eye as there was a fair amount of traffic. I
will start my investigation by opening up a ssh connection to my Network Security
Toolkit probe and make use of the whois, host and wget tools:
[root@probe root]# whois 69.44.123.39
Williams Communications, Incorporated WCG-BLK-4 (NET-69-44-0-0-1)
69.44.0.0 - 69.45.255.255
Akamai Technologies WLCO-TWC02103579-AKAMAI-TECH-BROADVIEW (NET-69-44-123-32-1)
69.44.123.32 - 69.44.123.63
# ARIN WHOIS database, last updated 2004-05-29 19:15
# Enter ? for additional hints on searching ARIN’s WHOIS database.
[root@probe root]# host 69.44.123.39
39.123.44.69.in-addr.arpa domain name pointer 69-44-123-39.wcg.net.
[root@probe root]# wget -O - http://wcg.net/
--17:07:32-- http://wcg.net/
=> ‘-’
Connecting to 192.168.0.2:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 127 [text/html]
0% [
] 0
--.--K/s
ETA --:--<HTML>
<HEAD>
<META HTTP-EQUIV="refresh" CONTENT="0; url=http://www.wiltel.com/services/internet/index.html">
</HEAD>
</HTML>
100%[====================================>] 127
17:07:32 (124.02 KB/s) - ‘-’ saved [127/127]
54
124.02K/s
ETA 00:00
[root@probe root]# wget -O - http://www.wiltel.com/
<html>
<head>
<style>
... lots more output ...
</style>
<meta content="WilTel, overview">
<title>WilTel Communications</title>
<style type="text/css">
... lots more output ...
[root@probe root]#
Figure 2-20. Investigating IP 69.44.123.39
The brevity of the whois output made me a bit suspicious (maybe the kids had
infected one of the systems with more Spyware). So, I then tried running the IP
address down to a host that I could access with wget. The output leads me to
believe that this traffic is related to my wife’s IP phone. However, I may keep an
eye on this or further investigate the traffic with a tool like ethereal88 (it seemed
a bit too difficult to get information if it is indeed a real service).
Note: As a followup, I’m less suspicous of this IP address as time goes by. If this site
were related to Spyware, I would expect bandwidthd89 to show traffic to the site on a
continual basis. However, after letting bandwidthd90 run for several hours, I noticed only
the short burst of traffic. This suggests to me that the traffic was triggered by someone
within my house as opposed to a background Spyware process.
•
In looking at the traffic graphs for my home network, I see that most of the traffic
was due to HTTP/TCP traffic. As my younger son had been catching up with the
daily comics while I was getting my screen shots for this part of the document, the
report seemed reasonable.
Figure 2-21. bandwidthd Graph
55
This concludes a sample session of using bandwidthd91 from a running Network Security Toolkit probe. It should be enough to get you started at exploring the traffic in
your local network.
Notes
4. http://www.snort.org/
20. http://www.andrew.cmu.edu/~rdanyliw/snort/
34. http://grc.com/
56
42. http://www.nessus.org/
44. http://www.insecure.org/nmap/
72. http://bandwidthd.sourceforge.net/
57
58
Chapter 3. NST Scripts
The Network Security Toolkit has many useful command line scripts that allow the
network security administrator easy access to the comprehensive set of Open Source
Network Security Tools found in the NST distribution. The section will explore these
scripts and demonstrate their usage with NST.
Network Time Protocol (NTP)
It is extremely important for security related forensic analysis that all data captured
or logged by network infrastructure equipment throughout the enterprise environment be time-stamped using a common reference time synchronization standard.
NST uses NTP1 (the official reference implementation of the NTP protocol - RFC 1305
and RFC 2030) to accomplish this. Prior to running a security related application or
tool, one should startup NTP2. NST is configured by default to use the following time
reference sources ntp1.usno.navy.mil. (192.5.41.41) stratum: 1 and bonehed.lcs.mit.edu.
(18.26.4.105) stratum: 2 to achieve NTP3 time synchonization. Reference clocks and
other NTP4 configuration paramters can be changed in: /etc/ntp.conf.
The following caption shows one how to startup NTP5 and display useful NTP6 status
on a NST probe.
[root@probe root]# /etc/init.d/ntpd start (1)
ntpd: Synchronizing with time server:
Starting ntpd:
[
[
OK
OK
]
]
[root@probe root]# ntpq -p (2)
remote
refid
st t when poll reach
delay
offset jitter
==============================================================================
*ntp1.usno.navy. .USNO.
1 u
33
64
37 170.601
19.034
3.833
+bonehed.lcs.mit NAVOBS1.MIT.EDU 2 u
28
64
37
28.038
14.585
3.469
[root@probe root]# ntptime (3)
ntp_gettime() returns code 0 (OK)
time c486a6d7.3fd7c000 Fri, Jun 25 2004 9:27:51.249, (.249386),
maximum error 549609 us, estimated error 15516 us
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -208.000 us, frequency 124.953 ppm, interval 4 s,
maximum error 549609 us, estimated error 15516 us,
status 0x1 (PLL),
time constant 2, precision 1.000 us, tolerance 512 ppm,
pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
[root@probe root]# ntpdate -dv 192.5.41.41 (4)
14 Jul 08:36:53 ntpdate[5436]: ntpdate [email protected] Thu Feb 13 12:17:20 EST 2003 (1
transmit(192.5.41.41)
receive(192.5.41.41)
transmit(192.5.41.41)
receive(192.5.41.41)
transmit(192.5.41.41)
receive(192.5.41.41)
transmit(192.5.41.41)
receive(192.5.41.41)
transmit(192.5.41.41)
server 192.5.41.41, port 123
stratum 1, precision -19, leap 00, trust 000
refid [USNO], delay 0.26082, dispersion 0.06273
transmitted 4, in filter 4
reference time:
c49fa762.50451398 Wed, Jul 14 2004 8:36:50.313
originate timestamp: c49fa766.e083434e Wed, Jul 14 2004 8:36:54.877
59
transmit timestamp: c49fa766.bc573a79 Wed, Jul 14 2004
filter delay: 0.41434 0.32225 0.29274 0.26082
0.00000 0.00000 0.00000 0.00000
filter offset: -0.09171 -0.05684 -0.03271 0.023662
0.000000 0.000000 0.000000 0.000000
delay 0.26082, dispersion 0.06273
offset 0.023662
8:36:54.735
14 Jul 08:36:54 ntpdate[5436]: adjust time server 192.5.41.41 offset 0.023662 sec
(1) Start up the NTP7 daemon on a NST probe.
(2) Display NTP8 peer status with its reference clocks.
(3) Display time related NTP9 kernel values.
(4) Display the local time offset in verbose mode from NTP10 server 192.5.41.41 using
the ntpdate utility command without any adjustments to the local NST clock.
Note: NST’s Web User Interface found in Chapter 2 can also be used to start up NTP11.
Look under the "System/General" section for "Services" and one can "Start/Stop" the
"ntpd" daemon. One can also check the operational state of the "ntpd" daemon using the
"NTP Info" and "NTP Query" links found under the "Networking/Time" section.
RAM Disk Creation
Many of the applications found within the NST distribution require Read/Write file
system capability. A widely used script for the creation of additional RAM disk based
file systems that satisfies this need was build. The create_ramdisk script will setup a
RAM disk file system up to a default maximum size of 2GigaBytes (NST v1.0.5 and
above).
Warning
When you use the create_ramdisk make sure you have sufficient available RAM for the file system. Use the system utility free to help you
determine information about free and used memory on your system.
The following caption depicts how one uses the create_ramdisk script:
[root@probe root]# /root/bin/create_ramdisk -h
Usage: create_ramdisk [-v] -s <size in MB> -d <RAM device> [-m <mount point>] [-h]
This script creates a user specified RAM disk of size: "-s <size in MB>" using RAM
device: "-d <RAM device>" at a default or user specified mount point
"[-m <mount point>]".
-s <size in MB> | --size <size in MB>
RAM disk size in Mega Bytes (MB).
-d <RAM device> | --ram-device <RAM device>
RAM device to use for this RAM disk. NST will use the corresponding mount points
for the selected RAM device if no user mount point "[-m <mount point>]" is
specified:
/dev/ram2 => Mount point: /mnt/ram2
60
-m <mount point> | --mount-point <mount point>
Optional parameter to specify a mount point directory for the RAM device. If this
parameter is not used, then one of the above default mount points will be used.
Example: -m /data1
-v | --verbose
This optional switch will enable verbose output. Without this switch set, minimal
output from the execution of this script will be displayed.
-h | --help
Displays this help information.
**Notes: 1) If the mount point or the RAM device is already in use, this script will
exit and display a message indicating the reason for exiting.
2) If you unmount or detach the RAM device the Linux Kernel will not free
the allocated memory associated with the RAM device. This can be useful
if one wants to mount this device again: All data will be preserved. If
you need to free the memory back to the Kernel, one can use the "busybox"
command: "busybox freeramdisk <RAM device>". Use the "free" system memory
utility command to check your results.
--------------------------------------------------------------------------------------Example 1: Create a 128MB RAM disk at mount point: "/mnt/ram6" ...
# /root/bin/create_ramdisk -s 128 -d /dev/ram6
Example 2: Unmount and free the memory associated with RAM device: "/dev/ram6" back to
the kernel...
# free
# umount /mnt/ram6
# free
# busybox freeramdisk /dev/ram6
# free
---------------------------------------------------------------------------------------
The following is an example of creating a 128MB file system at mount point: /dev/ram9
using the create_ramdisk script:
[root@probe root]# /root/bin/create_ramdisk -v -s 128 -d /dev/ram9
=============================================================
= Creating a 131072KB RAM disk at mount point: /mnt/ram9... =
=============================================================
*** Zeroing out RAM device: "/dev/ram9"...
/bin/dd if=/dev/zero of=/dev/ram9 bs=1k count=131072
131072+0 records in
131072+0 records out
*** Creating a 131072KB Linux ext2 file system on RAM device: "/dev/ram9"...
/sbin/mke2fs -vm 0 /dev/ram9 131072
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 131072 blocks
61
0 blocks (0.00%) reserved for the super user
First data block=1
16 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
*** Creating RAM disk mount point: "/mnt/ram9"...
*** Mounting RAM disk device: "/dev/ram9" at mount point: "/mnt/ram9"...
/bin/mount -t ext2 /dev/ram9 /mnt/ram9
*** Show all current mounts...
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
none
127024
/dev/cdrom
493856
/dev/ram9
126931
Used Available Use% Mounted on
31152
32309 50% /
0
127024
0% /dev/shm
493856
0 100% /mnt/cdrom
13
126918
1% /mnt/ram9
*** Successfully created a 131072KB RAM Disk: "/dev/ram9" at mount point: "/mnt/ram9"...
Note: If you unmount or detach the RAM disk based file system the Linux Kernel will
not free the allocated memory associated with the RAM device. This can be useful if
one wants to mount this device again: All data will be preserved. If you need to free the
memory back to the Kernel, one can use the busybox command: "busybox freeramdisk
<RAM device>". Use the free system memory utility command to check your results.
MySQL
NST provide an easy and convenient means to setup a MySQL12 database engine.
Once that an initial instance of a MySQL13 database is configured and running,
one can then manage the database engine with extremely flexible tool called
phpMyAdmin14 which is found in Chapter 2.
The setup_mysql script is shown below. It allows for the runtime database engine
to be created and run from a RAM disk or a pre-existing directory. The directory
(i.e. runtime directory) can be a mount point on a locally attached disk drive or a networked file system. This allows for permanent database storage when using NST.
[root@probe root]# /usr/local/bin/setup_mysql -h
Usage: setup_mysql [-s] [-d] [-rd <RAM device>] [-rds <RAM disk size (MB)>]
[-rmp <RAM mount point>] [-rdir <runtime directory>] [-v] [-h]
This script is used to create an initial MySQL multi-user, multi-threaded SQL database
server configuration for a NST system. The default configuration will create a 64MB RAM
disk for the MySQL’s database files at directory location: /mnt/ram4/var/lib/mysql.
The MySQL database server engine will be started by this script.
62
A "root" password will be assigned to the database. Any additional configuration to
the database will be the responsibility of the database administrator.
-s | --stop
Use this optional parameter to stop an already running MySQL database server. If this
option is not used and a MySQL database server is already running, this script will
terminate leaving the existing database server running.
-d | --delete
Use this optional parameter to delete an existing MySQL database directory
structure. This will allow one to startup a new fresh MySQL database.
** Note: This option will destroy any previous database data that may exist. Make any
necessary backups prior to using this option.
-rd <RAM device> | --ram-device <RAM device>
Use this optional parameter to change the default RAM device that will be used for this
instance of the MySQL database data files. Available RAM device names on NST:
"/dev/ram0 - /dev/ram9". A cooresponding mount point: "/mnt/ram0 - /mnt/ram9"
will be automatically selected for the RAM device. One can use the following optional
parameter: "-rmp <mount point>" to change mount point location for the selected RAM
device.
Default: "/dev/ram4"
-rds <RAM dsk size (MB)> | --ram-disk-size <RAM disk
Use this optional parameter to change the default
will be used for MySQL database data files.
Default: "64"
** Note: Use a reasonable value and make sure you
The system memory utility: "free" can be
size (MB)>
RAM disk size in MegaBytes (MB) that
to not exceed your available system RAM.
used to help make your determination.
-rmp <mount point> | --ram-mount-point <mount point>
Use this optional parameter to change the selected RAM device’s: "-rd <RAM device>"
mount point for the MySQL database data files.
Default: "/mnt/ram4"
-rdir <runtime directory> | --runtime-directory <runtime directory>
One can use this optional parameter to force the setup script to use an existing
directory on a locally attached disk drive or a mounted network file system and
bypass the creation of a RAM disk. To do this, make sure the directory initially
exists prior to running this script.
Example:
Mount Point: "/dev/hda1" mount at: "/probe1" type ext3 (rw)
Directory: "/probe1/mysql"
Use: "-rdir /probe1/mysql" to create the top level runtime
directory structure the MySQL database data files.
Directory Structure: mysql => /probe1/mysql/var/lib/mysql
-v | --verbose
-h | --help
Note: This script only configures and starts an initial instance of the MySQL15 database.
It also creates a database administration user: "root" with an assigned password set to
the NST clear text password. The clear text password for user: "root" can be found from
the environment variable: "NSTCTPASSWD" which is generated by sourcing the NST
configuration file: "/etc/nst.conf". No additional user tables or databases are created. Any
configuration beyond this point will be the responsibility of the database administrator.
63
The following example creates a MySQL16 database at the runtime directory location:
"/mnt/ext3/mysql". In this example, the NST probe system has a locally attached disk
drive which was formatted using an Linux Ext3 file system.
[root@probe root]# setup_mysql -rdir /mnt/ext3/mysql -v
*** Creating a new MySQL database file structure at: "/mnt/ext3/mysql/var/lib/mysql"...
*** Starting up the MySQL database server...
Initializing MySQL database:
Starting MySQL:
[
[
OK
OK
]
]
*** Assigning a password for database user: "root"...
*** Successfully started up a MySQL database server...
*** List MySQL Database Directory...
/mnt/ext3/mysql/var/lib:
total 12
drwxr-xr-x
3 root
root
drwxr-xr-x
3 root
root
drwxr-xr-x
4 mysql
mysql
4096 Jun 21 13:01 .
4096 Jun 21 13:01 ..
4096 Jun 21 13:01 mysql
/mnt/ext3/mysql/var/lib/mysql:
total 16
drwxr-xr-x
4 mysql
mysql
drwxr-xr-x
3 root
root
drwx-----2 mysql
mysql
srwxrwxrwx
1 mysql
mysql
drwx-----2 mysql
mysql
4096
4096
4096
0
4096
Jun
Jun
Jun
Jun
Jun
21
21
21
21
21
13:01
13:01
13:01
13:01
13:01
.
..
mysql
mysql.sock
test
/mnt/ext3/mysql/var/lib/mysql/mysql:
total 112
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
4096
4096
8778
0
1024
8982
302
3072
8641
0
1024
8958
0
1024
8877
0
1024
9148
428
2048
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
21
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
13:01
.
..
columns_priv.frm
columns_priv.MYD
columns_priv.MYI
db.frm
db.MYD
db.MYI
func.frm
func.MYD
func.MYI
host.frm
host.MYD
host.MYI
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
user.frm
user.MYD
user.MYI
/mnt/ext3/mysql/var/lib/mysql/test:
total 8
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
4096 Jun 21 13:01 .
4096 Jun 21 13:01 ..
*** List MySQL Processes...
root
902
697 0 13:01 ttyp0
root
965
1 1 13:01 ttyp0
mysql
991
965 1 13:01 ttyp0
64
00:00:00 /bin/bash /usr/local/bin/setup_mysql -rdir /mnt/e
00:00:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc
00:00:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf -
At this point a MySQL17 database engine is up and running and ready for user
database and table creation. Management of the database engine can now proceed
with the phpMyAdmin18 web-based tool found in Chapter 2.
Snort (NST v1.0.4)
Snort19 is a network Intrusion Detection System (IDS) application that analyzes network traffic for matches against user defined rule sets and performs several actions
based upon its network analysis. Snort20 decodes application-layer packet contents,
allowing it to detect thousands of network attack signatures, including such things as
buffer overflows, fragmentation bombs, denial-of-service activity, and stealth scans.
I was inspired by the book: INTRUSION DETECTION with SNORT21 written by
Rafeeq UR Rehman and scripted an Enterprise snort22 solution based on this book. A
federation of NST probe sensors can be quicky setup for IDS using snort23 throughout an enterprise network computing envrionment as shown in Figure 6-5. Most of
the advanced IDS techniques and integration with recommended network applications by Rafeeq: Apache24, MySQL25, PHP26, and ACID27 are automatically setup and
configured for use with a single script.
The setup_snort script found in the "/usr/local/snort" directory is the primary means
to run snort28 on a NST probe system. NST’s Web interface found in Chapter 2 can
also be used to launch this script. Information on how to start snort29 via a Web user
interface can be found in the Section called Snort In Two Clicks in Chapter 2.
The help information for the Snort30 setup script is shown below:
[root@probe root]# /usr/local/snort/setup_snort -h
Usage: setup_snort -r <local | remote [-rs <URL: rules site]> [-h] [-i <interface>]
[-d <database hostname>] [-p <database port>] [-c] [-s <sensor name>]
[-a <full | fast>]
This script is used to setup an instance of the Snort Network Intrusion Detection System (IDS)
on a NST probe system. A Snort session can be used with a configured interface [-i <interface>
and all associated alert and log events redirected to a MySQL database on host
[-d <database name>]. A 64Mb RAM Disk will be created at mount point: /mnt/ram4 for MySQL
and Snort data files. If the database hostname [-d <database name>] is "localhost"
(i.e. the default value), a MySQL database server will be configured and started up
on this NST probe system for immediate Snort usage.
This script can also be used to setup and run a MySQL database for the collection of remote
Snort alert events and log information only (see the [-c] parameter below).
-r <local | remote> | --rules <local | remote>
The rules parameter is require for determining which Snort rule
set source to use:
local - copy the rules that came with the NST distribution to the
read/write directory: /mnt/ram4/snort/rules. Use these if
one does not have access to the internet.
remote - use "wget" to update the latest snort rules from default site:
http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz
-rs <URL: rules site> | --rules-site <URL: rules site>
Optional setting to change the default location of the remote "-r" rule site. Use
a URL formatted site name for the alternate snort rules site.
-h | --help
Displays this help information
-i <interface name> | --interface <interface name>
Interface name for which Snort will perform intrusion detection: Ex: "eth1".
65
Default: "eth0"
-d <database hostname> | --db_hostname <database hostname>
This parameter sets the MySQL database hostname for alert events and log information
collection. It can be either an IP address or a name resolved through the "/etc/hosts"
file or DNS.
** Note: If the name of the database hostname is resolved to a remote host, a MySQL
database instance will not be started on this NST probe system.
Default: "localhost"
-p <database port> | --db_port <database port>
This sets the database port number that the MySQL server is listening on.
Default: "3306"
-c | --collector_mode
This parameter is used to setup a MySQL database for the collection of remote Snort
IDS probe’s alert events and log information. This parameter is useful when setting up
an IDS architecture consisting of a federation of Snort probe sensors with a backend
MySQL server.
-s <sensor name> | --sensor_name <sensor name>
Use this parameter to identify the sensor name used by this Snort instance. This is useful
when many Snort sensors are logging to the same MySQL database. It will be easier to
distinguish between multiple sensors when using the ACID tool for viewing alert
and logged events.
** Note: Do not use spaces within the <sensor name> Ex: "Sensor 1" => "Sensor_1"
Default: "IP address of probe interface: eth0"
-a <full | fast> | --alert_detail <full | fast>
Used to set the detail of Snort alert and log events to the data base.
full - All alert information for an event will be logged.
fast - An abbreviated version of the alert event will be logged.
Default: "full"
An example of using this script with NST will be based upon the small business network configuration shown in Figure 6-4. We will be using network interface "eth2" in
stealth mode (i.e. no IP address bound to the network interface) as the probe monitor
sensor interface. In this example network interface "eth2" is attached to a network
"Hub" and all traffic on the "dirty side" of the Internet connection (i.e. Internet side of
the firewall with respect to the small business network) will been seen. This particular NST probe is configured with 3 10/100 NICs. The "ifconfig -a" command reveals
the following:
[root@probe root]# ifconfig -a
66
eth0
Link encap:Ethernet HWaddr 00:54:BD:14:93:12
RX bytes:2756634 (2.6 Mb) TX bytes:139064 (135.8 Kb)
Interrupt:10 Base address:0x7800
eth1
Link encap:Ethernet HWaddr 00:40:05:89:E8:03
BROADCAST MULTICAST MTU:1500 Metric:1
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:3 Base address:0x9c00
eth2
Link encap:Ethernet
HWaddr 00:04:75:A1:EF:AB
RX bytes:4831006 (4.6 Mb) TX bytes:60 (60.0 b)
Interrupt:9 Base address:0xdc00
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
The script will be started by obtaining up to date remote rules from the
"www.snort.org" site (this implies internet connectivity to the NST probe system).
The NST probe system will be labeled with a sensor name: "FW-Dirty" and full
snort31 details will be generated. Below is the command-line script execution for
this IDS snort32 example:
[root@probe root]# /usr/local/snort/setup_snort -r remote -i eth2 -s "FW-Dirty" -a full
============================================================
============================================================
*** Zeroing out RAM device: /dev/ram4
65536+0 records in
65536+0 records out
*** Create a 65536KB Linux ext2 file system on RAM device: /dev/ram4
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
First data block=1
8 block groups
8193, 24577, 40961, 57345
*** Mounting RAM disk device: /dev/ram4 at mount point: /mnt/ram4
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
none
94704
/dev/cdrom
479712
/dev/ram4
63461
31168
32293 50% /
0
94704
0% /dev/shm
479712
0 100% /mnt/cdrom
13
63448
1% /mnt/ram4
67
*** USING REMOTE SNORT RULES DEFINITIONS ***
*** Fetching the latest Snort rule definitions from: "http://www.snort.org/dl/rules/snortrules-sn
--21:31:27-- http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz
=> ‘snortrules-snapshot-2_1.tar.gz’
Resolving www.snort.org... done.
Connecting to www.snort.org[199.107.65.177]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 130,764 [application/x-gzip]
100%[==================================================================>] 130,764
21:31:27 (336.94 KB/s) - ‘snortrules-snapshot-2_1.tar.gz’ saved [130764/130764]
rules/
rules/classification.config
rules/generators
rules/gen-msg.map
rules/reference.config
rules/sid
rules/sid-msg.map
rules/snort.conf
rules/threshold.conf
rules/unicode.map
rules/attack-responses.rules
rules/backdoor.rules
rules/bad-traffic.rules
rules/cgi-bin.list
rules/chat.rules
rules/ddos.rules
rules/deleted.rules
rules/dns.rules
rules/dos.rules
rules/experimental.rules
rules/exploit.rules
rules/finger.rules
rules/ftp.rules
rules/icmp-info.rules
rules/icmp.rules
rules/imap.rules
rules/info.rules
rules/local.rules
rules/misc.rules
rules/multimedia.rules
rules/mysql.rules
rules/netbios.rules
rules/nntp.rules
rules/oracle.rules
rules/other-ids.rules
rules/p2p.rules
rules/policy.rules
rules/pop2.rules
rules/pop3.rules
rules/porn.rules
rules/rpc.rules
rules/rservices.rules
rules/scan.rules
rules/shellcode.rules
rules/smtp.rules
rules/snmp.rules
rules/sql.rules
rules/telnet.rules
rules/tftp.rules
rules/virus.rules
68
336.94K/s
rules/web-attacks.rules
rules/web-cgi.rules
rules/web-client.rules
rules/web-coldfusion.rules
rules/web-frontpage.rules
rules/web-iis.rules
rules/web-misc.rules
rules/web-php.rules
rules/x11.rules
*** Setup the MySQL Server...
/root/bin/setup_mysql
============================================================
============================================================
### This script is exiting -- a ram disk on device: /dev/ram4 already exists!!!
### (mount):
/dev/ram4 on /mnt/ram4 type ext2 (rw)
### (df -k):
Filesystem
/dev/ram
none
/dev/cdrom
/dev/ram4
1K-blocks
63461
94704
479712
63461
31406
32055 50% /
0
94704
0% /dev/shm
479712
0 100% /mnt/cdrom
1290
62171
3% /mnt/ram4
Starting MySQL:
[
[
OK
OK
]
]
/mnt/ram4/var/lib:
total 3
drwxr-xr-x
3 root
root
drwxr-xr-x
3 root
root
drwxr-xr-x
4 mysql
mysql
1024 Mar 11 21:31 .
1024 Mar 11 21:31 ..
1024 Mar 11 21:31 mysql
/mnt/ram4/var/lib/mysql:
total 4
drwxr-xr-x
4 mysql
drwxr-xr-x
3 root
drwx-----2 mysql
srwxrwxrwx
1 mysql
drwx-----2 mysql
mysql
root
mysql
mysql
mysql
1024
1024
1024
0
1024
Mar
Mar
Mar
Mar
Mar
11
11
11
11
11
21:31
21:31
21:31
21:31
21:31
.
..
mysql
mysql.sock
test
/mnt/ram4/var/lib/mysql/mysql:
total 67
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
1024
1024
8778
0
1024
8982
302
3072
8641
0
1024
8958
0
1024
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
11
11
11
11
11
11
11
11
11
11
11
11
11
11
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
21:31
.
..
columns_priv.frm
columns_priv.MYD
columns_priv.MYI
db.frm
db.MYD
db.MYI
func.frm
func.MYD
func.MYI
host.frm
host.MYD
host.MYI
69
-rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----
1
1
1
1
1
1
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
/mnt/ram4/var/lib/mysql/test:
total 2
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
root
5385 5318 0 21:31 ttyp0
root
5462
1 0 21:31 ttyp0
mysql
5487 5462 0 21:31 ttyp0
8877
0
1024
9148
428
2048
Mar
Mar
Mar
Mar
Mar
Mar
11
11
11
11
11
11
21:31
21:31
21:31
21:31
21:31
21:31
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
user.frm
user.MYD
user.MYI
1024 Mar 11 21:31 .
1024 Mar 11 21:31 ..
00:00:00 /bin/bash /root/bin/setup_mysql
00:00:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc
00:00:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf -
*** Initialize Snort MySQL databases...
/usr/local/bin/mysql -u root -p****** < /usr/local/snort/snort_mysql
-------------/usr/local/bin/mysql Ver 11.18 Distrib 3.23.58, for redhat-linux-gnu (i386)
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
Client characterset:
Server characterset:
UNIX socket:
Uptime:
2
snort
root@localhost
stdout
”
3.23.58
10
Localhost via UNIX socket
latin1
latin1
/var/lib/mysql/mysql.sock
4 sec
Threads: 1 Questions: 6
--------------------------/usr/local/bin/mysql
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
Slow queries: 0
Opens: 7
Flush tables: 1
Open tables: 1 Queries per
Ver 11.18 Distrib 3.23.58, for redhat-linux-gnu (i386)
2
snort_archive
root@localhost
stdout
”
3.23.58
10
latin1
latin1
4 sec
--------------
Slow queries: 0
Opens: 8
Flush tables: 1
*** Initialize the base Snort MySQL database tables...
/usr/local/bin/mysql -u snort -p****** snort < /usr/local/snort/contrib/create_mysql
*** Create the extra Snort MySQL database tables and entries...
/bin/zcat /usr/local/snort/contrib/snortdb-extra.gz | /usr/local/bin/mysql -u snort -p****** snor
*** Initialize the Snort Archive database tables...
70
/usr/local/bin/mysql -u snort -p****** snort_archive < /usr/local/snort/contrib/create_mysql
*** Test for proper MySQL database setup for Snort...
List Snort database status and service entries: (ports: between 20 and 30)...
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
6
snort
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
50 sec
--------------
Slow queries: 0
Opens: 52
Flush tables: 1
Open tables: 11 Queri
port
protocol
name
description
21
6
ftp
File Transfer [Control]
21
17
ftp
22
6
Unassigned
22
17
Unassigned
23
6
telnet Telnet
23
17
telnet Telnet
24
6
Unassigned
24
17
Unassigned
25
6
smtp
Simple Mail Transfer
25
17
smtp
26
6
Unassigned
26
17
Unassigned
27
6
nsw-fe NSW User System FE
27
17
28
6
Unassigned
28
17
Unassigned
29
6
msg-icp MSG ICP
29
17
msg-icp MSG ICP
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
6
snort_archive
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
51 sec
--------------
Slow queries: 0
Opens: 52
Flush tables: 1
Tables_in_snort_archive
data
detail
encoding
event
71
icmphdr
iphdr
opt
reference
reference_system
schema
sensor
sig_class
sig_reference
signature
tcphdr
udphdr
*** Setting up ACID for snort...
/bin/tar -xzf /usr/local/snort/snort-utils/ACID/acid-0.9.6b23.tar.gz
*** Setting up snort utility programs: ADODB and JPGRAPH...
*** Installing: ADODB...
/bin/tar -xzf /usr/local/snort/snort-utils/ADODB/adodb410.tgz
*** Installing: JPGRAPH...
/bin/tar -xzf /usr/local/snort/snort-utils/JPGRAPH/jpgraph-1.13.tar.gz
*** Editing ACID config file: "acid_conf.php"...
*** Display Disk Usage: df
Filesystem
1K-blocks
/dev/ram
63461
none
94704
/dev/cdrom
479712
/dev/ram4
63461
31416
32045 50% /
0
94704
0% /dev/shm
479712
0 100% /mnt/cdrom
16142
47319 26% /mnt/ram4
*** Snort config files: "/etc/snort_eth2"...
total 241
drwxr-xr-x
2 root
root
1024 Mar
drwxr-xr-x
42 root
root
3072 Mar
-rw-r--r-1 root
root
3521 Mar
-rw-r--r-1 root
root
1622 Mar
-rw-r--r-1 root
root
6799 Mar
-rw-r--r-1 root
root
608 Mar
-rw-rw-r-1 root
root
59 Mar
-rw-rw-r-1 root
root
145450 Mar
-rw-rw-r-1 root
root
22834 Mar
-rw-r--r-1 root
root
53841 Mar
11
11
11
11
11
11
11
11
11
11
21:31
21:31
21:15
21:15
21:15
21:15
21:15
21:15
21:31
21:15
.
..
classification.config
generators
gen-msg.map
reference.config
sid
sid-msg.map
snort.conf
unicode.map
*** Snort setup complete...
... A SNORT CONFIGURATION INSTANCE FOR INTERFACE: eth2 ...
**************************************************************
**************************************************************
***
Snort Version: 2.1.1-1
***
Snort MySQL Version: 2.1.1-1
***
Snort Utility ACID Version: 0.9.6b23
***
Snort Utility ADODB Version: 410
*** Snort Utility JPGraph Version: 1.13
***
Snort Execution Directory: /mnt/ram4/snort
***
Snort Configuration File: /etc/snort_eth2/snort.conf
***
Snort Rules Directory: /mnt/ram4/snort/rules
***
MySQL Database Hostname: localhost
***
MySQL Database Port: 3306
***
Snort IDS Interface: eth2
***
Snort IDS Sensor Name: FW-Dirty
*** Snort Alert Event Logging Mode: full
**************************************************************
72
**************************************************************
---- To run snort on interface: eth2 ---# cd /mnt/ram4/snort
# ifconfig eth2 up
# ./snort -c /etc/snort_eth2/snort.conf &
Each step in the setup process for the NST snort33 implementation is described in
the above caption. One can see the following: (1) creation of a 64MB RAM disk
for snort34 data files and the MySQL database; (2) remote rule set download from
"http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz"; (3) creation of a MySQL
database instance for logging snort35 alerts, events, extra tables, and archiving; (4)
MySQL database testing; (5) Analysis Console for Intrusion Databases (ACID) setup;
(6) snort36 utility Active Data Objects Data Base (ADODB) setup; (7) Object-Oriented
(OO) graphics class library JPGRAPH setup; and (8) a summary section with commands to execute for running the configured snort37 setup.
In the next caption we will show the results of starting up a snort38 instance on
network interface "eth2". The following commands to start snort39 are shown below:
[root@probe root]# cd /mnt/ram4/snort
[root@probe snort]# ifconfig eth2 up
[root@probe snort]# ./snort -c /etc/snort_eth2/snort.conf &
[1] 5355
[root@probe snort]# Running in IDS mode
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==-Initializing Output Plugins!
Decoding Ethernet on interface eth0
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /etc/snort_eth2/snort.conf
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
Found logdir config directive (/mnt/ram4/snort/logs)
OpenPcap() device eth2 network lookup:
eth2: no IPv4 address assigned
,-----------[Flow Config]---------------------| Stats Interval: 0
| Hash Method:
2
| Memcap:
10485760
| Rows :
4099
| Overhead Bytes: 16400(%0.16)
‘---------------------------------------------No arguments to frag2 directive, setting defaults to:
Fragment timeout: 60 seconds
Fragment memory cap: 4194304 bytes
Fragment min_ttl:
0
Fragment ttl_limit: 5
Fragment Problems: 0
Self preservation threshold: 500
Self preservation period: 90
Suspend threshold: 1000
Suspend period: 30
Stream4 config:
Stateful inspection: ACTIVE
73
Session statistics: INACTIVE
Session timeout: 30 seconds
Session memory cap: 8388608 bytes
State alerts: INACTIVE
Evasion alerts: INACTIVE
Scan alerts: INACTIVE
Log Flushed Streams: INACTIVE
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Suspend period: 30
Stream4_reassemble config:
Server reassembly: INACTIVE
Client reassembly: ACTIVE
Reassembler alerts: ACTIVE
Zero out flushed packets: INACTIVE
flush_data_diff_size: 500
Ports: 21 23 25 53 80 110 111 143 513 1433
Emergency Ports: 21 23 25 53 80 110 111 143 513 1433
HttpInspect Config:
GLOBAL CONFIG
Max Pipeline Requests:
0
Inspection Type:
STATELESS
Detect Proxy Usage:
NO
IIS Unicode Map Filename: /etc/snort_eth2/unicode.map
IIS Unicode Map Codepage: 1252
DEFAULT SERVER CONFIG:
Ports: 80 8080 8180
Flow Depth: 300
Max Chunk Length: 500000
Inspect Pipeline Requests: YES
URI Discovery Strict Mode: NO
Allow Proxy Usage: NO
Disable Alerting: NO
Oversize Dir Length: 500
Only inspect URI: NO
Ascii: YES alert: NO
Double Decoding: YES alert: YES
%U Encoding: YES alert: YES
Bare Byte: YES alert: YES
Base36: OFF
UTF 8: OFF
IIS Unicode: YES alert: YES
Multiple Slash: YES alert: NO
IIS Backslash: YES alert: NO
Directory: YES alert: NO
Apache WhiteSpace: YES alert: YES
IIS Delimiter: YES alert: YES
IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG
Non-RFC Compliant Characters: NONE
rpc_decode arguments:
Ports to decode RPC on: 111 32771
alert_fragments: INACTIVE
alert_large_fragments: ACTIVE
alert_incomplete: ACTIVE
alert_multiple_requests: ACTIVE
telnet_decode arguments:
Ports to decode telnet on: 21 23 25 119
database: compiled support for ( mysql )
database: configured to use mysql
database:
user = snort
database: password is set
74
database: database name = snort
database:
host = localhost
database:
port = 3306
database:
sensor name = FW-Dirty
database: detail level = full
database:
sensor id = 1
database: schema version = 106
database: using the "alert" facility
1652 Snort rules read...
1652 Option Chains linked into 152 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
+-----------------------[thresholding-config]---------------------------------| memory-cap : 1048576 bytes
+-----------------------[thresholding-global]---------------------------------| none
+-----------------------[thresholding-local]----------------------------------| gen-id=1
sig-id=2275
type=Threshold tracking=dst count=5
seconds=60
+-----------------------[suppression]-----------------------------------------------------------------------------------------------------------------------Rule application order: ->activation->dynamic->alert->pass->log
--== Initialization Complete ==--*> Snort! <*Version 2.1.1 (Build 24)
By Martin Roesch ([email protected], www.snort.org)
As this point snort40 is up and running on stealth network interface "eth2". One
needs to proceed to the Section called Examining Snort Results in Chapter 2 and use
ACID41 for monitoring any network intrusion traffic activity.
Snort (NST v1.0.5 and Above)
Snort42 is a network Intrusion Detection System (IDS) application that analyzes network traffic for matches against user defined rule sets and performs several actions
based upon its network analysis. Snort43 decodes application-layer packet contents,
allowing it to detect thousands of network attack signatures, including such things as
buffer overflows, fragmentation bombs, denial-of-service activity, and stealth scans.
I was inspired by the book: INTRUSION DETECTION with SNORT44 written by
Rafeeq UR Rehman and scripted an Enterprise snort45 solution based on this book. A
federation of NST probe sensors can be quicky setup for IDS using snort46 throughout an enterprise network computing envrionment as shown in Figure 6-5. Most of
the advanced IDS techniques and integration with recommended network applications by Rafeeq: Apache47, MySQL48, PHP49, and ACID50 are automatically setup and
configured for use with a single script.
The setup_snort script found in the "/usr/local/snort" directory is the primary means
to run snort51 on a NST probe system. NST’s Web User Interface found in Chapter 2
can also be used to launch this script. Information on how to start snort52 via a Web
user interface can be found in the Section called Snort In Two Clicks in Chapter 2.
There are 3 operational "setup_snort" modes that one can chose with this script.
1. This mode ("-r") sets up a standalone Snort instance with local MySQL
database and ACID (Analysis Console for Intrusion Databases) support.
2. This mode ("-r" and "-d") sets up a standalone Snort instance and uses a remote
MySQL database engine for archiving and requesting Snort IDS events.
75
3. This mode ("-c") creates a "collector" for remote Snort security and alert incident archiving. An enterprise configuration of remote Snort sensors can be
deployed with the "collector" serving as a backend Snort database engine and
console access to security incidents for the network security administrator using ACID53. Permanent storage for Snort incidents can be sent to local hard
disk or a networked file system.
Note: If a NST probe was originally configured as a Snort "collector" only, one can add
Snort IDS capability to the probe by ruuning the "setup_snort" script a second time with
the operational mode one setting described above. The MySQL54 database engine associated with the Snort "collector" operation will be automatically detected and used.
The help information for the Snort55 setup script: /usr/local/snort/setup_snort
is shown below:
[root@probe root]# /usr/local/snort/setup_snort -h
Usage: setup_snort -r <local | remote [-rs <URL: rules site]> [-i <interface>]
[-d <database hostname>] [-p <database port>] [-s <sensor name>]
[-a <full | fast>] [-rd <RAM device>] [-rds <RAM disk size (MB)>]
setup_snort -c [-rd <RAM device>] [-rds <RAM disk size (MB)>]
The first form of this script "[-r]" is used to setup an instance of the Snort Network
Intrusion Detection System (IDS) on a NST probe system. A Snort session can be used with
any configured interface [-i <interface>] and all associated alert and log events redirected
to a MySQL database server on host [-d <database name>]. The default setting is to create a
64MB RAM Disk at mount point: "/mnt/ram4" for MySQL, ACID, and Snort data files.
If the database hostname [-d <database name>] is "localhost" (i.e. the default value), a MySQL
database server will be configured and started on this NST probe system for immediate Snort
usage. The PHP-based analysis engine: ACID (Analysis Console for Intrusion Databases) will
also be configured to search and process the MySQL database for security incidents generated
by Snort. End user access to ACID is via the Apache Web Server. One needs to make sure that
an instance of Apache is running on the NST probe system for access to ACID generated
Web pages. The following are 2 examples on how to get access to the ACID Web interface:
Example 1: Local Access (IP Address "localhost": 127.0.0.1)
NST probe running Snort, MySQL, and ACID
Interface: "Firefox" browser using X Windows or VNC client, or the "elinks" browser
using the console or a SSH session.
URL: http://127.0.0.1/acid
Example 2: Remote Access (IP Address of NST Probe running Snort, MySQL, and ACID: 10.21.33.44)
Interface: Any Web browser that supports SSL
URL: https://10.21.33.44/acid
The second form of this script "[-c]" can also be used to setup and run a backend MySQL
database server engine taylored with the ACID analysis engine for the collection of remote
Snort security incidents and log information (see the [-c] parameter below). A federation
of remote Snort IDS probes can populated throughout a Enterprise network computing
evironment and be configured to send any security incidents and log information to
this database server.
-r <local | remote> | --rules <local | remote>
The rules parameter is require for determining which Snort rule
set source to use:
local - a copy of the rules that came with the NST distribution will be
transferred to read/write Snort runtime directory. Use these
method if one does not have access to the internet.
76
remote - use "wget" to update the latest Snort rules from default site:
http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz
-rs <URL: rules site> | --rules-site <URL: rules site>
Optional setting to change the default location of the remote "-r" rule site. Use
a URL formatted site name for the alternate Snort rules site.
-i <interface name> | --interface <interface name>
Interface name for which Snort will perform intrusion detection: Ex: "eth1".
Default: "eth0"
-d <database hostname> | --db_hostname <database hostname>
This parameter sets the MySQL database hostname for alert events and log information
collection. It can be either an IP address or a name resolved through the naming
service "/etc/hosts" file or DNS.
** Note: If the name of the database hostname is resolved to a remote host, a MySQL
database instance will not be started on this NST probe system.
Default: "localhost"
-p <database port> | --db_port <database port>
This sets the database port number that the MySQL server is listening on.
Default: "3306"
-c | --collector_mode
This parameter is used to setup a MySQL database for the collection of remote Snort
IDS probe’s security alert events and log information. This parameter is useful when
setting up an IDS architecture consisting of a federation of Snort probe sensors with
a backend MySQL server and ACID analysis engine.
-s <sensor name> | --sensor_name <sensor name>
Use this parameter to identify the sensor name used by this Snort instance. This is useful
when many Snort sensors are logging to the same MySQL database. It will be easier to
distinguish between multiple sensors when using the ACID tool for viewing alert
and logged events.
** Note: Do not use spaces within the <sensor name> Ex: "Sensor 1" => "Sensor_1"
Default: "IP address of probe interface: eth0"
-a <full | fast> | --alert_detail <full | fast>
Used to set the detail of Snort alert and log events to the data base.
full - All alert information for an event will be logged.
fast - An abbreviated version of the alert event will be logged.
Default: "full"
Use this optional parameter to change the default RAM device that will be used for this
instance of Snort, the associated MySQL database, and ACID data files. Available RAM
device names on NST: "/dev/ram0 - /dev/ram9". A cooresponding mount point:
"/mnt/ram0 - /mnt/ram9" will be automatically selected for the RAM device. One can
use the following optional parameter: "-rmp <mount point>" to change mount point location
for the selected RAM device.
-rds <RAM dsk size (MB)> | --ram-disk-size <RAM disk size (MB)>
Use this optional parameter to change the default RAM disk size in MegaBytes (MB) that
will be used for this instance of Snort, the associated MySQL database, and ACID data
files.
Default: "64"
** Note: Use a reasonable value and make sure you to not exceed your available system RAM.
The system memory utility: "free" can be used to help make your determination.
Use this optional parameter to change the selected RAM device’s: "-rd <RAM device>"
mount point for this instance of Snort, the associated MySQL database, and ACID
data files.
77
One can use this optional parameter to force the "setup_snort" script to use an
existing directory on a locally attached disk drive or a mounted network file system and
bypass the creation of a RAM disk. To do this, make sure the directory initially exists
prior to running this script.
Example:
Mount Point: "/dev/hdc1" mount at: "/probe1" type ext3 (rw)
Directory: "/probe1/snort"
Use: "-rdir /probe1/snort" to create the top level runtime
directory structure for this instance of Snort, the
associated MySQL database, and ACID data files.
Directory Structure: Snort
=> /probe1/snort/snort
mysql
=> /probe1/snort/var/lib/mysql
www(ACID)
=> /probe1/snort/var/www/html/acid
-v | --verbose
-h | --help
Setup Snort Example: Standalone Configuration
We will now demonstrate a standalone snort56 configuration using this script with
NST. It will be based upon the small business network configuration shown in Figure
6-4. We will be using network interface "eth2" in stealth mode (i.e. no IP address
bound to the network interface) as the probe monitor sensor interface. In this example
network interface "eth2" is attached to a network "Hub" and all traffic on the "dirty
side" of the Internet connection (i.e. Internet side of the firewall with respect to the
small business network) will been seen. This particular NST probe is configured with
3 10/100 NICs. The "ifconfig -a" command reveals the following:
[root@probe root]# ifconfig -a
78
eth0
Link encap:Ethernet HWaddr 00:54:BD:14:93:12
eth1
Link encap:Ethernet HWaddr 00:40:05:89:E8:03
BROADCAST MULTICAST MTU:1500 Metric:1
Interrupt:3 Base address:0x9c00
eth2
Link encap:Ethernet HWaddr 00:04:75:A1:EF:AB
RX bytes:4831006 (4.6 Mb) TX bytes:60 (60.0 b)
lo
inet addr:127.0.0.1 Mask:255.0.0.0
The script will be started by obtaining up to date remote rules from the
"www.snort.org" site (this implies internet connectivity to the NST probe system).
The NST probe system will be labeled with a sensor name: "FW-Dirty" and full
snort57 details will be generated. A 128MB RAM disk will be created using the
default RAM device: "/dev/ram4" at mount point: "/mnt/ram4". Since this is a
standalone setup, a MySQL58 database engine will also be configured and started
for this snort59 instance. Below is the command-line script execution for this IDS
snort60 example:
[root@probe root]# /usr/local/snort/setup_snort -r remote -i eth2 -s "FW-Dirty" -a full -
*** Creating a 128MByte RAM disk at mount point: "/mnt/ram4"... (1)
/root/bin/create_ramdisk -s 128 -d /dev/ram4 -m /mnt/ram4 -v
============================================================
============================================================
131072+0 records in
131072+0 records out
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
First data block=1
16 block groups
8193, 24577, 40961, 57345, 73729
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
none
256892
/dev/cdrom
493888
/dev/ram4
126931
31218
32243 50% /
0
256892
0% /dev/shm
493888
0 100% /mnt/cdrom
13
126918
1% /mnt/ram4
*** Successfully created a 131072KB RAM Disk: "/dev/ram4" at mount point: "/mnt/ram4"..
79
*** Using remote Snort rules definitions... (2)
*** Fetching the latest Snort rule definitions from: "http://www.snort.org/dl/rules/sno
/usr/local/bin/wget http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz
100%[==================================================================>] 141,307
rules/
rules/generators
rules/gen-msg.map
rules/sid
rules/sid-msg.map
rules/snort.conf
rules/unicode.map
rules/cgi-bin.list
rules/chat.rules
rules/ddos.rules
rules/deleted.rules
rules/dns.rules
rules/dos.rules
rules/exploit.rules
rules/finger.rules
rules/ftp.rules
rules/icmp.rules
rules/imap.rules
rules/info.rules
rules/local.rules
rules/misc.rules
rules/mysql.rules
rules/netbios.rules
rules/nntp.rules
rules/oracle.rules
rules/p2p.rules
rules/policy.rules
rules/pop2.rules
rules/pop3.rules
rules/porn.rules
rules/rpc.rules
rules/scan.rules
rules/smtp.rules
rules/snmp.rules
rules/sql.rules
rules/telnet.rules
rules/tftp.rules
rules/virus.rules
80
rules/web-cgi.rules
rules/web-iis.rules
rules/web-php.rules
rules/x11.rules
*** Setup the MySQL Server... (3)
/root/bin/setup_mysql -rd /dev/ram4 -rds 128 -rmp /mnt/ram4 -v
*** Creating a 128MByte RAM disk at mount point: "/mnt/ram4"...
*** Mount point: "/mnt/ram4" is already in use, script: "create_ramdisk" is exiting nor
*** (mount):
/dev/ram4 on /mnt/ram4 type ext2 (rw)
*** (df -k):
Filesystem
/dev/ram
none
/dev/cdrom
/dev/ram4
1K-blocks
63461
256892
493888
126931
31477
31984 50% /
0
256892
0% /dev/shm
493888
0 100% /mnt/cdrom
1335
125596
2% /mnt/ram4
*** Creating a new MySQL database file structure at: "/mnt/ram4/var/lib/mysql"...
Starting MySQL:
[
[
OK
OK
]
]
/mnt/ram4/var/lib:
total 3
drwxr-xr-x
3 root
root
drwxr-xr-x
3 root
root
drwxr-xr-x
4 mysql
mysql
1024 Jun 22 01:39 .
1024 Jun 22 01:39 ..
1024 Jun 22 01:39 mysql
/mnt/ram4/var/lib/mysql:
total 4
drwxr-xr-x
4 mysql
drwxr-xr-x
3 root
drwx-----2 mysql
srwxrwxrwx
1 mysql
drwx-----2 mysql
mysql
root
mysql
mysql
mysql
1024
1024
1024
0
1024
Jun
Jun
Jun
Jun
Jun
22
22
22
22
22
01:39
01:39
01:39
01:39
01:39
.
..
mysql
mysql.sock
test
/mnt/ram4/var/lib/mysql/mysql:
total 67
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
1024
1024
8778
0
1024
8982
302
3072
8641
0
1024
8958
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
22
22
22
22
22
22
22
22
22
22
22
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
.
..
columns_priv.frm
columns_priv.MYD
columns_priv.MYI
db.frm
db.MYD
db.MYI
func.frm
func.MYD
func.MYI
host.frm
81
-rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----
1
1
1
1
1
1
1
1
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
/mnt/ram4/var/lib/mysql/test:
total 2
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
root
2826 2825 1 01:39 ttyp0
root
2908
1 0 01:39 ttyp0
mysql
2930 2908 0 01:39 ttyp0
0
1024
8877
0
1024
9148
428
2048
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
22
22
22
22
22
22
22
01:39
01:39
01:39
01:39
01:39
01:39
01:39
01:39
host.MYD
host.MYI
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
user.frm
user.MYD
user.MYI
1024 Jun 22 01:39 .
1024 Jun 22 01:39 ..
00:00:00 /bin/bash /root/bin/setup_mysql -rd /de
00:00:00 /bin/sh /usr/bin/safe_mysqld --defaults
00:00:00 /usr/libexec/mysqld --defaults-file=/et
*** Try to initialize the Snort MySQL databases...
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
5
snort
root@localhost
stdout
”
3.23.58
10
latin1
latin1
4 sec
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
Slow queries: 0
Opens: 7
Flush tables: 1
Open tables: 1 Qu
5
snort_archive
root@localhost
stdout
”
3.23.58
10
latin1
latin1
4 sec
--------------
Slow queries: 0
Opens: 8
Flush tables: 1
Open tables: 2 Q
/bin/zcat /usr/local/snort/contrib/snortdb-extra.gz | /usr/local/bin/mysql -u snort -p*
82
*** Initialize the Snort archive database tables...
/usr/local/bin/mysql -u snort -p****** snort_archive < /usr/local/snort/contrib/create_
*** Test for proper MySQL database setup for Snort... (4)
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
9
snort
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
17 sec
--------------
Slow queries: 0
Opens: 52
Flush tables: 1
Open tables
port
protocol
name
description
21
6
ftp
21
17
ftp
22
6
Unassigned
22
17
Unassigned
23
6
telnet Telnet
23
17
telnet Telnet
24
6
Unassigned
24
17
Unassigned
25
6
smtp
25
17
smtp
26
6
Unassigned
26
17
Unassigned
27
6
27
17
28
6
Unassigned
28
17
Unassigned
29
6
msg-icp MSG ICP
29
17
msg-icp MSG ICP
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
9
snort_archive
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
17 sec
--------------
Slow queries: 0
Opens: 52
Flush tables: 1
data
detail
encoding
83
Open tables
event
icmphdr
iphdr
opt
reference
reference_system
schema
sensor
sig_class
sig_reference
signature
tcphdr
udphdr
*** Setting up "ACID" for Snort... (5)
*** Setting up: "ADODB" for Snort... (6)
*** Setting up: "JPGRAPH" for Snort... (7)
total 262
drwxr-xr-x
2 root
root
1024 Jun
drwxr-xr-x
45 root
root
3072 Jun
-rw-r--r-1 root
root
3521 Jun
-rw-r--r-1 root
root
1622 Jun
-rw-r--r-1 root
root
6799 Jun
-rw-r--r-1 root
root
608 Jun
-rw-rw-r-1 root
root
59 Jun
-rw-rw-r-1 root
root
167674 Jun
-rw-rw-r-1 root
root
22834 Jun
-rw-r--r-1 root
root
53841 Jun
22
22
21
21
21
21
21
21
22
21
01:39
01:39
13:15
13:15
13:15
13:15
13:15
13:15
01:39
13:15
.
..
generators
gen-msg.map
reference.config
sid
sid-msg.map
snort.conf
unicode.map
*** Setup Snort complete...
... A SNORT CONFIGURATION INSTANCE FOR INTERFACE: eth2 ... (8)
**************************************************************
**************************************************************
***
***
Snort MySQL Version: 2.1.3-1
***
Snort Utility ACID Version: 0.9.6b23
***
Snort Utility ADODB Version: 410
*** Snort Utility JPGraph Version: 1.13
***
***
***
***
MySQL Database Hostname: localhost
***
***
***
Snort IDS Sensor Name: FW-Dirty
**************************************************************
**************************************************************
---- To run Snort on interface: eth2 ---# cd /mnt/ram4/snort
# ifconfig eth2 up
84
Each step in the setup process for the NST snort61 implementation is described in
the above caption. One can see the following:
(1) Creation of a 128MB RAM disk for snort62 data files, MySQL database directory
structure, and ACID related data files.
(2) Remote rule set download from "http://www.snort.org/dl/rules/snortrules-snapshot2_1.tar.gz".
(3) Creation of a MySQL63 database instance for logging snort64 security incident
alerts, events, extra tables, and archiving database.
(4) snort65/MySQL66 database testing output.
(5) Analysis Console for Intrusion Databases (ACID) setup.
(6) snort67 utility Active Data Objects Data Base (ADODB) setup.
(7) Object-Oriented (OO) graphics class library JPGRAPH setup.
(8) A summary section with commands to execute for running the configured
snort68 setup.
In the next caption we will show the results of starting up a snort69 instance on
network interface "eth2". The following commands to start snort70 are shown below:
[root@probe root]# cd /mnt/ram4/snort
[1] 3033
+++++++++++++++++++++++++++++++++++++++++++++++++++
| Hash Method:
2
| Memcap:
10485760
| Rows :
4099
Fragment min_ttl:
0
Suspend period: 30
Stream4 config:
85
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Suspend period: 30
Ports: 21 23 25 53 80 110 111 143 513 1433
Emergency Ports: 21 23 25 53 80 110 111 143 513 1433
HttpInspect Config:
GLOBAL CONFIG
0
Inspection Type:
STATELESS
Detect Proxy Usage:
NO
Ports: 80 8080 8180
Flow Depth: 300
Base36: OFF
UTF 8: OFF
database:
user = snort
86
database:
host = localhost
database:
port = 3306
database:
sensor name = FW-Dirty
database:
sensor id = 1
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
sig-id=2275
seconds=60
| gen-id=1
sig-id=2523
type=Both
tracking=dst count=10 seconds=10
+-----------------------[suppression]-----------------------------------------------------------------------------------------------------------------------Rule application order: ->activation->dynamic->alert->pass->log
As this point snort71 is up and running on stealth network interface "eth2". One
needs to proceed to the Section called Examining Snort Results in Chapter 2 and use
ACID72 for monitoring any network intrusion traffic activity.
Setup Snort Example: Backend MySQL Snort Database With
Remote IDS Snort Probes
In this example we will setup and configure a backend MySQL73 database that
is snort74 ready. A federation of remote IDS snort75 probes strategically placed
throughout an enterprise network computing environment as shown in Figure 6-5
can then forward any detected security incidents to this database engine. Typically
the positioning of an IDS snort76 probe will be at the ingress/egress interface point
for a particular security zone. The setup_snort script will be run with the "collector"
mode option enabled for initializing the backend MySQL77 database.
The backend MySQL78 database will be running on NST probe: 10.222.222.101. This
particular NST system has a locally attached disk drive formatted with a Linux Ext3
file system. The runtime MySQL79 database file structure will be located on this disk
at mount point: "/mnt/ext3/mysql". The "collector" configuration is now shown with
the following options to the setup_snort script. In this case no prior MySQL80 setup
occurred. This is the initial setup.
[root@probe snort]# /usr/local/snort/setup_snort -c -rdir /mnt/ext3/mysql -v
/root/bin/setup_mysql -rdir /mnt/ext3/mysql -v
*** Creating a new MySQL database file structure at: "/mnt/ext3/mysql/var/lib/mysql"...
87
Starting MySQL:
[
[
OK
OK
]
]
total 12
drwxr-xr-x
3 root
root
drwxr-xr-x
3 root
root
drwxr-xr-x
4 mysql
mysql
4096 Jun 22 21:24 .
4096 Jun 22 21:24 ..
4096 Jun 22 21:24 mysql
total 16
drwxr-xr-x
4 mysql
mysql
drwxr-xr-x
3 root
root
drwx-----2 mysql
mysql
srwxrwxrwx
1 mysql
mysql
drwx-----2 mysql
mysql
4096
4096
4096
0
4096
Jun
Jun
Jun
Jun
Jun
22
22
22
22
22
21:24
21:24
21:24
21:24
21:24
.
..
mysql
mysql.sock
test
total 112
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
4096
4096
8778
0
1024
8982
302
3072
8641
0
1024
8958
0
1024
8877
0
1024
9148
428
2048
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
.
..
columns_priv.frm
columns_priv.MYD
columns_priv.MYI
db.frm
db.MYD
db.MYI
func.frm
func.MYD
func.MYI
host.frm
host.MYD
host.MYI
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
user.frm
user.MYD
user.MYI
total 8
drwx-----2 mysql
mysql
drwxr-xr-x
4 mysql
mysql
4096 Jun 22 21:24 .
4096 Jun 22 21:24 ..
root
1330
697 1 21:24
root
1339 1338 2 21:24
root
1402
1 1 21:24
mysql
1428 1402 1 21:24
ttyp0
ttyp0
ttyp0
ttyp0
00:00:00
00:00:00
00:00:00
00:00:00
/bin/bash ./setup_snort -c -rdir /mnt/ext3/mysql
/bin/bash /root/bin/setup_mysql -rdir /mnt/ext3/m
/bin/sh /usr/bin/safe_mysqld --defaults-file=/etc
/usr/libexec/mysqld --defaults-file=/etc/my.cnf -
Connection id:
Current database:
Current user:
88
5
snort
root@localhost
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
stdout
”
3.23.58
10
latin1
latin1
5 sec
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
Slow queries: 0
Opens: 7
Flush tables: 1
5
snort_archive
root@localhost
stdout
”
3.23.58
10
latin1
latin1
5 sec
--------------
Slow queries: 0
Opens: 8
Flush tables: 1
/bin/zcat /usr/local/snort/contrib/snortdb-extra.gz | /usr/local/bin/mysql -u snort -p****** snor
*** Initialize the Snort archive database tables...
/usr/local/bin/mysql -u snort -p****** snort_archive < /usr/local/snort/contrib/create_mysql
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
9
snort
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
58 sec
-------------port
21
21
protocol
6
ftp
17
ftp
Slow queries: 0
Opens: 52
Flush tables: 1
name
description
89
22
6
Unassigned
22
17
Unassigned
23
6
telnet Telnet
23
17
telnet Telnet
24
6
Unassigned
24
17
Unassigned
25
6
smtp
25
17
smtp
26
6
Unassigned
26
17
Unassigned
27
6
27
17
28
6
Unassigned
28
17
Unassigned
29
6
msg-icp MSG ICP
29
17
msg-icp MSG ICP
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
9
snort_archive
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
58 sec
--------------
Slow queries: 0
Opens: 52
Flush tables: 1
data
detail
encoding
event
icmphdr
iphdr
opt
reference
reference_system
schema
sensor
sig_class
sig_reference
signature
tcphdr
udphdr
*** Setting up "ACID" for Snort...
*** Setting up: "ADODB" for Snort...
*** Setting up: "JPGRAPH" for Snort...
****************************************************
****************************************************
90
*** A MySQL database is running on this probe at
*** IP:Port: 10.222.222.101:3306 for the collection
*** of remote Snort security incidents.
****************************************************
****************************************************
Another setup example is shown where a prior MySQL81 instance existed and was
configured for snort82. The -rdir DIR option will be used to attach to the existing
MySQL83 file structure at directory location: /mnt/ext3/mysql.
[root@probe root]# fdisk -l (1)
Disk /dev/hdc: 20.0 GB, 20060135424 bytes
255 heads, 63 sectors/track, 2438 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot
/dev/hdc1
Start
1
End
2438
Blocks
19583203+
Id
83
System
Linux
[root@probe root]# mount -t ext3 /dev/hdc1 /mnt/ext3 (2)
[root@probe root]# df (3)
Filesystem
/dev/ram
none
/dev/cdrom
/dev/hdc1
1K-blocks
63461
31143
32318 50% /
127024
0
127024
0% /dev/shm
492928
492928
0 100% /mnt/cdrom
19275868
65160 18231548
1% /mnt/ext3
[root@probe root]# ls -al /mnt/ext3 (4)
total 29
drwxr-xr-x
5 root
root
4096 Jun 22 21:23 .
drwxr-xr-x
28 root
root
1024 Jun 25 23:05 ..
drwx-----2 root
root
16384 May 30 19:31 lost+found
drwxr-xr-x
3 root
root
4096 Jun 22 21:24 mysql
drwxr-xr-x
3 root
root
4096 Jun 19 09:34 var
[root@probe root]# cd /usr/local/snort
[root@probe snort]# ./setup_snort -c -rdir /mnt/ext3/mysql -v (5)
/root/bin/setup_mysql -rdir /mnt/ext3/mysql -v
*** Using existing MySQL database file structure at: "/mnt/ext3/mysql/var/lib/mysql"...
Starting MySQL:
[
OK
]
*** A password for database user: "root" was already set...
total 12
drwxr-xr-x
3 root
root
drwxr-xr-x
4 root
root
drwxr-xr-x
6 mysql
mysql
4096 Jun 22 21:24 .
4096 Jun 22 21:25 ..
4096 Jun 26 20:28 mysql
total 24
drwxr-xr-x
6 mysql
mysql
drwxr-xr-x
3 root
root
drwx-----2 mysql
mysql
srwxrwxrwx
1 mysql
mysql
drwx-----2 mysql
mysql
4096
4096
4096
0
4096
Jun
Jun
Jun
Jun
Jun
26
22
22
26
24
20:28
21:24
21:24
20:28
23:59
.
..
mysql
mysql.sock
snort
91
drwx-----drwx------
2 mysql
2 mysql
mysql
mysql
total 112
drwx-----2 mysql
mysql
drwxr-xr-x
6 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
-rw-rw---1 mysql
mysql
92
4096 Jun 22 21:25 snort_archive
4096 Jun 22 21:24 test
4096
4096
8778
0
1024
8982
906
3072
8641
0
1024
8958
0
1024
8877
0
1024
9148
642
2048
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
26
22
22
22
22
22
24
22
22
22
22
22
22
22
22
22
22
22
24
21:24
20:28
21:24
21:24
21:24
21:24
21:24
00:22
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
21:24
00:22
.
..
columns_priv.frm
columns_priv.MYD
columns_priv.MYI
db.frm
db.MYD
db.MYI
func.frm
func.MYD
func.MYI
host.frm
host.MYD
host.MYI
tables_priv.frm
tables_priv.MYD
tables_priv.MYI
user.frm
user.MYD
user.MYI
/mnt/ext3/mysql/var/lib/mysql/snort:
total 4468
drwx-----2 mysql
mysql
4096
drwxr-xr-x
6 mysql
mysql
4096
-rw-rw---1 mysql
mysql
8612
-rw-rw---1 mysql
mysql
0
-rw-rw---1 mysql
mysql
1024
-rw-rw---1 mysql
mysql
8680
-rw-rw---1 mysql
mysql
0
-rw-rw---1 mysql
mysql
1024
-rw-rw---1 mysql
mysql
8922
-rw-rw---1 mysql
mysql
34600
-rw-rw---1 mysql
mysql
76800
-rw-rw---1 mysql
mysql
8728
-rw-rw---1 mysql
mysql
0
-rw-rw---1 mysql
mysql
1024
-rw-rw---1 mysql
mysql
8614
-rw-rw---1 mysql
mysql
206296
-rw-rw---1 mysql
mysql
6144
-rw-rw---1 mysql
mysql
8606
-rw-rw---1 mysql
mysql
40
-rw-rw---1 mysql
mysql
2048
-rw-rw---1 mysql
mysql
8614
-rw-rw---1 mysql
mysql
60
-rw-rw---1 mysql
mysql
2048
-rw-rw---1 mysql
mysql
8642
-rw-rw---1 mysql
mysql
9450
-rw-rw---1 mysql
mysql
21504
-rw-rw---1 mysql
mysql
8802
-rw-rw---1 mysql
mysql
17476
-rw-rw---1 mysql
mysql
1024
-rw-rw---1 mysql
mysql
8738
-rw-rw---1 mysql
mysql
2567
-rw-rw---1 mysql
mysql
5120
-rw-rw---1 mysql
mysql
8920
-rw-rw---1 mysql
mysql
14400
-rw-rw---1 mysql
mysql
18432
-rw-rw---1 mysql
mysql
8728
-rw-rw---1 mysql
mysql
0
-rw-rw---1 mysql
mysql
1024
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
24
26
24
24
24
24
24
24
24
25
25
24
24
24
22
25
25
22
22
24
22
22
24
22
25
25
22
22
24
22
25
25
22
25
25
22
22
22
23:59
20:28
23:59
23:59
23:59
23:59
23:59
23:59
23:59
13:05
16:10
23:59
23:59
23:59
21:24
21:21
23:03
21:24
21:24
00:22
21:24
21:24
00:22
21:24
21:21
23:03
21:24
21:25
00:22
21:24
21:21
23:03
21:24
21:21
23:03
21:24
21:24
21:24
.
..
acid_ag_alert.frm
acid_ag_alert.MYD
acid_ag_alert.MYI
acid_ag.frm
acid_ag.MYD
acid_ag.MYI
acid_event.frm
acid_event.MYD
acid_event.MYI
acid_ip_cache.frm
acid_ip_cache.MYD
acid_ip_cache.MYI
data.frm
data.MYD
data.MYI
detail.frm
detail.MYD
detail.MYI
encoding.frm
encoding.MYD
encoding.MYI
event.frm
event.MYD
event.MYI
flags.frm
flags.MYD
flags.MYI
icmphdr.frm
icmphdr.MYD
icmphdr.MYI
iphdr.frm
iphdr.MYD
iphdr.MYI
opt.frm
opt.MYD
opt.MYI
-rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
8624
6248
1024
8630
644
2048
8618
100
2048
8580
13
2048
8738
108
2048
8648
3686536
1024
8614
180
4096
8730
1480
4096
8616
442
2048
8888
7770
15360
8704
680
4096
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
22
24
22
25
25
22
24
24
22
22
24
22
25
25
22
22
24
22
25
25
22
25
25
22
25
25
22
25
25
22
25
25
21:24
21:24
00:22
21:24
13:03
16:10
21:24
08:12
23:34
21:24
21:24
00:22
21:24
10:35
16:10
21:24
21:25
00:22
21:24
12:59
16:10
21:24
13:03
16:10
21:24
13:03
16:10
21:24
19:26
23:03
21:24
21:21
23:03
protocols.frm
protocols.MYD
protocols.MYI
reference.frm
reference.MYD
reference.MYI
reference_system.frm
reference_system.MYD
reference_system.MYI
schema.frm
schema.MYD
schema.MYI
sensor.frm
sensor.MYD
sensor.MYI
services.frm
services.MYD
services.MYI
sig_class.frm
sig_class.MYD
sig_class.MYI
signature.frm
signature.MYD
signature.MYI
sig_reference.frm
sig_reference.MYD
sig_reference.MYI
tcphdr.frm
tcphdr.MYD
tcphdr.MYI
udphdr.frm
udphdr.MYD
udphdr.MYI
/mnt/ext3/mysql/var/lib/mysql/snort_archive:
total 276
drwx-----2 mysql
mysql
4096 Jun
drwxr-xr-x
6 mysql
mysql
4096 Jun
-rw-rw---1 mysql
mysql
8614 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8606 Jun
-rw-rw---1 mysql
mysql
40 Jun
-rw-rw---1 mysql
mysql
2048 Jun
-rw-rw---1 mysql
mysql
8614 Jun
-rw-rw---1 mysql
mysql
60 Jun
-rw-rw---1 mysql
mysql
2048 Jun
-rw-rw---1 mysql
mysql
8642 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8738 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8920 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8728 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8630 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8618 Jun
-rw-rw---1 mysql
mysql
0 Jun
-rw-rw---1 mysql
mysql
1024 Jun
-rw-rw---1 mysql
mysql
8580 Jun
22
26
22
22
22
22
22
24
22
22
24
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
21:25
20:28
21:25
21:25
21:25
21:25
21:25
00:22
21:25
21:25
00:22
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
.
..
data.frm
data.MYD
data.MYI
detail.frm
detail.MYD
detail.MYI
encoding.frm
encoding.MYD
encoding.MYI
event.frm
event.MYD
event.MYI
icmphdr.frm
icmphdr.MYD
icmphdr.MYI
iphdr.frm
iphdr.MYD
iphdr.MYI
opt.frm
opt.MYD
opt.MYI
reference.frm
reference.MYD
reference.MYI
reference_system.frm
reference_system.MYD
reference_system.MYI
schema.frm
93
-rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----rw-rw----
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
mysql
total 8
drwx-----2 mysql
mysql
drwxr-xr-x
6 mysql
mysql
root
821
758 1 20:28
root
830
829 0 20:28
root
872
1 0 20:28
mysql
898
872 1 20:28
ttyp0
ttyp0
ttyp0
ttyp0
13
2048
8738
0
1024
8614
0
1024
8730
0
1024
8616
0
1024
8888
0
1024
8704
0
1024
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
22
24
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
21:25
00:22
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
21:25
schema.MYD
schema.MYI
sensor.frm
sensor.MYD
sensor.MYI
sig_class.frm
sig_class.MYD
sig_class.MYI
signature.frm
signature.MYD
signature.MYI
sig_reference.frm
sig_reference.MYD
sig_reference.MYI
tcphdr.frm
tcphdr.MYD
tcphdr.MYI
udphdr.frm
udphdr.MYD
udphdr.MYI
4096 Jun 22 21:24 .
4096 Jun 26 20:28 ..
00:00:00
00:00:00
00:00:00
00:00:00
/bin/bash ./setup_snort -c -rdir /mnt/e
/bin/bash /root/bin/setup_mysql -rdir /
/bin/sh /usr/bin/safe_mysqld --defaults
/usr/libexec/mysqld --defaults-file=/et
*** Prior MySQL databases for Snort detected...
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
5
snort
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
4 sec
-------------port
21
21
22
22
23
23
24
94
protocol
6
ftp
17
ftp
6
17
6
telnet
17
telnet
6
-
Slow queries: 0
Opens: 6
name
description
Unassigned
Unassigned
Telnet
Telnet
Unassigned
Flush tables: 1
Open tables: 0 Qu
24
17
Unassigned
25
6
smtp
25
17
smtp
26
6
Unassigned
26
17
Unassigned
27
6
27
17
28
6
Unassigned
28
17
Unassigned
29
6
msg-icp MSG ICP
29
17
msg-icp MSG ICP
Connection id:
Current database:
Current user:
Current pager:
Using outfile:
Server version:
Protocol version:
Connection:
UNIX socket:
Uptime:
5
snort_archive
snort@localhost
stdout
”
3.23.58
10
latin1
latin1
5 sec
--------------
Slow queries: 0
Opens: 7
Flush tables: 1
data
detail
encoding
event
icmphdr
iphdr
opt
reference
reference_system
schema
sensor
sig_class
sig_reference
signature
tcphdr
udphdr
*** "ACID" configuration already exists, skipping setup...
*** "ADODB" configuration already exists, skipping setup...
*** "JPGRAPH" configuration already exists, skipping setup...
****************************************************
****************************************************
*** A MySQL database is running on this probe at
*** IP:Port: 10.222.222.101:3306 for the collection
*** of remote Snort security incidents.
****************************************************
****************************************************
95
Open tables: 1 Q
(1) List the partition table found in the Kernel proc file: /proc/partions. This represents detected partitions for all locally attached disk devices.
(2) Mount the Linux Ext3 file system found on partition: /dev/hdc1 at mount point:
/mnt/ext3.
(3) Display all mounted file systems with command: df.
(4) Display a long directory listing at the mount point: /mnt/ext3.
(5) Setup the Snort "Collector" using the exiting MySQL84 at directory location:
/mnt/ext3/mysql.
At this point a backend MySQL85 snort database collector is configured, running,
and waiting for remote snort86 security incidents. The collector mode also configures
ACID87 to be used with this snort88 database.
Note: The collector mode does not setup the NST probe as a IDS snort89 sensor.
The "IP address:port" for the MySQL90 listening TCP/IP connection in this example is:
10.222.222.101:3306.
We will now setup a remote snort91 IDS probe: 10.222.222.110 and log all security
incidents detected on stealth interface: "eth1" to the backend MySQL92 snort database
collector at: 10.222.222.101:3306. Interface "eth1" is monitoring all traffic entering and
leaving: Security Zone: 1 DMZ NST "probe 2".
[root@probe snort]# /usr/local/snort/setup_snort -r remote -i eth1 -d 10.222.222.101 -s DMZ -a full
*** Creating a 64MByte RAM disk at mount point: "/mnt/ram4"...
============================================================
============================================================
65536+0 records in
65536+0 records out
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
First data block=1
8 block groups
8193, 24577, 40961, 57345
96
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
none
256892
/dev/cdrom
494048
/dev/ram4
63461
31255
32206 50% /
0
256892
0% /dev/shm
494048
0 100% /mnt/cdrom
13
63448
1% /mnt/ram4
*** Using remote Snort rules definitions...
*** Fetching the latest Snort rule definitions from: "http://www.snort.org/dl/rules/snortrules-sn
/usr/local/bin/wget http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz
100%[==================================================================>] 141,308
rules/
rules/generators
rules/gen-msg.map
rules/sid
rules/sid-msg.map
rules/snort.conf
rules/unicode.map
rules/cgi-bin.list
rules/chat.rules
rules/ddos.rules
rules/deleted.rules
rules/dns.rules
rules/dos.rules
rules/exploit.rules
rules/finger.rules
rules/ftp.rules
rules/icmp.rules
rules/imap.rules
rules/info.rules
rules/local.rules
rules/misc.rules
rules/mysql.rules
rules/netbios.rules
rules/nntp.rules
rules/oracle.rules
rules/p2p.rules
rules/policy.rules
rules/pop2.rules
rules/pop3.rules
rules/porn.rules
97
337.40K/s
rules/rpc.rules
rules/scan.rules
rules/smtp.rules
rules/snmp.rules
rules/sql.rules
rules/telnet.rules
rules/tftp.rules
rules/virus.rules
rules/web-cgi.rules
rules/web-iis.rules
rules/web-php.rules
rules/x11.rules
total 262
drwxr-xr-x
2 root
root
1024 Jun
drwxr-xr-x
44 root
root
3072 Jun
-rw-r--r-1 root
root
3521 Jun
-rw-r--r-1 root
root
1622 Jun
-rw-r--r-1 root
root
6799 Jun
-rw-r--r-1 root
root
608 Jun
-rw-rw-r-1 root
root
59 Jun
-rw-rw-r-1 root
root
167674 Jun
-rw-rw-r-1 root
root
22834 Jun
-rw-r--r-1 root
root
53841 Jun
24
24
24
24
24
24
24
24
24
24
18:13
18:13
05:15
05:15
05:15
05:15
05:15
05:15
18:13
05:15
.
..
generators
gen-msg.map
reference.config
sid
sid-msg.map
snort.conf
unicode.map
*** Setup Snort complete...
... A SNORT CONFIGURATION INSTANCE FOR INTERFACE: eth1 ...
**************************************************************
**************************************************************
***
***
***
***
***
MySQL Database Hostname: 10.222.222.101
***
***
***
Snort IDS Sensor Name: DMZ
**************************************************************
**************************************************************
---- To run Snort on interface: eth1 ---# cd /mnt/ram4/snort
# ifconfig eth1 up
The remote snort93 setup is now complete. Prior to starting the IDS snort94
sensor one needs to bring up the stealth interface: "eth1" and make any
additional snort95 rules set changes from the default in configuration file:
/etc/snort_eth1/snort.conf.
Results for starting up this remote IDS snort96 sensor are now presented:
98
[root@probe snort]# cd /mnt/ram4/snort
[1] 1335
+++++++++++++++++++++++++++++++++++++++++++++++++++
| Hash Method:
2
| Memcap:
10485760
| Rows :
4099
Fragment min_ttl:
0
Suspend period: 30
Stream4 config:
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Suspend period: 30
Ports: 21 23 25 53 80 110 111 143 513 1433
Emergency Ports: 21 23 25 53 80 110 111 143 513 1433
HttpInspect Config:
99
GLOBAL CONFIG
0
Inspection Type:
STATELESS
Detect Proxy Usage:
NO
Ports: 80 8080 8180
Flow Depth: 300
Base36: OFF
UTF 8: OFF
database:
user = snort
database:
host = 10.222.222.101 (1)
database:
port = 3306
database:
sensor name = DMZ
[root@probe snort]# database:
sensor id = 1
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
sig-id=2275
seconds=60
| gen-id=1
sig-id=2523
type=Both
tracking=dst count=10 seconds=10
+-----------------------[suppression]------------------------------------------------------------------------------------------------------------------------
100
Rule application order: ->activation->dynamic->alert->pass->log
(1) One can see from the snort97 output that Snort Collector: 10.222.222.101:3306"
serves as the MySQL98 backend database for security incident archiving. At this
point additional IDS snort99 probes can be added to create a comprehensive IDS
deployment throughout one’s network computing enterprise.
Nessus
Nessus100 is a powerful network security scanner which will audit a given host or
network and determine if any detected network services are vulneraable or can be
misused by an intruder. This tool is much more than a network port scanner, it test for
numerous current exploits, and it identifies and test services running on nonstandard
ports. Nessus101 is built using a client/server architecture allowing an entire network
segment to be tested and analyzed at once.
ettercap
ettercap102 is a multipurpose sniffer/interceptor/logger for switched Local Area
Networks (LAN). It supports active and passive dissection of many protocols (even
ciphered ones) and includes many feature for network and host analysis.
IFGraph
IFGraph103 is a set of Perl104 scripts that were created to fetch data from SNMP agents
and feed a RRD file (Round Robin Database) for graphical presentations at a later
date. All graphics are rendered from the RDD database using the RRDtool105 tool.
IFGraph106 has 3 main Perl107 script components:
ifgraph.pl: this script is responsable for creating, organizing and mantaining the RRD
databases. The program also queries the SNMP agents, analizing the returned data
before sending it to RRDtool108
find-if.pl: this script was created to help the admin to set the ifgraph.conf file. You
feed it with the correct arguments (try ./ifgraph -h) and it will show the network
interfaces of the selected host. With this data you decide what interfaces you will
monitor.
makegraph.pl: this script reads the RRD databases and queries the SNMP agents
searching for info that will help in the creation of the HTML files and in the PNG
images.
Kismet
Kismet109 is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring
(rfmon) mode, and can sniff 802.11b, 802.11a, and 802.11g traffic.
101
Kismet110 identifies networks by passively collecting packets and detecting standard
named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic.
NST has been configured to work with Kismet111. Specifically, the default configuration is to use the linux-wlan-ng112 IEEE 802.11 standard-based project and wireless adapters that support the "Prism2/2.5/3" chipset. For 802.11b monitoring I have
been using the "Microsoft MN-510 USB" wireless adapter. Many other 802.11 wireless
adapters are supported (Ex: Orinoco and aironet).
In addition to 802.11 wireless monitoring, Kismet113 also includes tools and integration for producing graphical maps depicting 802.11 wireless network topologies. A
NST probe running the "gpsd" daemon (found in the Section called GPSD in Chapter
11) coupled with an attached Chapter 11 receiver can be integrated with Kismet114
to produce these wireless network topologies. This ensemble of hardware/software
collectively forms the necessary equipment to perform wireless ’War Driving115’.
I will now demonstrate how to use Kismet116 with NST. An example ’War Driving117’
exercise will be shown.
The diagram shown in Figure 3-1 is our NST configuration for this Kismet118 demonstration.
Figure 3-1. Kismet - NST 802.11b Wireless Network Monitoring Configuration
First we need to start our GPS daemon "gpsd" with an attached GPS receiver. I use
a Magellan Meridian Color GPS receiver. One needs to enabled the NMEA V2.1 GSA
data stream (i.e. found in the Setup/NMEA menu) to feed the GPS daemon (gpsd).
Remember to first flush/reset your connecting serial device on the NST probe with
the reset_serial script before running the "gpsd" daemon.:
[root@probe root]# /usr/local/bin/reset_serial /dev/ttyS0 > /dev/null 2>&1
[root@probe root]# /usr/local/bin/gpsd -p /dev/ttyS0
To verify that the NMEA data stream is being received by the "gpsd" daemon, one
can connect to the daemon with the "NetCat" - (nc) TCP/IP network utility as shown
in Figure 11-2
Next we will setup the kismet119 "setup_kismet" script found in the
"/usr/local/kismet-RELEASE" directory (where "RELEASE" is the Kismet release
used in the NST distribution, Ex: 2004.04.R1, the directory location would be:
"/usr/local/kismet-2004.04.R1") is the primary means to run the kismet120 server on a
NST probe system.
Output information is shown for running the kismet121 setup script (setup_kismet):
[root@probe root]# /usr/local/kismet-2004.04.R1/setup_kismet
102
============================================================
============================================================
*** Zeroing out RAM device: /dev/ram4
65536+0 records in
65536+0 records out
*** Create a 65536KB Linux ext2 file system on RAM device: /dev/ram4
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
First data block=1
8 block groups
8193, 24577, 40961, 57345
*** Mounting RAM disk device: /dev/ram4 at mount point: /mnt/ram4
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
none
127024
/dev/cdrom
482112
/dev/ram5
31729
/dev/ram4
63461
32781
30680 52% /
0
127024
0% /dev/shm
482112
0 100% /mnt/cdrom
22209
9520 70% /mnt/ram5
13
63448
1% /mnt/ram4
*** Moving Kismet’s runtime script to: /mnt/ram4/kismet ...
*** Kismet’s runtime script in: /mnt/ram4/kismet ...
total 4
drwxr-xr-x
2 root
root
1024 Apr 23 13:59 .
drwxr-xr-x
4 root
root
1024 Apr 23 13:59 ..
-rwxr-xr-x
1 root
root
1032 Oct 16 2003 run_kismet_server
*** Edit the Kismet configuration file: "/etc/kismet/kismet.conf"
for your appropriate wireless network adapter settings.
Other Kismet configuration parameters may also need to be
changed for your environment (Ex: GPS or sound usage).
*** Use the "run_kismet_server" script to start up the
Kismet Server with NST. The "kismet_client" can then be
used to start monitoring wireless network traffic. Also
"gkismet" can be used within the X or VNC environment as
a GTK GUI frontend to the Kismet wireless sniffer.
---- To run the Kismet Server... ---# cd /mnt/ram4/kismet
103
# vi /etc/kismet/kismet.conf
# ./run_kismet_server
A 64MByte RAM disk and directory structure at mount point: "/mnt/ram4" was created when the kismet122 setup script was run. This RAM disk will be used as the
kismet123 data storage repository for all output associated with a kismet124 session.
Edit the kismet125 configuration file" "/etc/kismet/kismet.conf" to change parameters
such as: "capture sources, GPS connectivity, and audio characteristics". After this, enter the kismet126 NST directory and run the script (run_kismet_server) to start-up the
kismet127 server. A user named: "kismet" will be created and own the kismet128 server
process. The following depiction is the results from starting the script:
[root@probe root]# cd /mnt/ram4/kismet
[root@probe kismet]# ./run_kismet_server
*** Initialize the USB Wireless Adapter...
Starting WLAN Devices:
*** Adding user: "kismet"...
[
OK
]
*** Starting up the Kismet Server...
[root@probe kismet]# Will drop privs to kismet (1001) gid 1001
No specific sources given to be enabled, all will be enabled.
Enabling channel hopping.
Enabling channel splitting.
Source 0 (prism2source): Enabling monitor mode for wlanng source interface wlan0 channel 6...
Source 0 (prism2source): Opening wlanng source interface wlan0...
Spawned channelc control process 1793
Dropped privs to kismet (1001) gid 1001
Allowing clients to fetch WEP keys.
configdir ’/home/kismet/.kismet/’ does not exist, making it.
SSID cloak file did not exist, it will be created.
IP track file did not exist, it will be created.
Logging networks to Kismet-Apr-23-2004-1.network
Logging networks in CSV format to Kismet-Apr-23-2004-1.csv
Logging networks in XML format to Kismet-Apr-23-2004-1.xml
Logging cryptographically weak packets to Kismet-Apr-23-2004-1.weak
Logging cisco product information to Kismet-Apr-23-2004-1.cisco
Logging gps coordinates to Kismet-Apr-23-2004-1.gps
Logging data to Kismet-Apr-23-2004-1.dump
Writing data files to disk every 300 seconds.
Mangling encrypted and fuzzy data packets.
Tracking probe responses and associating probe networks.
Reading AP manufacturer data and defaults from /usr/local/etc/ap_manuf
Reading client manufacturer data and defaults from /usr/local/etc/client_manuf
Dump file format: wiretap (ethereal libwiretap) dump
Crypt file format: airsnort (weak packet) dump
Kismet 2004.04.R1 (Kismet)
Logging data networks CSV XML weak cisco gps
Listening on port 2501.
Allowing connections from 127.0.0.1/255.255.255.255
Registering builtin client/server protocols...
Registering requested alerts...
Registering builtin timer events...
Gathering packets...
Fri Apr 23 21:31:04 2004 Found new network "shop" bssid 00:06:25:B3:9D:BF WEP Y Ch 6 @ 54.00 mbit
Fri Apr 23 21:31:10 2004 Found new network "midget" bssid 00:06:25:E8:B9:CC WEP Y Ch 3 @ 54.00 mb
[root@probe kismet]#
104
There are a couple of ways to attach to the (kismet_server) running TCP/IP on
port: 2501. One can use the (kismet_client) or gkismet129 in a X or tightvnc130
environment. For this demonstration I chose to show the gkismet131 client application
in a tightvnc132 session which is displayed in Figure 3-2.
Figure 3-2. gkismet - GTK GUI Frontend for the Kismet Wireless Sniffer
From the gkismet133 client application we can see that 2 wireless 802.11b networks
("shop" and "midget") were detected and monitored. In a separate window, the packet
rate for the "shop" network is shown.
A few evenings back, I took a trip in my truck with the NST apparatus described
above and did some War Driving. I spent about 1/2 hour driving in the vicinity of
my residence and detected about 111 wireless networks. A subset of the wireless
network power strength topology and the actual path I followed is show in Figure
3-3
105
Figure 3-3. Kismet - Wireless Network Power Distribution Topology and Track
Map
To produce the topology map shown above, the following gkismet134 "gpsmap" command was executed:
[root@probe kismet]# gpsmap -o kismetwardriving -tkrp -q0 ./Kismet-Apr-23-2004-1.gps
My biggest concern and advice to the owners of these networks is to at least enable
WEP (Wired Equivalent Privacy - 802.11’s optional encryption standard) wireless security at their AP (Access Point). Ease of use and strong security are at opposite ends
of the spectrum. Most of the networks I detected had wireless security disabled. This
is a bad situation for all. Education, security vulnerablities, and implementation of
wireless networking for the non-technical person needs to occur. Typically default
setting on the consumer grade wireless network equipment have wireless security
disabled and the SSID (Service Set Identification) in broadcast mode. Wireless equipment manufacturers make the experience of using wireless networking easy right out
of the box. This does come with a price and a bad side effect: Provides an "Identity
Theft" environment for the wireless hacker.
BandwidthD
BandwidthD135 tracks usage of TCP/IP network subnets and builds html files with
graphs to display utilization. Charts are built by individual IPs, and display utilization over 2 day, 8 day, 40 day, and 400 day periods. Furthermore, each ip address’s
utilization can be logged out at intervals of 2.5 minutes, 10 minutes, 1 hour or 12
hours in CDF (Common Data Format). HTTP, TCP, UDP, ICMP, VPN, and P2P network traffic are color coded.
Nikto
Nikto136 is an Open Source (GPL) web server scanner which performs comprehensive
tests against web servers for multiple items, including over 2600 potentially dangerous files/CGIs, versions on over 625 servers, and version specific problems on over
230 servers. Scan items and plugins are frequently updated and can be automatically
updated.
106
NTop
ntop137 shows the current network usage. It displays a list of hosts that are currently
using the network and reports information concerning the (IP and non-IP) traffic
generated by each host. ntop138 may operate as a front-end collector (sFlow and/or
netFlow plugins) or as a stand-alone collector/display program. A web browser is
used to access the information captured by the ntop139 program.
ntop140 is a hybrid layer 2 / layer 3 network monitor, that is by default it uses the
layer 2 Media Access Control (MAC) addresses AND the layer 3 tcp/ip addresses.
ntop141 is capable of associating the two, so that ip and non-ip traffic (e.g. arp, rarp)
are combined for a complete picture of network activity.
NST is configured with a setup script for running the ntop142 application. The script:
/usr/local/bin/setup_ntop creates a ntop143 runtime environment along with setting
up a file directory structure for the Round Robin Database support tool (RRDtool144).
The NST alias: lntop can be used to reference the /usr/local/bin/setup_ntop script.
The following caption displays
/usr/local/bin/setup_ntop script:
the
documentation
usage
for
the
[root@probe root]# /usr/local/bin/setup_ntop -h
Usage: setup_ntop [-s] [-i <interface>] [-rd <RAM device>]
[-rds <RAM disk size (MB)>] [-rmp <RAM mount point>]
[-rdir <runtime directory>] [-no <ntop_options>] [-v] [-h]
This script is used to create a runtime execution environment for ntop and
start the ntop daemon. ntop is a network traffic probe that shows network
usage and protocol statistics. Accessibility to ntop is via ones Web browser
at the default SSL port: 3001. The default configuration will create a 64MB
RAM disk for ntop and its associated Round Robin Database (rrd) at directory
location: /mnt/ram4/ntop.
The following are 2 examples on how to get access to the ntop Web
interface:
Example 1: Local Access (IP Address "localhost": 127.0.0.1)
NST probe running a ntop daemon.
Interface: "Firefox" browser using X Windows or VNC client, or the "elink
browser using the console or a SSH session.
URL: http://127.0.0.1:3001
Example 2: Remote Access (IP Address of NST Probe running ntop: 192.168.3.24)
Interface: Any Web browser that suport SSL.
URL: https://192.168.3.24:3001
-s | --stop
Use this optional parameter to stop an already running ntop daemon. If this
option is not used and a ntop daemon is already running, this script will
terminate normally leaving the existing ntop daemon running.
-i | --interface
Use this optional parameter to specify the network interface or interfaces to be u
by ntop for network monitoring. If multiple interfaces are used their names must b
separated with a comma. For instance -i "eth0,lo,eth2".
Use this optional parameter to change the default RAM device that will be used for
instance of ntop and rrd data files. Available RAM device names on NST:
"/dev/ram0 - /dev/ram9". A cooresponding mount point: "/mnt/ram0 - /mnt/ram9"
will be automatically selected for the RAM device. One can use the following optio
parameter: "-rmp <mount point>" to change mount point location for the selected RA
device.
107
-rds <RAM dsk size (MB)> | --ram-disk-size <RAM disk
Use this optional parameter to change the default
will be used for ntop and rrd data files.
Default: "64"
** Note: Use a reasonable value and make sure you
The system memory utility: "free" can be
size (MB)>
RAM disk size in MegaBytes (MB)
to not exceed your available sys
used to help make your determina
Use this optional parameter to change the selected RAM device’s: "-rd <RAM device>
mount point for ntop and rrd data files.
One can use this optional parameter to force the setup script to use an existing
directory on a locally attached disk drive or a mounted network file system and
bypass the creation of a RAM disk. To do this, make sure the directory initially
exists prior to running this script.
Example: Mount Point: "/dev/hdc1" mount at: "/probe1" type ext3 (rw)
Directory: "/probe1/networkdata"
Use: "-rdir /probe1/networkdata" to create the top level
runtime directory structure the ntop and rrd data files.
Directory Structure: ntop => /probe1/networkdata/ntop
rrd => /probe1/networkdata/ntop/rrd
-no <ntop_options> | --ntop-option <ntop_options>
Use this optional parameter to pass options to ntop in the format used by
ntop(8). This is useful when specifying options for which there is no separate
"setup_ntop" command-line flag. For example, set sticky hosts and change the
default ntop HTTP server port to 4600: -no "-c -w 4600".
** Note: Double quotes are necessary when spaces exist between command-line
flags and values.
-v | --verbose
-h | --help
This script will also startup a ntop145 daemon with user access via a SSL capable
web browser at the default SSL port: 3001. ntop146 parameters can be set in the
/etc/ntop.conf configuration file or passed along to the ntop daemon via the
"-no" or "--ntop-option" command-line parameter.
Note: The command-line parameters take precedence over any settings in the ntop147
configuration file: /etc/ntop.conf
The following example will startup an ntop148 instance monitoring network traffic
on a stealth interface: eth1. An 80 MByte RAM disk associated with device: /dev/ram9
will be used for the runtime environment. The ntop149 parameter: "set sticky hosts" "-c" will be passed along to the ntop150 daemon. Verbose output from the execution of
the setup_ntop script using the example parameters above is shown in the depiction
below.
[root@probe root]# /usr/local/bin/setup_ntop -i eth1 -no "-c" -rd /dev/ram9 -rds 80 -v
*** Creating a 80MByte RAM disk at mount point: "/mnt/ram9"... (1)
============================================================
============================================================
108
81920+0 records in
81920+0 records out
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
First data block=1
10 block groups
8193, 24577, 40961, 57345, 73729
*** Show all current mounts... (2)
/bin/df -k
Filesystem
1K-blocks
/dev/ram
63461
32705
30756 52% /
none
192256
0
192256
0% /dev/shm
/dev/cdrom
494976
494976
0 100% /mnt/cdrom
/dev/ram5
31729
20553
11176 65% /mnt/ram5
/dev/ram9
79327
13
79314
1% /mnt/ram9
*** Starting up ntop... (3)
/usr/local/bin/ntop @/etc/ntop.conf -d -i "eth1" -c
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Processing file /etc/ntop.conf for parameters...
Jul 14 20:01:27 2004 ntop v.3.0 SourceForge RPM MT (SSL)
Jul 14 20:01:27 2004 Configured on Mar 21 2004 18:07:20, built on Mar 21 2004 18:0
Jul 14 20:01:27 2004 Copyright 1998-2004 by Luca Deri <[email protected]>
Jul 14 20:01:27 2004 Get the freshest ntop from http://www.ntop.org/
Jul 14 20:01:27 2004 Initializing ntop
Jul 14 20:01:30 2004 Checking eth1 for additional devices
Jul 14 20:01:30 2004 Resetting traffic statistics for device eth1
Jul 14 20:01:30 2004 DLT: Device 0 [eth1] is 1, mtu 1514, header 14
Jul 14 20:01:30 2004 Initializing gdbm databases
Jul 14 20:01:30 2004 Now running as requested user ’ntop’ (100:101)
Jul 14 20:01:30 2004 VENDOR: Loading MAC address table.
Jul 14 20:01:30 2004 VENDOR: Checking for MAC address table file
Jul 14 20:01:30 2004 VENDOR: Loading newer file ’/etc/ntop/specialMAC.txt.gz’
Jul 14 20:01:30 2004 VENDOR: ...found 61 lines
Jul 14 20:01:30 2004 VENDOR: ...loaded 59 records
Jul 14 20:01:30 2004 VENDOR: Checking for MAC address table file
Jul 14 20:01:30 2004 VENDOR: Loading newer file ’/etc/ntop/oui.txt.gz’
Jul 14 20:01:31 2004 VENDOR: ...found 44580 lines
Jul 14 20:01:31 2004 VENDOR: ...loaded 7231 records
109
Wed Jul 14 20:01:31 2004
Wed Jul 14 20:01:31 2004
INIT: Bye bye: I’m becoming a daemon...
INIT: Parent process is exiting (this is normal)
ntop successfully started and monitoring interface(s): eth1...
(1) Create a RAM disk at mount point: /mnt/ram9.
(2) List all mounts points on the probe system. Notice the 80 MBytes RAM disk
created at mount point: /mnt/ram9.
(3) Startup a ntop151 daemon on interface: eth1 with the "set sticky hosts" - "-c" parameter specified.
Access to visualize the ntop152 network traffic analysis is via a SSL capable
web browser. In this case the ntop153 daemon is running on NST probe with
IP address: 10.222.222.117. The URL for access to this ntop154 daemon is:
http://10.222.222.117:3001. A remote Microsoft Windows XP Professional desktop
running Internet Explorer will now be used to show various ntop155 screen shots for
this example.
ntop156 screen shot showing the network load time series.
Figure 3-4. NTop Network Load
ntop157 screen shot showing all protocol data as a function of detected hosts.
110
Figure 3-5. NTop All Protocol Data
ntop158 screen shot showing graphs of packet rates (ethernet and broadcast) collected
on eth1. These graphs were generated from data stored in the associated rrdtool159
database.
Figure 3-6. NTop Packet Rate Graphs (RRD)
111
Note: NST’s Web User Interface found in Chapter 2 can also be used to start up ntop160.
Look under the "Networking/Monitors" section for the "ntop" link.
setup_sendmail
The setup_sendmail script is used to enable the sendmail daemon. This allows the
Network Security Toolkit probe to transmit email in a standard manner.
Note: The setup_sendmail script was added starting with the 1.0.5 release of the Network Security Toolkit.
Warning
When you use the setup_sendmail script, you will have the option as
to whether you want to appear as a SMTP server to the rest of the network. You should NEVER enable this option if your probe is accessible
from the network. Doing so would most likely result in your Network
Security Toolkit probe being used as a mail relay host for spammers.
In a typical situation, you would invoke this script without any arguments and it
would then enable the sendmail daemon such that the Network Security Toolkit
probe would then be able to send mail out (other systems on the network would
not be able to use the service).
[root@probe root]# setup_sendmail
Starting sendmail:
Starting sm-client:
[
[
OK
OK
]
]
[root@probe root]#
Figure 3-7. setup_sendmail Typical Usage
Help can be found from the script using the --help option. Most likely you would
want to pipe the results into less (like: sendmail --help | less). The resulting help is
shown in its entirety below:
[root@probe root]# setup_sendmail --help
Usage:
setup_sendmail [-d DOMAIN] [-f HOST] [--relay] [-h|--start|--setup|--remove]
Typically, one just runs this command without any command line
options to configure the NST probe for the sendmail service and to
then start up the sendmail service. Once started, you can verify
that sendmail is working properly with a command like:
echo "$(date): Test sendmail" | sendmail -v [email protected]
For a more thorough test of your sendmail settings, try using
test_sendmail.
If you want client machines on your network to be able to use the
probe like a SMTP server, you will need to include the --relay
option.
The following example enables the probe to act like a SMTP server
and to use the "Smart Host" option enabling sendmail to forward the
processing to stmp-server.indy.rr.com:
112
setup_sendmail --relay --smart-host smtp-server.indy.rr.com
If you just need to temporarily enable/disable the sendmail service,
you can use:
/etc/rc.d/init.d/sendmail start|stop
If you are completely done with the sendmail service, you can stop
it and clean up the files involved with mail via:
setup_sendmail --remove
Where:
-h | --help
Displays this help screen
-d DOMAIN | --domain DOMAIN
Used to specify the fully
resolved to a IP address.
mail if this name can not
make our best guess using
qualified domain name which can be
The sendmail daemon will not send out
be resolved. If omitted, we will
getipaddr.
--relay
If you want the SMTP service to be public you need to specify
this option. WARNING: This will enable your probe to be used as a
mail transport agent by any system which can connect to it. You
should NEVER specify this option if your probe is running outside
of a firewall as it would allow anyone to use it as a mail relay
host. You typically don’t use this option unless you need a
running SMTP server to diagnose email issues of clients on your
network.
-f HOST | --smart-host HOST
This corresponds to the "Smart" relay host option (DS) in the
/etc/mail/sendmail.cf configuration file. It can be useful if you
need to forward the mail processing to another SMTP server
(typically at your ISP). For example, I’ve found that I need to set
it to smtp-server.indy.rr.com in order to get all of my email
out.
--start
This is the default (if you don’t specify any commands). Causes
any previously started sendmail stuff to be stopped and cleaned
up (mail queues are nuked). It then configures the system for the
sendmail daemon and starts it up.
--setup
This is similar to the start command except that the sendmail
deamon isn’t actually started. When your ready to start the
daemon, you’ll need to run:
/etc/rc.d/init.d/sendmail start
--remove
This stops any running sendmail daemon and then removes all of
the configuration, log, spool and links associated with the
sendmail service.
[root@probe root]#
Figure 3-8. setup_sendmail Help Output
Once setup, the script will create the standard /etc/rc.d/init.d/sendmail script. You
can use this script if you need to temporarily stop or start the sendmail service.
113
[root@probe root]# /etc/rc.d/init.d/sendmail stop
Shutting down sendmail:
Shutting down sm-client:
[
[
OK
OK
]
]
[
[
OK
OK
]
]
[root@probe root]#
Figure 3-9. Stopping sendmail
[root@probe root]# /etc/rc.d/init.d/sendmail start
Starting sendmail:
Starting sm-client:
[root@probe root]#
Figure 3-10. Starting sendmail
If you want to stop the sendmail service and remove all of the associated files and
links that were placed into RAM, you can invoke the setup_sendmail script with the
--remove option.
[root@probe root]# setup_sendmail --remove
Shutting down sendmail:
Shutting down sm-client:
[
[
OK
OK
]
]
[root@probe root]#
Figure 3-11. setup_sendmail Removal Of Service
Checking sendmail Status
Once you have the sendmail daemon running, there are several places you can look
to check on its status. This might be necessary if mail is not being routed as you
hoped (trust me, getting sendmail properly configured for your environment can be
a bit tricky). Here are some useful ideas when tracking down problems:
echo "Test001" | sendmail -d0.4 -v [email protected]
You can invoke the mail command directly from the command line (as shown
above) to send a test message to a specific email address.
mailq
The mailq command will show you how many messages are currently queued
up for processing by the sendmail daemon.
/var/log/maillog
You will find error messages reported by the sendmail daemon in the
/var/log/maillog file. If no errors have occurred, the file will be empty.
/var/spool/mail/root
If any outbound mail bounces back, the /var/spool/mail/root file will be created and contain a log of the bounced messages. This file will not exist until the
first bounced message occurs.
/etc/mail/sendmail.cf
This is the main configuration file for the sendmail daemon. If you need to
tweak your sendmail rules, you will need to edit this file (trust me - you won’t
really WANT to edit it). After editing this file you will need to start/stop the
sendmail service. WARNING: This file is removed/replaced each time the
setup_sendmail script is invoked - so make a backup copy if you choose to edit
it by hand.
114
You will find a test_sendmail script available to help test your sendmail setup. It
will attempt to send a email note to vpn@localdomain plus all other email addresses
listed on the command line. It then examines the log and spool files to see if it looks
like the email notes were successfully delivered. It is recommended to pass both a
external email address AND and email address you have access to at your ISP. For
example, the usage below demonstrates how I might use the setup_sendmail script
for the indy.rr.com ISP and then use the test_sendmail script to verify that mail can
be delivered to user accounts on the Network Security Toolkit probe, a user account
at the ISP, and a user account outside of the ISP (note, if you omit the domain on a
email address to the test_sendmail script, it will default it to the domain returned by
getipaddr --public-domain).
[root@probe root]# setup_sendmail -f smtp-server.indy.rr.com
Starting sendmail:
[ OK ]
Starting sm-client:
[ OK ]
[root@probe root]# test_sendmail root@localdomain [email protected] pindy
Generating email messages with date stamp: 2004-06-23 17:12:24
========================================================================
Sending email message to: vpn@localdomain...
Version 8.12.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASL SCANF STARTTLS TCPWRAPPERS
USERDB USE_LDAP_INIT
Canonical name: probe.localdomain
UUCP nodename: probe
a.k.a.: probe.localdomain
a.k.a.: [192.168.0.3]
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = probe
(canonical domain name) $j = probe.localdomain
(subdomain name) $m = localdomain
(node name) $k = probe
========================================================
vpn@localdomain... Connecting to [127.0.0.1] via relay...
220 probe.indy.rr.com ESMTP Sendmail 8.12.8/8.12.8; Wed, 23 Jun 2004 17:12:24 -0500
>>> EHLO probe.localdomain
250-probe.indy.rr.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<[email protected]> SIZE=161
250 2.1.0 <[email protected]>... Sender ok
>>> RCPT To:<vpn@localdomain>
>>> DATA
250 2.1.5 <vpn@localdomain>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 i5NMCOjG003788 Message accepted for delivery
vpn@localdomain... Sent (i5NMCOjG003788 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 probe.indy.rr.com closing connection
========================================================================
115
Sending email message to: root@localdomain...
Version 8.12.8
a.k.a.: [192.168.0.3]
========================================================
root@localdomain... Connecting to [127.0.0.1] via relay...
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> RCPT To:<root@localdomain>
>>> DATA
250 2.1.5 <root@localdomain>... Recipient ok
>>> .
250 2.0.0 i5NMCOjG003797 Message accepted for delivery
root@localdomain... Sent (i5NMCOjG003797 Message accepted for delivery)
>>> QUIT
========================================================================
Sending email message to: [email protected]...
Version 8.12.8
a.k.a.: [192.168.0.3]
========================================================
[email protected]... Connecting to [127.0.0.1] via relay...
116
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> RCPT To:<[email protected]>
>>> DATA
250 2.1.5 <[email protected]>... Recipient ok
>>> .
250 2.0.0 i5NMCPjG003806 Message accepted for delivery
[email protected]... Sent (i5NMCPjG003806 Message accepted for delivery)
>>> QUIT
========================================================================
Sending email message to: [email protected]...
Version 8.12.8
a.k.a.: [192.168.0.3]
========================================================
[email protected]... Connecting to [127.0.0.1] via relay...
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> RCPT To:<[email protected]>
>>> DATA
250 2.1.5 <[email protected]>... Recipient ok
>>> .
250 2.0.0 i5NMCQjG003837 Message accepted for delivery
[email protected]... Sent (i5NMCQjG003837 Message accepted for delivery)
>>> QUIT
117
========================================================================
Checking for email message delivery errors...
Checking vpn account for email message containing ’2004-06-23 17:12:24’
Success: Found ’2004-06-23 17:12:24’ in ’/var/spool/mail/vpn’
Checking root account for email message containing ’2004-06-23 17:12:24’
Success: Found ’2004-06-23 17:12:24’ in ’/var/spool/mail/root’
Checking log file for error messages in email to: [email protected]
It appears that our message to ’[email protected]’ was accepted.
You should check the ’[email protected]’ email account for a new
message containing the string ’2004-06-23 17:12:24’.
Checking log file for error messages in email to: [email protected]
It appears that our message to ’[email protected]’ was accepted.
You should check the ’[email protected]’ email account for a new
message containing the string ’2004-06-23 17:12:24’.
The log file: /root/test_sendmail.log has been created.
[root@probe root]#
Figure 3-12. Using test_sendmail to Check sendmail Configuration.
Becoming a SMTP Server
The setup_sendmail script allows one to easily turn the Network Security Toolkit
probe into a SMTP server for the LAN. This might be useful for testing client machines on your LAN. For example, you could setup Outlook on a Windows machine
to use the Network Security Toolkit probe as its SMTP server. HOWEVER, you should
NEVER enable this option if your Network Security Toolkit probe is exposed to everyone on the Internet (spammers would most likely discover this service and make
use of your Network Security Toolkit probe to deliver their SPAM).
To enable the Network Security Toolkit probe to act as a SMTP server for the network,
add the --relay option.
[root@probe root]# setup_sendmail --relay
Starting sendmail:
Starting sm-client:
[root@probe root]# nmap 192.168.0.9
[
[
OK
OK
]
]
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-17 07:15 EST
Interesting ports on probe (192.168.0.9):
(The 1655 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE
22/tcp
open ssh
25/tcp
open smtp
443/tcp open https
3306/tcp open mysql
Nmap run completed -- 1 IP address (1 host up) scanned in 2.694 seconds
[root@probe root]#
Figure 3-13. setup_sendmail as SMTP Server
118
Notice how port 25 is now open (and accepting connections) on my Network Security
Toolkit probe after including the --relay option.
Enabling Smart Host
It was discovered that setting the "smart host" option in the /etc/mail/sendmail.cf
file was required in some situations. To the best of my understanding, this tells the
sendmail daemon that it should not directly try to handle the mail transfer with remote hosts, but instead pass its work to another SMTP server to process the messages.
For example, I’ve found that my ISP won’t allow me to send email directly from my
Network Security Toolkit probe machine to accounts hosted by the ISP. My ISP does
not allow users to run servers. This was a bit confusing to me as I was only sending
mail out. My Network Security Toolkit probe was not accepting connections on port
25 - so in my mind I view my situation as a client and not a server. Regardless of
how I viewed the situation, my ISP mail servers said "Hey, there is a sendmail server
attempting to connect to us from a IP address that should not have a sendmail server
running. Must be some virus infected user spewing out SPAM. We better close the
connection". To work around this situation, I needed to forward the processing of my
mail to my ISP’s SMTP server.
It was discovered that specifying a "Smart" relay host in the /etc/mail/sendmail.cf
file could be used in this situation. Once enabled, mail is no longer sent directly from
the Network Security Toolkit probe to the final destination, but is instead forwarded
to the "smart host" for processing.
The following demonstrates how one would use the setup_sendmail script in order
to forward mail processing to stmp-server.somedomain.com:
[root@probe root]# setup_sendmail --smart-host smtp-server.somedomain.com
Starting sendmail:
Starting sm-client:
[
[
OK
OK
]
]
[root@probe root]#
Figure 3-14. setup_sendmail as SMTP Server
Note: It is possible to specify both --smart-host HOST and the --relay option to the
setup_sendmail script if your situation warrants it.
Notes
1. http://www.ntp.org
119
12. http://www.mysql.com
14. http://www.phpmyadmin.net/home_page/
21. http://authors.phptr.com/rehman/snort/
24. http://www.apache.org
27. http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html
44. http://authors.phptr.com/rehman/snort/
47. http://www.apache.org
120
121
102. http://ettercap.sourceforge.net/
103. http://ifgraph.sourceforge.net/
104. http://www.perl.org
105. http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
106. http://ifgraph.sourceforge.net/
107. http://www.perl.org
109. http://www.kismetwireless.net/
112. http://www.linux-wlan.org/
115. http://www.wardriving.com
117. http://www.wardriving.com
129. http://gkismet.sourceforge.net/
122
136. http://www.cirt.net/code/nikto.shtml
137. http://www.ntop.org/
123
124
Chapter 4. File Systems
Though not required, the Network Security Toolkit has a full set of tools for accessing
various file systems. If you are already familiar with the mount command you may
want to skip this section (though I’d recommend skimming through Loopback Tricks).
Finding Mounted File Systems
If you use your Network Security Toolkit probe to mount and umount a lot file systems, its easy to lose track of what file systems you currently have mounted. The
mount and df -k commands are very useful in determing what file systems are currently available (and where they map).
The following was invoked after I’d been playing around with the -rdir DIRECTORY
option to the /usr/local/bin/setup_snort script.
[root@probe root]# mount
/dev/ram on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
/dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
//rice/public on /mnt/samba type smbfs (0)
/mnt/samba/tmp/nst/loop-ext3 on /mnt/loop type ext3 (rw,sync,loop=/dev/loop0)
/dev/sda1 on /mnt/nst type vfat (rw)
[root@probe root]# df -k
Filesystem
1K-blocks
/dev/ram
63461
31459
32002 50% /
none
159972
0
159972
0% /dev/shm
/dev/cdrom
490464
490464
0 100% /mnt/cdrom
//rice/public
20161024 18031616
2129408 90% /mnt/samba
/mnt/samba/tmp/nst/loop-ext3
198337
20597
167500 11% /mnt/loop
/dev/sda1
127716
90318
37398 71% /mnt/nst
[root@probe root]#
Figure 4-1. Finding Mounted File Systems
From the above ouput, I see that I have a samba file system (//rice/public - a
shared folder on a Windows machine) mounted to the directory /mnt/samba). In
addition, I see that I have a file on this shared folder mounted as a loop back device at
/mnt/loop (this reminds me that I was still experimenting with keeping a permanent
copy of the snort1 logs using space on a shared folder from a Windows machine).
I can also tell that my thumb drive is 71% full (OK it’s not technically my thumb drive
- I borrowed my wife’s MP3 player).
Finding Unmounted Disks
The Network Security Toolkit only mounts the CDROM at boot time. If you want to
see what disk partitions are available, you can use the fdisk -l command as shown
below (this was done on my old Sager 8550 laptop):
[root@probe root]# fdisk -l
Disk /dev/sda: 131 MB, 131072512 bytes
125
Device Boot
/dev/sda1
Start
1
End
500
Blocks
127984
Id
6
System
FAT16
Disk /dev/hda: 12.0 GB, 12072517632 bytes
Device Boot
/dev/hda2
*
/dev/hda3
/dev/hda4
/dev/hda5
/dev/hda6
/dev/hda7
/dev/hda8
Start
4
393
410
932
1193
410
865
End
392
409
1467
1192
1467
864
931
Blocks
3124642+
136552+
8498385
2096451
2208906
3654724+
538146
Id
b
83
5
83
83
83
82
System
Win95 FAT32
Linux
Extended
Linux
Linux
Linux
Linux swap
Partition table entries are not in disk order
[root@probe root]#
Figure 4-2. Using fdisk -l To Find Disks
The fdisk -l should report all partitions for all available disk drives. The above output tells me that my 128MB USB thumb drive is inserted and treated as SCSI disk
/dev/sda. The output also tells me that there are 6 available partitions on the IDE
hard disk /dev/hda - I’m not counting partition /dev/hda4 as it is a extended partion containing /dev/hda5, /dev/hda6, /dev/hda7 and /dev/hda8.
Using File Systems
Making Use of Swap Space
By default, the Network Security Toolkit probe does not access your hard disk and
runs entirely out of RAM. However, if your hard disk has available Linux swap partitions, you can make use of them. To do this, you simply use the laddswap command.
It will look for all hard disk partiions that are formated as Linux swap space and attempt to make use of them. The following demonstrates the affects on free memory
which the laddswap command can have:
[root@probe root]# free
total
used
Mem:
319944
230820
-/+ buffers/cache:
50640
Swap:
0
0
[root@probe root]# laddswap
free
89124
269304
0
*** Swap space prior to adding...
/sbin/swapon -s
Filename
Type
shared
0
buffers
4444
cached
175736
Size
Used
Priority
Size
538136
Used
0
Priority
-2
*** Detecting existing swap areas...
*** Swap space after adding...
/sbin/swapon -s
Filename
/dev/hda8
[root@probe root]# free
total
used
Mem:
319944
230820
-/+ buffers/cache:
50640
Swap:
538136
0
[root@probe root]#
126
Type
partition
free
89124
269304
538136
shared
0
buffers
4444
cached
175736
Figure 4-3. Using laddswap To Find/Use Swap Partitions
If you want to stop making use of swap space (though I can’t think of a good reason
to do so), you can use the swapoff -a command.
Mounting Local Hard Disks
A typical PC will have a single IDE hard disk installed. IDE hard disk partitions show
up with the prefix /dev/hd (SCSI disks show up with the prefix /dev/sd).
The following demonstrates how one might find all of the mountable IDE hard disk
partitions on a system (note the use of grep to weed out extended and swap partitions).
[root@probe root]# fdisk -l | grep /dev/hd | grep -v xtended | grep -v swap
Disk /dev/hda: 12.0 GB, 12072517632 bytes
/dev/hda2
*
4
392
3124642+
b Win95 FAT32
/dev/hda3
393
409
136552+ 83 Linux
/dev/hda5
932
1192
2096451
83 Linux
/dev/hda6
1193
1467
2208906
83 Linux
/dev/hda7
410
864
3654724+ 83 Linux
[root@probe root]# mount -t vfat /dev/hda2 /mnt/fat; ls /mnt/fat
aecu.sys
config.dos
maestro.com
Program Files tmp
asd.log
config.sys
MP3Player
recycled
usblog.txt
ati
debug.log
msdos.--scandisk.log
USBStorage
autoexec.ago detlog.old
msdos.bak
setuplog.old
vcrtemp.avi
autoexec.bat detlog.txt
msdos.sys
setuplog.txt
videorom.bin
autoexec.dos docs
mstrinf.ini
setupxlg.txt
wfcname.ini
bootlog.prv
drivers
My Documents
Sierra
windows
bootlog.txt
frunlog.txt
My Received Files suhdlog.--WUTemp
cavedog
Impressions Games netlog.txt
suhdlog.dat
command.com
io.sys
opt
system.1st
[root@probe root]# umount /mnt/fat
[root@probe root]# mount -t auto /dev/hda3 /mnt/ext3; ls /mnt/ext3
boot.b
kernel.h
module-info-2.4.20-8 vmlinuz
chain.b
lost+found
os2_d.b
vmlinuz-2.4.20-8
config-2.4.20-8
message
System.map
grub
message.ja
System.map-2.4.20-8
initrd-2.4.20-8.img module-info vmlinux-2.4.20-8
[root@probe root]# umount /mnt/ext3
emumail erik etc ftp lost+found megan nst pkb root scott
lost+found
bin
dev halt initrd lib
misc mysql proc sbin usr
boot etc home lan
lost+found mnt
opt
root tmp
var
[root@probe root]#
Figure 4-4. Finding IDE Partitions
If you looked closely at the above, you’ll notice that I specified vfat for the file system type for the /dev/hda2 partition where as I was lazy and let Linux guess at the
appropriate file system by specifying auto for the other partitions. Its been my experience that if you don’t specify vfat, Linux will sometimes choose msdos as the file
system type and limit you to file names following the 8.3 DOS file name convention.
Note: I’ve found that the partitions on flash memory inserted into a PCMCIA adapter often
shows up as a IDE device (with the /dev/hd prefix), where as the same memory inserted
into a USB adapter will show up as a SCSI device (with the /dev/sd prefix).
127
Mounting USB Thumb Drives
Often one can make use of USB Flash drives (also known as a "memory stick" or
"thumb drive"), external USB hard disks, camera memory (in a USB adapter). If you
are free to partition and format the drive, you can create any kind of file system
you want on it (like a fully Linux compatible ext3 file system). However, if you can’t
dedicate the drive to Linux usage (maybe you decided to borrow your wife’s MP3
player like me), you will probably need to treat it like a old Windows FAT file system.
It should be noted that most USB drives show up as SCSI disks to Linux. Because of
this, fdisk -l will reports the partition’s device with the prefix /dev/sd. For example,
after inserting my wife’s MP3 player into my laptop running the Network Security
Toolkit probe, I can use the following commands to find it and then mount it to the
mount point /mnt/memstick:
[root@probe root]# fdisk -l | grep /dev/sd
Disk /dev/sda: 131 MB, 131072512 bytes
/dev/sda1
1
500
127984
6 FAT16
[root@probe root]# mount -t vfat /dev/sda1 /mnt/memstick
[root@probe root]# ls /mnt/memstick
01-Is This Love.mp3
After You Came.mp3
01-Steve McQueen.mp3
Babe.mp3
02-Baba.mp3
Flash.mp3
02-I Don’t Remember.mp3
Heartbeat_City.mp3
03-You’re An Original.mp3
home
04-No Way Out.mp3
Killer Queen.mp3
05-Would I Lie To You.mp3
My_Best_Friend_s_Girl.mp3
08-San Jacinto.mp3
nst.lp
09-Diamond Road.mp3
settings.dat
13-Living In A Box Living In A Box.mp3
test
14-Jamming.mp3
The_Tracks_of_My_Tears.mp3
15-Joining You.mp3
Touch_And_Go.mp3
15-Mother Earth.mp3
voice
17-Missing Persons Destination Unknown.mp3
[root@probe root]# umount /mnt/memstick
[root@probe root]#
Figure 4-5. Mounting a Thumb Drive (Memory Stick)
There are a couple of things to note when making use of USB storage:
128
•
Not all USB storage is usable (we’ve run across combinations of USB devices +
motherboards + Network Security Toolkit that would not work).
•
We have seen cases where the fdisk -l failed to detect the USB storage device, but
we were still able to mount it by specifying /dev/sda1.
•
Writes may seem to occur very quickly to the USB storage device. This is due to
the way Linux caches disk writes. Because of this, you MUST ALWAYS remember
to umount your USB storage device prior to removing it (if you simply pull it out
- expect file system corruption). You’ll also notice that the umount command may
take a long time to complete. This is common if there is a lot of cached data that
needs to be written out over a slow USB 1.0 bus.
•
Flash memory typically has a limited number of times which it can be written to.
You may want to consider including the noatime option when mounting a file
system that normally keeps track of access times. This will reduce the number of
writes to the device.
Making SMB (Windows Shares)
It is possible to access and make use of file systems which are shared by Windows
machines on the local network (or any other samba like server). If you know the
public name of the shared file system (like //gauntlet/public) you can mount it in
the following manner:
[root@probe root]# mkdir /mnt/smb
[root@probe root]# mount -t smbfs -o username=pblank //guantlet/public /mnt/smb
Password:
[root@probe root]# ls /mnt/smb
ant
art
bin
books
cd
classes
docs
dos
download IBMJava2-13 jar
linux
office52
sbin
firefox
interbase
java lost+found
ogg
tmp
gps
j2sdk1.4.0
jdk
MozillaFirebird originals win32
guide
jalbum
jre
mp3
photos
[root@probe root]# touch /mnt/smb/tmp/bogus.txt
[root@probe root]# ls -l /mnt/smb/tmp/smb.txt
-rwxr-xr-x
1 root
root
0 Jun 17 17:21 /mnt/smb/tmp/smb.txt
[root@probe root]# chown mysql.mysql /mnt/smb/tmp/smb.txt
chown: changing ownership of ‘/mnt/smb/tmp/smb.txt’: Operation not permitted
[root@probe root]# rm /mnt/smb/tmp/smb.txt
rm: remove regular empty file ‘/mnt/smb/tmp/smb.txt’? y
[root@probe root]# umount /mnt/smb
[root@probe root]#
Figure 4-6. Mounting a Shared Windows Folder
The interesting thing to note in this situation is that all files under /mnt/smb will
appear to be owned by root to the Network Security Toolkit probe. In truth, these
files are still owned by the user pblank on the server. There is no way to change
the ownership of these files from our Network Security Toolkit probe. Hence the
Network Security Toolkit probe will only be able to make limited use of this file
system. If we want to do something more (like use it as a place to permanently store
our SQL data base), we’ll need to make use of the loop back device as describe in the
Loopback Tricks section.
In the above example, we were fortunate and knew the name of the Windows machine and the name of the file system it was sharing (the //gauntlet/public passed
to the mount command). If you are not so fortunate as to know this information ahead
of time, you can make use of the nmap and smbclient commands to help track down
what shares are available on your network.
[root@probe root]# nmap -p 139 192.168.100.2-20
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-17 17:35 EST
Interesting ports on rice.linux.bogus (192.168.100.2):
PORT
STATE SERVICE
139/tcp open netbios-ssn
Interesting ports on beans.linux.bogus (192.168.100.3):
PORT
STATE SERVICE
139/tcp closed netbios-ssn
Interesting ports on tamale.linux.bogus (192.168.100.5):
PORT
STATE SERVICE
Interesting ports on flan.linux.bogus (192.168.100.8):
PORT
STATE SERVICE
Interesting ports on mole.linux.bogus (192.168.100.9):
PORT
STATE SERVICE
129
Interesting ports on tortilla.linux.bogus (192.168.100.12):
PORT
STATE SERVICE
Nmap run completed -- 19 IP addresses (6 hosts up) scanned in 2.302 seconds
[root@probe root]# smbclient -L 192.168.100.2 -N
added interface ip=192.168.100.9 bcast=192.168.100.255 nmask=255.255.255.0
Anonymous login successful
Domain=[CCG] OS=[Unix] Server=[Samba 2.2.7a-security-rollup-fix]
Sharename
--------netlogon
profiles
print$
public
family
IPC$
ADMIN$
inkjet
photo
photo4x6
ps
Type
---Disk
Disk
Disk
Disk
Disk
IPC
Disk
Printer
Printer
Printer
Printer
Comment
------Network Logon Service
Printer Drivers
Public Stuff
Family Stuff (like accounts)
IPC Service (Samba Server)
IPC Service (Samba Server)
Created by redhat-config-printer
Server
--------POPPERS
RICE
Comment
------Megan’s laptop
Samba Server
Workgroup
--------CCG
Master
------RICE
0.6.x
0.6.x
0.6.x
0.6.x
[root@probe root]#
Figure 4-7. Looking For Windows Shares
The above tells me that the machine 192.168.100.2 has a lot of shares available. It
also tells me that its security should be enhanced as I was able to gather this information anonymously (guess I better go start reading through the samba guides to figure
out how to configure my home samba server to be more secure).
Mounting NFS Drives
Mounting and using NFS drives from a server is fairly straight forward. The one
issue to be aware of is that ownership of files is likely not to be root. For example:
[root@probe root]# mount -t nfs 192.168.0.2:/opt /mnt/nfs
[root@probe root]# touch /mnt/nfs/tmp/bogus.txt
[root@probe root]# ls -l /mnt/nfs/tmp/bogus.txt
-rw-r--r--
1 nfsnobody nfsnobody
0 Jun 17 17:00 /mnt/nfs/tmp/bogus.txt
[root@probe root]# chown mysql.mysql /mnt/nfs/tmp/bogus.txt
chown: changing ownership of ‘/mnt/nfs/tmp/bogus.txt’: Operation not permitted
[root@probe root]# umount /mnt/nfs
[root@probe root]#
Figure 4-8. Mounting a NFS Drive
As shown above, the root user on the probe has limited access to the NFS drive
exported by 192.168.0.2. If we want to do something more (like use it as a place
to permanently store our SQL data base), we’ll need to make use of the loop back
device as describe in the Loopback Tricks section.
130
Loopback Tricks
Some filesystems have very limited capabilities. In particular, one will find:
•
FAT file systems (typically found on thumb drives) will not support the concepts
of file ownership or permissions (at least not fully).
•
NTFS file systems should not be written to (at least all of the warning messages
I’ve seen have kept me from experimenting with mounting a NTFS file system in
read/write mode).
•
SMB file systems (typically folders shared by Windows machines) will not support
the concepts of file ownership or permissions (at least not fully).
•
NFS file systems (typically shared drives by other Linux/Unix machines) will not
allow the root user to create/write files with the user ID left as root (in my situation, my NFS server changes the file ownership from root to nfsnobody when my
Network Security Toolkit probe creates a new file).
Warning
Unfortunately, the Network Security Toolkit probe can’t do much about
the risk with writing to NTFS file systems. I just wouldn’t recommend
writing to these systems period (maybe there will be a point in the future
where NTFS write support will be considered risk free - but we aren’t
there yet). So, if your only available disk space lies on a NTFS partition,
it is recommended that you skip the remainder of this section.
These limitations are not typically a big issue when transferring files. However, if
one wants to make use of the space on one of these limited file systems, they will
often run across permission and/or ownership errors that would not be encountered
on a ext3 file system. For example, if the directory DIR lies on one of these limited
file systems, one will find that invoking the setup_mysql -rdir DIR will fail because
of ownership and permission issues. Hence you won’t be able to keep a permanent
copy of your SQL databases on one of these limited file systems.
However, if the root user can create and write to a single file on any of these limited
file systems, we can treat that file as its own partition through the magic of the Linux
loop back device.
Note: Much of the following information was gleaned through the result of a Google
search that found the Backup ideas2 web page.
Mounting A File As A Filesystem
In the following example, I’m going to mount my USB thumb drive to /mnt/limited
and create and prepare a 20MB file called nst.lp that will be used to emulate a full
ext3 file system (even though it resides on a FAT file system).
[root@probe root]# mkdir /mnt/limited
[root@probe root]# mount -t vfat /dev/sda1 /mnt/limited
[root@probe root]# df -k /mnt/limited
Filesystem
/dev/sda1
1K-blocks
127716
90318
37398 71% /mnt/limited
[root@probe root]# dd if=/dev/zero of=/mnt/limited/nst.lp bs=1048576 count=20
20+0 records in
20+0 records out
[root@probe root]# mkfs.ext3 /mnt/limited/nst.lp
mke2fs 1.32 (09-Nov-2002)
/mnt/limited/nst.lp is not a block special device.
131
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
First data block=1
3 block groups
8193
Creating journal (1024 blocks): done
[root@probe root]# tune2fs -i 0 -c 0 /mnt/limited/nst.lp
tune2fs 1.32 (09-Nov-2002)
Setting maximal mount count to -1
Setting interval between check 0 seconds
[root@probe root]#
Figure 4-9. Preparing a ext3 File System on a FAT Thumb Drive.
At this point, we now have the 20MB file /mnt/limited/nst.lp prepared such that
we can mount it like a ext3 file system via the loop back device. We will now create
a new mount point and verify that the standard file operations are supported. Notice
how the noatime option was added (this prevents updates to the file system each
time a file is accessed - flash drives have a limited number of writes).
[root@probe root]# mkdir /mnt/loop
[root@probe root]# echo ’/mnt/limited/nst.lp /mnt/loop ext3 loop,sync,noatime 0 0’ \
>>/etc/fstab
[root@probe root]# mount /mnt/loop
[root@probe root]# ls -l /mnt/loop
total 12
drwx------
2 root
root
12288 Jun 17 12:06 lost+found
[root@probe root]# cp /etc/hosts /mnt/loop
[root@probe root]# chown mysql.nobody /mnt/loop/hosts
[root@probe root]# ls -l /mnt/loop/hosts
-rw-r--r--
1 mysql
nobody
600 Jun 17 12:20 /mnt/loop/hosts
[root@probe root]# chmod 700 /mnt/loop/hosts
[root@probe root]# ls -l /mnt/loop/hosts
-rwx------
1 mysql
nobody
600 Jun 17 12:20 /mnt/loop/hosts
Filesystem
1K-blocks
/mnt/limited/nst.lp
19827
1044
17759
6% /mnt/loop
[root@probe root]# rm /mnt/loop/hosts
total 12
drwx-----2 root
root
12288 Jun 17 12:06 lost+found
[root@probe root]# setup_mysql -rdir /mnt/loop
[root@probe root]# du /mnt/loop
12
66
1
68
69
132
/mnt/loop/lost+found
/mnt/loop/var/lib/mysql/mysql
/mnt/loop/var/lib/mysql/test
/mnt/loop/var/lib/mysql
/mnt/loop/var/lib
70
83
/mnt/loop/var
/mnt/loop
[root@probe root]#
Figure 4-10. Mounting a Virtual ext3 File System on a FAT Thumb Drive.
By using the loop back trick, I was able to let mysql make use of the available space
on my USB thumb drive (and thus save a permanent copy of my snort3 logs).
Note: While the loop back trick is handy in a pinch, it should not be used in a situation
where you need every ounce of performance that you can get. There is a significant
amount of overhead involved when using a loop back device.
Mounting a ISO Image
You can make use of the loop option on the mount command to mount a ISO image
and access the files it contains.
[root@probe root]# mkdir /mnt/iso
[root@probe root]# mount -t iso9660 -o loop,ro /tmp/nst-1.0.5.iso /mnt/iso
[root@probe root]# mount
/dev/hda2 on / type ext3 (rw)
/tmp/nst-1.0.5.iso on /mnt/iso type iso9660 (ro,loop=/dev/loop0)
[root@probe root]# losetup /dev/loop0
/dev/loop0: [0302]:213066 (/tmp/nst-1.0.5.iso) offset 0, no encryption
[root@probe root]# ls /mnt/iso
etc isolinux local modules README README.html utils
[root@probe root]# gzip -dc /mnt/iso/isolinux/initrdr9.gz > /tmp/initrd
[root@probe root]# umount /mnt/iso
[root@probe root]#
Here is another way of mounting an ISO image by manually chosing the loop
device with the losetup command.
mkdir /mnt/iso
losetup /dev/loop4 /tmp/nst-1.0.5.iso
mount -t iso9660 -o ro /dev/loop4 /mnt/iso
mount
/dev/hda2 on / type ext3 (rw)
/dev/loop4 on /mnt/iso type iso9660 (ro)
[root@probe root]# losetup /dev/loop4
/dev/loop4: [0302]:213066 (/tmp/nst-1.0.5.iso) offset 0, no encryption
[root@probe root]# ls /mnt/iso
etc isolinux local modules README README.html utils
[root@probe root]# gzip -dc /mnt/iso/isolinux/initrdr9.gz > /tmp/initrd
[root@probe root]# umount /mnt/iso
[root@probe root]# losetup -d /dev/loop4
[root@probe
[root@probe
[root@probe
[root@probe
root]#
root]#
root]#
root]#
[root@probe root]#
133
Mounting a Initial RAM Disk
Most Linux distributions will boot and load files from a "initial RAM disk". This "initial RAM disk" is a single file containing a collection of files. The following demonstrates how one can make use of the loop back device to mount a initial RAM disk
image. In this example, we will use the initial RAM disk image which we extracted
from the Network Security Toolkit ISO image (shown in Mounting a ISO Image).
[root@probe root]# mkdir /mnt/initrd
[root@probe root]# mount -t ext2 -o loop /tmp/initrd /mnt/initrd
[root@probe root]# ls /mnt/initrd
bin
boot
dev
etc
home
initrd
lib
mnt proc
lost+found opt root
[root@probe root]# umount /mnt/initrd
sbin
tftpboot
tmp
usr
var
[root@probe root]#
Note: Notice that ext2 was specified as the file system for the /tmp/initrd file. It may
be possible to create initial RAM disks using alternative filesystem formats (so you may
need to adjust this value for your situation).
Mounting A Encrypted Filesystem (**Note: Fedora Core 2 and
Above Only)
Mounting a file as a encrypted filesystem is very similar as to what was discussed in
the previous section (Mounting A File As A Filesystem). The following steps need to be
done:
•
The cryptography modules and loop back modules need to be available on the
system. These come standard on a Network Security Toolkit distribution.
•
A file needs to be created and initialized with a random pattern. It takes longer to
initialize a file in this manner, but it provides better security than zero filling the
file.
•
The file needs to be initialized with a password through the losetup utility.
•
We will then need to format the file system.
Note: For additional details on encrypted filesystems, refer to: Using CryptoAPI4, Cryptoloop HOWTO5, and How to Configure an Encrypted Loopback Filesystem on Red Hat
Linux 8.06.
In the following example, I’m going to mount a SMB filesystem (a folder "shared"
by a Windows desktop computer) to store my encrypted filesystem on. This will be
mounted to /mnt/smb. I will then create and prepare a 20MB file called crypt.ext3
that will be used to emulate a fully encrypted ext3 file system.
[root@probe
[root@probe
[root@probe
[root@probe
root]#
root]#
root]#
root]#
modprobe cryptoloop
MNTPT=/mnt/smb
if [ ! -d "${MNTPT}" ]; then mkdir "${MNTPT}"; fi
mount -t smbfs -o username=al //rice/public "${MNTPT}"
Password:
[root@probe root]# df -k "${MNTPT}"
Filesystem
//rice/public
1K-blocks
20161024 18864640
1296384 94% /mnt/smb
[root@probe root]# EFILE="${MNTPT}/tmp/crypt.ext3"
[root@probe root]# dd if=/dev/urandom of="${EFILE}" bs=1048576 count=20(1)
134
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
root]#
root]#
root]#
root]#
root]#
root]#
modprobe aes
losetup -e aes /dev/loop0 "${EFILE}"(2)
mkfs.ext3 /dev/loop0
tune2fs -i 0 -c 0 /dev/loop0
losetup -d /dev/loop0(3)
Figure 4-11. Preparing a Encrypted ext3 File System on a Windows Shared Folder.
(1) Filling a file with a random data stream from /dev/urandom can take a VERY
long time - especially over a slow network link. You may be better off to create it
on a local hard disk or RAM disk and then copy the file to your network drive.
(2) This step assigns the encryption key (based on a hash from the password you
provide). Do NOT forget this password as there is no way I know of to recover it
(or your files) once forgotten.
(3) This disconnects the file from the loopback device. We will need to mount it in
the future when we are ready to make use of it.
At this point, we now have the 20MB file /mnt/smb/tmp/crypt.ext3 prepared such
that we can mount it like a encrypted ext3 file system via the loop back device. We
will now create a new mount point and verify that the standard file operations are
supported.
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
[root@probe
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
root]#
MNTPT=/mnt/crypt
mkdir $MNTPT
mount -t ext3 -o loop,encryption=aes /mnt/smb/tmp/crypt.ext3 $MNTPT
ls -l $MNTPT
cp /etc/hosts $MNTPT
chown mysql.nobody $MNTPT/hosts
ls -l $MNTPT/hosts
chmod 700 $MNTPT/hosts
ls -l $MNTPT/hosts
df -k
rm $MNTPT/hosts
df -k
setup_mysql -rdir $MNTPT
du $MNTPT
umount $MNTPT
Figure 4-12. Mounting a Encrypted ext3 File System.
By using the loop back trick, I was able to let mysql make use of the available space
on a shared Windows drive and keep the data encrypted (if someone were able to get
hold of the file - they would have a tough time getting usable information from it).
Note: Making use of encrypted file systems adds an additional peformance penalty. The
article "How to Configure an Encrypted Loopback Filesystem on Red Hat Linux 8.07"
contains a table at the end showing the affects on performance when going to a encrypted
file system.
Warning
Do not forget the password you used to encrypt your file system with.
As far as I know, there is no way to recover data from a encrypted file
system once the password has been lost.
135
Notes
2. http://www.bytemark-hosting.co.uk/tech/backupideas.html
4. http://www.kerneli.org/howto/node3.php
5. http://mobile.linux.com/howtos/Cryptoloop-HOWTO/loopdevicesetup.shtml
6. http://bob.plankers.com/other/linux/loopback_efs.html
7. http://bob.plankers.com/other/linux/loopback_efs.html
136
Chapter 5. System Recovery
The Network Security Toolkit has a full set of system recovery tools.
Windows XP Recovery
My neighbors had the unfortunate experience of having the sewer backup into their
basement. Their Gateway 300S system happened to be on floor and ended up sitting
in three inches of water. Not being the best at protecting their data, they asked if
I could help in trying to recover it. The general steps in the process involved the
following:
•
They brought the disable system down to my house (just the CPU unit).
•
They did not know how to open the case. I had to go to Gateway’s web site to
discover the trick. It’s actually a nice design once you understand how it works
(you can remove a hard disk from one of these systems in less than a minute).
•
I removed the hard disk from the system, wiped it off with a rag, and tried to dry
it with a hair dryer. I then let it sit for 24 hours.
•
I connected a power cord to the CPU unit, installed the now dry hard disk, connected a ethernet cable and inserted the Network Security Toolkit bootable CD in
the CDROM drive.
•
I crossed my fingers and booted the system.
•
By looking at the /var/log/messages log file on my DHCP server, I determined
that the system had indeed booted and been assigned the IP address of
192.168.0.48.
•
Using my work system (running Red Hat Linux 91), I then used the following set
of commands to remotely create a ISO image of what my best guess was of the user
documents on my neighbors’ system:
[root@rice root]# ssh [email protected] mount -t ntfs -r \
/dev/hda1 /mnt/ntfs
/usr/X11R6/bin/xauth: creating new authority file /root/.Xauthority
[root@rice root]# (ssh [email protected] mkisofs -m "*Temporary*" -J \
"/mnt/ntfs/Documents\ and\ Settings") > /lan/tmp/xp.iso
...Warning messages about file names that had to be changed...
5.90% done, estimate finish Tue Sep 9 14:23:20 2003
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 1667072
Path table size(bytes): 12382
Max brk space used 1e9000
84896 extents written (165 Mb)
137
[root@rice root]# cdrecord -eject -v /opt/tmp/xp.iso
TOC Type: 1 = CD-ROM
scsidev: ’0,0,0’
scsibus: 0 target: 0 lun: 0
atapi: 1
Device type
: Removable CD-ROM
Version
: 0
Response Format: 2
Capabilities
:
Vendor_info
: ’ATAPI
’
Identifikation : ’CD-RW 52X24
’
Revision
: ’F.FZ’
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags
: MMC-3 SWABAUDIO BURNFREE FORCESPEED
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
FIFO size
: 4194304 = 4096 KB
Track 01: data
165 MB
Total size:
190 MB (18:51.97) = 84898 sectors
Lout start:
190 MB (18:53/73) = 84898 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 4
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, high Beta category (A+) (3)
ATIP start of lead in: -11849 (97:24/01)
ATIP start of lead out: 359848 (79:59/73)
Disk type:
Long strategy type (Cyanine, AZO or similar)
Manuf. index: 25
Manufacturer: Taiyo Yuden Company Limited
Blocks total: 359848 Blocks current: 359848 Blocks remaining: 274950
Forcespeed is OFF.
Starting to write CD/DVD at speed 24 in real TAO mode for single session.
Last chance to quit, starting real write
0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Performing OPC...
Starting new track at sector: 0
Track 01: 165 of 165 MB written (fifo 100%) [buf 96%] 23.9x.
Track 01: Total bytes read/written: 173867008/173867008 (84896 sectors).
Writing time:
62.441s
Average write speed 18.1x.
Min drive buffer fill was 96%
Fixating...
Fixating time:
14.950s
cdrecord: fifo had 2739 puts and 2739 gets.
cdrecord: fifo was 0 times empty and 1844 times full, min fill was 84%.
[root@rice root]#
138
•
At this point, I took out the freshly burned CD, labeled and dated it and put it in
a sleeve to give back to my friends. As well as advice on delegating the currently
working system as a backup/kid games system (I don’t think its wise to count on
a IDE hard drive that has had a sewer bath).
•
The amazing thing about this, is that it will take me longer to explain to my friends
(who are "click and guess" computer users) how to find their files and copy them
back to their hard drive than it actually took to create the backup using the Network Security Toolkit.
Using a DVD+RW Drive
The Network Security Toolkit includes the dvd+rw-tools2 package which allows you
to burn DVDs using the dvd+rw-format and growisofs commands. This brief section
will demonstrate how one can use these two commands to backup data from a Windows system (my wife’s laptop). For additional details on what you can do with these
two commands, refer to http://fy.chalmers.se/~appro/linux/DVD+RW/.
For this experiment, the following equipment will be used:
Table 5-1. DVD Burning Equipment
Component
Manufacturer
Model
Laptop
vpr Matrix
200A5
DVD+RW
Lite-On
4X LDW-451S
USB 2.0 Enclosure
MWAVE?
USB2.0 3.5"/5.25"
DEVICES EXTERNAL
(AA17570) from
http://www.mwave.com/
Figure 5-1. DVD Burner in USB 2.0 Enclosure
In this experiment, we will also be testing the USB 2.0 capabilities of the Network
Security Toolkit distribution. Trust me. You don’t want to think about burning much
data with a USB 1.1 interface.
Note: At the time of this writing, it is assumed that the Network Security Toolkit CDROM
will be booted from a drive other than the one used to burn the DVD. Were this not the
case, the necessary executables and libraries would need to be copied from the Network
Security Toolkit boot CDROM to the RAM disk so that the Network Security Toolkit boot
CDROM could be ejected from the drive. This process involves the use of the ldd command on the dvd+rw-format and growisofs commands to determine what needs to be
transferred. Eventually, a script will be provide for this situation - but the developers don’t
currently have the equipment to try it out on yet.
139
After booting the Network Security Toolkit and logging in, the DVD burner is
plugged into a USB 2.0 port on the laptop and the following commands are issued:
[root@probe root]# insmod ntfs (1)
[root@probe root]# mount -t ntfs /dev/hda1 /mnt/ntfs (2)
[root@probe root]# du -s /mnt/ntfs/Documents\ and\ Settings/ (3)
876751
/mnt/ntfs/Documents and Settings
[root@probe root]# cdrecord -scanbus (4)
scsibus0:
0,0,0
0) ’MATSHITA’ ’CD-RW CW-8121 ’ ’AZ20’ Removable CD-ROM
0,1,0
1) *
0,2,0
2) *
0,3,0
3) *
0,4,0
4) *
0,5,0
5) *
0,6,0
6) *
0,7,0
7) *
scsibus1:
1,0,0
100) ’LITE-ON ’ ’DVDRW LDW-451S ’ ’GSB6’ Removable CD-ROM
1,1,0
101) *
1,2,0
102) *
1,3,0
103) *
1,4,0
104) *
1,5,0
105) *
1,6,0
106) *
1,7,0
107) *
[root@probe root]# growisofs -Z /dev/scd1 -R -J -m "Temporary*" \
"/mnt/ntfs/Documents and Settings" (5)
... Lots of output ...
[root@probe root]#
Figure 5-2. Burning a DVD with growisofs
(1) This command makes sure the NTFS file system module is loaded.
(2) This command mounts the NTFS file system on the laptop and maps it to
/mnt/ntfs.
(3) This command checks to see how much space is used by the directory we plan to
back up. The 876MB reported will easily fit onto a DVD.
(4) This command helps us locate the device name to pass to the growisofs command. The first device found is the DVD/CDRW drive built into the laptop (this
would be /dev/scd0). The second device found is the DVD+RW burner that we
want to use, so we will need to specify /dev/scd1 when we invoke growisofs or
dvd+rw-format.
(5) This command actually forms the ISO image and burns it to the DVD. The -m
option is used to ignore files and directories whose name starts with Temporary.
The -Z option indicates that we want to replace everything that may currently
exist on the DVD with the backup.
Now that we’ve burned the DVD, let’s check that we can read it. We’ll do this by
mounting it and checking to see if we see the names of the users of this computer in
the top level directory.
[root@probe root]# mount -t iso9660 -o ro /dev/scd1 /mnt/cdrom1
[root@probe root]# ls /mnt/cdrom1
All Users
140
erik
megan
pkb
BB443B11-7D12-450c-9F85-2D32804655F9
Default User
[root@probe root]# du -s /mnt/cdrom1
654717 /mnt/cdrom1
[root@probe root]# umount /mnt/cdrom1
[root@probe root]# eject scd1
Guest
LocalService
NetworkService
Owner
rr_moved
[root@probe root]#
If you’ve just removed the shrink wrap from your new DVD+RW disk, its likely that
you’ll need to format it prior to using growisofs. The following demonstrates they
type of error message the growisofs command may issue if you attempt to use it on
a unformatted disk, followed by the dvd+rw-format command necessary to format
the disk:
[root@probe root]# growisofs -Z /dev/scd1 -R -J /mnt/ntfs/tmp
Executing ’mkisofs -R -J /mnt/ntfs/tmp | builtin_dd of=/dev/scd1 obs=32k seek=0’
:-[ LBA=0h, SENSE KEY=5h/ASC=30h/ASCQ=10h ]
:-( write failed: Input/output error
[root@probe root]# dvd+rw-format /dev/scd1
* DVD?RW format utility by <[email protected]>, version 4.2.
* 4.7GB DVD+RW media detected.
* formatting 73.3/\
[root@probe root]#
Figure 5-3. Formatting a DVD+RW Disk
This section has only touched on some of the capabilities of the dvd+rw-tools4 package. Hopefully its enough for those of you with DVD burning equipment to get
started.
While writing this section, several discoveries were made and additional questions
asked:
•
The laptop used in the experiment was able to boot the Network Security Toolkit
CDROM directly from the USB 2.0 enclosure. This is sure to be system dependendent, but opens up some future possibilities.
•
It was possible to burn the Network Security Toolkit ISO image to a DVD+RW disk
and boot from the DVD.
•
The dvd+rw-tools5 package allows one to "grow" (add to) an existing DVD. This
warrants future investigation as to whether it would be possible to burn the Network Security Toolkit to a DVD+RW disk such that one would have the option of
saving settings.
•
We only backed up the Document and Settings directory on the Windows XP
system in question. This seemed like a reasonable thing to do - the majority of user
documents seemed to be found under this directory (similar to /home in the Unix
world). There may be other critical directories and files on a Windows box that
should be backed up.
•
We only experimented with DVD+RW media. Would using DVD+R, DVD-RW, or
DVD-R media present any issues?
Notes
1. https://www.redhat.com/support/resources/howto/rhl9.html
2. http://fy.chalmers.se/~appro/linux/DVD+RW/
141
142
Chapter 6. Using NST In The Wild
Overview
This chapter will demonstrate various usage of NST in a wide variety of network
evironments.
Basic Simple: 1
Figure 6-1 is a basic simple configuration for NST. A notebook computer running NST
attached directly to a broadband cable network.
Figure 6-1. Basic Simple Configuration: 1
This configuration is useful for monitoring and exploring the Intrusion Detection
System (IDS): snort1 or to work with the ethereal2 protocol analyzer.
Basic Simple: 2
Figure 6-2 is another basic simple configuration for NST. A notebook computer running NST behind a router/switch/firewall/wireless device that is attached a broadband cable network.
Figure 6-2. Basic Simple Configuration: 2
This configuration is useful for exploring the NST Linux Operating System and its
capabilities.
143
Mobile Wireless Monitoring
Figure 6-3 demonstrats a configuration for a notebook computer running NST to monitor 802.11 wireless networks.
Figure 6-3. Mobile Wireless Monitoring
This configuration is desirable for running the kismet3 wireless network sniffer.
Graphical maps can be produced with the addition of a GPS navigational device. All
data capture can be archived via the attached USB Thumb Drive.
Small Business Configuration
Figure 6-4 depicts a typical NST configuration and placement for network security
monitoring within a small business network environment attached to the public internet.
Figure 6-4. Small Business Diagram
In this NST configuration a notebook computer is used as the display device for the
NST probe system.
144
Enterprise Configuration
NST can be integrated in the Corporate Enterprise Network environment. Figure 6-5
shows an example of setting up a federation of NST IDS probe sensors with a backend MySQL database server, Analysis Console for Intrusion Databases (ACID), and
a Apache Enterprise Web (HTTP) Server.
Figure 6-5. Network Enterprise Diagram
The placement of a NST Honeypot probe within the DMZ security zone: 1 can be used
as an offensive measure to protect and track the ever present hacker community.
Notes
145
146
Chapter 7. Using VPNs With NST
Overview
This chapter will explore the use of configuring various Virtual Private Network
(VPN) connection types with NST. A VPN allows two private networks to be connected over a publicly-accessible network (Ex: Public Internet). Typically the VPN is
built using a secure tunnel so that the privacy of the data is preserved. It is important to also discuss effective throughput rates and overhead associated with the VPN
tunnel. These topics will also be reviewed in this chapter.
The first VPN network configuration type we will cover consists of setting up a VPN
by tunneling the Point-To-Point (PPP) layered protocol over a Secured Shell (SSH)
session. The second VPN type uses the Secure Wide Area Network (S/WAN) project:
FreeS/WAN. The FreeS/WAN is an implementation of IPSEC (Internet Protocol SECurity) and IKE (Internet Key Exchange) for Linux.
The VPN PPP Tunneled Over SSH Script: vpn-pppssh
NST comes with a script to easily setup a VPN using PPP tunnelled over a SSH session. Host and user authentication is accomplished with public-key cryptography.
Default keys for user: root and user: vpn were created during the NST build process.
[root@probe root]# /usr/local/bin/vpn-pppssh -h
Usage: vpn-pppssh -r <remote NST hostname | IP address>
-s <remote server VPN IP address>
-c <local client VPN IP address>
[-u <user name>] [-p <remote sshd port>]
[-rt [-sn <remote server network>]
[-sn-if <remote server network interface>]
[-cn <local client network>]
[-cn-if <local client network interface>]] [-nt] [-v] [-h]
vpn-pppssh -r <remote NST hostname | IP address>
-td <remote server VPN PPP interface> [-st] [-v] [-h]
The first form of the vpn-pppssh script initiates a secure VPN
connection using PPP tunneled over a SSH session between two NST
probe systems. You may enable "IP Forwarding" and "Proxy Arp" on
both systems with the "-rt" command line switch. This will allow
hosts on both sides of the VPN networks to route packets over the
secure VPN tunnel.
The second form of the vpn-pppssh script tears down an established
VPN connection using PPP over a ssh session between two NST probe systems.
This is invoked with the "-td <remote server VPN ppp interface>" command
line parameter.
The remote NST system may be referred to as the server side and the local
NST system may be referred to as the client side of the VPN respectively.
-r <remote NST hostname | IP address> |
--remote-nst-host <remote NST hostname | IP address>
This is the remote NST Fully Qualified Domain Name (FQDN) hostname or
IP address (public internet address). This may be a NATed address.
-s <remote VPN IP address> | --server-IP <remote VPN IP address>
This is the IP address of the remote PPP endpoint - IP address we need to
assign at the NST system that is passively waiting for an incoming VPN
connection (remote server side).
147
-c <local VPN IP address> | --client-IP <local VPN IP address>
This is the IP address of the local PPP endpoint - IP address we need to
assign at the NST system that initiates the VPN connection (local client
side).
-u <user name> | --user <user name>
Optional user name that run the VPN tunnel (/usr/sbin/pppd) on the
server side of the connection.
Default value: vpn
-p <remote sshd port> | --port <remote sshd port>
Optional port value that sshd is running on the remote server side of the VPN
connection.
Default value: 22
-rt | --enable-ip_forward_proxy
Optional switch to enable "IP Forwarding" and "Proxy Arp" on both the
client and server NST systems. This will enable hosts on both sides of the
VPN networks to route packets over the secure VPN tunnel. If this switch is
not used, only the two NST probes will be able to send network packet between
themselves over the VPN tunnel.
-sn <remote server network> | --remote-server-net <remote server network>
If the "-rt" switch is set, this value is the network address of the remote
server system in Classless Inter-Domain Routing (CIDR) format. A static route
is configured on the client (local) VPN host to point to this remote server
network. This will allow hosts on the client’s network to route packets to
the remote server network through the client VPN host.
Example: 10.133.140.0/24
-sn-if <remote server network interface> |
--remote-server-net-int <remote server network interface>
Optional value for the interface that the remote server network is physically
located on.
Default value: eth0
-cn <local client network> | --local-client-net <local client network>
If the "-rt" switch is set, this value is the network address of the local
client system in Classless Inter-Domain Routing (CIDR) format. A static route
is configured on the server (remote) VPN host to point to this local client
network. This will allow hosts on the server’s network to route packets to
the local client network through the server VPN host.
Example: 192.168.1.0/24
-cn-if <local client network interface> |
--local-client-net-int <local client network interface>
Optional value for the interface that the local client network is physically
located on.
Default value: eth0
-nt | --no-tcpip-timestamp
This optional switch disables the TCP/IP timestamp option (RFC 1323: "TCP
Extensions for High Performance") on all TCP/IP packets. The TCP/IP timestamp
option adds 12 additional bytes in the TCP/IP header for each TCP/IP packet.
By default Linux enables the TCP/IP timestamp option.
** WARNING: This is a global setting and effects all subsequent TCP sessions on
this local system. This setting is only applied on the local
system and not on the remote system. During the TCP/IP SYN/ACK
process this option is negotiated.
-td <remote server VPN PPP interface> | --teardown <remote server VPN PPP interface>
Second form of the vpn-pppssh script that tears down an established
VPN connection using PPP over a ssh session between two NST probe systems. The
remote server VPN PPP interface value is the name of network interface at the
remote server VPN PPP endpoint.
148
Example: ppp0
-st | --tcpip-timestamp
This optional switch enables the TCP/IP timestamp option on the local client
system. It is used with the second form: (VPN teardown "-td") for re-enabling
TCP/IP timestamps that may have been disabled during the VPN setup.
-v | --verbose
This optional switch will enable verbose mode. More information on the execution
of setting up and tearing down a VPN tunnel will be displayed. Also useful
routing information for the client and server side networks wil be displayed.
-h | --help
**Example 1)
vpn-pppssh -r 24.99.159.194 -s 172.18.1.31 -c 172.18.1.32 -rt
-sn 172.18.1.0/24 -sn-if eth1 -cn 172.29.1.0/24 -v -nt
- This example sets up a VPN using PPP over SSH between the
private RFC 1918 client network: "172.29.1.0/24" and server
network: "172.18.1.0/24". The VPN PPP network endpoints are:
local: "172.18.1.32" and remote: "172.18.1.31". The public
Internet IP address of the remote NST probe is: "24.99.159.194".
Both "IP Forwarding" and "Proxy Arp" will be enabled. The
network interface of the associated remote server network
is: "eth0". Verbose mode is enabled and TCP/IP timestamps are
disabled.
**Example 2)
vpn-pppssh -r 12.111.33.44 -td ppp0 -st
- This example tears down a VPN session enabled on the remote
NST system at public IP address: "12.111.33.44" for PPP interface:
"ppp0". TCP/IP timestamps are re-enabled if previously disabled.
**Note 1) The environment variable: "LOCAL_SSH_OPTS" is used for any user
specific ssh options.
Ex: export LOCAL_SSH_OPTS "-qC"
- enable quiet mode and compression...
**Note 2) This script requires the use of public/private key authentication
via ssh for logging into the remote NST system. The public key for
the client NST "root" user must be found in the remote NST system’s
"/root/.ssh/authorized_keys" for both the "root" and "VPN" user.
If one uses the [-v] verbose option, useful client and server network routing information will be displayed for each of the major Operating Systems. An example output
for setting up a VPN using PPP over a SSH session is shown below.
This example sets up a VPN using PPP over SSH between the private RFC 1918
client network (Satellite Office): "192.168.1.0/24" and server network (Corporate
Headquarters): "172.18.2.0/24". The VPN PPP network endpoints are: local:
"172.18.2.32" and remote: "172.18.2.31". The public Internet IP address of the
remote NST probe at the corporate site is: "70.22.33.10" using Port Address
Translation (PAT): "70.22.33.10:20022" <=> "172.18.2.50:22" for the SSH service. Both
"IP Forwarding" and "Proxy Arp" will be enabled. The network interface of the
associated remote server network is: "eth0". TCP/IP timestamps will be disabled.
This example is graphically layed out in Figure 7-1.
[root@probe root]# vpn-pppssh -r 70.22.33.10 -p 20022 \
149
-s 172.18.2.31 -c 172.18.2.32 -rt -sn 172.18.2.0/24 -cn 192.168.1.0/24 -nt -v
Success: updated /root/.ssh/authorized_keys for root on 70.22.33.10
Success: updated /home/vpn/.ssh/authorized_keys for vpn on 70.22.33.10
Starting a VPN connection to NST: 70.22.33.10
*** Disable TCP/IP timestamps on local client: 192.168.1.51...
/sbin/sysctl -w net.ipv4.tcp_timestamps=0
net.ipv4.tcp_timestamps = 0
/usr/sbin/pppd updetach noauth passive pty "/usr/bin/ssh -p 20022 70.22.33.10 -lvpn \
-o Batchmode=yes sudo /usr/sbin/pppd nodetach notty noauth" ipparam \
vpn 172.18.2.32:172.18.2.31
Using interface ppp0
Connect: ppp0 <--> /dev/ttyp1
Deflate (15) compression enabled
local IP address 172.18.2.32
remote IP address 172.18.2.31
A PPP connection was established to remote server: 70.22.33.10 on interface: ppp0
#################################################################################
########################### Client Side VPN Parameters ##########################
#################################################################################
*** Setup client side route on NST probe: 192.168.1.51...
--------------------------------------------------------------------------------/sbin/route -v add -net 172.18.2.0/24 gw 172.18.2.32 metric 1
--------------------------------------------------------------------------------*** Enabling "IP Forwarding" and "Proxy Arp" on client side...
--------------------------------------------------------------------------------/sbin/sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
/sbin/sysctl -w net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.eth0.proxy_arp = 1
--------------------------------------------------------------------------------*** Client side route info...
--------------------------------------------------------------------------------Kernel IP routing table
Destination
Gateway
Genmask
Flags
MSS Window irtt Iface
172.18.2.31
*
255.255.255.255 UH
0 0
0 ppp0
192.168.1.0
*
255.255.255.0
U
0 0
0 eth0
172.18.2.0
172.18.2.32
255.255.255.0
UG
0 0
0 ppp0
127.0.0.0
*
255.0.0.0
U
0 0
0 lo
default
192.168.1.1
0.0.0.0
UG
0 0
0 eth0
--------------------------------------------------------------------------------*** Client side ifconfig info...
--------------------------------------------------------------------------------eth0
Link encap:Ethernet HWaddr 00:40:05:86:73:E5
lo
150
inet addr:127.0.0.1 Mask:255.0.0.0
ppp0
Link encap:Point-to-Point Protocol
inet addr:172.18.2.32 P-t-P:172.18.2.31 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
--------------------------------------------------------------------------------#################################################################################
########################### Server Side VPN Parameters ##########################
#################################################################################
*** Setup server side route on NST probe: 172.18.2.50...
--------------------------------------------------------------------------------/usr/bin/ssh [email protected] "/sbin/route -v add -net 192.168.1.0/24 gw 172.18.2.31 metric 1"
--------------------------------------------------------------------------------*** Enabling "IP Forwarding" and "Proxy Arp" on server side...
--------------------------------------------------------------------------------/usr/bin/ssh [email protected] "/sbin/sysctl -w net.ipv4.ip_forward=1"
net.ipv4.ip_forward = 1
/usr/bin/ssh [email protected] "/sbin/sysctl -w net.ipv4.conf.eth0.proxy_arp=1"
net.ipv4.conf.eth0.proxy_arp = 1
--------------------------------------------------------------------------------*** Server side route info...
--------------------------------------------------------------------------------Kernel IP routing table
Destination
Gateway
Genmask
Flags
MSS Window irtt Iface
172.18.2.32
*
255.255.255.255 UH
0 0
0 ppp0
172.18.2.0
*
255.255.255.0
U
0 0
0 eth0
192.168.1.0
172.18.2.31
255.255.255.0
UG
0 0
0 ppp0
127.0.0.0
*
255.0.0.0
U
0 0
0 lo
default
172.18.2.1
0.0.0.0
UG
0 0
0 eth0
--------------------------------------------------------------------------------*** Server side ifconfig info...
--------------------------------------------------------------------------------eth0
Link encap:Ethernet HWaddr 00:0A:E6:5A:B9:19
RX bytes:11378048 (10.8 Mb) TX bytes:18138136 (17.2 Mb)
lo
inet addr:127.0.0.1 Mask:255.0.0.0
ppp0
Link encap:Point-to-Point Protocol
inet addr:172.18.2.31 P-t-P:172.18.2.32 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
151
RX bytes:246 (246.0 b)
TX bytes:252 (252.0 b)
--------------------------------------------------------------------------------Use the following static route commands on systems with the major Operating Systems
shown so that network traffic may be properly routed between the client and server
networks over the established secure VPN.
Route Commands For VPN Client Side Systems To Network: (172.18.2.0/24)
==============================================================================
Linux:
-----/sbin/route -v add -net 172.18.2.0/24 gw 192.168.1.51 metric 1
Windows:
-------C:\WINDOWS\system32\route ADD 172.18.2.0 MASK 255.255.255.0 192.168.1.51 METRIC 1
Sun:
---/usr/sbin/route add -net 172.18.2.0/24 192.168.1.51
Route Commands For VPN Server Side Systems To Network: (192.168.1.0/24)
==============================================================================
Linux:
-----/sbin/route -v add -net 192.168.1.0/24 gw 172.18.2.50 metric 1
Windows:
-------C:\WINDOWS\system32\route ADD 192.168.1.0 MASK 255.255.255.0 172.18.2.50 METRIC 1
Sun:
---/usr/sbin/route add -net 192.168.1.0/24 172.18.2.50
--------------------------------------------------------------------------------Command to tear down the VPN tunnel: vpn-pppssh -r 70.22.33.10 -td ppp0 -st
---------------------------------------------------------------------------------
VPN: PPP Tunneled Over SSH
Figure 7-1 demonstrates the use of extending Corporate CIFS (SMB) file services to a
remote satellite office securely over the untrusted public Internet.
152
Figure 7-1. VPN: PPP tunneled over SSH
At the corporate site Port Address Translation (PAT) is used to protect the standard
IANA (Internet Assigned Numbers Authority) port assign to the SSH daemon (ie.
port: 22 is mapped to port: 20022 on the public Internet side).
VPN: Tunnelling Multiple PPP Links Over SSH
Multiple VPN PPP tunnels over SSH can be setup as shown in Figure 7-2.
153
Figure 7-2. Multiple VPN PPP tunnels over SSH
At the corporate site all static routes for the established PPP links can be added at
default layer 3 routing device.
VPN: PPP Tunneled Over SSH Overhead Discussion
This section discusses the packet overhead associated with using a PPP over SSH
VPN tunnel. We will use a UDP DNS query packet to examine the average packet
overhead. The DNS lookup utility: dig (domain information groper) is used to generate the DNS query packet. The network diagram shown in Figure 7-3 will be used as
the reference network setup for the overhead discussion. A VPN tunnel is establish
between 2 private networks through host probe: A (10.222.222.84) and host probe: B
(172.16.1.77). The dig command: "dig @172.16.1.20 thunder.unifiedholdings.com" is issued on host: probe: A
154
Figure 7-3. VPN: PPP tunneled over SSH: packet flow through the IP stacks
(Network Diagram)
Figure 7-4 demonstrates the flow through the IP stacks that the DNS query packet
must traverse before physically being sent out the network adapter on probe: A network interface: eth0 to the VPN tunnel. The blue shaded area shown on the network
diagram in Figure 7-3 graphical represents the extent of the packet flow discussion.
When the packet reaches the VPN tunnel endpoint at probe: B, it will be decrypted,
uncompressed, and then forwarded to the DNS server: 172.16.1.20.
Figure 7-4. VPN: PPP tunneled over SSH: packet flow through the IP stacks
We have used the ethereal1 network protocol analyzer to capture the packet on both
the network interface: eth0 and virtual interface: ppp0 on probe: A.
155
Frame 1 (89 bytes on wire, 89 bytes captured)
Arrival Time: Feb 2, 2004 09:57:24.410147000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 89 bytes
Capture Length: 89 bytes
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 512
Link-layer address length: 0
Source: <MISSING>
Protocol: IP (0x0800)
Internet Protocol, Src Addr: 172.16.1.34 (172.16.1.34), Dst Addr: THUNDER (172.16.1.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 73
Identification: 0x0000 (0)
Flags: 0x04
.1.. = Don’t fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xe04d (correct)
Source: 172.16.1.34 (172.16.1.34)
Destination: THUNDER (172.16.1.20)
User Datagram Protocol, Src Port: 32770 (32770), Dst Port: domain (53)
Source port: 32770 (32770)
Destination port: domain (53)
Length: 53
Checksum: 0x5e49 (correct)
Domain Name System (query)
Transaction ID: 0x1db9
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
thunder.unifiedholdings.com: type A, class inet
Name: thunder.unifiedholdings.com
Type: Host address
Class: inet
0000
0010
0020
0030
0040
0050
00
45
ac
00
0f
03
04
00
10
01
75
63
02
00
01
00
6e
6f
00
49
14
00
69
6d
00
00
80
00
66
00
00
00
02
00
69
00
99
40
00
00
65
01
08
00
35
00
64
00
80
40
00
07
68
01
00
11
35
74
6f
00
e0
5e
68
6c
00
4d
49
75
64
Figure 7-5. Ethereal capture: interface ppp0
156
68
ac
1d
6e
69
ff
10
b9
64
6e
08
01
01
65
67
00
22
00
72
73
............h...
E..I..@[email protected]..."
.......5.5^I....
.........thunder
.unifiedholdings
.com.....
Since both captures occured on the same NST probe, one can use the the packet arrival time difference as an estimation of the delay for sending out the DNS query
packet to the network on interface: eth0. The packet arrival time difference is: 0.295
msecs ((eth0: 09:57:24.410442000) - (ppp0: 09:57:24.410147000)). This time difference
represents CPU process time for compression and flow through the PPP IP stack.
Frame 6 (130 bytes on wire, 130 bytes captured)
Arrival Time: Feb 2, 2004 09:57:24.410442000
Time delta from previous packet: 0.592448000 seconds
Time since reference or first frame: 0.592448000 seconds
Frame Number: 6
Packet Length: 130 bytes
Capture Length: 130 bytes
Ethernet II, Src: 00:40:05:86:73:e5, Dst: 00:e0:1e:5c:d5:f2
Destination: 00:e0:1e:5c:d5:f2 (Cisco_5c:d5:f2)
Source: 00:40:05:86:73:e5 (AniCommu_86:73:e5)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.222.222.84 (10.222.222.84), Dst Addr: rrcs-nys-24-97-150-194.biz.
Version: 4
Differentiated Services Field: 0x08 (DSCP 0x02: Unknown DSCP; ECN: 0x00)
0000 10.. = Differentiated Services Codepoint: Unknown (0x02)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 116
Identification: 0xccaa (52394)
Flags: 0x04
.1.. = Don’t fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xd57b (correct)
Source: 10.222.222.84 (10.222.222.84)
Destination: rrcs-nys-24-97-150-194.biz.rr.com (24.97.150.194)
Transmission Control Protocol, Src Port: 32785 (32785), Dst Port: 22 (22), Seq: 0, Ack: 0, Len: 6
Source port: 32785 (32785)
Destination port: 22 (22)
Sequence number: 0
Next sequence number: 64
Acknowledgement number: 0
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 15776
Checksum: 0xa0bc (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 7922224, tsecr 24160092
SSH Protocol
Encrypted Packet: 1F42744747E7C197CF8DB7B548BA0DA3...
0000
0010
0020
0030
00
00
96
3d
e0
74
c2
a0
1e
cc
80
a0
5c
aa
11
bc
d5
40
00
00
f2
00
16
00
00
40
77
01
40
06
f2
01
05
d5
7c
08
86
7b
20
0a
73
0a
79
00
e5
de
a6
78
08
de
07
e2
00
54
88
30
45
18
80
01
08
61
18
70
...\[email protected].
.t..@.@..{...T.a
......w.| y.....
=..........x.0.p
157
0040
0050
0060
0070
0080
a7
0d
64
ee
62
5c
a3
04
ce
68
1f
52
e3
57
42
3e
b4
c5
74
de
4f
1d
47
dc
bc
a1
47
07
ea
29
e7
48
32
68
c1
65
00
83
97
62
ee
1a
cf
4e
22
6a
8d
b2
bc
91
b7
cd
1b
6c
b5
92
43
0e
48
86
07
b2
ba
5a
60
1f
.\.BtGG.......H.
..R>...HebN....Z
d...O..2.."..C.‘
..W...)h..j.l...
bh
Figure 7-6. Ethereal capture: interface eth0
The lower portion of Figure 7-4 shows a breakout of the size of the DNS query packet
as it flows through the IP stacks. In this example, the DNS query packet is actually
being compressed by the PPPD Deflate compression scheme and packaged by the SSH
protocol as a 64 byte payload. The compression algorithm used by the PPPD daemon
helps erase some of the overhead sized added by tunnelling the packet through the
SSH session. If this DNS query was sent directly to the eth0 network interface, the
packet size would be: 87 bytes (DNS (45B) + UDP (8B) + IP (20B) + Link (14B)). So
for this example an extra 42 bytes of data was necessary to tunnel the DNS query
securely through the VPN.
Data that can be compressed (ie. text) can actually be passed through the VPN tunnel
at effective rates that erase all overhead associated with this type of VPN tunnel. It
really depends on the entropy of the data. I have measured some throughput rates
using the measurement tool: TTCP2 with this type of tunnel that have provided a 32
times increase.
VPN: PPP Tunneled Over SSH Effective Throughput Rate
Discussion
It is important to know the effective data throughput performance and rates when
using a TCP/IP VPN tunnel created with PPP over an SSH session. I will take a stepwise approach in explaining how I determined these rates using NST probe systems,
various networking equipment, and software benchmarking tools. I tried to follow
many of the methods described in RFC 2544 "Benchmarking Methodology for Network
Interconnect Devices".
To get started some background information is appropriate. Communication
between computers using TCP/IP takes place through the exchange of packets. A
packet is a PDU (Protocol Data Unit) at the IP layer. The PDU at the TCP layer is
called a segment while a PDU at the data-link layer (such as Ethernet) is called a
frame. However the term packet is generically used to describe the data unit that is
exchanged between TCP/IP layers as well as between two computers.
First, one needs to know the maximum performance of the network environment
to establish a baseline value. I will be using a switched Fast Ethernet (IEEE 802.3u)
network configuration. I chose this configuration because it is a common network
topology used in today’s enterprise internetworking environments.
Frames per second (FPS) or Packets per second (PPS) is a common method of rating
the throughput performance of a network device. Understanding how to calculate
frames per second can provide a lot of insight on how the Ethernet system functions
and assists you in network design.
In this section we will calculate the theoretical maximum frames per second of an Fast
Ethernet (100Mb/sec) segment. The calculation is considered theoretical because it
requires a network segment without collisions and a standard packet length. Today’s
network switches allow us to achieve these theoretical limits by providing Full Duplex capability. Also, Ethernet data size relies on the upper layer application, so it is
very unlikely to find a stream of packets with exactly the same size in an Ethernet
network.
Figure 7-7 shows the components that make up a Fast Ethernet TCP/IP datagram
frame. The minimum frame payload is 46 Bytes (dictated by the slot time of the Eth158
ernet LAN architecture). The maximum frame payload is 1500. The maximum frame
rate is achieved by a single transmitting node which does not therefore suffer any collisions. This implies a frame consisting of 72 Bytes with a 960 nanosecond inter-frame
gap (corresponding to 12 Bytes at 100Mb/sec).
**Note: Typically protocol analyzers or network monitoring tools do not capture the Ethernet’s
"Frame Check Sequence" or (Cyclic Redundancy Check (CRC)). The minimum frame length
is usually reported as 60 bytes and the maximum length is reported at a 1514 bytes (using the
normal Ethernet Maximum Transmission Unit (MTU) = 1500 (RFC 894)).
Figure 7-7. VPN: PPP tunneled over SSH: Fast Ethernet Maximum Throughput
Rates
The calculation for the maximum framing rate of Fast Ethernet is also shown in Figure 7-7. For the minimum TCP/IP payload frame the maximum theoretical rate is
148,810 FPS. For the maximum TCP/IP payload frame the maximum theoretical rate
is 8,127 FPS.
The inter-frame gap timing is set to 96 bit times for all types of Ethernet. Bit time is
defined as the amount of time required to send one data bit on the network.
Although not shown, the inter-frame gap times for Ethernet (10Mb/sec)(IEEE 802.3)
and Gigabit Ethernet (1000Mb/sec) (IEEE 802.3z) are 9.6 microseconds and 96
nanoseconds respectively. The maximum theoretical Ethernet Framing rate for the
minimum TCP/IP payload frame is 14,881 FPS. The maximum theoretical Gigabit
Ethernet Framing rate for the minimum TCP/IP payload frame is 1,488,100 FPS.
Effective Throughput Rate: NST Probe - NST Probe Same Fast
Ethernet LAN Segment
Lets measure the actual data transmission rate on a LAN segment between 2 NST
probe systems. The network topology for determining the rate can be found in Figure
7-8
159
Figure 7-8. VPN: PPP tunneled over SSH: Effective data rate: NST Probe - NST
Probe same LAN segment
The TTCP3 measurement tool was choosen to determine the TCP/IP transfer rate
between Probe: A and Probe: B. A fair amount of data was transferred (ie: 4096 buffers
at a length of 8192 bytes each resulting in a 33554432 byte transfer).
Actual results from the TTCP4 tool on Probe: A (10.222.222.84). 33 MBytes of text-based
data was transferred in 2.85 seconds.
TTCP Results: Transfer Data From: 10.222.222.84
==== ======== ======== ==== ===== =============
[root@probeA tmp]# /usr/bin/ttcp -t -s -n 4096 10.222.222.87
ttcp-t: socket
ttcp-t: connect
ttcp-t: buflen=8192, nbuf=4096, align=16384/0, port=5001 tcp -> 10.222.222.87
ttcp-t: 33554432 bytes in 2.85 real seconds = 11486.27 KB/sec +++
ttcp-t: 4096 I/O calls, msec/call = 0.71, calls/sec = 1438.24
ttcp-t: 0.0user 0.0sys 0:02real 1% 0i+0d 0maxrss 1+2pf 0+0csw
Actual results from the TTCP5 tool on Probe: B (10.222.222.87).
TTCP Results: Receive Data On: 10.222.222.87
==== ======== ======= ==== === =============
[root@probeB tmp]# /usr/bin/ttcp -r -s
ttcp-r: socket
ttcp-r: accept from 10.222.222.84
ttcp-r: buflen=8192, nbuf=4096, align=16384/0, port=5001 tcp
ttcp-r: 33554432 bytes in 2.85 real seconds = 11486.27 KB/sec +++
ttcp-r: 23172 I/O calls, msec/call = 0.13, calls/sec = 8122.55
ttcp-r: 0.0user 0.3sys 0:02real 11% 0i+0d 0maxrss 0+1pf 0+0csw
TTCP6 reports its default data rate in 1024(K) Bytes(B) per sec (KB/sec) units. The actual
decimal data rate reported by TTCP7 on Probe: A is 11486.27 KB/sec * 1.024 = 11,761,940
Bytes/sec. Compare this value to the theoretical maximum rate for Fast Ethernet with a
TCP/IP payload of 1448 bytes: 11,767,896 Bytes/sec (with TCP/IP timestamp) as shown
in Figure 7-7. For all practical purposes, these typical NST probes can transfer data at
the Fast Ethernet wire speed.
By default, Linux has the TCP/IP timestamp option turned on "RFC 1323: TCP Extensions for High Performance" to improve performance over large bandwidth*delay
product paths and to provide reliable operation over very high-speed paths. The
TCP/IP option adds 12 bytes of TCP header information to each TCP/IP packet. By
160
turning off this option, more data traffic can be squeezed into the TCP/IP payload.
One can turn off this option for all subsequent TCP/IP traffic with the following
command run as root:
[root@probeA tmp]# echo 0 > /proc/sys/net/ipv4/tcp_timestamps
My experience with this option disabled for local and broadband internet connectivity has not shown any network performance degradation. The "-nt" or "--no-tcpiptimestatmp" command line switch option can be used with the vpn-pppssh script to
disable TCP/IP timestamping.
Next another test using TTCP8 was accomplished over the same Fast Ethernet LAN
segment. This time the TCP/IP timestamp option was disabled on both NST Probe: A
and Probe: B. The results are now presented:
Actual results from the TTCP9 tool on Probe: A (10.222.222.84) - no TCP/IP timestamps.
33 MBytes of text-based data was transferred in 2.83 seconds..
TTCP Results: Transfer Data From: 10.222.222.84 TCP/IP Timestamps Disabled
==== ======== ======== ==== ===== ============= ====== ========== ========
[root@probeA tmp]# /usr/bin/ttcp -t -s -n 4096 10.222.222.87
ttcp-t: socket
ttcp-t: connect
Actual results from the TTCP10 tool on Probe: B (10.222.222.87) - no TCP/IP timestamps.
TTCP Results: Receive Data On: 10.222.222.87 TCP/IP Timestamps Disabled
==== ======== ======= ==== === ============= ====== ========== ========
ttcp-r: socket
The results for this test with the TCP/IP timestamp option disabled are now discussed. The actual decimal data rate reported by TTCP11 on Probe: A is 11582.06 KB/sec
* 1.024 = 11,860,029 Bytes/sec. Compare this value to the theoretical maximum rate
for Fast Ethernet with a TCP/IP payload of 1460 bytes: 11,865,420 Bytes/sec (with no
TCP/IP timestamp) as shown in Figure 7-7. Once again the transfer rate between these
NST probes is practically Fast Ethernet wire speed.
With the TCP/IP timestamp disabled, our results show that an additional 103,480
Bytes/sec (11,865,420 - 11,761,940) can be sent.
A secondary method for determining the actual TCP/IP transfer rate between the
probe systems was done. Cisco offers a network monitoring feature called the
Switched Port Analyzer (SPAN) on its Switch equipment. One can see from Figure 7-8
that all network traffic on Fast Ethernet port: 8 is being monitored by Fast Ethernet
port: 21 using SPAN.
161
A high-end Linux Redhat System (2 x Intel Xeon 2.8GHz) was used to monitor the
SPAN traffic using ethereal12 (Version: 0.10.0). The ethereal13 summary view for
the TCP/IP traffic captured is shown in Figure 7-9. At the maximum Fast Ethernet
transfer rate, no packet lossdt was detected with the capture while using this equipment. This capture took place at the identical time we tested the maximum TCP/IP
transfer rate with the TCP/IP timestamp option disabled.
Figure 7-9. VPN: PPP tunneled over SSH: Ethereal capture summary view
From this summary one can see the high utilization of the Fast Ethernet bandwidth.
An ethereal14 display filer was used to focus on data packets associated only with
the NST probe systems. In the "Data in filtered packets" section, the "Avg. Mbit/sec"
value is: 97.686. Ethereal does not count the "Frame Check Sequence" (CRC) - Cyclic
Redundancy Check 4 byte value. A quick calculation of adding the CRC (4 Bytes
per packet) and equivalent Inter-Frame Gap (12 Bytes per packet) data value to the
"Avg. Mbit/sec" results in a new average value of: 99.20 Mbit/sec = (12,210,700 +
((4+12)*11,869))/12,500,000) * 100Mbit/sec.
Effective Throughput Rate: NST Probe - NST Probe On Different
Fast Ethernet LAN Segments (2 VLANs)
Next we will measure the actual effective data transmission rate between 2 NST
probe systems across a network segment boundary. 2 VLANs were created within a
Layer 3 (L3) Gigabit managed switch: (S2) (D-Link DGS-3308TG). The network topology for this benchmarking measurement can be found in Figure 7-10. As one can see
from the results below, packets transmitted by Probe: A, switched through Layer 2
(L2) switch: (S1), routed throught L3 switch: (S2), switched throught L2 switch: (S3),
and received by Probe: B approach the theoretical Fast Ethernet wire speed.
This result is important because when we benchmark the throughput rate across a
network segment using a PPP over SSH VPN we need to know that the infrastructure
networking gear is not causing any unknown bottlenecks in the measurement.
162
Figure 7-10. VPN: PPP tunneled over SSH: Throughput Rate: NST Probe - NST
Probe Different LAN Segments (2 VLANs)
Actual results from the TTCP15 tool on Probe: A (10.222.222.86) - Transverse network
segment boundary with no TCP/IP timestamps. 67 MBytes of text-based data was transferred
in 5.70 seconds.
TTCP Results: Transmit Data From: 10.222.222.86 TCP/IP Timestamps Disabled
==== ======== ======== ==== ===== ============= ====== ========== ========
[root@probeA tmp]# ttcp -t -s -n 8192 10.222.221.101
ttcp-t: socket
ttcp-t: connect
Actual results from the TTCP16 tool on Probe: B (10.222.221.101) - Transverse network
segment boundary with no TCP/IP timestamps.
TTCP Results: Receive Data On: 10.222.221.101 TCP/IP Timestamps Disabled
==== ======== ======= ==== === ============== ====== ========== ========
ttcp-r: socket
Remember TTCP17 reports its default data rate in 1024(K) Bytes(B) per sec (KB/sec)
units, therefore the actual decimal data rate reported by TTCP for this benchmarking
measurement was: 11505.45 KB/sec * 1.024 = 11782 KB/sec.
Effective Throughput Rate: NST Probe - NST Probe On Different
Fast Ethernet LAN Segments (2 VLANs) Using a PPP Tunneled
Over SSH VPN
Finally we will measure the actual effective data transmission rate using a PPP tunneled over SSH VPN between 2 NST probe systems across a network segment bound163
ary. Once again 2 VLANs were created within a Layer 3 (L3) Gigabit managed switch:
(S2) (D-Link DGS-3308TG). The network topology for this benchmarking measurement can be found in Figure 7-11.
Different data types will be transmitted over the VPN so that the results could match
that of typical real-world data traffic environments. We will benchmark text-based
transfers, compressed file data transfers (bzip2 format), and SMB file system transfers.
Packets will be transmitted by Probe: A through the VPN and eventually received by
Probe: B.
First we need to setup the VPN. Redhat Linux host: 10.222.222.14 on VLAN: 222 and
NST Probe: C (10.222.221.100) on VLAN: 221 will form the endpoints of the VPN. The
following parameters to the "vpn-pppssh" script are used to setup the VPN on Redhat
Linux host: 10.222.222.14:
[root@redhat tmp]# vpn-pppssh -r 10.222.221.100 -s 10.222.222.31 -c 10.222.222.32 -rt -sn 10.222.22
-cn 10.222.222.0/24 -v -nt
Figure 7-11. VPN: PPP tunneled over SSH: Effective data Rate: NST Probe - NST
Probe different LAN segments (2 VLANs) over the VPN
**Note: The network route to VLAN: 221 for Redhat Linux host: 10.222.222.14 is
"10.222.222.4". The network route to VLAN: 221 for Probe: A is through: "10.222.222.14".
The network route to VLAN: 222 for NST Probe: C is "10.222.221.1". Lastly, the network
route to VLAN: 222 for Probe: B is through: "10.222.221.100".
Now that the VPN has been established, we will examine the results of sending textbased data over the VPN between 2 NST probe systems using TTCP18.
Actual results from the TTCP19 tool on Probe: A (10.222.222.86) - Transverse network
segment boundary with no TCP/IP timestamps. 67 MBytes of text-based data was transferred
in 5.87 seconds.
TTCP (TEXT DATA) Results: Transmit Data From: 10.222.222.86 TCP/IP Timestamps Disabled
==== ===== ===== ======== ======== ==== ===== ============= ====== ========== ========
[root@probeA tmp]# ttcp -t -s -n 8192 10.222.221.101
ttcp-t: socket
ttcp-t: connect
164
segment boundary with no TCP/IP timestamps.
TTCP (TEXT DATA) Results: Receive Data On: 10.222.221.101 TCP/IP Timestamps Disabled
==== ===== ===== ======== ======= ==== === ============== ====== ========== ========
ttcp-r: socket
From the TTCP21 results, one can see that a high effective data rate can be acheived
when sending text-based data through the VPN. The pppd daemon uses a "deflate"
compression scheme which is very effective with text-based data. By default this
compression scheme is enabled when starting up the pppd daemon which is called
by the "vpn-pppssh" script.
The next benchmark test will be to send a 6 MByte "bzip2" compressed file over the
VPN from Probe: A (10.222.222.86). This transfer took 1.06 seconds.
TTCP (COMPRESSED FILE) Results: Transmit Data From: 10.222.222.86 TCP/IP Timestamps Disabled
==== =========== ===== ======== ======== ==== ===== ============= ====== ========== ========
[root@probeA tmp]# ttcp -t 10.222.221.101 < /tmp/xxx.bz2
ttcp-t: socket
ttcp-t: connect
segment boundary with no TCP/IP timestamps. These results reflect the compressed file
being transferred.
TTCP (COMPRESSED FILE) Results: Receive Data On: 10.222.221.101 TCP/IP Timestamps Disabled
==== =========== ===== ======== ======= ==== === ============== ====== ========== ========
[root@probeB tmp]# /usr/bin/ttcp -r > /tmp/xxx.bz2
ttcp-r: socket
Since the source of the data to be transferred is compressed to start with, the pppd
daemon’s "deflate" compression scheme will not increase the effective data throughput rate. These results can serve as the baseline for the lower end of the effective
165
data throughput rate over the VPN when the data to be transferred is primarily compressed. For this benchmark measurement, the effective thoughput rate for transferring compressed data over the VPN is slightly less than one-half of the maximum
theoretical Fast Ethernet line speed.
Many factors contibute to the results of this effective data throughput rate for transferring compressed data over the VPN: 1) overhead associated with the tunnelling
data (discussed above); 2) simultaneous TCP/IP acknowledgements to both the file
transfer sender and VPN end-point recipient occurring on the same physical network
interface; and 3) inherent delays associated with routing packets within the Linux OS
between different network interfaces (i.e. ppp0 <=> eth0).
Our final benchmarking test will consist of sending the SMB (Service Message Block)
protocol or the Common Internet File System (CIFS), LanManager, or NetBIOS protocol over the VPN. The network topology for this measurement is shown in Figure
7-12.
Probe different LAN segments (2 VLANs) over the VPN for SMB file services
The notebook system (NIC0: 10.222.222.18) has been changed back to running the
Windows XP Professional OS. We will start up Samba on Probe: B and send files using
SMB over the VPN.
The protocol analyzer ethereal23 was used on the Redhat Linux system to capture
packets on network interface "eth1". Once again this interface did not have an assigned binding IP address, thus it was in "stealth" mode. Network interface "eth1"
was connected to a SPAN port: 21 on Switch: S1. This SPAN port: 21 was configured to
monitor all network traffic activity occurring on Switch: S1 port: 11.
The summary below Figure 7-13 describes the results from sending a 10 MByte textbased file using SMB files services from system Probe: B to the Windows XP Professional
system.
166
Probe different LAN segments (2 VLANs) over the VPN for SMB file services Ethereal capture summary: 1
Setting a display filter in ethereal24 (Version: 0.10.3) for only showing data between
hosts: 10.222.222.18 (Windows XP) and 10.222.221.10 (Probe: B) was done. The
ethereal25 display filter syntax to do this was: "ip.addr == 10.222.222.18 or ip.addr
== 10.222.221.101". The results for this display filter can be seen in the summary
window under "Data in filtered packets". This section tells us that is took 3.449
seconds to send the 10 MByte text-based file using SMB over the VPN. The file
transfer plus any SMB overhead (a total of 11116288 bytes of data) had an effective
throughput rate of 3223.30 KB/sec.
Probe different LAN segments (2 VLANs) over the VPN for SMB file services Ethereal capture summary: 2
The summary above Figure 7-14 shows the results of the same data with a different
ethereal26 display filter that focused on the VPN traffic only. The ethereal27 display
167
filter syntax to accomplish this was: "ip.addr == 10.222.222.14". The results for this
display filter can once again be seen in the summary window under "Data in filtered
packets". This section tells us that is took 3.488 seconds to send the 10 MByte textbased file over the VPN. Only 972320 bytes of data was sent over the VPN between
the two VPN end-points. It is clearly evident here that the text-based data is being
compressed by the "pppd" daemon with a factor of over 11 to 1.
In summary, the make-up or entropy of the data being sent through the PPP tunneled
over SSH VPN will dictate the effective throughput rate. Hopefully the analysis presented here can be used to determine if this type of VPN configuration is appropriate
for your environment.
VPN: FreeS/WAN IPSEC
To be written.
Notes
2. http://www.clarkson.edu/projects/itl/HOWTOS/PCATTCP-jnm20011113.htm
168
169
170
Chapter 8. Virtual Computing
Secure Virtual Computing
Secure Virtual Computing can be accomplish by tunnelling services or application
protocols within an encrypted Secure Shell (ssh) session envelope. Figure 8-1 shows
two applications; VNC and ntop that are tunnelled between a remote Satellite Office
and the associated Corporate Headquarters through a ssh session.
Figure 8-1. Secure Virtual Computing
This example also shows the use of Network and Port Address Translation (NAT) and
(PAT) at the Satellite Office Firewall.
Secure Virtual Computing With Microsoft Remote Desktop (RDP)
Two NST probes can be configured for a VPN that tunnels the Remote Desktop
Protocol (RDP) between a Terminal Services Server and a Microsoft Terminal Service
Client (mstsc) across the public Internet. Figure 8-2 demonstrates a user at the Corporate Headquarter Site A running both a desktop session on a Windows XP Professional System and a Terminal Services session running Microsoft Word on a Windows
Server 2003 which are both located at the remote Satellite Office Site B.
171
Chapter 8. Virtual Computing
Figure 8-2. Secure Virtual Computing With Microsoft Remote Desktop (RDP)
Note that in this configuration NST probe A is allowing connections to the RDP VPN
tunnels. This is accomplish by specifiying the "-g" command line option to the ssh
command.
172
Chapter 9. LDAP
The Network Security Toolkit can be used as a LDAP testing tooling.
LDAP search example
This example uses openldap’s ldap search to query an Enterprise Windows 2003
Server’s Active Directory for all users.
Search Options Used
-h Win2003AD
LDAP server (Win2003AD)
-x
Use simple authentication instead of SASL
-W
Prompt for simple authentication
-D cn=Administrator,cn=Users,dc=lab1,dc=nst,dc=com
bind
to
the
LDAP
server
with
this
distinguished
("cn=Administrator,cn=Users,dc=lab1,dc=nst,dc=com")
name:
-b cn=Users,dc=lab1,dc=nst,dc=com
Start search from this branch
("cn=Users,dc=lab1,dc=nst,dc=com")
point
in
the
directory
hierarchy:
-s sub
Use scope subtree
"cn=*"
Filter to search all names.
Command with some results.
[root@probe root]# ldapsearch -h Win2003AD -x -W \
-D "cn=Administrator,cn=Users,dc=Lab1,dc=nst,dc=com" \
-b "cn=Users,dc=lab1,dc=nst,dc=com" -s sub "cn=*"
# DnsUpdateProxy, Users, lab1, nst, com
dn: CN=DnsUpdateProxy,CN=Users,DC=lab1,DC=nst,DC=com
objectClass: top
objectClass: group
cn: DnsUpdateProxy
description: DNS clients who are permitted to perform dynamic updates on
behal f of some other clients (such as DHCP servers).
distinguishedName: CN=DnsUpdateProxy,CN=Users,DC=lab1,DC=nst,DC=com
instanceType: 4
whenCreated: 20030428181251.0Z
whenChanged: 20030428181251.0Z
uSNCreated: 12404
uSNChanged: 12404
name: DnsUpdateProxy
objectGUID:: uEZfx0w/4kyEDQjFdfq6pA==
objectSid:: AQUAAAAAAAUVAAAA7wtQ4NKtSIRuOPjVVwQAAA==
sAMAccountName: DnsUpdateProxy
sAMAccountType: 268435456
groupType: -2147483646
173
Chapter 9. LDAP
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=lab1,DC=nst,DC=com
# Ronald W. Henderson, Users, lab1, nst, com
dn: CN=Ronald W. Henderson,CN=Users,DC=lab1,DC=nst,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Ronald W. Henderson
sn: Henderson
description: Sys Admin
givenName: Ronald
initials: W
distinguishedName: CN=Ronald W. Henderson,CN=Users,DC=lab1,DC=nst,DC=com
instanceType: 4
whenCreated: 20030428185954.0Z
whenChanged: 20030509143500.0Z
displayName: Ronald W. Henderson
uSNCreated: 13905
memberOf: CN=Domain Admins,CN=Users,DC=lab1,DC=nst,DC=com
uSNChanged: 69829
name: Ronald W. Henderson
objectGUID:: BPu+7X0lvUetG1UbAujRYg==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 126974068888147426
lastLogoff: 0
lastLogon: 126974069001018408
pwdLastSet: 126969645008608914
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA7wtQ4NKtSIRuOPjVWgQAAA==
adminCount: 1
accountExpires: 9223372036854775807
logonCount: 32
sAMAccountName: rwh
sAMAccountType: 805306368
userPrincipalName: [email protected]
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=lab1,DC=nst,DC=com
174
Chapter 10. Serial Traffic Monitoring
The Network Security Toolkit can be used to monitor a physical serial connection
attached to a NST Probe by use of a customized Serial Tap Cable diagrammed in
Figure:1. Standard Linux utility programs are used to display the serial traffic being
tapped. A NST utility script: "monitor_serial" is also described to automate the process
of serial traffic monitoring.
The other day I was trying out various commands to control my Magellan Color GPS
Receiver via the serial interface. I was using the terminal emulation utility program:
"Minicom" and was not very successful. I believed I had setup Minicom (4800 baud,
no parity, 8 data bits, and 1 stop bit - 4800N81) correctly but I could not get a response from the GPS when I issued a command to it. I needed a way to see what
was occurring over the serial connection. After doing a Google Internet search, I then
realized in the Open Source World that there are very few serial monitoring utility
programs that can tap into a serial connection. The ones that I found typically required kernel modifications. Although these may be fine solutions for serial traffic
monitoring, NST is built around a standard RedHat implementation and any Kernel
modifications solutions are typically not used with NST.
Cable Construction
Based on my limited search results, I decided to take a hardware approach for my
desired solution. I created a Serial Tap Cable which is shown in Figure:1. This is a
rather simple design. Even though I am violating the RS-232 specifications by driving
more than one RS-232 receiver (DTE or DCE plus a corresponding Tap) the short
cable length of 8 inches should work in most instances. I am simply presenting the
DTE’s or DCE’s transmit date line on a corresponding tap connection which can then
be plugged into another serial port for monitoring. If your NST Probe only has one
serial port, one can use a serial over USB device.
Monitoring Session - Using Basic Linux Utility Programs
I will now demonstrate a serial monitoring session using the custom Serial Tap Cable.
The setup environment consists of a NST Probe desktop system connected to a Magellan Color GPS device on serial port: "/dev/ttyS0". See Figure: 2. I used the terminal
emulation program: "Minicom" for serial communication to the GPS. The discussion
that follows shows various monitoring techniques that can be used with standard
Linux utility programs.
175
After connecting the cable, you can use utility programs cat and hexdump to start
viewing results:
In this example the DTE Serial Tap (NST Probe) is connected to serial device:
/dev/ttyS1 and the DCE Serial Tap (Magellan Color GPS) is connected to serial
device: /dev/ttyUSB0.
First we need to setup serial communication parameters on devices: /dev/ttyS0 and
/dev/ttyUSB0. Note that these serial devices need to be put in "raw" mode with an
8 bit character length ("cs8") in order for a binary capture to occur. We do not want
any character translations occurring. If even or odd parity is required, use the parenb
and [-]parodd control setting where appropriate.
** Note: I have found that it is best to zero out all stty parameters and settings prior
to starting a capture on a serial device. With USB serial converters this is necessary
or a Kernel Panic will occur when the serial device is closed out. This is a known bug
in the USBserial Kernel Module for Kernel Version: 2.4.20-20.9. This should be fixed
in Kernel Version: 2.4.23.
A NST utility program reset_serial was written to reset a serial device’s communication parameters and settings. It uses the stty readable format. This format consist
of 36 zeroes delimitied by a colon ":"
[root@probe tmp]# /bin/stty -F /dev/ttyUSB0 \
0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Now lets initialize the serial devices for capturing serial traffic at: 4800N81.
[root@probe
[root@probe
[root@probe
[root@probe
tmp]#
tmp]#
tmp]#
tmp]#
/usr/local/bin/reset_serial /dev/ttyS1
/usr/local/bin/reset_serial /dev/ttyUSB0
/bin/stty -F /dev/ttyS1 speed 4800 raw cs8
/bin/stty -F /dev/ttyUSB0 speed 4800 raw cs8
Print out current communication parameter settings for devices: /dev/ttyS1 and
/dev/ttyUSB0:
[root@probe tmp]# /bin/stty -a -F /dev/ttyS1
speed 4800 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>;
eof = <undef>; eol = <undef>; eol2 = <undef>; start = <undef>;
stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>;
lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl
176
-noflsh -xcase -tostop -echoprt -echoctl -echoke
[root@probe tmp]# /bin/stty -g -F /dev/ttyS1
0:0:3c:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
[root@probe tmp]# /bin/stty -a -F /dev/ttyUSB0
speed 4800 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>;
eof = <undef>; eol = <undef>; eol2 = <undef>; start = <undef>;
stop = <undef>; susp = <undef>; rprnt = <undef>; werase = <undef>;
lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb -cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl
-noflsh -xcase -tostop -echoprt -echoctl -echoke
[root@probe tmp]# /bin/stty -g -F /dev/ttyUSB0
0:0:3c:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Now start your capture on device: /dev/ttyS1
[root@probe tmp]# cat < /dev/ttyS1 >| /tmp/nema_cmd_version_request.txt
Now start your capture on device: /dev/ttyUSB0
[root@probe tmp]# cat < /dev/ttyUSB0 >| /tmp/nema_cmd_version_response.txt
We will issue a Magellan private command to get the version of the GPS
device as our example for this monitoring session. The command is:
"$PMGNCMD,VERSION*28\r\n". The command is now sent within the Minicom
session.
View the actual serial data sent to the GPS device:
[root@probe tmp]# hexdump -C nema_cmd_version_request.txt
00000000
00000010
00000015
24 50 4d 47 4e 43 4d 44
2a 32 38 0d 0a
2c 56 45 52 53 49 4f 4e
|$PMGNCMD,VERSION|
|*28..|
The reason I initially could not get my GPS device to respond was that Minicom program does not append a needed Linefeed (Newline - 0x0d) character to the data sent
out the serial port when the Enter Key is pressed. I determined this from analyzing the
above serial traffic data. As you can see from the syntax of the Magellan Version Command above, the transmission protocol for Magellan GPS devices is very strict and
a Carriage Return/Linefeed termination sequence is required for all commands sent to
the GPS device. In order to send out a Linefeed character from the Minicom program,
a "Ctrl-j" key sequence needs to be typed. Once I did this the version command executed properly.
View the actual serial data received from the GPS device:
[root@probe tmp]# hexdump -C nema_cmd_version_response.txt
00000000
00000010
00000020
00000029
24 50 4d 47 4e 56 45 52
20 34 20 30 32 2c 4d 65
6f 6c 6f 72 2a 37 38 0d
2c 30 33 39 2c 56 45 52
72 69 64 69 61 6e 20 43
0a
|$PMGNVER,039,VER|
| 4 02,Meridian C|
|olor*78..|
177
Monitoring Session - Using NST Utility Program: "monitor_serial"
I found that it would be beneficial to automate the process of serial traffic data
monitoring. A bash script: "monitor_serial" was created to do this for NST. It
essentially just automates the process just described above. The big advantage with
monitor_serial beside automation is that traffic serial data will continue to be
displayed on the screen and only blocked for a user specified collection time. The
Serial Tap Cable described above is best used with the monitor_serial utility
program. The reset_serial utility is called by monitor_serial for the base
initialization.
The usage information for monitor_serial is presented:
[root@probe tmp]# /usr/local/bin/monitor_serial -h
Usage: monitor_serial -d1
[-f1
[-d2
[-n2
<1st
<1st
<2nd
<2nd
serial
serial
serial
serial
dev> [-s <usec>] [-b <baud>] [-u <"stty options">]
dev capture file>] [-n1 <1st serial dev nickname>]
dev>] [-f2 <2nd serial dev capture file>]
dev nickname>]
This utility program will monitor serial traffic for up to 2 serial devices. Data will
be collected for a user specific collection time (See: -s option). The "hexdump" utility
is then used to display the serial traffic in both the Hex and ASCII format. To exit
type the "Ctrl-c" key sequence.
-s <microseconds> | --sleep <microseconds>
Sleep value in microseconds to collect data before
sending it to the hexdump utility. Default: 500000 usecs (1/2 sec)
-b <baud rate> | --baud <baud rate>
Baud rate for the serial device. Default: 9600 baud
-u <"stty options"> | --stty-opts <"stty options">
User specified stty options must be put within double quotes:
Example (even parity): -u "parenb -parodd"
-d1 <serial dev name> | --device-1 <serial dev name>
Name of the first serial device to
to monitor: Ex: "/dev/ttyS1"
-f1 <1st capture file name> | --file-1 <1st capture file name>
Capture file full path name for the 1st serial device.
Default: /tmp/serial_capture_dev1
-n1 <1st nickname> | --nickname-1 <1st nickname>
Used to describe a more meaningful name to the first serial
device.
-d2 <serial dev name> | --device-2 <serial dev name>
Optional name of a second serial device
to monitor. Ex: "/dev/ttyUSB0"
-f2 <2nd capture file name> | --file-2 <2nd capture file name>
Optional capture full path file name for the
2nd serial device.
Default: /tmp/serial_capture_dev2
-n2 <2nd nickname> | --nickname-2 <2nd nickname>
Used to describe a more meaningful name to the second serial
device.
178
-h | --help
Now lets demonstrate by example the features of the monitor_serial utility program. We will analyze the NTP clock status command issued on a Cisco Router 3620.
The Minicom program will be used to issue the command: "show ntp status\r". The
serial port communication parameters are: (115200 baud, no parity, 8 data bits, and 1
stop bit - 115200N81).
** Note 1: The monitor_serial utility program will put the capture serial device in:
"raw" mode.
** Note 2: Remember that the raw capture files are available after stopping
monitor_serial. The default files are names are: /tmp/serial_capture_dev1 and
/tmp/serial_capture_dev2.
In this example the DTE Serial Tap (NST Probe) is connected to serial device:
/dev/ttyUSB0 and the DCE Serial Tap (Cisco 3620 Router) is connected to serial
device: /dev/ttyS1.
[root@probe tmp]# /usr/local/bin/monitor_serial -d1 /dev/ttyUSB0 -s 2000000 -b 115200 -n1 "NST Prob
>
-d2 /dev/ttyS1 -n2 "Cisco 3620"
*** Serial Data Capture From Device: /dev/ttyUSB0
-- NST Probe --
and Device: /dev/ttyS1
*** Waiting for data, collection interval: 2000000 (usecs) ***
%%%%%% Capture From Serial Device 2: /dev/ttyS1 -- Cisco 3620 -- %%%%%%
00000000 0d 0a 73 68 6f 70 72 6f 75 74 65 3e 20
|..shoproute> |
0000000d
###### Capture From Serial Device 1: /dev/ttyUSB0 -- NST Probe -- ######
00000000 73 68 6f 77 20 6e 74 70 20 73 74 61 74 75 73 0d |show ntp status.|
00000010
%%%%%% Capture From Serial Device 2: /dev/ttyS1 -- Cisco 3620 -- %%%%%%
00000000 73 68 6f 77 20 6e 74 70 20 73 74 61 74 75 73 0d |show ntp status.|
00000010 0a 43 6c 6f 63 6b 20 69 73 20 73 79 6e 63 68 72 |.Clock is synchr|
00000020 6f 6e 69 7a 65 64 2c 20 73 74 72 61 74 75 6d 20 |onized, stratum |
00000030 32 2c 20 72 65 66 65 72 65 6e 63 65 20 69 73 20 |2, reference is |
00000040 32 30 34 2e 33 34 2e 31 39 38 2e 34 30 0d 0a 6e |204.34.198.40..n|
00000050 6f 6d 69 6e 61 6c 20 66 72 65 71 20 69 73 20 32 |ominal freq is 2|
00000060 35 30 2e 30 30 30 30 20 48 7a 2c 20 61 63 74 75 |50.0000 Hz, actu|
00000070 61 6c 20 66 72 65 71 20 69 73 20 32 35 30 2e 30 |al freq is 250.0|
00000080 30 31 30 20 48 7a 2c 20 70 72 65 63 69 73 69 6f |010 Hz, precisio|
00000090 6e 20 69 73 20 32 2a 2a 31 38 0d 0a 72 65 66 65 |n is 2**18..refe|
000000a0 72 65 6e 63 65 20 74 69 6d 65 20 69 73 20 43 33 |rence time is C3|
000000b0 32 38 33 30 37 43 2e 45 31 42 45 31 42 41 36 20 |28307C.E1BE1BA6 |
000000c0 28 31 33 3a 32 39 3a 33 32 2e 38 38 31 20 45 44 |(13:29:32.881 ED|
000000d0 54 20 46 72 69 20 4f 63 74 20 33 20 32 30 30 33 |T Fri Oct 3 2003|
000000e0 29 0d 0a 63 6c 6f 63 6b 20 6f 66 66 73 65 74 20 |)..clock offset |
000000f0 69 73 20 30 2e 34 36 31 37 20 6d 73 65 63 2c 20 |is 0.4617 msec, |
00000100 72 6f 6f 74 20 64 65 6c 61 79 20 69 73 20 31 31 |root delay is 11|
00000110 30 2e 32 36 20 6d 73 65 63 0d 0a 72 6f 6f 74 20 |0.26 msec..root |
00000120 64 69 73 70 65 72 73 69 6f 6e 20 69 73 20 34 2e |dispersion is 4.|
00000130 30 39 20 6d 73 65 63 2c 20 70 65 65 72 20 64 69 |09 msec, peer di|
00000140 73 70 65 72 73 69 6f 6e 20 69 73 20 33 2e 35 31 |spersion is 3.51|
00000150 20 6d 73 65 63 0d 0a 73 68 6f 70 72 6f 75 74 65 | msec..shoproute|
00000160 3e 20
|> |
00000162
179
-- Ci
The Minicom screen appearance for the above command:
shoproute> show ntp status
Clock is synchronized, stratum 2, reference is 204.34.198.40
nominal freq is 250.0000 Hz, actual freq is 250.0010 Hz, precision is 2**18
reference time is C328307C.E1BE1BA6 (13:29:32.881 EDT Fri Oct 3 2003)
clock offset is 0.4617 msec, root delay is 110.26 msec
root dispersion is 4.09 msec, peer dispersion is 3.51 msec
shoproute>
180
Chapter 11. Global Positioning System (GPS)
GPS, which stands for Global Positioning System, is the only system today able to
show you your exact position on the Earth anytime, in any weather, anywhere. GPS
satellites, 24 in all, orbit at 11,000 nautical miles above the Earth. They are continuously monitored by ground stations located worldwide. The satellites transmit signals that can be detected by anyone with a GPS receiver. Using the receiver, you can
determine your location with great precision.
GPS is one of history’s most exciting and revolutionary developments, and new uses
for it are constantly being discovered. But before we learn more about GPS, it’s important to understand a bit more about navigation. A good GPS reference can be
found at: GPS1.
The follow sections will explore various ways that GPS2 navigation can be used with
NST.
GPSD
Gpsd is a user land daemon acting as a liason between a gps or Loran-C receiver
and clients. This utility program was written by Remco Treffkorn and released under
the terms and conditions of the GNU GENERAL PUBLIC LICENSE Version 2, June
1991 by Russell Nelson. The receiver is expected to generate position information as
NMEA-0183 sentences, or Rockwell binary format.
Gpsd listens on TCP port: 2947 for clients requesting position, time, velocity or altitude information. It can take information from a GPS receiver and translate it into
something easier to understand for clients.
The client does not have to run on the same computer. Remote access over a LAN
can be used to attach to a gpsd daemon.
Start up gpsd on: probe1 using serial device: "/dev/ttyUSB0"
[root@probe1 root]# /usr/local/bin/reset_serial /dev/ttyUSB0 > /dev/null 2>&1
[root@probe1 root]# /usr/local/bin/gpsd -h
usage: gpsd [options]
options include:
-D integer
[ set debug level ]
-L longitude [ set longitude ]
-S integer
[ set port for daemon ]
-T e
[ earthmate flag ]
-h
[ help message ]
-l latitude [ set latitude ]
-p string
[ set gps device name ]
-s baud_rate [ set baud rate on gps device ]
-c
[ use dgps service for corrections ]
-d host
[ set dgps server ]
-r port
[ set dgps rtcm-sc104 port ]
[root@probe1 root]# /usr/local/bin/gpsd -p /dev/ttyUSB0
Russell Nelson also wrote a sample client: "gps" which is included in the NST distribution. It simply connects to a gpsd and displays satellites in their current position
in the sky along with useful GPS status information.
Start up gps on: probe2 and connect to the "gpsd" serice on probe1.
Gpsd is tested with DeLorme’s TripMate, EarthMate, Garmin, and Magellan units.
[root@probe2 root]# /usr/local/bin/gps -h
usage:
gps [options]
181
options include:
-D integer
[ set debug level ]
-h
[ help message ]
-p string
[ set gps device name ]
-s baud_rate [ set baud rate on gps device ]
[root@probe2 root]# /usr/local/bin/gps -p probe1:2947
A screen shot of the gps client is presented in Figure 11-1.
Figure 11-1. GPS X Client Utility Application
A description of the gpsd protocol can be found at: gpsd3. This was written by:
Thomas Hargrove. A couple of examples are now shown using: Netcat - (nc):
[root@probe2 root]# /usr/bin/nc probe1 2947
P
GPSD,P=42.694432 -73.861363
D
GPSD,D=10/08/2003 18:22:26
PAMS
GPSD,P=42.694420 -73.861352,A=101.600000,M=2,S=1
R
GPSD,R=1
$GPGGA,182300,4241.6651,N,07351.6809,W,1,05,1.9,101.9,M,-33.5,M„*74
$GPGSA,M,2,01,02„„,16,20,25„„2.1,1.9,1.0*34
$GPGSV,3,2,10,13,18,316,00,14,04,143,00,16,87,198,35,20,27,246,38*73
$PGRME,7.8,M,6.8,M,10.3,M*1D
R$GPRMC,182301,A,4241.6650,N,07351.6809,W,000.0,326.7,081003,014.2,W*73
$GPGGA,182301,4241.6650,N,07351.6809,W,1,05,1.9,101.8,M,-33.5,M„*75
$GPGSA,M,2,01,02„„,16,20,25„„2.1,1.9,1.0*34
GPSD,R=0
Figure 11-2. NetCat - (nc) TCP/IP Network Utility Interrogating the GPSD Daemon
A GPS receiver can be used with the Kismet4 application to generate various graphical maps depicting 802.11 wireless network topologies. Documentation on how to do
this can be found in the Section called Kismet in Chapter 3.
182
Notes
1. http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
2. http://www.colorado.edu/geography/gcraft/notes/gps/gps_f.html
3. http://www.pygps.org/gpsd/gpsd.html
183
184
Chapter 12. Networking
This chapter will cover various topics related to networking in general.
Ethernet/Fast Ethernet/Gigabit Ethernet Network Cabling
This section describes the network cable configuration associated with the following
Ethernet LAN (Local Area Network) Standards over copper UTP (Unshielded
Twisted Pair): Ethernet (10BaseT), Fast Ethernet (100BaseTX), and Gigabit Ethernet
(1000BaseT). Some of this information was obtained from Steven Nikkel’s Web site1.
Use quality grade UTP Category 5/5e/6 networking cable, don’t skimp on this.
Shielded cable works also, but isn’t necessary. Bulk cable comes in many types, there
are 2 basic categories, solid and braided cable. Braided cable tends to work better in
"patch" applications for desktop use. It is more flexible and resiliant than solid
cable and easier to work with, but really meant for shorter lengths. Solid cable is
meant for longer runs in a fixed position. Plenum rated cable should/must be used
whenever the cable travels through an air circulation space. For example, above a
false celing or below a raised floor.
There are 8 color coded wires. These wires are twisted into 4 pairs of wires, each
pair has a common color theme. One wire in the pair being a solid or primarily
solid colored wire and the other being a primarily white wire with a colored stripe
(Sometimes cheap cable doesnt have any color on the striped cable, the only way
to tell is to check which other wire it is twisted around). Examples of the naming
schemes used are: Orange (alternatively Orange/White) for the solid colored wire
and White/Orange for the striped cable. The twists are extremely important. They
are there to counteract noise and interference. It is important to wire according to a
standard to get proper performance from the cable. The hardware expects the cable
to have certain properties, a cable that does not fall within tolerance will cause errors
and or failures. Besides, this maintains all your cables to the standards and makes it
easy to find errors and cross-over cables. The standard for generic LAN telecommunications cabling is known as the TIA/EIA-568-A standard. It is chartered to include
criteria for planning, installation, and performance metrics that will support a multivendor environment defining next-generation cabling such as Category 5E and Category 6, provide performance specifications for hybrid and bundled cables such as
SpeedPull, and further define fiber usage including connectors, distances and 50 micron wavelengths. This standard also specifies two wiring standards for a 8-position
modular connector (RJ45) that is used in UTP ethernet networks. The two wiring
standards, T568A and T568B vary only in the arrangement of the colored pairs.
Figure 12-1 describes the various color coding and pinouts for the network cabling
and the RJ45 modular connector. The T568B/T568B was chosen for the straight
through cable and T568B/T568A for the cross-over cable. It is also possible to wire it
the opposite way (ie straight through is a T568A). Your choice might be determined
by the need to match existing wiring, jacks or personal preference, but you should
maintain consistancy.
185
Figure 12-1. Networking Cable Configuration for Ethernet LAN Standards
The RJ45 end is a 8-position modular connector. There are a couple variations available. The primary variation you need to pay attention to is whether the connector
is intended for braided or solid wire. For braided/stranded wires, the connector has
contacts that actually pierce the wire. For solid wires, the connector has fingers which
pierce the insulation and make contact with the wire by grasping it from both sides.
The connector is the weak point in an ethernet cable, choosing the wrong one will
often cause grief later. If you just walk into a computer store, it’s pretty impossible to
tell what type of connector it is, if it isn’t specifically labelled. Strain relief boots are
somewhat helpful sometimes.
The following table lists various specifications and the approprate cable type for the
associated Ethernet LAN standard.
Table 12-1. Ethernet LAN Standards and Cable Type
186
Ethernet
LAN
Standard
Frequency
(MHz)
Symbol
Encoding
Signal
Rate
(Mbaud)
S
R
10BaseT
10
Manchester
10
1
100BaseT4
12.5
Multilevel,
2T/Hz
25
100BaseTX
31.25
MLT-3
125
1
Ethernet
LAN
Standard
Frequency
(MHz)
Symbol
Encoding
Signal
Rate
(Mbaud)
100BaseT2
12.5
PAM5x5
(2DPAM5)
25
1000BaseT
31.25
4DPAM5
125
Notes
1. http://www.ertyu.org/~steven_nikkel/ethernetcables.html
187
S
R
188

Using the Network Security Toolkit

Transcription

Similar documents

Bovine • Equine • Ovine • Caprine • Porcine - vaucluse

Preoperative Measurements and Intraocular Lens

Presentation

Video Borescope RIGEL UF 4.0mm Brochure

Probe Year in Review

CRYOGEN-FREE Models

Tutorial: Create online polls with PHP and MySQL

mobile banking service mobile banking service

Saf-T-Log ® Thermomètre enregistreur HACCP

Technical data sheet Electro ejaculator