diff options
author | Walt Miner <wminer@linuxfoundation.org> | 2017-05-10 08:43:41 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-05-10 08:43:41 -0500 |
commit | 1a0283b0a4d60fa718fcaba9233d4cf486e67830 (patch) | |
tree | 062136c967cfa1b6b9402428d7a3c83eab593e27 /sec-blueprint | |
parent | 4e9dc8be544e2a107d35860d1a9852e16d60cc03 (diff) | |
parent | 2fbdfb10dd95a9e7568262a32ba17682c323ca1c (diff) |
Merge pull request #28 from hammadahmedirdeto/system_hardening
Adding system hardening guide
Diffstat (limited to 'sec-blueprint')
-rw-r--r-- | sec-blueprint/08-Hardening.md | 716 |
1 files changed, 673 insertions, 43 deletions
diff --git a/sec-blueprint/08-Hardening.md b/sec-blueprint/08-Hardening.md index 8e2b582..a53ead5 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 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 not boot. + +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 not boot + +8. The Stage 2 boot loader will load the successfully verified kernel + 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 @@ -247,17 +424,6 @@ Kernel Hardening ```bash CONFIG_SWAP=n -``` - -### Disable namespace support - - Do not allow namespace support to prevent duplicates of dev nodes, - pids and mount points. - This may be used in virtualization and container solutions like LXC, so in some cases it cannot be disabled. - -```bash - CONFIG_NAMESPACES=n -``` ### Disable NFS file system @@ -365,6 +531,195 @@ 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 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 or completely removed + +#### 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 +728,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 ---------------- @@ -392,7 +830,6 @@ Kernel Hardening | Kernel Configuration | Kernel Version | |---------------------------------------|----------------| -| CONFIG\_CHECKPOINT\_RESTORE=n |3.3+ | | CONFIG\_UNIX\_DIAG=n |3.3+ | | CROSS\_MEMORY\_ATTACH=n |3.5+ | | CONFIG\_PANIC\_ON\_OOPS=y |3.5+ | @@ -400,16 +837,16 @@ Kernel Hardening | CONFIG\_MODULE\_SIG\_FORCE=y |3.7+ | | CONFIG\_PACKET\_DIAG=n |3.7+ | | CONFIG\_FW\_LOADER\_USER\_HELPER=n |3.9+ | -| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ (MIPS) | +| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ | | CONFIG\_USELIB=n |3.15+ | -| BPF\_JIT=n |3.16+ (MIPS) | +| BPF\_JIT=n |3.16+ | | CONFIG\_DEVMEM=n |4.0+ | ### Build with Stack Protection Similar to the stack protector used for ELF programs in user-space, the kernel can protect its internal stacks as well. - This configuration for the MIPS architecture is supported in Linux 3.11 and greater and + This configuration is supported in Linux 3.11 and greater and thus should only be enabled for such versions. This configuration also requires building the kernel with the gcc compiler 4.2 or greater. @@ -516,7 +953,7 @@ Kernel Hardening The BPF JIT can be used to create kernel-payloads from firewall table rules. - This configuration for the MIPS architecture is supported in + This configuration for is supported in Linux 3.16 and greater and thus should only be disabled for such versions. @@ -524,18 +961,6 @@ Kernel Hardening BPF_JIT=n ``` -### Disable checkpoint/restore - - The checkpoint/restore service can take a process, freeze it and - migrate it. - This results in providing more info than a core dump. - This configuration is supported in Linux 3.3 and greater and thus should - only be disabled for such versions. - -```bash - CONFIG_CHECKPOINT_RESTORE=n -``` - ### Enable Enforced Module Signing This configuration is supported in Linux 3.7 and greater and thus @@ -553,7 +978,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 +1005,229 @@ Kernel Hardening /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg output as sensitive. -### SELinux - - 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. +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** + +It is recommended that dynamic linking should 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 | INCLUDE | EXCLUDE | +| Editors (vi) | /bin/vi | 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 | INCLUDE | 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 identity or any +capability. + +If the main application are allowed to execute at any capability, +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 no capability and all persistent resources should be +maintained without any capability. + +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: -```bash - CONFIG_SECURITY_SELINUX_DEVELOP=n - CONFIG_SECURITY_SELINUX_DISABLE=n - CONFIG_SECURITY_SELINUX_BOOTPARAM=n +``` + login + su + ssh + scp + sftp ``` +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. + 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. |