セキュリティチップス :Security Tips

Some hints and tips on security issues in setting up a web server. Some of the suggestions will be general, others specific to Apache.

web サーバのセットアップでのセキュリティの課題におけるいくつかのヒントとチップスです. 提案のいくつかは一般的なもので, その他は Apache に固有です.

最新に保つ :Keep up to Date

The Apache HTTP Server has a good record for security and a developer community highly concerned about security issues. But it is inevitable that some problems -- small or large -- will be discovered in software after it is released. For this reason, it is crucial to keep aware of updates to the software. If you have obtained your vApache HTTP Server Announcements Listersion of the HTTP Server directly from Apache, we highly recommend you subscribe to the Apache HTTP Server Announcements List where you can keep informed of new releases and security updates. Similar services are available from most third-party distributors of Apache software.

Apache HTTP Server はセキュリティのグッドな記録をもっていて開発者コミュニティはセキュリティの課題についてとても憂慮しています. しかしソフトウェアがリリースされた後で -- 大なり小なりの -- いくつかの問題が発見されることは避けられません. このため, ソフトウェアのアップデートを意識し続けておくことが肝心です. もしあなたが直接 Apache から HTTP サーバのバージョンを取得しているなら, 私たちはあなたが新しいリリースとセキュリティアップデートについて継続して報告されることができる Apache HTTP Server Announcements List のサブスクライブを強く推奨します. 同様のサービスは Apache ソフトウェアのほとんどのサードパーティディストリビューションから利用可能です.

Of course, most times that a web server is compromised, it is not because of problems in the HTTP Server code. Rather, it comes from problems in add-on code, CGI scripts, or the underlying Operating System. You must therefore stay aware of problems and updates with all the software on your system.

もちろん, サーバが侵害されるほとんどの場合は, HTTP サーバのコードの問題によるものではありません. むしろ, それはアドオンのコード, CGI スクリプト, または基盤のオペレーションシステムの問題からやってきます。したがってあなたはあなたのシステム上のすべてのソフトウェアでの問題とアップデートを意識し続けなければなりません.

サービス拒否 (DOS) アタック :Denial of Service (DOS) attacks

All network servers can be subject to denial of service attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can do certain things to mitigate the problems that they create.

全てのネットワークサーバはそのサーバのリソースを拘束することによりクライアントへのレスポンスを阻止するサービス拒否アタックの対象になりえます. そのようなアタックは完全に防止することはできませんが, あなたはそれが生じる問題を軽減するために一定のことを行えます.

Often the most effective anti-DoS tool will be a firewall or other operating-system configurations. For example, most firewalls can be configured to restrict the number of simultaneous connections from any individual IP address or network, thus preventing a range of simple attacks. Of course this is no help against Distributed Denial of Service attacks (DDoS).

大抵最も効果的な対 Dos ツールはファイアウォールや他のオペレーションシステム構成になります. 例えば, ほとんどのファイアウォールは個別の IP アドレスやネットワークからの同時接続数を制限するために構成することができるので, シンプルな範囲のアタックを防ぐことができます. もちろんこれは分散型サービス拒否アタック (DDos) に対する助けにはなりません.

There are also certain Apache HTTP Server configuration settings that can help mitigate problems:

問題の軽減を助けることができる一定の Apache HTTP Server 構成セッティングもあります:

• The RequestReadTimeout directive allows to limit the time a client may take to send the request.

  
  RequestReadTimeout ディレクティブはクライアントがリクエストを送信するための時間を制限できるようにします.



• The TimeOut directive should be lowered on sites that are subject to DoS attacks. Setting this to as low as a few seconds may be appropriate. As TimeOut is currently used for several different operations, setting it to a low value introduces problems with long running CGI scripts.

  
  Dos アタックの標的のサイトでは TimeOut ディレクティブは低くしたほうがよいはずです. 数秒程度にこれをセッティングするのが適切でしょう. TimeOut は現在いくつか異なるオペレーションで使われるので, それを低い値にセッティングすると長時間走る CGI スクリプトで問題をもたらします.



• The KeepAliveTimeout directive may be also lowered on sites that are subject to DoS attacks. Some sites even turn off the keepalives completely via KeepAlive, which has of course other drawbacks on performance.

  
  KeepAliveTimeout ディレクティブも Dos アタック対象のサイトでは低くしたほうがよいかもしれません。一部のサイトでは KieepAlive を介してその keepalive を完全にオフにすることさえありますが, もちろんそれはパフォーマンスで他の難点があります.



• The values of various timeout-related directives provided by other modules should be checked.

  
  その他のモジュールによって提供されるタイムアウトに関連した様々なディレクティブの値をチェックしたほうがよいでしょう.



• The directives LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, and LimitXMLRequestBody should be carefully configured to limit resource consumption triggered by client input.

  
  LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, それと LimitXMLRequestBody ディレクティブはクライアントの入力によりトリガされるリソースの消費を制限するために注意深く構成されるべきです.



• On operating systems that support it, make sure that you use the AcceptFilter directive to offload part of the request processing to the operating system. This is active by default in Apache httpd, but may require reconfiguration of your kernel.

  
  AcceptFilter ディレクティブをサポートするオペレーティングシステム上では, あなたはそれを使ってオペレーティングシステムへのリクエスト処理の一部をオフロード (# 負荷軽減) するようにしてください。これは Apache httpd のデフォルトでアクティブですが, あなたのカーネルの再構成が必要になるかもしれません.



• Tune the MaxRequestWorkers directive to allow the server to handle the maximum number of simultaneous connections without running out of resources. See also the performance tuning documentation.

  
  サーバがリソースを使い果たすことなく同時接続の最大数を処理できるように MaxRequestWorkers ディレクティブを調整します. perfomance tuning documentation も参照してください.



• The use of a threaded mpm may allow you to handle more simultaneous connections, thereby mitigating DoS attacks. Further, the event mpm uses asynchronous processing to avoid devoting a thread to each connection. Due to the nature of the OpenSSL library the event mpm is currently incompatible with mod_ssl and other input filters. In these cases it falls back to the behaviour of the worker mpm.

  
  スレッド化された mpm の使用はあなたにより多くの同時接続を処理できるようにして, それにより Dos アタックを軽減できるかもしれません。 さらに, event mpm は各コネクションへのスレッドの割当てを回避するために非同期処理を使います. OpenSSL ライブラリの性質により event mpm は現在 mod_ssl や他のインプットフィルタとの互換性がありません. これらのケースでは worker mpm の振る舞いにフォールバックします.



• There are a number of third-party modules available that can restrict certain client behaviors and thereby mitigate DoS problems.

  
  特定のクライアントの振る舞いを制限することで Dos 問題を軽減するサードパーティモジュールが多くあります.

ServerRoot ディレクトリの権限 :Permissions on ServerRoot Directories

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

典型的なオペレーションでは, Apache は root ユーザによってスタートされ, User ディレクティブによって定義されたユーザにスイッチします. ルートが実行するコマンドのケースのように, あなたはそれが非 root ユーザたちによる変更から保護されるように注意しなければなりません. ファイルそれ自体がルートによってのみ書き込み可能であるだけでなく, ディレクトリ, およびすべてのディレクトリの親もそうでなければなりません.　例えば, もしあなたが /usr/local/apache に ServerRoot を配置することを選択したならあなたはそのディレクトリをこのようなコマンドで, root として作成することが推奨されます:

mkdir /usr/local/apache

cd /usr/local/apache

mkdir bin conf logs

chown 0 . bin conf logs

chgrp 0 . bin conf logs

chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected:

/, /usr, および /usr/local は root によってのみ変更可能だと想定されています. あたなが httpd 実行可能ファイルをインストールするとき, あなたはそれが同様に保護されていることを確認しなければなりません:

cp httpd /usr/local/apache/bin

chown 0 /usr/local/apache/bin/httpd

chgrp 0 /usr/local/apache/bin/httpd

chmod 511 /usr/local/apache/bin/httpd

You can create an htdocs subdirectory which is modifiable by other users -- since root never executes any files out of there, and shouldn't be creating files in there.

あなたは他のユーザによって変更可能な htdocs サブディレクトリを作成できます -- 決して root はそこからファイルを実行することがなく, そこでファイルの作成をするべきではないからです.

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises. For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

もしあなたが root が実行や書込みをするファイルの変更を非 root ユーザができるようにするとあなたはあなたのシステムを root 侵害に開いてしまいます. 例えば, 誰かが httpd バイナリをリプレイスしてあなたが次にそれをスタートすると, それは何らか任意のコードを実行することになります. もし logs ディレクトリが書き込み可能 (非 root ユーザによって) なら, 誰かが log ファイルを何らかほかのシステムファイルへの symlink (# シンボリックリンク) でリプレイスして, root がそのファイルを任意のデータで上書きするかもしれません. もしログファイルそれ自体が書き込み可能 (非 root ユーザによって) なら, 誰かが偽のデータでその log ファイルそのものを上書きできるはずです.

サーバサイドインクルード :Server Side Includes

Server Side Includes (SSI) present a server administrator with several potential security risks.

サーバサイドインクルード (SSI) はサーバ管理者にいくつか潜在的なセキュリティリスクをもたらせます.

The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant.

1 つめのリスクはそのサーバの負荷の増加です. すべての SSI が有効なファイルは Apache によってパースされなければなりません, そのファイルに何らかの SSI ディレクティブがあるかどうかに関わらずです. この負荷の増加は小さいものの, 共有サーバ環境では重大になりかねません.

SSI files also pose the same risks that are associated with CGI scripts in general. Using the exec cmd element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf.

SSI ファイルは一般的な CGI スクリプトに関連したものと同じリスクももたらします. exec cmd エレメントを使うと, SSI が有効なファイルは任意の CGI スクリプトやプログラムを httpd.conf で構成されている Apache を実行するユーザおよびグループの権限下で実行できます.

There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide.

SSI ファイルが提供する利点のアドバンテージをとりながらそのセキュリティを強化する方法があります.

To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section.

厄介な SSI ファイルが引き起こすダメージを分離するために, サーバ管理者は CGI in General セクションで説明されているように suexec を有効にできます.

Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

.html や .htm 拡張子のファイルで SSI を有効にするのはデンジャラスになりえます. これは共有や, 高トラフィック, のサーバ環境では特にそうです. SSI が有効化されたファイルは慣習的な .shtml など, 別の拡張子を持つべきです. これはサーバの負荷を最小限に維持してリスクのマネージメントを簡単にすることを助けます.

Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.

もうひとつの解決策は SSI ページからスクリプトとプログラムを実行するための機能を無効化することです. これを行うには Options ディレクティブ内の Includes を IncludesNOEXEC でリプレイスします. なおユーザはそれらのスクリプトが ScriptAlias ディレクティブによって指定されたディレクトリ内にあれば CGI スクリプトを実行するために <--#include virtual="..." --> をまだ使えることに注意してください.

一般的な CGI :CGI in General

First of all, you always have to remember that you must trust the writers of the CGI scripts/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental. CGI scripts can run essentially arbitrary commands on your system with the permissions of the web server user and can therefore be extremely dangerous if they are not carefully checked.

まずはじめに, あなたは CGI スクリプト/プログラムの作者やそれが故意なのか偶発的なのかに関わらず, CGI の潜在的なセキュリティホールを見つけるあなたの能力を信頼しなければならないことを常に覚えておかねばなりません. CGI スクリプトは元来その web サーバのユーザの権限であなたのシステム上において任意のコマンドを実行できるのでそれらが注意深くチェックされないならば極めてデンジャラスになります.

All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B's CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1.2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.

すべての CGI スクリプトは同じユーザとして走るので, 他のスクリプトと競合する (故意であれ意図的であれ) 可能性をもちます e.g. User A が User B を嫌っているので, 彼は B の CGI データベースを捨てるスクリプトを書きます. 異なるユーザとしてスクリプトの実行を可能にするために使われるプログラムのひとつは 1.2 の Apache で含まれた suEXEC で Apache server コード内容のスペシャルフックからコールされます. これを行うもうひとつのポピュラーな方法は CGIWrap です.

非スクリプトエイリアスの CGI :Non Script Aliased CGI

Allowing users to execute CGI scripts in any directory should only be considered if:

ユーザが任意のディレクトリで CGI スクリプトを実行できるようにすることはこの場合にのみ検討してください:

• You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.

  
  あなたが故意または偶発的にあなたのシステムをアタックにさらすようなスクリプトを書かないとあなたのユーザを信頼する.



• You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.

  
  あなたはあなたのサイトでのセキュリティが他のエリアでとても脆弱なので, 潜在的な穴をひとつ増やしても関係ないと考えている.



• You have no users, and nobody ever visits your server.

  
  あなたはユーザをもっておらず, あなたのサーバを訪れる人は誰もいない.

スクリプトエイリアスの CGI :Script Aliased CGI

Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes.

CGI を特別なディレクトリに制限することはその管理者に何がそのディレクトリに入るのかのコントロールを与えます. これは必然的に非 エイリアスの CGI よりもセキュアですが, そのディレクトリへの書込みアクセスをもつユーザが信頼されているか, 管理者が新しい CGI スクリプト/プログラムを潜在的なセキュリティホールのためにそれぞれテストをすることを厭わない場合に限られます.

Most sites choose this option over the non script aliased CGI approach.

ほとんどのサイトは非 スクリプトエイリアスの CGI アプローチよりもこちらのオプションを選びます.

その他の動的コンテンツのソース :Other sources of dynamic content

Embedded scripting options which run as part of the server itself, such as mod_php, mod_perl, mod_tcl, and mod_python, run under the identity of the server itself (see the User directive), and therefore scripts executed by these engines potentially can access anything the server user can. Some scripting engines may provide restrictions, but it is better to be safe and assume not.

mod_php, mod_perl, mod_tcl, および mod_python のような, サーバそれ自体の一部として走る埋め込みのスクリプトオプションは, サーバ自身のアイデンティティのもとで走ります (User ディレクティブを参照), したがってそれらのエンジンによって実行されるスクリプトは潜在的にそのサーバユーザがアクセスできるすべてのもにアクセスできます. いくつかのスクリプトエンジンは制限を提供するはずですが, それで安全になると思わない方がベターです.

動的コンテンツのセキュリティ :Dynamic content security

When setting up dynamic content, such as mod_php, mod_perl or mod_python, many security considerations get out of the scope of httpd itself, and you need to consult documentation from those modules. For example, PHP lets you setup Safe Mode, which is most usually disabled by default. Another example is Suhosin, a PHP addon for more security. For more information about those, consult each project documentation.

mod_php, mod_perl や mod_python のような, 動的コンテンツをセットアップするとき, 多くのセキュリティの検討事項が httpd 自体のスコープ外になり, あなたはそれらのモジュールのドキュメントを調べる必要があります. 例えば, PHP をあなたは Safe Mode にできますが, それは通常は大抵デフォルトで無効化されています. もうひとつの例は Suhosin で, よりセキュリティを高める PHP アドオンです. これらについての詳細は, 各プロジェクトのドキュメントを調べてください.

At the Apache level, a module named mod_security can be seen as a HTTP firewall and, provided you configure it finely enough, can help you enhance your dynamic content security.

Apache レベルでは, mod_security という名前のモジュールが HTTP ファイアウォールとしてみることができ, あなたが十分に細かくそれを構成すれば, あなたの動的コンテンツのセキュリティをあなたが強化することを助けることができます.

システム設定の保護 :Protecting System Settings

To run a really tight ship, you'll want to stop users from setting up .htaccess files which can override security features you've configured. Here's one way to do it.

本当にタイトに船を走らせる (# タイトな運営を行う) ために, あなたはあなたが構成したセキュリティ機能を上書きできる .htaccess ファイルのユーザによるセットアップを停止したほうがよいでしょう. こちらはそれを行う方法のひとつです.

In the server configuration file, put

サーバ構成ファイルに, これを置きます

<Directory "/">

    AllowOverride None

</Directory>

This prevents the use of .htaccess files in all directories apart from those specifically enabled.

これはそれが特別に有効化されたものを別としてすべてのディレクトリでの .htaccess ファイルの使用を防止します.

Note that this setting is the default since Apache 2.3.9.

なおこのセッティングは Apache 2.3.9 からデフォルトです.

デフォルトでサーバファイルを保護する :Protect Server Files by Default

One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.

ときおり誤解される Apache の側面のひとつはデフォルトアクセスの機能です. つまり, あなたがそれを変更するステップをふまない限り, サーバが通常の URL マッピングルールを通じてファイルへの道を見つけた場合は, クライアントにそれを提供できます.

For instance, consider the following example:

実際に, 次の例を考えます:

# cd /; ln -s / public_html

Accessing http://localhost/~root/

This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server's configuration:

これはクライアントがファイルシステム全体を通り抜けられるようにします. これを回避するには, あなたのサーバの構成に次のブロックを追加します:

<Directory "/">

    Require all denied

</Directory>

This will forbid default access to filesystem locations. Add appropriate Directory blocks to allow access only in those areas you wish. For example,

これはファイルシステムロケーションへのデフォルトのアクセスを禁止します. あなたが望む場所だけにアクセスできるようにするためには適切な Directory ブロックを追加します. 例えば,

<Directory "/usr/users/*/public_html">

    Require all granted

</Directory>

<Directory "/usr/local/httpd">

    Require all granted

</Directory>

Pay particular attention to the interactions of Location and Directory directives; for instance, even if <Directory "/"> denies access, a <Location "/"> directive might overturn it.

Location と Directory ディレクティブの相互作用には特に注意を払ってください; 実際に, <Directory "/"> がアクセスを拒否したとしても, <Location "/"> ディレクティブはそれを覆すかもしれません.

Also be wary of playing games with the UserDir directive; setting it to something like ./ would have the same effect, for root, as the first example above. We strongly recommend that you include the following line in your server configuration files:

また UserDir ディレクティブでのゲームのプレイも用心してください; それを ./ のようなものにセッティングすると上記の最初の例のような, root への, 同じ効果を持つことになります. 私たちはあなたが次の行をあなたのサーバ構成ファイルに含めることを強く推奨します:

UserDir disabled root

あなたのログを観察する :Watching Your Logs

To keep up-to-date with what is actually going on against your server you have to check the Log Files. Even though the log files only reports what has already happened, they will give you some understanding of what attacks is thrown against the server and allow you to check if the necessary level of security is present.

あなたのサーバに対して実際に何が起こっているのかを常に把握するためにあなたは Log File をチェックする必要があります. ログファイルはすでに発生したことだけをレポートするにせよ, どのようなアタックがサーバに対して投げられているのかあなたにいくつかの理解を与えあなたが必要なセキュリティのレベルが存在するかのチェックをできるようにします.

A couple of examples:

ふたつの例:

grep -c "/jsp/source.jsp?/jsp /jsp/source.jsp??" access_log

grep "client denied" error_log | tail -n 10

The first example will list the number of attacks trying to exploit the Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability, the second example will list the ten last denied clients, for example:

最初の例は Apache Tomcat Source.JSP Malformed Request Information Vulnerability (# Apache Tomacat Source.JSP の不正なリクエスト情報開示脆弱性) を悪用する試みのアタックの数をリストし, 二番目の例は最後に拒否されたクライアントを 10 個リストします, 例えば:

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd 

As you can see, the log files only report what already has happened, so if the client had been able to access the .htpasswd file you would have seen something similar to:

あなたが見てのとおり, このログファイルはすでに発生したことだけをレポートしますので, もしこのクライアントが .htpasswd ファイルへのアクセスができた場合あなたはあなたの Access log で:

 foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" 

in your Access Log. This means you probably commented out the following in your server configuration file:

これに似た何かを見ることでしょう. これはあなたのサーバ構成ファイルでおそらくあなたが次のものをコメントアウトしたことを意味します:

<Files ".ht*">

    Require all denied

</Files>

構成セクションのマージ :Merging of configuration sections

The merging of configuration sections is complicated and sometimes directive specific. Always test your changes when creating dependencies on how directives are merged.

構成セクションのマージングは複雑でときにディレクティブ固有です. ディレクティブがどのようにマージされるかに依存する物を作成するときは常にあなたの変更をテストしてください.

For modules that don't implement any merging logic, such as mod_access_compat, the behavior in later sections depends on whether the later section has any directives from the module. The configuration is inherited until a change is made, at which point the configuration is replaced and not merged.

mod_access_compat のような, 何もマージロジックを実装していないモジュールでは, 後ろのセクションの振る舞いは後ろのセクションがそのモジュールからの何らかのディレクティブをもっているかどうかに依存します. その構成は変更されるまで継承され, それ (# 変更) がされた時点で構成はリプレイスされてマージはされません.

コメント :Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.

お知らせ
これは Q&A セクションではありません. ここにおかれるコメントはドキュメントやサーバの改善の提案に向けられなければならず, もし無効/オフトピック (# の条件) を満たしたり (# そうであると) 見做された場合は私たちのモデレータによって削除されるかもしれません. Apache HTTP Server をどのように管理するかの質問は私たちの Libera.chat 上の IRC チェンネル, #httpd か私たちのメーリングリストいずれかの方に送られるべきです.

NEXT

次回は、Mod Perl2 の「 Documentation / Tutorials 」を確認する前に、本文中で言及のあった More Tuning Advice "Stas Bekman's Performance Guide" のリンク先「 Documentation / 1.0 / mod_perl 1.0 User Guide / Performance Tuning 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認する予定です。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index