それマグで！

知識はカップより、マグでゆっくり頂きます。　takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。
トップ > セキュリティ > sslh で ssh / httpsを同時443で使い、しかも接続元IPを維持する

sslh で ssh / httpsを同時443で使い、しかも接続元IPを維持する

セキュリティ sslh ssh https

sslh で443 をポートを共有する

sslh を使うと443 ポートを再利用することができる。

どんなときに使うのか。

公衆無線LANや公民館のLANなど。共用部分の共用インターネット接続でで、平然と443以外のポートを閉じてるWiFiがたくさん存在する。

社内LANと勘違いしてるんじゃないかと思うんだけど。まぁしかたない。53 ポート(DNS)か443ポート(https)を使うしか無い

DNSでVPNは前に試したし、sslhも以前試した、nginx を使う方法も試した。

あれから数年たち、443 ポート以外の利用が厳しい環境が増加しているので、実運用に投入することにした。

全体の接続

sslh を使うと、443ポートで複数のプロトコルで転送ができる。

nginx で作った場合に比べて随分とシンプルになる。

f:id:takuya_1st:20220406010014p:plain

インストール

sudo apt install sslh

設定

debian/ubuntu の場合は、/etc/default/sslh が設定ファイルになる。

transparent を使うのが今回の設定の肝になる。

設定例

# Default options for sslh initscript
# sourced by /etc/init.d/sslh

# binary to use: forked (sslh) or single-thread (sslh-select) version
# systemd users: don't forget to modify /lib/systemd/system/sslh.service
DAEMON=/usr/sbin/sslh

DAEMON_OPTS="--transparent --user sslh --listen 192.168.2.1:443 --ssh 127.0.0.1:8022 --tls 127.0.0.1:443 --pidfile /var/run/sslh/sslh.pid"

細かい設定は、github にあった

有効化と起動

sudo systemctl enable  sslh.service
sudo systemctl start sslh.service

設定したら起動して接続テストする。

既存のnginx443 はどうするのか

既存のnginx の443 は、127.0.0.1:443 へ退避するか、eth0 に複数のIPアドレスを割り当ててそちらを使うようにする。

nginx で ip 指定でリッスンする
server {
   listen 127.0.0.1:443 ssl https;
}
apache で ip 指定でリッスンする
<Virtuahost>
<IfModule ssl_module>
    Listen 127.0.0.1:443
</IfModule>

複数のIPを１つのNICに割り当て

 ip addr add ...

または

iface br0:0 inet static
  address 192.168.101.5/24
  gateway 192.168.101.1
iface br0:1 inet static
    address 192.168.101.9/24

複数割当については過去記事に→debianで br0 にIPアドレスを２つ割り当てる。

transparent の問題

transparent はiptablesの設定とバッティングしたり、初期設定のままでは動くが、既存設定と競合して動かないことがあるので十分に注意する。

対策はgitレポジトリに掲載されていた→ Transparent Proxy

問題点 の解決：接続元IPが解決

--transparent を使うことで、ソースIPはそのまま通信ができる。

nginx や apache も ssh もちゃんと接続元IPは維持されて接続される。

問題点 プロトコル

プロトコル自体をいじってないので、プロトコルを見てロックされることがある。SSLでないと通さないとかはよくあると思う。

その場合HTTPS_PROXYでCONNECTでSSLしてプロトコルを見せない方法もある。

 ssh USER@FINAL_DEST -o "ProxyCommand=nc -X connect -x PROXYHOST:PROXYPORT %h %p"

この場合。ProxyCommand nc -X connect -x proxy.example.com:8080 %h %pの接続が最初に走るので、HTTPSのCONNECTになる。

まぁHTTPSのCONNECTも制限されてたらどうしようもないんだけど。

PROXY CONNECT を使ってHTTPSを転送するときに仕掛けることは可能だと思う。

その場合は、Softetherが最終手段になるかもしれない。

その他の方法。

22番が使えずに、443番でなんとか頑張る方法は他にもある。

ブラウザ中でリモートデスクトップを起動したり、仮想マシンに接続したり、ブラウザでターミナルに接続・・・etc そのような方法で443ポートを通して別サーバーのシェルにログインして作業は工夫すれば可能である。

  • sslh
  • nginx ssl_preread
  • shell in a box
  • portainer
  • cockpit
  • vscode on web

など、代替手段が山程存在する。

最近だと、vs code をサーバーにインストしておけば、好きな場所からHTTPS経由でVs Code使って便利に使える。

接続制限する方も大変だろう。ipv6で接続制限も大変だ。v6時代になっているのに、ポート制限はなくならないってのはしんどいねぇ。

OpenVPNやWireguardにSoftetherなどVPN技術もSSL-VPNも進歩してるし、大変だけど。みんな裏口つくるの楽しそうですよね

コロナ禍が落ち着いて、近所のイオンのフードコードで作業しようと思って無線LANのポートが制限かかってて、イラッとなって、コロナ禍が落ち着いたのでホテルに宿泊してインターネットを楽しんでいたら443ポート以外が閉じられいた。これらを回避するために、sslhを使うことにした。

テザリングでも、携帯電話キャリアによっては443以外のポートのシェービングや優先度を落としたり、切断したりしますからね。契約書類に書いてないことをされるのは本当に怖い。