QNAPでGitlabを立てていたが、諸事情で普通のインスタンスで立てることに。
以前、こんなブログを書いていたので楽勝。
とおもっていたが、そんなことはなかったと言う話。
QNAPで案内される、gitlabのdocker-compose.ymlのベースはこれ。何気にちゃんとメンテナンスされている。セキュリティアップデートも早い。
https://github.com/sameersbn/docker-gitlab
docker-compose.ymlは、これ。
https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
必要なパラメーターをいじって終わり。少なくとも、GITLAB_HOST=localhostは変更したほうがいい。といわけで完了。
というわけではなく、一箇所だけ書き換える場所がある。ポートを10080からまともなポートに変更する。10080だって問題ないはずだが、そのまま動かすとこの問題にあたる。
https://chromestatus.com/feature/6510270304223232
この記事によると以下もダメなんですね。
https://www.zdnet.com/article/google-deploys-new-chrome-mitigations-against-new-nat-slipstreaming-attack/
69, 137, 161, 1719, 1723, 6566, and 10080. しかし、あくまでもブラウザでの話。(http://hoghoge:XXXXX)
ちなみに、アサインされているポートは以下。あくまでもブラウザにアクセスさせるポートなので、これらがやばいわけではない。また、1024以下は、well knownポートなので、管理者以外はアサインすべきではなく、ユーザアプリに故意で指定する人もいないはず。
69 TFTP
137 netbios-ns
161 snmp
1719 h323gatestat
1723 pptp
10080 Amanda
NATスリップストリームアタックの防御でブラウザからの10080の利用ができなくなっている。。。知らんかった。ジェットストリームアタックは知っている世代なんだが。
この設定を変えないと、ブラウザでアクセスしてもブランクページに遷移する。パケットキャプチャーをしても、パケット情報が出ず。ローカルホストでlynxでアクセスするとちゃんとアクセスができる。最初Dockerのネットワーク周りを疑ってしまったが。。。NATストリームアタック抑止でブラウザが拒否しているのは納得。
というわけで、QNAPで指定していた12080に変更して完了。
日曜日フルフル使ってしまった。
