SSL

 

理由を説明しますと、

クロスルート証明書が正しくインストールされているかどうかを確認するにはこの方法しかないためです。

過去にクロスルート証明書の設定に問題があり、

通常のブラウザ(といってもie7以上)での動作確認はエラーとならないため、指摘されるまで気づかなたったという件がありました。

よくよく確認していくと

ie6やネットスケープナビゲーターじゃないとクロスルート証明書が正しく設定されているのかが確認ができないことがわかりました。

こうやって、

dmmのie6は1台のpcだけ存在し隔離された状態で細々と現役を続行していくこととなります。

 

クロスルート証明書を使うと

ガラケーなどの古いブラウザでもサイトの認証が可能となり安全なSSL通信が可能となります。

古いブラウザ⇒中間CA⇒最新ルートCA(クロスルート)⇒昔のルートCA⇒サイトの認証OK

という流れですが、

クロスルート証明書を使わないと

ガラケーの古いブラウザには最新のルートCAがプリインストールされておりませんので、

下記のように

古いブラウザ⇒中間CA⇒最新ルートCA⇒サイトの認証エラー

最新のルートCAは信頼されずサイトの認証はエラーとなってしまいます。

一方、ie7以上のブラウザなら下記の通りエラーとはなりません。

最新ルートCAがプリインストールされたブラウザ⇒中間CA⇒最新ルートCA⇒サイトの認証OK

 

 

最後にie6とie10の見え方の違いをご紹介します。

ie6はクロスルート証明書を含む4階層

ie6

ie10はクロスルート証明書は必要ないので3階層

ie10

 

これを見るとわかっていただけると思うのですがie7以上だとクロスルートを必要としないので動作確認ができないんですね。

hardware, linux

 

前回の記事でBroadcomのnicでは分散ができないのではないかとお伝えしましたが、

解決方法が見つかりましたのでご連絡します。

設定前の/proc/interruptsです。

interrupts

em1はcpu0に偏っています。

p6p1は問題なく分散されています。

早速設定してみます。

IRQごとに利用できるCPUを指定してあげると分散するようになるようです。

コマンドはこちらです。108、109、110、111は/proc/interruptsを見れば確認できます。

echo 1 > /proc/irq/108/smp_affinity
echo 2 > /proc/irq/109/smp_affinity
echo 4 > /proc/irq/110/smp_affinity
echo 8 > /proc/irq/111/smp_affinity

cpuの番号はこのように指定します。
参考ページ:https://cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt

              Binary         Hex 
    CPU 0    00000001         1 
    CPU 1    00000010         2
    CPU 2    00000100         4
    CPU 3    00001000         8
    CPU 0    00010000         10 
    CPU 5    00100000         20
    CPU 6    01000000         40
    CPU 7    10000000         80

このコマンド入力後、memslapで負荷をかけてみた結果が以下です。

broadcomkaizen

分散ができるようになったようです。

これでintelでもbroadcomでもコントロール可能となりました。

あとは起動時に読み込まれるように下記で設定しておきます。
※smp_affinityは/proc/sys以外のディレクトリで管理されているのでsysctl.confでは設定はできないようです。

vi /etc/rc.d/rc.local

いずれにしても多くのコアを搭載するようになった現在、キューも多く割り当てられているほうが分散させるにはよさそうです。

インフラ全般, クラウド, セキュリティ

世の中にはDDoSを防ぐためにいろんな製品やサービスが登場していますが、

そのどれも完璧に防げるとは言い切れないように思います。

ROIを考えても、完璧に防ぐための投資は莫大になりかねず、

リターンに見合わない投資が必要になってくるように思います。

そこで、シンプルな戦略を考えてみました。

まず、保護レベルを4段階ほど設定します。

1.アプリケーションサーバの保護
2.データベースの保護
3.ログイン処理の保護
4.メンテナンスモード

では、それぞれのレベルで対策を考えていきます。
1.アプリケーションサーバの保護

フロントサーバにnginxなどの高速なリバースプロクシサーバを配置。普段はキャッシュしない。

ショートパケットのSyn Floodの攻撃などはこのフロントエンドで吸収する。

また、特定できるパケットがあればそのパケットをiptablesなどで落とす

2.データベースの保護

フロントサーバのリバースプロクシサーバでほぼすべてのページをキャッシュさせるように設定変更

攻撃発生中はダイナミックなページを停止しキャッシュから静的なページを配信。

高速なウェブサーバであれば1台あたり10万リクエスト/秒での配信も可能。

特にhttp get floodに有効
3.ログイン処理の保護

ログインページを閉鎖する。もしくは流量制限を行う。

流量制限はフロントのサーバで行う。

決まった数のリクエストのみアプリケーションサーバへ渡す。それ以上はエラー処理

ポリシーに合わせてログインに失敗したIPをロックアウトする。

http post floodに有効

攻撃時であってもログイン後は通常サービスが提供可能とする

フロントサーバにてクッキーでログインを識別し専用のサーバへスイッチ
4.メンテナンスモード

フロントサーバにメンテナンスページを配置

想定以上の攻撃時はメンテナンスページへ
あとは、このフロントのサーバをどれだけ用意するかになってくると思います。

パブリッククラウドを組み合わせて各社のクラウドでも対応できるよう準備すれば大きな攻撃時に対応ができるかもしれません。

コストはその攻撃時に稼働させていたインスタンス分の支払いだけでよくなります。

以上、シンプルな戦略を考えてみたのですがいかがでしょうか?

ご意見いただけると助かります。

高価な攻撃対策用の製品であっても大規模な攻撃だとダウンしてしまいます。

であれば、こういった機材は検知用に利用することで、必要最低限の投資で最適なリターンが見込めるのではないかと。

いずれにしても、攻撃はサーバで守る。これが一番シンプルで確実じゃないかなあ。

 

 

linux, 小ネタ

 

PCIのクワッドポートを利用するときなんですが、

どっちがeth0なんだろうと今だに悩まされるときがあります。

そんな時の私の味方
ethtool -p eth0
指定したインターフェースポートでリンクが点灯しお知らせしてくれます。

ケーブルが差さってなくても大丈夫!(^^)v

linux

 

みんなご存知の方ばかりだと思いますので、

今回は共有するというよりは

最近、weighttpを初めて使ってみた自分に対する備忘録です。

マルチコア時代のウェブサーバの優等生「g-wan」のベンチを取るためにweighttpを知りました。

abやhttperfなどではg-wanを泣かすことができなかったのでweighttpで泣かせてみようと。

結果、泣かせることはできませんでしたが。^^;

開発者様に敬意を!

さて、実際にインストールしてコマンドを試してみます。

私もいろんなサイトで紹介されていたものを参考にしていますので、

詳細は他のサイトでご確認いただいたほうがいいかと思います。

gwanをインストールしたホスト自身にインストールしてlocalhost宛でベンチを取ります。

このベンチでは秒間のリクエスト処理数を確認してもらうのがいいかと思います。

参考までにhttperfやabの結果も載せておきます。

環境

CentOS release 6.4 (Final)
2.6.32-358.el6.x86_64
Intel Xeon E5-2640@2.50GHz * 2個
Memory 32GB
Program : G-WAN (freeware)
Platforms: Linux 32-bit and 64-bit

■weighttp

インストール

yum install -y --enablerepo=epel libev libev-devel
wget http://github.com/lighttpd/weighttp/zipball/master
unzip master
cd lighttpd-weighttp-c14ac58/
vi src/weighttp.h → ev.hのInludePathの修正
gcc -g2 -O2 src/*.c -o weighttp -lev -lpthread
cp ./weighttp /usr/local/bin

コマンド例

weighttp -n 100000 -c 300 -t 4 -k http://localhost:8080/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 75 concurrent requests, 25000 total requests
spawning thread #2: 75 concurrent requests, 25000 total requests
spawning thread #3: 75 concurrent requests, 25000 total requests
spawning thread #4: 75 concurrent requests, 25000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 0 sec, 305 millisec and 510 microsec, 327321 req/s, 2389702 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 747600000 bytes total, 25600000 bytes http, 722000000 bytes data

■httperf

インストール

rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
yum --enablerepo=rpmforge install httperf

コマンド例

httperf --server=127.0.0.1 --port=8080 --num-call=200 --num-conns=50 --hog --uri=/test.html
httperf --hog --client=0/1 --server=127.0.0.1 --port=8080 --uri=/test.html --send-buffer=4096 --recv-buffer=16384 --num-conns=50 --num-calls=200
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1

Total: connections 50 requests 10000 replies 10000 test-duration 0.198 s

Connection rate: 252.7 conn/s (4.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 3.9 avg 4.0 max 4.4 median 3.5 stddev 0.1
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 200.000

Request rate: 50540.8 req/s (0.0 ms/req)
Request size [B]: 71.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.0 transfer 0.0
Reply size [B]: header 255.0 content 2213.0 footer 0.0 (total 2468.0)
Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.04 system 0.16 (user 18.7% system 80.9% total 99.5%)
Net I/O: 125315.5 KB/s (1026.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

■Apache Bench

インストール

yum install -y httpd-tools

コマンド例

ab -c 300 -n 10000 -k http://localhost:8080/test.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: G-WAN
Server Hostname: localhost
Server Port: 8080

Document Path: /test.html
Document Length: 2213 bytes

Concurrency Level: 300
Time taken for tests: 0.109 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 10000
Total transferred: 25226516 bytes
HTML transferred: 22402199 bytes
Requests per second: 91367.59 [#/sec] (mean)
Time per request: 3.283 [ms] (mean)
Time per request: 0.011 [ms] (mean, across all concurrent requests)
Transfer rate: 225086.52 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.2 0 10
Processing: 2 3 0.2 3 6
Waiting: 2 3 0.2 3 6
Total: 2 3 1.2 3 13

Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 9
99% 11
100% 13 (longest request)

このような結果となりました。

ベンチツール 処理数/秒 web server application
weighttp 327321 G-WAN
httperf 50540 G-WAN
ab 91367 G-WAN

weighttpが圧倒的ですね。

ちなみに

g-wan、nginx、httpd、mighttpdのウェブサーバでもベンチを取ったので
比較も載せておきます。configはいじっていません。

web server application 処理数 ベンチツール
gwan 334944 req/s weighttp
nginx 111842 req/s  weighttp
httpd 19395 req/s  weighttp
mighttpd 107883 req/s  weighttp

各コマンドの詳細は下記です。

■g-wan

weighttp -n 100000 -c 300 -t 4 -k http://localhost:8080/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 75 concurrent requests, 25000 total requests
spawning thread #2: 75 concurrent requests, 25000 total requests
spawning thread #3: 75 concurrent requests, 25000 total requests
spawning thread #4: 75 concurrent requests, 25000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 0 sec, 298 millisec and 557 microsec, 334944 req/s, 2445420 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 747619832 bytes total, 25601273 bytes http, 722018559 bytes data

■nginx

weighttp -n 100000 -c 300 -t 4 -k http://localhost:80/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 75 concurrent requests, 25000 total requests
spawning thread #2: 75 concurrent requests, 25000 total requests
spawning thread #3: 75 concurrent requests, 25000 total requests
spawning thread #4: 75 concurrent requests, 25000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 0 sec, 894 millisec and 116 microsec, 111842 req/s, 427595 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 391495650 bytes total, 21695650 bytes http, 369800000 bytes data

■httpd

weighttp -n 100000 -c 300 -t 4 -k http://localhost:80/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 75 concurrent requests, 25000 total requests
spawning thread #2: 75 concurrent requests, 25000 total requests
spawning thread #3: 75 concurrent requests, 25000 total requests
spawning thread #4: 75 concurrent requests, 25000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 5 sec, 155 millisec and 910 microsec, 19395 req/s, 8769 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 0 succeeded, 100000 failed, 0 errored
status codes: 0 2xx, 0 3xx, 100000 4xx, 0 5xx
traffic: 46300000 bytes total, 46300000 bytes http, 0 bytes data

■mighttpd

weighttp -n 100000 -c 300 -t 4 -k http://localhost:80/index.html
weighttp - a lightweight and simple webserver benchmarking tool

starting benchmark...
spawning thread #1: 75 concurrent requests, 25000 total requests
spawning thread #2: 75 concurrent requests, 25000 total requests
spawning thread #3: 75 concurrent requests, 25000 total requests
spawning thread #4: 75 concurrent requests, 25000 total requests
progress: 10% done
progress: 20% done
progress: 30% done
progress: 40% done
progress: 50% done
progress: 60% done
progress: 70% done
progress: 80% done
progress: 90% done
progress: 100% done

finished in 0 sec, 926 millisec and 927 microsec, 107883 req/s, 410146 kbyte/s
requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0 failed, 0 errored
status codes: 100000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 389300000 bytes total, 19500000 bytes http, 369800000 bytes data

PAGE TOP