[トップ] [自作PC] [PCの履歴] [フリーソフト] [プロバイダー選び] [レンタルサーバー]
[ワイマックスで損しない方法] [VPS比較] [フレッツ光東西でギガビットインターネット接続] [着メロ] [MSX] [ツイッターでポイントを貯めよう! ]

#powerusage

うちの書いた書籍(の一部)

タイトル:ドメインを取ろう!(エーアイムックより)

&date(SGGY年Zn月Zj日(DL RY RK RS RG XG SZ MG),//); に書いた原稿ですが、
今となってはほとんど古い資料となっているでしょう。

しかしながら、物理的なサーバーのセキュリティー に関しては、役に立つかもしれません。

// 一部削除 (URL関係)



中古価格 ¥1から

  • うちの書いた書籍(の一部)
    • 目次
    • 以下、原稿
    • ドメインとサーバーのセキュリティー
    • パスワードの管理
      • わかりやすいパスワードは付けない!
      • 絶対に紙に書いてはならない!
      • 同じパスワードを複数のサーバーで利用しない
      • 複数の人間で同じパスワードを使用しない
      • root パスワードは限られた人のみ!
    • アカウントの管理
      • シェルを無効にする
      • シャドウパスワードの導入
      • /etc/login.access によるログイン設定
      • スーパーユーザーになれるユーザーを設定する
    • TCP/IPにおいて不必要、制限すべきネットワークサービス
      • echo サービス
      • systatサービス
      • netstatサービス
      • FTP-Data、FTPサービス
      • sshサービス
      • telnetサービス
      • smtpサービス
      • finger サービス
      • http、https サービス
      • pop3サービス
      • authサービス
      • netstatサービス
      • imapサービス
      • loginサービス
      • shellサービス
      • NFSサービス
    • 外部アクセスからの制限について
      • アプリケーション自身が常駐するもの
      • inetd を経由して、TCP Wrappers※ で制限する。
      • tcpserver を利用する。
      • ルーターによるパケットフィルタリング処理
      • 非公開サーバーを別サブネットに配置する。
      • スイッチングハブ、セキュリティーハブの導入
    • セキュリティー設定方法
      • /etc/services ファイル
      • /etc/inetd.conf ファイル
      • TCP Wrapper
      • hosts.allow/hosts.deny の記述方法
      • hosts.equiv、及び .rhosts
      • ルーターによるIPアドレス、ポートによる制御
      • ルーター自身のセキュリティー
    • アクセスログを見てみよう
      • syslog の設定
      • ログを別のホストに出力するには
      • syslogの見方
      • その他のアクセスログ
    • 物理的セキュリティー
      • 最低限、OSの起動ディスクは近くにおかないこと。
      • FDDドライブ、CD-ROMドライブに、何かテープを張りつけておき、封印する。
      • BIOS で FDDドライブを使用不能状態にする
      • FDDドライブ、CD-ROMドライブを抜いてしまう
      • いっそのことVGAカードも抜いてしまう?
      • リセットスイッチのコネクタを抜いておく
      • 電源スイッチもショートさせておく。(ATX型のみ)
      • それでも心配?やはり鍵のかかる所に入れる
      • ハードディスクの管理には要注意!
      • その他、各種セキュリティー情報
      • OSのセキュリティーホール
      • sendmail におけるセキュリティー
      • qpopper POPサーバー
      • Free Servers from Eudora:
      • qmail sendmailの代わりとなる安全なMTU
      • telnet サービス
      • ftp サービス
      • ssh サービス
      • NFS サービス
      • その他、セキュリティー関係サイトの紹介
    • 攻撃する側の改竄事例
      • 実際にクラックされってしまったら?
    • ドメインの個人情報について(実話)
    • アンケート
    • このことに関する話題

目次

● ドメインとセキュリティー
 ■ パスワードの管理

 ■ アカウントの管理
  ・シェルを無効にする
  ・シャドウパスワードの導入
  ・/etc/login.access によるログイン設定
  ・スーパーユーザーになれるユーザーを設定する

 ■ TCP/IPにおいて不必要、制限すべきネットワークサービス
  ・echo サービス
  ・systatサービス
  ・netstatサービス
  ・FTP-Data、FTPサービス
  ・sshサービス
  ・telnetサービス
  ・smtpサービス
  ・finger サービス
  ・http、https サービス
  ・pop3サービス
  ・authサービス
  ・netstatサービス
  ・imapサービス
  ・loginサービス
  ・shellサービス
  ・NFSサービス (追加)

 ■ 外部アクセスからの制限について
  ・アプリケーション自身が常駐するもの
  ・inetd を経由して、TCP Wrappers※ で制限する。
  ・tcpserver を利用する。
  ・ルーターによるパケットフィルタリング処理
  ・非公開サーバーを別サブネットに配置する。
  ・スイッチングハブの導入

 ■ セキュリティー設定方法
  ・/etc/services ファイル
  ・/etc/inetd.conf ファイル
  ・TCP Wrapper
  ・hosts.equiv、及び .rhosts
  ・ルーターによるIPアドレス、ポートによる制御
  ・ルーター自身のセキュリティー

 ■アクセスログを見てみよう
  ・syslog の設定
   ・syslog.conf
    ・ログの項目名の設定
    ・/etc/syslog.conf の設定例
   ・ログを別のホストに出力するには
    ・/etc/servicesの設定
    ・rc 初期化ファイルの syslogd 起動方法を変更する
   ・syslogの見方
  ・その他のアクセスログ
   ・Apache のアクセスログ
   ・/var/log/sulog
   ・lastlog コマンド

 ■物理的セキュリティー

 ■ その他、各種セキュリティー情報
  ・OSのセキュリティーホール
  ・sendmail におけるセキュリティー
  ・qpopper POPサーバー
  ・qmail sendmailの代わりとなる安全なMTU
  ・telnet サービス
  ・ftp サービス
  ・ssh サービス
  ・その他、セキュリティー関係サイトの紹介

 ■ 攻撃する側の改竄事例
  ・実際にクラックされってしまったら?

■ドメインの個人情報について(実話)<コラム

以下、原稿

ドメインとサーバーのセキュリティー

 サーバー導入にあたって最も重要なのがセキュリティーです。せっかく構築したサーバーも、セキュリティーホールによって侵入され、そして、いつのまにか跡形もなくなってるといったら、きっとまた面倒な作業、いや、場合によっては、何億もの損害になりかねないこともあります。あとで後悔する前に、最初に正しい知識を身につけ、正しい設定を行うことが必要です。ここでは、私が過去のレンタルサーバー事業者としていろいろと勉強させられたセキュリティー事項について解説します。

パスワードの管理

 ほとんどのサーバーOSでは、必ずといっていいほど、ログイン名とパスワードを利用して、それに認証されたユーザーのみが作業することができます。しかし、そのパスワードが漏れてしまっては何をされるかわかりません。その為に、運営する上で次の点に注意して下さい。

わかりやすいパスワードは付けない!

 パスワードは、極端な話ではありますが、どこの誰もが人為的、もしくは機械的に探ることが可能です。たとえば、誕生日、車のナンバー、保険証、免許証の番号はもちろんのこと、一般的にあるような単語等では「辞書アタック」といわれるような方法で解読することができてしまいます。
 パスワードは、ランダム文字で、可能なシステムでは大文字小文字を区分し、できれば記号文字や数字も混ぜる等、複雑なパスワードにし、パスワードの文字数制限の最大文字数で設定することが重要です。最近フリーソフトで出まわっているパスワード生成ソフトを用いるのも一つの手段です。

---------------------------------------------------
|・良いパスワードの例
| bZ5h@s$a - 大文字小文字数字記号混ざり
| s3zkqb9a - 小文字数字混ざり
|
|・悪いパスワードの例
|  - 誕生日でしょうか?
| nanami   - 奥さんの名前でしょうか?
| ai-pub5  - ドメイン名でしょうか?
|           - パスワード未設定はご法度です!
---------------------------------------------------

絶対に紙に書いてはならない!

 パスワードは人に見せものではありません。例えば、いつも忘れやすいからといって手帳にメモしておく等をしておくと、いつその手帳を紛失してそれを元にログインされるかもわかりません。それでは、せっかくのパスワードが台なしになるでしょう。  パスワードの重要性とは、管理者以外であるユーザーも知っておかなければならないことです。安易な考えでユーザーにアカウントを発行せず、パスワードが漏れたらどのようになるかをしっかりと指導する必要があります。  また、オートログインマクロによって自動ログインされると便利ではありますが、最低でもパスワードのかからないクライアントOSでは設定させないよう徹底する必要があります。

同じパスワードを複数のサーバーで利用しない

 よく、たくさんのアカウントを持っている人等がこのようないことを行いがちですが、これは非常に危険です。もし、そのうちどれか1つのパスワードが破られれば、そのパスワードが辞書アタックのリストに加わる訳です。

複数の人間で同じパスワードを使用しない

 共有したパスワードを使用することで、もしパスワードが漏れてしまった場合、どうしてパスワードが漏れてしまったかの追跡がかなり困難になります。何らかのファイルの複数ユーザーにおける共用を行うならば、グループでひとまとめにすることをお薦めします。

root パスワードは限られた人のみ!

 root パスワードは絶対に破られてはいけません。破られたらどのようなことがされるかというのは見当つくと思います。すべての権限を持つのが root です。すべての権限の中には破壊行為、盗み出し、いろいろできる訳です。定期的にパスワードを変更する等しっかりとした管理が必要です。

アカウントの管理

 もし、パスワードが漏れたとしても、アカウントの管理がしっかりしていれば被害を最小限に食い止めることができます。必要な権限のみをユーザーに与える方法をいくつか紹介します。

シェルを無効にする

 最も簡潔でかつ有効なのが、telnet ログインそのものを無効にしてしまうことです。メールやFTP等しか利用しないユーザーに対して設定するのに、非常に有効です。  「/bin/echo」 で適当なメッセージを出力したり、「/bin/date」 等で日付を表示し、強制ログアウトにする方法もありますが、よくある方法として、「/usr/bin/passwd」の方法を紹介します。
---------------------------------------------------
|  chsh -s /usr/bin/passwd ユーザー名
|  usermod -s /usr/bin/passwd ユーザー名
|  pw usermod -s /usr/bin/passwd ユーザー名
---------------------------------------------------

 上記の設定にすることで、ユーザーはログインしてもパスワードの変更ができるのみとなります。通常、このままであれば、メール等のネットワークサービスは問題なく使えます。

 しかし、FTPの機能はこのままでは使用できない場合があります。この場合には、「/etc/shells」というファイルに、シェルの代わりに設定したプログラム名(「/usr/bin/passwd」等)を記述します。

シャドウパスワードの導入

 UNIXが開発された当初は、「/etc/passwd」ファイルに一方的な暗号化によるパスワードが格納されました。しかし、コンピュータの進歩が続き、それらの暗号化されたパスワードが辞書アタック等を用いて、非常に高速に解読できるようになってきています。「/etc/passwd」 は、ユーザー名がわからないと動作しないアプリケーションの為に、パーミッションが4に設定されている為、そのサーバーのユーザーであれば、もしくは、http サーバーのように nobody ユーザー等であっても、ある種の SSI 方式掲示板に多少のものを記述するだけでも簡単に覗けてしまいます。その為に、「/etc/passwd」をダミーのファイルとし、他のファイル名でかつパーミッションを0とした形で格納するシャドウパスワードが開発されました。最近のOSではほとんどが実装されていますが、Linux に関しては特に実装が遅れていした。また、一部のパッケージにおいてはシャドウパスワードは任意のインストールとなっているものもありますので、忘れずにインストールを行って下さい。また、年以前のシャドウパスワードパッケージにおいては、セキュリティーホールもありますので、インストールされているバージョン等を確認して下さい。

/etc/login.access によるログイン設定

 シャドウパスワードパッケージには、「/etc/login.access」による高度なログイン制限を行うことができます。指定した端末以外のログイン禁止や、ネットワーク上においての指定したホストからしかログインできないようにすることも可能です。

---------------------------------------------------
| /etc/login.access の記述方法
|
|  許可フラグ:ユーザー:アクセス場所
|
| 先頭が「#」ではじまる行はコメント行
|
| 許可フラグ:許可をする/しないの選択
|       + 許可する
|       − 許可しない
| ユーザー: ユーザー名、グループ名
|       空白区切りで複数指定可
|       ALL を指定することですべてのユーザー
|       LOCAL を指定すると、「.」を含まない
|       すべてのローカルユーザー
|       EXCEPT ユーザー名等の前に指定すれば
|       「それ以外」
| 場所:   コンソールの名前(console tty1 ttyp0)
|       ホスト名 (win.example.co.jp)
|       ドメイン名(.example.co.jp)
|       IPアドレス(2.8.1.3)
|       同一サブネット(2.8.1.)
|       ALL を指定するとすべての場所
---------------------------------------------------

/etc/login.access の設定例を挙げてみました。

 ・rootユーザー以外は、コンソール、仮想端末からのログインを禁止する
---------------------------------------------------
|-:EXCEPT root: console tty1 tty2 tty3 tty4 tty5 tty6
---------------------------------------------------

  ・あるドメイン名以外からのログイン禁止
---------------------------------------------------
|-:ALL:EXCEPT .example.co.jp .example.com
---------------------------------------------------

 ・2.8.1.0/5.5.5.0 、及びコンソール、仮想端末からのみのログインを
  認める場合
---------------------------------------------------
|-:ALL:ALL
|:ALL:2.8.1.
|:ALL:console tty1 tty2 tty3 tty4 tty5 tty6
---------------------------------------------------

 ・それぞれのアカウントからのtelnetを有効にする場合
---------------------------------------------------
|-:ALL:ALL
|:user1:win.example.co.jp
|:user2:ppp.example.com
---------------------------------------------------

 ・特定のグループからのtelnetを有効にする場合
---------------------------------------------------
|-:ALL:ALL
|:wheel:ALL
---------------------------------------------------

スーパーユーザーになれるユーザーを設定する

 FreeBSDにおいては標準設定されていますが、Linuxの一部のパッケージにおいては、誰でも su コマンドでスーパーユーザーになることができます。
 この su コマンドの制限を行うには、下記の方法があります。
 ・/etc/login.def を設定する
 /etc/login.def の中にある
---------------------------------------------------
| SU_WHEEL_ONLY   no
---------------------------------------------------
という項目を
---------------------------------------------------
| SU_WHEEL_ONLY   yes
---------------------------------------------------
に変更します。

上記の設定をした後、実際にユーザーの設定をします。

---------------------------------------------------
| usermod -G root ユーザー名
| usermod -G wheel ユーザー名
| pw usermod -G wheel ユーザー名
---------------------------------------------------

 ・su コマンド自体のパーミッション、オーナーを変更する
 /bin/su コマンドのパーミッションを  に設定し、su コマンドの
 グループオーナーを root もしくは、新たに設定したグループ名に変更します。

---------------------------------------------------
| groupadd admingroup 又は vi /etc/group
| chmod  /bin/su
| chown root.admingroup /bin/su
---------------------------------------------------

上記の設定をした後、実際にユーザーの設定をします。

---------------------------------------------------
| usermod -G admingroup ユーザー名
| pw usermod -G admingroup ユーザー名
---------------------------------------------------

TCP/IPにおいて不必要、制限すべきネットワークサービス

 まず、外部からのセキュリティーにおいて重要なのがどのようなサービスが必要か、不要かということを理解することです。/etc/inetd.conf には、OSインストール時に便宜の上で各種サービスが登録されていますが、これらのうち一部はクラッキングの参考となったり、直接のセキュリティーホールになる可能性もあります。特に問題がない限りこれらのネットワークサービスは閉じておいたほうがよいでしょう。

echo サービス

 ポート7番において、TCP/UDP で使用可能なサービスです。不要であれば拒否しておくとよいでしょう。

systatサービス

 ポート番において、TCP/UDPで利用可能な ps コマンドの代わりのサービスです。これらの内容にはクラッキングの参考となる情報が提供される為、/etc/inetd.conf のエントリから削除すべきです。通常では、ログオン後に ps コマンドを実行することで調べることができますので、閉鎖したことによる影響はないはずです。

netstatサービス

 ポート番において、TCP/UDPで利用可能な netstat コマンドの代わりのサービスです。これらの内容にはクラッキングの参考となる情報が提供される為、/etc/inetd.conf のエントリから削除すべきです。通常では、ログオン後に netstat コマンドを実行することで調べることができますので、閉鎖したことによる影響はないはずです。

FTP-Data、FTPサービス

 ポート、番において TCP/UDPで使用可能なファイル転送サービスです。システムの構成において FTPが必要でなければ拒否しておくとよいでしょう。FTPの場合、クリアテキストによって認証されることにより、覗かれる場合があります。

sshサービス

 ポート番において TCP/UDPで使用可能なセキュアシェルサービスです。暗号通信を行うシェルということで人気もありますが、暗号パスワードを用いない認証方法もある為、場合によっては覗かれたり既に覗かれたパスワードでログインされる可能性があります。これらは「/etc/login.access」において制限はされないので、inetdから起動する形で、TCP Wrappers においてホスト名における制限をかけておくのもよいでしょう。なお sshd を単体で常駐プログラムとして起動せず、「/etc/inetd.conf」を用いて inetd から起動する場合、何もオプションを付けないと毎回毎回RSA鍵を生成する為非常に重くなります。ssh 1.2. の場合では「-i」オプションを指定しておくことをお薦めします。

telnetサービス

 ポート番において TCP/UDPで使用可能なシェルサービスです。ftpと同様にクリアテキストで認証される為、覗き見されることがあります。特に不要であれば拒否、もしくは TCP Wrappers において制限しておくとよいでしょう。

smtpサービス

 ポート番において TCP/UDPで使用可能なメール配信サービスです。そのままで開放した場合、セキュリティーホールはもとより、SPAM 等の迷惑メールに用いられ、場合によってはサーバーがそれらのメールが非常に大量の為、それらの処理の為にストールする場合があります。メールサーバーが外部にあり、特に必要がなければ拒否を行い、メールを使用するサーバーにおいては、sendmail や qmail 等のメールサーバーソフトウエアにあります SPAM対策を行って下さい。

finger サービス

 ポート番において TCP/UDPで使用可能なユーザーの詳細情報提供サービスです。これらの内容にはクラッキングの参考となる情報が提供される為、インターネットからの利用に対しては拒否すべきです。また、通常ではあまり利用することもないため、ポート自体を閉鎖するのもよいでしょう。

http、https サービス

 ポート番、3番において TCP/UDPで使用可能なWWWサービスです。これらの開放によって直接セキュリティーホールにはならないものの、CGI、SSI、PHF等によるセキュリティーホール※が発生する場合があります。公開サーバーであれば、適時それらの CGI、SSI、PHF等のスクリプトに対しセキュリティー対策※を行い、公開サーバーでなければ http サーバーにおけるアクセス制限等を行ったほうがよいでしょう。  また、Apache に付属されている Proxy 機能を放置しているホストが多数見受けられます。Proxy 機能とはどのようなものか? そして、放置したら多数の方に悪用される等とのようなことを理解しておくべきです。

※ CGIやSSI、PHF 等でも、意外と思わぬセキュリティーホールやアタック等が発生する場合があります。まず、パラメータとして渡す引数のチェックを行わないと、UNIXのSHELLで許されている連続実行等を許してしまうケースがあります。また、最近大流行のチャットや掲示板等においても、HTTP_REFERER を用いた自サーバーを閲覧した後の投稿、連続発言の制限、一定のシリアル番号等を用いた動的な発言許可、及び、適度な HTML タグの制限を行わなければ、荒らし等の行為でサーバーストール、他のチャットへのいたずら自動発言、もしくは、参加者のブラウザクラッシュ、場合によっては、それらのブラウザに搭載している Javaアプレット、Active-Xアプレット、Javaスクリプト、VBスクリプト、ASPスクリプト、BATスクリプト等からディスクフォーマットまでさせるというような事が場合によってはできてしまいます。ちょっと古いブラウザでしたら、確認もせず即実行されてしまいます。

pop3サービス

 ポート0番において、TCP/UDPで利用可能な、メール受信サービスです。メールサーバー以外であればこのサービスは /etc/inetd.conf のエントリから削除すべきです。また、APOPと呼ばれる機能を有効にしておかない限りメールのパスワードは暗号化されずに送信されます。

authサービス

 ポート3番において、TCP/UDPで利用可能な、ポート番号照会サービスです。これらの内容にはクラッキングの参考となる情報が提供される為、/etc/inetd.conf のエントリから削除すべきです。

netstatサービス

 ポート番において、TCP/UDPで利用可能な netstat コマンドの代わりのサービスです。これらの内容にはクラッキングの参考となる情報が提供される為、/etc/inetd.conf のエントリから削除すべきです。通常では、ログオン後に netstat コマンドを実行することで調べることができますので、閉鎖したことによる影響はないはずです。

imapサービス

 ポート3番において、TCP/UDPで利用可能な、メール受信サービスです。imapサービス自体はまだはじまったばかりで、意外とセキュリティーホールがまだ残っている可能性があります。どうしてもサービス提供したいのでなければ /etc/inetd.conf のエントリから削除すべきです。また、大抵のパッケージを導入すると、imap が使用できる状態になっています。メールサービスを使用しないのであれば、必ず削除するようにして下さい。

loginサービス

 ポート3番において、TCPで利用可能な rlogin サービスです。条件によってはパスワードを確認せずにユーザーのログインを許す為、ポート自体を閉じておくとよいでしょう。

shellサービス

 ポート4番において、TCPで利用可能な rsh サービスです。条件によっては login と同様にパスワードを確認せずにプログラムの実行を許す為、不安であればポート自体を閉じておくとよいでしょう。

NFSサービス

 ポート1番等において、TCPで利用可能な sun rpcサービスです。SUN Microsystems がUNIX用にネットワークファイル交換を目的に開発されたもので、多くのUNIX等で使用されていますが、セキュリティーの設定を厳密に行わないと容易に他のホストから参照できる等のことがあります。不要であればサービスを停止しておくことをお薦めします。

 これら以外のサービスであっても、不明なサービスに関しては基本的に閉じておく必要がありますが、逆に、安易の閉じすぎてばかりいても、提供すべきサービスが提供できなかったりする事もありますので、「何をやりたいか?」を念頭にもって設定する必要があるかと思います。

外部アクセスからの制限について

 UNIXにおけるネットワークサービスのプログラムを動作する方法として2種類あり、そのひとつはアプリケーション自身が常駐しリクエストを受け付けるもの、それと、inetd のみが常駐して要求に応じてそれぞれのアプリケーションを起動する方法があります。

アプリケーション自身が常駐するもの

 システムにアプリケーションが常駐することにより、外部からのリクエストに対し高速に応答することができます。しかし、それぞれのプロセスが select 状態になる為には、メモリ、及びCPUパワーを必要とすることがあります。また、接続制限を行う場合も、自前で行なう必要があります。

inetd を経由して、TCP Wrappers※ で制限する。

 inetd というアプリケーションが常駐し、inetd が受けたリクエストに対し、「/etc/inetd.conf」に記述してあるそれぞれのプログラムを起動するものです。こちらの場合はまとめてアクセス制御等を行うことができるものの、inetd、及び、アクセス制限をしている場合は TCP Wrappers を経由する分だけ多少遅くなります。しかし、常駐しているものは inetd のみなので、メモリ及びCPUパワーは大きく必要はありません。しかし、inetd で制御できるできる内容もあまり多くはなく、OSにもよりますが、大量の同一サービスのリクエストが接続された場合に、OSによっては最大起動数制限がない為メモリが大量に必要とされる場合もあります。

※ 一部OSにおいては、TCP Wrappers は標準でインストールされません。/etc/inetd.conf の中に tcpd を起動する部分が存在しない、もしくは、/usr/sbin/tcpd、/usr/local/sbin/tcpd 等が存在しない場合はインストールされません。セキュリティーを向上させる為に必ず導入して下さい。

tcpserver を利用する。

(後記:daemontools等も含む)
 inetd の代わりとして一部で注目されているのが tcpserver です。inetd 単体ではできなかったホスト名制御、接続数の制限等が可能です。また、inetd 及び TCP Wrappers の両方の機能がひとつの tcpserver として集結されていること、及び、TCP Wrappers で使用する hosts.allow、hosts.deny 等のような内容がハッシュ化DBにより格納される為、接続速度が高速という利点もあります。

ルーターによるパケットフィルタリング処理

 個々のサーバーマシンにおいて設定するのではなく、インターネットに接続する為のルーターにおいてフィルタリングを行う方法です。すべてのサーバーに対して一斉にパケット拒否を行うことも可能で、かつ、個々のサーバーに対しても設定が可能です。この場合においては、個々のサーバーにおいてセキュリティーに関する誤りの設定があってもルーターでカバーできる部分がある為、多少は安心できるでしょう。

非公開サーバーを別サブネットに配置する。

 ファイアーウォールや、IPマスカレード、又は nat※を用いて外部から見れなくする方法です。本書では特に説明はしませんが、IPマスカレードを行って、外部から見れないからといって、セキュリティーレベルが上がったとはいえません。あくまでもその補助に過ぎないことを念頭において下さい。

※ IPマスカレード、nat  これらの機構は、LAN側とWAN側のIPアドレスを変換してインターネットに情報を送るひとつの手段です。通常はプライベートネットワークをLAN側に指定する為、外部から直接IPアドレスを指定しての攻撃は避けられ、少ないWAN側IPアドレスに多数のクライアントを接続できるなどのメリットがあります。昔は、Linux の IPマスカレード等が流行していましたが、今では ISDNルーター等によく用いられています。

スイッチングハブ、セキュリティーハブの導入

 スイッチングハブはネットワークのパケット処理を最小限にする為に開発されたものですが、セキュリティーに関しても大きな効果があります。また、セキュリティーハブは、セキュリティーを重視したパケット配送するもので、スイッチングハブの同等の機能をより特化させたものです。

 従来のハブですと、自サーバー以外のリクエストに関してもパケットがLANカードに流れてしまう為 tcpdump やパケット盗聴ツール等で同一ネットワークの他のサーバに流れるべき情報(パスワードも!)が見れてしまうことがありますが、スイッチングハブを導入することで必要なパケット以外を送信しない為、被害を最小限にすることができます。特に、同一ネットワークに多数のホストを導入されている方は、導入を今すぐ検討されたほうがよいかと思います。Base-Tの製品であれば、最近は非常に安価になっています。

セキュリティー設定方法

/etc/services ファイル

 TCP/IP におけるネットワークサービスに接続する手段として、TCPポートとUDPポートを使用します。TCPはデータ転送の信頼性を優先したもので、エラー確認を行います。しかし、マルチメディアコンテンツ、NFS、及び一部のメッセージングサービスにおいては UDP等が用いられます。これらはエラーチェックを行わないかわりに高速に転送することができるからです。また、自前でエラーチェックを行うことによりTCP以上の信頼性を確保することもでき、かつ高速です。

 TCPポート、UDPポート、共に 1~5 の値で各種サービスのポートが割り振られています。これらは OS をインストールした時点において標準でインストールされる為、、特に新しいネットワークサービスを用いない限り変更する必要はありません。

 変更する必要はないものの、このファイルを参照して、個々のサービスについて、どのようなものかは認知しておく必要があります。後で説明する /etc/inetd.conf 等で不必要なサービスを閉じるのにも必要です。

写真:/etc/services
(画像:services編集画面-1.gif)

/etc/inetd.conf ファイル

 /etc/inetd.conf ファイルは、ネットワーク接続があった時にどのアプリケーションをどのような方法で起動するかを記述するものです。

---------------------------------------------------
| /etc/inetd.conf の記述方法
|
|  サービス名 ソケット種別 プロトコル フラグ 実効ユーザー 実行するプログラム 引数
|
| 行頭に「#」を記述すれば、コメントとなる
| サービス名:/etc/services に記述されているサービス名
| ソケット種別:TCPの場合には「stream」
|               UDPの場合には「dgream」
| プロトコル:TCPの場合には「tcp」
|             UDPの場合には「udp」
| フラグ:「wait」切断されるまで他の要求を受けつけない
|         「nowait」切断しなくても他の要求を受け付ける
|          TCPの場合には、「nowait」を指定する。
| 実効ユーザー:プログラムを実行するアカウント
| 実行するプログラム:起動するプログラム名
| 引数:プログラムに渡す引数
---------------------------------------------------

 不要なサービスがある場合には、inetd.confにある不要なサービス行を削除、もしくは、コメント行にすることでそのサービスを止めることができます。

 また、inetd.conf においては、他の方法でリクエストを受け付けるものと共用することはできません。例えば、ポートの HTTPサービスで、Apache等がデーモンとして動作しているにも関らず、inetd.conf において指定することはできません。また、1つのホストでTCP/UDPの共有もできません。

 inetd.conf を書き換えたら、その設定を有効にする為に、inetd に対して HUPシグナルを送信して下さい。

---------------------------------------------------
| kill -HUP `cat /var/run/inetd.pid`
---------------------------------------------------

写真:/etc/inetd.conf
(画像 inetd-conf編集画面-1.gif)
(画像 inetd-conf編集画面-2.gif 上記の続きです。)

TCP Wrapper

 inetd と組み合わせて使用できる、ホスト制限機能です。許可されたホスト以外からの接続要求があった場合、ネットワークアプリケーションを起動せずに切断することができます。

---------------------------------------------------
| TCP Wrapper に対応した /etc/inetd.conf の記述方法
|
|  サービス名 ソケット種別 プロトコル フラグ 実効ユーザー /usr/sbin/tcpd 引数
|
| なお、tcpd の位置はOSによっても異なります。
| ex) /usr/local/sbin/tcpd、/etc/tcpd 等
---------------------------------------------------

hosts.allow/hosts.deny の記述方法

 hosts.allow、hosts.deny は次のようにして記述します。

---------------------------------------------------
| hosts.allow、hosts.deny の記述方法
|
|  引数: ホスト名
|
| 引数は、inetd.conf で記述した tcpd に対する引数
| ホスト名は、下記のとおり
| ホスト名で記述:ある特定の1台を許可/拒否
|    例) wu.ftpd: win.example.co.jp
| ドメイン名で記述:「.ドメイン名」で記述
|  例) telnetd: .example.com
|  IPアドレスで記述:ある特定の1台をIPアドレスで指定
|  例) in.pop3d: 2.8.0.
|  ネットワークアドレスで記述
|  例) in.rshd: 2.8.0.0/5.5.5.0
|  ALLで記述
|  例) in.rlogind: ALL
|  EXCEPTを指定すると除外を示す
|  例) in.execd: EXCEPT 2.8.0.0/5.5.5.0
|  例) in.execd: EXCEPT 2.8.0.0/5.5.5.0
---------------------------------------------------

 基本的には、特定のホスト以外からのアクセスは拒否する設定となりますので、hosts.deny には ALL で指定し、hosts.allow には、許可したいホスト、ネットワークアドレス等を指定することとなります。

 hosts.deny で ALL で制限した時には、自ホスト(7.0.0.1)の指定を hosts.allow に加えておかないと、正常に起動できないサービスが一部出てくることがあります。

 なお、hosts.allow/hosts.deny は OSにより位置が異なります。/etc/hosts.allow、/etc/hosts.deny もしくは /usr/local/etc/hosts.allow、/usr/local/etc/hosts.deny 等が一般的です。

 ・hosts.allow、hosts.deny の設定例   wu.ftpd、in.pop3d 以外は2.8.0.0/5.5.5.0のみ許可する

---------------------------------------------------
| hosts.allow
| -----------
| wu.ftpd in.pop3d: ALL
| ALL: 2.8.0.0/5.5.5.0
|
| hosts.deny
| ----------
| ALL: ALL
---------------------------------------------------

  in.telnetd のみを特定のドメインから許可するが、その他は拒否しない

---------------------------------------------------
| hosts.allow
| -----------
| in.telnetd: .example.com
|
| hosts.deny
| ----------
| in.telnetd: ALL
---------------------------------------------------

hosts.equiv、及び .rhosts

 rsh、rlogin、rcp コマンドで使用するファイルですが、これらのファイルを設定することで認証を省略してログイン、ファイルのコピーのやりとりをすることができます。しかし、あまりセキュリティー上好ましくない部分もありますので、これらのファイルは設定しないようにして下さい。特に .rhosts を指定することで、その記述されたホスト名からパスワード認証なしにログインできてしまうので、注意が必要です。

 なお、hosts.equiv は、localhost のみを記述しておくことで、rsh、rlogin、rcp コマンドで他のホストからの要求がある場合、パスワードを要求、もしくは拒否を行います。

ルーターによるIPアドレス、ポートによる制御

 専用線、ISDNルーター等では、サーバーに情報が到達前に不必要な攻撃等を事前に防ぐことができ、かつ、いろいろな種類の制御方法があります。基本的には、ルーター上で設定できるip filter コマンドを用いることで設定ができます。しかし、初心者を意識しているご丁寧なルーターの標準設定で、外部からの侵入防止という意味合いでほとんどの外部からのリクエストを遮断しているルーターも中にはあります。 ルーターにおいては、下記のような高度なパケット制御を行うことができます。

 ・内部から外部のみ、外部から内部へのパケットを許す設定  一般的に、内部から外部、外部から内部へのパケット送信を意味します。しかし、実際にはインターネットでは、単方向通信というのはなく、コマンドを送信し、その結果を返すというようなクライアント/サーバー方式によるパケットがかなりあります。その為、このようなパケット制御しかできないルーターでは、送受信共に許可、もしくは拒否の設定をすることができません。

 ・内部からリクエストしたパケットのみを許す設定  上記のように、インターネットでは送信した結果を返すというような方式で基本的には成り立っています。しかし、送信だけを許可し、受信だけを拒否するといったことは事実上不可能です。そのため、ACKビットというフラグを用いて、リクエスト、及び、リクエストに対する回答のような送受信内容の判別を行います。

 ルーターにより、これらの設定コマンドは違う為、本書では特に説明致しませんが、これらの写真のように、最近ではWebで設定できるルーターが増えてきています。詳しくはルーターの取扱説明書をご覧下さい。

写真:MN8-SOHO SL の IP応用設定
(画像:MN8設定画面-1.gif)

写真:RTAi ネットボランチの IP Filter 設定
(画像:ネットボランチ設定画面-1.gif)

写真:RT0e のシリアル接続によるルーター設定の例
(画像:RT0e設定画面-1.gif)

ルーター自身のセキュリティー

 ルーターは、今まで使用されてきたモデムやTA等のかわりとして、LANからインターネットに接続できる便利なものです。しかし、モデムやTA等の感覚で使用していると、知らないうちにあなたのルーターは公開ルーターになってしまいます。公開ルーターになってしまうと、下記のようなクラック行為が容易にできます。

 ・ルーターのtelnet機能を用いて踏み台行為  アクセス元がバレずに、安心して別のサーバーをクラックできます。そうすることえ、クラックされた方のサーバー管理者、もしくはプロパイダ経由で苦情のメールが来るでしょう。

 ・ルーターの設定が変えられる  せっかく設定したフィルタ等が無効になってしまい、内側のネットワークへの侵入を容易にすることになります。もしくは、ルーティング情報を改竄して、あなたのルーターの内側からインターネットを見えなくすることもできます。

 このようなことをされないように、最低限、これだけのことは行って下さい。

 ・ルーターのパスワードの設定  何故ルーターにパスワードがある理由がわからない方は、今すぐルーターの電源を切り、取扱説明書を熟読して下さい。

 ・ルーター自身を公開しないこと  ルーター自身を公開するということは、ルーターの存在を公開するという意味ではなく、ルーターの設定機能を公開するという意味です。telnet、tftp、Web 等が挙げられるでしょう。これらは、基本的に ip filter コマンド等で設定できます。ルーター自身のIPアドレスに対して、外部からの拒否設定をすべて行うことをお薦めします。なお、大抵のルーターは上記のような拒否設定をしたからとはいえ、ルーティングには影響ありません。

 ・ファームウェアを適時アップデートすること  ルーターにもファームウェア、いわゆるルーターの為のソフトウェアというものがあります。しかし、買ったばかりのファームウェアで、1年後どんな新たなアタック手段があるかは、誰も予測することができません。その為に、ファームウェアはルーター製造メーカーがいつもバージョンアップ等を行っています。これらのバージョンアップを行わないことによって、新たなセキュリティーホールが生まれる手段となるでしょう。最低でも発表されてから2ヶ月以内にファームウェアを更新することをお薦めします。

これらのルーターは、Web 上でマニュアルを掲載していますので、購入前にどのような設定ができるか確認することができます。

アクセスログを見てみよう

 システムへの不法侵入を防ぐには、まずアクセスログ等を取得して、何が起きたかを把握しておかなければなりません。  アクセスログには、UNIXで備わっているsyslog、及びそれぞれのアプリケーションで独自にとるログ等があります。本書においては、syslog、及び Apache のアクセスログ、sulog について紹介します。

syslog の設定

  syslog は、UNIXにおいて標準で導入され、大抵のアプリケーションが使用します。大抵のシステムでは /usr/sbin/syslogd 等の位置に導入され、設定は /etc/syslog.conf で行います。

 ・syslog.conf   syslog.conf は、次のように記述します。

---------------------------------------------------
| /etc/syslog.conf の記述方法
|
|  ログの項目名 (タブ) 出力先ファイル名
|
| 先頭が「#」ではじまる行はコメント行
| 項目名と出力先ファイル名の間は、必ずタブで区切ること|
| ログの項目名は、ファシリティーとプライオリティーの
| 組み合わせ
|
---------------------------------------------------
  ログの項目名とは、表xxx−1にありますファシリティー、表xxx−2にありますプライオリティーの組み合わせで設定され、それらを複数設定することができます。

表xxx−1 ファシリティー

ファシリティー 意味
auth、security   認証サービス
auth-priv       プライベートな認証サービス
cron            cronサービス
daemon          各種デーモン(常駐プログラム等)
ftp             ftpサービス(無いシステムもあります)
kern            カーネル
lpr             印刷サービス
mail            メールサービス
news            ニュースサービス
user            ユーザープログラム
uucp            UUCP関係
local0~local7   アプリケーションが自由に使用できる

表xxx−2  プライオリティー(下にいく程プライオリティーが高い)
debug           デバッグ用のメッセージ
info            各種情報
notice          注意のメッセージ
warn、warning    警告のメッセージ
err、error       エラーメッセージ
crit            致命的なエラーメッセージ
alert           直ちに修復を要する重大なメッセージ
emerg、panic     処理続行不可能な程度の非常に重大なメッセージ

 ・ログの項目名の設定   ログの項目名は、ファシリティーとプライオリティーの組み合わせで設定します。

---------------------------------------------------
|「ファシリティ.プライオリティ」と記述
| 指定したプライオリティーより高いものすべてが対象
| 例) mail.warn の場合、「mail.warn」「mail.err」「mail.crit」「mail.alert」「mail.panic」が対象
|
|「ファシリティ.=プライオリティ」と記述
| 指定したプライオリティーのものが対象
| 例) mail.warn の場合、「mail.warn」が対象
---------------------------------------------------

  また、「!」を記述して否定を指定したり、「*」を記述して「すべて」と指定したりすることもできます。複数のログ項目名は「;」で区切って指定します。

 ・/etc/syslog.conf の設定例   設定例のを紹介します。

  ・「mail」に関するすべてのログを /var/log/maillog に記録する

---------------------------------------------------
|mail.*    /var/log/mail
---------------------------------------------------
  ・すべてのファシリティーに関する「err」の情報のうち、「mail」に関するものを除いたものを /var/log/err に記録する
---------------------------------------------------
|*.err;!mail.*    /var/log/err
---------------------------------------------------
  ・authに関するもののうち、auth.warn以上のものを /var/log/auth に出力するが、auth.crit のみを /var/log/authcrit に出力する
---------------------------------------------------
|auth.warn;auth.!crit   /var/log/auth
|auth.=crit             /var/log/authcrit
---------------------------------------------------
  その他、同一のファイル名で出力される行を複数行において設定してはならない、他にも、同一のファシリティー、プライオリティーを複数のログに出力できる等もあります。

ログを別のホストに出力するには

 「ログのファイル名」の所に、「@ホスト名」と記述します。  たとえば、すべてのファシリティーのエラー(err)よりプライオリティーの高いものを sysloghost というホストに出力するには
---------------------------------------------------
|*.err  @sysloghost
---------------------------------------------------
 と記述します。しかし、syslog を受ける側にも設定が必要です。  ・/etc/servicesの設定   /etc/services に
---------------------------------------------------
|syslog    4/udp
---------------------------------------------------
 という項目があるか確認します。

 ・rc 初期化ファイルの syslogd 起動方法を変更する   Linuxの場合は、rc 初期化ファイル (/etc/rc.d/* 等) の中にある、syslogd の起動部分に、「-r」オプションを加えます。

---------------------------------------------------
|/usr/sbin/syslogd
| を
|/usr/sbin/syslogd -r
---------------------------------------------------

  FreeBSDの場合は、標準で syslog パケットを受信できるようになっています。外部からの攻撃対策の為に、rc コンフィギュレーションファイル (/etc/rc.conf)の中にある、syslogd_flags に「-a IPアドレス/マスク」を加えます。また、Linuxの場合でも、このような形でアクセス制限をすることをお薦めします。

---------------------------------------------------
|syslogd_enable="YES"
|syslogd_flags="-a 2.8.1.0/"
---------------------------------------------------

  その他、ログを受け取るホスト等の制限等の設定できます。詳しくは、「man sysklogd」、「man syslog」、 「man syslogd」等のマニュアルで調べてみて下さい。

syslogの見方

 ログ閲覧ソフトを用いて見るケースもありますが、大抵は指定したキーワードに対して grep 等でフィルタリングしたり、tail コマンドでリアルタイムに見る等の方法もありますが、他にもスクリプトを組まれてその集計をメールで送信する等の方法もあります。一部のOSには、これらのsyslogの集計結果を毎日 root 宛に送信するものもあります。root で直接読まないのであれば、/root/.forward ファイル等にメールの転送先を指定すれば、普段お使いになられているメールソフトで閲覧することができます。

写真:FreeBSDから毎日送られてくるセキュリティー情報メール
(画像 セキュリティー情報メール-1.gif)
(画像 セキュリティー情報メール-2.gif)
(引用 セキュリティー情報メール-3.txt)

その他のアクセスログ

 ・Apache のアクセスログ
  WWW 閲覧者のアクセスログです。Apache 自体が直接的にセキュリティーホールに関係することはありませんが、CGI/SSI/PHF 等に対するアタック等がある場合があります。analog 等のソフトを用いて解析してみるのもよいかと思います。

 ・/var/log/sulog
  su コマンドでスーパーユーザーなったことを記録するログです。

 ・lastlog コマンド
  telnetやFTPでログインしたユーザーが最新から順に表示されます。アカウントとリモートホストを対応付けして、クラックされていないかどうかチェックする手段のひとつとなります。

物理的セキュリティー

 これで外部からの侵入には十分に対処できたと思います。しかし、あなたの会社、いや友人等に内通者等がいて、その人がある程度の操作できるとなればどうでしょうか?実は、それぞれの起動ディスクがあればそれらのセキュリティーは「無い」に等しいものとなります。ここでは、いろいろな物理的セキュリティーの対処方法を紹介します。

最低限、OSの起動ディスクは近くにおかないこと。

 ホストを再起動等を行い、起動ディスクを入れておくことで、パスワードなしのrootでログインできます。そして、mount コマンドを知っていれば、いつでもすぐに、/etc/passwd の内容をコピー、改竄ができてしまいます。

FDDドライブ、CD-ROMドライブに、何かテープを張りつけておき、封印する。

 FDDドライブ、もしくはCD-ROMドライブに何か入れたということがすぐわかると思いますが、既に入れられて何かされてたらアウトです。

BIOS で FDDドライブを使用不能状態にする

 BIOSの設定により FDD ドライブを殺すことができるものがあります。FDD ドライブを認識させないようにして、起動ドライブを第1ドライブ(C、もしくは、IDE もしくは、SCSI)に設定し、最後にBIOS 設定のパスワードを設定すれば完了です。

FDDドライブ、CD-ROMドライブを抜いてしまう

 物理的にFDDドライブ等を抜いてしまえば、そのサーバーに何らかの方法で不正ログインしようにも、電源を落とす以外ありません。

いっそのことVGAカードも抜いてしまう?

 あまり大きな効果はありませんが、現在のコンソールの状態を見られないという意味では多少安心できる場合があります。自作サーバー等であればAward 系の BIOS であれば可能です。しかし、何か、常にモニターをしたい場合においては、抜いてしまっては何もできなくなってしまうでしょう。

リセットスイッチのコネクタを抜いておく

 意外と誤ってリセットスイッチを間違えて押してしまうことというのは、結構あるものです。不必要であればマザーボードのコネクタから抜いておきましょう。

電源スイッチもショートさせておく。(ATX型のみ)

 電源スイッチも ATX型であれば、裏にメインパワースイッチがあると思います。マザーボード上の POWER コネクタをショートさせておけば裏の電源スイッチをON/OFFにすることで投入ができます。表のスイッチが心配な方はこの方法を試してみてください。また、停電等があった場合、ATX型の場合は電源スイッチを押さないと起動しないのですが、ショートさせることで停電復帰後に勝手に起動してくれると思います。AT型や、その他のサーバーでは不必要なこともあります。なお、誤って、裏の電源スイッチをショートさせて感電しても保証は致しかねます。

それでも心配?やはり鍵のかかる所に入れる

 予算はかかると思いますが、どうしても心配ならこれしかないかと思いますが、最も安全な方法ではあるでしょう。

ハードディスクの管理には要注意!

 物理的セキュリティーとして、意外と重要で忘れられやすいのが、ハードディスクの管理です。サーバーを分解され、ハードディスクを別のマシンにマウントを行って、/etc/passwd 等を変更することも可能ですし、意外と見落としな所で電源投入時において、ハードディスクが正常に接続されていない、もしくは、ハードディスクの物理・論理エラー等の理由で正常に起動できずに、いきなり root 権限のシングルモードに移行することがあります。これらは、ディスクの安全性を確保する為に用意されているものですが、これにより /etc/passwd 等のパスワードファイルを簡単に改竄することができます。特に外付けハードディスクを使用している場合においては、コネクタをしっかりと固定し、何らかの方法でマークをする、外づけハードディスクの電源を封印する等という方法をお薦めします。また、定期的なディスクチェックもお忘れずに!

その他、各種セキュリティー情報

OSのセキュリティーホール

 フリーのUNIXであるLinux、FreeBSD等、及び、商用UNIXにおいても、最近ではクラッカー等が増えていることもあり、いろいろとセキュリティーホールが発覚しています。大抵は、DoSアタック等のセキュリティーホールではありますが、お互いいたちごっこかのように、どんどん増えてきています。

 最低でも、下記のバージョン以上に挙げておくことをお薦めします。もし、バージョンアップが容易に出来ない状態であれば、再インストールをされることをお薦めします。

 ・Linux : カーネル2.2.5 以上(最低でも、2.0.)
 ・FreeBSD : 3.1-RELEASE以上、2.8-RELEASE、2.8-STABLE
 ※ 執筆時当初のセキュリティー情報による

sendmail におけるセキュリティー

 sendmail プログラムはかなり古いインターネットからの伝統を受け継いでいることもあり、いろいろな方法でメールが送信することもできます。その為、非常にソースコードが膨大になり、更に、すべてが root 権限で実行され、SUID※ を行っていることもあり、過去に頻繁にセキュリティーホールが発覚しています。常に最新版を使用されることをお薦め致します。

 また、現状においてすべてのバージョンで、ローカルユーザーが mail queue を埋めつくすというDoS攻撃も発覚しています。MaxMessageSize を設定したり、ログをこまめにチェックして、未然に防止することをお薦めします。

※ SUID プログラムが必要な時に、他のユーザーから root 権限、もしくは、更に他のユーザーへ権限を設定するものです。誤ったプログラムでセキュリティーホールが出た時には非常に危険です。nobody ユーザーでも簡単に root になれるチャンスですので・・・

qpopper POPサーバー

 APOPにも対応しており、最近人気の高い POP サーバーです。古いバージョンですとセキュリティーホールが発覚していますので、最新バージョンに更新されることをお薦めします。

Free Servers from Eudora:

 本書執筆時には、2. 及び、3.0β がリリースされています

qmail sendmailの代わりとなる安全なMTU

 qmail は、モジュールごとにプログラムが分割され、かつそれぞれの専門のユーザーを登録することにより、非常に安全にメールを配信することができます。また、簡潔に出来ていることにより、プログラムの奥底から出てくるようなセキュリティーホールもまず出てこないとみなしてもよいかと思います。また、SPAM対策においても、sendmail に比べ、非常に簡単に設定でき、ソース解析等もモジュールが少ない為、ある程度のCプログラミングができる方であれば自分でパッチも作成することも不可能ではないですが、他のMTUとは違い、一切のパッチがなくてもしっかりとした動作をしてくれるでしょう。また、sendmail のように、共有スプールで1ユーザーを1ファイルとしてメール管理するのではなく、各ユーザーディレクトリに1通ずつ1ファイルにしてメールを管理するのも、ハードディスククラッシュから耐えやすいのもあります。また、単体ではできませんが、qmapop-0.3.tar.gz を用いて、かつ、それを改造することで、APOPサービスを提供することもできます。(但し、最新版の qmail-1..tar.gz に対して適用するには多少の改造が必要です)私の運営していたレンタルサーバーにおいても、sendmail ではなく qmail を使用しています。

telnet サービス

(追記:現在、telnetなんてつかわないでしょう・・・
 でもローカルネットでは案外まだ有用なんですよね。
もし、使う場合は、tcpserverを用いて、外部IPと内部IPを分離したり、
VPN暗号化通信経由でして下さい。)

 各OSにそれぞれ付属している重要な位置をしめるサービスのひとつです。単体におけるセキュリティーホールはあまりないものの、他の連携によるセキュリティーホールがまちまちです。シャドウパスワード、及び tcpd、又は ルーターの設定においてセキュリティーを確立することができます。とはいえ、外部接続からの信頼できる接続かどうかといえばそうは保証できたことではないかもしれません。なるだけ ssh における接続に移行することをお薦めします。

ftp サービス

 ftpサービスにも、多数の種類がありますが、この中でも wu.ftpd 等は非常にメジャーではあるものの、ある時期のバージョンまでは、バッファオーバーラン等のセキュリティーホールが発覚しています。可能な限り最新バージョンを使用するよう心がけて下さい。  また、Anonymous FTPによる、incoming ディレクトリによる匿名アップロードによる不正ファイル交換等にも注意すべき所です。著作権違法ファイル等をやり取りする上でも、簡潔であるというのも要因でしょう。

ssh サービス

(商用のsshは今ない?)
 sshdには、フリー版、商用版があり、それぞれバージョンが異なります。商用版である Version 2系は、フリー版よりも高度なセキュリティーを保つことができます。詳しくは ssh 関連のURLをご覧になって下さい。

NFS サービス

 多くの Linux パッケージで NFS マウントデーモンとして収録されている mountd プログラム (rpc.mountd という名前でインストールされます)のいくつかのバージョンにおいて、リモートから管理者権限でコマンドを実行等のようなことができるセキュリティーホールが最近発覚されています。これにより、システムにおいて重要なファイル等を改竄されたりして、破壊される場合があります。通常、Webやメールサーバーに使用される場合は特に不要なサービスですので、特にわからないという方は rpc.mountd 起動部分を削除されることをお薦めします。

 また、NFS 自体においても、標準でインストールされているものに関しては、生のデータを直接やりとりしたり、簡単な認証のみでアクセスできたりするようなこともあります。NFSサービスをやむなく使用される場合は、セキュリティーには充分な配慮を講じる必要があります。

 NFS マウントデーモン mountd を悪用したアタックに関する緊急報告

その他、セキュリティー関係サイトの紹介

 JPCERT/CC コンピュータ緊急対応センター   国内で有数の、コンピュータにおける不正アクセスを専門に取り扱っている機関です。

攻撃する側の改竄事例

 攻撃して来る人というのは、攻撃したサーバーを踏み台にして他のサーバーを攻撃したり、パスワードを盗み出して内輪で売買を行ったり、他にも、サーバーに届いたメールを .forward、もしくはそれに類する方法で他に転送したり、ましては、そのサーバーのデータを書き換えたり、DNSを書き換えて偽ホストを作るなどの目的で来ています。これらの人々は、root を取得すると、大抵はサーバーのアクセスログを何らかの方法で停止にしたり、もしくは syslogd 等を改竄して、偽情報を書かせたり等をまずします。そして、必要であれば、ls コマンド、ps コマンド、whoコマンド等を書き換えて、他の人に攻撃者が見つからないような手段を講じます。その後、/etc/inetd.conf を書き換えて、今後侵入しやすいようにしたり、それを書き換えたことがバレないように隠しディレクトリ「...」上の inetd.conf を使用する inetd にすり替えたり等いろいろ行います。この時点で、既にあなたのサーバーはほとんど再インストールしない限りは元の状態には戻れないとはいえるでしょう。参考までに、書き換えた例をいくつか紹介します。

---------------------------------------------------
|inetd.conf の例
|
| klogin stream tcp nowait root /bin/bash bash -i
---------------------------------------------------

これは、klogin ポートから直接 telnet でログインすることにより、root 権限で認証なしにシェルを起動する例です。このような状態になれば、どこの誰もが簡単にそのサーバーに root 権限でログインできることを意味しています。

---------------------------------------------------
|隠しディレクトリの例
|
|sv:/usr/X/include# ls -a
|.        ..         ...      X
---------------------------------------------------

ディレクトリ . は、自分自身のディレクトリを差します。 ディレクトリ .. は、上位のディレクトリを差します。 しかし、ディレクトリ ... は、... という名前そのもののディレクトリです。 ls コマンドでドットファイルの一覧が省略されるのが標準になるシステムでは見落としがちです。 このようなディレクトリが作られていれば、大抵、クラックされてるといえるでしょう。

---------------------------------------------------
|実際にクラックする時までの手段
|
|・ネットワークサービスのセキュリティーホールを利用
|  Apache/PHF、sendmail、INN、imap 等
|・/etc/passwd を入手し、パスワードの辞書アタック
|・OS自体のセキュリティーホール(suidプログラム)
|・トロイの木馬、パケット盗聴ツール等の導入
---------------------------------------------------

しかし、内容の多少の破壊、改竄等は必ずといっていい程されるものですが、何故かサーバーハードディスクの初期化をされる等の損害は不思議と少ないのが現実です。(何せ、フォーマットしてしまえば自分の踏み台となるホストが1つ自分自身で潰してることとなる訳ですから・・・)

実際にクラックされってしまったら?

 実際に何らかの方法でクラックされたら、どうすればよいのかわからない方もかなりいらっしゃると思います。

 ・侵入者がいる間は、下手にサーバーを落とさない

  もし、サーバー等に重要な機密情報(個人情報も含)等のファイルがなければ、クラックされている間はサーバーを落とさないようにして下さい。その最中に、クラック用のすり替えツール等をインストールしており、そのインストールが再起動等で失敗することにより、逆にシステムが破壊し、システムが起動できなくなるような事で重要なファイル等を待避すらできなくなる場合があります。パスワード等の情報は、極論からいえば、あとでいくらでも新たに設定できます。危険をおかしてまでサーバーを落とさないようにして下さい。場合によっては、OS 起動カーネルが削除されている可能性もありますので・・・

 ・侵入者を常に監視し、いなくなったと確認したらまず何をやるか?

  ユーザーアカウントのみがクラックされたと判断された場合は、まずはパスワードの変更を行って下さい。この場合はシステムファイルまでは変更されていないと思います。また、そのユーザーがどこからログインするかを、/etc/login.access 及び、TCP Wrappers、もしくはルーターのパケット制限において制御することも必要です。

 もし、ここで、root がハックされてしまった場合、OS の再インストールをお薦め致します。ひとつひとつ、端から端までどのファイルが書き換えられたかをチェックするよりは楽です。実際の所、ユーザーアカウントがハックされてしまった場合、明らかな簡単ないたずら行為以外であれば、大抵は root がハッキングできる可能性が非常に大です。不安であれば、何も考えずに OS を再インストールすることをお薦めします。

 上級者の方は、どのファイルが書き換えられたかをチェックするのもよいかと思います。その例として、まったく同じ構成な OS を用いて別のマシンをインストールし、タイムスタンプ、ファイルサイズを含んだリストを作成し、クラックされたサーバーと比較するという方法もあります。しかし、実際にクラックされていれば、ls コマンド等もすり替えられている可能性もありますので、共に FDD起動のレスキューディスクを用いて作業を行うようにして下さい。

 基本コマンド、cron、シャドウパスワード、ネットワークデーモン等を改竄するツールが実際に Web 上にて平気で公開されているのが実態です。本書はクラック方法を紹介する本ではありませんのでURL等は挙げませんが、どのようなことがされるのかということを理解しておくべきではあるでしょう。

 また、余力があれば、ポートスキャン等の攻撃対策スクリプトの制作、もしくは対策設定をするのもよいかと思います。

ドメインの個人情報について(実話)

 インターネットにおいて、World Wide Web がかなり流行したある日、某レンタルサーバーホスティング会社から、直接ある日本で活躍しているアイドルに電話がありました。  その内容は 「ホームページを作りませんか? 代行しますよ」  その答えは 「是非作ってほしいです」

 いろいろと沢山ある申込書に、アイドル自身が自分の住所、電話番号、本名も記載し、その某レンタルサーバーホスティング会社に郵送で送りました。その中には、InterNic の登録申請用紙のようなものも入っていたそうです。

 そして、ホームページは、某レンタルサーバーホスティング会社の手により、ドメインと共に世界中に公開されました。そして、毎日のタレント業務、他にもいろいろとメールでのお返事とかいろいろと忙しい毎日だそうでした。

 しかし、ある時期になり、突然、いたずら電話が毎日数10回も鳴り、更には、いろいろとファンレターまで直接そのアイドルの家に来るようになったそうです。週に1、2日程休みはあったそうですが、家の電話はうるさくて、結局切ってしまい、あまり広くない家の中に大量のファンレターが来るようになり、本人も一体どうしてこうなったのか、不思議がってたそうです。あとで、プロダクションの方から「ホームページを勝手に作ったでしょう?」とのお叱りを受けて、それでようやくどうしてこうなったのかが気づいたそうです。 InterNICでドメインの個人情報が公開されていることも・・・

 何の為の、プロダクションなのだか、本人は思い知らされたそうです。今現在では、そのいたずら電話、ファンレターのおかげで、引っ越してしまったそうです。

 このような例は、あくまでも特例ですので、あまり起こる例は少ないものの、他にも女性関係等が一部狙われたり、whois 情報を悪用したDM業者等も現れているというのは現状です。しかし、ネットワークというものを意識して頂く意味で、基本的には運用者本人の連絡先を提示できるだけの意気込みは必要です。どうしてもドメインによる個人情報の漏れを心配される方は、プロパイダ等に相談してみるのもよいかと思います。

アンケート

このことに関する話題