NST General Information
- 1 What is the Network Security Toolkit?
- 2 What are the System Requirements?
- 3 Where do I go for information?
- 4 Where can I get the Network Security Toolkit?
- 5 What is the password?
- 6 How can I Avoid Setting the Password Each Time It Boots?
- 7 Why is the nstpasswd Command Insecure?
- 8 What is the IP Address?
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 (Core 2 series or later).
- At least 512MB of RAM (we recommend at least 1024MB 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 supported Ethernet (NIC) Adapter or WIFI card.
- At least 16 GB of disk space if you want to install to your hard disk.
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:
You will want to change this as soon as you log in using the nstpasswd command as shown below:
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 getipaddr script to determine your IP address:
[root@cayenne-e ~]# getipaddr -d 192.168.1.33
You can use the ifconfig command to list more information about your active network 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 an NST probe only provides services on ports: "22 (SSH)" and "443 (HTTPS)", one can look at the above output and see that IP Address: "192.168.12.9" is the only system meeting these restrictions (the key being the absence of service port: "80 (HTTP)").