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

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.

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

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/

Manually Update Plugins on a Nessus Scanner (Windows)

I had an issue the other day with one of my Nessus Vulnerability Scanners which is being managed by Security Center. In Security Center the status of one of the Nessus scanners showed "Plugin Out of Sync". I tried to push the plugins to the Nessus scanner from the Security Center, but I was getting a status error of "Connection timed out".  So basically I was getting a latency issue on the connection. The Nessus scanner and the Security Center are in different states, so this may be why there is so much latency. I just built this Nessus scanner, so there were just too many plugins to be pushed over the wire by Security Center. To fix this issue, I just manually copied the plugins to the Nessus scanner. Then I manually loaded the plugins into the Nessus scanner. After I did this, I have not had this issue again.

Manually updating the Plugins can sometimes fix error or scanner status of "Protocol error". These instructions work on Nessus 5x and 6x, when managed by Security Center 4x or 5x.

Follow the instructions below to manually install plugins for the Nessus scanner on a Windows computer. For Linux computers click here.

1. Login to the Nessus scanner.

2. Open PowerShell or the Windows command line (CMD) as privileged user.

3. Stop the Nessus service

# net stop "Tenable Nessus"

4. Remove the Nessus scanner from Security Center

5. Reset the scanner

# …\Program Files\Tenable\Nessus>nessuscli fix --reset

6. Connect the Nessus scanner

# …\Program Files\Tenable\Nessus>nessuscli fetch –security-center

7. Load the plugins into Nessus

# …\Program Files\Tenable\Nessus>nessuscli update plugins_file.tar.qz

8. Start the Nessus scanner

# net start “Tenable Nessus”

9. Login to the web interface for Nessus and verify that the configuration is complete.
https://localhost:8834

10. Login to the web interface for the Security Center. Add the Nessus scanner back and verify connectivity.

Your done.

Related posts
On this Blog

How to Reset a Nessus Scanner

The other day I installed a new Nessus Vulnerability Scanner which is a security scanner that is often controlled Security Center, both of which are Tenable products. After I finished the install and configured the Nessus scanner to be managed by Security Center.  I tried to log back into the scanner and discovered I was locked out. So I figured I could just reinstall the Nessus scanner, after all it only take a few minutes to do. I reinstalled Nessus and I was still locked out, what gives. Below are the steps used to get back into the scanner. I later found an even easier way to get back into the Nessus scanner, which I also posted below.

Follow the steps below to uninstall the Nessus scanner and remove the configuration files.

1. Optional - Stop the nessusd service

root@earth> service nessusd stop

2. To uninstall Nessus remove the Nessus package

root@earth> rpm -e nessus-package

For some reason /opt/nessus still exists after the Nessus package is removed

3. Remove the Nessus directory.

root@earth> rm -r /opt/nessus

Note- Don't worry the Nessus the files will be recreated after the reinstall.

Note- If the /opt/nessus directory is not removed, then your account will still be locked. This is because the configuration files will still exist.

4. Now install Nessus

root@earth> rpm -ivh nessus.rpm

5. Go to the Web interface to finish the configuration of the scanner
https://nessus:8834

Installing Nessus and setting it up to be managed by Security Center takes very little time, but you

Create a new user and/or set the user password.

Add user to scanner

root@earth> /opt/nessus/sbin/nessuscli  adduser  newuser

Change password on the nessus scanner

root@earth> /opt/nessus/sbin/nessuscli  chpasswd username

I showed you in a previous post "Reset Admin account on Security Center" how to do this for Security Center.

Related posts on this site:
Reset Admin account on Security Center
Manually Update Plugins for your PVS
Manually Update Plugins on a Nessus Scanner

Manually Update Plugins for your PVS

I had an issue the other day with one of my Passive Vulnerability Scanners (PVS) which is being managed by Security Center. In Security Center the status of one of the PVS scanners showed "Plugin Out of Sync". I tried to push the plugins to the PVS scanner from the Security Center, but I was getting a status error of "Connection timed out".  So basically I was getting a latency issue on the connection. The PVS scanner and the Security Center are in different states, so this may be why there is so much latency. I just built this PVS scanner, so there were just too many plugins to be pushed over the wire by Security Center. To fix this issue, I just manually copied the plugins to the PVS scanner. Then I manually loaded the plugins into the PVS scanner. After I did this, I have not had this issue again.

Follow the instructions below to manually install plugins for the PVS scanner.

1. Login to the PVS scanner.

root@earth> ssh pvs

2. Stop the PVS service.

root@nessus> service pvs stop

3. Load the plugins into PVS.

root@nessus> /opt/pvs/var/pvs --update-plugins  plugins_file.tar.gz 

4. Start the PVS service

root@nessus> service pvs start

5. Login with an admin account to the web interface for the Security Center and check the status of the PVS.

You're done.

If you have any questions or comments please post them below.

Related post on this Blog
Manually Update Plugins on a Nessus Scanner
Reset Admin account on Security Center
How to Reset a Nessus Scanner

Manually Update Plugins on a Nessus Scanner (Linux)

I had an issue the other day with one of my Nessus Vulnerability Scanners which is being managed by Security Center. In Security Center the status of one of the Nessus scanners showed "Plugin Out of Sync". I tried to push the plugins to the Nessus scanner from the Security Center, but I was getting a status error of "Connection timed out".  So basically I was getting a latency issue on the connection. The Nessus scanner and the Security Center are in different states, so this may be why there is so much latency. I just built this Nessus scanner, so there were just too many plugins to be pushed over the wire by Security Center. To fix this issue, I just manually copied the plugins to the Nessus scanner. Then I manually loaded the plugins into the Nessus scanner. After I did this, I have not had this issue again.

Manually updating the Plugins can sometimes fix error or scanner status of "Protocol error". These instructions work on Nessus 5x and 6x, when managed by Security Center 4x or 5x.

Follow the instructions below to manually install plugins for the Nessus scanner on a Linux server. To do this on a Windows computer go here.

1. Login to the Nessus scanner.

root@earth> ssh nessus

2. Stop the Nessus service.

root@nessus> service nessusd stop

3. Remove the scanner from Security Center.

4. Reset the scanner

root@nessus> /opt/nessus/sbin/nessuscli fix --reset
Resetting Nessus configuration will permanently erase all your settings and causes Nessus to become unregistered.
Do you want to proceed? (y/n) [n]: y
Successfully reset Nessus configuration.

5. Connect the Nessus scanner.

root@nessus> /opt/nessus/sbin/nessuscli fetch --security-center
nessud can now be started, SeccrityCenter will upload the plugins

6. Manually copy over the plugins file.
    Copy the file tar.gz file from Security Center to or download latest plugins from Tenable.

Note - In Security Center The plugins are located here: /opt/sc/data/plugins

7. Load the plugins into Nessus.

root@nessus> /opt/nessus/sbin/nessuscli update plugins_file.tar.gz

* Update successful. The changes will be automatically processed by Nessus 

8. Start the Nessus service

root@nessus> service nessusd start

9. Login to the web interface for Nessus and wait for the bar to complete.

root@nessus> firefox https://localhost:8834

10. Login to the web interface for the Security Center. Add the Nessus scanner back and verify connectivity.

You're done.

If you have any questions or comments please post them below.

Related posts
Manually Update Plugins for your PVS
Reset Admin account on Security Center

Is SELinux running?

There is a simple question that you need to know when you get a new Linux server to manage, is SELinux running? If so, what are its setting? Below are some ways to answer these questions.

See if the SELinux configuration file exists and if it does what the settings for SELinux are.

root@earth> cat /etc/sysconfig/selinux
#    This file controls the state of SELinux on the system.
#    SELINUX= can take one of these three values:
#                enforcing - SELinux security policy is enforced.
#                permissive - SELinux prints warnings instead of enforcing.
#                disabled - No SELinux policy is loaded.
SELINUX=permissive
#    SELINUXTYPE= can take one of these two values:
#               targeted - Only targeted network daemons are protected.
#               strict - Full SELinux protection.
#               mls - Multi Level Security protection.
SELINUXTYPE=targeted
#    SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

The getenforce command displays the current SELinux enforcement policy being used.

root@earth> /usr/sbin/getenforce
Permissive

The sestatus command is a tool that is used to get the status of  a system running SELinux.

root@earth> /usr/sbin/sestatus
SELinux status:              enabled
SELinuxfs mount:           /selinux
Current mode:                permissive
Mode from config file:     permissive
Policy version:               21
Policy from config file:    targeted

Reference
Security Enhanced Linux (SELinux) project page
Wikipedia - SELinux

Disable VRFY for Postfix (Retina ID 146)

The Retina Network Security Scanner from BeyondTrust, Inc was run against my servers and ID 146 was a hit or finding on one of my servers. Retina can give good results on network security vulnerabilities, but false finds are also common. The problem with that the scanner is that it doesn't show you how it finds the vulnerability or how to fix it. I did some research and it turns out that you need to disable the VRFY command in postfix. Below I have posted the security vulnerability from Retina, with instructions on how to fix the issue.

What Retina says about the vulnerability 

Retina ID or vID 146
Description The VRFY command can lead to a remote attacker gaining the first and last name registered to any given email account. This can aid an attacker in social engineering attacks.

Discussion - fix Follow your SMTP server's manual on how to disable the VRFY command. If no instructions are provided contact your SMTP server's vender.

Severity = Low to Med
SevCode = III
Port = TCP:25
IA Controls = Mail Server

Retina scan Version 5.19.9.2802
Expected "252" and found "252 2.0.0. administrator"

Test for this issue.

man@earth> telnet localhost 25
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
220 earth.planet.com ESMTP Postfix
VRFY
502 5.51.1 VRFY command is disabled

If the VRFY command does not come back as "VRFY command is disabled" then this is a finding.

Remediation
Add this line below to the /etc/postfix/main.cf.

disable_vrfy_command = yes

Reference section

Ref for fix:
cyberciti.biz

Ref for Security issue:
iss.net
xforce.iss.net

Manpages
Sendmail
Postfix

See Cyber Attacks on Global Scale

I found this website that claims to show live cyber attacks.

http://map.ipviking.com/

How to install or upgrade Java in Linux

These are my notes on how to install or update Java on a Linux server. In this how to, I will be using the Java from Oracle and not the operating systems or distros repository. You can download and install either a rpm or a tar file, from Oracle's site.

When using the Java provided on Oracle's website, they give you a choice of downloading rpm or tar file.

You can download Java here.
http://www.java.com/en/download/linux_manual.jsp

Installing Java with using RPM

Find the current version of Java on the system.

root@earth> find / -name java -type f
/usr/java/jre1.7.0_55/bin/java

Note If you use which or java -version commands to find Java on you system. This will only show your the system's main java. You may have additional versions installed.

Now take each line of output and paste it at the end of this command. This gives you the name of the rpm package that installed this file and version of Java.

root@earth> rpm -qf    /usr/java/jre1.7.0_55/bin/java
jre-1.7.0_55-fcs

Uninstall the old package.

root@earth> rpm -e  jre-1.7.0_55-fcs

Note- Do not run the above command for java that is part of an application. If the file was in /usr/bin/ you should be fine.

Install Java

root@earth> rpm  -ivh    jre-7u65-linux-x64.rpm

You can alternately upgrade Java instead.

root@earth> rmp   -Uvh    jre-7u65-linux-x64.rpm

Install Java using a tar file
Change directory to where Java is going to be installed. Usually it will be /user/java.

root@earth> cd  /usr/java

Move the tar file to /usr/java.

Unpack the tarball and install Java

root@earth> tar  zxvf   jre-7u65-linux-i586.tar.gz

Delete the tar file after you test Java and your done.

Reference:
Java.com

Related posts on this Blog
How to install Java 7 & 8 on Solaris
Access the Java Control Panel
Updating Java on Solaris

Checking Java Versions Remotely

This is the script I use to find instances of Java, on the servers I manage. To do this I use two scripts, check-java and stig-java. The check-java script logs in to each server listed in the server-list file and acts  as the control for the other script. The check-java script also combines the output of the stig-java script from each server and combines the output into a single file. The stig-java script looks for Java on the servers and sends the output to a file.

I order for this script to work you will need to setup your SSH clients for auto login. If you don't know how to do this please refer to my post How to setup SSH Keys. This script doesn't needs the automount in order to work.

What the scripts do.
First off you need to put both script in the same location. Put the scripts in your home directory in a folder called scripts. The main script, check-java copies the stig-java script to /tmp on all the servers. Then logs into all the servers, one at a time, and runs the stig-java script and sends the output to a file with the servers name. The check-java script then deletes stig-java form /tmp on all the servers. All those output files are then combined into a single file with extra lines removed.


The check-java script

#!/bin/bash
# This script is for running the stig-java script on the servers.

for s in `cat  server-list`
scp stig-java $s:/tmp 2>&1 2>/dev/null
ssh -q $s /tmp/stig-java &> ~/scripts/outputJ/$s
ssh -q $s rm /tmp/stig-java
done
cat ~/scripts/outputJ/* |egrep -v '(Runtime|HotSpot)' > ~/scripts/outputJ/solM

# Finishing up
echo -e "\e[1m ------------------------ Servers -------------------------  \033[0m" > ~/scripts/outputJ/output
echo -e " "
cat ~/scripts/outputJ/solM >> ~/scripts/outputJ/output
more ~/scripts/outputJ/output

The stig-java script

#!/bin/bash
# This script is for finding versions of Java on a server.
#
host=$HOSTNAME
echo -e "\e[1m <<<<<<<<<<<<<<<<<<<<<<<<<<<<< $host >>>>>>>>>>>>>>>>>>>\033[0m "
sudo find / \( -name 10_Recommended* -o -name scratch -o -name zones -o -name mnt  \) -prune -o -type f -name java -print 2>/dev/null >/tmp/joutput
for s in `cat /tmp/joutput`
do echo -e "\e[1m  $s \033[0m "
sudo $s -version
done
echo -e " "
rm /tmp/joutput

Let me know if this script is helpful in anyway. If you need more details or have questions let me know, by posting below.

Check for a blank SSH key passphrase

I found out one of my co-workers was not using a passphrase to secure his SSH keys. This is very insecure way to do business. Many people leave passphrase blank because they do not know how to setup a SSH agent, or can't be bothered with setting up the SSH agent. If you don't know to set up a SSH agent refer to my How to setup SSH Keys post. I came up with a way to check all the accounts on the servers I manage. I wanted to know how many other people where not practicing good security. I have tested this script on Solaris 10, Red Hat Linux (RHEL 5) and SuSe (SLES 11.2).

What the script does.
The script mounts the share that all the users home directories auto-mount from.  This way the user needs not to be logged in for me to check there keys. I then copy all the names of the users home directories into a file. The script checks then checks for the word  ENCRYPTED in the id_rsa file. If the word ENCRYPTED is in the file then the passphrase is set. The temp files are then removed and the share unmounted.

This my script I came up with.

#!/bin/bash
# This script is for checking for a blank passphrase. Meaning no passphrase
to secure your SSH file.
# Script most be run as root.
# Example: sudo ./check-sshkeys

mount share:/vol/home /mnt
ls /mnt >/tmp/ls
for s in `cat /tmp/ls`
do echo -e "\e[1m User $s \033[0m "
if ls /mnt/$s/.ssh/id_rsa 2>/dev/null
        then grep ENCRYPTED /mnt/$s/.ssh/id_rsa || echo -e "No RSA
passphrase"
        else echo "RSA key not found"
fi
if ls /mnt/$s/.ssh/id_dsa 2>/dev/null
        then grep ENCRYPTED /mnt/$s/.ssh/id_dsa || echo -e "No DSA
passphrase"
        else echo "DSA key not found"
fi
done
rm /tmp/ls
umount /mnt

Draw backs
Now there are ways that a user can get around this, like putting the word ENCRYPTED in the right file. But most users will not do this, so this should still work for most users. The script above will need to be modified in order to check users who don't have their home directories auto-mounted.

I can't take all the credit for this, I had some help. Below I have posted the link to the forum were I  asked for help on this script.

Ref:
Is there a way to check a users SSH key to see if the passphrase is blank

Installing Firefox on Solaris (Update III)

These are my updated notes on how to install Firefox on a Solaris 10 server. In this installment, I will go over two different ways to install Firefox. I will be using the files found at the Mozilla website, which just started hosting these files. To check out my previous posts on installing Firefox please check out at the bottom of this post.

The files on the Mozilla site, are the same files that can be found at Sunfreeware.com or UNIXpackages.com. The only issue with getting Firefox from this site is that it is not actually from them. They go out of there way to say this on there site and I quote; "They are the ONLY packages in our repository that are not compiled by us, and were contributed by External Offshore developers in East Asia". The README file on the site says that they where contributed by Oracle Solaris Desktop Beijing Team. I checked with the local Oracle reps in the area and they can't confirm that install files are from Oracle. Anyway if this is not an issue for you then follow the instructions below to install Firefox.

Get the Files
Use the links below to download the files needed for this how to.
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/24.0esr/contrib/solaris_pkgadd/
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/24.0esr/contrib/solaris_tarball/

We will use the files below to install Firefox.
firefox-24.1.1esr.en-US.solaris-10-fcs-sparc.tar.bz2
firefox-24.1.1esr.en-US.solaris-10-fcs-sparc-pkg.bz2

Install Firefox from a tar file.
One advantage of installing Firefox with a tar file is that you can install Firefox almost anywhere.  Run the following commands to install Firefox.

root@earth> mv firefox-* /usr/lib/
root@earth> cd /usr/lib
root@earth> bzip2 -cd firefox-24.1.0esr.en-US.solaris-10-fcs-sparc.tar.bz2 | tar xvf - root@earth> ln -s /usr/lib/firefox/firefox /usr/bin/firefox

Start Firefox.

root@earth> firefox

Install Firefox from a package.

root@earth> bzip2 -d firefox-24.0esr.en-US.solaris-10-fcs-sparc-pkg.bz2
root@earth> pkgadd -d ./firefox-24.0esr.en-US.solaris-10-fcs-sparc-pkg

The following packages are available:
   1  SFWatk           ATK - Accesibility Toolkit Libraries
                       (sparc) 1.24.0,REV=110.0.4.2009.02.26.22.56
   2  SFWcairo        Vector graphics library
                       (sparc) 1.8.4,REV=110.0.4.2009.02.26.23.05
   3  SFWfirefox     Mozilla Firefox Web browser
                       (sparc) 24.1.0esr,REV=110.0.4.2013.10.24.13.53
   4  SFWglib2       Low level core compatibility library for GTK+ and GNOME
                      (sparc) 2.18.3,REV=110.0.4.2009.02.27.14.31
   5  SFWgtk2        GTK+ - GIMP Toolkit Library for creation of graphical user interfaces
                      (sparc) 2.14.5,REV=110.0.4.2011.05.26.09.57
   6  SFWpango      Library for layout and rendering of internationalized text
                      (sparc) 1.22.3,REV=110.0.4.2009.02.26.23.21
   7  SFWpixman    Vector graphics library
                      (sparc) 0.12.0,REV=110.0.4.2009.02.26.23.01

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

You can install all the packages listed above or just the Firefox package (SFWfirefox). Firefox will be installed at /opt/sfw/lib/firefox. The install process will link the Firefox exacuteable to /usr/local/bin/firefox. Start firefox as shown below.

root@earth> firefox

If Firefox doesn't start then I would make sure that /usr/local/bin in your path.

My Other Firefox posts.
Installing Firefox on a Solaris server
Installing Firefox on Solaris (Update)
Installing Firefox on Solaris (Update II)

Installing Firefox on Solaris (Update II)

This part three of my "How to Install Firefox" series of posts. Please read the other Firefox posts linked to at the bottom of this post, for additional information. This post is an update on the Firefox situation on Solaris.

The Oracle Security Blog, posted on October 13, 2013, the long awaited patch for Firefox. You will need a MOS (My Oracle Support) login to download the patches though. Patch 145080-13 for SPARC and patch 145081-12 for X86 will upgrade Firefox to 10.0.12 ESR. This is pathetic considering that at the time I'm writing this, Firefox is at version 24.0. Mozilla doesn't even support Firefox 10 ESR anymore. So why is Oracle giving us this now? Most operating systems are using Firefox 17 ESR right now and they will soon be moving to version 24 ESR. On top of that, Oracle's security blog also doesn't address any of the security vulnerabilities for 2013.

Note - Mozilla doesn't offer Firefox install packages for Solaris.

Current Mozilla supported versions

• Firefox 17.0.9 ESR
• Firefox 24.0
• Firefox 24.0 ESR

Now on the install on Firefox.
The package Solaris uses for the Firefox install is SUNWfirefox. Run the command below to make sure that package is installed. There may be other Firefox related packages, that's OK.

root@earth> pkginfo -l | grep firefox
PKGINST: SUNWfirefox
PKGINST: SUNWfirefoxl10n-es-ES
PKGINST: SUNWfirefox-devel

If the package is not installed then you will have to install it. Unfortunately it installs Firefox 3, so you need to patch it right away. As I mentioned above the patch will update Firefox to 10.0.12. If this is the 1st patch to be applied to Firefox it may take some time, this is normal. In the example below we are installing the SPARC patch.

root@earth> mv 145080-13 /tmp
root@earth> unzip 145080-13
root@earth> pkgadd 145080-13

And you're done. Test the application. If your previous version of Firefox was not part of a package, but instead was install using a tar file then you will have to delete it from the server. I have instructions on how to do that in my 1st post on how to install Firefox.

Info
I have removed Firefox from my server at work because I don't think it is secure on Solaris 10. I am instead using Firefox on Linux server, until Oracle gets their act together. I have heard that Oracle will be releasing FireFox 17 ESR soon. The only problem is, Firefox is only coming to Solaris 11 and not Solaris 10. You can still get Firefox at SunFreeware.com or UNIXpackages.com, which are the same people. The only issue with getting Firefox from there site is that it is not actually from them. They go out of there way to say this on there site and I quote; "They are the ONLY packages in our repository that are not compiled by us, and were contributed by External Offshore developers in East Asia". 

Links to my other Firefox install posts
Installing Firefox on Solaris
Installing Firefox on Solaris (Update)
Installing Firefox on Solaris (Update III)

If you have any comments or question please post them below.

Checking for HTTP

I often need to check what version of Apache HTTP server is running in our environment. I also need to check for what modules are installed. The examples are form a Solaris 10 server and can be applied to any UNIX based operating system, like Linux.

The command below is the basic command for checking the HTTP version.

man@earth> httpd -v

It is best to run the find command. This way you can find any instaces on HTTP as well as any embedded versions that may be hiding on the server.

root@earth> find / -name httpd -type f 2>/dev/null
/usr/local/apache2/bin/httpd

Then to check the version run the following command.

man@earth> /usr/local/apache2/bin/httpd -v
Server version: Apache/2.2.25 (Unix)
Server built: Jul 31 2013 23:39:37

Below is the command for checking what modules are installed.

man@earth> httpd -M

Other sites with info on this.
www.cyberciti.biz
nixcraft.com

Related posts
Version index

Get the OpenSSL version

I often have to check which versions of applications we have installed our servers. Below I have post the method of checking the version of OpenSSL installed on a server. The command below should work with any UNIX based operating system. I might even work on Windows.

man@earth> openssl version -a

To find the non system or embedded versions you will have to run the find command. Shown below.

root@earth> find / -name openssl -type f 2>/dev/null

I hope this helps someone