2016年11月22日火曜日

CentOS5のyumな環境でATS対応させた話

どうもtaka3110ことどんです。

今回は待った無しになっているATS対応の話です。
そもそもATS対応って何じゃい?という方は、こちらをご参照下さい。

簡単に言うと、AppleさんとこのIOSアプリからAppleさんが言うセキュリティに
準拠していないサイトは片っ端から弾きまっせ。覚悟しとき。
という宣告です。

ATSに対応する為には
-------------------
・ TLS ver 1.2以上であること
・ 以下のcipherに対応している事
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
・サーバ証明書はsha256でキーは2048bit長以上にする事
-------------------
というルールがあるらしい。

何が困ったってCentOS5系を運用しているサイトやゲームですね。
特に側ネイティブでやっているアプリなんて季節的にもCentOS5があったりするのでは?

CentOS5でATS対応するには、
・opensslをsrcからコンパイル
・apacheの最新版をsrcからコンパイル
しなければ対応出来ません。
(対応出来たよ!という方は教えて下さい・・・)
ちなみにopensslをsrcコンパイルしてmod_ssl作ればええやん的な安易な発想でしたが、
SSLCompressionの設定、ECDHEに対応していない等の罠があり結論無理でした。

yumの環境だと相当難儀な作業になります。
モジュール類、特にphpもソースコンパイルして対応となると、
もうね、それだけで面倒な作業。

という訳で、出来る限りyumでインストールされている現況を崩す事なく、
何とかATS対応出来ないかという事でやってみました。

aprを変更せずに、prefix指定でソースコンパイルすれば、
そのままyumで入れた同じモジュールを使えるのではないか説が沸きあがり、
実際にやってみたら使えたのでご紹介します。
(実際にやっても自己責任でお願いしますね・・・)

1.作業ディレクトリ作成
解りやすく作業する為に作業ディレクトリを作ります。

mkdir /root/src
cd /root/src

2.ソースゲット
最新版のソースをゲットします。
元々2.2系だったので、2.2系の最新とopensslの1.0.1の最新を入れます。

wget http://ftp.jaist.ac.jp/pub/apache/httpd/httpd-2.2.31.tar.gz
wget https://www.openssl.org/source/openssl-1.0.1u.tar.gz

3.opensslのインストール
あくまでmod_sslを作るためだけのopensslにしたいので、
prefixを指定してインストールします。
#config時の"-fPIC"は入れても入れなくても大丈夫です。入れた場合、ソースの書き換えが一部必要になります。

tar xzvf openssl-1.0.1u.tar.gz
cd openssl-1.0.1u
./config --prefix=/usr/local/openssl1.0.1 shared
make
make install
cd ..

4.apache
apacheについても既存環境を汚さないようにprefixを指定してインストールします。
ちなみにenable類は無くても大丈夫だと思います。何か、念のためやりました。

tar xzvf httpd-2.2.31.tar.gz
cd httpd-2.2.31
./configure --prefix=/usr/local/httpd-2.2.31 \
--enable-dav=shared \
--enable-dav-fs=shared \
--enable-dav-lock=shared \
--enable-proxy=shared \
--enable-proxy-connect=shared \
--enable-proxy-ftp=shared \
--enable-proxy-http=shared \
--enable-proxy-balancer=shared \
--enable-proxy-ajp=shared \
--enable-rewrite=shared \
--enable-ssl=shared \
--enable-mem-cache=shared \
--enable-so \
--enable-modules=all \
--enable-mods-shared=all \
--with-ssl=/usr/local/openssl1.0.1
make
make install
cd ..


ここまで出来れば後はapacheのmoduleと起動スクリプト類を入れ替えるだけです。
ちなみに同じようなCentOS5が他にもある場合、ここで作ったディレクトリを配布すれば、
いちからコンパイルする必要は無いです。
/usr/local配下にopenssl1.0.1とhttpd-2.2.31ディレクトリを置いてやればokです。


適用作業はこんな感じでやりました。

5.初期コンフィグのバックアップ
戻せるようにしておきましょう。

mv /usr/local/httpd-2.2.31/conf /usr/local/httpd-2.2.31/conf.org
mv /usr/local/httpd-2.2.31/modules /usr/local/httpd-2.2.31/modules.org

6.既存モジュールのcopy
yumで入れたモジュールをコピーします。
#パスは64bitの場合です。

cp -rp /usr/lib64/httpd/modules /usr/local/httpd-2.2.31/

7.既存コンフィグのコピー
既存のコンフィグを適用させましょう。

cp -rp /etc/httpd/conf /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/conf.d /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/common /usr/local/httpd-2.2.31/

8.設定ファイル類のディレクトリ構成設定
運用性を考えて同じディレクトリ構成にしておきましょう。

mv /etc/httpd /etc/httpd.org
ln -s /usr/local/httpd-2.2.31 /etc/httpd

9.起動ファイルの変更
戻せるようにしておくのと、tab効きするようにしておきましょう。

mv /etc/init.d/httpd /etc/init.d/httpd.org
chmod -x /etc/init.d/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/apachectl /etc/init.d/httpd
mv /usr/sbin/httpd /usr/sbin/httpd.org
chmod -x /usr/sbin/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/httpd /usr/sbin/httpd

10.mod_sslのモジュールのみコピー
mod_sslは今回コンパイルしたものを使います。

cp -pi /usr/local/httpd-2.2.31/modules.org/mod_ssl.so /usr/local/httpd-2.2.31/modules/

11.logやrunフォルダの設定
logフォルダは引き継ぐようにしておきます。

mkdir /etc/httpd/run
mv /etc/httpd/logs /etc/httpd/logs.org
ln -s /var/log/httpd /etc/httpd/logs

12.アップデートしたopensslをmod_sslが読みに行く為の設定
最後にmod_sslがprefixしたopensslを読みに行けるようにしておきます。

echo "/usr/local/openssl1.0.1/lib" >> /etc/ld.so.conf
ldconfig

以上で完了。
古いapacheが上がっていればpkill httpdで落としてやれば、
普通に新しいapacheを上げられる筈。

これで構築したサイトを以下で見てみるとATS対応している筈。
https://www.ssllabs.com/ssltest/


ここまででとりあえず一時しのぎ的にATS対応出来たとしましょう。
でもね、そもそも論としてCentOS5を使い続けるってどうなのよ?
という疑問を投げかけざるを得ない。

という訳で、取り急ぎ時間が出来たという事で、
しっかりと計画してリプレースしましょう。

それではよいクラウド構築を。












一応、、、、もとにもどす手順も置いときます。

rm /etc/httpd
mv /etc/httpd.org /etc/httpd
rm /etc/init.d/httpd
mv /etc/init.d/httpd.org /etc/init.d/httpd
chmod +x /etc/init.d/httpd
rm /usr/sbin/httpd
mv /usr/sbin/httpd.org /usr/sbin/httpd
chmod +x /usr/sbin/httpd

2016年9月20日火曜日

YAMAHAのルーターで存在しないNWを使ってVPNする話

どうもtaka3110ことどんです。

最近、YAMAHAのルーターと戯れる事が多かったので、
少しメモ代わりに書いておきます。

題名だけ見ると大それたというか、謎めいた感じですが、
簡単に言えばNATです。はい。
ただ、双方向NAT(TwiceNAT)のドキュメントはありますが、
単方向NATでマスカレードしないのはあまりなく、でも結構使う機会がある。
というところでブログネタにした訳です。

最近ではフレッツVPNなどで店舗間でも割と簡単にフレッツ網を使ったVPNがはれます。
店舗間データのやり取りをセキュアに行いたい等、結構使う機会はあると思います。
例えば、本店と店舗のNWが全く同じ場合は、前記のTwiceNATを用いれば良いですが、
(TwiceNATの設定例:http://jp.yamaha.com/products/network/solution/vpn/connect/twice_nat/ )
本店が「このNWで接続して下さい。」と払い出されて、店舗側が違うNWになっている場合。
これって、店舗側のNWを総入れ替えするか、NATするかの2択な訳で。
やれ工数だの改修だのを考えると、結論NATになる訳です。

ただ、もう1台ルーターを置いてやるのが綺麗なやり方。
存在しないNWではなく、存在するNWを作ってしまう。
本社ルーター --> 店舗ルーター(NEW) -(払い出しNW)-> 店舗ルーター
という感じで払い出しNWを作ってしまって、そこのIP帯でNATさせる。
というのが割と綺麗なやり方だと思います。
が、そんなポコスカとルーターを買うという訳にもいかないと思いますし、
出来るので、1台でやってしまいましょうと。

そうすると、やり方としてはざっと考えて2つあって、
・ セカンダリIPをつけてルーティングさせてしまう。
・ 払い出しNWのIPでNATさせてしまう。
という2つかと。

で、もう存在はしてないけど、払い出しNWのIPでNATして通信出来れば良い。
という事で、今回はそんな感じの話です。

本店から払い出されたNWは10.1.10.1/24
基幹に接続するコンピュータのIPは接続元制限により10.1.10.254のみ許可。
例えばストコンが基幹にデータを送る場合は上記IPで送る必要がある。
というような感じ。


構築するNWはこんな感じです。


















で、どう構築するかって話になるんですが、
先のTwiceNATのページのreverseの部分を削除すればいいだけ。
というより、TwiceNATも存在しないNWを間に挟んで同じNWを通信させてるイメージなので、
それと同じことをしてやれば良いと。

書き方も割と単純に、ほんとreverseを削除しただけのこんな感じで通ります。
(ISPの部分やVPN認証、フィルタ等の設定は別途必要)
---
#ルーティング
ip route 172.11.0.16/32 gateway pp 1
ip route 10.20.0.0/16 gateway tunnel 1

#NAT
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 172.11.0.16 udp 500
nat descriptor masquerade static 1 2 172.11.0.16 esp
nat descriptor type 2 nat
nat descriptor address outer 2 10.1.10.1-10.1.10.254
nat descriptor static 2 1 10.1.1.254=192.168.1.50 1

pp select 1
ip pp address 172.11.0.1/32
ip pp nat descriptor 1

tunnel select 1
ip tunnel nat descriptor 2
---

やっぱり存在しないNWがあって、途中でNATにより処理する。
というのはあり得る話なんですが、少し気持ち悪いなぁ。と思うのは私だけかしら。。

割と設計的にはあり得る話ですが、ググってもなかなか出てこないので、
書いてみました。

というわけで、よいクラウド?構築を。

2016年8月27日土曜日

IDCFクラウドの追加NWの注意点

最近、IDCFクラウドの追加ネットワークでちょっとしたハマり方をしたのでメモ。


IDCFクラウドはネットワークを追加する事が出来ます。
NICも独立するので、インターネット側のNWとは別にしてVPNのネットワークを作ったり、
DBの通信にしようしたり、Heartbeat専用のネットワークを作ったり。
まぁ、いろんな設計が無停止で柔軟に出来るようになっています。
ネットワーク追加も従量課金で20円/時間で課金され、1か月1万円が課金上限になるシステムです。

で、今回は既存の環境から移設というところで構築したのですが、
色々な制限があり再設計する事になりました。
結論から言うと、追加ネットワークを使った設計をする時は、
実際に追加ネットワークをしてから設計するか、IPを柔軟に変更できる設計にしておくと良いです。
例えばDBと接続する際にIP指定で許可している場合、許可設定の変更をしたり、
そもそもDBのIPが変更しなければならない可能性があります。
同じハマり方をしないようにご注意というところで。


1.システム予約IPがある
後方20個のIPはシステム予約として使用出来ないIPになっています。
例えば、デフォルトで以下NWが指定されます。(もちろん変更可能)
192.168.0.0/21
上記のうち、192.168.7.235~254はシステムで予約して使用不可能になっています。
従って、後方20IPを使用したIP設計は見直しになります。

2.CIDRが/24~/21のみ
CIDRは/24~/21でしか使用できません。/25、/26のNWは作れません。
従って、/24よりも分割されたNWは設計見直しになります。

3.仮想ルーターにIPが自動で採番される
仮想ルーターにIPが自動で採番されます。これはシステム予約IPに含まれていません。
例えば、192.168.0.0/21のNWで構築した場合、どこに採番されるか解りません。
基本的には192.168.0.1が使用されるようですが、2や3が採番される可能性もあります。
仮想ルーターのIPは使用出来ないので、こちらも被った場合は設計見直しになります。


ご察しの通り、3に見事にはまりまして。
移設前はWebサーバーを192.168.0.1に割り振っていたのですが、
移設したところ仮想ルーターに192.168.0.1を取られてしまい採番出来なくなりました。
今回はteslaからnewtonへのゾーン間移設だったのですが、
移設前と移設後で仮想ルーターのIPが変わった為、このようなハマり方をした次第です。

もし、セキュリティ的にもしばりが無いようであれば、
192.168.0.0/24のNWを作る場合、
192.168.0.0/23のNWを作って、192.168.1.1~254の範囲でIP設計をすると良いと思います。
どうしても/24で作成する場合、念のため、192.168.0.1~10は使用しない等で回避が出来るかと思います。


ちなみに、NICは追加/削除をしていくとデバイス名が変わります。
CentOS7であればさほど困らないかもしれませんが、、

CentOS6系でNICを追加/削除してeth1のつもりがeth2や3になってeth1に戻したいという場合、
udevを修正する事で変更する事が可能です。
以下ファイルにNICの情報が記載されています。
/etc/udev/rules.d/70-persistent-net.rules
上記ファイルで不要なNIC情報を削除し、最後に割り当てられているNICのnameをeth1にします。
udev rulesの反映を行う為に以下コマンドを実行します。
start_udev
これでeth1に戻ります。
あまり使う機会は無いと思いますが。。

それではよいクラウド構築を!

2016年7月11日月曜日

クラウドの勉強会をやる際に注意するポイント

最近、クラウド系の勉強会をやる機会が多いどん斉藤ことtaka3110です。

初級~中級、上級、テスト対策、いろいろとやります。
非エンジニア向けのクラウド勉強会などもやったりします。
ベンダーフリーで使うクラウドは問わないので、こんな勉強会やってよ!など、
ご依頼はtaka3110までご連絡頂ければ打ち合わせ/企画から一緒にやります。

さて、宣伝はこの辺にして。。
クラウド系の勉強会、特にハンズオンの勉強会をやるときに注意するポイントが結構あります。
今回、実際にハマるポイントを書こうと思います。

① 上限の確認
 複数人でやる場合、サーバーの上限やIPの上限等、
クラウドが定める上限値に達していないか確認をします。
上限以上を使用するならば、上限の緩和申請をサポートにしましょう。
殆どのクラウドで上限の緩和が可能です。
遅くても3営業日前には申請をするようにしましょう。

② 同じアカウント内で同時実行時のデフォルトパラメーター確認
 同じ資料を見ながら行った場合やデフォルトの値を使用する場合に、
値がすべて同じになってしまいエラーが続発する可能性があります。
特に同じアカウントでやる場合(AWSでIAM使用する場合も含む)は、
ユーザー名を追加する等、ユニークな値を入力してもらうようにしましょう。
例:AWSのサーバー起動時のセキュリティグループ等

③ リージョンの確認
 これもハンズオンをやる時にたびたび出る問題です。
多くのクラウドはリージョンの変更を行っても殆ど画面上に変化はありません。
リージョンを指定して、ログインした際に確認するように促します。

④ OS選択時のマイナーバージョンの確認
 OSによってはマイナーバージョンが違うだけでログイン方法が変わるものがあります。
(管理者ログインが禁止されているものなど)
テンプレートやAMI等を選んでもらう際にはID等で解るようにしておきます。

⑤ 削除漏れの確認
 削除したと思ってDiskが残っていたり、スナップショットが残っていたりする事があります。
勉強会が終わったら、早めにリソース状況の確認を行って削除するようにしましょう。

⑥ サービスとアカウントを分ける
 これが一番恐ろしいんです!
社内の場合、同じアカウント内にユーザーを作成して多人数で実施するケースが多いと思います。
サービス提供をしているサーバーがある場合は間違えて停止や削除等の誤操作をする可能性があります。
結構触ってもらいたい場合、管理者に近い権限を付与する事になります。
教える側も緊張するので、なるべくサービスアカウントではなく、別途アカウントを取得するようにしましょう!
いたしかたない場合はリージョンを変更する等で容易に触れられない環境を作りましょう。


クラウドは便利なんですけど、便利だから簡単に出来るのではなく、
最低限の準備は必要という事ですね。

それでは、よいクラウド構築を!

2016年7月1日金曜日

IDCFクラウドのDisk領域を3GBにしたテンプレート

Disk領域3GBのCentOS6.8テンプレートを作りました。

light.S1ならば1か月稼働で260円程度(2016/06/30現在)になります。
落としておいても1か月60円程度ですので、気軽に複数台の検証サーバとして使えるかと。
空き容量は約1.4GB程度ありますので、
色々と試せる環境かと思います。
cloudstack-apiもインストール済みなので、
ちょっとしたAPIテストや、検証などにご使用ください。

またコンテンツ領域を追加Diskにしてlogローテを行い、
そのlogをオブジェクトストレージ上に保存する事で、
コンテンツ領域のみをスナップショットでバックアップしながら、
無償で使える50GBのオブジェクトストレージを有効活用するなんて事も出来るかと思います。

いろんな用途で試して頂ければ幸いです。

自分の場合はab(負荷テスト)用として使ったり、踏み台として利用したり。
使わない時は落としておくような、ちょっとした事に使ってます。

要望やバグ連絡は本ブログにコメント頂ければ幸いです。
ちなみに本テンプレートを元に更新してコミュニティテンプレートをアップ頂いて構いません。

詳細
----
OS:CentOS 6.8
インストール:Baseシステム
その他:
・VMW関連
vmware-tools-esx-nox
vmware-tools-esx-kmods
vmware-tools-vmxnet3-common

・IDCFクラウド関連
パスワード変更ツール
認証鍵変更ツール
cloudstack-api(v0.10.2)

・開発関連
pip(8.1.2)
git(1.7.1)
及び上記解決の為のソフトウェア

セキュリティ:
iptables off
ip6tables off
selinux Disable
----

2016年6月30日木曜日

IDCFクラウドでテンプレートのエクスポートロックを解除する話

どうも、taka3110ことどん斉藤です。

IDCFクラウドはテンプレートをエクスポートが出来ます。
ただしISOから作成した仮想マシンのテンプレートは、
ライセンスの問題もあってエクスポートが出来ないようになっています。

オープンソースの場合はサポートに申請をすれば、
すぐにエクスポートロックの解除対応をしてくれます。

こんな感じで申請します。
-----
CentOS6.8を使用して作成した以下テンプレートについて、
エクスポートロックの解除をお願いします。
テンプレートID:[テンプレートIDを記入]
-----

そうすると中の人が確認をしてくれます。
問題無ければエクスポートロックの解除をした旨連絡が入ります。

公式のテンプレートはDiskが15GBで縛られている為、
サーバーを止めていても月額で300円掛かってしまうんですよね。
自分は3GB程度あれば良いので、ISOから作成しています。

エクスポートロックが解除されるとリージョン/ゾーン間でコピー出来るようになりますし、
コミュニティテンプレートの公開も可能になります。
エクスポートロックが解除されたテンプレートは、そのままコミュニティテンプレートには
出来ません。
一旦、エクスポートのURLを発行して、そのURLを使ってテンプレート作成をする事で、
コミュニティテンプレートが作れるようになります。ここは謎仕様です。
(発行されたURLはhttps://~ですが、テンプレート作成時はhttp://~に書き換えれば読み込めます)

それでは、良いクラウド構築を!


2016年5月24日火曜日

IDCFクラウド「MORIO Dojo」に認定してもらったはなし

ブログを書くのが苦手なtaka3110こと、どん斉藤です。

なんでブログって書けないんですかね。
これ書こう、あれ書こう、って思って休日を迎えるんですけど、
結果的に家族サービスや競馬やってるんですよね。
ITへの愛が足りないのか。愛が。

という訳で、環境から作ろうという事でブログを書くきっかけを作りました。
IDCFクラウドで新しくアンバサダープログラムが始まりました。
その名も「MORIO Dojo」(モリオ道場)
IDCFクラウドの使いっぷりやコミュニティでの活躍っぷりによって、
段位認定してくれるというシステム。

このプログラムに参加すると、クローズドのコミュニティに参加して、
IDCFクラウドに長けたいろんな方々と会話が出来たり、
限定イベントに招待してもらえたり、プレゼントもらったり出来るそうです。

段位自体は空手みたいな感じで帯色によって認定が分かれてます。
段位認定の条件をクリアすれば次の段位へ!という形で、
最高段位のMORI帯を目指す。という感じのようです。
ゲーミフィケーション的な感じで面白いですね。

私もコミュニティを運営している端くれとして青帯で認定依頼をしたところ、
認定してもらえた次第です。
MORI帯までの道のりとして、一番の山場は3か月間、1か月に1度はIDCFクラウドの記事を書く。
基本、このブログはIDCFクラウドネタが多いのですが、連続性が無い、というか、
ブログを続けて書けない人なので、これをモチベーションにしてブログを続けてみようと。
そういう次第であります。
さて、私のクリア状況ですが、

白帯:
◎PCにMORIOステッカーを貼ってる
◎個人で発信する媒体を持っている
青帯:[いまここ]
◎ユーザー会への参加
○クローズドコミュニティでの積極的な発言
茶帯:
×IDCFクラウドのバナーを貼っている
△IDCFクラウド関連の記事を投稿(1か月に1回程度)
黒帯:
×IDCFクラウド関連の記事を3か月連続で投稿
◎お客様の声への協力
MORI帯:
◎ユーザー会を運営
×コミュニティテンプレートを公開

という訳で、茶帯は直ぐいけそうですが、黒帯は3か月後になりそう。
飛び級出来るなら3か月後にはMORI帯になれるんじゃないかと。

白帯については割と直ぐに認定されそうです。
青帯ですが、ユーザー会への参加があります。
東京では6月28日(火)にユーザー会を予定してますので、
こちらもチェキっといてもらえれば来月には青帯になれると。
ユーザーコミュニティ

というか、ユーザーコミュニティを作ってしまえばMORI帯の条件をクリア出来ます。
初めての運営でもmeetup運営メンバーに優しくサポートしてもらえます。
作りたいけどどうすんの?とか、やりたいから手伝って!
という方は以下の問い合わせから連絡くれればお手伝いします。

MORIO道場で検索すると奈良のよくわからん公共施設がヒットするので、
検索するときはMORIO Dojoで検索しましょう。
もしくは以下URLからどうぞ。

早速6月に限定イベントやるそうなので、登録はお早めに~。