【アクセス拒否】.htaccessでサイトアクセス制限:敵を「未然に」防ぐ | Raven's Articles

【アクセス拒否】.htaccessでサイトアクセス制限:敵を「未然に」防ぐ

この記事にはPRとスポンサーリンクが含まれます!

この記事の概要を簡単まとめ!

  • サイトは自分で鯖立てかレンタルサーバーやホスティングサービスで運営する
  • インターネットは内実無法地帯、攻撃者は常に破壊を求める
  • 無対策であれば確実に何らかの被害を被る
  • 初歩的なアクセス制限を行う設定ファイル、Apache系は”.htaccess”がある
  • .htaccessで使える正規表現、覚えるのは大変だが様々な設定ができる
  • 各ファイルに対してはファイル単位でアクセス制限可能
  • リファラ・ユーザーエージェントやIPアドレス単位でも許可と拒否を設定できる
  • 実はroot以外にも置ける.htaccess, ディレクトリ単位でセットできる
  • .htaccessが分かれば、クラッキングの大半をカバーできる

ブラウザを使ってどこかのサイトにアクセスする際、htmlやcssを呼び出して静的なページを表示する、或いはphpによる動的なページを表示するということはもはや当たり前のこととなった。だがそれらのページを呼び出すには当然のことながらそのファイルが存在しなければ不可能であり、さらにはその前提として他のPCやスマホからのアクセスを受けるために「サーバー」として何らかのサーバー向けOSをインストールしておき、外部からのアクセスが可能になるようにしておかなければならない。

その際、アクセス制御を行うファイルがサーバーのrootに自動で用意されるものである。これはそのサーバーがどういう用途であるかによらず必ず設置される。しかし特別な事情がないならそのファイルは特に編集する必要は全くなく、多くの人はこれに触ることなくサーバー運営している。普通に運用すれば、特別な事情はまず発生することがないためだ。

しかしインターネットの世界は無法地帯というべき状況、普通に運用していても特別な事情に遭遇する確率が高すぎる。所謂「クラッカー」によるサイト(サーバー)への攻撃、ダウンを目的とする(D)DoS攻撃、不正アクセス等、挙げればきりのない程あらゆる手段で妨害してくるわけだ。その妨害からサイトやサーバーを守る基本的なファイルが”.htaccess”である。このファイルに拒否・許可設定を記述してHTTPサーバーのrootに配置することで、99%はそれらの攻撃からの対策が可能になるのである。嫌われ者である私は多方面から攻撃を受けることも多く、その結果身に付けたのがそれだ。今回はそのことについて書いていく。

ブンブンハローサーバーのディレクトリ単位のWebサーバー設定ファイル、どうもKIBEKINです。

無法地帯インターネットとサーバー

サイト運営とサーバー

PCやスマホをインターネットに接続し、Google ChromeやSafariなどのブラウザを開き、何らかサイトへアクセスする。大抵のページは拡張子が.htmlや.phpとなっていて、見た目にはページに見えるそれの実体は、そのファイルへアクセスし、そこに記述されている内容を表示しているということになる。したがって、殆どの場合はサイトアクセス=ファイルアクセスとなる。

ところでファイルにアクセスするには、ストレージにそれがなくてはならない。そのファイルにアクセスするのは、殆どが外部、つまりストレージが存在するPCの外のデバイスからである。そのため、外からのアクセスが可能なよう、OSも一般用途のOSではなくサーバー機能が存在するOSが必要になる。Windows系のOSではWindows Serverも存在するがサーバーOSの多くはLinux系であり、有名どころではビジネス向け有償OSのRed Hat Enterprise Linux, そこから商用パッケージを取り除いたCentOS, 他に無償のOSはDebian, Debianから派生したUbuntu Serverなどがあり、他にも多数のサーバーOSが存在する。



ただし、サーバーは通常企業で運用するものである。或いは大学の研究のために建てられることもある。要求されるスペックは個人や企業が業務で使用するものとは違い、同時に多数のアクセスに対応できるようマルチスレッドのCPUを使用することが前提で、かつアクセス(=ファイル呼び出しのリクエスト)に迅速に応答するための回線速度が必要になる。RAMは一応16GBあれば問題なく、GPUについてはゲームをするわけではないので原則不要である。最低限、コマンドラインを表示するためのものがあれば良いので、解像度もそこまで必要ない。

とはいえサーバーは通常、メンテナンス作業などで一時的にダウンさせる以外には24時間365日稼働し続けるのが当たり前である。つまり電源はいつ何時入れっぱなしとなる。また、不測の事態、特に自然災害や停電が発生しても維持できるようにしなければならない。そのためには無停電電源装置が必要だが、非常に大型の機械となるそれを一般家庭が導入するなど到底不可能な話である。したがって、サーバーは基本的には企業・学校レベルで運用するものであり、個人で運用することは殆どないと言ってもいいだろう。建てるとすれば、実験用や業務のテスト版というレベルで使うことになるであろう。

インターネットは内実無法地帯、攻撃者は常に破壊を求める

インターネットは生活を便利にしたが、その裏で破壊と犯罪のために使用されている。これはインターネットに限らずどの技術でも正しい方向に使うものがいれば悪い方向に使う者がいるが、インターネットに関してはそれが顕著である。それが一般に言われるクラッカー、日本語で言う「攻撃者」である。ハッカーとも言われるがそれは意味的にはホワイトハッカーの略であり、破壊を目的とする攻撃的意図を持って利用する者はクラッカーとして区別している。

そのクラッカーが行う破壊工作は多岐にわたるが、総じて「ハッキング」という言葉で表される。ここでは何らかの手段でもってシステムやデータを破壊するものであると考えてもらって構わない。その方法で最も簡単なものを挙げるとすれば、個人情報や機密情報についてガバガバな管理者を狙った、ID・パスワードの取得による不正アクセスで内部から破壊することだ。私が知る限り、一番楽に破壊できる方法であると思われる。その他の方法としては、ブルートフォースアタック(総当たり攻撃)、(D)DoS攻撃などが様々なサイトに対して行われている。

知っての通り私は世界的嫌われ者ながらブログ運営に向いたソフトウェアであるWordPressを使用している。世界的に使用されているソフトウェアであるため、様々なプラグインやカスタマイズ方法がある反面で、一部存在する脆弱性を狙った攻撃はずっと多い。またWordPressは記事内容をデータベースに収録しており、システムとしてはMySQLが利用されている。その脆弱性を狙った攻撃、所謂SQLインジェクションがその代表例である。他にもクロスサイトスクリプティング、コードインジェクション、ディレクトリトラバーサルといったものが挙げられ、これらも何らかの損害を与えることを目的とした攻撃の1つである。

しかもこれらの攻撃については、サーバー運営者(管理者)が起きている時に来るとは限らないのが問題である。24時間365日、寧ろ管理者が離れている時に狙われやすいものである。そうして管理者が気付いたら酷い有様、それこそ復元できない状態にして完全に破壊するか、或いはデータだけは別で保存し仮想通貨で「データの身代金」を要求するようなこともある。後者についてはサーバーだけでなくランサムウェアを用いて一般人が使用するデバイスに対しても要求することがある。しかし今ではあまり見かけないので、もはや過去の物なのだろうか。

無対策であれば確実に何らかの被害を被る

ID・パスワードを不正な手段によって入手しアクセスする不正アクセスは勿論、ブルートフォースアタックも非常に時間がかかるものであるが、それを取得するためにプログラミングの知識を悪用し、自動化を図っていることが多くなっている。それ以外の方法についても、大抵の場合はソフトウェアを最新版にしておけば殆どは避けられるものになっているが、だがそのままにしておいても良くはない。放置していれば、いつかは確実に何らかの被害を被るわけだ。

無能ジャップの無能な警察官よろしく、何か事件が起きてから動くのは全くもって馬鹿の思考である。それ故、攻撃されていることが分かったら何かが起きる前に対策を行い、攻撃者をサイトないしサーバーから追い出すというのが当たり前のことである。それ以前に対策を行い、そもそも攻撃させないということも大事になる。これは犯罪抑止でよくあるものだが、インターネットでも同じことが言える。しかしどうも、インターネットだからなのか、対策意識が薄い人が多いようである。とはいえ「普通の場合」なら考える必要がないだろう。だがもはや今は普通ではなくなってしまっており、普通の場合が通用しなくなっていることについては考慮する櫃がある。




初歩的なアクセス制限を行う設定ファイル、Apache系は”.htaccess”がある

では、どう対策していけばいいか。ソフトウェアレベルであれば、WordPressならWordPressの下にインストールできるプラグインを導入することが挙げられる。これには様々なプラグインがあり、アクセス制限を行うプラグインも多数存在する。とはいえプラグインの中には情報の抜き取りを目的に設計された悪意の塊も存在するわけで、またプラグインだけでは不正アクセスなどを100%カバーすることができない。所詮ソフトウェアの制御であり、プラグインを無効化されれば防御は効かなくなる。それを考えたとき、プラグインだけに頼るのはあまりにも非力である。それにサーバーの用途もそれぞれ存在し、WordPress以外のソフトウェアがインストールされていることも想定されることである。したがって、プラグインやソフトウェア頼みの対策はあまり利口とはいえないものである。

そこであがってくる方法がサーバーに標準に存在する、サーバー設定ファイルでアクセス制御を行う方法である。この名前はサーバーOSによって名称が異なることがあるが、Apache系のサーバーであれば標準で”.htaccess”が存在する。これは何もしなくても外部からサーバーにアクセスした際のrootに置かれるものであり、サーバー内部(Apache系)から見た場合は/var/www/html/に存在する。これは名前の存在しない、拡張子のみのファイルであるが一般的なテキストエディタで編集できるものである。そのついで、サーバーのroot以外にも各ディレクトリに配置することもできるファイルであり、ディレクトリ単位でアクセス制御も可能にするものである。今回は.htaccessを利用したアクセス制御について、実例を用いながら解説していく。

.htaccess、実際に「編集」する

はじめに:.htaccessを編集するにあたっての注意

実際に.htaccessを編集するにあたり、まず注意しなければならないことがある。.htaccessは重要な設定ファイルであり、指定された書式に沿って記述を行わないと、サーバーは500エラーを返す。つまり、何かを少し間違えただけでもサイトにアクセスできなくなる可能性があるということだ。.htaccessに関する設定方法が書かれているサイトを見ると、定型句のように「サイトやサーバーに影響を与える可能性があります。」と書かれた文章がある。この言葉の意味するところは、「この 内容の通りに行っても、責任は負いかねます」と同義だ。

ただし、私が知る限り.htaccessはあくまでも単純な設定ファイルに過ぎない。そのファイルのバックアップを作業時にあらかじめ用意しておき、ファイル更新後に何か問題が生じたのなら、差し戻しを行えば何ら問題もなく元通りにすることができる。また、最近ではローカルでApacheサーバー他を起動できるソフトウェアも存在し、前述の通り無償利用可能のOSにDebian系Apacheサーバーを持つUbuntu Serverもあり、これらを利用してローカルで実験してから実際に動作している環境で導入するという手段も取ることができる。もし不安があるのなら、ローカル環境を用意してから.htaccessを実験してみるといいだろう。

設定初歩:.htaccessとサーバーのroot構成

まずは設定の初歩として、.htaccessとサーバーのroot構成についておさらいしておく。なお、ここではWordPressを使用していることを想定する。基本的に.htaccessは以下のような配置になる。

rootにおける.htaccessの配置
WordPressの場合のrootにおける.htaccessの配置図解。WordPressにおいては3つのディレクトリがあり、その他のファイルが存在するのがrootだ。ここに作成した.htaccessを置くのである。

WordPressにおいては”wp-[admin, content, include]”がディレクトリで、それ以外が何らかのファイルで構成されている。ただ基本的には.phpと(収益化がされている場合)特別なテキストファイルとhtmlファイルで構成されているはずだ。もっともこれはレンタルサーバーの場合ブラウザからファイルやディレクトリ操作を行えるほか、FTPの設定を行えばFTPソフトから中身を見ることができる。操作しやすいのはFTPソフトからである。いずれにしても、ブラウザから直接ではない正規の方法を用いれば、中身がどうなっているかがより実感があるはずだ。




.htaccessの中身を見る

設置場所とその他のファイルないしディレクトリのおさらいが出来たところで、.htaccessの中身を見ていくこととする。なお、.htaccessは自作のサーバーの場合は標準で存在せず、レンタルサーバーなどでwordPressを運用している場合はブラウザから操作できるサービスから.htaccessを間接的に編集できる機能があるため標準で存在している、というパターンが多い。とはいえ殆どの場合は自分のPCで”.htaccess”の名称でファイルを新規作成し、それをサーバーにアップロードするのが原則となる。アップロード先がレンタルサーバー等のサービス利用の場合はアップロードして上書きする前に先にバックアップとして上書きする前の.htaccessファイルをダウンロードしておくといい。

以下はWordPressの場合における、.htaccessの初期状態である。大半のレンタルサーバーで導入したての頃は、おそらくこうなっているはずである。

WordPressの.htaccessの初期状態
WordPressをレンタルサーバーでインストールし、何も弄っていない場合の.htaccessの内容。これはレンタルサーバーのWordPressの場合、共通で自動で書かれるものである。

.htaccessが自動で生成され、かつその内容に”# BEGIN WordPress”から”# END WordPress”のセクションが自動で記述されているはずだ。これらの部分はどうやら自動生成されるものであるようで、かつこのセクションの間に書き込んだものは勝手に上書きされてしまう、という注意書きまで丁寧に生成されている。つまり、.htaccessに新たに内容を記述する際は、このセクションより上か下に書き込む必要があるということになる。だが下の方であると何かと上書きされる心配があるので、記述するならセクションの上の方が安全である。

次項からは.htaccessの書き方について解説していく。なお解説内容は私が実際に対策している内容に限定する。そうしないと、無限に内容を書くことになってしまうためである。

.htaccessと記述ルール

記述ルール1:ファイルアクセス制限

.htaccessはサーバーに存在するだけで機能する重要なファイルであることは、先の解説で認識してもらえたことであろう。攻撃者はこのことを理解しているため、.htaccess自体も不正に改竄するか、或いは中身を盗み見ようとすることがあり得る。中身を盗み見ようとするのは.htaccessに限った話でなく、特に.php, .js, .jsonも狙われやすい。したがってそれらのファイルにブラウザからアクセスさせないよう、拒否設定をファイルに対してかけてしまうようにすればいい。なお、許可設定も同時に行うことができる。

ファイルに対しての拒否/許可設定を行うにあたり、基本の書式が以下となる。

このように記述することで、そのファイルに対してのアクセスを完全に拒否するものとなる。もちろんこれは設定した自分自身も外部からアクセスしても見れなくなるものになる。ちなみにここにある書き方は.htaccessの最新の書き方に沿ったものであるが、私としては正直分かりにくい。そのため従来の記述形式となるOrder形式の記述方法もサポートしており、こちらでも問題なく動くようになっている。Require形式への書き換えはOrder形式の廃止の時に考える必要があるが、昔から動いているサーバーの大幅な.htaccessの修正必要性による手間があると考えれば、その可能性は十分低いはずである。




必須メモ1:正規表現の意味を理解する

上記ではしれっと正規表現を使用しているが、全く触れたことがない人からすれば何を意味しているのか全く分からない、で終わることである。上記では<Files ~ "^\.htaccess$">に正規表現を用いているが、それらが何を意味しているのか、そして他にも存在する正規表現の意味は何か、ここで軽く解説しておく。

表1 正規表現の文字とその意味1)参照:.htaccess の書き方 | murashun.jp ここを見るだけで大半の書き方が分かり、非常に詳しく書かれている。
文字 意味
. (ドット) 任意の1文字にマッチする
+ (プラス) 直線の文字が1回以上繰り返す場合にマッチする
* (アスタリスク) 直前の文字が0回以上繰り返す場合にマッチする。文字がなくてもOK
? (クエスチョン) 直前の文字が0個または1個の場合にマッチする。あってもなくてもOK
^ (ハット) 直後の文字が行の先頭にある場合にマッチする。$と組み合わせることが多い
$ (ドル) 直前の文字が行の末尾にある場合にマッチする。^と組み合わせることが多い
| (バーティカルバー) 選択肢を区切る際に使用する。()と組み合わせることが多い
\ (バックスラッシュ) 正規表現において特別な意味を持つ文字をエスケープする。文字として扱うために必要
() (丸括弧) 文字の集合を1つのグループとして扱う。他の正規表現と併用することが多い
{n,m} 直前の文字またはグループの桁数を指定してマッチ判定する
[] (角括弧) 角括弧に含まれる文字のいずれか1つにマッチする。”-“を使えば範囲を指定でき、”^”を使うと角括弧内の文字を除外する設定になる

他にも定義済み正規表現クラスが存在し、これは既に決まっているものを表現したいときに便利である。これについては詳細はリンクを参照してもらうとして、基本はこれらについて意味と使い方が分かっていれば問題ない。特にエスケープについてはファイル指定の時に重要になる。拡張子指定の際に”\.”で単に文字のドットとして機能させられるので、覚えておくことだ。今回の例の場合では、そもそもファイル名が.htaccessなので認識させるには”^”と”$”も合わせて”.”をエスケープさせたいので、”^\.htaccess$”となるのだ。ちなみにFilesで正規表現を使用してファイル名指定を行いたい場合、先に半角スペースで”~”(チルダ)を記述することで使用可能になる。あまり正規表現の解説でも記述されていないが何気に重要事項である。

もちろん、.htaccess以外のファイルに対しても正規表現によってアクセス制限をかけることができる。ではディレクトリに対してはアクセス制限をかけられないのかと思うことだろう。その方法は別にあるので、心配しなくていい。

記述ルール2:mod_rewriteでリダイレクト・拒否設定

ファイルはもちろんだがディレクトリ内部も本来であればむやみやたらに見られてはまずいものである。しかし初期状態だと何の対策もされておらず、どのWordPressでもディレクトリ名は共通であるので、その名称をブラウザから入力すれば簡単にブラウザで閲覧でき、ファイルにアクセスできてしまう状態にある。それはあまりにも無防備すぎるため、.htaccessにそれを守るための設定を記述してしっかりと防御する必要がある。

その場合、mod_rewriteを使用してリダイレクトや拒否設定を行うことができる。これは<IfModule mod_rewrite.c>という宣言が必要で、その後に内容を記述し、そして</IfModule>で閉じることで1つのブロックと認識する。通常、ApacheサーバーであればIfModule宣言をしなくても利用できるはずだが、もし存在しない場合500エラーの原因となるのでIfModuleを宣言している。こうすることで、もし該当モジュールが存在しない場合はそのブロックはコメントアウトと同じに扱われる。一種の保険のようなものである。



さて、このmod_rewriteであるが、その中で使用できるディレクティブ(命令)は以下である。

表2 mod_rewrite.cで使用できるディレクティブ2)参照:.htaccess – mod_rewrite | murashun.jp オプションも含めて詳しい説明が書かれている。
ディレクティブ名 動作
RewriteEngine URLの書き換えの有効/無効の切り替え
RewriteBase リダイレクト先の基準を相対パスで指定する。デフォルトは.htaccessの置かれたディレクトリ
RewriteRule URLの書き換えを行う。後で詳しく解説
RewriteCond RewriteRuleの書き換えルールの条件を定義する
RewriteOptions サーバーまたはディレクトリ単位でオプションを設定する

これらがmod_rewriteで使用できるディレクティブである。これを利用してディレクトリにアクセス制限をかける方法が以下である。

このように記述することで、特定のディレクトリのアクセス制限をかけることができる。ディレクトリと言いながらしれっとファイルにもアクセス制限を行っているが、これは正規表現を用いたものである。Rewrite系でも同じことができるので、使い方をマスターするとこっちの方が制御しやすい可能性もある。

補足:RewriteCondはどう使うのか

ところで表に書いたわりには例でRewriteCondは使っていない。なので、実際に私が被害を受けた際に対策として導入したものを例として、以下のように使用した。ちなみにこれはファイルやディレクトリのアクセス制限ではなく、リファラによるアクセス制限である。

RewriteCondはこのようにして書くことで、もしそれが一致した場合は直後に置くRewriteRuleの条件の書き換えが行われるようになる。通常のRewriteRuleでは難しい条件の設定もこれを使えば簡単にアクセス制限の設定が可能になる。特定の場所からアクセスしてほしくない場合などにはこれを利用するといい。ちなみに、.htaccessの環境変数についてはここが詳細に内容が書かれている。いずれも%{環境変数名}の書式である。

スポンサーリンク




スポンサーリンク

記述ルール3:リファラ・ユーザーエージェントやIPアドレス単位でも許可と拒否を設定できる

さて、特定のリンク元からのアクセスや特定のIPアドレスからのアクセスを拒否したいということは、サイト運営者ならありがちな悩みであるはずだ。また、特定のユーザーエージェントからのアクセスを拒否したいパターンもまたあるはず。それを解決する手段を.htaccessは提供してくれている。モジュールの1つでmod_setenvif.cによって提供される機能とDeyn/Allowのオーダーを使うことで、これも簡単に設定できるのである。

Apache系ではmod_setenvif.cは標準で使用できるものであるが、安全のためには宣言をしておいた方がいいだろう。当の私は急いでいたこともあって宣言を行わずに使用しているが、宣言しなかったことによる500エラーは発生していない。しかし今後どうなるかは分からないので、心配な人は宣言した方がいい。ところで、mod_setenvifで使用できるディレクティブは以下である。

表3 mod_setenvif.cで使用できるディレクティブ3)参照:.htaccess – mod_setenvif | murashun.jp
ディレクティブ名 動作
BrowseMatch User-Agent HTTPリクエストヘッダの内容とregexが一致した場合に環境変数を設定する
BrowseMatchNoCase BrowseMatchと同じ。こちらは大文字と小文字の区別を行わない
SetEnvIf リクエストの属性に基づいて環境変数を設定する
SetEnvIfNoCase SetEnvIfと同じ。こちらは大文字と小文字の区別を行わない

今回使用するのはSetEnvIf(NoCase)で、BrowseMatch(NoCase)は使わない。基本的にはSetEnvIfで十分対応できるためだ。それではこれを使ったリファラ・ユーザーエージェント及びIPアドレス単位の拒否設定は以下のように行う。

このように記述すれば、うざったいリファラスパムもユーザーエージェント(特にBot)も、さらに攻撃性の高いIPアドレスもこの方法でアクセス制限(拒否)を行うことができるようになる。ただし、それらの情報の取得はかなり苦労する。私は特殊な方法を用いてアクセスログを生成し、その情報を基に.htaccessに随時入力して拒否設定を更新しているが、その詳細については安全性の観点から、残念ながら語ることはできない。これは各自で調査してもらいたい。

これらの拒否設定は単純なOrder形式によるもので、特別な設定は必要ない。ただしこちらは正規表現は調査した限りでは使用できないような感じである。そのため、同じような文字列で数字やドメインだけ変えてくるような迷惑者に対して対策する場合は、正規表現の使えるmod_rewrite.cの方で対策するといい。

スポンサーリンク




スポンサーリンク

実はroot以外にも置ける.htaccess, ディレクトリ単位でセットできる

.htaccessは実はサーバーのroot以外に、各ディレクトリにもセットできるようになっている。この場合、rootよりもディレクトリにセットされた.htaccessの方が優先して適用されることになる。ただし優先されるのは同じ設定が存在するときで、それ以外はrootの設定が反映されるというルールになっている。

通常は各ディレクトリに.htaccessを置くことはないが、ブログを運営している場合は多数の画像や動画をアップロードし、それを記事に挿入していることが普通である。その際、別のサイトで画像や動画のリンクを直接貼ってほしくないというのが運営者の願いだ。しかしそんな願い虚しく、直リンクする人間の姿をした蟲は多数存在するわけで、それについての対策も立てなければならないものになる。その場合でも、アップロード先のディレクトリに.htaccessを配置して制御すれば簡単にアクセス制限をかけることができる。その例が以下である。

上記はブラウザから直接入力するパターンと、一部のリファラのみに許可し、それ以外は全て拒否する形となる。形式としては最初に全部拒否してから一部を許可する形だ。そのため、許可設定を正しく行わなければSNSにリンクを貼ったときや自身のブログのサムネイルで正しく表示されなくなる。とはいえこれはローカル環境での実験が難しいので、いつでも復元できる状態で試すといいだろう。とはいえ表示されない状態はあまりいいものではないので、もしうまく表示されない状態になったらすぐに直すようにすることだ。

.htaccessが分かれば、クラッキング対策の大半をカバーできる

以上が.htaccessでサイトアクセス制御を行う方法である。.htaccessで行えることは多彩であるが、今回はその中から主にアクセス制限を行うものを中心に、クラッキングの対策の内容について解説した。.htaccess, つまりApacheの書式となるそれは、何もわからない状態で見れば一体何の命令を出しているのかはわからない。一種のプログラミング言語と捉えてもいいこれは、他のそれと同様にちゃんとした公式リファレンスが存在するため、それを見ながら記述していけば、初めて触れる人でも問題なく使っていけるものである。多くのプログラミング言語がそうであるように、使い方については必ずしも暗記する必要はない

WordPressは自由度の高さと多くの人に使われているということから、非常に多彩な機能が存在する。だがそれ故に破壊行為の対象としてはうってつけであるので、破壊を目的にサイトアクセスを行う人間の姿をした蟲は後を絶たない。だが初歩に戻って考えてみれば、WordPressを動かしている大元のハードウェアはサーバーとして稼働している。ならば、ソフトウェアではなくサーバーの機能からアクセス制限を行ってやれば、そもそも到達する前に遮断できるわけだ。イラっとするクソみたいなクラッカー共から自分のサイトないしサーバーを守るために、.htaccessに臆せずカスタマイズしていくといい。それが安定した運営にも繋がるからである。

 

以上、.htaccessでサイトアクセス制御:敵を「未然に」防ぐ、であった。それでは、次回の記事で会おう。ン、バァーイ!

 

KIBEKIN at 00:00 Dec. 29th, 2021


スポンサーリンク




脚注

脚注
本文へ1 参照:.htaccess の書き方 | murashun.jp ここを見るだけで大半の書き方が分かり、非常に詳しく書かれている。
本文へ2 参照:.htaccess – mod_rewrite | murashun.jp オプションも含めて詳しい説明が書かれている。
本文へ3 参照:.htaccess – mod_setenvif | murashun.jp
RA管理人
RA管理人。名前は時にない。かつてこのサイトを管理していた前任者はどこかへ消えてしまった。


コメントを残す

メールアドレスが公開されることはありません。
名前は必須項目となります。記入をお願いいたします。

CAPTCHA


日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

Ads Blocker Image Powered by Code Help Pro

広告ブロックを検知しました。 | Ad block detected.

ブラウザのアドオン、及びブラウザに内蔵されているアドブロック機能により、広告ブロックが行われていることが検知されました。
本ブログは広告収入により運営されており、広告ブロックは正当な理由の下で配信されている広告をも阻害することとなり、運営が非常に困難になります。
この表示は広告ブロック機能の無効化、あるいはホワイトリストへの追加を行った上で、更新を行うことで消すことができます。または、広告ブロック機能のないブラウザで閲覧ください。
広告で嫌な思いをしたことがあるとは思いますが、一律に広告をブロックすることで失われるコンテンツも存在します。そのことへのご理解とご協力をお願いします。

We have detected that ad-blocking is being performed by browser add-ons and the browser’s built-in ad-blocking function.
This blog is operated by advertising revenue, and ad blocking will interfere with advertisements that are also being served under legitimate reasons, making it very difficult to operate.
This display can be removed by disabling the ad-blocking function or adding it to the white list and then updating it. Alternatively, please view the site with a browser that does not have an ad-blocking function.
We understand that you may have had bad experiences with advertisements, but there are some contents that are lost by uniformly blocking advertisements. We ask for your understanding and cooperation in this matter.

Powered By
100% Free SEO Tools - Tool Kits PRO