Restrict SSH Users to Run Limited Commands

This is the note to focus on how to restrict SSH users from executing certain commands once they successfully log in to a remote OpenSSH server.

Setup key-based authentication

$ key-keygen

$ ssh-copy-id login@remote-ssh-server

On the remote SSH server, a file called 'authorized_keys' should be created at ~/.ssh. We should see the copied public key.

$ ssh login@remote-ssh-server

$ cd ~/.ssh

$ cat authorized_keys

 

Restrict Execution in 'authorized_keys' file

To restrict a user to execute the 'ls' command on this server, we can modify the authorized_keys file in the following manner:

from="192.168.233.84",command="/usr/bin/ls" ssh-rsa AAAABBB.......

The entry above will point to the IP address and specified the only command to be executed.

Once we login to the remote SSH server, the ls command will execute and the connection will be closed.

We can create a BASH script and restrict the execution to the BASH script which provide limited command only.

Links:

• https://www.linuxshelltips.com/restrict-ssh-user-commands/
  

Understanding and Getting Started with ZERO TRUST

 

A look at what Zero Trust really is and how to get started by John.

My take away (ZT principles):

• Verify explicitly (on every single session or resources)
  
• Least privilege (just enough and in time) 
• Assume breach

Other notes: 

• A wrong VPN deployment may degrade the security in overall.
• IAM with SSO (MFA, Passwordless, disable legacy auth, RBAC)
• Endpoints (TPM, TLS cert, register-managed-compliant)
• Network (defense-in-depth, end-to-end encryption/IPSec, layers/tiers - microsegmentation, IDS/IPS) 
• Risk Context and controls (Identity, endpoint, network, conditional access)
• Infra and apps (policy, shadow IT, proxy)
• data (data driven protection and travel with data, encryption, classification, Azure Purview)
• SIEM/SOAR (Azure Sentinel + ML + automation)

 

Links:

• https://www.youtube.com/watch?v=hhS8VdGnfOU
• MS Zero Trust Maturity Model
• https://github.com/johnthebrit/CertificationMaterials 
  

EPSS for Better Vulnerability Management OSINT Strategy

EPSS is a measure of exploitability. Specifically, EPSS is estimating the probability of observing any exploitation attempts against a vulnerability in the next 30 days. 

This is accomplished by observing and recording exploitation attempts against vulnerabilities and then collecting as much information about each vulnerabilities. 

EPSS is best used when there is no other evidence of active exploitation. When evidence or other intelligence is available about exploitation activity, that should supersede the EPSS estimate.

EPSS does not account for any specific environmental, or compensating controls, and it does make any attempt to estimate the impact of a vulnerability being exploited. EPSS should not be treated as a complete picture of risk, but it can be used as one of the inputs into risk analyses.

In vulnerability management, EPSS is treated as "pre-threat intel." If an organization have any intel source which something is being exploited (via their own telemetry sensors or OSINT), then they should use that as an indication of activity in the wild. For those without any evidence of exploitation or that lack threat intel, then EPSS is a great fit.

Thus, EPSS can be used for better Vulnerability Management's OSINT strategy and prioritization.

Links:

• https://www.first.org/epss/user-guide
• https://www.first.org/epss/articles/prob_percentile_bins
• https://www.first.org/epss/data_stats
• https://www.first.org/epss/model
• https://www.fortinet.com/blog/threat-research/predict-threats-and-secure-networks-with-epss
  

Creating Disk Image and MBR

Creating disk image or just MBR (master boot record) in Linux is common for backups, copying disks, and recovery. And the 'dd' command is an easy to use tool for making such clones.

To clone an entire hard disk:

# dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

The cmdline above set the block size to 64k (can be 128k or other value), and continue operation and ignoring all read errors. It also add input blocks with zeroes if there were any read errors, so data offsets stay in sync. Both hard disks (sda and sdb) must be the same size.

To clone a partition and make a disk image:

dd if=/dev/sdb1 of=disk_sdb1.img bs=128K conv=noerror,sync

dd if=/dev/sdb1 conv=sync,noerror bs=128K | gzip -c > disk_sdb1.img.gz

dd if=/dev/sdb1 conv=sync,noerror bs=128K status=progress | gzip -c | ssh xx@remote.ip dd of=disk_sdb1.img.gz

 

To restore system:

# gunzip -c disk_sdb1.img.gz | dd of=/dev/sdb1

To copy MBR:

# dd if=/dev/sda of=/dev/sdb bs=512 count=1

The cmdline above will copy 512 bytes (MBR) from sda to sdb disk. This only work if both disks are identically sized partitions.

# dd if=/dev/sda of=/tmp/mbrsda.bak bs=512 count=1

The cmdline above will copy 512 bytes (MBR) from sda to a disk image for 2 disks with different size partitions.

To restore the MBR to any sdb:

# dd if=/tmp/mrbsda.bak of=/dev/sdb bs=446 count=1

Master Boot Record (MBR) is the 512-byte boot sector that is the first sector of a partitioned data storage device of a hard disk.  MBR is divided into 3 sections:
1. Bootstrap - 446 bytes
2. Partition table - 64 bytes
3. Signature - 2 bytes

For restore MBR, use 446 bytes to overwrite/restore your /dev/sda MBR boot code only, and use 512 bytes to overwrite/restore your /dev/sda full MBR.

To backup and restore the primary and extended partition tables:

# sfdisk -d /dev/sda > /tmp/sda.bak

# sfdisk /dev/sda < /tmp/sda.bak

 

To backup MBR and Extended Partitions schema:

# dd if=/dev/sda of=/tmp/backup-sda.mbr bs=512 count=1

# sfdisk -d /dev/sda > /tmp/backup-sda.sfdisk

 

To restore MBR and Extended Partition schema:

# dd if=/tmp/backup-sda.mbr of=/dev/sda

# sfdisk /dev/sda < /tmp/backup-sda.sfdisk

 

Links:

• https://www.cyberciti.biz/faq/unix-linux-dd-create-make-disk-image-commands/
• https://www.cyberciti.biz/faq/howto-copy-mbr/
  

GHA Runners - Security In Action

An excellent write up, from Magno Logan, about the GitHub Actions (GHA), one of the commonly used CI tools today.

This article covers some security risks and best practices about using GHA as your primary CI tool.

About GitHub Actions (GHA)

GitHub Actions released in 2019. Working as CI tools, tt helps developers automate tasks within the software development life cycle (SDLC). One advantage of GHA is that developers do not need a separate CI tool but executes the workflow directly from GitHub. 

Actions are formed by a set of components. These are the six main components of a GHA:

• Workflows: Automated procedure added to the repository, and is the actual Action itself
• Events: An activity that triggers a workflow; these can be based on events such as push or pull requests, but they can also be scheduled using the crontab syntax
• Jobs: A group of one or more steps that are executed inside a runner
• Steps: These are tasks from a job that can be used to run commands
• Actions: The standalone commands from the steps
• Runners: A server that has the GHA runner application installed

 

The full article contains many more information including:

1. GitHub Actions (GHA) and its components
2. GitHub Action (GHA) runners
3. Cryptomining with GitHub Actions
4. Ubuntu Runner reconnaissance
5. Scanning for vulnerabilities
6. Setting up a reverse shell with Netcat and more
7. The Mono Web Server XSP
8. Scanning other runners
9. Conclusions and recommendations
10. Trend Micro solutions
    

GitHub Action Runners

Links:

• GitHub Action Runners - Analyzing the Environment and Security in Action