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 will be the one you specified at boot
time. If you were not prompted to set the password at boot time,
you will need to use the default value of
nst2003 (NST distributions prior to
1.4.2, will use
nst@2003). This combination is used
regardless of whether you are logging in at the console, through
a ssh connection, through a VNC connection,
or via the Web User Interface. If you
logged in using the default password, you should immediately run
the nstpasswd script to set a new system
password (this is described in Setting the Password (nstpasswd)).
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.
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).
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):
Figure 1.7. Using ssh
[pkb@salsa docs]$ssh root@192.168.0.17Enter passphrase for key '/home/pkb/.ssh/id_rsa': root@192.168.0.17's password:YOUR_PASSWDLast 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]#
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.
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.
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_xStarting 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 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]#startxXFree86 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 (bhcompile@porky.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Feb 4 20:44:26 EST 2004 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 wireshark, etherape and ipsc running on a Network Security Toolkit probe running X:
The VTWM 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 VTWM 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.
If you are familiar with VNC (it allows for virtual desktops), and you have a VNC client for another system on the network, you can use a virtual desktop to run the software on the Network Security Toolkit probe. The VNC 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 VNC 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: [ OK ] *** Starting a vnc server on display: 6 /usr/local/bin/vncserver :6 -geometry 1280x1024 -depth 24 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 00:00:00 Xvnc :6 -desktop X -httpd /usr/share/vnc/classes -auth /root/.Xauthority -geometry 1280x1024 -depth 24 -rfbwait 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:6VNC 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 (ettercap-common, firefox and gaim).
For the most part, X based applications run at near native speed when using VNC on a local network (its pretty amazing). However, over a WAN link (i.e. a relative slower network connection), X based applications that do a lot of animation (like etherape) won't appear to run as smoothly over VNC.
The screenshot shown in Figure 1.10, “VNC Screenshot (Windows XP Professional Desktop)” 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.
You should avoid runing VNC sessions across a public network. The information transmitted across the VNC is not encrypted. If you need to run a VNC session across a public network, you should read up on SSH tunneling to create a secure communications channel between the two systems first. Tunneling VNC traffic over a SSH link is diagrammed in Figure 8.1, “Secure Virtual Computing”.