Securing a Cluster
KubeCon + CloudNativeCon 2024Join us for three days of incredible opportunities to collaborate, learn and share with the cloud native community. Buy your ticket now! 12 - 15 November | Salt Lake City Securing a ClusterThis document covers topics related to protecting a cluster from accidental or malicious access and provides recommendations on overall security. Before you beginYou need to have a K
シングルサインオンのSAMLライブラリに脆弱性、認証かわされる恐れ
異なるドメイン間での認証連携規格「SAML」を使った複数のシングルサインオン（SSO）サービスに脆弱性が発見され、米セキュリティ機関CERT/CCが2月27日に脆弱性情報を公開した。 CERT/CCによると、この脆弱性を悪用された場合、リモートの攻撃者によってSAMLコンテンツが改ざんされ、SAMLサービスプロバイダーの認証をかわされてしまう恐れがある。 この問題は、SSOツールなどを提供するDuo Securityが発見した。2月27日の時点で、同社の「Duo Network Gateway（DNG）」のほか、OneLoginの「python-saml」「ruby-saml」、Cleverの「saml2-js」など、複数のベンダーのSAML処理ライブラリで脆弱性が確認されている。 CERT/CCの脆弱性情報では、CiscoやGitHub、Google、Microsoftなどが影響を受ける
GPKIよ、おととい来やがれ！(タイトルで煽るスタイル) - yumetodoの旅とプログラミングとかの記録
はじめに 煽っておいてすみません。ぶっちゃけGPKIよくわかってないです。 一応 GPKIとはなにか？ - IT digitalforensic.jp の内容が理解できる程度にはわかっているつもりですが。 前提知識 誰がどんな立場にいるかわからんと全くわからんと思うので CA/Policy Participants - MozillaWiki 問題 アプリケーション認証局２(Sub) | 政府認証基盤(GPKI)のホームページ にもあるように、 https://www.gpki.go.jp/selfcert/finger_print.html にアクセスしようとすると のようにルート証明書が信用できんといわれるんですね。 それで、ルート証明書を信用してくれるように mozilla.dev.security.policy › Japan GPKI Root Renewal Request （
【徳丸浩×LINE志賀遼太】セキュリティにはブラックボックスを解き明かす、パズル的な面白さがある｜CodeIQ MAGAZINE
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
“Meltdown” と “Spectre” に備える ―― Kubernetes Engine クラスタのアップデート状況を Forseti で確認 | Google Cloud 公式ブログ
“Meltdown” と “Spectre” に備える ―― Kubernetes Engine クラスタのアップデート状況を Forseti で確認 Google のセキュリティ チームである Project Zero は今年 1 月、“Meltdown” および “Spectre” と呼ばれる CPU 脆弱性について明らかにしました。そのうえで、既知のすべての脆弱性の影響を受けないよう Google Cloud サービスがアップデート済みであることもお知らせしました。 Google Cloud サービスで仮想マシン（VM）を実行しているお客様は、引き続きセキュリティのベスト プラクティスに従い、あらゆる OS の脆弱性対策と同様に、定期的にすべてのセキュリティ アップデートを適用する必要があります。そこで私たちは、Google Cloud Platform（GCP）のお客様向けに、CP
BSDは死につつある？ 一部のセキュリティ研究者はそう考えている - YAMDAS現更新履歴
Are the BSDs dying? Some security researchers think so | CSO Online 「目玉の数さえ十分あれば、どんなバグも深刻ではない」というのがリーナスの法則として知られる経験則だが、BSD 系 Unix OS は、そのソースコードに目を光らせる開発者の目玉が足りてないらしい。 Ilja van Sprundel によると、BSD には容易に115個のカーネルのバグが見つかり（FreeBSD が30、OpenBSD が25、NetBSD が60）、しかもその多くは簡単に解決できる問題とのこと。彼はそのバグ全部をレポートしたのだが、それから半年経ち、その多くが残ったままだったそうだ。 Linux であれば、セキュリティ問題が長期間残ることは少ないのに、BSD はそれと比べて明らかに劣るというのだ。 BSD 系の中では、OpenBSD がセ
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
SPAでのセッション管理とセキュリティ - Qiita
編集履歴 ※ SessionStorage→LocalStorage（永続化される方はこちらだった） ※ OPTIONメソッド→OPTIONSメソッド ※ JWTについて少し調べたのでLocalStorage欄を追記 概要 Frontend Meetup vol.1 - SPAを語り尽くす会!のLT資料です。 フロントエンドのガチ勢には当たり前の内容になるかもしれません。 SPA探り探りなので、ご指摘あればコメントなどで頂ければと思います。 自己紹介（後で消す） 名前：しばたこ/uryyyyyyy 所属：株式会社オプト 得意分野：Scala/Play2/Spark/React 最近はReact/Redux/TypeScriptで書いてます。 materializeを導入したのですがjQueryなかなか辛い。。。 この資料で話すこと SPAでのセッション管理 CSRF対策 CORS SPAで
CPUの脆弱性 MeltdownとSpectreについてまとめてみた - piyolog
2018年1月3日にCPUに関連する3つの脆弱性情報が公開されました。報告者によるとこれらの脆弱性はMeltdown、Spectreと呼称されています。ここでは関連情報をまとめます。 脆弱性の概要 報告者が脆弱性情報を次の専用サイトで公開した。 Meltdown and Spectre (またはこちら) 3つの脆弱性の概要をまとめると次の通り。 脆弱性の名称 Meltdown Spectre CVE CVE-2017-5754（Rogue data cache load） CVE-2017-5753（Bounds check bypass） CVE-2017-5715（Branch target injection） 影響を受けるCPU Intel Intel、AMD、ARM CVSSv3 基本値 4.7(JPCERT/CC) 5.6(NIST) ←に同じ PoC 報告者非公開 論文中にx
DDoSMon - Global DDoS Attack Monitoring
Open & Free Open for security community, Free to use and cite. Realtime DDoS Detection CDN aware, track new ip updates in realtime Instant Email Notification Elaborate Attack Report Full report with detailed break down Get insights about the attack RESTful API Integration DDoSMon with your security infrastructure. How does DDoSMon work? We have partnership with multiple network service providers,
2017年版CSIRT/情報セキュリティ担当者が読んでおいたほうがいい資料・スライド - Qiita
2017年に公開された資料・スライドで、CSIRT/情報セキュリティ担当者が読んでおいたほうがいいのでは?というものを独断と偏見でまとめてみました。 これが足りないじゃないか！という意見がある方はPRください。🙏🙏🙏 Note: この投稿は個人ブログ上の記事のQiitaへのクロスポストです。 技術関連資料 JPCERT/CC: インシデント調査のための攻撃ツール等の実行痕跡調査に関する報告書 (2017/12/05) JPCERT/CC: ログを活用したActive Directoryに対する攻撃の検知と対策 (2017/07/28) FIRST: FIRST Publications 2017 人材・組織関連資料 NCA: CSIRT人材の定義と確保(Ver.1.5) (2017/03/13) CSIRT に求められる役割と実現に必要な人材のスキル、育成についてまとめた資料 補足文
メールの送信元を完璧になりすます「Mailsploit」は何が危険か | 匿名ブログ
Mozillaの「Thunderbird」や、macOSおよびiOSに標準搭載の「Apple Mail.app」など、多数のメールクライアントにおいて、受信されたメールの送信元を詐称することが可能な脆弱性「Mailsploit」が5日、公開されました。日本語の情報がまだ出回っていないため、自分用のメモも兼ねてまとめました。 — 今回発覚したこの脆弱性の影響を受けるメールクライアントは非常に多く、先述の「Thunderbird」「Apple Mail.app」だけでなく、Microsoftの「メール」アプリ、「Outlook 2016」、Webメールでは「Yahoo!メール（英語版）」など、世界中でリリースされているほぼ全てのメールクライアントが該当しています。 Mailsploitのサイトでは、実際にそのデモを試すことができます。 Mailsploitのデモ 送信先の欄に自分のメールアドレ
Webセキュリティ覚書 : "攻撃" 編 [ 初学者向け ] - Qiita
Webのセキュリティ プログラミングスクールからエンジニアデビューしたものですが、セキュリティの重要さと、攻撃された時の恐ろしさに戦々恐々としました。今でもしてます。 たとえ、エンジニアでなくとも、最低限の対策をしないとリリースするのは危険です。 プログラミングスクールではセキュリティについては、深く学ぶことはあまりないと思います。 自分と同じ駆け出しエンジニアさんや、エンジニアじゃないけど、Webサービスリリースしたい！みたいな方に共有できたらと思います。 セミナーでセキュリティについて学んできたので、復習も兼ねて自分なりの解釈で記事に落とそうと思います。 脆弱性? Webサイトの脆弱性は二種類。 ロジックエラー(設計段階で生まれる脆弱性) セッションの管理不備や特殊文字を処理せずにデータを受け渡してしまうことです。 テクニカルエラー(実装段階で生まれる脆弱性) SQLインジェクション、
![Webセキュリティ覚書 : "攻撃" 編 [ 初学者向け ] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9cd60d834e7670c5c46367f5a563bdc44316be42/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9V2ViJUUzJTgyJUJCJUUzJTgyJUFEJUUzJTgzJUE1JUUzJTgzJUFBJUUzJTgzJTg2JUUzJTgyJUEzJUU4JUE2JTlBJUU2JTlCJUI4JTIwJTNBJTIwJTIyJUU2JTk0JUJCJUU2JTkyJTgzJTIyJTIwJUU3JUI3JUE4JTIwJTVCJTIwJUU1JTg4JTlEJUU1JUFEJUE2JUU4JTgwJTg1JUU1JTkwJTkxJUUzJTgxJTkxJTIwJTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0wNTg3MzFjOTYyYTBjNzFiN2Q0ZjhjYTcwZDcxNWQzOQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBUc3V0b3UmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWJlZWI5ZjFhYzNmYjAyOTRiZjNmMmFlZjdmYTZhNzIy%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gVGltZXJzIGluYw%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dd758944b11d85a5db1cfab2c1f2f59d4)
opensslでRSA暗号と遊ぶ - ろば電子が詰まつてゐる
opensslとRSA暗号についてちょっと調べてみようかな、と思った。 まずRSA暗号とは、 公開鍵暗号方式の実装のひとつである 2つの素数の積(ケタ数が大きい場合の素因数分解の困難さ)を利用している ってことを理屈としては理解しているけど、実際にopensslコマンドで作った鍵ファイルの中身がどうなっているのか? ということまで踏み込んだことが無かった。 というわけで、ちょっとその辺をコマンド叩きながら遊んでみることにする。 はじめに：opensslの操作について opensslコマンドは増築に増築を重ねすぎており、もはやそびえ立つ××のようである。ヤヴァいことになったレベルで機能てんこ盛りのコマンドなので、サブコマンドとして機能名を指定して使うことになる。 openssl command [ command_opts ] [ command_args ]上例の「command」には、R
REST Security - OWASP Cheat Sheet Series
REST Security Cheat Sheet¶ Introduction¶ REST (or REpresentational State Transfer) is an architectural style first described in Roy Fielding's Ph.D. dissertation on Architectural Styles and the Design of Network-based Software Architectures. It evolved as Fielding wrote the HTTP/1.1 and URI specs and has been proven to be well-suited for developing distributed hypermedia applications. While REST i
BASIC認証とDigest認証、hydraによる辞書攻撃 - ろば電子が詰まつてゐる
某所でajitingさせてもらうという貴重なユーザ体験をしたのですが、「THC-Hydraでhttp-getにてクラックするとき、BASIC認証とDigest認証を自動判別してくれるのか?」という質問に答えられずに悔しい思いをしました。ので、ちゃんと検証しました。 結論から言うと、THC-Hydraは自動でBASIC認証/Digest認証を判断してくれるので、http-get指定だけでよく、特別に設定する必要はありません。 BASIC認証のおさらい まずはじめに、BASIC認証のおさらいをしておきます。 BASIC認証では、IDとパスワードをコロンで連結した文字列を、Base64でエンコードしてAuthorization:ヘッダに付けることで認証をおこないます。 GET /basicauth/ HTTP/1.1 Host: 192.168.2.66 User-Agent: Mozilla/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Control communication between Pods and Services using network policies | Google Kubernetes Engine (GKE) | Google Cloud
Kubernetes Security Best Practices
Hacker uses Heartbleed bug to retrieve private security keys , falsifies claims by security experts - The Tech Portal
Return Of Bleichenbacher's Oracle Threat (ROBOT) | Cryptology ePrint Archive: Report 2017/1189