linux, 小ネタ

 

ほんとに小ネタです。すみません。

先ほどpingを打ちながら、ふと、こんなふうに使っていたなあと思ったので徒然なるままに。

pingに日付を付けたい時はこれ

$ ping localhost | perl -pe 'use POSIX;$x=POSIX::strftime("%Y/%m/%d %H:%M:%S ", localtime()); s/^/$x/;'

 

localhostへのpingはこれ

$ ping 0

 

pingの途中で統計が見たいときは[CTRL]を押しながら[¥]

$ ping  0

PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.045 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.033 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.032 ms
5/5 packets, 0% loss, min/avg/ewma/max = 0.014/0.029/0.022/0.045 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.013 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.017 ms
64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=0.017 ms
10/10 packets, 0% loss, min/avg/ewma/max = 0.013/0.024/0.020/0.045 ms
64 bytes from 127.0.0.1: icmp_seq=11 ttl=64 time=0.027 ms
64 bytes from 127.0.0.1: icmp_seq=12 ttl=64 time=0.018 ms
12/12 packets, 0% loss, min/avg/ewma/max = 0.013/0.023/0.021/0.045 ms
64 bytes from 127.0.0.1: icmp_seq=13 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=14 ttl=64 time=0.019 ms
64 bytes from 127.0.0.1: icmp_seq=15 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_seq=16 ttl=64 time=0.016 ms
16/16 packets, 0% loss, min/avg/ewma/max = 0.013/0.023/0.021/0.045 ms
64 bytes from 127.0.0.1: icmp_seq=17 ttl=64 time=0.018 ms
64 bytes from 127.0.0.1: icmp_seq=18 ttl=64 time=0.016 ms
^C
— 0 ping statistics —
18 packets transmitted, 18 received, 0% packet loss, time 17429ms
rtt min/avg/max/mdev = 0.013/0.022/0.045/0.010 ms

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

PAGE TOP