k6というカジュアルな負荷テストのパフォーマンス計測用ツールがあります。 触ってみた感じ、なかなか良かったので触りだけまとめます。 LOAD IMPACTという実績のあるサービスを運営している会社が出したツールです。 https://loadimpact.com/ ドキュメント https://k6.readme.io/ GitHub https://github.com/loadimpact/k6 インストール Macならbrewで入ります。Dockerでも簡単にインストールできるので好きな方でインストールすればいいと思います。 brewで入れてみたら、go, icu4c, nodeに依存しているようで、自分の環境だと5分程度かかりました。 バージョンは、0.13.0です。 $ brew tap loadimpact/k6 $ brew install k6 : ==> Installi
JPCERT/CCでは2017年2月10日に類似ドメイン名(jpcert.org)を第三者に登録されたことを契機にドメイン名紛争を行い、結果的にこのドメイン名を取り戻しました。不幸にして同様の状況に陥った日本企業においても、所定の手続きを踏むことでドメイン名を取り戻すことができる可能性があることから、対応の一助となることを期待してJPCERT/CCでの事例をご紹介します。 対象読者: 自社・自組織の類似ドメイン名を第三者に登録されてお困りの方 経緯 JPCERT/CCは1996年に正式発足し、それから20年の間jpcert.or.jpというドメイン名を使用してきた。 *iこのドメイン名に似た、jpcert.org(以下「偽JPCERTドメイン名」)というドメイン名が何者かによって登録された。 発端 2017年2月10日に何者かが偽JPCERTドメイン名をPublicDomainRegist
当方ITエンジニア。 最近我が社のネットワークにIPv6が入りつつある。 これのせいで最近イライラが止まらない。 以前のIPv4のネットワークならなんとなく見続けるうちにネットワークの概要をつかむことができた。 255までの数字が4つあるだけだからだ。 1.1.1.1とかせいぜい面倒でも232.111.102.22とかだ それがIPv6になったらどうだ AAA1:CAFE:1:1:A11B:BEEF:1100:4750とか CAFE:AAA1:1:1:A11B:ABBB:1100:4750とか もう何と戦っているのかわからなくなる。 これ障害が起こったらとんでもないことになるぞ。 ネットワーク図があってもどこで何が起こってるかわからなくなるやつ増えると思う。 CCENTの難易度がCCNP並みに上がるのは必至だ。 簡単なOSPFの設定でも意味がわからないからな。 もうネットワークは CAFE
IPv6導入が世界中に進んでいますが、日本国内では2017年中にIPv6導入が一気に加速しそうです。 NTTドコモは2017年4月頃からIPv6導入 昨日、NTTドコモ端末でのIPv6利用が2017年4月頃より開始されることがTwitterで発表されました。 2017年4月頃より、 #ドコモ 端末よりインターネットにアクセスする際に #IPv6 アドレスが付与される場合があります。自サーバへの接続でIPアドレス制限されている場合は、今のうちに設定変更を実施しましょう。詳細は→ https://t.co/cblmNM9lZ0 担当pix — NTTドコモ開発者情報 (@docomo_dev_info) 2017年2月7日 そのTweetで紹介されている「詳細」は、次のページです。 NTTドコモ:spモードサーバ情報 その「spモードサーバ情報」のページでは、一番下に以下のように記載されていま
2016年6月から、iOSアプリの審査基準としてIPv4に依存するコードの禁止が追加され、IPv6対応がiOSアプリの義務なったことからも、IPv6に関する知識が必須となったエンジニアも多いのではないかと思います(Appleの発表)。 Appleのサイトでは、IPv4アドレス在庫枯渇の発生とともに、ユーザに対してIPv6のみによるインターネット接続性を提供するNAT64(「なっとろくよん」です。ろくじゅうよんではないです。)とDNS64という技術が、エンタープライズ網や携帯電話網で採用されることが増えているとあります。 Apple Developer: Supporting IPv6 DNS64/NAT64 Networks iOSアプリ開発者は、このNAT64とDNS64環境でもアプリが正しく動作することを求められています。 Appleのサイトでは、NAT64とDNS64はOS X 10
Debianは1月29日、コマンドラインネットワークトラフィック分析ツールの「tcpdump」に見つかった32件の脆弱性を修正するセキュリティアップデートを公開した。 脆弱性を悪用された場合、サービス妨害(DoS)状態を誘発されたり、任意のコードを実行されたりする恐れがあるとされ、Debianではtcpdumpパッケージをアップグレードするよう勧告した。 米セキュリティ機関SANS Internet Storm Centerはこの脆弱性について、「ライブの攻撃トラフィック監視にtcpdumpを使っている場合は特に憂慮される」と指摘。「-Z userid」のオプションを使ってroot権限ではなくユーザー権限で起動することも可能だが、それでもユーザーとして任意のコードを実行することはできると解説している。 脆弱性の詳細は不明だが、tcpdumpの4.9.0よりも前のバージョンは全て影響を受ける
NTT、ネットワーク障害の原因を推定するAI技術を開発。従来のネットワークエンジニアによる分析と切り分けを不要に NTTは、ネットワーク障害時にネットワーク機器などから発生するさまざまな警告などを分析し、障害の原因を分析、推定するAI技術を開発したと発表しました。 NTTによるとこのAI技術は、ネットワーク障害の対応履歴などを基にネットワーク機器などからのアラームと真の障害原因を教えていくことで、障害の原因を推定するルールそのものを自動的に作り出せるというもの。そしてこのAI技術によって、これまでネットワーク障害時に技術者が行っていた障害の切り分けや分析作業をAIが実行できるようになるとのこと。 本技術を用いた障害原因推定がシステム化されると、これまで数時間から数日かかることもあった分析作業を数秒程度に短縮することができ、スキルフリーで迅速なネットワーク障害対応が可能となります。 (プレス
Dockerの導入をAWSやAzureで一括実行してくれる「Docker for AWS」「Docker for Azure」が正式版に。Docker for GCPも開発中 Amazon Web ServicesやMicrosoft AzureでDockerを使うための環境構築を一括で自動的に実行してくれる「Docker for AWS」と「Docker for Azure」がベータ版を終え、正式版になったことが発表されました。 例えばAWSでDockerをクラスタ運用する場合には、CloudFormationのテンプレートやファイアウォールのルール設定、ロードバランサーの設定など多くのツールを用いてさまざまな設定をしなければなりません。 Docker for AWSやDocker for Azureは、こうした設定をそれぞれの環境においてできるだけネイティブな方法により一括して自動的に
こんにちは。アマゾンウェブサービス(AWS)サポートの有賀と申します。好きなサービスはAmazon Virtual Private Cloud(VPC)です。これからAWSサポートの各メンバーがそれぞれ「今一番AWSユーザーに伝えたいこと」を連載の形でお届けしていきます。筆者の担当する本稿では、AWSの「ネットワーク」について見ていきたいと思います。第1回の今回は、AWSのリージョンやアベイラビリティーゾーンといった、ネットワークの「物理設計」について解説します。 本稿でお伝えするのは下記の内容です。全3回に渡って解説していきます。 AWSのネットワークの物理的な側面 ⇒ 第1回 AWSのネットワークの論理的な側面 ⇒ 第2回 AWSのネットワークにおけるベストプラクティス ⇒ 第3回 AWSのネットワークにおいて過去に発生した問題の事例 ⇒ 第3回 必ずしもAWSの使い方といった内容では
IPv6の大きな特徴として、IPアドレスの自動設定機能がIPv6の根本的な仕組みとして組み込まれている点があげられます。 IPv4が誕生した当初はIPアドレスの自動設定のための手法が存在していませんでした。 IPアドレス自動設定のためのDHCP(Dynamic Host Configuration Protocol)を規定したRFC 1531が発行されたのは1993年です。 IPv4におけるIPアドレスの自動設定は、後から作られたDHCPを使うというものでしたが、IPv6では最初からIPアドレス自動設定が議論されています。 ただし、その議論の結果生み出されたものが非常にややこしくなっています。 IPv6には最初からIPアドレス自動機能が備わっているものの、IPv6用のDHCPであるDHCPv6も同時に存在しており、非常にややこしいのです。 この文章を執筆している時点では、IPv6におけるI
(編注:2016/11/17、記事を修正いたしました。) ディープラーニングの分野でテクノロジの進化が続いているということが話題になる場合、十中八九畳み込みニューラルネットワークが関係しています。畳み込みニューラルネットワークはCNN(Convolutional Neural Network)またはConvNetとも呼ばれ、ディープニューラルネットワークの分野の主力となっています。CNNは画像を複数のカテゴリに分類するよう学習しており、その分類能力は人間を上回ることもあります。大言壮語のうたい文句を実現している方法が本当にあるとすれば、それはCNNでしょう。 CNNの非常に大きな長所として、理解しやすいことが挙げられます。少なくとも幾つかの基本的な部分にブレークダウンして学べば、それを実感できるでしょう。というわけで、これから一通り説明します。また、画像処理についてこの記事よりも詳細に説明
パケットのヘッダに記載された情報を読み取らなければ、ルータはパケットを転送できません。 日本の法律では、ISPなどの電気通信事業者がIPヘッダに記載された情報を読み取ることは通信の秘密を侵害すると解釈されています。その一方で、インターネットにおける通信を実現するためにはルータがIPヘッダに記載された情報を読み取ることは必要であり、違法であるとは思えません。 日本におけるインターネットと法律に関する話題に触れたことがない方にとっては、非常に奇妙な話に聞こえるかも知れません。しかし、このように「法益を侵害するが違法ではない」という解釈は、日本においてインターネットがどのように運用されているのかを理解するうえで非常に重要なポイントです。 日本国憲法(第21条)と電気通信事業法(第4条)は、通信の秘密を定めています。憲法における通信の秘密と、法律における通信の秘密の違いは、憲法が政府などの公権力に
Master Canary Forging: 新しいスタックカナリア回避手法の提案 by 小池 悠生 - CODE BLUE 2015 Stack Smashing Protection(SSP)はエクスプロイトに対する古くからある根本的な防御機構の1つであり、現在多くのコンパイラやオペレーティングシステムがこの機能を提供している。 SSPの提供する機能の1つであるスタックカナリアはスタックバッファの直後に配置された番兵の値が変化していないかを調べることでスタックバッファがオーバーフローしているかどうかを確認することができる。 今まで、スタックカナリアの回避方法としては、番兵の値の確認処理が行われる前にエクスプロイト処理を終わらせてしまうか、番兵の値を漏洩させてからオーバーフローさせるものが主流であったが、本講演では、これらの回避方法とは違うアプローチを取った回避手法を紹介する。
どうも先日(2016年9月現在)からさくらインターネット様や技術評論社様でDDoS被害が相次いでいますね。 「DDoS対策しとけ」なんてよく言われていますが、セキュリティにステータス振ってない場合は「DDoSってF5連打じゃないの?」みたいな人も結構いるんじゃないでしょうか。あとはiptablesをとりあえず入れておけば大丈夫なんじゃないの?とか。 Web系の開発者にとってのセキュリティ対策は「フレームワークをちゃんとアップデートする」に尽きるので、フレームワークの脆弱性に依存しないDDoSって意外と知らない事が多いと思います。 知っているようで意外と知らないDDoSの世界、ちょっとまとめてみました。 TL;DR スケールできる設計でDDoSに備えよう nginxは置いとけ、キャッシュは甘く見るな SYN cookiesは入れとこう 最後はカネの力でセキュリティを手に入れろ Akamaiセ
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
カリフォルニア大学らの研究者らが公開したホワイトペーパー「Off-Path TCP Exploits: Global Rate Limit Considered Dangerous (PDF)」が、Linuxカーネルバージョン3.6以降にはネットワークスタックに重大な脆弱性があり、遠隔から攻撃者によってTCP通信の内容を推測される危険性があると指摘していることを複数のメディアが伝えた。Linuxカーネル3.6は2012年に公開されており、影響範囲が広範囲に及ぶ可能性が高く注意が必要。 研究者らが指摘した脆弱性はパス外TCP攻撃(Off-Path TCP Exploits)を許してしまうというもの。1分間ほどの攻撃で90%程度の確率で通信に割り込むパケットを生成することが可能になるとされている。この攻撃は受けていることがわかりにくく、しかも広範囲に影響が及ぶ可能性が高い。Linux以外のオペ
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
TLS 1.3は現在策定中ですが、 前方秘匿性 の問題から RSAのみ を用いた鍵委共有が禁止になる見込みです。(詳細は後述します) HTTPSとは 次に、HTTPSです。 HTTPS - Wikipedia HTTPS(Hypertext Transfer Protocol Secure)は、HTTPによる通信を安全に(セキュアに)行うためのプロトコルおよびURIスキームである。 厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供される セキュアな接続の上でHTTP通信を行うこと をHTTPSと呼んでいる。 とのことです。 HTTPの説明を割愛するとすれば、「SSL/TLSでセキュアにHTTPをやる」というだけの説明で済んでしまいます。 最近では個人情報等の観点から全てのサイトをHTTPSにするような動きが見られますが、元々HTTPSが使われやすかった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く