AWS – Processor Speculative Execution Research Disclosure News About Concerning: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754

We Talked about Meltdown and Spectre on this article.

Here what AWS – Amazon says:

Update As Of: 2018/01/07 11:30 PST

This is an update for this issue.

Amazon EC2

All instances across the Amazon EC2 fleet are protected from all known threat vectors from the CVEs previously listed. Customers’ instances are protected against these threats from other instances. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads.

Recommended Customer Actions for AWS Batch, Amazon EC2, Amazon Elastic Beanstalk, Amazon Elastic Container Service, Amazon Elastic MapReduce, and Amazon Lightsail

While all customer instances are protected, we recommend that customers patch their instance operating systems. This will strengthen the protections that these operating systems provide to isolate software running within the same instance. For more details, refer to specific vendor guidance on patch availability and deployment.

Specific vendor guidance:

For operating systems not listed, customers should consult with their operating system or AMI vendor for updates and instructions.

Updates to other AWS services

Amazon Linux AMI (Bulletin ID: ALAS-2018-939)

An updated kernel for Amazon Linux is available within the Amazon Linux repositories. EC2 instances launched with the default Amazon Linux configuration on or after 10:45 PM (GMT) January 3rd, 2018 will automatically include the updated package. Customers with existing Amazon Linux AMI instances should run the following command to ensure they receive the updated package:

sudo yum update kernel

After the yum update is complete, a reboot is required for updates to take effect.

More information on this bulletin is available at the Amazon Linux AMI Security Center.

EC2 Windows

We have updated AWS Windows AMIs. These are now available for customers to use, and AWS Windows AMIs have the necessary patch installed and registry keys enabled.

Microsoft have provided Windows patches for Server 2008R2, 2012R2 and 2016. Patches are available through the built-in Windows Update Service for Server 2016. We are pending information from Microsoft on patch availability for Server 2003, 2008SP2 and 2012RTM.

AWS customers running Windows instances on EC2 that have “Automatic Updates” enabled should run automatic updates to download and install the necessary update for Windows when it is available.

Please note, Server 2008R2 and 2012R2 patches are currently unavailable through Windows Update requiring manual download, Microsoft advise these patches will be available Tuesday, January 9th.

AWS customers running Windows instances on EC2 that do not have “Automatic Updates” enabled should manually install the necessary update when it is available by following the instructions here: http://windows.microsoft.com/en-us/windows7/install-windows-updates.

Please note, for Windows Server, additional steps are required by Microsoft to enable their update’s protective features for this issue, described here: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution.

ECS Optimized AMI

We have released Amazon ECS Optimized AMI version 2017.09.e which incorporates all Amazon Linux protections for this issue. We advise all Amazon ECS customers to upgrade to this latest version which is available in the AWS Marketplace. Customers that choose to update existing instances in-place should run the following command on each container instance:

sudo yum update kernel

The update requires a reboot of the container instance to complete

Linux customers who do not use the ECS Optimized AMI are advised to consult with the vendor of any alternative / third-party operating system, software, or AMI for updates and instructions as needed. Instructions about Amazon Linux are available in the Amazon Linux AMI Security Center.

An updated Microsoft Windows EC2 and ECS Optimized AMI will be released as Microsoft patches become available.

Elastic Beanstalk

We will be releasing new platform versions that include the kernel update to address this issue within 48 hours. For Linux environments, we recommend that you enable “Managed Platform Updates” to automatically update within your chosen maintenance window once these updates are available. We will post instructions for Windows environments once the update is available.

AWS Fargate

All infrastructure running Fargate tasks has been patched as described above and no customer action is required.

Amazon FreeRTOS

There are no updates required for or applicable to Amazon FreeRTOS and its supported ARM processors.

AWS Lambda

All instances running Lambda functions have been patched as described above and no customer action is required.

RDS

RDS-managed customer database instances are each dedicated to only running a database engine for a single customer, with no other customer-accessible processes and no ability for customers to run code on the underlying instance. As AWS has finished protecting all infrastructure underlying RDS, process-to-kernel or process-to-process concerns of this issue do not present a risk to customers. Most database engines RDS supports have reported no known intra-process concerns at this time. Additional database engine-specific details are below, and unless otherwise noted, there is no customer action required. We will update this bulletin as more information is available.

RDS for MariaDB, RDS for MySQL, Aurora MySQL, and RDS for Oracle database instances currently have no customer actions required.

For RDS PostgreSQL and Aurora PostgreSQL, DB Instances running in the default configuration currently have no customer actions required. We will provide the appropriate patches for users of plv8 extensions once they are made available. In the meantime, customers who have enabled plv8 extensions (disabled by default) should consider disabling them and review V8’s guidance at https://github.com/v8/v8/wiki/Untrusted-code-mitigations.

For RDS for SQL Server Database Instances, we will release OS and database engine patches as Microsoft makes each available, allowing customers to upgrade at a time of their choosing. We will update this bulletin when either has been completed. In the meantime, customers who have enabled CLR (disabled by default) should review Microsoft’s guidance on disabling the CLR extension at https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server.

VMware Cloud on AWS

Please refer to the VMware security advisory here for more details: https://www.vmware.com/security/advisories/VMSA-2018-0002.html.

WorkSpaces

AWS will apply security updates released by Microsoft to most AWS WorkSpaces over the coming weekend. Customers should expect their WorkSpaces to reboot during this period.

Bring Your Own License (BYOL) customers, and customers who have changed the default update setting in their WorkSpaces should manually apply the security updates provided by Microsoft.

Please follow the instructions provided by Microsoft security advisory at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002. The security advisory includes links to knowledge base articles for both Windows Server and Client operating systems that provide further specific information.

Updated WorkSpaces bundles will be available with the security updates soon. Customers who have created Custom Bundles should update their bundles to include the security updates themselves. Any new WorkSpaces launched from bundles that do not have the updates will receive patches soon after launch, unless customers have changed the default update setting in their WorkSpaces, in which case they should follow the above steps to manually apply the security updates provided by Microsoft.

WorkSpaces Application Manager (WAM)

We recommend that customers choose one of the following courses of action:

Option 1: Manually apply the Microsoft patches on running instances of WAM Packager and Validator by following the steps provided by Microsoft at https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. This page provides further instructions and downloads for Windows Server.

Option 2: Rebuild new WAM Packager and Validator EC2 instances from updated AMIs for WAM Packager and Validator which will be available by end of day (2018/01/04).

=========================================================

2018/01/03 14:45 PST

AWS is aware of recently disclosed research regarding side-channel analysis of speculative execution on modern computer processors (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754). These are vulnerabilities that have existed for more than 20 years in modern processor architectures like Intel, AMD, and ARM across servers, desktops, and mobile devices.

List for troubleshooting Process and threads on Linux

To the get the sum of all threads running in the system:

ps -eo nlwp | tail -n +2 | awk '{ num_threads += $1 } END { print num_threads }'

To get the number of threads for a given pid:

ps -o nlwp <pid>

Locate a Process

top

or

ps

To display all process names, use the following command –

$ ps -e

List the process associated with  a service/program

ps aux | grep my_service /  PID

To Kill a Process

kill PID

To see the thread count of process, use the following command-

$ cat /proc/<pid>/status

Configure IPTABLES to Allow Access to Common Services This article gives the steps to open firewall ports on CentOS in Iptables IPv4

Basics

  • Iptables rules can be changed on the fly by using the iptables binary.
  • The rules that are set using iptables command are in memory only and will vanish when the daemon is restarted.
  • The firewall rules added on the fly can be saved to the configuration file easily in CentOS/RHEL with the command service iptables save
    • This is no need to edit the configuration file unless you really want to.
  • The following examples are aimed at hardening the inbound traffic, but allowing all outbound traffic.
    • You can completely lock down all inbound, outbound and forwarded traffic if needed. It generally just causes a lot more administration and usually isn’t necessary.

Basic Commands

iptables –flush delete all firewall rules from memory.
iptables –list List current firewall policies
service iptables save (CentOS/RHEL) save current rules in memory to configuration file (/etc/sysconfig/iptables)
service iptables restart restart iptables daemon and load firewall rules from configuration file.
iptables-save > /root/firwallrules.fw save firewall rules in memory to a specific configuration file.
iptables-restore > /root/firwallrules.fw restore firewall rules from a specific configuration file to memory.

Basic iptables Command Parameters

  • -A append to policy chain
  • INPUT | OUTPUT | FORWARD policy chain identifiers
  • -p protocol
  • -m match
  • -s source
  • –dport destination port
  • –state connection state
  • -j jump target ACCEPT | DROP

Backup Current Iptables Configuration to File

Before you begin, it is recommended to backup your current firewall rules.

iptables-save > /path/to/somewhere/filename

Example:

iptables-save > /home/user1/iptable-rules-20130308.fw

Remove All Current Rules

iptables --flush

Set Policy Chains Default Rule

iptables -P INPUT DROP
 iptables -P OUTPUT ACCEPT
 iptables -P FORWARD ACCEPT

Allow Loopback

iptables -A INPUT -i lo -j ACCEPT

Allow All Established and Related Connections

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Allow ICMP “ping” from LAN (TCP Port 22)

iptables -A INPUT -p icmp -m icmp -s 192.168.0.0/24 --icmp-type echo-request -j ACCEPT

Allow SSH from LAN (TCP Port 22)

iptables -A INPUT -p tcp -m tcp -s 192.168.0.0/24 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

Allow RSYNC from LAN (TCP Port 873)

iptables -A INPUT -p tcp -m tcp -s 192.168.0.0/24 --dport 873 -m state --state NEW,ESTABLISHED -j ACCEPT

Allow HTTP (TCP Port 80)

iptables -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

Allow HTTPS (TCP Port 443)

iptables -A INPUT -p tcp -m tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

Allow MySQL Server Access from LAN (TCP Port 3306)

iptables -A INPUT -p tcp -m tcp -s 192.168.0.0/24 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT

Allow Nagios NRPE Client Access from Nagios Server (TCP Port 5666)

iptables -A INPUT -s 192.168.0.100 -p tcp -m tcp --dport 5666 -m state --state NEW,ESTABLISHED -j ACCEPT

Save Current Rules in Memory to Configuration File

service iptables save

Restart Service

service iptables restart

iptables: insert a rule at a specific line number

# list the rules with line numbers

iptables -nL --line-numbers

# insert a rule at line 5

iptables -I INPUT 5 -p tcp -m state --state NEW -m tcp --dport 4000 -j ACCEPT

Related Articles: Configure iptablesiptables: insert a rule at a specific line number

Give Linux read-only permission for specific user and folder A small HOW-TO create a user then give to that user a read-only permissions with ACL

In this article we will show you how to create a user, then give to that new user a read-only permissions (for example if you need a log viewer user)

  1. create user
    #useradd username
  2. give to that user a password
    #passwd username
  3. use ‘setfacl’ to give the permission
    #setfacl -R -m u:username:r-x /dir/sub_dir1/.../

setfacl syntax

setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] file ...

Description of SETFACL

The setfacl utility sets Access Control Lists (ACLs) of files and directories. On the command line, a sequence of commands is followed by a sequence of files (which in turn can be followed by another sequence of commands, and so on).

The options -m and -x expect an ACL on the command line. Multiple ACL entries are separated by commas (“,”). The options -M and -X read an ACL from a file or from standard input. The ACL entry format is described in the ACL Entries section, below.

The –set and –set-file options set the ACL of a file or a directory. The previous ACL is replaced. ACL entries for this operation must include permissions.

The -m (–modify) and -M (–modify-file) options modify the ACL of a file or directory. ACL entries for this operation must include permissions.

The -x (–remove) and -X (–remove-file) options remove ACL entries. It is not an error to remove an entry which does not exist. Only ACL entries without the perms field are accepted as parameters, unless the POSIXLY_CORRECT environment variable is defined.

When reading from files using the -M and -X options, setfacl accepts the output produced by getfacl. There is at most one ACL entry per line. After a pound sign (“#”), everything up to the end of the line is treated as a comment.

If setfacl is used on a file system which does not support ACLs, setfacl operates on the file mode permission bits. If the ACL does not fit completely in the permission bits, setfacl modifies the file mode permission bits to reflect the ACL as closely as possible, writes an error message to standard error, and returns with an exit status greater than 0.

Options
-b, –remove-all Remove all extended ACL entries. The base ACL entries of the owner, group and others are retained.
-k, –remove-default Remove the Default ACL. If no Default ACL exists, no warnings are issued.
-n, –no-mask Do not recalculate the effective rights mask. The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given. The mask entry is set to the union of all permissions of the owning group, and all named user and group entries. (These are exactly the entries affected by the mask entry).
–mask Do recalculate the effective rights mask, even if an ACL mask entry was explicitly given. (See the -n option.)
-d, –default All operations apply to the Default ACL. Regular ACL entries in the input set are promoted to Default ACL entries. Default ACL entries in the input set are discarded. (A warning is issued if that happens).
–restore=file Restore a permission backup created by “getfacl -R” or similar. All permissions of a complete directory subtree are restored using this mechanism. If the input contains owner comments or group comments, setfacl attempts to restore the owner and owning group. If the input contains flags comments (which define the setuid, setgid, and sticky bits), setfacl sets those three bits accordingly; otherwise, it clears them. This option cannot be mixed with other options except “–test”.
–test Test mode. Instead of changing the ACLs of any files, the resulting ACLs are listed.
-R, –recursive Apply operations to all files and directories recursively. This option cannot be mixed with “–restore”.
-L, –logical “Logical walk”: follow symbolic links to directories. The default behavior is to follow symbolic link arguments, and skip symbolic links encountered in subdirectories. Only effective in combination with -R. This option cannot be mixed with “–restore”.
-P, –physical “Physical walk”: do not follow symbolic links to directories. This also skips symbolic link arguments. Only effective in combination with -R. This option cannot be mixed with “–restore”.
-v, –version Print the version of setfacl, and exit.
-h, –help Print a help message explaining the command line options.
— A double-dash marks the end of command line options; all remaining parameters are interpreted as file names. This option is especially useful for file names that start with a dash.
– If the file name parameter is a single dash, setfacl reads a list of files from standard input.

ACL Entries
setfacl recognizes the following ACL entry formats (spaces in the following formats are optional, but have been included for legibility):

[d[efault]:] [u[ser]:]uid [:perms] Permissions of the user with user ID uid, or permissions of the file’s owner if uid is empty.
[d[efault]:] g[roup]:gid [:perms] Permissions of the group with group ID gid, or permissions of the owning group if gid is empty.
[d[efault]:] m[ask][:] [:perms] Effective rights mask.
[d[efault]:] o[ther][:] [:perms] Permissions of others.
Whitespace between delimiter characters and non-delimiter characters is ignored.

Proper ACL entries including permissions are used in modify and set operations (options -m, -M, –set and –set-file). Entries without the perms field are used for deletion of entries (options -x and -X).

For uid and gid you can specify either a name or a number.

The perms field is a combination of characters that indicate the permissions: read (“r”), write (“w”), execute (“x”), or “execute only if the file is a directory or already has execute permission for some user” (capital “X”). Alternatively, the perms field can be an octal digit (“0”-“7”).

Related Articles: Linux setfacl command | Setting filesystem ACL

How to recover GRUB and Root password on VCSA This article will provide the step by step screenshot to recover the VMware vCenter Appliance

This article will provide the step by step screenshot to recover the VCSA (5.5 and 6.0 tested) root password and breaking the GRUB password.

VMware vCenter Appliance(VCSA) is a pre-configured Linux VM based on SUSE Linux.
If you forget the root password of the appliance, you need to recover the root password like other Linux Operating systems.
Recovering root password is very simple if there is no grub password has been setup or if you know the GRUB boot loader password. If you don’t know the grub password, then you need to reset the grub password first by using Redhat or SUSE Linux DVD or live cd such Hiren’s Boot CD.

RECOVER GRUB PASSWORD

If you deployed a VCSA changing grub password, and you lost it, you can remove it following this steps. Default grub passsword for VCSA is ‘vmware‘:

  1. Power OFF VCSA Server (it culd be a Physical server or VM);
  2. Insert a Live Boot CD linux for recover (Live Linux, Hiren’s Boot etc..);
  3. Power ON the Server, then Boot from CD;
  4. Start Recovery procedure from CD;
  5. Mount VCSA file system on a mount point like ‘/mnt/vcsa‘, in RW mode: ‘mount -o remount,rw /partition/identifier /mount/point‘;
  6. Navigate into /mount/point/boot/grub;
  7. List file into grub and find ‘menu.lst‘;
  8. Ensure to backup menu.lst: ‘cp menu.lst menu.lst.bck‘;
  9. Edit menu.lst with Vim editor or similar, then remove or place # to comment the ‘Password’ row:Recover Grub Password, commented ‘password’
  10. Exit VIM saving;
  11. Reboot Server.

RECOVER ROOT PASSWORD

  1. Start the VCSA Server (or VM) and interrupt the GRUB menu by pressing “ESC” key .  Press “e” edit the commands;If you know the GRUB password , you can pass it by press “p” and enter the GRUB password. If you don’t know the GRUB password , you need to follow the above procedure to break the grub password first.

    Recover Root Password Linux
    Recover Root Password Linux
  2. Press “e” to edit the commands again for the kernel;
  3. Append “init=/bin/bash” in this step and press enter;
  4. Press “b” to boot the system;
  5. You will get the bash;
  6. Set the new root password for VCSA ‘passwd root’;
  7. Exit the shell using “exit” command.

Once the system is booted , you should be able to login with new root password.

Related article: