タグ: ssh

sshuttle がエラーになる

matoken コメントをする

SSH VPN がお手軽に利用できる sshuttle を久々に使おうとしたら失敗します．いくつかのremotehostを試してもうまくいかない．

Debian sid 環境でのエラー

$ sshuttle -v -r user@remotehost 0/0
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.7.4
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: False
User enabled: False
TCP redirector listening on ('127.0.0.1', 12300).
Starting client with Python version 3.7.4
c : connecting to server...
Host key fingerprint is SHA256:kUoWT4bCu7+HiegN9R5tYqO5nnvpQPobzSk46T8WEwU
+---[ECDSA 256]---+
|   .E...o        |
|    o o= .       |
|     +o +        |
|    oo . .       |
|    oo. S        |
|   *++ o         |
|  *.+=X+o        |
| ..=+X*=.        |
| .o+%B+o         |
+----[SHA256]-----+
Enter passphrase for key '/home/matoken/.ssh/id_ed25519':
Authenticated to nnn.nnn.nnn.nnn ([nnn.nnn.nnn.nnn]:nn).
-c:3: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
Starting server with Python version 3.7.3
 s: latency control setting = True
c : Connected.
 s: auto-nets:False
firewall manager: setting up.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42
firewall manager: undoing changes.
>> iptables -t nat -D OUTPUT -j sshuttle-12300
>> iptables -t nat -D PREROUTING -j sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -X sshuttle-12300
c : fatal: server died with error code 255

最後の行のエラーメッセージで検索すると以下のIssue を見つけました．

参考にして -x remotehostip で使えるようになりました．-x は除外オプションで接続先のip を指定して除外するとOKのようです．

  • NG $ sshuttle -r user@remotehost 0/0

  • OK $ sshuttle -r user@remotehost 0/0 -x remotehostip

VPN 対象のサブネットと同様 -x にも複数のサブネット/ip の指定ができます．

Debian sid 環境
$ dpkg-query -W sshuttle
sshuttle        0.78.5-1
$ hostnamectl|grep -E 'Operating System|Architecture'
  Operating System: Debian GNU/Linux bullseye/sid
	  Architecture: x86-64

Raspbian Buster 環境でのエラー

ちなみに sshuttle を Raspbian Buster で試すとまた違うこんなエラーに．でもやっぱり -x で解決しました．

Raspbian Buster での error message
 :
client: Connected.
packet_write_wait: Connection to 192.168.1.102 port 22: Broken pipe
Traceback (most recent call last):
  File "/usr/bin/sshuttle", line 11, in <module>
	load_entry_point('sshuttle==0.78.5', 'console_scripts', 'sshuttle')()
  File "/usr/lib/python3/dist-packages/sshuttle/cmdline.py", line 82, in main
	opt.sudo_pythonpath)
  File "/usr/lib/python3/dist-packages/sshuttle/client.py", line 787, in main
	seed_hosts, auto_hosts, auto_nets, daemon, to_nameserver)
  File "/usr/lib/python3/dist-packages/sshuttle/client.py", line 547, in _main
	ssnet.runonce(handlers, mux)
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 598, in runonce
	h.callback(s)
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 488, in callback
	self.flush()
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 439, in flush
	wrote = _nb_clean(os.write, self.wsock.fileno(), self.outbuf[0])
  File "/usr/lib/python3/dist-packages/sshuttle/ssnet.py", line 79, in _nb_clean
	return func(*args)
BrokenPipeError: [Errno 32] Broken pipe
Raspbian Buster の環境
$ dpkg-query -W sshuttle
sshuttle        0.78.5-1
$ lsb_release -d
Description:    Raspbian GNU/Linux 10 (buster)
$ uname -m
armv6l
$ cat /proc/device-tree/model ;echo
Raspberry Pi Model B Rev 2

Ubuntu 18.04 LTS 環境(OK)

Ubuntu 18.04 LTS のsshuttle でも試してみましたがこれは -x を付けなくても問題なしでした．sshuttle 0.78.4 〜 0.78.5 の間の修正での影響でしょうか?

error の出なかった環境
$ dpkg-query -W sshuttle
sshuttle        0.78.3-1ubuntu1
$ lsb_release -d
Description:    Ubuntu 18.04.2 LTS
$ uname -m
x86_64

Endlessh を使って ssh 接続をとてもゆっくりと処理して攻撃者に嫌がらせをする

matoken コメントをする

ssh は攻撃が多いです．公開鍵認証にしておくと大分侵入に強くなりますがインターネットに直接繋がっているサーバでは攻撃はとても多いです．

Endlessh はsshd の代わりに起動してバージョン情報を送る前のデータにほぼランダムな文字列をゆっくりと配信し続けて攻撃者の足止めをするプログラムのようです．
本当の sshd は別ポートで起動してそっちを使う感じでしょうか．22番を無くして port knocking や sslh を使うなどのほうがいいかもですが面白そうです．

ということで手元で少し試してみました．

導入とビルド
$ git clone https://github.com/skeeto/endlessh
$ cd endlessh
$ git log |head -1
commit 548a7b1521b2912e7e133d0d9df50e0e514f1f2c
$ make
port 22222 で起動
$ ./endlessh -v -p22222 &
[1] 22698
2019-03-24T04:56:10.338Z Port 22222
2019-03-24T04:56:10.338Z Delay 10000
2019-03-24T04:56:10.338Z MaxLineLength 32
2019-03-24T04:56:10.338Z MaxClients 4096
ssh 接続してみると700分ほど捕まえていた
$ time ssh localhost -p 22222
2019-03-24T04:56:19.510Z ACCEPT host=::1 port=59402 fd=4 n=1/4096
ssh_exchange_identification: No banner received

real    700m30.650s
user    0m0.040s
sys     0m0.240s
2019-03-24T16:37:00.162Z CLOSE host=::1 port=59402 fd=4 time=42040.652 bytes=73944
終了
$ kill %1
[1]+  Done                    ./endlessh -v -p22222

数回試しましたが，標準オプションでは700分前後捕まりました．単にありもののscriptを動かすレベルの攻撃者であればツールが対応するまでは妨害になりそうです．

環境
$ git log |head -1
commit 548a7b1521b2912e7e133d0d9df50e0e514f1f2c
$ dpkg-query -W openssh-client
openssh-client  1:7.9p1-9
$ lsb_release -dr
Description:    Debian GNU/Linux buster/sid
Release:        unstable
$ uname -m
x86_64

ssh環境での誤ったシステム停止を防ぐmolly-guard

matoken コメントをする

最近 shutdown の man を見比べたりしてたのですが，そのときに systemd, sysvinit 以外に molly-guard という見知らぬものが．

$ apt-file search /sbin/shutdown
molly-guard: /sbin/shutdown
systemd-sysv: /sbin/shutdown
sysvinit-core: /sbin/shutdown

パッケージ情報をみると shutdown コマンドなどを置き換えて ssh 接続時には確認のためにホスト名を聞くようになるようです．
これにより手元のPCの再起動をしたつもりがリモートのサーバを再起動してしまうなどといったことが防げるようになります．

$ apt show molly-guard
Package: molly-guard
Version: 0.6.4
Priority: extra
Section: admin
Maintainer: Francois Marier <francois@debian.org>
Installed-Size: 57.3 kB
Depends: procps
Enhances: init, kexec-tools, mosh, openssh-server, pm-utils, systemd, sysvinit, upstart
Tag: implemented-in::shell, interface::commandline, network::server,
 protocol::ssh, role::program, scope::utility
Download-Size: 13.8 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.jp.debian.org/debian stretch/main amd64 Packages
Description: protects machines from accidental shutdowns/reboots
 The package installs a shell script that overrides the existing
 shutdown/reboot/halt/poweroff/coldreboot/pm-hibernate/pm-suspend* commands
 and first runs a set of scripts, which all have to exit successfully,
 before molly-guard invokes the real command.
 .
 One of the scripts checks for existing SSH sessions. If any of the four
 commands are called interactively over an SSH session, the shell script
 prompts you to enter the name of the host you wish to shut down. This should
 adequately prevent you from accidental shutdowns and reboots.
 .
 molly-guard diverts the real binaries to /lib/molly-guard/.  You can bypass
 molly-guard by running those binaries directly.

早速試してみます．

$ sudo apt install molly-guard
    :
package diverts others to: /lib/molly-guard/coldreboot
/sbin/halt
package diverts others to: /lib/molly-guard/halt
/sbin/pm-hibernate
/sbin/pm-suspend
/sbin/pm-suspend-hybrid
/sbin/poweroff
package diverts others to: /lib/molly-guard/poweroff
/sbin/reboot
package diverts others to: /lib/molly-guard/reboot
/sbin/shutdown
package diverts others to: /lib/molly-guard/shutdown

このあたりのコマンドが置き換わっています．

$ ls -l /sbin | grep molly
lrwxrwxrwx 1 root root        28 Aug 16  2016 coldreboot -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 halt -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 pm-hibernate -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 pm-suspend -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 pm-suspend-hybrid -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 poweroff -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 reboot -> /lib/molly-guard/molly-guard
lrwxrwxrwx 1 root root        28 Aug 16  2016 shutdown -> /lib/molly-guard/molly-guard

コマンド類は /lib/molly-guard 以下に退避されるようです．

sysvinit
$ ls -lA /lib/molly-guard
total 48
-rwxr-xr-x 1 root root 18952 Feb 13  2017 halt
-rwxr-xr-x 1 root root  2767 Aug 16  2016 molly-guard
lrwxrwxrwx 1 root root     4 Feb 13  2017 poweroff -> halt
lrwxrwxrwx 1 root root     4 Feb 13  2017 reboot -> halt
-rwxr-xr-x 1 root root 23368 Feb 13  2017 shutdown
systemd
$ ls -lA /lib/molly-guard
total 4
lrwxrwxrwx 1 root root   14 Jun 14 05:20 halt -> /bin/systemctl
-rwxr-xr-x 1 root root 2767 Aug 16  2016 molly-guard
lrwxrwxrwx 1 root root   14 Jun 14 05:20 poweroff -> /bin/systemctl
lrwxrwxrwx 1 root root   14 Jun 14 05:20 reboot -> /bin/systemctl
lrwxrwxrwx 1 root root   14 Jun 14 05:20 shutdown -> /bin/systemctl

ssh 経由で shutdown(sysvinit) を試みるとこのように hostname を求められます．ここで誤った hostname を書くと shutdown がキャンセルされました．

$ sudo shutdown -f -P -h +10 "kernel update (`uname -r`)"
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: desktop
Good thing I asked; I won't shutdown debian ...
W: aborting shutdown due to 30-query-hostname exiting with code 1.

正しい hostname を指定すると shutdown が呼ばれます．

$ sudo shutdown -f -P -h +10 "kernel update (`uname -r`)"
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: debian

Broadcast message from root@debian (pts/0) (Thu Sep 27 06:15:28 2018):

kernel update (4.9.0-3-amd64)
The system is going DOWN for system halt in 10 minutes!
^C
Shutdown cancelled.

ssh経由でない場合は molly-guard はすぐに shutdown を呼びます．

$ sudo shutdown -f -P -h +10 'poweroff'
^C
Shutdown cancelled.

環境

$ dpkg-query -W systemd-sysv molly-guard
molly-guard     0.6.4
systemd-sysv    232-25+deb9u4
$ dpkg-query -W sysvinit-core
sysvinit-core   2.88dsf-59.9
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ cat /etc/debian_version
9.5
$ uname -m
x86_64

Windows10標準のsshの鍵はレジストリに保存されているらしい

matoken コメントをする

[janog:14329] より．

Windows 10標準のssh-keygenで鍵を作ると標準で %HOMEPATH%/.ssh で鍵が管理されるようだけどここから消した鍵が再起動後も使えてしまうという話からはじまっている．

HKCU\Software\OpenSSH\Agent\Keys 以下に保存されているらしい．

以下のscriptでレジストリ内の鍵が取り出せるよう．

今環境がないけどなんか嵌りそうだし今度試してみよう．