Fast Network Discovery

The Need for Speed in Network Scanning

In network administration and security testing, quickly identifying active hosts on a subnet is a frequent requirement. While advanced tools offer comprehensive analysis, sometimes a simple, command-line solution is needed for rapid inventory and troubleshooting. The goal is efficiency and minimal overhead.

The ipsweep.sh script, available on GitHub, is designed specifically for this purpose. It provides a lightweight, effective method for performing a ping sweep across a local network using only standard operating system utilities.

How This Script Accelerates Scanning

This specialized Bash script speeds up network discovery by utilizing parallel execution. Rather than checking network addresses one by one in sequence, the tool performs concurrent ping requests to every potential host within the specified subnet simultaneously. This method significantly reduces the time required for a complete network sweep.

Key Functions and Benefits:

*    Parallel Execution: By running checks in the background, the script drastically cuts down the total time required for the sweep, allowing for near-instantaneous discovery of live hosts.

*    Active Host Identification: The core function uses the standard ping command to send ICMP requests and identify which IP addresses are actively responding on the network.

*    Automatic Hostname Resolution: A critical utility feature is the inclusion of a reverse DNS lookup (nslookup) for every active IP. This translates cryptic IP addresses (e.g., 192.168.1.109) into human-readable hostnames (e.g., My-Workstation or router.local), greatly improving the utility of the scan results.

*    Low Dependency: The script relies only on utilities that are standard across most Unix-like environments (Linux, macOS): bash, ping, and nslookup.

Getting Started: Deploying the Script

To integrate ipsweep.sh into your toolkit, follow these straightforward steps:

1. Obtain the Script

The script can be obtained by cloning the Git repository:

git clone https://github.com/2bitninja/ipsweep.git

2. Prepare for Execution

Navigate to the repository directory and ensure the script has the correct permissions:

cd ipsweep
chmod +x ipsweep.sh

3. Execute the Scan

Run the script by supplying the first three octets of the target subnet (e.g., for the range 10.0.0.1 to 10.0.0.254):

./ipsweep.sh 10.0.0

The script will output a clean, two-column list detailing the active IP addresses and their resolved hostnames:

These are the active IP Address for 192.168.1

IP Adress Hostname
==========================
192.168.1.1    router.asus.com.
192.168.1.104    Samsung.
192.168.1.128
192.168.1.136
192.168.1.137     Joel.
192.168.1.143     MacBook-Pro.
192.168.1.169
192.168.1.211
192.168.1.36

Summary

ipsweep.sh is a valuable, minimalist tool for network auditing and troubleshooting. Its combination of speed, simplicity, and automatic hostname resolution makes it an efficient utility for anyone needing to quickly map out the active devices on a local network.

For further details and to view the source code, please visit the repository:

View the ipsweep repository on GitHub

Simplifying Tenable Administration: A Menu-Driven Utility for User Management

Managing a robust security infrastructure often means interacting with multiple administrative interfaces, and Tenable environments (Nessus and Tenable.sc) are no exception. Performing routine tasks like resetting a password or simply managing user access can become repetitive, especially in environments without seamless directory integration.

Crucially, when an administrator or standard user account gets locked out, gaining back immediate access can be a critical, high-stress scenario. This script offers a rapid solution for those situations.

To streamline these common administrative headaches, I developed the Tenable Utility, a simple, menu-driven Bash script designed to centralize and automate essential user management tasks for both Tenable.sc and Nessus.

Core Features of the Tenable Utility

The Tenable-Utility.sh script provides a clear, numbered menu system to execute privileged commands against your Tenable installations.

1. Quick Lock/Unlock: Quickly unlocking an administrator or standard user account.

2. Password Resets: Reset a Tenable.sc user's password to a known default value.

3. Add/Remove Users: (Nessus only) Add a new Nessus user or removing an existing one

Getting and Running the Script

Because this script performs administrative actions directly on the backend files of Tenable products, it must be run with the appropriate permissions.

Requirements:

- Tenable.sc and/or Nessus installed on a Linux or macOS system

- Root or sudo privileges.

Installation and Usage

1. Clone the Repository

> git clone https://github.com/2bitninja/Tenable-Utility.git
> cd Tenable-Utility

2. Grant Execution Rights

> chmod +x Tenable-Utility.sh

3. Execute and Select Options

Run the script using sudo. This will launch the interactive main menu

> sudo ./Tenable-Utility.sh

When executed, the script will display a menu that allows you to choose from various administrative options related to Tenable.sc and Nessus.

Menus

Tenable.sc User Management

After running the script, you'll be presented with a menu. Pick an option to perform the corresponding task:

------------------------------------------------
        What do you want to do?
1. Unlock admin account     | 4. Lock admin account
2. Unlock all accounts          | 5. Lock all accounts
3. Unlock one account         | 6. Lock one account

7. Reset user password      | 8. Manage Nessus accounts
9. Exit program

Nessus User Management Menu

If you select option 8, you'll enter the Nessus User Management menu where you can manage Nessus user accounts:

Nessus User Management
1. Add user        | 3. Change password
2. Remove user | 4. Exit

Conclusion

The Tenable Utility offers Tenable administrators a fast, reliable, and convenient way to handle crucial user management and operational tasks. Instead of navigating complex UIs or recalling lengthy command syntax, you can execute necessary changes from a single, simple menu.

If you are looking to simplify your daily administrative routine, check out the repository today and integrate this utility into your toolbox!

Tenable-Utility on GitHub

Feel free to check out the script, use it, and let me know if you have any suggestions for improvements!

Related Posts:
How to Reset Passwords for Tenable.sc

Reset Admin account on Security Center (Older versions)

How to Reset a Nessus Scanner

Automating Verification for Nessus Scans

 The Challenge of Scan Verification

As vulnerability managers and security engineers we rely on credentialed scans to provide accurate visibility into our environment. An uncredentialed scan is essentially a surface-level check, missing most critical vulnerabilities that require authenticated access (like missing patches or insecure configurations).

When managing Tenable environments (Nessus or Tenable.sc), confirming that every asset in a large scan successfully ran with credentials is a critical, yet highly inefficient task. Since the definitive check demands manually reviewing Nessus Plugin ID 19506 (Nessus Scan Information) for the credentialed=true value on every host, this drill-down approach is simply too time-consuming.

The Solution: check-scans.sh

To solve this problem and reclaim time, I developed a simple Bash script called check-scans.sh.

This script automates the verification process, allowing vulnerability managers to confirm scan integrity quickly and efficiently without having to manually sift through the user interface.

The Script's Core Utility

The primary purpose of check-scans.sh is straightforward: verify that scans were conducted with credentials.

It targets the operational need to ensure that the foundational data used for patching and risk analysis is reliable. If Plugin 19506 is missing or shows credentialed=false, the script flags that asset, pointing you directly to the hosts that require re-scanning or troubleshooting.

How to Implement and Run the Script

The script is available in my GitHub repository. It requires minimal setup, making it easy to integrate into your existing workflow.

1. Getting the Script

You can find the source code and usage details here: https://github.com/2bitninja/check-scans

To get the script, clone the repository and navigate into the directory:

git clone https://github.com/2bitninja/check-scans.git

2. Prepare for Execution

Make the script executable:

chmod +x check-scans.sh

3. Running the Check

Due to the nature of interacting with the Nessus/Tenable installation directories and files, you will need elevated privileges (e.g., being in the tns group or using sudo) to execute it successfully.

Execute the script:

sudo ./check-scans.sh

The script will handle the heavy lifting, giving you an immediate, verifiable result of your credentialed scan coverage.

Conclusion

Operational efficiency in security is often achieved through small, focused automations. By leveraging a simple script like check-scans.sh, you eliminate a manual administrative burden, ensuring your security team can maintain a high standard of data quality for all vulnerability assessments.

Feel free to check out the script, use it, and let me know if you have any suggestions for improvements!

How does this version look? I focused on explaining the technical necessity and the workflow benefit.

How to Reset Passwords for Tenable.sc

Accidentally locked yourself out of your Tenable.sc (formerly Security Center) admin account? Don't worry! This post walks you through the steps to reset your password on version 5.11 and newer. If you're running an older version, you can find instructions in my previous blog post. We'll cover how to reset the password, unlock your account, and clear any pesky login failures.

Important Security Note: Directly modifying the database should be done with caution. Ensure you have a backup of your Security Center configuration before proceeding.

Reset the admin account password

root@earth# /opt/sc/support/bin/sqlite3 /opt/sc/application.db "update userauth set password = '943807ff8e7f4735e2a4774f0cf9ceec1044889088737759ef1f329beb40de00107446dffa66fdcc3d557c1b5109800b8f5083cd4e6cd018c5739135f9ceeb12', salt = 'e+xmTMivzO0Jmyl3XLcDIKcnXOWaKYzWCRRJu2ebr41K8sHJjtYy7JGJwR3IfohbFLUHWzVlivXtt8Dn/ok2tg==', hashtype = 2 where username='admin';"

This command resets the 'admin' user's password to 'password'. It's essential to log in and update this password right away. You can also use this command to reset the password of any other Tenable.sc user by replacing 'admin' with their username. This command does not unlock the account.

Clear Login Failures

root@earth# sqlite3 /opt/sc/application.db "update userauth set failedLogins='0' where username='admin';"

This command resets the count of failed login attempts for the 'admin' user or anther specified user.

Unlock the admin Account

root@earth# sqlite3 /opt/sc/application.db "update userauth set locked='0' where username='admin';"

Use this command to restore access to a locked 'admin' account. Note that this action only unlocks the account; the password remains the same.

 
After running these commands, you should now be able to log in to your Tenable.sc administrator account. Keep in mind that the password has been reset to a specific, secure value behind the scenes. For security, your very first step after logging in should be to change this password through the Tenable.sc interface. If you run into any problems or have more questions, please leave a comment below.

Note: A better way of doing account actions on Tenable.sc (security center), and Nessus is on this blog post: Simplifying Tenable Administration: A Menu-Driven Utility for User Management

Taming Runaway tmux Sessions and Keeping Your Scans Smooth

This post tackles a common issue encountered during vulnerability scans with Tenable.sc (formerly Security Center). It addresses the problem of lingering tmux sessions that can hinder login attempts and system responsiveness.

The Problem

Recently, a critical plugin (21745) triggered on a Red Hat Enterprise Linux 8 (RHEL 8) system during a Tenable.sc scan. The scan user account wasn't locked out, but SSH login attempts hung indefinitely despite system logs showing a successful login. A reboot temporarily resolved the issue, but it kept reoccurring.

The Culprit: Unclosed tmux Sessions

Tenable.sc leverages tmux, a terminal multiplexer, to manage multiple connections during a scan. When a connection is established, tmux typically creates a session. The problem arose when these tmux sessions weren't being automatically closed after the scan completed. This led to a situation where the scan user ended up with thousands of orphaned sessions, causing login issues.

Fixing the Runaway Sessions

1. Automatic Cleanup

• Edit the system-wide tmux configuration file ( /etc/tmux.conf ).
• Add the line set -g destroy-unattached on to the configuration file. This instructs tmux to automatically terminate any sessions that are not actively in use.
• To implement this change:

scanuser@remotesystem> sudo echo "set -g destroy-unattached on" >> /etc/tmux.conf

2. User-Specific Control (Optional)

• This approach allows tmux usage only for the designated scan user ( scanuser ). 
• Create a custom shell script ( /etc/profile.d/custom.sh ) with the following content:

[ "$USER" != "scanuser" ]
 then if [ "$PS1" ]
   then parent=$(ps -o ppid= -p $$)
        name=$(ps -o comm= -p $parent) 
        case "$name" in (sshd|login) exec tmux
        esac 
 fi 
fi 

This script checks the current user and only allows tmux execution if the user is "scanuser" and the parent process is either "sshd" (SSH daemon) or "login" (login shell).

Understanding the Tools

tmux: An open-source terminal multiplexer that allows managing multiple terminal sessions within a single window. You can split your terminal into different panes, detach from sessions, and reattach later, similar to the "screen" application.

Tenable Plugin 21745: This is an informational plugin that gathers and displays information from other plugins, triggered in this instance due to potential login failures.

Additional Resources

• Tmux Cheat Sheet & Quick Reference: https://tmuxcheatsheet.com/
• A beginner's guide to tmux: https://www.redhat.com/en/blog/introduction-tmux-linux

By implementing these solutions, you can ensure that your Tenable.sc scans run smoothly without encountering issues caused by lingering tmux sessions.

Free Google Training & Certification Exam

Google is offering free training for US or Canadian military veterans or service members looking to transition into a tech career. This program is designed to help you leverage your military experience and skillset to succeed in the tech industry. 

Key Program Benefits:

• Free Training: Attend a two-day virtual training event to learn the fundamentals of cloud computing and Google Cloud Platform.
• Certification Vouchers: Receive a voucher to take the Cloud Digital Leader certification exam, valued at $99.
• Expert Guidance: Learn from Google Cloud experts and veteran Google employees.
• Networking Opportunities: Connect with other veterans and industry professionals.

Agenda

Attend the Cloud Digital Leader Training Even
Dates: November 7-8, 2024
Time: 10 AM - 6 PM EST
Location: Virtual

Exam Prep Sessions
Dates: November 15 and/or November 22, 2024
Time: 1 PM - 2:30 PM EST
Location: Virtual

Go to the link below to register for the class

https://rsvp.withgoogle.com/events/google_cloud_launchpad_for_vets

Don't Miss Out!

Login hangs for scanning account

The Problem

I ran into this issue the other day. Tenable.sc (formerly Security Center) was reporting a hit on plugin 21745 for a Red Hat Enterprise Linux 8 (RHEL 8) system. I checked on the account used on the systems for scanning and it wasn't locked out or anything. When I tried to SSH into the system with the credentials, it would just hang. The system logs showed "login successful". When I rebooted the system was able to login normally again, but the problem would come back eventually.

The Cause

When the Nessus scanner connects to a system, it's scanning, it makes several connections to the host. Each connection starts a TMUX session. The problem is the TMUX sessions where not being closed after the Nessus scanner disconnected from the system. It turned out that the account used for security scanning had around 2,000 TMUX sessions running.

The Fix

Add "set -g destroy-unattached on" to the /etc/tmux.conf file.

scanuser@remotesystem> sudo echo "set -g destroy-unattached on" >> /etc/tmux.conf

This will append this line "set -g destroy-unattached on" into the /etc/tmux.conf configuration file. This will auto close sessions not being actively used.

Anther Fix

Set system wide rules for TMUX on the effected systems so only the account used by the Nessus scanner will have use of the TMUX terminal multiplexer. /etc/profile.d/custom.sh

[ "$USER" != "scanuser" ]
 then if [ "$PS1" ]
   then parent=$(ps -o ppid= -p $$)
        name=$(ps -o comm= -p $parent) 
        case "$name" in (sshd|login) exec tmux
        esac 
 fi 
fi 

Defs

TMUX is an open-source terminal multiplexer for Unix type systems. Multiple terminal sessions can be accessed simultaneously by splitting the terminal into different screens. Can also detach remote sessions and reattach later, similar to what the screen application can do.

 
Tenable Plugin a plugin is a script deployed by the Nessus scanner to check for security vulnerabilities. In this case plugin 21745 is an info plugin, it displays info from other plugins. This plugin is triggered (displayed) whenever a login failure occurs.

Other useful links

Tmux Cheat Sheet & Quick Reference
https://tmuxcheatsheet.com/
A beginner's guide to tmux
https://www.redhat.com/sysadmin/introduction-tmux-linux

Setup SSH Keys with Agent

This guide for setting up SSH Keys with an SSH Agent for auto-logging into Linux based systems. Why set up SSH keys, why not just use your password? SSH Keys are considered more secure than using passwords to access systems, because user accounts are authenticated by the server without ever having to send your password over the network. If the passwords are not transmitted then they can't be intercepted. This works by identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. When you set up an SSH agent then the agent will handle the challenge-response authentication for you.

This guide is not for installing or setting up a SSH server. You must have the sshd service running on your system in order to follow along with this guide. All the examples are take from a Red Hat system. In the following examples, earth is the name on the local system and moon is the remote system. 

Create you key pair

The ssh-keygen command will generate a public and private keypair. The keys will be stored in the users home directory by default, this is the path  ~/.ssh/. The basic command looks like this: ssh-keygen -t [dsa|rsa]  The -t sets the type of keys used. In the example below I create a rsa key pair. This command also sets the passphrase, think of this like setting a password. Make sure you remember the  passphrase because you will use this instead of the password for logging into the remote system (moon).

man@earth> ssh-keygen -t rsa
Enter file in which to save the key (/home/man/.ssh/id_rsa): Press [Enter] key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/man/.ssh/id_rsa.
Your public key has been saved in /home/man/.ssh/id_rsa.pub.
The key fingerprint is:dfhjodfnk
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01

It is import to protect your private key, so don't share it. 

Note- Do not leave the passphrase blank. Doing this is a bad security practice, because this defeats the purpose of having the extra security of SSH keys. This will make the system less secure. If you have done this just rerun the command and add a passphrase. 

Install Public Key on Remote Host

You install the public SSH key by copying or appending it to the authorized_keys file on a remote host. This file is also located in the users home directory, ~/.ssh/.  For most systems you can use the ssh-copy-id command, which I cover in Method 1.  I will show a work around if the ssh-copy-id command is not available, in Method 2 & 3.

Method 1 - Use The ssh-copy-id Command

The easiest way to install the public key to a remote SSH server is use the ssh-copy-id command. To use the command type "ssh-copy-id <remote host>". This command appends the public key to the authorized_keys file on the the remote host. If the file doesn't exist it will be created. 

In the example below "moon" is the name of the remote host.

man@earth> ssh-copy-id moon
Now try logging into the machine, with "ssh 'remote-host'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

This the best way is to copy over the public key because ssh-copy-id will create .ssh/authorized_keys file if it doesn't exist. The command also appends the public key to the authorized_keys file, whereas other methods may overwrites the file. This allows the account to use keys from more than one system.

Note- This method will not work on some systems, such as Solaris 10.

Method 2 - Manually Copy the Key File

This method uses the scp command to copy the public key to the remote server. Before the ssh-copy-id  command came about, this was way it was done. The key file will fail to copy to the system if .ssh/authorized_keys doesn't exist. If this happens just login with your password and create the file and try again. The main downside to this method is that it overwrites the authorized_keys file.

man@earth> scp ~/.ssh/id_rsa.pub moon:~/.ssh/authorized_keys

Alternately you can get around this by doing this instead. The command below mimics what the ssh-copy-id command does. It creates the .ssh directory if it doesn't exist and appends the contents of the key to the authorized_keys file.

man@earth> cat ~/.ssh/id_rsa.pub | ssh man@moon "mkdir -p ~/.ssh  &&  cat   >>  ~/.ssh/authorized_keys

Method 3 - If You Automount Your Home Directory

If your home directory automounts across a lot of servers then you can just append the contents of the public key to the authorized_keys file. This method can be a lot faster then other methods. For example if you have 100 hosts you need to connect to, you just need to run the command once to connect to all of them. Instead of running 100 copy commands you just run one. Again this will only work if the hosts your connecting to automount the same home directory that the SSH kays are on.

You can copy it over with the cat command.

man@earth> cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

The other methods will still work if you prefer them to this one. 

Setting up the SSH Agent

At this point when you login to a remote host you now get prompted for the SSH passphrase instead of the password. To automate the login process it is recommended to setup an SSH Agent. Luckily setting up an SSH Agent is easy. The agent holds the passphrase for the user and then presets the passphrase when prompted. 

There are some considerations you need to consider when running an SSH Agent. If a GUI is installed on the system, such as gnome, then the window manager may run the agent for you. This is by far the easiest way to setup an agent. If the system window manager handles SSH keys then you get prompted with a GUI text box for a passphrase the 1st time you try to SSH to a remote host. If you enter the passphrase the GUI will run the SSH Agent for you system wide for the user currently logged into that account. This lasts until the system is rebooted or the user logs out.

You can also run the agent from within a terminal or shell. When you run an agent from the terminal it will only work from that terminal and not system wide like does if the GUI manages the agent. 

To start an SSH Agent in a terminal run the commands show below. 

man@earth> eval `ssh-agent`
man@earth> ssh-add
Enter passphrase for /home/man/.ssh/id_rsa:
Identity added: /home/man/.ssh/id_dsa (/home/man/.ssh/id_rsa)

Note- Add these commands to the .bashrc file to start an agent automatically when you open a terminal emulator. 

If you use VNC, just start your VNC server session in the same terminal you used to starting your agent. This way all your terminal emulators launched in your VNC session, will use the same agent.     

SSH Agent Management

One issue with agents is that sometimes you end up running a lot of agents. This is because the agent doesn't stop running when the terminal closes. You need to run the command below and kill any agents that you are not using.

man@earth> ps aux | grep agent

If there is more than one agent running then you should kill the additional ssh-agent.

man@earth> pkill ssh-agent

This will only kill agents owned by the user running the command in.

One way to kill your ssh-agents is to add a kill statement to the .bash_logout file.

Reference Section
Manpage ssh-copy-id

Free Blockchain training

I found some free training on Cryptocurrency or Blockchain technology. This training is from the people who bought us the Ethos wallet. Go to there site and checkout there free wallet and training.

Tape Format Script for Tape Pickup

The other day my co-worker showed me how to send our tapes offsite. Apparently you need to format the list of tapes in a certain way. So you can input the info to the Iron Mountain site for pickup. He was going though several steps to change the format in Excel. I told myself there has to be a better way, so wrote a script shown below.

First you need to put all the tapes in a list. I put the tape list in the file called list shown in the example below. Then I run the script, I created (tape-input.sh). I take the output and paste it into the web portal.


list

U00010L5
U00011L5
U00012L5
U00013L5
U00014L5
U00015L5
U00016L5
U00017L5
U00018L5
U00019L5
U00020L5
U00021L5
U00022L5
U00023L5
U00024L5
U00025L5
U00026L5
U00027L5
U00028L5
U00029L5
U00030L5 CAT

tape-input.sh

#!/bin/bash
# Created to format the tapes numbers to add to the web portal
echo -e "Packaged by man, $(date|awk '{print $2" "$3" "$6}')"

cat list |sed ':a;N;$!ba;s/\n/, /g'| perl -pe 's{,}{++$n % 3 ? $& :"\n"}ge'

man@earth> ./tape-input.sh
Packaged by man, Dec 13 2018
U00010L5, U00011L5, U00012L5
U00013L5, U00014L5, U00015L5
U00016L5, U00017L5, U00018L5
U00019L5, U00020L5, U00021L5
U00022L5, U00023L5, U00024L5
U00025L5, U00026L5, U00027L5
U00028L5, U00029L5, U00030L5 CAT

I take the output and paste it into the Iron Mountain web portal for pickup.

I hope this helps someone out. If you have any questions please ask below.

Fix RPM Database finding for UEFI file types

I ran into an issue the other day when was hardening a server. I couldn't change the file permissions on a few files to what the RPM database says is the default. This was in regard to the /boot/efi files or UEFI file types.

This is the check: rpm -Va

The security rule: RHEL-07-010010 "The Red Hat Enterprise Linux operating system must be configured so that the file permissions, ownership, and group membership of system files and commands match the vendor values." Basically the the check is to ensure the files have the default file permissions or less.
 
Also works for Red Hat 6
RHEL-06-000516, RHEL-06-000517, RHEL-06-000518, RHEL-06-000519

The Fix

Add the line below to /etc/fstab

UUID=####       /boot/efi     vfat umask=0177,shortnames=winnt  0 0

Unmount and mount /boot/efi

root@earth> umount /boot/efi
root@earth> mount /boot/efi

Some other reference materials.
Could not change permission for /boot/efi/EFI/redhat/grub.conf
Why do /boot/efi content always show up in rpm -Va output in UEFI enabled system?

How to lookup UUIDs
https://liquidat.wordpress.com/2007/10/15/short-tip-get-uuid-of-hard-disks/
https://liquidat.wordpress.com/2013/03/13/uuids-and-linux-everything-you-ever-need-to-know/