NURO光はセキュリティ的にやばいって話 (安全に使うための方法) - Qiita
要約 NUROひかりのHGWはデフォルトでIPv6ファイアウオール機能が 無効 または 未搭載 の可能性がある ので、そのまま使うと家庭内LANがインターネットから見えちゃうからちゃんと設定か対策して使おうぜって話。 このドキュメントの対象とする人たち 何も考えずに速度が速いだけでNURO光を使っている、「いんたぁねっとが何かよく分かっていない」人向けです。 ネットワークやセキュリティを理解していて、自分のルータでセキュリティを維持しつつ使える！って人には全く関係ない話なので気にしなくていいです。読まなくていいです。 IPv6 と IPv4 のセキュリティ ここでは IPv6 と IPv4 のアドレスが割り当てられたPCやスマホとかがインターネットからどう見えるのか？について説明します IPv4 の場合 一般的にIPv4アドレスは1契約につき1アドレスが付与され、それをルータ呼ばれる機器を
VyOSでポリシールーティングの設定をしてサブネットごとにゲートウェイ等を設定する | 俺的備忘録 〜なんかいろいろ〜
VLANで小分けにしているネットワークでVyOSを用いたVPNルータを追加しようとした際、各サブネットごとにゲートウェイ等を設定してやりたいということがあったので、ポリシーベースルーティングを設定したのでその備忘。 なお、VyOSのバージョンは1.1.7を利用している。 以下、コンフィグの設定例。 ... interfaces { bonding bond0 { ... vif 100 { bridge-group { bridge br100 } } } bridge br100 { address 192.168.100.1/24 ... } ethernet eth0 { ... ethernet eth1 { ... ethernet eth2 { ... openvpn vtun1 { bridge-group { bridge br100 } ... policy { rout
VyOS で Policy Based Routingして複数の ISP を使い分ける
はじめに こんにちは yosida95 です。 先月4月26日の話なのですが、ブログエントリになっていなかったので、今になって書いてみます。 昨年の9月にひとり暮らしを始め てから今まで、 WG1800HP で PPP してゲートウェイとして使ってきました。 しかし、定期的に具合が悪くなり PPP セッションが切れる事、足元には Xeon と Intel NIC を計4ポート積んだサーバーが眠っていてもったいないと感じていた事から、このサーバーを KVM で仮想化して、ソフトウェアルーターである VyOS をそのゲストとして動かすことで、 WG1800HP をタダの WiFi AP として運用することにしました。 今回組んだネットワークのネットワーク図は以下の通りです。 ここまでは実家に居たころと変わらず、 2年以上前に前に書いた Vyatta の記事ともほとんど変わらないのですが、自宅で
React今昔物語 - ICS MEDIA
機能改善だけでなく、非推奨になった機能も多いですね。 2015年〜 ES2015の正式リリース前 2015年6月まではES2015が正式リリースされていなかったため、Reactのコンポーネントの作成にはReact.createClassが使われていました。 React独自のクラスコンポーネントを生成する機能です。 var Component = React.createClass({ render: function() { return ReactDOM.tagName({options, "Hello"}) } }); React.renderComponent( Component(null), document.getElementById("root") ) 2016年〜 クラスコンポーネントの時代 Reactバージョン15.0.0からはReact.createClassはほとん
オリジン間リソース共有 (CORS) - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アクセス制御 (CORS) HTTP
[新機能] HTTPヘッダーやクエリ文字列などなどでルーティングができちゃう!!AWS ALBで高度なリクエストルーティングが可能になりました! | DevelopersIO
はじめに おはようございます､加藤です｡ALBに新機能が登場し､高度なリクエストルーティングが可能になりました｡ 従来ALBでもリスナールールを使うことによって以下の要素で転送先を制御可能でした｡ ホストヘッダー パスパターン ※ ポート番号はリスナールールによる制御ではなく､ポート番号毎にリスナーを作成して行う制御なので記載していません｡ 今回のアップデートで以下による制御も可能になりました!! HTTPヘッダー Valueにのみ*と?が使用可能 HTTPリクエストメソッド 標準またはカスタムのメソッドを使用可能で*は使用不可 クエリ文字列 *と?が使用可能 送信元IPアドレス IPv4, IPv6アドレスをCIDR形式(XXX.XXX.XXX.XXX/XX)で指定可能 上記項目のリンクから詳細仕様のドキュメントに飛べます｡ 概要 ALBのルーティング機能で､従来のホストヘッダー､パスパ
![[新機能] HTTPヘッダーやクエリ文字列などなどでルーティングができちゃう!!AWS ALBで高度なリクエストルーティングが可能になりました! | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f65c40211fcb979cf973d35ae396b0d7afa2ee06/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_application-load-balancer_1200x630.jpeg)
ALB経由で公開するAPサーバに(リバースプロキシ用の)Webサーバーを利用する意味はあるのか？立ち止まって考えてみた | DevelopersIO
まずは、リフト＆シフトのリフトだ。オンプレ環境の構成を変えずにAWSでリプレイスするぜ。 静的コンテンツの処理はWebサーバーに任せてアプリケーションサーバーの負担を減らす構成だな。 次はシフトだ。だが大きくは変えない。静的コンテンツを外だしするところから始めよう。 あれ？Webサーバー(Nginx)っているんだっけ？？ALBではログも取れるし最近はでできることも多いよね？ [新機能] HTTPヘッダーやクエリ文字列などなどでルーティングができちゃう!!AWS ALBで高度なリクエストルーティングが可能になりました! 待てよ待てよ。将来的にはSPAで実装する方法も検討しているんだった。その場合はいらないでいいよね？ ということを社内チャットで呟きました。いくつか意見が出てきたのでこのブログにまとめます。 先に結論 コンテンツ（html）をAppサーバーで作成する場合、あったほうが良さそう
CookieのSameSite=Laxデフォルト化 アクセスログで影響調査 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
したがってSameSite=Lax化の影響を調べるには、「アンカータグとGETのfrom以外で、異なるRegistrable Domainから生成されたリクエストでCookieを使用していないか」ということを確認する必要があります。 しかしこれを漏れなく確認していくことは、なかなか骨の折れる作業ではないでしょうか。 アクセスログのRefererヘッダを見れば、異なるRegistrable Domainから送られてきたリクエストかどうか、ある程度わかりそうな気もしますが、Refererヘッダは送られないケースが多々あったり、そもそもリクエスト生成元のタグ名を判別できなかったりと完璧ではありません。 Fetch Metadataリクエストヘッダとは Fetch Metadataリクエストヘッダとは、一言で言うと「リクエストが生成されたコンテキストをサーバ側に通知するためのヘッダ」です。 ざっく
![CookieのSameSite=Laxデフォルト化 アクセスログで影響調査 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/429d6761b29121c48e76f6c54419eaebcb802f21/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2020%2F01%2Fsamesite_lax.jpg)
インフラ視点で見た時のリバースプロキシの必要性について - Neinvalli
インフラ視点で見た時のリバースプロキシの必要性について 3年前の記事ですが、ふとしたことがきっかけでこちらの記事が目に入ってきました。 Reverse Proxy がなぜ必要か http://d.hatena.ne.jp/naoya/20140826/1409024573 ウェブのインフラの経験がある私としてはとても共感できました。 その中で自分なりに掘り下げることができる箇所があったので、私の考えを述べたいと思います。 この「重い」アプリケーションサーバーと「軽い」Reverse Proxy を組み合わせてそれぞれ自分が得意なものだけ担当することで、システム全体の系でみたときにリソース効率を全体最適させましょう･･･というのがインフラ視点で Reverse Proxy を導入したい一番の理由である。 上のブログで言われている通り、インフラ視点で見た場合にリバースプロキシを導入し、リソース
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
JWTは使うべきではない 〜 SPAにおける本当にセキュアな認証方式 〜 - Qiita
React/Redux/Spring Boot/AWSでSPAを作っているのですが 認証の方式をどうするか悩みました。 ベストと思われる認証方式をこちらに記載することにしました（随時更新します）。 JWTは使うべきじゃない ログイン済みであるという事実を サーバーサイドのセッションを使わずに保存しておく場合、 ログインした後でJWTなどのトークンをサーバーで生成し、 それをクライアントサイドで何らかの形で保存しておく必要がある。 なぜなら、ReactおよびReduxのstateで管理してしまうと、 ページをリロードされたときにstateがクリアされてしまうから。 具体的な保存先はローカルストレージくらいしか無いのだが JWTをローカルストレージに格納するのは危険。 なぜなら、ローカルストレージはJavaScriptで簡単に読み込めてしまうから。 自ドメイン以外のJavaScriptを読み込
APIファーストでバックエンドとフロントエンドを別々に開発する時にハマるクロスドメインアクセス - Qiita
いま個人で開発を行っているWebサービスがありまして、そこではバックエンドをRubyonRails、フロントエンドをClojure & ClojureScriptで開発し、APIでお互いやりとりするように設計しています。(その設計した理由は色々ありますが、単純に好きな2つの言語を使いたかったのが大きな理由の一つですw) おそらくこれからのアプリケーション開発において、このようにフロントエンドとバックエンドをサーバーも言語も分けて設計・開発することが多くなると思いますので、最近ハマった問題をシェアしておきます。 同一生成元ポリシー(Same Origin Policy) そのハマった問題というのが同一生成元ポリシーによるAjaxの規制です。 同一生成元ポリシーとは、ドメインAに配置されているHTMLファイルから別ドメインBのサーバーのAPIにAjaxで通信することが出来ないという制約です。
Fetch: クロスオリジン(Cross-Origin) リクエスト
もし任意の web サイトから fetch を行った場合、そのリクエストは恐らく失敗するでしょう。 ここで中心となる概念は オリジン – ドメイン/ポート/プロトコルの３つ揃いです。 クロスオリジンリクエスト(これらは別のドメイン(サブドメインも)、プロトコル、あるいはポートに送信されたもの)には、リモート側からの特別なヘッダが必要です。そのポリシーは “CORS” (Cross-Origin Resource Sharing) と呼ばれています。 例えば、http://example.com へのフェッチをしてみましょう。: 予想通り、fetch は失敗します。 なぜ?なぜなら、クロスオリジン制約が悪意のあるハッカーからインターネットを保護するからです。 脱線しますが、簡単に歴史的な背景を振り返りましょう。 長い間、JavaScript はネットワークリクエストを実行するための特別なメソ
同一生成元ポリシー(Same-Origin Policy) - とほほのWWW入門
クロスサイトリクエストフォージェリ(CSRF)などのセキュリティ攻撃を防止するために、ブラウザは「同一生成元ポリシー(Same-Origin Policy)」という仕組みを実装しています。異なるオリジンのリソースへのアクセスに制約をかけるものです。制約はまた、JSONP や CORS(Cross-Origin Resource Sharing) と呼ばれる仕組みを利用することで一部解除することができます。 オリジン(Origin)は、スキーム、ホスト、ポート番号の組み合わせです。下記は同じオリジンとみなされます。 http://site-a.example.com/ http://site-a.example.com:80/ http://site-a.example.com/example.html 下記は異なるオリジンとみなされます。 https://site-a.example.co
包括的にSame-Origin Policy（同一生成元ポリシー）を理解する＜2021年版＞ - Qiita
記事の目的と想定読者 World Wide Webが世の中で比較的広く使われるようになって、すでに20年を超えました。アクセス元の主役もPCからスマートフォンになり、Webはシンプルを追求する設計思想から大きく幅を広げてきました。この記事は、主にサイトコンテンツ開発者が安全で便利なサイトを開発するための基礎知識を身につけるために通して読んでいただくこと、あるいは深く調べるためのネタ元として役立てることを念頭に置いて書いています。冗長に感じられることも多いと思いますが、お許しください。 なぜSame-Origin Policyがあるのか Same-Origin Policyって何？という話はWikipediaにお任せするとして、なぜSame-Origin Policyが必要なのかという話は根本的理解に必要不可欠なので、今さら感はありますが、ちゃんと書いておきます。 そもそもWorld Wid
Pythonの知っておくと良い細かい処理速度の違い8個 - kumilog.net
はじめに 標準入力 input と sys.stdin.readline ソート sort と sorted ソートの key ループ for と while リスト リストの初期化 二次元配列の場合 リストの値参照 リストへの値追加 それぞれの処理速度 まとめ はじめに 最近、PythonでAtCoderなどの競技プログラミングに挑戦しています。これまであまりに気にしなかったけど、ちょっとした書き方で処理速度が変わってくることに気づいたので、これを気に少し調べてみました。 目次にあるように、標準入力、ソート、ループ、リストについて、計8個の処理の速度比較を行いました。処理速度の計測方法は、Mac Book Pro*1を使い、timeitでそれぞれ100回計測*2し、平均と標準偏差を求めています。 結果だけ知りたい方は、まとめへどうぞ。 計測に用いたコードは以下にあります。 github.
Pythonプログラムが遅い！高速化したい！そんな時は... - Qiita
Pythonで実装したときに、処理時間が長すぎて要件を満たせないことがあります。そんなときにはこの記事で示す4種類の対策があります。 なお、高速化のために何かをすると別の何かを失います。トレードオフの代表例としては、表現の自由度、可読性、依存度、メモリ使用量、CPU使用量でしょうか。用法・容量を守って正しくお使いください。 また、高速化をする前にはスクリプトのどこが遅いのか、プロファイリングツールなどを使って確かめる必要があります。遅くない処理を頑張って高速化しても、全体の実行時間にはほとんど影響を与えません。この記事ではその手順については説明しません。 4種類の高速化手法 この記事では、下記の4種類の高速化手法について紹介します。 言語仕様・標準ライブラリの範疇でスクリプトを書き直す ライブラリを使う ライブラリを作る バイトコードを最適化する 1. 言語仕様・標準ライブラリの範疇でスク
Pythonistaなら知っておきたい計算量のはなし - Qiita
最近久しぶりにアルゴリズムイントロダクションを読んでいるのですが、ふと「Python(CPython)のデータ構造に関する各操作の計算量ってどれくらいなのかな？」と気になったので調べてみました。以下のページを参考にしています: Python Time Complexity 以下では $n$ や $k$ といった記号を使います。ここで $n$ はコンテナ内の要素数、$k$ はパラメータ内の要素数かパラメータの値とします。では見ていきましょう。 2021/05/02 コメントでのご指摘を記事に反映しました。ありがとうございます。 リスト まずはリストです。Pythonではリストは内部的にはC言語の配列として表しているようです。そのため、先頭要素の追加や削除を行うとそれ以降の要素をすべて移動する必要があるため大きなコストがかかります。なので先頭に要素を追加したり削除する必要がある場合は、代わりに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NTTとIPAの「シン・テレワークシステム」はラズパイだった。1ユーザーあたり月14円で運用可能
