Here’s What’s New in VMware vSphere and vCenter 6.7 You can expect some incremental changes to VMware hypervisor (ESXi) and management (vCenter Server)

Widenet is VCP Certified for VMware Products.
In many Article, we talked about Tips & tricks, or to solve problems, like here, or here. Now we will talking about a big news from VMware.

vSphere 6.7, released today, includes an update to both its hypervisor (ESXi 6.7) and management console (vCenter Server 6.7). This release shows that VMware Inc. is not content to let its hypervisor become a commodity, and that it’s possible to make incremental, evolutionary changes to a proven product and, moreover, that VMware is still making substantial investments in its hypervisor. The vSphere 6.7 beta, though NDA-constrained, has been available to the public since October 2017. Despite the fact that a lot of new features were baked into the 6.5 release, this release does make some nice incremental changes. Following are some of the most important changes included with vSphere 6.7.

Hardware Caveat
An important hardware caveat to be aware of is VMware has released an HCL for vSphere 6.7 that excludes some older, yet popular CPUs. If you’re thinking about running this release on an older system for development or testing first before placing it into production on your newer servers, make sure to check the HCL to ensure compatibility.

Single Reboot Upgrade
vSphere upgrades can now be completed with one single reboot. Prior to vSphere 6.7, major version upgrades took quite a while (although they could be done without disruption by transferring workloads by using the Distributed Resource Scheduler [DRS]). vSphere 6.7, on the other hand, allows you to do a “quick boot” where it loads vSphere ESXi without restarting the hardware because it only restarts the kernel. This feature is only available with platforms and drivers that are on the Quick Boot whitelist, which is currently quite limited.

VMware Configuration Maximum Tool
The most visible configuration maximum change in vSphere 6.7 is the number of devices that can be attached to a host. VMware has increased some of the other maximums.

vSphere Client
vSphere 6.5 eliminated the vSphere Client that ran natively on Windows (also known as the C# Client or Thin Client) in favor of the vSphere Web Client, which was Flash-based. Also introduced in version 6.5 was the vSphere Client, which replaced Flash with HTML5. vSphere 6.7 further extends the capabilities of the vSphere Client and will eventually replace the vSphere Web Client. It looks like the vSphere Client can do about 90 percent that the vSphere Web Client can do. In vSphere 6.5, VMware had a list of the functionalities not yet supported in the vSphere Client; hopefully the company will do the same for vSphere 6.7.
Figure 1 shows the main menu of the vSphere Web Client, and Figure 2 shows the main vSphere Client menu. Although the new client looks cleaner, and does seem more responsive than the vSphere Web Client, the location of some items has changed and some workflows will have to be adjusted accordingly with these changes. I wrote an article on the vSphere Client when it first came out that explains why VMware is switching to an HTML5-based client.

[Click on image for larger view.]Figure 1. 
The vSphere Web Client main menu.
[Click on image for larger view.]Figure 2.

vCenter Server Appliance

Now that the vCenter Server Appliance (VCSA) is functionally equivalent to the Windows-based vCenter Server, it would take a lot to convince me to use the Windows-based one instead of VCSA. Overall, I have found that the VCSA embedded database (PostgreSQL) performs great. Furthermore, the VCSA is very easy to update, and the Linux OS (Photon OS) is rock solid. As a side note, the VCSA can easily be monitored using vimtop (be sure to read my recent articles on using vimtop). You can also read my article about migrating from a Windows-based vCenter Server to a VCSA, as well as another article on using the built-in VCSA backup tool. The built-in backup tool in vSphere 6.7 offers more scheduling options for its VCSA backup tool than in vSphere 6.5. The Backup Scheduler tool (Figure 3) can be accessed from the vCenter Server Appliance Management Interface (VAMI). VMware is also stating that there are “phenomenal” performance improvements in vCenter operations per second, in reduction of memory usage and DRS-related operations.

[Click on image for larger view.]Figure 3. 
The Backup Scheduler tool.

Suspend and Resume of vGPU Workloads
vGPU allows you to carve up a physical GPU into multiple virtual GPUs that can be used by VMs. Although vGPUs were introduced with vSphere 6.0, the VMs that used vGPUs there were limited in what you could do with a VM that was using a vGPU. vSphere 6.7, on the other hand, removes some of these barriers, and now you can suspend and resume a vGPU-enabled VM.

Per-VM EVC
For quite some time vSphere has had the ability to mask off CPU features so that VMs that were running on systems with newer CPUs could be vMotion to servers with older CPUs. This is called Enhanced vMotion Compatibility, or EVC. In vSphere 6.7 VMware has extended this capability to allow you to do this on a per-VM, rather than on an ESXi-host basis. This means that if you have VMs that you want to take advantage of CPU-specific features, and are willing to limit those VMs to CPUs that only have those features in your cluster, you can configure them to do so.

A per-VM EVC is set from the vSphere client by selecting a VM, going to the Configure tab and selecting Edit (Figure 4).

[Click on image for larger view.]Figure 4. Setting up a per-VM EVC.

 

Instant Clone
I’ve been a fan of using instant clones with virtual desktops—they’ve proven to be a big space saver, to use only a fraction of the disk resources compared to a full clone, and to allow VMs to be provisioned in seconds from a parent image. With vSphere 6.7, VMware has exposed the APIs that can be used to create instant clones. It looks like a straightforward process and I suspect that many people will figure out some very interesting ways to use the instant clone API.

ESXi Quick Boot
vSphere 6.7 introduces the Quick Boot feature, which allows a system to reboot in less than two minutes as it does not re-initialize the physical server BIOS. This can speed up operations that require an ESXi system to be rebooted; however, Quick Boot is only supported on certain systems and does not work with systems that have ESXi Secure Boot enabled.

Figure 5 shows two hosts, one with Quick Boot enabled and another without it enabled. By default, Quick Boot is enabled if the system supports it.

[Click on image for larger view.]Figure 5. 
The New ESXi Quick Boot feature is enabled by default if the system supports it.

Persistent Memory (PMem) Devices
vSphere 6.7 now supports the next generation of storage devices that use persistent DRAM memory, known as non-volatile dual in-line memory module (NVDIMM) devices. This technology is still in its infancy, but applications that require the lowest possible latency regardless of the cost will find this feature invaluable. PMem is presented to vSphere as either as vPMemDisk, which is treated somewhat like a datastore, or as a virtual NVDIMM (vNVDIMM), which is presented directly to guest OSes that can use NVDIMM devices.

Virtual Hardware Version 14
Virtual hardware is the abstract version of physical hardware to a virtual machine or, in essence, a virtual motherboard. As physical hardware supports more features, VMware builds new virtual hardware accordingly to emulate the physical version. vSphere 6.7 comes with a new virtual hardware, version 14. Version 14 adds support for NVDIMM, as well as Trusted Platform Module (TPM), Microsoft Virtual-based Security (VBS) and I/O Memory Management.

VMFS Datastores
VMFS3 datastores have been around for a long time, but VMware is now phasing them out. To assist with this transition, vSphere 6.7 automatically upgrades VMFS3 datastores to VMFS5 when they’re mounted. If you want to upgrade VMFS5 datastores to VMFS6 datastores, you’ll need to upgrade the datastore with vSphere Storage vMotion because an in-place upgrade of a VMFS5 to VMFS6 datastore isn’t possible.

As a side note, vSphere 6.7 supports VMFS5 and VMFS6; however, vSphere 6.0 and earlier systems only support VMFS5 datastores. As such, if you have an environment that contains vSphere 6.0 or earlier systems, you’ll want to only use VMFS6 datastores on systems that won’t be accessed by them.

Upgrading to vCenter Server 6.7
A specific order must be used when upgrading to vSphere 6.7. Check the documentation for the latest order and caveats, but the basic procedure can be carried out by first upgrading the Platform Service Controller (PSC), then upgrading vCenter Server and, last, updating the ESXi hosts.

Because upgrading directly from vSphere 5.5 to 6.7 isn’t supported, you’ll need to first upgrade from vSphere 5.5 to vSphere 6.5, and then finally to vSphere 6.7. It needs to be noted that an ESXi 5.5 host cannot be managed by VCSA 6.7. On the contrary, upgrading from vSphere 6.0 to 6.7 is supported. If you’re still running a window-based vCenter Server rather than a VCSA, VMware does offer a tool to assist you in the migration; be sure to read my article on using this tool.

Upgrading to ESXi 6.7
As mentioned earlier, ESXi 6.5 doesn’t support all the CPUs that ESXi 6.0 does, so be sure to check the HCL to unsure that your system is supported. Roughly speaking, what you’ll typically find supported, at the minimum, is a 2 core CPUs that were released after September 2006 and have NX/XD enabled. You can use the VMware Update Manager (VUM) to do an orchestrated automated upgrade. Alternatively, you can manually update the ESXi systems using an ISO image or esxcli commands or, if you use stateless host, you can use vSphere Auto-Deploy to update your servers. To see how to update an ESXi system using esxcli commands, be sure to read my article.

Wrapping Up
If I’m forced to pick one single standout feature in vSphere 6.7, it would have to be the instant clone API. I see this feature as a great enabler for the VMware ecosystem and VMware developers because the ability to spawn hundreds of identical VMs that only use a small amount of space in minutes has some mind-boggling use cases. However, with great power comes greater responsibility, and it will be interesting to watch the development of tools to manage and orchestrate these VMs over time.

Yes, instant clones is the gee-wiz feature in this release, but the rest of the improvements in this release prove that the hypervisor has room for evolutionary growth—and that VMware is serious in maintaining its leadership position in this regard.

Related Article: Here’s What’s New in vSphere 6.7

Intel’s CPU List affected by Meltdown and Spectre Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method

We talk about Meltdown and Spectre Here and Here.

In this article we’re reporting the Intel’s CPU list affected by Meltdown and Spectre.

Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method

 

Intel ID: INTEL-SA-00088
Product family: Systems with Speculative Execution
Impact of vulnerability: Information Disclosure
Severity rating: Important
Original release: Jan 03, 2018
Last revised: Jan 03, 2018
Summary:Today a team of security researchers disclosed several software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from many types of computing devices with many different vendors’ processors and operating systems.

Intel is committed to product and customer security and to responsible disclosure. We worked closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to mitigate this issue promptly and constructively.

For facts about these new exploits, and steps you can take to help protect your systems and information please visit: https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html.

Description:Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

Affected products:For non-Intel based systems please contact your system manufacturer or microprocessor vendor (AMD, ARM, Qualcomm, etc.) for updates.

The following Intel-based platforms are impacted by this issue. Intel may modify this list at a later time. Please check with your system vendor or equipment manufacturer for more information regarding updates for your system.

  • Intel® Core™ i3 processor (45nm and 32nm)
  • Intel® Core™ i5 processor (45nm and 32nm)
  • Intel® Core™ i7 processor (45nm and 32nm)
  • Intel® Core™ M processor family (45nm and 32nm)
  • 2nd generation Intel® Core™ processors
  • 3rd generation Intel® Core™ processors
  • 4th generation Intel® Core™ processors
  • 5th generation Intel® Core™ processors
  • 6th generation Intel® Core™ processors
  • 7th generation Intel® Core™ processors
  • 8th generation Intel® Core™ processors
  • Intel® Core™ X-series Processor Family for Intel® X99 platforms
  • Intel® Core™ X-series Processor Family for Intel® X299 platforms
  • Intel® Xeon® processor 3400 series
  • Intel® Xeon® processor 3600 series
  • Intel® Xeon® processor 5500 series
  • Intel® Xeon® processor 5600 series
  • Intel® Xeon® processor 6500 series
  • Intel® Xeon® processor 7500 series
  • Intel® Xeon® Processor E3 Family
  • Intel® Xeon® Processor E3 v2 Family
  • Intel® Xeon® Processor E3 v3 Family
  • Intel® Xeon® Processor E3 v4 Family
  • Intel® Xeon® Processor E3 v5 Family
  • Intel® Xeon® Processor E3 v6 Family
  • Intel® Xeon® Processor E5 Family
  • Intel® Xeon® Processor E5 v2 Family
  • Intel® Xeon® Processor E5 v3 Family
  • Intel® Xeon® Processor E5 v4 Family
  • Intel® Xeon® Processor E7 Family
  • Intel® Xeon® Processor E7 v2 Family
  • Intel® Xeon® Processor E7 v3 Family
  • Intel® Xeon® Processor E7 v4 Family
  • Intel® Xeon® Processor Scalable Family
  • Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
  • Intel® Atom™ Processor C Series
  • Intel® Atom™ Processor E Series
  • Intel® Atom™ Processor A Series
  • Intel® Atom™ Processor x3 Series
  • Intel® Atom™ Processor Z Series
  • Intel® Celeron® Processor J Series
  • Intel® Celeron® Processor N Series
  • Intel® Pentium® Processor J Series
  • Intel® Pentium® Processor N Series

 

Recommendations:Intel has worked with operating system vendors, equipment manufacturers, and other ecosystem partners to develop software updates that can help protect systems from these methods. End users and systems administrators should check with their operating system vendors and apply any available updates as soon as practical.

For non-Intel based systems please contact your system manufacturer or microprocessor vendor (AMD, ARM, Qualcomm, etc.) for updates.

Please check with your system vendor or equipment manufacturer for more information regarding your system.

Other variants of this side-channel analysis are being addressed by Operating System and Software Vendors.  For more details see:

–         CVE-2017-5753 https://01.org/security/advisories/intel-oss-10002

–         CVE-2017-5754 https://01.org/security/advisories/intel-oss-10003

Acknowledgements:Intel would like to thank Jann Horn with Google Project Zero for his original report and for working with the industry on coordinated disclosure.

Intel would also like to thank the following researchers for working with us on coordinated disclosure.

  • Moritz Lipp, Michael Schwarz, Daniel Gruss, Stefan Mangard from Graz University of Technology
  • Paul Kocher, Daniel Genkin from University of Pennsylvania and University of Maryland, Mike Hamburg from Rambus, Cryptography Research Division and Yuval Yarom from  University of Adelaide and Data61.

Thomas Prescher and Werner Haas from Cyberus Technology, Germa

Revision history:

Revision
Date
Description
1.0
03-January-2018
Initial Release
1.1
03-January-2018
Update Links
1.2
05-January-2018
Update
CVE Name:  CVE-2017-5715

All You Need To Know About Spectre And Meltdown A pair of bugs has silently infested CPUs from Intel, AMD, and ARM for years.

 

After two days of whirlwind developments, we finally have more of a complete picture of the new vulnerabilities that impact processors from the leading vendors. Reports initially surfaced two days ago that Intel’s processors are susceptible to a new hardware-based bug that cannot be patched with a mere microcode update. A report from The Register, based in part on a blog post, said that incoming Windows and Linux patches would correct the vulnerability but come with a 5-30% performance loss depending on the workload.

The industry remained silent due to NDAs that were scheduled to expire on January 9, the same date as a round of patches were scheduled to appear. After a day of silence while its stock slumped, Intel issued a statement and claimed the issue is not a hardware bug. Intel also announced that it’s working with other titans of the industry, such as AMD and ARM Holdings, to “develop an industry-wide approach to resolve this issue promptly and constructively.” AMD has since released a statement and claimed that it has minimal exposure to the primary vulnerability.

The root issues behind the vulnerabilities weren’t clearly defined at the time, but a slew of releases from several of the parties involved, along with Google’s Project Zero team, have shed light on two new exploits that have served as the catalyst for the recent developments. We’ll cover the new exploits below; then we’ll get to the updates from Intel, ARM, AMD, and Nvidia.

Performance First

Before we dive into the nuts and bolts, recent tests indicate the patch does not impart a cataclysmic performance loss in most workloads. Phoronix tested the Linux patch, and Computerbase.de tested a patched Windows Insider build.

The good news? Most desktop applications appear to be safe in both Windows 10 and Linux. That includes most workloads that are largely confined to the user space, such as gaming and normal productivity applications. There does appear to be a slowdown to storage I/O operations (2-7%), but for now it’s hard to ascertain if that is due to the patch or other kernel updates. The Windows 10 patch was rolled out to the Windows Insider builds in November, and there haven’t been reports of performance issues.

The bad news? The patch does incur a performance overhead to some enterprise applications. Phoronix recorded significant performance regressions in the object-relational PostgreSQL database. Redis also suffers a performance loss. Many industry analysts feel the real impacts will come in virtualized environments, but we have yet to see benchmarks. Google has already updated all its cloud infrastructure, which includes its cloud computing services, and we haven’t yet heard of significant user backlash due to reduced performance.

Meet Meltdown & Spectre

Google’s Project Zero touched off the vulnerability scare when it discovered that it could access data held in the protected kernel memory through two exploits that are now known as Meltdown and Spectre. Google does not believe these exploits have ever been used in the wild, but it’s impossible to tell if they have or not.

 

Meltdown is both easy to execute and easy to fix. This exploit allows applications to read from the protected kernel memory. That ability can allow hackers to read passwords, encryption keys, or other data from the memory. Intel’s statement specifically noted that the exploits cannot corrupt, modify, or delete data, but those points are moot if the attacker can access passwords and encryption keys. The biggest concern for data centers and cloud service providers is that the exploit also allows an application resident in one virtual machine to access the memory of another remote virtual machine. This means an attacker could rent an instance on a public cloud and collect information from other virtual machines on the same server.

Researchers have been able to execute a Meltdown exploit only on Intel processors, although ARM has submitted patches to protect itself from the same method of attack. In fact, the attack exploits Intel’s out-of-order execution implementation that is present on every Intel processor made since 1995. Researchers discovered Meltdown last year. The exploit is reportedly simple enough that a script kiddie could execute the attack, so a fix is of utmost importance.

Apple already patched this exploit in the MacOS December OSX patch (10.13.2). Windows is also pushing emergency patches out immediately. The Linux kernel has also been patched. These patches do have performance impacts, as we noted above, that largely revolve around how frequently the application issues kernel calls.

The Spectre exploit is much more nefarious and impacts Intel, AMD, and ARM. This exploit can access kernel memory or data from other applications. Researchers contend that fixing this exploit would require a fundamental re-tooling of all processor architectures, so we’ll live with the threat of this vulnerability for the foreseeable future. Fortunately, this exploit is extremely hard to execute and requires an elevated level of knowledge of the interior workings of the target processor.

These two exploits are categorized into three variants. Variants 1 and 2 are Spectre, whereas Variant 3 is Meltdown. Intel is vulnerable to all three.

Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)

Levels Of Exposure

We reached out to AMD, and the company responded with the following information, which has since been publicly released.

Most notably, AMD claims that is has zero vulnerability to Variant 3 (Meltdown), stating that the patches that are currently being issued for Meltdown do not apply to its processors due to “architectural differences.” This is excellent news for AMD, as it therefore has no exposure to the current round of potentially performance-sapping patches. That bodes very well for the company as it reenters the data center with a competitive line of EPYC processors.

The Ryzen desktop processors are also not susceptible to Meltdown. Linus Torvalds has also granted AMD an exemption to the performance penalties incurred by the Linux patch for Meltdown.

AMD is vulnerable to Variant 1, which is a Spectre exploit. As noted above, many contend that Spectre is not likely to see an effective patch any time soon, and some researchers claim the vulnerability exists in every modern processor architecture in existence. They also claim that fixing the issues could require a redesign of fundamental processor architectures. AMD said it has a patch that can mitigate Variant 1 with minimal performance impact and further stated that it has a “near zero risk of exploitation” from Variant 2, which is also a Spectre exploit.

Nvidia also issued a statement regarding the vulnerabilities:

Nvidia’s core business is GPU computing. We believe our GPU hardware is immune to the reported security issue and are updating our GPU drivers to help mitigate the CPU security issue. As for our SoCs with ARM CPUs, we have analyzed them to determine which are affected and are preparing appropriate mitigations.

ARM Holdings has added a security update to its website that outlines its exposure to the vulnerabilities, and like Intel, it is susceptible to all three variants.

The legal ramifications of these developments could be troublesome. The Law Offices of Howard G. Smith has already announced an investigation on behalf of Intel Corporation investors, and there will likely be more similar developments in the coming weeks. Intel has a history of establishing a reserve to cover pending large-scale hardware replacements, but the company has not disclosed a new fund to deal with the vulnerabilities. The company has also stated that it does not expect any impact to its business.

Intel’s statement on the matter specifically says that the exploits are not caused by a “bug” or a “flaw” that is unique to Intel products. Intel also noted that the exploits can “gather sensitive data from computing devices that are operating as designed.” These statements likely indicate Intel will defend any potential claims because “the hardware is working correctly.” Depending on when these vulnerabilities became known (some claim that Meltdown-type attacks have been a known entity since 2010), these points may be challenged in court. ARM and other vendors may also face similar challenges.

Intel’s CEO, Brian Krzanich, also sold $39 million in stocks in November 2017 (this doesn’t include the amount he paid for the stock options). These transaction initially appeared innocuous (and they may be) because Krzanich sold the stock under a 10b5-1(c) plan, which is a pre-planned sale of stocks intended to prevent claims of insider trading. The sale left Krzanich with the Intel-mandated minimum of 250,000 stocks. The sale was pre-planned on October 30. Now, though, MarketWatch claims Intel was made aware of the vulnerability on June 1, which may draw attention to the matter from regulatory officials. Business Insider said a representative for the Securities and Exchange Commission declined to comment on the matter.

Considering the lengthy preparation period, we imagine there will not be any major service disruptions to the cloud service providers. However, we expect more details to come to light concerning performance impacts of the new patches on various workloads. Stay tuned.

Related Articles: Understanding The Meltdown And Spectre Exploits: Intel, AMD, ARM, And Nvidia

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