diff options
author | Hammad Ahmed <hammad.ahmed@irdeto.com> | 2016-12-13 17:08:41 -0800 |
---|---|---|
committer | Hammad Ahmed <hammad.ahmed@irdeto.com> | 2016-12-21 08:46:07 -0500 |
commit | 3fb9e563844d183d1909263394068d9d59c3d7a6 (patch) | |
tree | 317d08313581142f74387b21ef76d283a6e528d5 /sec-blueprint | |
parent | 5d0f0e61aea7e89589b6a0c1280a99b18646eb11 (diff) |
Adding system hardening guide
Diffstat (limited to 'sec-blueprint')
-rw-r--r-- | sec-blueprint/08-Hardening.md | 769 |
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=”<*insert kernel command line here*>” + 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=<interface> 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. |