Accessing your WSL2 instance remotely via SSH can be incredibly useful.
Here’s a quick guide to set it up:

1. Install OpenSSH Server

Run the following commands in your WSL2 instance (valid for Debian-like distros):

sudo apt update
sudo apt install openssh-server
sudo nano /etc/ssh/sshd_config

Edit your sshd_config file as needed (e.g., ensure PermitRootLogin is set to no, etc...)

2. Allow SSH Through Windows Firewall

Run the following command:

netsh advfirewall firewall add rule name="WSL SSH Access" dir=in action=allow protocol=TCP localport=22

Or via the GUI, open Windows Defender Firewall settings.
Navigate to Advanced Settings > Inbound Rules.
Add a new rule:

• Type: Port
• Port: 22 (or your custom SSH port)
• Action: Allow the connection
• Profile: All
• Name: WSL SSH Access

3. Forward Ports From Windows to WSL

Run the following PowerShell commands:

$wslIP = wsl hostname -I | ForEach-Object { $_.Trim() }
netsh interface portproxy add v4tov4 listenaddress=* listenport=22 connectaddress=$wslIP connectport=22

This ensures SSH connections to your Windows IP are forwarded to WSL.

4. Start the SSH Service

Given that standard methods like enabling it via systemctl do not work, we have to start the SSH server manually.

From the Linux WSL:

sudo /usr/sbin/service ssh start

Now, you can SSH into your WSL2 instance using your Windows IP address!

ssh user@<windows_ip>

Make the Solution Persistent Across Restarts

But the access will not work after a restart of the windows machine given that the WSL IP address would change.
To make SSH access persist after a system reboot, create a PowerShell script and configure it to run at boot:

1. Open Task Scheduler and create a new task:
   • General Tab:
     • Name: WSL SSH Setup
     • Check Run with highest privileges.
     • Select Run whether user is logged on or not.
   • Triggers Tab:
     • Add a trigger with Begin the task set to At startup.
   • Actions Tab:
     • Add an action with:
       • Program/script: powershell.exe
       • Arguments: -ExecutionPolicy Bypass -File "C:\Scripts\wsl-ssh.ps1"
   • Save the task and provide your Windows credentials if prompted.

Save the following script as C:\Scripts\wsl-ssh-setup.ps1:

$wslIP = wsl hostname -I | ForEach-Object { $_.Trim() }
netsh interface portproxy delete v4tov4 listenaddress=* listenport=22
netsh interface portproxy add v4tov4 listenaddress=* listenport=22 connectaddress=$wslIP connectport=22
wsl -d Debian -- sudo /usr/sbin/service ssh start

This toolset facilitates the migration of content from BookStack to Outline, a modern knowledge base. The tool includes two Python scripts:

1. export_from_bookstack.py: Exports content from BookStack into a JSON file.
2. import_to_outline.py: Imports the exported JSON file into Outline

Features

• Converts BookStack shelves to Outline collections.
• Converts BookStack books, chapters, and pages to Outline documents.
• Maintains document hierarchy during the migration.
• Automatically downloads and saves images into the Outline storage during the import process.
• Orphaned books (books not placed in a shelf) are imported under "Orphaned books" collection

Installation

1. Clone the repository:
   git clone https://github.com/somoit-net/bookstack_outline_migrator.git
2. cd bookstack_outline_migrator
3. Install the necessary Python packages
   pip3 install -r requirements

Configuration

A sample config.txt file is included in the repository. You need to update this file with your specific BookStack and Outline credentials and URLs.

# Bookstack and Outline config

# Bookstack
BOOKSTACK_BASE_URL=https://bookstack.mydomain.com
BOOKSTACK_API_TOKEN_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
BOOKSTACK_API_TOKEN_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
BOOKSTACK_EXPORT_FILENAME=bookstack_export.json

# Outline
OUTLINE_BASE_URL=https://outline.mydomain.com
OUTLINE_API_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• BOOKSTACK_BASE_URL: URL of your BookStack instance.
• BOOKSTACK_API_TOKEN_ID: Your BookStack API token ID.
• BOOKSTACK_API_TOKEN_SECRET: Your BookStack API token secret.
• BOOKSTACK_EXPORT_FILENAME: Name of the file where the exported data will be saved (default is bookstack_export.json).
• OUTLINE_BASE_URL: URL of your Outline instance.
• OUTLINE_API_TOKEN: Your Outline API token.

Usage

1. Export from BookStack

To export content from BookStack, run the following command:

python3 export_from_bookstack.py

This will generate a JSON file named as specified in BOOKSTACK_EXPORT_FILENAME.

Note: Ensure that the BookStack site is accessible and the config.txt file is correctly configured.

2. Import to Outline

To import the exported content into Outline, use the following command:

python3 import_to_outline.py

The output is similar to the import process

Note: The Bookstack site must still be accessible so the script can automatically download the images.

Our Bash script leverages SNMP to check the status of VPN tunnels. Although this example focuses on a VSX environment, the script can be adapted for a standard Check Point deployment with minimal changes.

Below is the complete script:

#!/bin/bash

HOST=$1
VS=$2
PEER_GW=$3
SNMP_USER=$4
SNMP_PASS=$5

SNMP=$(snmpwalk -v 3 -l authNoPriv -u $SNMP_USER -A $SNMP_PASS -n ctxname_vsid$VS $HOST .iso.org.dod.internet.private.enterprises.checkpoint.tables.tunnelTable.tunnelEntry.tunnelState.$PEER_GW.0 2> /dev/null)

if [ -z "$SNMP" ]; then
    echo "UNKNOWN: No SNMP response from $HOST"
    exit 3
fi

RESULT=$(echo $SNMP | awk '{ print $9 }' 2> /dev/null)

case $RESULT in
    3)
        echo "OK - VPN tunnel is active (state $RESULT)"
        exit 0
        ;;
    4)
        echo "Critical - VPN tunnel is destroyed (state $RESULT)"
        exit 2
        ;;
    129)
        echo "Warning - VPN tunnel is idle (state $RESULT)"
        exit 1
        ;;
    130)
        echo "Critical - VPN tunnel is during Phase1 (state $RESULT)"
        exit 2
        ;;
    131)
        echo "Critical - VPN tunnel is down (state $RESULT)"
        exit 2
        ;;
    132)
        echo "Critical - VPN tunnel is initializing (state $RESULT)"
        exit 2
        ;;
    *)
        echo "Unknown - VPN tunnel state unknown"
        exit 3
        ;;
esac

• Input Parameters: The script takes five input parameters: the host (IP address or hostname of the Check Point device), the VSID (Virtual System ID), and the peer gateway ID, and the SNMP credentials (USER + PASS)
• SNMP Query: Using snmpwalk, the script queries the Check Point device for the VPN tunnel state. The SNMPv3 protocol ensures secure querying.
• State Evaluation: The script evaluates the returned state and provides corresponding output messages:
  • 3: VPN tunnel is active.
  • 4: VPN tunnel is destroyed.
  • 129: VPN tunnel is idle.
  • 130: VPN tunnel is in Phase 1.
  • 131: VPN tunnel is down.
  • 132: VPN tunnel is initializing.
• Exit Codes: The script uses standard Icinga plugin exit codes (0 for OK, 1 for Warning, 2 for Critical, and 3 for Unknown).

Prerequisites

Before using this script, ensure SNMP is enabled and properly configured on your Check Point gateway. In this example, SNMP v3 with user/password authentication is configured and used to authenticate and query the SNMP.

Test it

After granting proper execution permissions, an example test:

$ ./check_fw_tunnelstate.sh myvsx 2 195.95.95.95 snmp_user snmp_password
OK - VPN tunnel is active (state 3)

Finally, some additional steps are needed to configure it in Icinga, like the command definition, the service definition and reloading the Icinga services so the tunnel is finally monitored:

When trying to use the SQL server linux command-line clients, mssql-cli in a continuous loop without connecting to the SQL server succesfully without any output and sqlcmd returned this error:

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : TCP Provider: Error code 0x2746.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Client unable to establish connection.

Network traces showed that the server returned a FYN packet on both cases:

14:09:49.913302 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [S], seq 1942944609, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
14:09:49.913731 IP 10.100.10.40.60725 > 10.98.13.2.55743: Flags [S.], seq 3664072506, ack 1942944610, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
14:09:49.914092 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [.], ack 1, win 1026, length 0
14:09:49.914501 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [P.], seq 1:89, ack 1, win 1026, length 88
14:09:49.914813 IP 10.100.10.40.60725 > 10.98.13.2.55743: Flags [P.], seq 1:49, ack 89, win 513, length 48
14:09:49.926536 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [P.], seq 89:397, ack 49, win 1026, length 308
14:09:49.927209 IP 10.100.10.40.60725 > 10.98.13.2.55743: Flags [F.], seq 49, ack 397, win 512, length 0
14:09:49.927379 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [.], ack 50, win 1026, length 0
14:09:49.927610 IP 10.98.13.2.55743 > 10.100.10.40.60725: Flags [F.], seq 397, ack 50, win 1026, length 0
14:09:49.927868 IP 10.100.10.40.60725 > 10.98.13.2.55743: Flags [.], ack 398, win 512, length 0

After some research, i found a forum in someone suffered this problem commenting it was related to the configuration of openssl.

This was my configuration:

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

After changing the CipherString...

CipherString = DEFAULT@SECLEVEL=0

... both clients started to work.

I was doing it from an external machine via SSH and SCP, but i have decided to run it locally in the F5 system:

#!/bin/bash

DEVICE_NAME="bigip1"
SHARE="//my_fileserver/myshare"
SHARE_PATH="F5_backups"
SHARE_CREDENTIALS_FILE="/opt/scripts/.smbcredentials.txt"


TODAY=$(date +%Y%m%d)
LOCAL_FILE="${DEVICE_NAME}_$TODAY"
LOCAL_PATH="/dev/shm"

tmsh save /sys ucs $LOCAL_PATH/$LOCAL_FILE > /dev/null

cd $LOCAL_PATH
smbclient -A $SHARE_CREDENTIALS_FILE $SHARE -c "cd $SHARE_PATH; put $LOCAL_FILE.ucs" 2> /dev/null
cd -

rm $LOCAL_PATH/$LOCAL_FILE.ucs

It needs and smb credentials file (of a user with permissions in the SMB share) with the format showed below:

username=myuser
password=mypassword
domain=mydomain.com

(the domain in case it is necessary)

Just configure the execution in the cron (for example weekly, or daily) and the backups are ready for any disaster

[Expert@mgmt_server:0]# mgmt_cli login user "myuser" password mypassword" -f json
{
   "code" : "generic_error",
   "message" : "Error 503. The Management API service is not available. Please check that the Management API server is up and running."
}

The API status only confirmed that the API was not running but no more clues:

[Expert@mgmt_server:0]# api status

API Settings:
---------------------
Accessibility:                      Require all granted
Automatic Start:                    Enabled

Processes:

Name      State     PID       More Information
-------------------------------------------------
API       Stopped
CPM       Started   29253     Check Point Security Management Server is running and ready
FWM       Started   27142
APACHE    Started   8772

Port Details:
-------------------
JETTY Internal Port:
APACHE Gaia Port:         443

Profile:
------------
Machine profile:  24800-35800 with SME
CPM heap size:    2048m
API heap size:



--------------------------------------------
Overall API Status: The API Server Is Not Running!
--------------------------------------------

Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'

Checking the "api.elg" log file took me to the correct path:

[Expert@mgmt_server:0]# tail -20 /opt/CPsuite-R80.40/fw1/log/api.elg | grep -i error
2024-03-27 08:58:09,072  WARN org.eclipse.jetty.xml.XmlParser.fatalError:404 [main] - FATAL@null line:-1 col:-1 : org.xml.sax.SAXParseException: Premature end of file.

Seems that $FWDIR/api/conf/jetty.xml file is empty:

[Expert@mgmt_server:0]# cat $FWDIR/api/conf/jetty.xml
[Expert@mgmt_server:0]#

With a bit more research i found this official article:https://support.checkpoint.com/results/sk/sk144332

I had to recover the contents of the file by installing another management server in a different machine. (check this post https://somoit.net/checkpoint/checkpoint-recover-sms-disaster/ the steps "install checkpoint 1" and "install checkpoint 2"). After installing and copying the file into the production server, i started the api server succesfully:

[Expert@mgmt_server:0]# api start
2024-Mar-27 09:04:01 - Starting API...
. . . . . . . .
2024-Mar-27 09:04:48 - API started successfully.

And again i was able to use it and make calls:

[Expert@mgmt_server:0]# mgmt_cli login user "myuser" password "mypassword" -f json
{
  "uid" : "*******************************",
  "sid" : "********************************************",
  "url" : "https://127.0.0.1:443/web_api",
  "session-timeout" : 600,
  "api-server-version" : "*.*.*"
}

Recently, I encountered an interesting scenario in which an "Exchange Delegation Federation" certificate on one of our Exchange servers appeared to be duplicated.

Get-ExchangeCertificate | select-object Thumbprint,SerialNumber,Services,Subject | where { $_.Subject -eq "CN=Federation" }

Thumbprint                               SerialNumber                             Services Subject
----------                               ------------                             -------- -------
1ABC4623DE565ABBAECE1ABC4623DE565ABBAECE A156734AB54685EF673EFAABFE7864 SMTP, Federation CN=Federation
43FABC56DE565ABBAECE1ABC4623DE565BCA42A1 F2BCFA4AB54685EF673EFAABBABA21 SMTP CN=Federation

This certificate is necessary for the hybrid environment and the redundancy raised concerns about unnecessary overhead and potential complications in certificate management. To address this issue, I decided to investigate further and take appropriate action.

First, I carefully examined the certificate details and its associated services using the Get-ExchangeCertificate cmdlet. This revealed that the certificate assigned to both federation and SMTP services was effectively serving all necessary functions. Conversely, the second certificate, assigned only to SMTP, seemed redundant (no send or receive connectors were using this certificate).

So i decided to remove it (previously exporting it as 'backup'):

Remove-ExchangeCertificate 43FABC56DE565ABBAECE1ABC4623DE565BCA42A1

Get-ExchangeCertificate | select-object Thumbprint,SerialNumber,Services,Subject | where { $_.Subject -eq "CN=Federation" }

Thumbprint                               SerialNumber                             Services Subject
----------                               ------------                             -------- -------
1ABC4623DE565ABBAECE1ABC4623DE565ABBAECE A156734AB54685EF673EFAABFE7864 SMTP, Federation CN=Federation

Fortunately, the removal process went smoothly without any adverse effects on Exchange functionality. With the redundant certificate removed potential points of failure are reduced and streamlined certificate maintenance tasks.

However, despite efforts to create strong passwords, sometimes they can be compromised. In this blog post, we'll delve into the process of cracking Windows machine passwords, shedding light on the methods used and the tools involved.

Tools we will use

• pwdump: A utility for dumping password hashes from the SAM database on Windows systems.
  Link: website
  Link: pdump8-8.2.zip
• John the Ripper: A powerful password cracking tool that supports various cracking techniques and hash formats. Usually used under linux, in this example we are using the windows version.
  Link: website
  Link: john-1.9.0-jumbo-1-win64.zip
  
• "rockyou" wordlist: A commonly used wordlist containing millions of passwords, useful for dictionary attacks. You can find it in many sites.
  Link: rockyou.txt
  
• Test users: This is not a tool but i created some users in my windows machine as test users to try to crack their passwords. The first 3 ones are weak passwords. The last one is an strong password.

Extracting Password Hashes

The first step in cracking Windows machine passwords involves extracting the password hashes from the system. One common tool for this purpose is pwdump. This utility allows users to dump the password hashes stored in the Security Account Manager (SAM) database on a Windows system. Obviously you need to be Administrator of the machine.

To extract the password hashes using pwdump, follow these steps:

1. Download and unzip the pwdump zip file on your Windows machine.
2. Open a command prompt with administrative privileges.
3. Navigate to the directory where pwdump was unzipped.
4. Run the command "pwdump8.exe" (8 because this is the version i am using the moment i am publishing this post) to extract the password hashes.

Cracking Password Hashes

Once the password hashes have been extracted, the next step is to crack them using a password cracking tool. One of the most popular tools for this purpose is John the Ripper. This powerful tool supports various password hash formats and employs different cracking techniques, including dictionary attacks, brute force attacks, and hybrid attacks.

Run John the Ripper with the appropriate options and specify the path to the password hash file. Use the "rockyou" wordlist for more comprehensive cracking.

Check the path and the options in the example:

• The executable "john.exe" is under the run subfolder of the unzipped file you have downloaded
• --format-NT parameter to crack windows hashes
• --wordlist <path to rockyou.txt file> to use the wordlist
• last parameter is the hashes file we have generated in the previous step

As you can see, the passwords of user1, user2 and user3 have been cracked.
It was not possible to crack the strong password of user4.

It's important to note that the success of password cracking depends on various factors, including the strength of the passwords, the quality of the password cracking dictionary (such as "rockyou"), and the computational resources available.

Conclusion

In this blog post, we've explored the process of cracking Windows machine passwords, from extracting the password hashes using pwdump to cracking them using John the Ripper with the "rockyou" wordlist.

While password cracking can be a powerful tool for security professionals and penetration testers, it's essential to use these techniques responsibly and ethically. Additionally, organizations and individuals should prioritize strong password practices to mitigate the risk of password compromise.

Understanding the iRule

The iRule provided captures HTTP request and response headers and logs them for analysis. Let's break down its structure:

when HTTP_REQUEST {
   set LogString "Client [IP::client_addr]:[TCP::client_port] [TCP::local_port] -> [HTTP::host][HTTP::uri]"
   log local0. "#DEBUG# ============================================="
   log local0. "#DEBUG# $LogString (request)"
   foreach aHeader [HTTP::header names] {
      log local0. "#DEBUG# $aHeader: [HTTP::header value $aHeader]"
   }
   log local0. "#DEBUG# ============================================="
}
when HTTP_RESPONSE {
   log local0. "#DEBUG# "
   log local0. "#DEBUG# ============================================="
   log local0. "#DEBUG# $LogString (response) - status: [HTTP::status]"
   foreach aHeader [HTTP::header names] {
      log local0. "#DEBUG# $aHeader: [HTTP::header value $aHeader]"
   }
   log local0. "#DEBUG# ============================================="   
}

• HTTP_REQUEST Block: This block is triggered whenever an HTTP request is received. It constructs a log string containing information about the client, ports, host, and URI. Then, it iterates over each HTTP header, logging its name and value.
• HTTP_RESPONSE Block: Similarly, this block is triggered upon receiving an HTTP response. It logs the same client information along with the response status and iterates over response headers for logging.

Example

This is how the result looks like:

#DEBUG#  ====================== Request Headers ============================
#DEBUG# Client xxx.xxx.xxx.xxx:60749 443 -> <URL> (request)
#DEBUG# sensorid: 4148
#DEBUG# Host: <DOMAIN>
#DEBUG# Accept: text/html,*/*
#DEBUG# User-Agent: Mozilla/5.0 (compatible; xxxxxxxxxxx; Windows)
#DEBUG# Proxy-Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#DEBUG# X-Forwarded-For: xxx.xxx.xxx.xxx
#DEBUG# X-Forwarded-Proto: https
#DEBUG# Access-Control-Allow-Credentials: true
#DEBUG# =============================================

#DEBUG#  ====================== Response Headers ============================
#DEBUG# Client xxx.xxx.xxx.xxx%1:60749 443 -> <URL> (response) - status: 200
#DEBUG# Cache-Control: no-cache, must-revalidate, no-transform, no-store
#DEBUG# X-XSS-Protection: 1; mode=block
#DEBUG# X-Frame-Options: SAMEORIGIN
#DEBUG# Referrer-Policy: no-referrer
#DEBUG# Content-Security-Policy: frame-src 'self'; frame-ancestors 'self'; object-src 'none';
#DEBUG# Date: Tue, 12 Mar 2024 15:04:19 GMT
#DEBUG# Connection: keep-alive
#DEBUG# X-Robots-Tag: none
#DEBUG# Strict-Transport-Security: max-age=31536000; includeSubDomains
#DEBUG# X-Content-Type-Options: nosniff
#DEBUG# Content-Type: text/html;charset=utf-8
#DEBUG# Content-Length: 2740
#DEBUG# =============================================

Conclusion

Custom iRules like the one we've explored here exemplify the power and flexibility of the F5 BIG-IP platform. By logging HTTP request and response headers, administrators can gain valuable visibility into traffic patterns, diagnose issues efficiently, and enhance security posture.

Do you use custom iRules in your F5 deployments? Share your experiences and insights in the comments below!

Additionally, you might find that attempting to access SmartView directly via "https://management-server/smartview" redirects you to the Gaia portal instead of opening SmartView.

Diagnosing the Cause

After some investigation, it was discovered that the root of the issue lay within the /web/conf/extra/httpd2-smartview.conf configuration file, which was found to be empty. This configuration file is crucial for enabling proper communication and functionality between the SmartConsole and the SmartView component.

Implementing the Solution

To rectify the problem, the following configuration was added to the /web/conf/extra/httpd2-smartview.conf file:

LoadModule proxy_module modules/libmod_proxy.so
LoadModule proxy_http_module modules/libmod_proxy_http.so
LoadModule proxy_wstunnel_module modules/libmod_proxy_wstunnel.so

ProxyErrorOverride On

<Location /smartview/PUSH/>
  ProxyPass ws://127.0.0.1:8082/smartview/PUSH/
  ProxyPassReverse ws://127.0.0.1:8082/smartview/PUSH/
</Location>

<Location /smartview/embedded/PUSH/>
  ProxyPass ws://127.0.0.1:8082/smartview/embedded/PUSH/
  ProxyPassReverse ws://127.0.0.1:8082/smartview/embedded/PUSH/
</Location>

<Location /smartview/editor/PUSH/>
  ProxyPass ws://127.0.0.1:8082/smartview/editor/PUSH/
  ProxyPassReverse ws://127.0.0.1:8082/smartview/editor/PUSH/
</Location>

<Location /smartview/viewer/PUSH/>
  ProxyPass ws://127.0.0.1:8082/smartview/viewer/PUSH/
  ProxyPassReverse ws://127.0.0.1:8082/smartview/viewer/PUSH/
</Location>

<Location /smartview>
  <LimitExcept HEAD POST GET>
    Require all denied
  </LimitExcept>

  ProxyPass http://127.0.0.1:8082/smartview
  ProxyPassReverse http://127.0.0.1:8082/smartview
</Location>

<Location /smartview/pdf/>
  Require all denied
</Location>

After inserting the configuration, the HTTPD2 daemon was restarted using the following commands:

To stop: tellpm process:httpd2
To start: tellpm process:httpd2 t


Fixed

Following these steps, the SmartConsole should now be able to load SmartView without encountering any further issues. The added configuration ensures proper proxying and routing of requests to the SmartView component, resolving the loading problem and allowing users to seamlessly access SmartView functionalities.

VMWare commands

Listing VMs

This command provides a list of VMs along with their IDs, making it easy to identify the VMs we want to manage.
vim-cmd vmsvc/getallvms

Getting Power State

This command returns whether the VM is powered on, off, suspended, etc., allowing us to determine its current state before taking further action.
vim-cmd vmsvc/power.getstate VMID

Powering On a VM

This command initiates the boot process for the VM, allowing its guest OS to start up
vim-cmd vmsvc/power.on VMID

Shutting Down a VM

This command sends a shutdown signal to the VM, allowing its guest OS to perform a clean shutdown before the VM powers off.
vim-cmd vmsvc/power.shutdown VMID

Powering Off a VM

This command immediately powers off the VM without waiting for its guest OS to shut down
vim-cmd vmsvc/power.off VMID.

Script to simplify powering on/off VMs

I've created a simple but handy bash script called vms-power-state.sh that simplifies VM management via the command line.

Download

You can download it in Github

Overview

The script offers several commands to interact with VMs:

• vms-power-state.sh Prints help text, providing an overview of available commands.
• vms-power-state.sh list Displays a list of VMs along with their powering states.
• vms-power-state.sh <poweron|shutdown|poweroff> <VM_NAME|ALL>:
  • poweron Powers on the specified VM or all VMs.
  • shutdown Initiates a graceful shutdown of the guest OS of the specified VM or all VMs.
  • poweroff Immediately powers off the specified VM.

Usage Examples

Let's walk through some usage examples of the script:

• Listing VMs and Powering States:
  Running vms-power-state.sh list provides a clear overview of all VMs and their current powering states, making it easy to identify which VMs are powered on or off.

• Powering On a VM:
  To power on a VM, simply run vms-power-state.sh on <VM_NAME|ALL>.

• Gracefully Shutting Down a VM:
  To initiate a graceful shutdown to perform a clean shutdown of a VM's guest OS, use vms-power-state.sh shutdown <VM_NAME|ALL>.

• Powering Off a VM:
  To power off immediately a VM, use vms-power-state.sh shutdown <VM_NAME>.

Whether you need to power on/off VMs or gracefully shut down their guest OS, this script provides a convenient way to perform these tasks directly from the command line.

You can check your site by using a site like SSL Labs (https://www.ssllabs.com/ssltest/) or SecurityHeaders (https://securityheaders.com/) to perform a comprehensive security assessment of your website that evaluates various security aspects of the SSL/TLS configuration, including the presence and correctness of HSTS headers.

For example, this is the result of checking an example site I published using F5:

As you can see, it returns an invalid HSTS header: "Required directive missing: max-age"

That header was sent by the web backend behind the F5 device.

The official article https://support.f5.com/csp/article/K04436209 shows  the way to make F5 insert the HSTS header.

when HTTP_RESPONSE_RELEASE {
	if {!([HTTP::header exists “Strict-Transport-Security”])} 
	{
		HTTP::header insert “Strict-Transport-Security” “max-age=16070400; includeSubDomains”
	}
}

But that was not valid for the scenario I came across because the F5 header was already sent by another device and without the required max-age value.

Instead of inserting, by using this irule the HSTS was correctly set...

when HTTP_RESPONSE_RELEASE {
	HTTP::header replace “Strict-Transport-Security” “max-age=16070400; includeSubDomains”
}

...as confirmed afterwards:

Recently, I encountered a puzzling issue where the Identity Awareness module integrated with Active Directory (AD) began generating persistent errors, disrupting network operations. Upon investigation, I discovered that these errors were evident in the logs, revealing a continuous stream of "Failed Login" events. Here's how I tackled the problem and restored functionality.

Identifying the Issue

The first step was to scrutinize the logs, where I found a plethora of "Failed Login" entries, indicating authentication challenges. This prompted a deeper dive into the configuration settings to pinpoint the root cause.

Troubleshooting and Solution

After meticulous investigation, I determined that several settings defined in the Account Unit required attention to rectify the issue:

1. Check Username/Password: Ensure that the credentials are accurate and up-to-date. Incorrect credentials can lead to authentication failures and subsequent errors.
2. Verify Branch Configuration: Validate that the Branch configuration under the "Object Management" tab is correctly configured. Misconfigurations here can impede communication with AD and result in authentication issues.
3. LDAPS Certificate Verification: If LDAPS (LDAP over SSL/636) is utilized, verify whether the certificate has changed. In case of certificate modifications, re-fetch the fingerprint to ensure secure communication:
   • Navigate to the Servers tab.
   • Access the servers and proceed to the Encryption tab.
   • Click "Fetch" to retrieve the updated fingerprint.
   • Repeat this process for all relevant servers.
   • After refetching all servers, install the relevant policies

Resolution and Mitigation

Upon performing the necessary steps, including the re-fetching of fingerprints and policy installations, the persistent errors were successfully resolved.

Cisco ESA / Ironport manages it using SMTP routes, where you match the receiving domains with the destination hosts:

While logical, this approach can present challenges in specific scenarios. For example, I encountered a situation where I needed to selectively route outgoing emails to different relay servers during testing or migration processes.

This would allow to gain the flexibility to direct emails to either the existing relay or the new one, depending on the sender's address/domain, providing greater control and helping to keep the flow uninterrupted. To address this challenge, I researched how routing based on the sender can be achieved on Cisco ESAs. Here is how i managed to do it:

Create dictionary

Using a dictionary allows granularity to add patterns to which the new route will be applied:

Later we will associate the dictionary to envelope sender address condition so, in this example, it would apply to:

• address -> test@mydomain.com
• domain -> @test.mydomain.ocm

Configure "fake" SMTP route

Using a fake domain name (in this example newrelay.mydomain.com), create a new smtp route.
That hostname does not need to be created, exist, or even be registered in DNS... it's a fake name.

The destination (or destinations) must be the hostname of the relay server (or servers, in case of round robin) where you are going to send emails that matches certain conditions (like the sender based one we want).

Configure outgoing content-filter

Open "Outgoing Content-Filters" section and create a new one:

Name

As you want, f.e. "CF_Route_NewRelay"

Conditions

Based on which conditions do you want to route the outgoing emails through the new relay? Here you will define it.

We can use the "Envelope sender" - "contains". But this does not offer enough flexibility. For that reason, as commented before, let's use the dictionary containing the patterns that, in case of matching the sender, will cause the CF to be applied.

Actions

This is what causes the magic to happen. Set the "Send to Alternate Destination Host" action pointing to the fake name we have used in a previous step:

This will cause to match the SMTP route with that domain name and use the relay configured in that entry.

The rule would be as follows:

Enable CF on the outgoing policies

Access "Outgoing Policies" section and edit the policies in which you want to apply the content-filter.

In the list of CFs of the policy, check the newly created one to enable it:

Apply and Commit changes

Apply and commit the changes and verify that it's working.

In the realm of web servers, one crucial aspect of server security is minimizing the amount of information disclosed about the web server software powering your site. This practice, known as "server header hardening" or "server banner suppression" can significantly bolster your server's defenses against potential threats.

For example, let's take a look at this received headers...

$ curl --head testsite.com
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Thu, 08 Mar 2023 08:56:35 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 12920
Connection: keep-alive
X-Powered-By: Express
Cache-Control: public, max-age=0

Sensitive information that we obtain:

• Web server is an Nginx version 1.18.0
• It's publishing a site developed using ExpressJS

Let's delve into how you can hide this information in Debian using Nginx.

Installing additional modules

For those looking to customize server headers without the bulk of the nginx-extras package, consider installing the libnginx-mod-http-headers-more-filter module:

sudo apt-get install libnginx-mod-http-headers-more-filter

This lightweight module empowers you to manipulate HTTP headers within Nginx configurations, providing flexibility while keeping resource usage low.

Reducing Information Disclosure

In your nginx.conf file (typically located in /etc/nginx/), locate the http block. Here, you'll make modifications to minimize information disclosure. Uncomment the server_tokens off; directive if present. This directive disables the version number from being displayed in server responses, a critical step in reducing the attack surface:

http { 
	# Other configurations... 

	server_tokens off; 

	# Other configurations... 
}

Customizing Server Headers

With the libnginx-mod-http-headers-more-filter module installed, you can customize the server header to obscure specific details. Add the following line within the http block to replace the default server header with a custom one, such as "SomoIT webserver":

more_set_headers 'Server: My own webserver';

Hide the sites X-Powered-By

To remove the "X-Powered-By" header in Nginx, you can use the proxy_hide_header directive in your Nginx configuration.
Probably you would have to configure it at site level in any of the config files located in /etc/nginx/sites-available/:

server { 
	# Other server configurations... 
    
    location / { 
    	# Other location directives... 
        proxy_hide_header X-Powered-By; 
	} 
    
    # Other server blocks and configurations... 
}

Restarting Nginx

After making these crucial adjustments, save the nginx.conf file and restart the Nginx service to apply the new configuration:

sudo systemctl restart nginx

Checking the result

Let's repeat the curl command to obtain the headers and check...

$ curl --head testsite.com
HTTP/1.1 200 OK
Server: My own webserver
Date: Thu, 08 Mar 2023 09:12:11 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 12920
Connection: keep-alive
Cache-Control: public, max-age=0

• Server header value now is "My own webserver"
• No X-Powered-By header is shown

Conclusion

Minimizing information disclosure one aspect of a comprehensive security strategy. It does not only reduces the attack surface but also contributes to user privacy.