コミュニケーションが生まれるツイートまとめツール
図1●既設のファイアウォール機器と併設して利用する。ファイアウォールにトラフィックを渡す前に、大量のIPアドレスのブラックリストで不要な通信を除外する 米イクシア(Ixia)の日本法人であるイクシアコミュニケーションズは2015年10月29日、IPアドレスによるアクセス制御という既存のやり方を応用した、サイバー攻撃対策アプライアンス「ThreatARMOR」を発表した。IPアドレスのブラックリストでインターネットとの通信をフィルタリングすれば、監視対象の通信量を減らせる、というアイデアを基にした。 IPアドレスでアクセスを制御する機能に特化したセキュリティゲートウエイ機器である。4個のネットワークポートを備えており、インターネットとファイアウォール機器の間に入ってインバウンドの通信をブロックすると同時に、ファイアウォール機器と社内LANの間に入ってアウトバウンドの通信をブロックする(図1)
SOHO向けのルータを乗っ取り、そのネットワークをスレーブ化することで構築した、DDoS用の大規模なボットネットの存在が明らかになった。 サイバーセキュリティ企業Incapsulaが米国時間5月12日に公開したレポートによると、SOHO向けルータのセキュリティまわりの運用が厳格でないために、大量のルータが乗っ取られ、ボットネットのネットワークを構成するスレーブシステムとして悪用されているという。 「Imperva Incapsula」サービスの提供を受ける数十の顧客は最近、乗っ取られたルータで構成されたDDoS用のボットネットから、アプリケーション層に向けた一連のHTTP Flood攻撃を受けた。こうした攻撃が2014年12月に初めて検出されて以来、Incapsulaはこの攻撃を軽減しようと取り組んできている。しかしこの30日間で、それまで記録されていた数の倍にあたるIPからの攻撃を受け、
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
あまり知らない環境で作業をする際、LAN内で稼働しているマシンの一覧が欲しくなる事もあるだろう。 そんなときに便利なのが、今回紹介する『arp-scan』コマンドだ。 このコマンドを実行することで、同じネットワークに所属して動作しているマシンのIPアドレスとMACアドレスの一覧を取得することができる。 1.インストール まずはインストールから。 インターネットに接続している環境であれば、以下のコマンドを実行するだけだ。 Debian/Ubuntuの場合 apt-get install arp-scan RHEL系の場合 yum install arp-scan ソースからコンパイルする場合は、前提となるpcapなどをインストールした上で、以下のようにコマンドを実行する。 git clone https://github.com/royhills/arp-scan.git cd arp-sc
企業や組織でセキュリティに従事する現場担当の方々は、日々のインシデント対応や、セキュリティレベルの向上を目指す中で、様々な疑問に直面していると思います。どんな対策をどこまでやれば安全なのか?ネットワークに脅威が侵入してしまったときに何をすればよいのか?本連載「すぐに役立つセキュリティ対策」では、トレンドマイクロのエキスパートたちが、お客様からの調査依頼対応やインシデントハンドリングの中から得たセキュリティ専門家としての知見を、すぐに業務に活かせる形で提供してまいります。前回は問題端末の特定には、事前の準備、内部統制による管理が不可欠という話でした。今回は、問題端末に対する不審ファイル特定の調査の中で、ほぼ定番のようになっている「端末をネットワークから外す」対応、いわゆる「抜線」対応について述べます。 連載も進んでおりますので再度前提をまとめておきますが、本稿では一般の企業や組織に多いWin
Published: 2024-07-16 Last Updated: 2024-07-17 00:33:04 UTC by Guy Bruneau (Version: 1) [This is a Guest Diary by Michael Gallant, an ISC intern as part of the SANS.edu BACS program] Image generated by DALL-E [8] Introduction During my internship at the SANS Internet Storm Center, I was tasked with setting up a honeypot, an internet device intentionally vulnerable, to observe and analyze attack ve
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
警視庁は2014年11月19日、不正利用目的のプロキシサーバーを設置したとして、東京都豊島区の「SUNテクノ」と東京都台東区の「大光」を捜索し、不正アクセス禁止法違反などの容疑で中国籍の男ら6人を逮捕した。両社は、インターネット接続事業者で使う第三者のユーザーアカウントを不正に入手し、中国内に住むユーザーにプロキシサーバー経由でそのアカウントを使わせていたとされる。悪用されたユーザーアカウントには、ロジテック製無線LANルーターのユーザーが持つアカウントが含まれていたとする一部の報道もある。 プロキシサーバーとは、ユーザーがWebサイトを閲覧する際、ユーザーのパソコンの代わりにWebサイトのコンテンツを収めたWebサーバーと代理で通信するサーバーを指す。企業ネットワークなどでは、ダウンロードしたデータを共有することで通信を高速化したり、不正な通信を検知・遮断してセキュリティを高めたりするた
オフィス機器は2000年代前半ごろから普及が始まり、ネットワーク対応機種の増加や、インターネットの普及も伴って、不用意にインターネットに接続されるオフィス機器の数が年々増加している。この様な状況の中、2009年にSHODANというインターネットに接続している機器の検索システムが登場した。本章では、登場以来注目され続けているSHODANについて解説する。 5億台分の機器情報を持つ「検索エンジン」 SHODANは、2009年にJohn Matherly氏によって開発された検索エンジンである(写真1)。ウェブサーバーだけでなくオフィス機器や情報家電、信号機や発電所の制御機器なども含めて、インターネット接続されている機器、約5億台分の情報をデータベースに格納している。利用者はその機器の情報をウェブで検索できる。 実際にSHODANを使用すると、認証が弱い機器や古いバージョンのまま運用されている機器
アップル(Apple)から今秋リリース予定の最新モバイルOS「iOS 8」では、端末のMAC(Media Access Control)アドレスを利用してユーザーを識別する従来のやり方が使えなくなるという。ユーザーのプライバシー保護強化につながるいっぽう、一部のマーケティング企業などには従来のやり方を改める必要が生じるなどと複数の媒体が報じている。 この変更は、フレデリック・ジェイコブズ(Frederic Jacobs)氏というプログラマーが発見してTwitter上で報告したもの。同氏によれば、「iOS 8」では、端末がWi-Fiネットワークに接続しようとする際に使われるMACアドレスが、ハードウェアに紐付いた固有のものから、毎回ランダムに生成されるソフトウェアベースのものに変更されるという。 iOS 8 randomises the MAC address while scanning
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
キャッシュポイズニングの開いたパンドラの箱 -2- Opened Pandora's box of Cache Poisoning -2- 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) 移転インジェクション攻撃: RFC2181 5.4.1 "Ranking data" の欠陥 今回、委任インジェクション攻撃に加え、さらに RFC2181 の欠陥を突いた攻撃が可能であることを確認した。 委譲元から得た最低ランクの NS キャッシュを、偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、そのゾーンを自由にできる。 これにより、現状では別途示した 1, 2, 3 の条件に関係なく容易に毒入れすることが可能である。 攻撃者は以下のようにターゲットのゾーンの NS を偽権威に向けることができる。
本日、JPRSが緊急の注意喚起を公表しました。 緊急)キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について(2014年4月15日公開)- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く