inspec 1.51.15 → 1.51.18

data/docs/resources/inetd_conf.md.erb

@@ -1,95 +1,95 @@
----
-title: About the inetd_conf Resource
----
-
-# inetd_conf
-
-Use the `inetd_conf` InSpec audit resource to test if a service is listed in the `inetd.conf` file on Linux and Unix platforms. inetd---the Internet service daemon---listens on dedicated ports, and then loads the appropriate program based on a request. The `inetd.conf` file is typically located at `/etc/inetd.conf` and contains a list of Internet services associated to the ports on which that service will listen. Only enabled services may handle a request; only services that are required by the system should be enabled.`
-
-<br>
-
-## Syntax
-
-An `inetd_conf` resource block declares the list of services that are enabled in the `inetd.conf` file:
-
-    describe inetd_conf('path') do
-      its('service_name') { should eq 'value' }
-    end
-
-where
-
-* `'service_name'` is a service listed in the `inetd.conf` file
-* `('path')` is the non-default path to the `inetd.conf` file
-* `should eq 'value'` is the value that is expected
-
-<br>
-
-## Supported Resource Properties
-
-This resource supports any of the properties listed as services in the `inetd.conf` file. You may want to ensure that specific services do not listen via `inetd.conf`.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Basic tests for inetd_conf services:
-
-    its('shell') { should eq nil }
-
-or:
-
-    its('netstat') { should eq nil }
-
-or:
-
-    its('systat') { should eq nil }
-
-For example:
-
-    describe inetd_conf do
-      its('shell') { should eq nil }
-      its('login') { should eq nil }
-      its('exec') { should eq nil }
-    end
-
-### Verify that FTP is disabled
-
-The contents if the `inetd.conf` file contain the following:
-
-    #ftp      stream   tcp   nowait   root   /usr/sbin/tcpd   in.ftpd -l -a
-    #telnet   stream   tcp   nowait   root   /usr/sbin/tcpd   in.telnetd
-
-and the following test is defined:
-
-    describe inetd_conf do
-      its('ftp') { should eq nil }
-      its('telnet') { should eq nil }
-    end
-
-Because both the `ftp` and `telnet` Internet services are commented out (`#`), both services are disabled. Consequently, both tests will return `true`. However, if the `inetd.conf` file is set as follows:
-
-    ftp       stream   tcp   nowait   root   /usr/sbin/tcpd   in.ftpd -l -a
-    #telnet   stream   tcp   nowait   root   /usr/sbin/tcpd   in.telnetd
-
-then the same test will return `false` for `ftp` and the entire test will fail.
-
-### Test if telnet is installed
-
-    describe package('telnetd') do
-      it { should_not be_installed }
-    end
-
-    describe inetd_conf do
-      its('telnet') { should eq nil }
-    end
-
-<br>
-
-## Matchers
-
- 
-
-For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
-
+---
+title: About the inetd_conf Resource
+---
+
+# inetd_conf
+
+Use the `inetd_conf` InSpec audit resource to test if a service is listed in the `inetd.conf` file on Linux and Unix platforms. inetd---the Internet service daemon---listens on dedicated ports, and then loads the appropriate program based on a request. The `inetd.conf` file is typically located at `/etc/inetd.conf` and contains a list of Internet services associated to the ports on which that service will listen. Only enabled services may handle a request; only services that are required by the system should be enabled.`
+
+<br>
+
+## Syntax
+
+An `inetd_conf` resource block declares the list of services that are enabled in the `inetd.conf` file:
+
+    describe inetd_conf('path') do
+      its('service_name') { should eq 'value' }
+    end
+
+where
+
+* `'service_name'` is a service listed in the `inetd.conf` file
+* `('path')` is the non-default path to the `inetd.conf` file
+* `should eq 'value'` is the value that is expected
+
+<br>
+
+## Supported Resource Properties
+
+This resource supports any of the properties listed as services in the `inetd.conf` file. You may want to ensure that specific services do not listen via `inetd.conf`.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Basic tests for inetd_conf services:
+
+    its('shell') { should eq nil }
+
+or:
+
+    its('netstat') { should eq nil }
+
+or:
+
+    its('systat') { should eq nil }
+
+For example:
+
+    describe inetd_conf do
+      its('shell') { should eq nil }
+      its('login') { should eq nil }
+      its('exec') { should eq nil }
+    end
+
+### Verify that FTP is disabled
+
+The contents if the `inetd.conf` file contain the following:
+
+    #ftp      stream   tcp   nowait   root   /usr/sbin/tcpd   in.ftpd -l -a
+    #telnet   stream   tcp   nowait   root   /usr/sbin/tcpd   in.telnetd
+
+and the following test is defined:
+
+    describe inetd_conf do
+      its('ftp') { should eq nil }
+      its('telnet') { should eq nil }
+    end
+
+Because both the `ftp` and `telnet` Internet services are commented out (`#`), both services are disabled. Consequently, both tests will return `true`. However, if the `inetd.conf` file is set as follows:
+
+    ftp       stream   tcp   nowait   root   /usr/sbin/tcpd   in.ftpd -l -a
+    #telnet   stream   tcp   nowait   root   /usr/sbin/tcpd   in.telnetd
+
+then the same test will return `false` for `ftp` and the entire test will fail.
+
+### Test if telnet is installed
+
+    describe package('telnetd') do
+      it { should_not be_installed }
+    end
+
+    describe inetd_conf do
+      its('telnet') { should eq nil }
+    end
+
+<br>
+
+## Matchers
+
+ 
+
+For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+

data/docs/resources/ini.md.erb

@@ -1,72 +1,72 @@
----
-title: About the ini Resource
----
-
-# ini
-
-Use the `ini` InSpec audit resource to test settings in an INI file.
-
-<br>
-
-## Syntax
-
-An `ini` resource block declares the configuration settings to be tested:
-
-    describe ini('path') do
-      its('setting_name') { should eq 'value' }
-    end
-
-where
-
-* `'setting_name'` is a setting key defined in the INI file
-* `('path')` is the path to the INI file
-* `{ should eq 'value' }` is the value that is expected
-
-For example:
-
-    describe ini('path/to/ini_file.ini') do
-      its('port') { should eq '143' }
-      its('server') { should eq '192.0.2.62' }
-    end
-
-Settings inside of sections, such as the following:
-
-    [section_name]
-    setting_name = 123
-
-... can be retrieved by prefixing the setting_name with the section.
-
-    its('section_name.setting_name') { should cmp 123 }
-
-In the event a section or setting name has a period in it, the alternate syntax can be used:
-
-    its(['section.with.a.dot.in.it', 'setting.name.with.dots']) { should cmp 'lotsadots' }
-
-<br>
-## Supported Properties
-
-This resource supports any of the settings listed in an INI file as properties. 
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test SMTP settings in a PHP INI file
-
-For example, a PHP INI file located at contains the following settings:
-
-    [mail function]
-    SMTP = smtp.gmail.com
-    smtp_port = 465
-
-and can be tested like this:
-
-    describe ini('/etc/php5/apache2/php.ini') do
-      its('mail function.smtp_port') { should eq('465') }
-    end
-
-<br>
-
-## Matchers
-
-For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).
+---
+title: About the ini Resource
+---
+
+# ini
+
+Use the `ini` InSpec audit resource to test settings in an INI file.
+
+<br>
+
+## Syntax
+
+An `ini` resource block declares the configuration settings to be tested:
+
+    describe ini('path') do
+      its('setting_name') { should eq 'value' }
+    end
+
+where
+
+* `'setting_name'` is a setting key defined in the INI file
+* `('path')` is the path to the INI file
+* `{ should eq 'value' }` is the value that is expected
+
+For example:
+
+    describe ini('path/to/ini_file.ini') do
+      its('port') { should eq '143' }
+      its('server') { should eq '192.0.2.62' }
+    end
+
+Settings inside of sections, such as the following:
+
+    [section_name]
+    setting_name = 123
+
+... can be retrieved by prefixing the setting_name with the section.
+
+    its('section_name.setting_name') { should cmp 123 }
+
+In the event a section or setting name has a period in it, the alternate syntax can be used:
+
+    its(['section.with.a.dot.in.it', 'setting.name.with.dots']) { should cmp 'lotsadots' }
+
+<br>
+## Supported Properties
+
+This resource supports any of the settings listed in an INI file as properties. 
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test SMTP settings in a PHP INI file
+
+For example, a PHP INI file located at contains the following settings:
+
+    [mail function]
+    SMTP = smtp.gmail.com
+    smtp_port = 465
+
+and can be tested like this:
+
+    describe ini('/etc/php5/apache2/php.ini') do
+      its('mail function.smtp_port') { should eq('465') }
+    end
+
+<br>
+
+## Matchers
+
+For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/).

data/docs/resources/interface.md.erb

@@ -1,55 +1,55 @@
----
-title: About the interface Resource
----
-
-# interface
-
-Use the `interface` InSpec audit resource to test basic network adapter properties, such as name, status, and link speed (in MB/sec).
-
-* On Linux platforms, `/sys/class/net/#{iface}` is used as source
-* On the Windows platform, the `Get-NetAdapter` cmdlet is used as source
-
-<br>
-
-## Syntax
-
-An `interface` resource block declares network interface properties to be tested:
-
-    describe interface('eth0') do
-      it { should be_up }
-      its('speed') { should eq 1000 }
-      its('name') { should eq eth0 }
-    end
-
-<br>
-## Resource Properties
-
-`name`, `speed`
-<br>
-
-## Resource Property Examples
-
-### name
-
-The `name` matcher tests if the named network interface exists:
-
-    its('name') { should eq eth0 }
-
-### speed
-
-The `speed` matcher tests the speed of the network interface, in MB/sec:
-
-    its('speed') { should eq 1000 }
-
-<br> 
-
-## Matchers
-
-For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/). 
-
-### be_up
-
-The `be_up` matcher tests if the network interface is available:
-
-    it { should be_up }
-
+---
+title: About the interface Resource
+---
+
+# interface
+
+Use the `interface` InSpec audit resource to test basic network adapter properties, such as name, status, and link speed (in MB/sec).
+
+* On Linux platforms, `/sys/class/net/#{iface}` is used as source
+* On the Windows platform, the `Get-NetAdapter` cmdlet is used as source
+
+<br>
+
+## Syntax
+
+An `interface` resource block declares network interface properties to be tested:
+
+    describe interface('eth0') do
+      it { should be_up }
+      its('speed') { should eq 1000 }
+      its('name') { should eq eth0 }
+    end
+
+<br>
+## Resource Properties
+
+`name`, `speed`
+<br>
+
+## Resource Property Examples
+
+### name
+
+The `name` matcher tests if the named network interface exists:
+
+    its('name') { should eq eth0 }
+
+### speed
+
+The `speed` matcher tests the speed of the network interface, in MB/sec:
+
+    its('speed') { should eq 1000 }
+
+<br> 
+
+## Matchers
+
+For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/). 
+
+### be_up
+
+The `be_up` matcher tests if the network interface is available:
+
+    it { should be_up }
+

data/docs/resources/iptables.md.erb

@@ -1,63 +1,63 @@
----
-title: About the iptables Resource
----
-
-# iptables
-
-Use the `iptables` InSpec audit resource to test rules that are defined in `iptables`, which maintains tables of IP packet filtering rules. There may be more than one table. Each table contains one (or more) chains (both built-in and custom). A chain is a list of rules that match packets. When the rule matches, the rule defines what target to assign to the packet.
-
-<br>
-
-## Syntax
-
-A `iptables` resource block declares tests for rules in IP tables:
-
-    describe iptables(rule:'name', table:'name', chain: 'name') do
-      it { should have_rule('RULE') }
-    end
-
-where
-
-* `iptables()` may specify any combination of `rule`, `table`, or `chain`
-* `rule:'name'` is the name of a rule that matches a set of packets
-* `table:'name'` is the packet matching table against which the test is run
-* `chain: 'name'` is the name of a user-defined chain or one of `ACCEPT`, `DROP`, `QUEUE`, or `RETURN`
-* `have_rule('RULE')` tests that rule in the iptables list. This must match the entire line taken from `iptables -S CHAIN`.
-
-<br>
-
-## Examples
-
-The following examples show how to use this InSpec audit resource.
-
-### Test if the INPUT chain is in default ACCEPT mode
-
-    describe iptables do
-      it { should have_rule('-P INPUT ACCEPT') }
-    end
-
-### Test if the INPUT chain from the mangle table is in ACCEPT mode
-
-    describe iptables(table:'mangle', chain: 'INPUT') do
-      it { should have_rule('-P INPUT ACCEPT') }
-    end
-
-### Test if there is a rule allowing Postgres (5432/TCP) traffic
-
-    describe iptables do
-      it { should have_rule('-A INPUT -p tcp -m tcp -m multiport --dports 5432 -m comment --comment "postgres" -j ACCEPT') }
-    end
-
-Note that the rule specification must exactly match what's in the output of `iptables -S INPUT`, which will depend on how you've built your rules.
-
-<br>
-
-## Matchers
-
-For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/). 
-
-### have_rule
-
-The `have_rule` matcher tests the named rule against the information in the `iptables` file:
-
-    it { should have_rule('RULE') }
+---
+title: About the iptables Resource
+---
+
+# iptables
+
+Use the `iptables` InSpec audit resource to test rules that are defined in `iptables`, which maintains tables of IP packet filtering rules. There may be more than one table. Each table contains one (or more) chains (both built-in and custom). A chain is a list of rules that match packets. When the rule matches, the rule defines what target to assign to the packet.
+
+<br>
+
+## Syntax
+
+A `iptables` resource block declares tests for rules in IP tables:
+
+    describe iptables(rule:'name', table:'name', chain: 'name') do
+      it { should have_rule('RULE') }
+    end
+
+where
+
+* `iptables()` may specify any combination of `rule`, `table`, or `chain`
+* `rule:'name'` is the name of a rule that matches a set of packets
+* `table:'name'` is the packet matching table against which the test is run
+* `chain: 'name'` is the name of a user-defined chain or one of `ACCEPT`, `DROP`, `QUEUE`, or `RETURN`
+* `have_rule('RULE')` tests that rule in the iptables list. This must match the entire line taken from `iptables -S CHAIN`.
+
+<br>
+
+## Examples
+
+The following examples show how to use this InSpec audit resource.
+
+### Test if the INPUT chain is in default ACCEPT mode
+
+    describe iptables do
+      it { should have_rule('-P INPUT ACCEPT') }
+    end
+
+### Test if the INPUT chain from the mangle table is in ACCEPT mode
+
+    describe iptables(table:'mangle', chain: 'INPUT') do
+      it { should have_rule('-P INPUT ACCEPT') }
+    end
+
+### Test if there is a rule allowing Postgres (5432/TCP) traffic
+
+    describe iptables do
+      it { should have_rule('-A INPUT -p tcp -m tcp -m multiport --dports 5432 -m comment --comment "postgres" -j ACCEPT') }
+    end
+
+Note that the rule specification must exactly match what's in the output of `iptables -S INPUT`, which will depend on how you've built your rules.
+
+<br>
+
+## Matchers
+
+For a full list of available matchers please visit our [matchers page](https://www.inspec.io/docs/reference/matchers/). 
+
+### have_rule
+
+The `have_rule` matcher tests the named rule against the information in the `iptables` file:
+
+    it { should have_rule('RULE') }