はじめに
実際のところ、サイト側で何をやっても不正なアクセス自体は減らない。
例えば、ファイヤーウォールなどでブロックしても、目につかなくなってるだけで不正なアクセスは発生したままだろう。
とりあえず目につかなくなれば、それで良いってことで。
ここに書いてあることは「正解」ではない。
「このような考え方もある」という程度に捉えて欲しい。
万能薬はないので、「状況に応じて適切にアレンジする」という姿勢が必要だろう。
SSH
サーバーがあれば、たぶんメンテナンス用にSSH/22も開放してると思う。
しかし、SSH/22はアクセスが多い。
ログを確認してみると、自分以外の不正アクセスが多いことに気づくだろう。
それが少ないなら、かなりラッキーだ。
不正アクセスを減らしたいと思った場合、自分の経験では、ポートを変えてしまうのが効果的だった。
見慣れないポートに変えたら一気にアクセスが減った。というかゼロになった。
どうも、SSHに不正アクセスする側はポート22しか狙わない場合が多いようだ。
脆弱性のあるページを探ってるアクセス
phpMyAdminやWordPressの管理画面がインストールされてそうなURLを探るようにアクセスしてくる人たちがいる。
それらを採用してなければ、それらの脆弱性に起因する問題は発生しない。
しかし、なんかウザイわけだ。
そう思ってアクセスを減らしたいと思った場合、自分の経験では、HTTP側を閉じてしまうのが効果的だった。
どうも、探るようなアクセスをする人たちの中には、HTTP側だけにアクセスする人たちがいる。
そして、常時SSL化が普及してきた昨今、HTTP側を開放しておくメリットがどこまであるだろうか?
選択肢の一つとして頭の片隅に置いといても良いと思う。
フォームがあるページが心配
あれこれ対策したとしても、フォームがあるページは、ちょっと心配だ。
だから、ログは確認したほうがいい。
不正なアクセスがなければ幸せだ。追加の対策は必要ないかもしれない。
でも、それは悪意のある誰かに見つかっちゃったら状況が変わるかもしれない。
見つかりにくくするには、自分では3つのネタを採用してる。
<form>を使わない。
それがあるから、そこにフォームがあるって判断できちゃうわけで、なければ良いのではないか? という発想だ。
<form>がなくても、ボタンのclickイベントを拾ってPOSTすれば問題ない。
ボタンに<input>とか<button>を使わない。
それがあるから(略)
clickイベントを拾ってPOSTするなら、<input>とか<button>じゃなくてもいいよね?
ボタンだけじゃなく、他のモノも排除できたら完璧かもしれない。
最初のGETに対してHTMLの枠組みと基礎的なJavaScriptだけ返し、そのJavaScriptからページ本体をリクエストさせる構成にする。
そうすると、フォームを探るようなアクセスでJavaScriptが処理されないなら、ページ本体が届かない。
届かないなら見つからないよね? という発想だ。
どうも、何かを探るようなアクセスではJavaScriptが処理されてる場合は少ないようだ。
現状、フォームのあるページに対する不正と思えるアクセスは皆無なので、何も考えずに3つをやっておけば良いと考えてる。
見つかりにくくするのとは違うけど、もうひとつネタがある。
POSTリクエストの遷移の正当性を確認することだ。
フォームのページをGETされたとき、サーバー側にデータを保存する。
同じものを出力するHTMLにも含めておき、POST時に送信させる。
POSTされたとき、それとサーバー側のデータを比較する。
一致してなければPOSTを信用できないので、処理する必要はない。