OCLHashcat と John the Ripper のマルコフ法の違い

other
  • JtRのレベルは文字列全体の確率から計算される値
    • 文字列の長さの最大値は決められるが, 文字列の長さそのものや最短文字数は指定できない.
    • 文字列の確率がレベルで指定された確率以上になるものは必ず検査される.
  • OCLHashcatのthresholdは, n 番目の文字から n+1 番目の文字を選ぶとき, 遷移確率上位の何番目までを選択するかの順位の数.
    • 文字列の長さ, 文字種は固定で変更できない.
    • 文字列長 L, threshold t のとき, 検査される空間の大きさは t^L.
      • 文字種が a 種類のとき threshold が a ならば, 全空間になる.
    • 文字列選択が局所的に決められているため, 速度は出るが, 文字列全体の確率が高いものが必ず検査されるわけではないということが起る.
      • 確率の低い遷移を切り捨ててしまっているため, 記号への遷移がある文字列がより選択されにくくなる.
    • threshold は整数値で指定され, 検査可能な全文字列空間の L 乗根で決まるため, L が長くなってくると容易に増やすことはできなくなる.

Twice-NAT の透過リダイレクション

other
  • IN,OUT,BACKの3つのネットワークがあり, IN から OUT への任意サーバへのWeb接続をBACKのWebサーバへリダイレクトする場合
    • network-any を subnet 0.0.0.0 0.0.0.0 と定義して任意のサーバを宛先変換する. any キーワードは受け付けられない.
    • service-web は tcp destination 80 のサービスオブジェクト
  • nat (IN,BACK) source static network-in network-back destination static network-any webserver-back service service-web service-web とした場合.
  • static NAT の結果 proxy-arp により応えることになるかは送信者のNAT変換先アドレスnetwork-backが宛先インターフェースBACKのネットワークに属するアドレスかによる.
    • 所属している場合が多いので, BACK側の変換先アドレスへBACK側から接続させるようにするかどうかを決めるno-proxy-arpオプションがある.
    • network-backから来たパケットをwebserver-backがBACKインターフェースに返すようなルーティングがあるなら, network-back アドレスをBACKのネットワークにしないことも可能
  • 逆に帰り道の変換である, 送信先のNAT前アドレス network-any がインターフェースINのネットワークに属するアドレスの場合 IN側でも proxy-arp 応答が返される.
    • IN側送信者の場合は送信先が送信者であるIN側のアドレスになることはないはずだが, 任意のアドレス net_any を指定した場合にはIN側ネットワークも含まれてしまうため, IN側の全てのアドレスにARPを返答するようになる.
    • 逆変換には no-proxy-arpオプションも効果がなく, destinationは必ずstaticでARP発信を行わないdynamic変換はないため, proxy-arpを止める方法がない.
    • このページの方法は機能しないのでは? http://networkengineering.stackexchange.com/questions/5970/asa-as-dns-transparent-proxy
  • IN 側で no-proxy-arp を有効にさせるため, 出入りを逆にした構文にする.
    • service-web オブジェクトも逆向きになるため destination でなく, tcp source 80 に修正が必要.
  • nat (BACK,IN) source static webserver-back network-any destination static network-back network-in service service-web service-web no-proxy-arp
    • 実際にはBACK側が発信者になることはできず, source アドレスが1:多の変換になっているようにみえるなど不自然な構文になる.

ASAの Twice-Nat でDNSパケットの書き換え

other
  • Object NATでの説明はドキュメントにあるが, Twiceの例は載っていない. Objectの例も成功例だけしか載っていないので, NATルールの順番を逆にした場合どうなるかまでわからない.
  • nat コマンドの dns オプションはDNSパケットの中身を書き換えるが, DNSに関係なくNAT,UNNATは行われる.
    • PIX時代からある機能だが, 挙動がわかりにくくなる原因. DNSの書き換えは別機能としてNATと分離できなかったのか?
  • WEBサーバがIN, OUTにIPを持ち,DNSサーバはOUTにあり, INからアクセスする時はWEBサーバのIN側アドレスに行くようにDNSパケットを書き換える場合
  • nat (in,out) source static wevsrvin wevsrvout dns と nat (out,in) source static wevsrvout wevsrvin dns はどちらもDNSサーバからのwebsrvoutという回答を通過時に書き換えてwebsrvinにするが, DNSパケット以外での挙動が違ってくる.
  • 共通の挙動
IN                                              OUT				
src=Client:10000,dst=DNSsrv:53               -> src=NATpool:10000,dst=DNSsrv:53(websrv query)
dst=Client:10000,src=DNSsrv:53(Ans:websrvin) <- dst=NATpool:10000,src=DNSsrv:53(Ans:websrvout)
  • nat (in,out) source static wevsrvin wevsrvout dns の場合
    • 暗黙に nat (out,in) destination wevsrvout wevsrvin が行われる.
  • wevsrvoutはOUTのLANに実体があり, NATのsrc書き換え先に指定されているwevsrvoutと衝突が起きるため, no-proxy-arpオプションを必要とする.
    • IN側からwevsrvinがパケットをゲートウエイに発信する必要はないため, このnatルールがDNS書き換え以外の目的で使われることはない.
    • no-proxy-arpがなく, もしOUT側でdst=websrvoutのパケットが着信するとwevsrvinに書き換えられてINから出てくる. ただしsrcはOUT側のまま.
  • nat (out,in) source static wevsrvout wevsrvin dns の場合
    • 暗黙に nat (in,out) destination wevsrvin wevsrvout が行われる.
  • IN側のクライアントがwebsrvinあてのパケットをwebsrvinではなく, ゲートウエイに投げた場合, websrvoutあてに書き換えられてOUTから出てくる.
    • ただし,srcがIN側のクライアントのアドレスのままなので, OUTのサーバが受け付けないか,返答が帰ってこない.
  • 3つのネットワークIN, OUT, BACKがあり, WebサーバがOUTとBACKにIPを持ち, DNSサーバがOUTにあり, INからアクセスする時はWEBサーバのBACKアドレスに行くようにDNSパケットを書き換える場合
    • 共通の挙動
IN                                                OUT				
src=Client:10000,dst=DNSsrv:53                 -> src=NATpool:10000,dst=DNSsrv:53(websrv query)
dst=Client:10000,src=DNSsrv:53(Ans:websrvback) <- dst=NATpool:10000,src=DNSsrv:53(Ans:websrvout)
  • nat (out,in) source static wevsrvout wevsrvback dns の場合
    • 暗黙に nat (in,out) destination static wevsrvback wevsrvout が行われる.
    • IN にいるクライアントは, websrvbackあてのパケットをゲートウエイに投げる. 宛先がwevsrvoutに書き換えられ, outから出てくることになり, websrvbackへは向わないため,目的を果たせない.
  • nat (in,out) source static wevsrvback wevsrvout dns no-proxy-arp の場合.
    • 暗黙に nat (out,in) destination wevsrvout wevsrvback が行われる.
    • outからwevsrvout向けのパケットを受け取らないようにするため no-proxy-arpが必要. アドレス衝突が起きる.
    • INからは別ネットワークのwevsrvbackのsrcアドレスを持つパケットは通常来ないので, これがDNS書き換え以外に使われることはない.

コマンドラインで SDEE イベントをCSV化する

other
  • センサーのSDEEサーバCGIからセッションキーを受け取り,そのキーでイベントを取出すため,2回に分けてアクセスが必要
  • 取得データはXMLであるため, xsltprocでパースして整形する
  • 最大500イベントまでしか取得できない.
  • 開始時刻を date -d '1 days ago' '+%s000000000' 等で定めておく
  • wget --no-check-certificate -q -O - 'https://センサーのIP/cgi-bin/sdee-server?'`wget --no-check-certificate -q -O - --http-user="cisco" --http-password="パスワード" "https://センサーのIP/cgi-bin/sdee-server?action=open&force=yes&events=evIdsAlert&idsAlertSeverities=Informational+low+medium+high&startTime=開始時刻" | xsltproc sdee-session.xsl - ` | xsltproc sdee-tsv.xsl -
  • セッションキーを切り出し, CGIへ渡すパラメータに整形する sdee-session.xsl
    • 名前空間を使用しているので, xmlnsの定義行が必要.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:sd="http://example.org/2003/08/sdee" xmlns:cid="http://www.cisco.com/cids/2006/08/cidee">

  <xsl:output method="text" encoding="UTF-8"/>

  <xsl:template match="/">
    <xsl:apply-templates select="env:Envelope" />
  </xsl:template>

  <xsl:template match="env:Envelope">
    <xsl:text>action=get&amp;sessionId=</xsl:text>
    <xsl:apply-templates select="env:Header" />
    <xsl:text>&amp;subscriptionId=</xsl:text>
    <xsl:apply-templates select="env:Body" />
  </xsl:template>

  <xsl:template match="env:Header">
    <xsl:apply-templates select="sd:oobInfo" />
  </xsl:template>

  <xsl:template match="sd:oobInfo">
    <xsl:value-of select="sd:sessionId" />
  </xsl:template>

  <xsl:template match="env:Body">
    <xsl:value-of select="sd:subscriptionId" />
  </xsl:template>

</xsl:stylesheet>
  • イベント時刻, IPアドレスなどを切り出し, タブ区切りにする sdee-tsv.xsl
  • 元のデータは, サービスアカウントでログインしたとき, /usr/cids/idsRoot/var/eventStore/IdsEventStore に格納されている. このcontextデータはバイナリのまま.
    • xsltproc はビルトインテンプレートを持っており,定義されていないテンプレートに対してあらゆるテキストデータを拾い出してしまう. env:Headerからの出力を抑制するため, 存在しないselectを記述
    • なぜか/のテンプレートでenv:Bodyだけをselectさせても正しい動作にならない.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:sd="http://example.org/2003/08/sdee" xmlns:cid="http://www.cisco.com/cids/2006/08/cidee">

  <xsl:output method="text" encoding="UTF-8"/>

  <xsl:template match="/">
    <xsl:apply-templates select="*" />
  </xsl:template>

  <xsl:template match="env:Header">
    <xsl:apply-templates select="NONE" />
  </xsl:template>

  <xsl:template match="env:Body">
    <xsl:apply-templates select="sd:events" />
  </xsl:template>

  <xsl:template match="sd:events">
    <xsl:apply-templates select="sd:evIdsAlert" />
  </xsl:template>

  <xsl:template match="sd:evIdsAlert">
    <xsl:value-of select="sd:time" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="@eventId" />
    <xsl:text>&#09;</xsl:text>
    <xsl:apply-templates select="sd:participants" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="cid:protocol" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="cid:threatRatingValue" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="cid:riskRatingValue" />
    <xsl:text>&#09;</xsl:text>
    <xsl:apply-templates select="sd:signature" />
    <xsl:text>&#09;</xsl:text>
    <xsl:comment>
    <xsl:apply-templates select="cid:context" />
    </xsl:comment>
    <xsl:text>&#10;</xsl:text>
  </xsl:template>

  <xsl:template match="sd:signature">
    <xsl:value-of select="@id" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="cid:subsigId" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="cid:sigDetails" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="@description" />
  </xsl:template>

  <xsl:template match="sd:participants">
    <xsl:apply-templates select="sd:attacker" />
    <xsl:text>&#09;</xsl:text>
    <xsl:apply-templates select="sd:target" />
  </xsl:template>

  <xsl:template match="sd:attacker">
    <xsl:value-of select="sd:addr" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="sd:port" />
  </xsl:template>

  <xsl:template match="sd:target">
    <xsl:value-of select="sd:addr" />
    <xsl:text>&#09;</xsl:text>
    <xsl:value-of select="sd:port" />
  </xsl:template>

  <xsl:template match="cid:context">
    <xsl:value-of select="cid:fromAttacker" />
  </xsl:template>

</xsl:stylesheet>

ASA NetFlow NSELの集計

other
  • ベータ版だが, 正しい集計値が出ないためnfdump-1.6.14-b2を使用.
  • ASA側の設定
    • flow-export destination コレクタのいるインターフェース コレクタのIP コレクタのポート
    • flow-export template timeout-rate 1
      • NetFlow v9 のテンプレートを送信するタイミング. コレクタに早期にフォーマットを理解させるため,タイムアウトを短くしている.
    • flow-export active refresh-interval 1
      • UPDATEの出力されるタイミング. 1は最小値
    • クラス定義 class-map flow_export は match any を設定. 全ての通信を対象に集計する.
    • policy-map global_policy 内のクラス指定 class flow_export は flow-export event-type all destination でコレクタのIP を指定
    • service-policy global_policy global でポリシーを割り当て.
  • nfcapd を起動する. nfcapd -b 待ち受けIP -4 -l ログディレクトリ -S 2 -T all -t 300 -w 2>&1
    • ログディレクトリ以下で -S 2 を指定することにより, 年月日時のディレクトリが作られ, ログファイルが格納される. -tはローテーション間隔, -wはローテーション間隔への整列.
    • 指定がないとポート番号は9995
  • nfdumpによりログを集計する
    • nfdump -a -N -q -R $dir -o 'fmt:%ts %te %sa %da %pr %sp %dp %ibyt %obyt %td %in %out %nfc %xsa %xda %xsp %xdp' '( asa event 1 ) or ( asa event 5 )'
    • -aが集計, -Nが数値をM,Gなどの単位にせずそのまま出力, -Rがログを収納したディレクトリ, -o fmt:がログの出力フォーマット
    • フィルタasa event 5でASAのNSEL出力のうち,CREATE と UPDATEを対象にする.
    • %bytは%ibytと同じ, %ibyt %obytの集計ではない.
    • byt の値はフィルタの要件として使用できるが, ibyt obytはできない. bytes 0 は ibytが0 と同じ.
    • %出力はスペースでパディングされている.
    • %nfc はコネクション番号, %x?? はNAT変換後のアドレス.NSELに固有の指定.
    • DELETEを対象に入れると, 最終集計であるDELETE出力と中間集計であるUPDATE出力が重複し, 通信量が倍近くカウントされてしまう.
    • CREATE,DELETEのみを対象にしてしまうと, 通信終了時にまとめて集計結果がカウントされるため, 通信量が終了時に偏り正確に出ない.
    • syslogにはDELETEの結果しか報告されない. syslog level 6(infomational)以下の設定でないと報告自体が出ない.
    • ヘッダ情報はバイト数としてカウントされていないため, キャプチャした場合より少ない量になる.
    • NSELにパケット数の項目はない.
    • CREATEのバイト数のカウントはすべて0. 開始時刻の正確性向上のため集計に繰り入れている.
    • 全てのレコードのfirst,lastの時刻は同じ値. 最初と最後のパケットの到達時間ではない. CREATEとDELETEのfirst,lastも全て同じ値.
    • durationはレコード時刻の差を取っているため, 短い時間の通信時間が正確に測定されていない.
      • %msec というNSEL拡張のイベント発生時間の差を取った方が正確か?
    • 送受信0バイトのUPDATEレコードが,実際の通信終了よりもかなり遅れて記録されることがある. DELETEと同時に来るものらしい.
    • 通信終了の理由などは拡張イベントとして%xevtの値で設定されるらしい. 2000以上が終了コードで, 奇数ばかりだが, Ciscoの文書でも記述が省略されている.
    • UPDATEのバイト数に4GB近い異常な値が出ることがある. このときibyt+obytは 4294967295 = 2^32-1になっている. DELETEイベント後にDENYイベント(No SYN)が起きるときの現象?

Windows 10のDHCPフィンガープリント

other

shのwait

other
  • wait の後に$!で取出したプロセスIDを複数指定すると, 終了を待つプロセスを選択できる.
  • ただし, wait発行の時点でバックグラウンドプロセスがまだ終了していないことが必要
    • 終了している場合, 存在しないプロセスを待つ事になるためwaitが終らない
    • 幾つかバックグラウンドプロセスを発行し, 全てを待つわけではない場合, 発行している間に終ってしまうプロセスもあり, これを待たないようにするか, sleep などでwait発行まで終らないように足止めする
    • 単にwaitだけの場合, その時点で終了していないバックグラウンドプロセスのみを待つため, この問題は生じない