「ネットワークの管理」の版間の差分
88行目: | 88行目: | ||
== サーバの管理 == | == サーバの管理 == | ||
+ | |||
+ | === Web サーバの管理 === | ||
+ | |||
+ | 昨今では外部に公開したウェブサーバに起因するセキュリティ問題が増加しておりますので、ウェブサーバを外部に公開する場合には以下の情報を登録していただいております。 | ||
+ | |||
+ | 1. 専攻施設 | ||
+ | 2. IPアドレス | ||
+ | 3. FQDN | ||
+ | 4. 管理者氏名 | ||
+ | 5. 管理者メールアドレス | ||
+ | 6. 担当者氏名 | ||
+ | 7. 担当者メールアドレス | ||
+ | 8. 用途 | ||
+ | 9. 備考 | ||
+ | |||
+ | === ssh サーバの管理 === | ||
sshを外部に公開する場合は鍵認証でしかログインできない設定にしてください。 | sshを外部に公開する場合は鍵認証でしかログインできない設定にしてください。 | ||
94行目: | 110行目: | ||
鍵認証でしかログインできない設定ではこういった問題は発生しません。 | 鍵認証でしかログインできない設定ではこういった問題は発生しません。 | ||
− | === ユーザの設定 === | + | ==== ユーザの設定 ==== |
* ssh-keygen コマンドを実行します。 | * ssh-keygen コマンドを実行します。 | ||
104行目: | 120行目: | ||
* .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します | * .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します | ||
− | === サーバの設定 === | + | ==== サーバの設定 ==== |
* /etc/ssh/sshd_config を編集してパスワード認証を禁止します | * /etc/ssh/sshd_config を編集してパスワード認証を禁止します | ||
PasswordAuthentication no | PasswordAuthentication no | ||
− | === 運用に関する注意点 === | + | ==== 運用に関する注意点 ==== |
パスワード認証によるログインを禁止した場合、新たに追加したユーザについては、 | パスワード認証によるログインを禁止した場合、新たに追加したユーザについては、 |
2013年9月2日 (月) 17:45時点における版
目次
1 理学系研究科アカウントの管理
理学系研究科で提供されるサービスは理学系研究科アカウントで認証を行います。 アカウントの申請や配布のほかに、無線LANやVPNで利用者が接続するネットワークの設定を行う必要があります。
詳しくは以下のページを参照してください。
2 ネットワークの管理
理学系研究科では専攻施設ごとにサブネットが分かれており、各サブネットについてはそれぞれ専攻施設の管理者に管理していただいています。 専攻施設によっては、専攻施設内に複数のサブネットがあり、それぞれのサブネットごとに管理者がいる場合もあるかと思います。
各サブネット内で NAT は設置せず、割り当てられたサブネットのグローバルIPを使用して端末などを接続してください。 接続する端末が増加してIPが不足する場合には、新しいIPの割り当て申請を行いますのでご相談ください。
2.1 各部屋の情報コンセントの設定について
各専攻施設のサブネットは VLAN によって設定されています。新たに部屋を利用する場合などはその部屋の情報コンセントの設定がされておりませんので、 メールにてどのネットワークを利用するかご連絡ください。
部屋の工事だけ行って情報コンセントを増設してもネットワークに接続できるわけではありません。 基幹機器側に空きがない場合もありますので、事前にご相談ください。 また、今後の管理の問題もありますので、業者に配線工事を依頼する場合には実施した内容について図面を提出してもらうようにしてください。
2.2 ファイアウォールについて
理学系研究科の各ネットワークのデフォルトの設定は、内部から外部は通信可能、外部から内部は通信不可能で、外部からの通信が必要な部分については申請いただいて設定するという形になっています。 外部からの接続が必要となるサーバについては個別にIPアドレスおよび使用するポート番号をご連絡ください。
ESPやUDPを利用する通信についてはそういった方向の区別がありませんので、内部から通信可能にすると外部からも通信可能になる都合上、内部から通信する場合についても個別に申請いただいて必要な部分のみ設定を行っています。
特に外部に公開したウェブサーバについてはセキュリティ問題が増加しておりますので管理者を登録していただきセキュリティ情報の通知や管理状況の問い合わせなどを行わせていただいております。
2.3 DNS・DHCP について
各専攻施設でDNSおよびDHCPサーバを運用することも可能ですが、効率化のために理学系のサーバで一括して運用することを推奨しています。 (既に多くの専攻施設にはご協力いただいています。) 設定の変更が必要な場合にはメールにてご依頼ください。
2.4 P2P の対応について
理学系ではP2Pの利用は禁止されています。UT-CERTにより利用が検出された場合には、その端末の利用者に対してP2Pの利用をやめるようにご指導ください。
また、サブネット全体の P2P 通信をファイアウォールで遮断するというサービスも行っております。 こちらを利用いただければ個別のユーザに対してP2Pの対応を行う手間の削減が可能かと思います。 各サブネットごとに特定のIPの範囲は遮断の対象外などの設定も可能ですので、導入をご検討ください。
2.5 NATの対応について
ネットワーク構成上の理由でどうしてもプライベートネットワークが必要な場合には別途ご相談ください。 室内にNAT機器を設置するのではなく、理学系のネットワーク機器の方でNATを行い、情報コンセントの設定をNATされたプライベートネットワークのVLANに変更するという構成を推奨しています。
どうしても個別にNAT機器を設置する場合には次の点に注意してください。NAT を利用した場合には、トラブルが発生したときに外部からは端末の特定ができなくなりますので、NAT のログを保存していただく必要があります。目安としては最低 3 か月は保存してください。また、NAT の下につながる端末についても、グローバル IP を使用する端末と同 様に適切な管理が必要です。
3 端末の管理
東京大学情報ネットワークシステム運用規則では学内のネットワークに接続する場合には申請を行い適切に管理を行うことが義務付けられています。 実際に全ての端末について申請や承認の作業を行うのは非常に大変ですが、少なくともネットワークに何が接続されていて、 問題が発生したときには誰のどの端末が問題を起こしているか把握できるためには何らかの管理を行う必要があります。
以下のページを参考に各専攻施設ごとに接続する機器を適切に管理してください。
NATの設置については管理上好ましくないので少なくとも個人レベルでの設置は禁止としてください。仮にNATを設置したとしても、そこに接続する機器を管理する必要があるというのは変わりません。端末の管理に加えて、NAT機器のログを一定期間保存することで、セキュリティ問題が発生したときに原因を究明できる環境を整えてください。
4 サーバの管理
4.1 Web サーバの管理
昨今では外部に公開したウェブサーバに起因するセキュリティ問題が増加しておりますので、ウェブサーバを外部に公開する場合には以下の情報を登録していただいております。
1. 専攻施設 2. IPアドレス 3. FQDN 4. 管理者氏名 5. 管理者メールアドレス 6. 担当者氏名 7. 担当者メールアドレス 8. 用途 9. 備考
4.2 ssh サーバの管理
sshを外部に公開する場合は鍵認証でしかログインできない設定にしてください。 パスワードでログイン可能なsshサーバを適切に管理するには、サーバに存在する全てのアカウントが適切なパスワードを付けていることを確認する必要があります。 適切な状態を維持するのは大変で、一時的に作ったアカウントの消し忘れなどからsshで侵入される事例が発生しています。 鍵認証でしかログインできない設定ではこういった問題は発生しません。
4.2.1 ユーザの設定
- ssh-keygen コマンドを実行します。
- 質問にエンターを入力します(ファイルの場所はデフォルト、パスフレーズなし)
- .ssh/id_rsa が秘密鍵、.ssh/id_rsa.pub が公開鍵です
- サーバの .ssh/authorized_keys に公開鍵を追加します
- サーバに id_rsa.pub をコピーしてから
cat id_rsa.pub >> .ssh/authorized_keys
- .ssh ディレクトリに g や o の書き込み権限がたってないことを確認します
4.2.2 サーバの設定
- /etc/ssh/sshd_config を編集してパスワード認証を禁止します
PasswordAuthentication no
4.2.3 運用に関する注意点
パスワード認証によるログインを禁止した場合、新たに追加したユーザについては、 管理者がユーザの公開鍵をメールで送ってもらうなどして設定する必要があります。
5 障害の対応
- 困ったときはを参照してください。