mirror of
git://git.code.sf.net/p/xtables-addons/xtables-addons
synced 2025-09-07 13:15:12 +02:00
94ecf3847b
I want to be able to use SYSRQ to reboot, crash or partially diagnose machines that become unresponsive for one reason or another. These machines, typically, are blades or rack mounted machines that do not have a PS/2 connection for a keyboard and the old method of wheeling round a "crash trolley" that has a monitor and a keyboard on it no longer works: USB keyboards rarely, if ever, work because by the time the machine is responding only to a ping, udev is incapable of setting up a new keyboard. This patch extends the xt_SYSRQ module to avoid both disclosing the sysrq password and preventing replay. This is done by changing the request packet from the simple "<key><password>" to a slightly more complex "<key>,<seqno>,<salt>,<hash>". The hash is the sha1 checksum of "<key>,<seqno>,<salt>,<password>". A request can be constructed in a small shell script (see manpage). Verification of the hash in xt_SYSRQ follows much the same process. The sequence number, seqno, is initialised to the current time (in seconds) when the xt_SYSRQ module is loaded and is updated each time a valid request is received. A request with a sequence number less than the current sequence number or a wrong hash is silently ignored. (Using the time for the sequence number assumes (requires) that time doesn't go backwards on a reboot and that the requester and victim have reasonably synchronized clocks.) The random salt is there to prevent pre-computed dictionary attacks difficult: dictionary attacks are still feasible if you capture a packet because the hash is computed quickly -- taking perhaps several milliseconds to compute a more complex hash in xt_SYSRQ when the machine is unresponsive is probably not the best thing you could do. However, cracking, say, a random 32 character password would take some time and is probably beyond what the people in the target untrustworthy environment are prepared to do or have the resources for. It almost goes without saying that no two victim machines should use the same password. Finally, the module allocates all the resources it need at module initialisation time on the assumption that if things are going badly resource allocation is going to be troublesome.
Xtables-addons ============== Xtables-addons is the proclaimed successor to patch-o-matic(-ng). It contains extensions that were not accepted in the main Xtables package. Xtables-addons is different from patch-o-matic in that you do not have to patch or recompile either kernel or Xtables(iptables). But please see the INSTALL file for the minimum requirements of this package. All code imported from patch-o-matic has been reviewed and all apparent bugs like binary stability across multiarches, missing sanity checks and incorrect endianess handling have been fixed, simplified, and sped up. Inclusion into a kernel tree ============================ External extensions =================== The program "xa-download-more" can be used to download more extensions from 3rd parties into the source tree. The URLs are listed in the "sources" file. If the "sources" file contains an entry like http://foobar.org/xa/ xa-download-more will inspect http://foobar.org/xa/xa-index.txt for files to download. That file may contain foobar.tar.bz2 and xa-download-more will then retrieve and unpack http://foobar.org/xa/foobar.tar.bz2. Files that should be contained in the tarball are an mconfig and Kbuild files to control building the extension, libxt_foobar.c for the userspace extension and xt_foobar.c for the kernel extension. mconfig.foobar extensions/Kbuild.foobar extensions/Mbuild.foobar extensions/libxt_foobar.c extensions/libxt_foobar.man extensions/xt_foobar.c extensions/xt_foobar.h