SiteGuardでnextcloudのクライアントソフトからの通信を許可する。
そんなこんなで苦労してnginx版SiteGuardをインストールしたわけですが、インストール後は割とすんなり設定が進み無事に悪意のある通信がブロックされる状況になりました。
・・・が、よく見てみるとnextcloudのクライアントの同期がダウンしている。
仕事でFortiwebやBig-IPのWAFを触っていた経験からなんとなく予想していたが、WEBDAVの通信がシグネチャによってブロックされている状況。
ということで、nextcloudのサイトについてはWEBDAVの通信を許可するためにシグネチャの例外設定を行ったのだが効果無し。
SiteGuardの不備を疑いホストURLによる全許可（セーフ設定）を入れてみるとこれは有効になる。また、PROPFINDメソッドに対して当該シグネチャを除外する設定も有効となる。
しかし、ホストURL＋シグネチャの組み合わせの除外設定はどうあっても動かない。
一時はシグネチャ自体を無効化することも考えたのですが、他のサイトに対する防御が落ちるのは納得がいかない。
そこで、打開策は無いかとマニュアルを見ていたところ、Siteguradのシグネチャ除外の設定はnginxのlocationディレクティブ内で設定することが可能ということが判明。
そこで、nextcloud用nginxコンフィグの"locatioon /"内にシグネチャ除外の設定を追加してnginxを再起動するもブロック状態が継続。
更に設定見直し、PHPファイルに対する処理を設定している”location ~ .php(?:$|/)”内に設定を追加することで漸く思っていたとおりの動作となった。
さて、なんでこんなことになったのか検討したのだが、よくよくリクエストURIをみてみると、
http://ホスト名/remote.php/dav/files/＜nextcloudのアカウント名＞/となっている事に気付く。
ここで注意すべきはremote.phpというファイル名にさらにパスが続いてる構造。
多分これはWAF的にかなりイレギュラーな構造で、URIを条件にすると正しく判定されないのではないかと思われる。
一方でPHPファイルに対するlocationディレクティブ内では設定が有効になるのはこのlocation内の設定がPHPファイルにアクセスしたときにトリガーされるためと思われる。
ともあれ、まずは無事に設定が完了したのでこれで後はどのくらいの検知率になるかをみていきたい。