3.4Firmware Level
If an attacker is looking to utilize a simple, and highly
undetectable, sequence of steps, a firmware level rootkit can be
extremely effective. Firmware level rootkits are implemented at
the hardware level, and lay near the bottom of the system stack.
By modifying code directly on the hardware, an attacker can
implement a program of her choosing, while remaining extremely
difficult to detect. Targets of firmware level rootkits include
peripheral hardware, disk controllers, USB keys, processors, and
firmware memory. At this point in time, firmware level rootkits
are mostly theoretical and have only recently been demonstrated
in a fully functional proof of concept. Very limited public
research has been done in this area.
The general concept of firmware rootkits is the idea that firmware
can be modified from the operating system directly. In particular,
BIOS, ACPI, expansion ROMS, and network card PXE systems
can typically be modified by administratively run code. What
makes firmware rootkits interesting is that in many instances,
these firmware devices are executed at boot time, well before the
actual execution of the operating system. This leaves a window of
opportunity for a subversive piece of firmware to hook interrupts
that may be called by the operating system at a later time. For
example, it is possible to hook the int10 interrupt, the video
interrupt, and have the firmware modify program execution based
on the execution of this interrupt. [28]
The network card PXE firmware is another interesting target. This
firmware gets executed prior to the operating system start up to
determine if the host should download and/or boot over a network
connection. Modification of this firmware leaves attack vectors
open including the ability to install, run, and potentially update a
rootkit that is located within this or other pieces of firmware. [28]
Once a rootkit has been installed in a piece of firmware it is very
difficult to remove. Reinstallation of the operating system,
formatting the hard disk, and even physically removing and
installing a new storage mechanism will not result in the removal
of the subversive code. The effected piece of firmware must be
returned to its safe state to ensure the removal of the firmware
rootkit.

[28] Heasman, J. “Firmware Rootkits and the Threat to the
  Enterprise”, Blackhat DC, 2007
    http://www.ngssoftware.com/research/papers/BH-DC-07-
    Heasman.pdf

Adds a TARPIT target to iptables, which captures and holds incoming TCP
connections using no local per-connection resources.  Connections are
accepted, but immediately switched to the persist state (0 byte window), in
which the remote side stops sending data and asks to continue every 60-240
seconds.  Attempts to close the connection are ignored, forcing the remote
side to time out the connection in 12-24 minutes.

This offers similar functionality to LaBrea
<http://www.hackbusters.net/LaBrea/> but doesn't require dedicated hardware
or IPs.  Any TCP port that you would normally DROP or REJECT can instead
become a tarpit.