RIMNET CORPORATION リムネットが 工ンジニアを募集します。 1994 年、インターネット通信事業参入。 1997 年 8 月、日本初の国際インターネット電話接続サービスの開始・・ 新たな通信情報サービス事業の OPENER ( 開拓者 ) 、リムネットが、エンジニアを募集します。 単なる国内プロバイダーから世界市場の競争を勝ち取っていくマルチメディア事業者へ、 明日を拓くのは、あなたのカです。 0 リムネット 2 大コア事業 囚インターネット通信サービス事業 囘通信機器開発販売、システムインテグレーション事業 当社のコア事業で、インターネットを生かした通信サービス インターネットの拡大に伴う通信市場の拡大は、 2015 年には の開発を行っております。現在 6 万人のお客様にご利用 20 0 兆円産業ともいわれる成長市場。当社の先進的な いただくデータアクセスサービスに加え、国内・国際インターネット インターネットサービス事業のために開発メーカーと共同開発 電話サービス「リムフォンサービス」、今期開始計画中の された機器や、我々社内開発を行う決済システム、運営ノウハウ 「リムファックスサービス」など国際展開を図っております。また、 などをシステムインテグレーションとして他社に先駆けて販売 法人向け、通信事業者向けの各種ホスティングサービス、 する事業です。 ハウジングサービスなど、今後国際的なサービスインフラの 提供を図ります。 ①ネットワークエンジニア 職種 / 2 大コア工ンジニア 国内 2 カ所のネットワークセンター、米国ネットワークセンターのインターネット運用 仕事内容 / 左記参照 マネジメント、 PC 、電話、 FAX 等の国内外アクセスポイントの設計、設置、運用マ 給与 / 当社規定により優遇 ネジメントをコアタスクとするエンジニア 待遇 / 昇給 1 回、賞与 2 回、交通費別途支給、各種社会保険完 ・ホストマネジメント担当 備、ハワイ福利施設、ストックオプション制度導入予定 ・旧 te 厄 phony ・ FAX システムマネジメント担当 勤務地 / 渋谷休日休暇 / 週休 2 日制、祝日、夏季、年末年始 ・アクセス MODEM マネジメント担当 勤務体制 / ①シフト制 ・クレジット決済サーバ運用担当 (NT) 2 ) ④ 9 : 30 ~ 18 : 00 応募方法 / 希望職種明記の上、履歴書 ( 写真貼付 ) ・職務経歴 ② R & D 工ンシニア 書をご郵送ください。書類選考の上、追って面接の日 当社のインターネット関連サービスに関わる機器 ( 旧 telephony 、旧 fax 等 ) 時等詳細をご連絡いたします。 メーカーとの共同開発 : 技術評価、サポートマネジメントをコアタスクとするエンジニア ・プロダクト担当 E ai での応募、グループでの応募も歓迎いたします。 ・製品サポート担当 会社説明会 / 就職希望の皆様を対象に「会社説明会」を行ってい ます。詳しくはお電話にてご連絡下さい。 ③工ンシニア 開催日時 : 毎月第 3 水曜日 14 : より 囚事業に関わるバックオフィスシステム ( クレジット決済、ビリング、顧客サポート 等のシステム ) 開発、販売、サポートや、囘事業に伴う当社バックオフィス製品の 販売、システムインテグレーションサポートをコアタスクとするエンジニア 株式会社リムネット アドミニストレーション担当 設立 / 1987 年 3 月 アプリケーションコンサルタント 特別第二種電気通信事業者 ( 登録番号聞号 ) 主要株主 / KDD 東京三菱銀行ー田あさひ銀行日本生命 東京海上 ( ①セールスエンシニア 〒 1 東京都渋谷区南平台町 2-17 日交渋谷南平台ビル 4F 従業員 / 60 名社員平均年齢 / 28 才 国内、国際通信情報産業における当社の事業戦略を理解し、営業、代理店への 資本金 / 2 億 1780 万円 総務人事部 03-5489-5561 担当 / 秋山 技術的支援とマーケットニーズからの製品企画、開発、販売計画の立案をタスク 売上推移 / 6 億 5000 万円 ( 95 年 8 月末 ) 、 14 億円 ( 96 年 8 月末 ) 、 最新情報は当社ホームページをご参照ください。 とするエンジニア 21 億 8g0 万円 ( 97 年 8 月末 ) 、 33 億円 ( 98 年 8 月予定 ) http://www.rim.0「.jp/ ・インターネット通信サービス担当 280 年株式店頭公開予定 E-maiI job@rimnet.co.jp ・通信機器販売、 SI サービス担当 募集要項 募集職種 会社概要

連載 /UNIX Communication Notes—O 結果としてネットワーク全体に求められる性能を系隊 の企業内ネットワーク (enterprise network) 、あるいは する ) 流行の言葉でいえばイントラネット、工クストラネットで ・必要に応してユーサーに課金し、その処理に必要な竹喋 は、電子メールサービスと Web サービスの一 f ・分な管理は を実施 必要不可欠である。 ( 5 ) セキュリティ里 (security management) ( 8 ) 複染自ヒするセキュリティ里 ネットワーク竟におけるセキュリティ保全にかかわる 前項で触れたセキュリティ管理は、きわめて曖昧かっ広 すべての作業である。具ー勺には、次のようなものがある。 義のセキュリティ対策である。しかし、現在のネットワー ク運用では、ネットワーク機能だけでなく、システム管理 矍すべき情報ク井芋定 とも叫秀したセキュリティ対策カ球められている。具イ勺 ・その情報に対するアクセスポイントの同定 には、次のような作業か含まれるようになってきた。 ・アクセスポイントの保全と制限 ・安全な通信路の確保 新たに考えなければならない管理作業 最近、普及し始めた VPN (Virtual Private Net- 前項で述べた 5 つの分類は、ネットワークだけを管理 work) のように、ネットワーク層プロトコルでの暗号 する場合には正しいか現在のネットワーク竟を考えると 化トンネリング技術などを用いて盜聴対策を施した安全 不十分といわざるをえない。とくに、システムに密着した な通イ各を砠呆する作業である。データリンク層での暗 管理作業は避けてとおれない。具イ勺には、次のような作 号機能をもつモデムの利用、あるいは、 SSL (Secure 業があるだろう。 Socket Layer) のようなアプリケーション・レベルで凾 信の暗号化機能をもつサービスの実施などが含まれる。 ( 6 ) 資源の里 ・ファイアウォール (firewall) の実装 ネ、 , トワーク鬻おける共有資源は数多 0 、。たとえは、 ファイアウォールとは、外部ネットワークからのアク NFS サーバーて提供されているディスク領域もその 1 っ セスを制限し、安全な通信だけを通過させる、セキュリ で、アクセス制坤バックアップ、領域管理などが必喫で ティ対策を施したゲートウェイである。インターネット ある。それ以外にも、プリンタやスキャナなどの入出力機 に接続されている組織においては、ファイアウォールの 器、あるいはモデムや FAX などの通信機器などがあり、 実装と管理・運用は重要な業務である。 それらを共有する環竟の整備や、場合によってはアクセス 盗聴に強いアカウント管理 の排他制御の実装なども必要になる。 現在のインターネットでは、ネットワーク内を流れるパ ( 7 ) ネットワーク・サービスの里 ケットの盜聴は大きな脅威である。したがって、使し鱠 現在のネットワーク竟では、業務に密接に嬲里する下 てパスワード (one-time password) などの盗聴に強い 己のようなサービスがある。 アカウント管理は必頭である。 暗号化メールの利用 ・ sendmail などの MTA (MaiI Transfer Agent) を用 電子メールの本文を暗号化し、醋中の盜聴や糒曳から いた電子メールの酉己医システム 守る技術は 1990 年代前半から開発力けられてきた。 ・ POP や IMAP などの、各ューサーのメールポックス 現在では、 PGP や S/MIME などの暗号化メールシス へのアクセスサービスを共するサーバー群 テムが簡単に使えるようになった。これら支術を利用 ・ Web サーバーと、 Web プロキシー / キャッシュ・サー できる竟を提供し、ユーサーか安心して電子メールを バーなどの Web に里したサーバー群 交換できる環竟を構築・運用することもネットワーク管 ・ FTP サーノヾー 理の重要な業務である。 これらのネットワーク・サーピスについても、障害が 安全な Web サーバーの運用 発生しないような円滑な運用が必喫である。とくに、も匠 現在の Web サーバーでは、 SSL 技術を用いてサーバー 一三ロ 12 UNIX MAGAZINE 1998.3

0 当 00 資料請求カードで入手 ! ・広告資料請求番号は各ページの下欄に記してあります。 ・広告資料請求カードはご面倒でも全項目にご記入く ださい。 ☆姓名のフリガナ、お電話番号、ご住所の番地は必ずご 記入ください。記入もれがある場合、資料をお届けで きないことがあります。 [ 表面 ] ←有効期限が過ぎて 12 月号 いるカードは、無効 切手を貼らずに一 とさせていただき のままご投函くだ ます。 資料が確実に届 く様 , 姓名のフリ ガナ , こ住所の番 地まで , こ面倒で も全項目正確に 第物第お滝れお物、の第メ こ記入ください。 ー ) ー・をを 1 を、物 0 0 第物 を物、物お物第物、第第第 最新の情報が簡単に入手できる ! こ希望の資料にⅵを お付けください。 前後にはみ出ない ようにこ記入ください。 : プレゼント 資料請求していただいた方の中から抽選でいすれ かの商品をプレゼントいたします。 ( なお当選者の発表 は商品の発送をもってかえさせていただきます。 ) ■時間を壁に映し出す ! タイムプロジェクター FAX で入手 ! ・裏面の記入用紙をコビーしてご記入ください。 己入方法は資料請求カードと同じです。 ・色の濃いボールペン等ではっきりとご記入く ださい。 ・資料請求受付 FAX 番号 三 -0 東京都渋簽区 代々木 4 -33- 川 株式会社アスキー 広告 「資料講求」係行 03 ・ 5351-8948 [ 裏面 ] インターネットで入手 ! Power A ロの サービスページ アスキー powe ′ AD サービス http://www. ascii. CO. jp/powerad ヘアクセ スしてください。記入フォームが表 - ~ ・、、学上′明第な第、よ、し 示されますので、画面の注意事項に したがって記入してください。 電子メールで入手 ! 資料請求カードや FAX と同様に電子メー ルでも資料請求サービスが受けられます。 インターネットのメールアドレス rqst-powerad@ascii. CO. jp にメールを送信してください。 アスキー Po e 「 A ロインターネット・センターから送信元のアドレスに、記入 フォームを自動返送します。記入フォームの注意事項にしたがって必須事項をご 記入いただき、指定のメールアドレスにご返送ください。 ( 送信するメールは、何も記入する必要はありません。また自動返送のため、も し記入されていても内容は一切無視されますのでご注意ください。 ) rqst-powerad@ascii-co-jp 0 4 ロボータブル M ロプレイヤー 広告資料請求サービスシステム ■資料請求サービスシステムに関する お問い合わせ先 〒 151-24 東京都渋谷区代々木 4 -33-10 株式会社アスキー広告局 TEL : 03-5351-8199 資料送付 資料請求カード FAX 広告主 読者 請求者リスト送付 ASCII 電子メール 、Ⅳ M M サー / ヾー

drvinit() か 1 平び出され、 cdevsw の一覧表に psm-cdev- sw を加えている。お気つ、きの方もいるだろうが、こんな まわりくどいことをしなくても SYSINIT と同しような 機構を利用して、コンパイル時にそれぞれのドライバの cdevsw を集めた構造体を作ることも可能なはすである。 そうしない理由は、 lkm (loadable kernel module) に よるドライバの追加を可能にするためである。 cdevsw の 情報を集めた構造体をいったん青勺に生成すると、あとで 重加勺に変史するのか難しい。そこであえて重加勺に生成する ようにして、 lkm との整合性をとっているのである。実 際、 lkm の処理をおこなう /sys/kern 」 km. c を見ると、 上と同し cdevsw-add() といったサービス関数を呼び出 してテパイスドライバを登録できるようになっている。 なお、ネットワーク・デバイスの場合はこのあたりか らほかのドライバとは大きく食い違ってくる。ネットワー ク・ドライバの関数については次回以降に詳述することに して、はかのドライバの場合についてデータ中幻の部分だ けを簡単にみておこう。 psmread() の処理を眺めていると、デバイスから受け 取ったデータを uiomove() というサービスルーチンを呼 んで処理しているのが分かる。これは、実際には read シ ステムコールの引数となっているバッフアにコヒーしてい るだけである。ただし、ドライバのバッフアはカーネル空 間に、 read の引数のほうはユーサー空間にあるので、両者 をまたがってコヒーしなけ川まならない。 uiomove() はこ れをおこなう特殊なサービスルーチンで、逆方向の write システムコールの処理にも使われる。 /sys/kern/kern-sub. c の定義を見ると、 uiomove( の下請けとして実際のコピーをおこなっているのは / sys / i386/i386/support. s の copyin() および copyout() で ある。、、 . s " で終ることからも分かるように、 support. s に はアセンプラで書かれた特殊なサービスルーチンが集めら れている。このほかにサービスルーチンでカーネル空間と ューサー空間相互のデータ転送をおこなうものとしては、 fubyte() や subyte() などがある。 カーネルの ISA コンフィキュレーション カーネルを生成する際に必要なコンフィギュレーショ ン・ファイルには、以前も解説したように、カーネルに組 み込む機能のほか ISA デバイスの I/O アドレスや IRQ 連載 /FreeBSD ノートー⑩ 84 番号といったリソースの割当てを言当主する。 EISA デバイスは、 ECU (EISA Configuration Util- ity) と呼はれる DOS などのユーティリティでリソース の割当てを決める。この情報は BIOS のメモリ領域に保 存されている。マシンか起動した直後、この情報に従って BIOS はカードを匆化する。 FreeBSD は起動するとこ の情報を逆に読み込んて利用するため、あらかしめカーネ ルに EISA デバイスのコンフィギュレーションを言当求し ておく必はない。 PCI デバイスはさらに自動化されており、マシンの起 動直後 BIOS によりリソースか割り当てられる。そのた め EISA デバイスと同様、カーネルに記録しておく必要 がない。 ISA テンヾイスのリソース割当てはコンフィギュレーショ ン・プログラムによりカーネルソースの一部である ioconf. c に変換さオ L 、 isa-devtab て始まる構造体に言当求される。 ISA デバイスの probe/attach 時にはこの情報をもとに 検出および設定がおこなわれる。 カーネル内のこの情報は、起重加叔こ BootConfig を起 動することで書きできる ( 具イ勺には、、、 b 。。 t : " プロン プトに対し、、一 c " を入力する ) 。デフォルトの設定ではさら に、 /sbin/dset コマンドでこの変史をカーネルファイルに 反映させるようになっている。そのため、リソースの割当 てだけの変史ならカーネルの再コンパイルか不要である。 カーネルファイルの書換えは危険をともなうので、デ バッグなど未な目的を除き普通はおこなわれない。 ISA のリソース割当ての部分はカーネルのなかでも上如勺独立 性が高いため、このような操作ができる。 ☆ 今回はすいぶん期化の話が多くなった。システムを動 イ大態にもっていくためのいくぶんトリッキーな負鹹トけが いろいろあるので、こういうところをみていくのもおもし ろい。逆に、テパイスにかぎらす初期化部分には重要な情 報がいろいろと詰まっているので、ソースコードを孑す るときの重要な足掛りになる。 次回はネットワーク・デバイスとそのドライバについて 詳細にみていく予定である。 UNIX MAGAZINE 1998.3 ( はまだ・なおき )

連載 /NET WORTH ことである。 ム・ソフトウェアに共通する目標は、ネットワーク・パ ディスク I/O とネットワークの双方を操作するシステ る一ヨ勺なガ去である。 HIPPI など ) への対応も、ネットワーク I/O 速度を上げ いネットワーク・ハードウェア (100Base T や ATM 、 処理の遅い SPARC CPU の性能を補えた。描虫の新し ングすることで、 ( 他の RISC べンダーの CPU よりも ) やネットワークシステム・ソフトウェアをうまくチュ UltraSPARC プロセッサの登場以前、 Sun は TCP/IP の実装における設言 t を強化すれは改善できる。たとえば、 ステム・ソフトウェアやネットワーク・デバイスドライバ いに、ネットワーク操作も、べンダーの TCP/IP シ ネル窈采用など ) 。 I / O 機器をサポートしている (Sun のファイバー・チャ 作を速くするために、べンダーは去肄〒かっ最高のディスク 均なハードウェア面でのアプローチである。ディスク操 RAID 技術は、ファイル I/O そのものの速度を上げる代 いる。ディスクアレイやディスク・ストライピングなどの ためにディスク・ファイルシステムに独自の工夫を加えて の代表例である。主要な UNIX べンダーは、性能 E の ムの言を通じてファイル I/O 性能の改善を試みたもの NT の NTFS ()T FiIe System) は、ファイルシステ る BerkeIey の FFS (Fast File System) や Windows システムの設言を改善すれは去も商化できる。 UNIX におけ ファイル操作の速度は、基礎となるディスク・ファイル うしてもディスク I / O が必要となる。 データを比較的矢可判日て物理記應装置に書き込む際に、ど 込み要求では、ファイルデータやファイルシステムのメタ ル I/O ははは間違いなく不要である。一方、ファイル書 物理ディスクへのアクセスとその結果として生じるファイ キャッシュされた Web ページに対するリクエストなら、 ループ化し、シークを最小限にするように最適化される。 ことが多い ) 、複数のファイル書込みを 1 つにまとめてグ シュされ (UNIX システムでは最高約 30 秒に設定される みのキャッシュがある。ファイルの書込みは矢可間キャッ に OS がもっともよく用いる去としては、ディスク書込 ディスクへッドの動「ドやシーク回数を最小限に抑えるため ク・キャッシュはあまり有効ではない。このような場合、 ファイルへの書込みカ瀕繁におこなわれる場合、ディス UNIX MAGAZINE 1998.3 ケットとファイノレヾッフア・バケットのよぶんなメモリ コピーを減らすことである。ソフトウェアの生能改善のた めの技術としては、もっともよくおこなわれる操作で実行 すべき CPU 命令数 ( コードバス ) を減らす去がある。 1 つの OS でネットワーク操作用のコードとディスク I/O 用のコードを別々に最商化することは可能だが、両方のプ ロセス間の通信を最適化するのは難しい。これは、 SMP (Symmetric Multiple Processor : 対 ( 型マルチプロセ ッサ ) システムに CPU を追加して、う攵ファイルシステ ム・サービスの速度がどの程度改善されたかを評価してみ れはたやすく分かるだろう。 最新かっ最高の PC ハードウェアを使い、 Pentium Pro CPU を追加して Windows NT Server を動かし ても、分散ファイルサービスの速度は約 20 % しか向上し ない。さらに CPU を追加すると性能が落ちる場合もあ る。同様に、 UNIX の典型的な RISC べースのマルチプ ロセッサ・ハードウェア (IBM や DEC など ) に CPU を追加しても、 NFS ファイルサービス操作は約 30 % しか 怖 1 上しない。新しい UNIX サーバー (Sun UItra や SGI Challenge など ) では、もうすこしましな性能向がみら れる。汎用 OS (UNIX や Windows NT など ) のネッ トワークやファイル I/O 操作における複雑な柤坊凾信は、 CPU 資源の奪い合いに終る。これに対して、複数の CPU をもつマシンをアプリケーション・サーバー (web サー バーやデータベース・サーバー ) として使うと、高い生能 向ーヒがみら相当な効果カ期待できる。 Auspex System や Network Appliance などに代表 される専用ファイルサーバー製品では、ファイル操作と ネットワーク操作のそれぞれに専用プロセッサを用意し、 OS の性能低下を最小限に抑えてこれらの問題を回避して いる。ネットワークと記應装置の附篥作に専用プロセッサ を用意することで、これらのべンダーのシステムはそれぞ れが別個に性能を商化でき、プロセッサを増やせはその ぶんだけ生能改善か図れる。 分散ファイルサービスの統合 歴史的に、 UNIX システムでは分散ファイルサーピス 用のネットワーク・プロトコルとして NFS を採用してき た。以前述べたように、デスクトップ用のネットワーク 107

計算機ごとに提供するサービスを変更する リスト 4 —telnetd: permit—hosts 127.0.0.1 -exec /usr/libexec/telnetd netacl telnetd : permit—hosts * —exec /usr/local/etc/tn—gw netacl— リスト 5 netacl を inetd からする /usr/local/etc/netacl ftp nowait stream tcp ftpd root /usr/local/etc/netacl telnet nowait telnetd stream tcp root /usr/local/etc/netacl login nowait stream tcp rlogind /usr/local/etc/netacl finger nowait nobody f ingerd stream tcp リスト 6 netacl を rc ファイルからする /usr/local/etc/netacl —daemon ftp ftpd & /usr/local/etc/netacl —daemon telnet telnetd & /usr/local/etc/netacl —daemon login rlogind & /usr/local/etc/netacl —daemon finger fingerd & - netacl す。たとえは、リスト 4 のルールでは、自分自身 (local- host) から接続要求を受け取ると本物の TeInet デーモン FWTK によるファイアウォール・ホストは、プロキ (/usr/libexec/telnetd) を起動し、自分以外の言算機か シー・サービスを提供するプロトコルごとに異なるプロセ らの接続要求に対しては Telnet のプロキシー・サーバー スを実行します。そして、あるポートへの接続カ蔀寉立され を起動します。 ると、そのポートに対応したプロトコルのプロセスがサー ビスを提供します。 netacl を起動する しかし、同一のポートで内容の異なるサービスを提供し netacl は、 /etc/inetd. conf に当求して、コネクション たい場合もあるでしよう。このような要求を実現するため を受け取るたびに inetd から起動させることができます。 に、 FWTK には netacl というアクセス制屆ワログラム あるいは、コマンド行や /etc/rc. local などの rc ファイ が用意されています。 ルからデーモンモードで起動し、デーモンとして常日赫カか netacl の動作 しておくことも可能です。 inetd から起動する場合は、 inetd の成疋ファイル /etc netacl がネットワークから接続要求を受け取ると、ま / ⅲ etd. c 。 nf にリスト 5 のようなエントリを追加します。 す netperm-table ファイルを読み込みます。そして、設 一方、 rc ファイルから起ける場合は、 rc ファイルに 定内容に従って、接続を要求してきた言算機からのアクセ リスト 6 を追加します。 スを許可するか、拒否するかを判断し、その結果をログに 当求します。 注意 2 アクセスを許可する場合はそのルールに定義されている いまのところは、 /etc/inetd. conf や rc ファイルを変更 プログラムを起動して、自分自身をそのプログラムに置き しないでください。今後、各フ。ロキシー・サーバーについて説 明するときに、必要なエントリを順番に」助日していきます。 換え (execv(3) し ) ます ( 図 2 ) 。 netacl と接続元とのあ いだに確立されたコネクションは、新たに起動されたプロ やってみる グラムにそのまま委譲されるので、クライアントがそれに 説明を読んでいるだけでは当でしようから、ちょっと 気つ、くことはありません。 netacl で遊んでみましよう ( といっても、たいしたこと 一方、アクセスを拒否する場合はそのコネクションを切 はできませんが・・ 断して処理を終了します。 ます、新しい netperm-table ファイルを作成し、次の 言算機の IP アドレスやホスト名に応して提供するサ 2 つのルールを書きます ( で折り返していますが、本来 ーピスを変えたい場合は、それぞれの接続要求元に対す はそれぞれ 1 行のルールです ) 。 る複数のルールを netperm-table ファイルに記述しま deny—hosts chili . raccoon. doubutsu. co ・」 p permit—hosts * . raccoon. doubutsu. CO ・」 p の順番で言己します。 1 三ロ 26 UNIX MAGAZINE 1998.3

のようにハンドシェイクやシーケンス番号を利用しないの で、 TCP にくらべてバケットを容易に偽造できるからで す。したがって、ソースアドレスを偽造したバケットが、 ファイアウォールの内側にやすやすと入り込むおそれが あります。 UDP バケットの正当性の本正や、認証作業は アプリケーションがおこなわなけれはなりません。もし、 UDP べースのサービスを中継したい場合は、専用のプロ キシー・サーバーを使用します。しかし、 FWTK には UDP を中継するプログラムは用意されていません。とい うことで、今回はあきらめてください。 どうしても中継したい場合は、製品版のファイアウォー ルを使うなど、別の手段を考えるしかありません。 ネームサービス ファイアウォール内部の言 t 算機のホスト名と IP アドレ スの情報をファイアウォール外部に公開するかどうかを決 めます。 もちろん、サイトのネットワーク管理者かオ当屋していな いアドレスがファイアウォール内部に勝手に割り当てられ ているような場合は、公開してはいけません。ホスト名と IP アドレスに関する情報は、外部の攻撃者にとって、、お いしいエサ " になる可能生があります。したがって、とく に理山がなければ、内部の情報は公開しないはうがいいで しよう。 すべてのホストの↑帯にを外部に公開する場合は、サイト の運用ポリシーに従って設定イ 1 璞をおこないます。一方、 ホスト情報を外部に公開しない場合は、ファイアウォール 内部て豸虫自にネームサーピスを提供するサーバーを設定し ます ( 前回作ったセキュリティ・ポリシーに従って竹喋し ます ) 。 現在のファイアウォール・ホストには、 OS のインス トール時に割り当てた、、仮の " ホスト名カ咐けられている はすです。これを、セキュリティ・プランて袂めたホスト 名に変史する竹喋をおこないます。 言 t 算機のホスト名は、 FreeBSD では、、 /etc/syscon- fig" で、 BSD/OS では、、 /etc/netstart" で定義されてい ます。 - ホスト名の変更 UNIX MAGAZINE 1998.3 これらのファイルに hostname= という文字列て始まる行があるはすです。ここに外部イン ターフェイスに割り当てた名前を設定します。繰り返しま すが、ファイアウォールを連想させる名前を付けてはいけ ません。 FreeBSD の場合は、ホスト名をかならず、、 " " ( ダブル クオート ) で囲みます。そして、ネームサービス (DNS など ) の設定も変更します。 設定ファイルを変更したら、言機をリプートします。 - IP アドレスを付ける 前回までの作業で、 2 枚目のネットワーク・カードを 取り付けてカーネルに認識させました。ただし、 2 枚目の ネットワーク・カードには IP アドレスは付けていません。 いわは、宙ぶらりんの放ったらかし状態です。このままで はかわいそうなので、ネットワークに接続してバケットを 送れるようにしてあげましよう。 2 枚目のネットワーク・カードに IP アドレスを設定 し、ネットワーク・インターフェイスとして動くようにし ます。 制・算機のネットワーク・インターフェイスの IP アドレ スとネットマスクは、 FreeBSD では、、 /etc/sysconfig で、 BSD/OS では、、 /etc/netstart" で定義されていま す。 1 枚目のネットワーク・カードの IP アドレスは、いま のところ変史する必要はありません。 2 枚目のネットワーク・カードには、適当なプライベー ト・アドレスから選んだ IP アドレスを設定します。もし 可能ならば、セキュリティ・プランで決めた内部ネット ワークの IP アドレスを定してください。しかし、ネッ トワーク友上、割り当てられない IP アドレスであれば 無理にセキュリティ・プランに合わせる必要はありません。 1 枚目と 2 枚目のネットワーク・カードに異なるネット ワーク・アドレスカリり当てらオレ Lt まそれで分です。 リスト 1 に設定ファイルの変史例を示します。この例 では、前回までのイ乍業でインストールした NE2000 ( 互 換 ) ネットワーク・インターフェイスである neO と nel に IP アドレスを設定しています。この連載の 1 ~ 2 回 21

現在の状態は、、標準化への提唱 " である。 1997 年 10 月 ・クライアントのドメインのシステム管理者だけか解読で 28 日に公開された。 きる、、@" を含まない文字列 新しく規定されたコマンドは、 何も送らない AUTH . 認証 / セキュリティ機溝 匿名アクセス可能なサーバーは、 ANONYMOUS 機 ADAT . 認証 / セキュリティ・データ 構を使ったログインを制限付きで許可する。 PROT : データチャンネルイ描矍レベル このようなサーバーは、誰にでも情報へのアクセスを PBSZ コ矍バッフアサイズ 午可する ANONYMOUS 欟冓の特生上、在の取得に CCC : コマンド・チャンネルのクリア 成功した匿名ューザーからの攻撃を受けやすい。したがっ MIC : 正当鬮イ矍コマンド て、攻撃を避けるために以下の点を考慮すべきである。 CONF : 機密描矍コマンド 衫状態では匿名アクセスを不許可にしておき、利用の ENC : プライバシーー描矍コマンド 際には管理者による明カ勺な設定が必要なようにする。 で、これらについての言岩田が定義されている。 大量書込みによるサービス妨害攻撃を避けるために、匿 名ューサーからのすべての書込みアクセスを無効にす RFC2230 Key Exchange DeIegation Record for the る。 DNS 情報を匿名で交換するためのイ中介機構として使われない DNS における鍵交換用イ里レコード ように、匿名書込みを許容するサーバーでは、、、 dr 叩 旧 fo. 、 R. Atkinson b 。 x " モデルにより、匿名での読込みができる領域と書 RFC2065 で定義されている DNS のセキュリティ刻長 込み領域をう黐隹する。 (Secure DNS) での暗号鍵の交換の際に利用される KX ・負荷の高い処理を開放するとサービス妨害攻撃の原因と (Key exchanger) レコードを定義している。、、広報 " と なるので、匿名ューザーがおこなう処理には各種リソー して 1997 年 11 月 4 日に公開された。 スの制限を実施する。 KX はかならす Secure DNS とともに用いられ、 ・匿名ューザーを無制限に受け入れるとサービス妨害攻撃 のレコードに指定されているノード ( ホスト ) は、鍵交換 の原因となるので、同時に利用できるユーザー数を制限 をおこなう認証機構として他のノードから委任されること する。 になる。このような代理認証オ絣冓は、さまざまなセキュリ ・証されていない j 毆小情報は信用できないことを認識す ティ・サーピスに利用可能である。 山い たとえは、 IP バケット・セキュリティ保証のために る。 電子メールアドレスの送付はユーサーのフライバシーを 用いられる IP セキュリティ ( RFC1825 、 RFC1826 、 侵害する可能生がきわめて高いので、扱いには慎重を期 RFC1827 ) では、この機構を利用することで与えられた す。クライアントからの j 亦情報に電子メールアドレス 宛先の遠「融建交換システムを検索し、利用する鍵交換サー を利用する際には、ユーサーの明示的な孑気こよるよう ーを決定することが可能である。 にする。また、 j 毆亦情報を送らないとい引支も用意 KX レコードは MX (MaiI eXchanger) レコードと する。 似ており、各ドメインやサブドメインに対するドメイン名 (FQDN) を一尉寺している。ドメインに対してだけではな RFC2228 FTP Security Extensions く、サブドメインおよびホストに対しても KX レコード FTP セキュリティ拡張 を指定することができる。 KX レコードは DNS のイン PS. 、 M. Horowitz 他 (RFC959 更新 ) ターネット (IN) クラスのメンバーであり、 DNS タイ インターネットでひろく使われているファイル転送プ プ、、 KX " 、番号は 36 番と規定されている。 ロトコルである FTP に対してセキュリティ拡張を施す KX レコードの表記は、下記のようになる。 ための新しいコマンドおよびそ窈区答、その際に利用され るファイルの符号化手法を規定している。 くドメイン名 > IN KX くプレファレンス > くドメイン名 > UNIX MAGAZINE 1998.3 158

「わたしたちが業界最高の技術とサービスを提供していま魂」 一、当乢まコー ″ R : れ t [ : / / ⅣⅣル .50 リ m. ( 0. ノ〃 / ど - 川′ゴ n 0 @soum. ( 0. ノ P 詳細はホームページをごらん下さい。 ※ LJN Ⅸは、 X / Open カンバニーリミテッドがライセンスしている米国ならびに他の国における登録商標です。 LJN Ⅸ技術者随時募集中 ! ※ X Window System は米国 X コンソーシアムの商標です。 詳細はお電話でお問い合わせください。 ※会社名及び商品名は各社の商標または登録商標です。 創夢 〒 15 ト 0072 東京都渋谷区幡ヶ谷ト 29 ー 9 日星ビル お申し込み・お問い合わせ・資料請求先株式会社 TEL : 03 ( 5453 ) 1251 ( 代 ) FAX : 03 ( 5453 ) 1252 E-MAlL:infO@soum.CO.jP 資料請求 No. 074

連載 / BSD をハックする一① ・階層化された構造 3 読出し、削除のはか、内容の追加やえが可能です。 前 ( ファイル名 ) カ咐けられます。通常、ファイルは作成、 ファイルシステム ( ゴ絲タされたデータには、それぞれ名 システムと呼ぶこともあります。 なんらかの方式に従って↑絲タされたファイル群をファイル す。ある論理ポリューム ( UNIX ではパーティション ) に れる ) のメディアにデータを保管するための方式をいいま などの軍発性 ( 電源を切っても言当求したデータが一尉寺さ 狭い意味でのファイルシステムとは、ハードディスク はいえなくなっています。 のほかの OS がとりいれたりして 4 、 UNIX 特有の性質と これらの性質の多くは、後続の OS がまねたり、既存 ・ノヾッフア・キャッシュのイ吏用 デバイス操作のファイルへの統合 ・ファイルサイズが自由 ( 予約不要 ) ・構造のない、バイトストリームとしてのファイル 2 ファイルの頁 不頁といってもいろいろな観点がありますが、 ファイルの内容の不鶤頁を考えます。 ロードモジュール ( プログラム・バイナリ ) 、 ーこでは ソースプ ログラム ( テキスト ) 、データベース ( 検索機能付き ) など、 ファイルにオ絲タされる内容に特化したファイルの不鶤頁を提 供することが考えられます。また、 UNIX のように、入 出力装置をファイルにみせかけたデバイスファイルをもつ OS もあります。 1 ディレクトリ : i 功かったり、あっても深さに制のある OS もあり ます。 2 ファイルの入出力がディスクプロック ( 128 とか 512 バイト ) 単位で しかおこなえない OS もあります。また、多くのメインフレーム OS で は、「テキストファイルとは 1 行 80 キャラクタの固定レコード長ファイ ルのこと」というように 80 桁パンチカードの朝 ( にをそのままファ イルにあてはめていました 3 ファイルを新規に作ったり体熔お助けるのに先立って、最及ファイル サイズを申告して割当てを受けなけオ u まならない OS も、 UNIX 倉性当 時 ( お参しくありませんでしな 4 CP/M や MS-DOS VI. 0 では、ディレクトリ : i 功く、ファイ ル I/O はセクタ ( 128 バイト ) 単位になっていましたが、 MS-DOS V2.0 以降で、ディレクトリやヾイト単位でのファイル操作助日さ れましたいまでも、テキストファイルの麦に "Ctrl 十 Z " を付ける ェデイタがありますが、これはファイルの翆毛にセクタサイズの倍数まで をゴミデータて鯉める都合止、ファイルの木尾を表す印カ陀だった名残 UNIX MAGAZINE 1998.3 ファイルの属性 ファイルに属性 ( なんらかの生質 ) をもたせる付加サー ビスも、ファイルシステムカ甘是供するサービスの 1 つで す。典型的な属性は、 ・読出しのみ (read only) 更辛万日時 (last modified time 不可視 (hidden) などといったものです。 UNIX をはしめとしたマルチュー ザー OS では、ファイルの所有者やアクセス権限なども属 性に含まれます。 BSD のファイルシステム・サービス Ken Thompson か開発した元祖 UNIX 以降、度重な る改良を経た BSD では、ファイルシステムに関連する サービスは多層化した複雑なものになっています。 当初の UNIX でサポートされていたファイルシステム は 1 種類だけで、 inode (index node: アイノード ) と 69 5 こク各枷蜊め勝手に作ったものてす。 古典的な UNIX ファイルシステムを性能、機能両面で改 4.2BSD で導入された FFS (Fast File System) は、 なりますが、ディスクの利用効率は悪くなります。 tem" と呼ばれました。ファイルの読み書きの速度は速く イト ) を操作単位とするファイルシステムは、、 lk filesys- ク " として扱う手法でした。たとえば、 2 セクタ ( 1024 バ 数個 ( 2 、 4 、 8 、 16 個 ) まとめたものを、、ディスクプロッ ズを大きくしたものカイ吏われました。これは、セクタを複 (SVR3) までは、 V7FS そのままか単純にプロックサイ 4. IBSD および SystemIII から SystemV ReIease3 を操作単位にしていました。 ました。また、ファイルシステムは 512 バイトのセクタ ルシステム上の inode は 65 , 536 個までという制限があり V7FS ではファイル名は 14 文字までで、 1 つのファイ 7th edition にちなんで、、 V7FS" と呼ぶことにします 5 こでは、 BSD や SystemV の共通のネ仕先である UNIX に、、 UNIX filesystem" と呼ばれていた ? ) ようですが、 われていました。これにはとくに正式名称はない ( たん ーネル内のファイルシステム・インターフェイスでも使 UNIX ファイルシステムの構造を特徴つ、けるもので、カ 呼ぶデータ構造を中心に構築されていました。 inode は