security

Securing Bash scripts is essential to prevent unauthorized access, accidental errors, or malicious activity. Here are best practices to secure your Bash scripts:

1. Use Absolute Paths

Always use absolute paths for commands and files to avoid ambiguity and to prevent the execution of unintended commands.

Example:

# Incorrect
rm -rf /tmp/*

# Correct
/bin/rm -rf /tmp/*

This ensures that the correct program is used, regardless of the user's environment or $PATH settings.

2. Avoid Using sudo or root Privileges in Scripts

If possible, avoid running scripts with sudo or root privileges. If root access is necessary, be explicit about which commands need it, and ensure they are used sparingly.

• Run only the necessary commands with sudo or root privileges.
• Consider using sudo with limited privileges (using sudoers file) to allow only certain actions.

Example (to limit permissions in sudoers file):

user ALL=(ALL) NOPASSWD: /path/to/safe/command

3. Sanitize User Input

Validate and sanitize all user input, especially when it's passed to commands, to prevent malicious injection, such as code injection or command substitution attacks.

Example:

# Avoid running commands directly with user input
read user_input
# Vulnerable to command injection

# Better approach: sanitize input
if [[ "$user_input" =~ ^[a-zA-Z0-9_]+$ ]]; then
  # Safe to proceed with the input
  echo "Valid input: $user_input"
else
  echo "Invalid input"
  exit 1
fi

4. Use Shellcheck for Script Linting

Use tools like ShellCheck to lint your scripts. It helps to catch errors, warnings, and potential security issues in your code.

shellcheck script.sh

5. Set Proper File Permissions

Set appropriate permissions for your script files to ensure they can only be executed by authorized users. You can use chmod to set permissions:

chmod 700 /path/to/script.sh  # Only the owner can read, write, or execute

6. Use set -e to Exit on Errors

Use set -e (also known as set -o errexit) to ensure that your script exits as soon as any command fails. This can help avoid unintended behavior.

#!/bin/bash
set -e  # Exit on error

You can also use set -u (also set -o nounset) to make your script fail if it tries to use undefined variables:

set -u  # Treat unset variables as an error

7. Quote Variables Properly

Always quote variables to prevent word splitting or globbing issues, which can be a security risk.

Example:

# Vulnerable to word splitting or globbing
file="/path/to/directory/*"
rm $file  # This can delete unintended files

# Safe way
rm "$file"

8. Log Sensitive Information Carefully

Avoid logging sensitive information such as passwords, keys, or tokens in clear text. If necessary, ensure logs are stored securely.

Example:

# Don't log passwords directly
echo "Password is: $password"  # Not secure

# Instead, log securely (e.g., obfuscated or masked)
echo "Password update successful"  # Better approach

9. Limit Access to Sensitive Files

If your script needs to access sensitive files (e.g., configuration files, private keys), make sure those files are protected with the right permissions and ownership.

# Set permissions to restrict access to sensitive files
chmod 600 /path/to/sensitive/file

10. Avoid Hardcoding Credentials

Never hardcode sensitive credentials such as passwords, API keys, or tokens directly in your script. Instead, use environment variables, configuration files with restricted access, or secret management systems.

Example:

# Avoid hardcoding secrets in the script
api_key="your-api-key"

# Better approach: Use environment variables
export API_KEY="your-api-key"

11. Use Secure Communication (TLS/SSL)

If your script communicates over a network, always use secure protocols like HTTPS instead of HTTP. Ensure that communication is encrypted, especially when transmitting sensitive data.

Example:

# Vulnerable (non-secure communication)
curl http://example.com

# Secure (encrypted communication)
curl https://example.com

12. Regularly Update and Patch Dependencies

Ensure that the tools and libraries your script depends on are kept up-to-date with the latest security patches. Regularly review the security of the script and its dependencies.

13. Use Proper Exit Statuses

Return appropriate exit statuses (0 for success, non-zero for failure) to indicate the result of the script’s execution. This allows better error handling and debugging.

Example:

#!/bin/bash
if some_command; then
  echo "Command succeeded"
  exit 0
else
  echo "Command failed"
  exit 1
fi

14. Use Restricted Shell (rbash) or AppArmor/SELinux

If the script is running on a multi-user system, consider restricting the environment with tools like rbash (restricted Bash shell) or enforce security policies with AppArmor or SELinux. These tools help limit what users can do, even if they gain access to the script.

15. Testing in a Safe Environment

Before running a script in a production environment, test it in a controlled, isolated environment. This helps to ensure that the script works as expected without causing unintended harm.

---

By following these best practices, you can significantly improve the security of your Bash scripts, minimizing the risks associated with running or sharing scripts in multi-user or production environments.

Safe and Secure SSH Connections

In a modern world where cyber-warfare is common place and every-day users are targets from organised crime, it goes without saying that you are likely to run into problems rather quickly if you don't use every available means of security.

The scope of this article is to connect via SSH Keys however you should also be doing some other more mundane tasks like encrypting the connection (preferably with a VPN on your router) and using altered ports, plus limiting access to SSH users, if you have them.

So what is the safest way to connect to your remote Linux OS distribution, by command line? Well quite simply, it is done with SSH Keys which you generate so that the connection can be established. These keys are then used as a form of password and where the remote user has these pre-generated keys on their system, SSH shares them and if allowed, serves the connection.

Generating Your Keys

From command line on the machine you are connecting from, do the following:

ssh-keygen - Leave as default values

This creates files inside your home directories .ssh folder. This is a hidden folder that you usually don't need access to. To see what's inside, do ls .ssh from your home path.

Now, do the following, from your home path:

cat .ssh/id_rsa.pub

This is your public password. Share this with unlimited amounts of remote servers and while you are using this account, you will have access.

Sharing Your Keys

On a mundane level, you can provide the key you generated via any method you like, only your machine and account will be able to use it.

Now, take the output of cat .ssh/id_rsa.pub, and do echo "key-here" >> .ssh/authorized_keys and voila, the magic is done. You can now do ssh user@example.com, password-free.

So that's one way of achieving passwordless login via SSH, although there is an easier way. Do:

ssh-copy-id user@example.com

This will auto-install the keys for you, assuming you can connect to the server via SSH using other authentication methods - such as password.

Removing Keys

To remove access to a users account, do vi .ssh/authorized_keys and delete the line corresponding to the users account.

It really is that simple!

Voila

Congratulations, you're all set up! Don't forget, while it is perfectly safe to share your id_rsa.pub key, do so with caution. Using it on your website homepage may attract unwanted attention!

Peace.