SSL自己署名証明書の作成

SSL自己署名証明書ではアクセス時に警告が出るため、商用で使う場合はベリサイン等の正規の認証局が発行する証明書するの通常です。

SSL自己署名証明書の作成手順

1. 秘密鍵を生成します
2. 秘密鍵からパスフレーズを削除
3. 生成された秘密鍵を使ってサイト証明書を発行

1. 秘密鍵を生成します。

[root@hoge ~]#cd /etc/pki/tls [root@hoge tls]# openssl genrsa -des3 2048 > private/localhost.key
Generating RSA private key, 2048 bit long modulus
.........................................................................................................................................+++
.............+++
e is 65537 (0x10001)
Enter pass phrase:　# パスフレーズを入力
Verifying - Enter pass phrase:　# パスフレーズを再入力
[root@hoge tls]#

2.秘密鍵からパスフレーズを削除します。（Apache起動時に毎回パスフレーズを聞かれるので..）

[root@hoge tls]# cd private
[root@hoge private]# cp -p localhost.key localhost.key.org　# オリジナルを退避する。（パスフレーズを問い合わせる）
[root@hoge private]# cd ../
[root@hoge tls]# openssl rsa -in private/localhost.key -out private/localhost.key
Enter pass phrase for private/localhost.key:　# パスフレーズを入力
writing RSA key
[root@hoge tls]#

3.生成された秘密鍵を使ってサイト証明書を発行します（Common NameはURLでのホスト名を入力）

[root@hoge tls]# openssl req -new -x509 -key private/localhost.key -out certs/localhost.crt -days 3650
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:chiyoda-ku
Organization Name (eg, company) [My Company Ltd]:example.inc
Organizational Unit Name (eg, section) []:example
Common Name (eg, your name or your server's hostname) []:example.com
Email Address []:
[root@hoge tls]#

下記の３つのファイル（実際は２つ）を作成

/etc/pki/tls/private/localhost.key.org パスフレーズ削除前
/etc/pki/tls/private/localhost.key     パスフレーズ削除後
/etc/pki/tls/private/localhost.crt     サイト証明書

※作成後はパーミッションを下記のようにしておきます。
 -r-------- 1 root root   1444  2月 16 05:58 localhost.key.org
 -r-------- 1 root root   1444  2月 16 05:58 localhost.key
 -r-------- 1 root root   1444  2月 16 05:58 localhost.crt

iptablesの設定について

/etc/sysconfig/iptables を見てみる。

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT

上記の記述を上から順に確認すると

• INPUTチェーンの定義
• FORWARDチェーンの定義
• OUTPUTチェーンの定義
• RH-Firewall-1-INPUTチェーンの定義
• INPUTチェーンに来たものはすべて無条件にRH-Firewall-1-INPUTチェーンへ転送する
• FORWARDチェーンに来たものはすべて無条件にRH-Firewall-1-INPUTチェーンへ転送する

となります。
つまり、これでINPUTとFORWARDがRH-Firewall-1-INPUTチェーンで束ねられたことになります。

さらに/etc/sysconfig/iptables を見ていくと、以下のようになっていると思います。

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

これは、RH-Firewall-1-INPUTチェーン内のルール設定で、外部からの８０番と８０８０番ポートへのアクセスを許可するように設定しています。

そして最後の行の
「-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited」
によって、RH-Firewall-1-INPUT チェーン内のどのルールにもマッチしなかったパケットは、icmp-host-prohibitedエラーを返すように設定しています。
つまり上記の場合、８０番でも８０８０番でもない宛先ポートのパケットは全部エラーになるということになります。

SDNへの潮流...

シンクイット(Think IT)の第1回 SDNへの潮流とOpenFlowの歴史と第2回 OpenFlowのアーキテクチャと仕様・機能を参照（読む）

この流れが実現されると通信機器のベンダーごとに微妙に異なる設定や通信機器の種類（スイッチ（L2〜L5)・ルーター（専用機）・ファイアウォール（専用機））の垣根がなくなる。利用者にとって複数機器を導入しなくて済むが、業者にとっては競争の激化と技術者の確保が命題になってくる。

SSHによるリモート接続設定

いつも使っているのだが、ついつい忘れがちな設定方法をメモする。

sshdによるファイル転送を行うため、Linux(SVR)側で設定内容を確認する。

アクセスの制限
/etc/hosts.allow にアクセスを許可先を設定。

sshd: 127.0.0.1 192.168.0. 192.168.1.

/etc/hosts.deny にアクセスを拒否先を設定。

sshd: ALL

/etc/ssh/sshd_configの編集

#Port 22
#■ポート番号を変更しても良い　例) 2222等

#Protocol 2,1
#↓■SSH 2 のみ接続を許可
Protocol 2

#PermitRootLogin yes
#↓■rootでのログインを禁止
PermitRootLogin no

#↓■パスワード方式ログインで設定する場合、パスワードでのログインを許可
PasswordAuthentication yes

#↓■鍵方式ログインで設定する場合、パスワードでのログインを拒否
PasswordAuthentication no

#↓■ 空パスワードの禁止
PermitEmptyPasswords no

【ログイン方式で鍵方式を設定した場合】 手順は下記の２通り考えられます。サーバーとクライアントが身近な（同一建物）場合は【手順１】で行い、ネットワークでの転送が必要な場合には、【手順２】が良いかも．．．
【手順１】でネットワークを経由で転送も方法を考慮すれば問題ないかもね。（キーをパスワード付きで圧縮して送り、パスワードは別手段で伝える）
ここでは、公開鍵・秘密鍵ともにデフォルトの値（名前）を使用して説明します。（鍵の生成時の名前（鍵名）は好きな名称をつけることが可能）
デフォルトでは、公開鍵（id_rsa.pub）・秘密鍵（id_rsa）になります。

【手順１】

1. サーバーでログイン方法（sshd_confing）の設定を行う。
2. サーバーでクライアントの秘密鍵と公開鍵のペアを作成する。
   ※作成された公開鍵は、~/.ssh/authorized_keys に追加する。
   

   ■authorized_keysがない場合
   $ cat ~/.ssh/id_rsa.pub > authorized_keys
   ■authorized_keysがある場合
   $ cat ~/.ssh/id_rsa.pub >> authorized_keys
   
   ※登録したら、作成した id_rsa.pub（公開鍵）は削除します。
   

3. 作成された秘密鍵（id_rsa）をクライアント(PC)へコピーする。
4. クライアント(PC)がSSHクライアントで公開鍵による認証を行うように設定する。

【手順２】

1. クライアントで秘密鍵と公開鍵のペアを作成する。
2. 作成した公開鍵をサーバーに登録する。
   登録先は、ユーザーディレクトリのauthorized_keysに鍵を追加。
   ※この時は、パスワード認証で鍵を送る。（または、別方法）
3. SSHサーバーのログイン方法を公開鍵暗号でのログインに変更する。
4. クライアント(PC)がSSHクライアントで公開鍵による認証を行うように設定する。

■鍵の作成方法
Linuxでの鍵の作成（Mac OS X Lion もほぼ同様です。）

$ ssh-keygen -t rsa

[hoge@hoge01 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): ←そのまま[Enter]を押す。（鍵名と鍵の格納先フォルダ）
Created directory '/home/hoge/.ssh'.
Enter passphrase (empty for no passphrase): ←パスワードを入力
Enter same passphrase again: ←パスワードを再入力
Your identification has been saved in /home/hoge/.ssh/id_rsa.
Your public key has been saved in /home/hoge/.ssh/id_rsa.pub.
The key fingerprint is:
b7:7b:f2:83:0b:da:6c:57:9a:51:93:4e:04:9a:b2:5f hoge@hoge01
[hoge@hoge01 ~]$

Windowsでの鍵の作成(WindowsXp TeraTerm Pro)

1. TeraTermProを起動して、Cancelを選択して接続画面を閉じる。
2. メニューの「設定」を選択して「SSH鍵の生成」を選択（ｸﾘｯｸ）します。
   
3. 鍵の生成画面が開いたら（鍵：RSA、ﾋﾞｯﾄ数:2048）、そのまま「生成」ボタンを押します。
   
4. 鍵の生成が完了すると「鍵を生成しました」と表示され、パスワードが入力可能の状態になります。
   
5. パスワードを入力して「公開鍵の保存」を押す。
   
6. パスワードを入力して「秘密鍵の保存」を押す。
   

上記で鍵を作成したら、秘密鍵はクライアントに保存し、公開鍵はサーバーのユーザー所定のディレクトリの authorized_keys に登録する。（なければ作成、あれば追記する。）

実際に確認してみると大した事ないのだが... (^_^)

ネットワークスペシャリスト試験 結果

　昨日、2011年10月16日に受験したネットワークスペシャリストの結果が発表された。試験勉強は試験直前に10日程度勉強したが、勉強不足と思いながら受験したが、試験内容は思っていたよりも簡単に感じ特に午後Ⅱについてはかなり上出来でした。これば結果が楽しみと考えていたら...

　なんと、結果は「不合格」という内容でした。

　試験ではOSPFやBGP-4の知識に不安があったのですが、実際の試験ではこの部分の割合が少なかったので「ヤッター」なんと心の中で喜んでいた次第でしたが、実際には午後Ⅱでなく、午後Ⅰで得点が 2点 足りずに不合格になっていました。

　まさかの午後Ⅰの得点不足で、午後Ⅱの出来を確認することも出来ず不戦敗のような感じです。
　結果は下記の通りで...

　この内容を戒めにして、今後は計画的に知識の吸収と確認を実施して合格を勝ち取ることにするぞ！ (>_<)

ネットワーク構築後のセキュリティ技術

　昨日（９月４日）、東京都のキャリアップ講習「ネットワーク構築後のセキュリティ技術」の第２回目を受講してきました。

　今までも何度か東京都のキャリアップ講習を受講したことがあるのですが、募集時の説明が概略であるせいか実際に受講してみるとかなり初心者対象の内容であったりして何度も辛い（痛い？）目にあっています。（受講料は安いのですが、時間とお金をかけて講習開催地へ行くので..(-_-;)）

　しかし、自分の知識も曖昧であったりするので知識の定着を図るためにも、気になった講座は（ベンダーや東京都）受講をして行こうと考えています。（数万以上という高額のものは除きます）
　ルーターやスイッチ（特にL3）は、なかなか操る機会にも恵まれないので大変楽しみにしています。
講師の先生方は丁寧に説明して下さるのですが、受講生に初心者が多いとかなり説明を端折る（説明してもわからないだろうと･･･）。　こちらは、知識の定着のために来ているのできちんと聞きたいのだが...(~_~)

　前回は暗号化についての基本的（初歩的）な講習と実習ではルーターの基本的な設定という内容でした。グループ（4人）ごとにルーター１台とスイッチ２台でルーティングを行う。

　今回は、IPsecの講習とルーター間でのパケットの暗号化（IPSec)を行いました。前回より少し難易度が増したせいか皆さん頑張っておりました。内容的には、講習・実習ともに、前回のおさらいを行ってから本題で IPSec について講習(午前）・実習（午後）が行われました。

　前半の課題は、２つのチームのネットワークのルーターで接続し、接続されたルーター間についてIPsecで暗号化通信を行う。（下記図参照）

後半の課題は、全６チームのルーター間をメッシュ接続する。（下記図参照）

　後半の課題は、時間がギリギリになり各チームとの暗号化の通信確認まではいかなかった。（部分的はチーム単位では疎通した。）

また、来週（最終回）は IEEE802.1X です。

PS.今週の資料（実習で必要な設定コマンドが記載）を実習室に置き忘れてしまった。(-_-;)
　今回（昨日）の実習の時も前回の資料を家に忘れてきてしまったので...orz