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 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)).

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):

Figure 1.7. Using ssh

[pkb@salsa docs]$ ssh root@192.168.0.17
Enter passphrase for key '/home/pkb/.ssh/id_rsa':
root@192.168.0.17's password: YOUR_PASSWD
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]#

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
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 (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:

Figure 1.8. X Screenshot (Linux Desktop)

X Screenshot (Linux Desktop)

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.

Run a X Desktop Remotely (VNC)

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: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 (ettercap-common, firefox and gaim).

Figure 1.9. VNC Screenshot (Linux Desktop)

VNC Screenshot (Linux Desktop)

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.

Figure 1.10. VNC Screenshot (Windows XP Professional Desktop)

VNC Screenshot (Windows XP Professional Desktop)

Warning

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”.