NST General Information

What is the Network Security Toolkit?

The Network Security Toolkit is a bootable ISO live CD/DVD (NST Live) and is based on Fedora. The toolkit was designed to provide easy access to best-of-breed Open Source Network Security Applications and should run on most x86/x86_64 platforms.

The main intent of developing this toolkit was to provide the network security administrator with a comprehensive set of Open Source Network Security Tools. The majority of tools published in the article: Top 100 Security Tools by INSECURE.ORG are available in the toolkit. An advanced Web User Interface (WUI) is provided for system administration, navigation, automation, geolocation and configuration of many network and security applications found within the NST distribution. In the virtual world, NST can be used as a network security analysis, validation and monitoring tool on enterprise virtual servers hosting virtual machines.

Before each release, the developers strive to make certain that the latest security patches and fixes for Fedora and the additional network security tools are up to date.

What are the System Requirements?

The system requirements for running the Network Security Toolkit include following:

• A i686 or x86_64 compatible CPU (Pentium III or later).
• At least 256MB of RAM (we recommend 512MB if you want to use a graphical desktop).
• A DVD drive and BIOS capable of booting from a DVD. If your system supports booting from USB devices, a 2GB USB flash drive can be used instead of a DVD.
• A Fedora Ethernet Adapter or WIFI card.

It is important to note that a hard disk is not required. And though the Network Security Toolkit has the capability to use hard disks, it does not do so by default.

In addition to the minimum requirements, the following standard equipment is supported:

• A video adapter and monitor.
• A PS/2 or USB keyboard.
• A standard serial port.
• Multiple Ethernet (NIC) Adapters or WIFI cards.
• A PS/2 or USB mouse.
• Disk drives.
• USB devices.

Where do I go for information?

• http://wiki.networksecuritytoolkit.org/ - This wiki serves is the primary location for information on using the NST.
• http://en.wikipedia.org/wiki/Network_Security_Toolkit - NST on Wikipedia
• http://twitter.com/NetSecToolkit - This is the NST Twitter feed. The NST authors will often "tweet" when enhancements are made to the NST distribution (typically when new packages become available).
• http://www.networksecuritytoolkit.org/ - The site's home page is updated each time a new release of the NST ISO image is posted to SourceForge.
• http://wiki.networksecuritytoolkit.org/repo/f13/i686/repoview/ - This link provides a list of packages which the NST developers have recently released for the 32 bit NST build (there is a 64 bit repository as well). These links can be used to tell what packages have recently been updated.
• http://sourceforge.net/projects/nst - This is the project's development site. You can download the current NST release from here, ask for help on the NST forum, and even browse the source code or monitor the latest commit messages posted by the NST authors.

Where can I get the Network Security Toolkit?

You can download the the Network Security Toolkit at the project's SourceForge site: http://sourceforge.net/projects/nst.

What is the password?

When you download and boot the NST distribution, the password for the root user will be:

nst2003

You will want to change this as soon as you log in using the nstpasswd command as shown below:

nstpasswd

Using the nstpasswd command will set many different passwords used to access the NST system and start the sshd and httpd service so that you can access the system using a Secure Shell client or a web browser.

When logging in via a web browser, you will need to login using the root account and the password you set with the nstpasswd command.

How can I Avoid Setting the Password Each Time It Boots?

If you find it tedious to specify a new password using the nstpasswd command each time you boot the Network Security Toolkit from live media, there are a couple of options:

• Create a live USB memory stick with a persistent overlay and boot from your USB memory stick instead of DVD media. See the "NST USB FAQ" for details.
• Build your own NST ISO image from the source. This allows you to specify your own custom password before the ISO image is built as well as customize what packages are included on your ISO image. This is a project for advanced users. See the "HowTo Build NST 2.13.0" page for details on building the NST from source.

Why is the nstpasswd Command Insecure?

The nstpasswd command makes it very easy to administer the Network Security Toolkit. It sets many of the system login/password combinations to a single value (i.e. creates a Single SignOn environment). This means you only need to remember one login/password to administer a Network Security Toolkit system.

However, having the same login/password combination for many different applications means that someone who is able to gain read access to your system might have a easier time determining the password for the super user: root. Single SignOn environments, where the same password for multiple applications (ssh, httpd, vnc, etc) is used, may make it easier for someone to break into your system and compromise your network.

This problem is not unique to the Network Security Toolkit. Anyone who uses the same password for different systems (or services on a single system) will have this issue.

Care should be taken if you install the NST to a hard disk partition on a system which is not physically secure (meaning that people you don't know will have physical access to the system and the ability to read the contents of the hard disk).

What is the IP Address?

By default, the Network Security Toolkit uses DHCP to determine its IP address. If your machine has a keyboard and monitor attached or you are able to connect to it via the serial port, you can use the following to determine your IP address:

[root@cayenne-e ~]# getipaddr -d
192.168.1.33

You can use the following command to list more information about your active interfaces including their IP addresses:

[root@probe root]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:02:68:27:12
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:119 errors:0 dropped:0 overruns:1 frame:0
          TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:19117 (18.6 Kb)  TX bytes:13105 (12.7 Kb)
          Interrupt:3 Base address:0x9000
 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
 
[root@probe root]# 

If you do not have a keyboard and mouse attached or serial access, the determination of the IP address assigned becomes a more difficult task. You will need to locate the logs of your DHCP server to determine what address was assigned.

Alternatively, if you have access to port scanning software (like nmap), you can scan your network for ports 22, 80 and 443 as shown in the following:

[pkb@salsa pkb]$ nmap -p 22,80,443 192.168.12.0/24
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on nacho.linux.bogus (192.168.12.1):
Port       State       Service
22/tcp     open        ssh                     
80/tcp     open        http                    
443/tcp    open        https                   

Interesting ports on rice.linux.bogus (192.168.12.2):
Port       State       Service
22/tcp     open        ssh                     
80/tcp     open        http                    
443/tcp    open        https                   

All 3 scanned ports on tamale.linux.bogus (192.168.12.5) are: closed

Interesting ports on salsa.linux.bogus (192.168.12.7):
Port       State       Service
22/tcp     open        ssh                     
80/tcp     open        http                    
443/tcp    open        https                   

All 3 scanned ports on flan.linux.bogus (192.168.12.8) are: closed

Interesting ports on mole.linux.bogus (192.168.12.9):
(The 1 port scanned but not shown below is in state: closed)
Port       State       Service
22/tcp     open        ssh                     
443/tcp    open        https                   

Nmap run completed -- 256 IP addresses (6 hosts up) scanned in 4 seconds 

[pkb@salsa pkb]$ 

Since the Network Security Toolkit probe only provides services on ports 22 and 443, I can look at the above output and see that 192.168.12.9 is the only system meeting these restrictions (the key being the absence of port 80).