2017年02月14日

Apache de UserDir

本日のドツボ

1. loadmodule がコメントのままだった

2.ユーザーのhome が 0700だった

orz

ここの記事の事象と同じ。

ユーザディレクトリ公開時に「403 Forbidden」
続きを読む
posted by koteitan at 17:23| Comment(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月10日

TicketBleed (CVE-2016-9244)

HeartBleed にもじったのかなー。

SSLのTicketが有効な場合にのみ31バイト分の未初期化メモリが見えてしまうという脆弱性。
クリアしていないメモリ=なんらかのセキュア情報を含む(可能性が高い)ので、
えらいこっちゃというわけですな。


チケットについてはこちらが詳しい

TLSセッション再開 (session resumption) のしくみ

TLS Session Ticketの動作をtsharkでなんとなく覗きみる

RFCのリンクもはっておきます。


F5社のページ

発見者のページ
※確認用のユーティリティがおいてありますが、あくまで自己責任で!


続きを読む
posted by koteitan at 11:18| Comment(0) | TrackBack(0) | 情報処理 | このブログの読者になる | 更新情報をチェックする

2017年02月07日

Cookieの有効範囲と省略時の動作について

結果オーライでdomain無指定がうまく機能している状況を目の当たりにして
どういう動きか説明する資料を作成するために、情報収集したので、備忘録しておこう。

Cookieの仕様とセキュリティ > domain指定

domain を指定しない場合は、Set-Cookie を送信したホストにのみクッキーは送信されます。 domain 属性なしで、example.com によって設定されたクッキーは www.example.com や docs.example.com には送信されません。 domain を省略した場合と、domainに今接続しているホスト名を指定した場合ではクッキーが送信される範囲が異なる点に注意が必要です。 サブドメインに送信されてはならないクッキーには domain 属性はつけてはなりません。


CookieのDomain属性は *指定しない* が一番安全 〜徳丸浩の日記


    Domain属性を指定しないCookieは、Cookieを発行したホストのみに送信される
    Domain属性を指定したCookieは、指定のホストおよびそのサブドメインのホストに送信される

すなわち、Domain=example.comを指定したCookieは、www.example.comにも送信されます。Domain属性を指定しないCookieは、example.comに送信され、www.example.comには送信されません。
これは、CookieのRFC2965(旧規格)、RFC6265(現規格)には明確に記述されています。

    3.3.1 【中略】
    Domain Defaults to the effective request-host. (Note that because there is no dot at the beginning of effective request-host, the default Domain can only domain-match itself.)
    http://www.ietf.org/rfc/rfc2965.txt

    4.1.2.3. The Domain Attribute
    【中略】If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.
    http://www.ietf.org/rfc/rfc6265.txt



RFCからの引用があるとお偉い方も納得してくださる。RFC偉大。
posted by koteitan at 11:30| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2017年02月01日

WebSphereプラグインログからIHSのPIDとTID

こんなものを見たい状況がイマイチよくわからないが、Pluginのログの書式は

日付 PID TID メッセージ

[18/Jan/2015:03:30:16.09247] 00eb00d4 00000306 - ERROR: ws_common: websphereHandleRequest: Failed to execute the transac

赤いところがPID(16進)、緑がTID(16進)ってことやね。

10進にしたけりゃ、 perl -lane 'print "@F[0]" , " " ,hex "@F[1]" ," ",hex "@F[2]"'とかでいいんでないか。
ラベル:WebSphere
posted by koteitan at 11:30| Comment(0) | TrackBack(0) | WebSphere | このブログの読者になる | 更新情報をチェックする

2017年01月17日

IHSでSSLhandshake問題の調査方法

調査方法というより、トレースの取り方ですな。

トレースはIHS側のmod_sslのトレースと、
肝心の暗号処理を行っているgskitのトレースを取ることになります。
やり方は簡単で、ちょっと設定をいれて再起動するだけです。
めっちゃログがでるようになるので注意。

httpd.conf の LogLevelをdebugに
httpd.conf に SSLTraceを追加
export GSK_TRACE_FILE=/tmp/gsk_trace.log

IHS再起動で反映

終わったら、httpd.confを戻し、unset GSK_TRACE_FILE

もっと細かいオプション等はリンク先で。


ラベル:ssl IHS GSKit
posted by koteitan at 10:53| Comment(0) | TrackBack(0) | WebSphere | このブログの読者になる | 更新情報をチェックする

2017年01月08日

cipherのマッチング順序制御

デフォルトはクライアント優先

以下のパラメータが有効であると、サーバーが優先(SSLv3、TLS1.0の時)

Apache
SSLHonorCipherOrder 

Nginx
ssl_prefer_server_ciphers

BIGIP
Cipher server preference

IHS
無い。常にサーバーが優先
Does IHS have anything like mod_ssl's SSLHonorcipherorder?

No, IHS always uses the servers preference (acts like 'SSLHonorcipherorder on');



うむ、見事にバラバラである。
posted by koteitan at 16:49| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2016年11月26日

[IHS]Etagについて

Etagは各コンテンツに対するハッシュ値みたいなもので、更新日付のみでの
(last-modified)のみでのキャッシュより精密な制御ができる。
古い日付のファイルで更新した場合、Etag無効なら更新が反映されずキャッシュがでてしまうというように。

無論経路上に存在するキャッシュ機器やブラウザが対応していないとダメ。
最近ならほとんど対応してるはず。

CVE-2003-1418なんて古−−−い脆弱性を調べてたときのメモである
Etagの値を求めるのに、inode番号を使ってたから、inodeが漏えいするってえやつ。
inodeが漏れただけではなんともないが、別の脆弱性と組み合わせてって感じなのかな。


以下リンク
IHS: ETagの無効化について

Disabling ETag headers in IBM HTTP Server

How do we fix "ETag Inode Information Leakage" vulnerability in IHS?

Apache HTTP Server での MIME メッセージ境界による情報漏えい (ApacheMimeInformationDisclosure)

ApacheのETAG計算
クラウド環境でのApacheの設定

ETagについて調べてみた


posted by koteitan at 10:44| Comment(0) | TrackBack(0) | WebSphere | このブログの読者になる | 更新情報をチェックする

[WebSphere]WebSphereでコネクションプールの状況をコマンドから確認する方法

昔はPMIモジュールを有効にして、TPVするしか確認できなかったのに、
最近は簡単になったんだねぇ。

1.wsadminツールにて管理ノードへ接続します

wsadmin.sh -lang jython -user <USERNAME> -password <PASSWORD>

2.対象のMbeanを検索します。

ds=AdminControl.queryNames('*:j2eeType=JDBCDataSource,name=DS名,process=AS名,*')

3.pool状況をモニタします

AdminControl.invoke(ds,"showPoolContents")


出力される内容の

Total number of connections: 1 (max/min 10/1, reap/unused/aged 180/1800/0, connectiontimeout/purge 180/EntirePool)
                               (testConnection/inteval false/0, stuck timer/time/threshold 0/0/0, surge time/connections 0/-1)

ここがプールの状況で、(これは1つプールされていて、最小1 最大10って意味)

Shared/Unsahred Connection information

ここにコネクションの使用状況が出る。スレッドIDが出るので、javacoreを吐かせて処理を特定できる。
同じスレッドIDがいくつもつかんでいたりすると開放漏れのリークかもねぇ。


参考

posted by koteitan at 10:39| Comment(0) | TrackBack(0) | WebSphere | このブログの読者になる | 更新情報をチェックする

2016年11月10日

RHEL de Tomcat

・バンドルされているTomcatだと、背筋の良い猫の画面やマネジメント画面がでない
 必要なファイルセットが不足。TOMCATとしては機能している。
 WASでいうところの管理コンソールとDefaultApplicationがインストールされていない状態。
 yum installで追加インストールすれば行けるみたいだが、
 ネットワークにつながらない場合はめんどくさい上に古いから、
 本家から拾ってきたほうがいいと思う。


 どんな罠だよ。

・最新はTomcat9だが、Tomcat9にするにはJava8が必要。

・管理画面を使うにはtomcat-users.xmlの編集が必要


バンドルじゃなかったらサポートはありませんとか言われるんだろうな、これ。
Tomcatのインストールなんて3分かからないのにねぇ・・。

posted by koteitan at 23:48| Comment(0) | TrackBack(0) | OSS | このブログの読者になる | 更新情報をチェックする