mirror of
git://git.code.sf.net/p/xtables-addons/xtables-addons
synced 2025-09-07 21:25: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.
81 lines
3.5 KiB
Groff
81 lines
3.5 KiB
Groff
The SYSRQ target allows to remotely trigger sysrq on the local machine over the
|
|
network. This can be useful when vital parts of the machine hang, for example
|
|
an oops in a filesystem causing locks to be not released and processes to get
|
|
stuck as a result - if still possible, use /proc/sysrq-trigger. Even when
|
|
processes are stuck, interrupts are likely to be still processed, and as such,
|
|
sysrq can be triggered through incoming network packets.
|
|
.PP
|
|
The xt_SYSRQ implementation uses a salted hash and a sequence number to prevent
|
|
network sniffers from either guessing the password or replaying earlier
|
|
requests. The initial sequence number comes from the time of day so you will
|
|
have a small window of vulnerability should time go backwards at a reboot.
|
|
However, the file /sys/module/xt_SYSREQ/seqno can be used to both query and
|
|
update the current sequence number. Also, you should limit as to who can issue
|
|
commands using \fB-s\fP and/or \fB-m mac\fP, and also that the destination is
|
|
correct using \fB-d\fP (to protect against potential broadcast packets), noting
|
|
that it is still short of MAC/IP spoofing:
|
|
.IP
|
|
-A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7
|
|
-p udp --dport 9 -j SYSRQ
|
|
.IP
|
|
(with IPsec) -A INPUT -s 10.10.25.1 -d 10.10.25.7 -m policy --dir in --pol
|
|
ipsec --proto esp --tunnel-src 10.10.25.1 --tunnel-dst 10.10.25.7
|
|
-p udp --dport 9 -j SYSRQ
|
|
.PP
|
|
You should also limit the rate at which connections can be received to limit
|
|
the CPU time taken by illegal requests, for example:
|
|
.IP
|
|
-A INPUT 0s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7
|
|
-p udp --dport 9 -m limit --limit 5/minute -j SYSRQ
|
|
.PP
|
|
This extension does not take any options. The \fB-p udp\fP options are
|
|
required.
|
|
.PP
|
|
The SYSRQ password can be changed through
|
|
/sys/module/xt_SYSRQ/parameters/password, for example:
|
|
.IP
|
|
echo -n "password" >/sys/module/xt_SYSRQ/parameters/password
|
|
.PP
|
|
Alternatively, the password may be specified at modprobe time, but this is
|
|
insecure as people can possible see it through ps(1). You can use an option
|
|
line in e.g. /etc/modprobe.d/xt_sysrq if it is properly guarded, that is, only
|
|
readable by root.
|
|
.IP
|
|
options xt_SYSRQ password=cookies
|
|
.PP
|
|
The hash algorithm can also be specified as a module option, for example, to
|
|
use SHA-256 instead of the default SHA-1:
|
|
.IP
|
|
options xt_SYSRQ hash=sha256
|
|
.PP
|
|
The xt_SYSRQ module is normally silent unless a successful request is received,
|
|
but the \fIdebug\fP module parameter can be used to find exactly why a
|
|
seemingly correct request is not being processed.
|
|
.PP
|
|
To trigger SYSRQ from a remote host, just use netcat or socat:
|
|
.PP
|
|
.nf
|
|
sysrq_key="s" # the SysRq key(s)
|
|
password="password"
|
|
seqno="$(date +%s)"
|
|
salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null |
|
|
openssl enc -base64)"
|
|
req="$sysrq_key,$seqno,$salt"
|
|
req="$req,$(echo -n "$req,$password" | sha1sum | cut -c1-40)"
|
|
|
|
echo "$req" | socat stdin udp-sendto:10.10.25.7:9
|
|
# or
|
|
echo "$req" | netcat -uw1 10.10.25.7 9
|
|
.fi
|
|
.PP
|
|
See the Linux docs for possible sysrq keys. Important ones are: re(b)oot,
|
|
power(o)ff, (s)ync filesystems, (u)mount and remount readonly. More than one
|
|
sysrq key can be used at once, but bear in mind that, for example, a sync may
|
|
not complete before a subsequent reboot or poweroff.
|
|
.PP
|
|
The hashing scheme should be enough to prevent mis-use of SYSRQ in many
|
|
environments, but it is not perfect: take reasonable precautions to
|
|
protect your machines. Most importantly ensure that each machine has a
|
|
different password; there is scant protection for a SYSRQ packet being
|
|
applied to a machine that happens to have the same password.
|