Paper Summary Encore: Lightweight Measurement of Web Censorship with Cross- Origin Requests
![インフラエンジニアのための次世代プロトコル入門 -
July TechFesta 2014](https://cdn-ak-scissors.b.st-hatena.com/image/square/48b1ae6e7e12ee8678437680a92be59fe307fc79/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F45f81630dbd90131d9c62a008baf6e6b%2Fslide_0.jpg%3F3227240)
よって、このヘッダがgzip圧縮データに付いていれば、適当なWebサーバにgzip圧縮リクエストを出し、gzip圧縮レスポンスを待って、バイト数が0x1f 0x8bで始まっているかどうかということと、正確な圧縮日を確認できるのです。 一般的なWebサーバでは、これは非常に限定的なシナリオにおいてのみ有用です。なぜなら、サーバの地理的な位置はいずれにしても隠されず、これもまた隠されていないサーバIPアドレスが分かればすぐに特定されるからです。しかし、 秘匿サービス では、サーバの時間帯に関する情報は、サーバが稼働している可能性のある国を特定するのに非常に役立ちます。 gzipの仕様を見れば、ファイル更新時間のヘッダフィールドには、ローカル時刻ではなく、世界時を使用すべきことは明確です。しかし、多くのサイトが世界時の代わりにローカル時刻を送信しています。どうもMicrosoft Windows
この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 (訳注:日本語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 )を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました( またPythonでTCPスタックを書いたらどうなるかについても書きました )。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ
ここでは、表題にもあるとおり、nmapという、セキュリティ確保に非常に役立つツールについて説明します。 ただし、この文章、長いですよぉ(笑)。 このツールは、ネットワーク上のサーバーが、「どの様なサービスを提供している(可能性があるか)をリモート(ネットワーク越し)に調査するためのものです。 なぜ、提供しているサービスを調査することが、セキュリティ確保につながるのでしょう? どんなサービスが動いていたっていいじゃん、とか、俺はどんなサービスを使っているか知っているから、なんていう声が聞こえてきそうです。 しかし、多くの場合、使っているつもりのないソフトが動いていたりなんかして、サービスが知らぬ間に動いていたりします。 知らぬ間に動くんだから、ろくな設定がされておらず、余計にセキュリティ上危ない、ということになりますねぇ。 また、トロイの木馬のように、勝手にサービスとして動いてしまう悪意のツ
てくろぐおすすめ「裏・注目セッション」 ご覧の通り、バラエティに富んだ内容です。共通点と言えば「インターネット関係」と言うことぐらいでしょうか。IIJって実は案外いろいろなことに取り組んでいるのです。 どのセッションにも気になるポイントはあるのですが、その中でも特に「これは!」と思うもの三つを特集ページで紹介いたしました。 注目1: Apache Mesosで挑む新しいクラウドアーキテクチャ 注目2: Webサイトを守れ!脆弱性対策から顧客対応まで防御スキルを磨くコンテスト 注目3: IIJはDockerをこう使う。クラウドサービスIIJ GIOに投入されたDockerの実態 余談ですが、こちらの紹介文も私(堂前)が書いています。ここに掲載したのはある意味「表の注目セッション」。多くの方に興味を持っていただけるであろうセッションを重点的に紹介させていただきました。ただ、ここに掲載しきれなか
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
クローラのように、ユーザからの入力に応じて任意のURLにHTTPリクエストを発行するソフトウェアは、誤ってプライベートネットワークへのリクエストを処理しないようにする必要があります。悪意のあるユーザが故意にプライベートなネットワークに対してリクエストして、内部情報にアクセスするといった攻撃を行う可能性があるからです。 PerlではLWPx::ParanoidAgentやLWPx::ParanoidHandlerといったモジュールが便利です。これらのモジュールは、リクエスト先のURLをチェックしてプライベートネットワークへのリクエストを禁止してくれます。単にIPアドレスをチェックするだけでなく、ホスト名をDNSで解決して得られたIPアドレスをチェックしたり、リダイレクト先のURLをチェックしたりしてくれます。まさに偏執的です。 このLWPx::ParanoidAgentと同様の機能をもったG
Since vnStat doesn't have/need a fancy GUI, all 'screenshots' are console captures. Examples of the image output can be found from the cgi demo page. $ vnstat --help vnStat 2.12 by Teemu Toivola -5, --fiveminutes [limit] show 5 minutes -h, --hours [limit] show hours -hg, --hoursgraph show hours graph -d, --days [limit] show days -m, --months [limit] show months -y, --years [limit] show years -t, -
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
よく訓練されたApple信者、都元です。 以前、【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみるという記事を書きましたが、そこから半年経ち、状況も変わって来ましたのでアップデートを行いたいと思います。 以前のエントリーを読んだ方は、忙しい場合は下記の「2013年10月版からのアップデート」だけを読むといいかもしません。 VPCを利用する理由 AWSは、あらゆる規模のプロジェクトに対応するインフラを提供しています。前述のサーバ数千台規模のプロジェクトしかり、1台構成しかり。大規模プロジェクトであれば当然、オンプレミスと同様にネットワークインフラについての設計を綿密に行う必要がありますが、では、中小規模のプロジェクトにおいてはネットワークの設計をする必要はないのでしょうか。 AWSでは、VPCという「ネットワーク環境」を構築するサービスを提供しています。しかもVPCの利用
簡単なチャットプログラムは、ネットワークプログラミング用のフレームワークでは定番のサンプルプログラムです。 echo サーバーが Hello World とするなら、チャットは FizzBuzz といったところでしょう。 とりあえず動くだけのチャットならだれでもすぐに作れるようになりますが、まじめにチャットを作ることで、 ネットワークプログラミングで考えないといけない点やエラー処理の重要な基礎を学ぶことができます。 ということで、 Go でシンプルなチャットを実装してみました。 (ソースコード) 以降、何を考えてどういう設計を採用したのかを解説していきます。 考慮すべきポイント 特定のクライアントへの送信に長時間待たされた場合に、他のクライアントへの送信が遅れないようにする。 クライアントを切断するのは、 (1)ルーム側から kick する場合, (2)受信エラー, (3)送信エラー の3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く