サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
jvnrss.ise.chuo-u.ac.jp
今年4月にCVE-2014-0160で公開され問題になったHeartbleedですが、その後も定期的に観測されています。 今年に入ってからの観測サーバーに届くheartbleed関連のパケット量(一日あたり)がこのグラフになります。 4月中旬の小さな山が問題になった時期です。その後は極少量しか観測されなくなってましたが、6月、7月にバースト的な量が観測されるようになり、7/26〜8/8にかけて急増しました。その後はまた少量しか観測されなくなっています。 送出元の国別集計。 CountryCount
いろいろなクラウドサービスで/.ssh配下にあるファイルを探すリクエストを観測しています。 6/4ごろ一度観測されてましたが6月末になり再度観測。 探索対象の例。すべてHEADリクエスト。user-agentなし。 /rsa /known_hosts /key.priv /key /identity /id_rsa.pub /id_rsa.old /id_rsa /id_ecdsa_old /id_ecdsa_2 /id_ecdsa.old /id_ecdsa.2 /id_ecdsa /id_dsa.pub /id_dsa.old /id_dsa /dsa /config /checknfurl123 /authorized_keys2 /authorized_keys /.ssh/rsa /.ssh/priv /.ssh/known_hosts /.ssh/key /.ssh/ident
Wordpressやphpmyadmin等を探すスキャンの中にepgrecを探すスキャンがよくまざってます。 例えばこれ。 2013-06-11 18:37:56,192 INFO x.x.x.x GET /epgrec/LICENSE.txt 2013-06-11 18:37:56,592 INFO x.x.x.x GET /epgrec/enter.php 2013-06-11 18:37:56,846 INFO x.x.x.x GET /epgrec/index.php 2013-06-11 18:37:57,121 INFO x.x.x.x GET /epgrec/editcgi.cgi 2013-06-11 18:37:57,391 INFO x.x.x.x GET /epgrec/head.php 2013-06-11 18:37:57,696 INFO x.x.x.x GET
今年に入ってからもwordpressを利用しているページのアカウントが乗っ取られてDrive-By攻撃のリダイレクタを設置されて攻撃に加担させられる例が多く観測されています。 アカウント情報を盗み出す方法は直接、間接様々な手法があるようですが、やはり単純にサイト自体がブルートフォースを食らうパターンが多いのかなと。ネット上に公開されているサーバーの宿命というか。 実際に複数のwordpressを立ち上げているサーバーで観測したところ、やはりたくさんきます。ここでの観測ポイントでは5月末あたりまではひどく最近は落ち着いていますが、たまたまでしょう。 攻撃をうけていたページは2つ。 通常のログイン画面へのID/passwordのセットでのログイン試行。 その他の手法もあるのでしょうがいまのところこれだけ。 試行されているIDはこの3つ。 admin root webmaster 圧倒的にadm
sshへのブルートフォースについて、あるタイミングでそれまでとは違うID、パスワードの組み合わせでのブルートフォースが観測されます。 最も多いのはrootアカウントのパスワードを狙うものですが、sshの認証失敗時にIDだけではなく入力されたパスワードも記録できるようにした環境を作りそこで観測されたアカウント/パスワードの組み合わせの例はこのような感じになります。 root/password root/1q2w3e root/abc123 root/abcd1234 root/redhat root/qwertyuiop root/qazwsxedc root/qsxesz root/q1w2e3r4 root/q2w3e4r5 root/2wsx3edc root/1qwe23 そのような中で、root以外のアカウントを狙うものも観測されますが、さらにあるタイミングで以下のような日本人の名
年末辺りから流行っているんでしょうか。 ログインすると、赤い警告バーが表示されていて、 不正なアクセスをブロックしたそう。 アカウントアクティビティの詳細をみるとこう。 「アカウントアクティビティ」とは、いつ、どこから、どのように利用されたか監視しブロックしたり、通知してくれたりする機能。 アメリカから。 止めてくれてありがとう。 このIPはzbotの感染端末としてリストに載ってたりしますがどうなのでしょう。 GmailのアカウントはGmailだけではなく、その他のサービスのアカウント情報としても利用されていると思いますので、乗っ取られた時の影響は非常に大きいです。 基本的なことですが、 アカウントアクティビティをONにして監視する。 画面の右下に表示される前回のログイン情報を気にする。 二段階認証プロセスを有効にする。 を実施することで安全度を高める対策をするしかないです。 当然推測され
2009年春に流行したGumblar関連の攻撃。いまだにウェブサイト経由で感染させる類似の攻撃手法が蔓延していいますが、そのGumblar(ガンブラー)という言葉の元ネタとなったサイト「gumblar.cn」、閉鎖されていたはずですが、12/20頃からAレコード登録されているたので調べてるとこうでした。 % whois gumblar.cn Domain Name: gumblar.cn ROID: 20121220s10001s61822890-cn Domain Status: ok Registrant ID: whois_private Registrant: WHOIS PRIVACY PROTECTION SERVICE Registrant Contact Email: whois.private.service@gmail.com Sponsoring Registrar:
7月から9月ごろに流行っていた、スマホの画面をヒカリにかざすだけで充電できたりするオーバーテクノロジーを使ったこれらのアプリがありました。 電池長持ち Power Charge Solar Charge Sun Charger SUN POWER : 昔からあるようなジョークソフトの一つで珍しいものではないんですが、 不正な機能が盛り込まれていて、以下の情報が抜き取られ外部のサーバーに送られというシロモノです。(それも昔からある手口かも) 感染した端末の電話番号 感染した端末のアドレス帳 (表示名、電話番号、メールアドレス) 送られるサーバーは、日本や海外にあるホスティングサーバーでHTTPを使って平文のままpostされる典型的なパターンです。アプリケーション毎にIDが振られていてその情報もあわせて送られているので、何かしらの分類や正当性?でもチェックしているのかもしれません。 当然流出し
8月31日に、Apache 1.3系は脆弱ではないとの発表がありました。 http://people.apache.org/~dirkx/CVE-2011-3192.txt ただし、このアドバイザリによれば、1.3系は脆弱ではないけれども、Rangeヘッダにコンマ区切りで非常に多くの範囲指定が設定された場合には、相当の負荷になると指摘しています。 さて、Apache 2.x 系では、setenvif_module (SetEnvIf) あるいは、rewrite_module (RewriteCond) を使った「Range ヘッダを許容するが、制限を加える」回避策が提示されています。この回避策において、制限を越えたアクセスのログ (制限超過ログ) を取得したい場合について補足したいと思います。 ここでは、制限超過ログとして、logs/range_log ファイルに、IPアドレス(%h)、時
8/24に新ファームがリリースされたようです。 http://web116.jp/ced/support/version/index.html 12.Xを飛び越えて14.Xに上がってます。 たとえばPR-S300SEの場合このような説明になってます。 必ず現在お使いのファームウェアのバージョンを確認し、バージョンアップを実施してください。 Ver.12.15以前をご利用の場合はこちらを最初にダウンロードしてください。 ソフトウェア(ファームウェア) Ver.12.50【ダウンロード】 PRRT-S300SE1250.dlm 約9.78MB ※Ver.12.50の機能はVer.12.15と同等となります。 Ver.12.50以降をご利用の場合はこちらをダウンロードしてください。 ソフトウェア(ファームウェア) Ver.14.07【ダウンロード】 PRRT-S300SE1407.dlm 約10
先週から話題になっているApache Killer。 リモートからRange指定を含むリクエストを大量に送ることで、ターゲットのメモリとCPUを消費させるというものでバージョン1.3系および2系のすべてが対象。「Range header DoS」というのですか。 かなり強力な効果があります。。。。。 しかも、攻撃コードが複数でまわっているせいか、このニュースが流れた後、25日夜〜26日夜にかけて大量の攻撃が観測されました。 たとえば。 T 2011/08/26 15:12:42.000000 x.x.x.x:45302 -> x.x.x.x:10080 [A] HEAD /xxxxxx.jpg HTTP/1.1..Host: xxx.xxx.xxx..Range:by : : T 2011/08/26 17:26:09.000000 x.x.x.x:63163 -> x.x.x.x:808
Google Public DNSがIPv6に対応したそうです。 https://groups.google.com/group/public-dns-announce/browse_thread/thread/c8283ef40db72f78?hl=en&pli=1 これですね。 2001:4860:4860::8888 2001:4860:4860::8844 そしてすでに使えます。 % host -t AAAA ipv6.google.com 2001:4860:4860::8888 Using domain server: Name: 2001:4860:4860::8888 Address: 2001:4860:4860::8888#53 Aliases: ipv6.google.com is an alias for ipv6.l.google.com. ipv6.l.goog
create:2008/6/18 あれ?よくよく見ると、グローバルアドレスがなくてもこのこのパケットとどきますね。まぁそんな使い方することはないでしょうが、l2tpが張れていてインターフェースがIPv6対応していさえすればいいんですね。リンクローカルアドレスさえあれば。まぁマルチキャストの原理的にはそんなもんでしょうね。30秒間隔で3x2発のポーリングも本物のデータパケットも届いちゃうわけですね、地震速報。このサービスの構成にもよるんでしょうが。 update:2008/6/27 by jyake 現状のインターネットは、ボットに感染した端末からの攻撃のようなセキュリティ的なものから、デフォルト設定のままインターネットにsyslogやsnmpを飛ばしまくっているPCやブロードバンドルータまで、ゴミトラフィックがまき散らかされている状況が続いています。最近は時代に合わせて、 VoIP/IP電
その昔IPv6を使った新しいサービスとかネットワークマネージメント手法が語られていた時代があり、そこでさまざまなことを語っていた人たちがたくさんいたような気がします。がしかし、ここ数年は、 IPv6?使えるアドレス数が膨大になるだけです。 IPv4と同じことができます。+も−もなく。 むしろシームレスに移行がすすみ、気がついたらIPv6になっていたという形が望ましい みたいな言葉をよく聞くようになってました。 そして、これらの言葉を受けて既存サービス提供側からは、 IPv4でできることはすべてできないといけない。 既存のネットサービスすべてがIPv4と同等に提供できないといけない。 IPv6化によるデグレはゆるさない。 みたいなことを言われ、さらに通常のサービス機能、オペレーション機能だけではなく スパム、DDoS対策などのセキュリティ対策機能 大量利用ユーザーに対するトラフィックマネージ
ほとんどの通信の基本となる名前解決ですが、IPv4/v6デュアルスタックな環境での動作はなかなか難しいことになります。 デュアルスタック環境での名前解決の挙動に関しては、AなのかAAAAなのかといった単純な話ではなく、次のことに注意する必要があります。 クエリーの順序 クライアントが名前解決する際にAを先に聞きに行くのか、AAAAを先に聞きに行くのか?また、機能実装にもいろいろあって、Aの応答があったら、それをそのまま使うのかAAAAの結果を待つか?など。 トランスポート 名前解決のためのトランスポートはIPv4なのかIPv6なのか? IPv4のリゾルバとIPv6のリゾルバが設定されている場合、どちらのリゾルバが利用されるのか? 簡単ですが、クエリ順序とトランスポートの関係の代表的な例をまとめるとこのようになります。 WindowsXPはIPv6トランスポートでの名前解決をサポートしていな
IPv4アドレスも枯渇に向い、IPv6を利用したサービスの利用機会もこれから増えていくと思われます。 そこで、セキュリティ的な観点からの調査の一つとして、スパムトラップに利用しているメールサーバーをIPv6に対応させてみました。 こういうことを想定して。。。 スパム送信側がIPv6に対応していて、受信側のメールサーバーのアドレスのAAAAの応答があればIPv4経由だったスパムがIPv6経由になって届くはずだろうと。 で、想定どおり、IPv6網経由でスパムが届くようになりました。 送信元はこのあたり。 IPnameASAS name国
いまさらですが。。。 DNSプリフェッチ、、、要はユーザがクリックする前、ユーザーがリターンキーを押す前に、どういうURLにアクセスしそうかChromeが判断して、事前にDNSでの名前解決を行っておくことで、名前解決の時間を短縮してウェブアクセスの体感速度の向上を測るという技術ですね。 よく例に上がるのが、表示されたページのリンクのドメインに対するプリフェッチですが、それ以外にも、Google Chromeだと、アドレスバーに入力する文字列についてもプリフェッチが行われます。 例えば、アドレスバーに www.google.com と入力するとき、 www.google.co で、クエリが飛び、 www.google.com まで打ったときにリターンキーを押す前にクエリが飛びます。 これ、 文字列.TLD という形になった瞬間にクエリを飛ばすもののようで、 hoge.cc hoge.pr で
500件を超えたので、リストが公開されたようですね。 なんとなくいろんな攻撃にさらされそうなので、これを抱えたxSPさん大変だろうなぁと思いつつ、調べてみましたが、、、日本にもありますね。。。 全部で507件ありましたが、利用可能なのがいまこの瞬間は497件。 国別に分類するとこのような感じ。 28.8%がドイツ、24.5%がアメリカ、14.3%がフランスの順。 とりあえずAS別に上位10件。 まぁよくありがちなホスティング系。。。。。 ASASNamehost数
9月の終り頃に話題になっていた最近よく利用されているといわれているexploitpackの一つCRiMEPACKに付属しているdeny listについて調べてみました。 これは何用のリストかというと、構築した攻撃サイトに対して、ハニーポットやクローラーなどを利用して調査、解析を行おうとする捜査機関、アナリスト、セキュリティ関連企業からのアクセスをブロックするために利用されるものです。 リストの中身は/32のIPアドレスの羅列です。一部のGoogle bot関連のみ/24。 このリストを下記のようなスクリプトを使って、iptablesに設定してアクセスをブロックするようです。 意外と地味です。 deny-ip.sh #!/bin/bash for ip in `cat ip-list-XXXXXXXX.txt` ; do iptables -I INPUT -s $ip -j DROP ;
ftpやウェブサイトのアカウント情報を奪われた結果こうなる例の一つ。 事象の詳細はこのあたりです。 インジェクション - お薬系 インジェクション - お薬系 2 インジェクション - お薬系 3 薬や時計の広告メールで、 そのメール文面に埋め込まれている誘導URLが http://xxxxxxx/uuu/xxx数字2桁.html となっているのが特徴。 uuuの部分がユーザーホームっぽいものが多数。 このURLにアカウント情報を盗まれたサイトが利用されているようです。 アクセスするとスパムの文面のとおり薬や時計の広告ページです。 たぶん、こんなモデルだと思われます。 2010年4月ごろまではこのような単純な形で、8080とかgumblar系?で収集したアカウント情報を利用して、そのサイトを改竄して広告ページを仕込む。そして数%の確率で攻撃サイトへ飛ばすiframeを仕込まれており、さらに
今年のはじめにAPNICに割り当てられた1.0.0.0/8 と 27.0.0.0/8ですが、すでに売り切れ状態のようです。とりあえず日本国内に割り当てられた分だけ情報をまとめてみました。アサインは終わっていて、すでにサービスに利用されているものから、まだ経路としては広報されていない?ものまで多々。 いや、ふいに、Xperiaにアサインされているが27.x.x.xであることに気づいてぐっと来たので。近いうちに1.x.x.xがアサインされる日が楽しみです。 1.0.0.0/8を見ていてモバイル系が多いなぁ、アドレスを必要としているところ、ネットワークが拡大しているところはやっぱりそっちかという感覚でいましたが、まぁ普通に他のところも。 一般のアクセスラインにも利用され始めているようですが、bogonフィルタとか、通信不具合とか問題は発生していないでしょうか? 関連: APNICに新規に割り当て
「facebook」の「face」 たとえば、こんなのを見て www.v6.facebook.com has IPv6 address 2620:0:1cfe:face:b00c::3 。。。ふと思ったのですが、 IPv6アドレスって表現力が豊かだなと。見た目の。 IPv4は、 xxx.xxx.xxx.xxx xxx=0〜255 だったわけですが、 IPv6は、 使用可能文字 0〜9、a〜f xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx xxxx=0000〜ffff になるわけですね。 これだけの文字が使えれば、いろんな表現ができそうだなと。 単純に使用可能な文字だけでも表現力は豊かですが、 いわゆる「leetspeak」とか「hexspeak」みたいな表現方法を利用すればより一層表現の幅が広がります。 若干話はそれますが「heaxspeak」というのは見
4月頃から一部のbotが勝手にWikipediaを検索しているのに気づきました。 果たして目的はなんなのだろうと。 ”命令が埋め込まれている” ”センテンスの先頭の文字をつなぎ合わせるとコマンドが現れる” などなど期待というか妄想がふくらんでいたのですが、 そのほとんどが http://en.wikipedia.org/wiki/Special:Random というリクエストで、ランダムページを表示をさせるもので、 それに加えていくつかの単語の検索が行われていました。 で、表示されるページをどう見ても何もなく、 結局は古くから行われてるpingやgoogle等へのアクセスなどによるインターネットへの接続状況確認の一つなのだろうと。 検索例 http://en.wikipedia.org/wiki/Special:Random http://en.wikipedia.org/wiki/Mai
.botnet観察日記 Rapidshareを利用したマルウェアの配布 DDoS観察日記 Apache HTTPD Security ADVISORY (UPDATE 3 - FINAL) Apache Killer (CVE-2011-3192) Apache Killer (CVE-2011-3192) 2 歴史的な記念日と世界的なスポーツ大会に関連するDDoS DNS観察日記 CNNICによる.cnドメイン登録審査の見直し DNS amp deepholeforyou.info DNS amp - impactpoint.ru , editdns.info DNS amp - source address DNS amp - source address 2 DNS amp - source address 3 DNS amp - source address 5 DNS amp -
日本時間の9日1:00頃、中国のISP(AS23724)による経路ハイジャックが発生しました。 リアルタイムにいろいろ見てたんですが、あんまり有益な情報を収集できず、結果だけ。。。。。 ハイジャックされたのが約37000経路ということで、それって全BGP経路の約一割がやられてしまったという、かなりインパクトの大きいものですね。 日本のISPの経路も604経路ほどやられているようですが、騒ぎはそれほど起こってない? 日本の経路が海の向こう(しかも中国に引っ張られた)ということで気づきにくいですかね? aut-num: AS23724 as-name: CHINANET-IDC-BJ-AP descr: IDC, China Telecommunications Corporation country: CN aut-num: AS4134 as-name: CHINA-TELECOM des
それぞれの登録理由はこちら。 spamhous PBL The first thing to know is: THE PBL IS NOT A BLACKLIST. You are not listed for spamming or for anything you have done. The PBL is simply a list of all of the world's dynamic IP space, i.e: IP ranges normally assigned to dialup and broadband ISP customers (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for dynamic IP addresses to be listed on the PBL. In fact all
ただでさえ、新規のアドレスブロックが割り当てられてから各ISPが利用するまでの時間が短くなっていて、世界中のbogonフィルターが開いていないせいでユーザーの通信ができないトラブルが多発している世の中なのに、このアドレス実際にISPに割り当てられ始めたらかなり問題になりそうだなぁと。 それ以外にも、 ネットワーク系のドキュメント類のサンプル構成で使われていて、それを設定しちゃってる人がいそう 装置のデフォルト設定ではいっていそう DNS blackhole的な使われ方していそう(127.x.x.xと同じ) DDNSとかで適当に設定されていそう 勝手に使われていそう といろんな問題が考えられます。 で、一番あやしい1.1.1.0/24と1.2.3.0/24についてはDebogonに割り当てられたようで、とりあえず一般には使われないようです。 inetnum: 1.1.1.0 - 1.1.1.
少し前のことではあるが、観測データによるとダウンロード違法化後、winnyノードは約1〜2割、shareノードは約3割減ったことがわかる。それぞれのP2Pネットワークを網羅的に観測できているかどうか定かではないが、一定の観測を続けているためこの減少率はある程度実態を表しているものと思われる。なお、ノード数はIPアドレス、ポート番号の組で識別しており、他ノード情報やキー情報から収集している。 また、接続できなかったWinnyノードの比率が上がった。このこともダウンロード違法化による影響か、あるいは巷に言われるダミーキーの放流にともなうダミーノードが増加したことに起因するのではないだろうか。Nyzilla利用者が増えると、接続したWinnyのサイト(ノード)は、Nyzillaを他ノード情報として保持するかもと思い、その影響として接続できなかったWinnyノードの比率が上がるかもと思ったが、グラ
次のページ
このページを最初にブックマークしてみませんか?
『jvnrss.ise.chuo-u.ac.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く