NST General Information

What is the Network Security Toolkit?

The Network Security Toolkit is a Linux distribution based on Fedora with additional network security tools installed and ready to run. The distribution in several forms and can be booted and run as a "live" boot (without installation) as well as being installed to a hard disk or run as a virtual machine.

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 equipment is supported:

• A video adapter and monitor.
• A keyboard.
• A standard serial port.
• Multiple Ethernet Adapters or WIFI cards.
• A mouse.
• Disk drives.
• USB devices.

What is the Recommended System?

If you are like Ron (heavily involved in setting up and Enterprise Network Security Architectures in the real world), you'll probably find yourself wanting to build custom Network Security Toolkit systems. Most likely, you'll be able to use most components that you come across. However, if you'd rather be safe, you may want to make use of Ron's current entry level parts list. If nothing else it serves as a good starting point for a suggested component list to get NST up and going. The following table is a breakdown of Ron's entry level parts preference and approximate prices as of 2004-Mar-21 (all amounts are in USD). This particular system configuration includes 3 10/100 network interfaces. It is important to stress that a CDROM with a fast read speed (52x) is beneficial to experience the best results from NST.

TBD

Where do I go for information?

• http://wiki.networksecuritytoolkit.org/ - This wiki serves is the primary location for information on using the NST.
• 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).