summaryrefslogtreecommitdiffstats
path: root/sec-blueprint
diff options
context:
space:
mode:
authorHammad Ahmed <hammad.ahmed@irdeto.com>2016-12-13 17:08:41 -0800
committerHammad Ahmed <hammad.ahmed@irdeto.com>2016-12-21 08:46:07 -0500
commit3fb9e563844d183d1909263394068d9d59c3d7a6 (patch)
tree317d08313581142f74387b21ef76d283a6e528d5 /sec-blueprint
parent5d0f0e61aea7e89589b6a0c1280a99b18646eb11 (diff)
Adding system hardening guide
Diffstat (limited to 'sec-blueprint')
-rw-r--r--sec-blueprint/08-Hardening.md769
1 files changed, 755 insertions, 14 deletions
diff --git a/sec-blueprint/08-Hardening.md b/sec-blueprint/08-Hardening.md
index 8e2b582..092eb74 100644
--- a/sec-blueprint/08-Hardening.md
+++ b/sec-blueprint/08-Hardening.md
@@ -41,16 +41,193 @@ invalid binaries on the device, and to prevent copying of security
related data from the device.
There are three main areas of focus for hardening an embedded device:
+**Boot Hardening**: Steps/requirements to configure the boot sequence,
+in order to restrict the device from executing anything other than the
+approved software image.
+
+**System Hardening**: Best practices associated with the configuration
+of an embedded Linux based operating system. This section includes both
+hardening of the kernel itself, as well as specific configurations and
+patches used to protect against known vulnerabilities within the build
+and configuration of the root filesystem.
+
+**Application Hardening:** Best practices to apply to the build and
+release of user space applications, in order to reduce the number of
+attack surfaces used by potential attackers.
+
+Secure Boot Software Flow Steps
+-------------------------------
+
+1. After power on, the secure processor will perform the verification
+ of the Stage 1 boot image, the stage 2 boot image and the Secure
+ loader image.
+
+ a. If any of the images fail the verification process the device
+ will restart.
+
+2. Upon successful verification of all of the boot and loader images,
+ the secure process will initiate the Stage 1 boot process.
+
+3. The Stage 1 boot process will perform processor initialization, and
+ then initiate the Stage 2 boot process.
+
+4. The Stage 2 boot process will initiate the Secure Loader, which will
+ process any customer specific customizations (e.g. front panel
+ of ECU, USB based image updates, etc).
+
+5. The Secure Loader will check to determine if there are any updates
+ to be processed. If the update settings indicate that an upgrade
+ should occur then the Secure Loader will will determine the correct
+ action based on the nature of the upgrades:
+
+ a. If the Secure Loader determines that an upgrade was performed
+ (or attempted), it will initiate the reboot process.
+
+ b. If no upgrades were processed: then the Secure Loader will pass
+ control back to the Stage 2 boot process for further processing
+
+6. The Stage 2 boot process will continue with the boot process, by
+ performing a verification of the kernel image prior to the load of
+ that image
+
+ a. If the kernel image verification fails, the Stage 2 boot loader
+ will initiate a reboot
+
+8. The Stage 2 boot loader will load the successfully verified kernel
+ image and boot the linux OS
+
+9. The booted Linux OS will perform the normal Linux init sequence
+
+10. The Linux init process will start the required applications and
+ services as described in the init process and present on the rootfs.
Requirements
============
For the purposes of reference and explanation, we are providing guidance
on how to configure an embedded device that runs with a linux 3. 10.17
- Linux kernel.
+ Linux kernel, and includes the use of U-Boot as the *Stage 2*
These requirements must still be met by manufacturers that
opt to build using an alternative version of the Linux kernel.
+Hardened Boot
+-------------
+
+### Boot image selection
+
+The boot process shall be uninterruptable and shall irrevocably boot the
+image as specified in the boot environment.
+
+In U-Boot set the “**bootdelay**” environment variable and/or define
+CONFIG\_BOOTDELAY to -2.
+
+### Verifying Authenticity of booting image
+
+It shall not be possible to boot from an unverified image.
+
+The secure boot feature in U-Boot shall be enabled. The secure boot
+feature is available from U-Boot 2013.07 version.
+
+To enable the secure boot feature, enable the following features:
+
+```
+CONFIG_FIT: enables support for Flat Image Tree (FIT) uImage format.
+CONFIG_FIT_SIGNATURE: enables signature verification of FIT images.
+CONFIG_RSA: enables RSA algorithm used for FIT image verifitcation.
+CONFIG_OF_CONTROL: enables Flattened Device Tree (FDT) configuration.
+CONFIG_OF_SEPARATE: enables separate build of u-Boot from the device tree.
+CONFIG_DEFAULT_DEVICE_TREE: specifies the default Device Tree used for the
+run-time configuration of U-Boot.
+```
+
+Generate the U-Boot image with public keys to validate and load the
+image. It shall use RSA2048 and SHA256 for authentication.
+
+### Disable USB support
+
+To disable USB support in U-Boot, following configs shall not be
+defined:
+
+```
+CONFIG_CMD_USB: enables basic USB support and the usb command
+CONFIG_USB_UHCI: defines the lowlevel part.
+CONFIG_USB_KEYBOARD: enables the USB Keyboard
+CONFIG_USB_STORAGE: enables the USB storage devices
+CONFIG_USB_HOST_ETHER: enables USB ethernet adapter support
+```
+
+### Console / Remote Access
+
+Serial console output shall be disabled. To disable console output in
+U-Boot, set the following macros:
+
+```
+CONFIG_SILENT_CONSOLE
+CONFIG_SYS_DEVICE_NULLDEV
+CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC
+```
+
+and set “***silent”*** environment variable.
+
+For the Secure loader, disable the traces by undefining the below macro
+
+```
+INC_DEBUG_PRINT
+```
+
+For sboot proper configuration needs to be done to disable the serial
+console.
+
+### Field upgrades
+
+Field upgrades can be achieved securely by using a Secure Loader.
+This loader will authenticate an incoming image (USB,Serial, Network)
+prior to writing it to the flash memory on the device. It should not be
+possible to write to flash from bootloader (U-Boot). Note that because
+ USB support is to be disabled within the sboot/U-Boot code, the board
+specific implementation of the Secure Loader will have to manage the
+entire USB initialization, enumeration, and read/write access to the
+mass storage device.
+
+### Disable USB, Serial, Docsis support
+
+Disable USB support in sboot. In addition, disable unnecessary communication
+modes like Ethernet, Serial ports, DOCSIS in U-Boot and sboot that are
+not necessary.
+
+### Immutable Environment variables
+
+In U-Boot, ensure Kernel command line, boot commands, boot delay and
+other environment variables are immutable. This will prevent
+side-loading of alternate images, by restricting the boot selection to
+only the image in FLASH.
+
+The environment variables shall be part of text region in U-Boot as
+default environment variable and not in non-volatile memory.
+
+Remove configuration options related to non-volatile memory such as:
+
+```
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_ENV_IS_IN_EEPROM
+#define CONFIG_ENV_IS_IN_FLASH
+#define CONFIG_ENV_IS_IN_DATAFLASH
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_ENV_IS_IN_FAT
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_IS_IN_NVRAM
+#define CONFIG_ENV_IS_IN_ONENAND
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_IS_IN_REMOTE
+#define CONFIG_ENV_IS_IN_UBI
+```
+
+and include the following definition:
+
+```
+#define** CONFIG_ENV_IS_NOWHERE
+```
+
Kernel Hardening
----------------
@@ -107,7 +284,7 @@ Kernel Hardening
```bash
CONFIG_CMDLINE_BOOL=y
- CONFIG_CMDLINE=”&lt;*insert kernel command line here*&gt;”
+ CONFIG_CMDLINE=”insert kernel command line here”
CONFIG_CMDLINE_OVERRIDE=y
```
@@ -200,7 +377,7 @@ Kernel Hardening
### Disable OOPS print on BUG()
The output from OOPS print can be helpful in Return Oriented
- Programming (ROP) when trying to determine the effectives of an
+ Programming (ROP) when trying to determine the effectiveness of an
exploit.
```bash
@@ -365,6 +542,217 @@ Kernel Hardening
```bash
CONFIG_MODULE_FORCE_LOAD=n
```
+### System Services
+
+#### Console & Remote Access
+
+- The kernel console interfaces shall be disabled. Do not pass any statements
+ of the following kind (e.g. console=ttyS0 console=tty0) on the kernel
+ command line. All of the console=&lt;interface&gt; statements should be
+ stripped and removed from the kernel command line.
+
+- The following lines from /etc/inittab should be removed for the
+ serial console:
+
+ S0:12345:respawn:/sbin/getty 115200 ttyS0
+
+ ttyS0::askfirst:-/bin/sh
+
+ Failing to do so will result in the System V init process trying to
+ infinitely open a tty port and spawn a login shell on the serial
+ console, which will result in the following repetitive output:
+
+ INIT: Id “S0” respawning too fast: disabled for 5 minutes
+
+- The telnet server shall be disabled.
+
+- Do not start telnetd in init scripts.
+
+- Remove telnetd from the root file system.
+
+- Root login access via the console shall be disabled.
+
+- Do not run shell or getty on /dev/ttySx or /dev/console from
+ init scripts.
+
+- Root login access through remote access such as SSH shall
+ be disabled.
+
+- In the /etc/ssh/sshd\_config file:
+
+ **PermitRootLogin no**
+
+ Or if running dropbear ssh server, in the /etc/config/dropbear config
+ file:
+
+ **RootLogin no**
+
+#### Disable *sudo* for other users
+
+ Remove the /etc/sudoers file from the root file system
+
+ Remove the sudo command from the root file system.
+
+#### Mount /tmp file system as noexec
+
+ A lot of malware can be stopped by not allowing files located in /tmp
+ to execute.
+
+ The /etc/fstab file should contain a line for the /tmp directory with
+ the noexec mount option set as follows:
+
+ tmpfs /tmp tmpfs noexec 0 0
+
+#### User Account Management
+
+ All user accounts shall have strong, non-default passwords. A strong
+ password is described to have all of the following attributes:
+
+- At least one upper-case letter
+
+- At least one numeric character
+
+- At least one lower-case letter
+
+- Password shall be eight or more characters in length
+
+- Shall not use a known, common pattern (e.g. Xxxxxxx\#
+ or Xxxxxxx\#\#)
+
+#### Remove known insecure services
+
+ The following legacy services are inherently insecure and should be
+ avoided:
+
+- rlogind
+
+- rshd
+
+- rcmd
+
+- rexecd
+
+- rbootd
+
+- rquotad
+
+- rstatd
+
+- rusersd
+
+- rwalld
+
+- rhosts
+
+- rexd
+
+ These services offer insufficient authentication, no encryption, and
+ are not considered secure. They shall be removed along with their
+ configuration files.
+
+### The mtd-utils shall not be present on the file system
+
+ The mtd-utils binary package (also known as the Memory Technology
+ Device Utilities package) contains a collection of executable binaries
+ that allow a user to perform operations on raw flash devices. Here’s a
+ non-exhaustive sample of commonly used utilities that are part of the
+ mtd-utils package:
+
+- flash\_erase
+
+- flash\_eraseall
+
+- flashcp
+
+- flash\_lock
+
+- flash\_otp\_dump
+
+- flash\_otp\_info
+
+- flash\_unlock
+
+- mkfs.jffs2
+
+- mkfs.ubifs
+
+- nanddump
+
+- nandtest
+
+- nandwrite
+
+- ubiattach
+
+- ubicrc32
+
+- ubidetach
+
+- ubiformat
+
+- ubimkvol
+
+- ubinfo
+
+- ubinize
+
+- ubirename
+
+- ubirmvol
+
+- ubirsvol
+
+- ubiupdatevol
+
+ The mtd-utils package as a whole (including all of its executable
+ binaries) shall not be present on the file system. Including these
+ binaries on the file system will facilitate an attacker’s ability to
+ read, write or otherwise gather information about raw flash devices
+ present on the system.
+
+### Debuggers shall not be present on the file system
+
+ No debuggers shall be present on the file system. This includes, but
+ is not limited to, the GNU Debugger client/server (commonly known in
+ their short form names such as the gdb and gdbserver executable
+ binaries respectively), or the LLDB next generation debugger.
+ Including these binaries as part of the file system will facilitate an
+ attacker’s ability to reverse engineer and debug (either locally or
+ remotely) any process that is currently executing on the device.
+
+### Partition Mount Options
+
+ There are several security restrictions that can be set on a
+ filesystem when it is mounted. Some common security options include,
+ but are not limited to:
+
+ nosuid - Do not allow set-user-identifier or set-group-identifier bits
+ to take effect
+
+ nodev - Do not interpret character or block special devices on the
+ filesystem
+
+ noexec - Do not allow execution of any binaries on the mounted
+ filesystem
+
+ ro - Mount filesystem as read-only
+
+ The following flags shall be used for mounting common filesystems:
+
+
+| Partition | Notes |
+|------------------------------|---------------------------------------------------------------------------------------------|
+| /boot | Use nosuid and nodev and consider using noexec. |
+| /var & /tmp | In the /etc/fstab or vfstab file, add nosuid, nodev and noexec. |
+| Non-Root local partitions | If the filesystem type is ext2 or ext3 and the mount point is not '/', add the nodev option.|
+| Removable storage partitions | Add nodev, nosuid, and noexec options. |
+| Temporary storage partitions | Add nodev, nosuid, and noexec options. |
+| /dev/shm | Add nodev, nosuid, and noexec options. |
+| /dev | Add nosuid, noexec options.\ |
+| | Note: if CONFIG\_DEVTMPFS\_MOUNT is set then the kernel will mount /dev and will not apply |
+| | the nosuid, noexec options. Either disable CONFIG\_DEVTMPFS\_MOUNT or add a remount with |
+| | noexec and nosuid options to system startup. |
+
Recommendations
===============
@@ -373,8 +761,91 @@ The following sections detail best practices that should be applied in
order to secure a device.
Although they are not currently listed as hard
requirements, they may be upgraded to requirements status in the future.
+In addition, specific operators may change some of these recommendations
+into requirements based on their specific needs and objectives.
+
+Hardened Boot
+-------------
+
+The boot loader consists of the Primary boot loader residing in OTP
+memory, sboot, U-Boot and Secure loader residing in external flash (NAND
+or SPI/NOR flash memory). The CPU on power on or reset executes the
+primary boot loader. The OTP primary boot loader makes the necessary
+initial system configuration and then loads the secondary boot loader
+sboot from external flash memory to ram memory. The sboot then loads the
+U-Boot along with the Secure loader. U-Boot then verifies and loads the
+Kernel/system image before passing control to it.
+
+### Removal of memory dump commands
+
+In U-Boot, following commands shall be disabled to avoid memory dumps
+
+```
+md : Memory Display command
+mm : Memory modify command – auto incrementing address
+nm : Memory modify command – constant address
+
+mw : memory write
+
+cp : memory copy
+
+mwc : memory write cyclic
+
+mdc : memory display cyclic
+
+mtest : simple ram read/write test
+
+loopw : infinite write loop on address range
+```
+
+Similarly memory dump support shall be disabled from sboot
+
+### Disable flash access
+
+In U-Boot following flash memory commands shall be disabled:
+
+Nand: Support for nand flash access available through **do\_nand** has
+to be disabled.
+
+Similarly sboot should disable flash access support through command line
+if any.
+
+Hardened System
+---------------
+
+### Network
+
+#### Disable all Network Interfaces
+
+ Preferably no network interface is allowed, but if required, then the
+ enabled services should be restricted to only those described in the
+ STB’s functional description.
+
+### Remove or Disable Unnecessary Services, Ports, and Devices.
+
+ Services and utilities that do not have a defined purpose on a system
+ should be removed. If removal is not possible, but the service or
+ utility can be disabled, then it should be disabled. If a service or
+ utility is necessary, available secure configuration best practices
+ should be implemented.
+
+ Telnet, FTP, and NFS have security weaknesses that are well known;
+ however, customers may have requirements to use these services. If
+ remote shell access and file transfer are required, then provide more
+ secure options, such as SSH and SFTP/SCP.
+
+### Restrict USB Ports
+
+ Linux Kernel support for USB should be compiled-out if not required.
+ If it is needed, the Linux Kernel should be configured to only enable
+ the minimum required USB devices.
+
+ User-initiated USB-filesystems should be treated with special care..
+
+ Whether or not the filesystems are mounted in userspace(FUSE), restricted
+ mount options should be observed.
Kernel Hardening
----------------
@@ -553,7 +1024,7 @@ Kernel Hardening
### Disable all file systems not needed
- To reduce the attack surface; file system data is parsed by the kernel
+ To reduce the attack surface, file system data is parsed by the kernel
so any logic bugs in file system drivers can become kernel exploits.
### Kernel Address Display Restriction
@@ -580,24 +1051,294 @@ Kernel Hardening
/proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg
output as sensitive.
-### SELinux
+Enable the below compiler and linker options when building user-space
+applications to avoid stack smashing, buffer overflow attacks.
+
+### Stack Smashing Attacks
+
+ **-fstack-protector-all**
+
+ Emit extra code to check for buffer overflows, such as stack smashing
+ attacks
+
+### Position Independent Executables
+
+ **-pie –fpic**
+
+ Produce a position independent executable on targets which supports
+ it.
+
+### Detect Buffer Overflows
+
+ **-D\_FORTIFY\_SOURCE=2**
+
+ Helps detect some buffer overflow errors.
+
+### Prevent Overwrite Attacks
+
+ **–z,relro**
+
+ This linking option helps during program load, several ELF memory
+ sections need to be written by the linker, but can be turned read-only
+ before turning over control to the program. This prevents some Global
+ Offset Table GOT overwrite attacks, or in the dtors section of the ELF
+ binary.
+
+ **-z,now**
+
+During program load, all dynamic symbols are resolved, allowing for the
+complete GOT to be marked read-only (due to -z relro above). This
+prevents GOT overwrite attacks. For very large application, this can
+incur some performance loss during initial load while symbols are
+resolved, but this shouldn't be an issue for daemons.
+
+### Library linking
+
+ **–static**
+
+Dynamic linking shall not be allowed. This will avoid user from
+replacing a library with malicious library. All libraries should be
+linked statically.
+
+Removal or Non-Inclusion of Utilities
+-------------------------------------
+
+Table below lists utilities that are typically present in an embedded
+device, along with the normal path of each utility. The table has
+information about whether a utility shall be included or excluded from
+respective environment. The values “INCLUDE” here means to include the
+utility in the environment and “EXCLUDE” means to exclude it from the
+respective environment.
+
+| **Utility Name** | **Location** | **Debug Environment** | **Production Environment** |
+|-------------------|-------------------------------------------|------------------------|------------------------------|
+| Strace | /bin/trace | INCLUDE | EXCLUDE |
+| Klogd | /sbin/klogd | INCLUDE | EXCLUDE |
+| Syslogd(logger) | /bin/logger | INCLUDE | EXCLUDE |
+| Gdbserver | /bin/gdbserver | INCLUDE | EXCLUDE |
+| Dropbear | Remove “dropbear” from ‘/etc/init.d/rcs’ | EXCLUDE | EXCLUDE |
+| SSH | NA | EXCLUDE | EXCLUDE |
+| Editors (vi) | /bin/vi | INCLUDE | EXCLUDE |
+| Netstat | /bin/netstat | INCLUDE | EXCLUDE |
+| Dmesg | /bin/dmesg | INCLUDE | EXCLUDE |
+| UART | /proc/tty/driver/ | INCLUDE | EXCLUDE |
+| Hexdump | /bin/hexdump | INCLUDE | EXCLUDE |
+| Dnsdomainname | /bin/dnsdomainname | EXCLUDE | EXCLUDE |
+| Hostname | /bin/hostname | INCLUDE | EXCLUDE |
+| Pmap | /bin/pmap | INCLUDE | EXCLUDE |
+| su | /bin/su | EXCLUDE | EXCLUDE |
+| Which | /bin/which | INCLUDE | EXCLUDE |
+| Who and whoami | /bin/whoami | INCLUDE | EXCLUDE |
+| ps | /bin/ps | INCLUDE | EXCLUDE |
+| lsmod | /sbin/lsmod | INCLUDE | EXCLUDE |
+| install | /bin/install | INCLUDE | EXCLUDE |
+| logger | /bin/logger | INCLUDE | EXCLUDE |
+| ps | /bin/ps | INCLUDE | EXCLUDE |
+| rpm | /bin/rpm | INCLUDE | EXCLUDE |
+| Iostat | /bin/iostat | INCLUDE | EXCLUDE |
+| find | /bin/find | INCLUDE | EXCLUDE |
+| Chgrp | /bin/chgrp | INCLUDE | EXCLUDE |
+| Chmod | /bin/chmod | INCLUDE | EXCLUDE |
+| Chown | /bin/chown | INCLUDE | EXCLUDE |
+| killall | /bin/killall | INCLUDE | EXCLUDE |
+| top | /bin/top | INCLUDE | EXCLUDE |
+| stbhotplug | /sbin/stbhotplug | INCLUDE | EXCLUDE |
+
+Note: The following Unix/Linux utilities shall be permitted as they are
+often used in the start-up scripts and for USB logging. If any of these
+utilities are not required by the device then those should be removed.
+
+ **sed, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount (vfat),
+ printf, tail, tee, test (directory), test (file)**
+
+Root Access
+------------
+
+The main applications, those that provide the principal functionality of
+the embedded device, **should not execute** with root privileges.
+
+If the main application are allowed to execute at elevated privileges,
+then the entire system is at the mercy of the said application’s good
+behaviour. Problems arise when an application is compromised and able to
+execute commands which could consistently and persistently compromise
+the system by implanting rogue applications.
+
+It is suggested that the middleware and the UI should run in a context
+on a user with lowered privileges and all persistent resources should be
+maintained with such privileges.
+
+One way to ensure this is by implementing a server-client paradigm.
+Services provided by the system’s drivers can be shared this way. The
+other advantage of this approach is that multiple applications can share
+the same resources at the same time.
+
+Root access **should not be allowed** for the following utilities:
- If SELinux is in use on the embedded system, the following kernel
- options should be enabled to prevent SELlinux from being disabled at
- either runtime or boot time.
+```
+ login
+ su
+ ssh
+ scp
+ sftp
+```
-```bash
- CONFIG_SECURITY_SELINUX_DEVELOP=n
- CONFIG_SECURITY_SELINUX_DISABLE=n
- CONFIG_SECURITY_SELINUX_BOOTPARAM=n
+Root access **should not be allowed** for the console device. The
+development environment should allow users to login with pre-created
+user accounts.
+
+Switching to elevated privileges shall be allowed in the development
+environment via sudo.
+
+Network Hardening
+-----------------
+
+### Disable IPv4 Forwarding
+
+ The net.ipv4.ip\_forward sysctl setting controls if IP forwarding is
+ allowed or not on the System. Unless the system is used as a router or
+ gateway, IPv4 forwarding should be disabled.
+
+### Disable IP Source Routing
+
+ Disable IP source routing on all interfaces through the
+ net.ipv4.conf.\*.accept\_source\_route = 0 setting.
+
+ IP source routing would allow a remote user (the sender) to specify
+ the route that the packet should take, rather than use the (default)
+ routing tables used by the routers between the sender and the
+ destination. This could be used to spoof IP addresses and still get
+ the replies (rather than sending the replies to the real owner of the
+ IP address).
+
+### Disable ICMP
+
+ Use of ICMP, especially ping, shall be avoided. This is a common way
+ of gaining access to a system.
+
+#### Disable ICMP Redirects
+
+ Set net.ipv4.conf.\*.accept\_redirects=0 to disable ICMP redirect
+ support on the interfaces.
+
+ ICMP redirect messages are used by routers to inform hosts to use a
+ different gateway than the one used. These packets should only be sent
+ by the gateway of the system. In managed and embedded devices the
+ gateway is controlled and any changes should be controlled.
+
+ Allowing ICMP redirect messages would allow for "remote" updating of
+ the routing table, which could allow an attacker to get all packets
+ sent to the outside first rather than the packets immediately going to
+ the real gateway.
+
+#### Ignore ICMP Echo Broadcasts
+
+ When net.ipv4.icmp\_echo\_ignore\_broadcasts=1 is set, then your
+ system will not reply to broadcast “ping” requests.
+
+#### Ignore ICMP Bogus Error Responses
+
+ When an invalid response is given to broadcast frames (which occurs
+ sometimes in erroneous routers), the Linux kernel will by default log
+ this event. These can be disabled by setting
+ throughnet.ipv4.icmp\_ignore\_bogus\_error\_responses to 1.
+
+### Ignore all broadcast message
+
+ All the IP packets that come on the address “255.255.255.255” shall be
+ ignored. This can be done through the iptables rules.
+
+### Disable IPV6
+
+ If there are no plans of using IPV6, it is a good practice to disable
+ this support as it will reduce the size of the kernel TCP/IP stack.
+
+### Enable TCP SYN Cookie Protection
+
+ One way of denial of service (DoS) attack against a service would be
+ to flood the server with SYNrequests (the TCP packet that starts a
+ handshake for a connection). Such a flood can lead to a service
+ disruption as the connection state handling will consume significant
+ resources.
+
+ By enabling net.ipv4.tcp\_syncookies, the Linux kernel will change its
+ handshake behavior when its SYN backlog queue overflows: it replies to
+ SYN requests with the appropriate SYN+ACK reply, but it does not store
+ the connection in its backlog queue.
+
+### Enable Iptables (firewall)
+
+ Iptables is used to set up, maintain, and inspect the tables of IPv4
+ packet filter rules in the Linux kernel. Iptables rules should be set
+ in such a way that it allows packets from authorized peer only.
+
+ Following are the rules recommended until new features are implemented
+ on the STB. The rules are to be in the following sequence as iptables
+ works based on the sequencing of the rules.
+
+ 1\) Allow only incoming UDP/TCP DNS packets only. These rules are only
+ applicable if the device needs to resolve DNS. If the device does not
+ need to resolve DNS then remove these.
```
+ iptables -A INPUT -p udp --sport 53 -j ACCEPT
+ iptables -A INPUT -p udp --dport 53 -j ACCEPT
+ iptables -A INPUT -p tcp --sport 53 -j ACCEPT
+ iptables -A INPUT -p tcp --dport 53 -j ACCEPT
+```
+
+ 2\) Allow only outgoing UDP/TCP DNS only
+
+```
+ Iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
+ iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
+ iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
+ iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
+```
+
+ 3\) Allow output UDP connection only for the audience measurement system
+```
+ iptables -I OUTPUT -p udp –sport 46251 -j ACCEPT
+```
+
+ 4\) Drop all ICMP
+
+```
+ iptables -A INPUT -p ICMP –icmp-type <all> -j DROP
+```
+
+ 5\) Drop all forwarding packet
+
+```
+ iptables -P FORWARD DROP
+```
+
+ 6\) Drop all the TCP connections where SYN flag is unset and state is
+ NEW.
+```
+ iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
+```
+
+ 7\) Drop all the remaining TCP or UDP packets unknown to the STB
+```
+ iptables -A INPUT -j DROP
+ iptables -A OUTPUT -j DROP
+```
+
+ 8\) Drop all broadcast or multicast packets
+
+```
+ iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
+ iptables -A INPUT -m pkttype --pkt-type multicast -j DROP
+```
Validation
==========
-Image Security Analysis Framework (ISAFW)
------------------------------------------
+Hardened System
+---------------
+
+### Image Security Analysis Framework (ISAFW)
+
**meta-security-isafw** is an OE layer that allows enabling the Image
Security Analysis Framework (isafw) for your image builds.