【#20 Proxy 】プロキシ解説 セキュリティのお勉強

แชร์
ฝัง
  • เผยแพร่เมื่อ 13 พ.ย. 2020
  • #情報セキュリティマネジメント試験
    #情報処理安全確保支援士
    #セキュリティ
    ご視聴ありがとうございます。まさるです。
    セキュリティについて動画作成始めました。
    一緒にセキュリティの勉強頑張りましょう(^^)
    ☆参考にしたyutaさんの動画
    • 【インフラスキル勉強サイト(仮)】サンプル其...
    ☆TWITTER始めました
    【まさるのつぶやき】
    / masaru_benkyou
    ☆セキュリティ勉強したい人向けの動画
    【セキュリティについて語れるようになりたい】
    • セキュリティについて語れるようになりたい。
    ☆ネットワーク初心者向けの動画
    【まさるの小部屋】
    • まさるの小部屋
    ☆ネットワーク中級向けの動画
    【ネットワークスペシャリスト勉強メモ】
    • ネットワークスペシャリスト勉強メモ
    ☆動画学習の強い味方
    【IT用語 動画辞典】
    toppakou.com/ITWORD

ความคิดเห็น • 46

  • @yu8847
    @yu8847 3 ปีที่แล้ว +10

    神チャンネルに出会ってしまった。。。

  • @user-in3ye3nk8f
    @user-in3ye3nk8f 3 ปีที่แล้ว +3

    長年の謎だったプロキシについて知れて良かったです。ありがとうございました!

    • @masaru-study
      @masaru-study  3 ปีที่แล้ว

      -ayumu RoundCat さん
      プロキシについて理解が深まったようで、良かったです(^^)
      コメントありがとうございます!

  • @tsuyoshi4649
    @tsuyoshi4649 3 ปีที่แล้ว +1

    プロキシサーバーについて詳しく知ることができて嬉しいです。
    あとsquidとかwiresharkとか知れてよかったです。いろいろ勉強になります。

    • @masaru-study
      @masaru-study  3 ปีที่แล้ว +1

      いつもコメントありがとうございますー!
      ふと思ったのですが、
      squid=イカ、shark=サメ
      何故か海の生物の名前を使ってるんですよね。
      この辺も興味深いですよね(笑)

  • @user-nk9uy3qz5p
    @user-nk9uy3qz5p ปีที่แล้ว

    今回はボリューム満点でおなかいっぱいです。ありがとうございました。

    • @masaru-study
      @masaru-study  ปีที่แล้ว

      長尺の動画ご覧下さりありがとうございます!
      お粗末様でございました。

  • @mk-wc1zj
    @mk-wc1zj 2 ปีที่แล้ว

    良くわかりました!

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      コメントありがとうございます!
      動画がお役にたてて良かったです(^^)

  • @kemeko137
    @kemeko137 ปีที่แล้ว

    CISSP勉強中です!めっちゃ観てます。これかも応援しています🎉

    • @masaru-study
      @masaru-study  ปีที่แล้ว

      kemeko137さん
      コメントありがとうございます。
      応援ありがとうございます。
      CISSP勉強中なんですね。
      分厚い参考書を覚えるの大変ですよね。
      良き結果になるように
      私もkemeko137さんを応援しています☺

  • @ryuheiitou6993
    @ryuheiitou6993 3 ปีที่แล้ว +5

    めちゃくちゃ分かりやすかったです!!
    特に実演があると具体的なイメージができて理解が深まりました。
    後輩に教える時こんな風に教えられる先輩になりたい笑

    • @masaru-study
      @masaru-study  3 ปีที่แล้ว

      ryuhei itou さん
      コメントありがとうございます。
      この動画は、私が新人の時にこんな事知っておきたかったなぁ…というものです(^^)
      お役に立てればとても嬉しいです。
      そして、ryuhei itou さんには私以上に教えられるエンジニアに
      なって頂きたいです(^^♪

  • @user-ps2wh7tm6j
    @user-ps2wh7tm6j 3 ปีที่แล้ว +3

    実演もわかりやすいですが
    昔の動画にあった
    まとめがなくなったのはちょっと残念です。
    あの「まとめ」はめっちゃよかった。

    • @masaru-study
      @masaru-study  3 ปีที่แล้ว +3

      ken domeさん
      コメントありがとうございます!
      ken dome さんのご意見を参考にさせて頂き、
      今後動画を作る時には、最後に”まとめ”を作成していきたいと思います。
      実は、動画を分析して
      まとめのタイミングで視聴者の離脱率が多かった事実がありました(^^;
      その結果、”まとめ”は必要とされていないのかな…と考え、まとめを削っている動画がいくつかあります。
      ただ、ken domeさんのように熱心に”まとめ”まで見て下さっている事を理解できました。
      これからの動画作りの参考にさせて頂きます!
      ありがとうございます(^^)

  • @AM-xl3py
    @AM-xl3py ปีที่แล้ว

    わかりやすいご説明ありがとうございます。
    1点質問があります。
    プロキシサーバはルーティングも行うのでしょうか?
    非透過性プロキシの場合、
    宛先IPアドレス(宛先ネットワーク)へパケットを送るまでのルート情報をどのように取得しているのか教えてていただきたいです。
    また、透過性プロキシの場合は、pcとプロキシの間にルータがあるので、そこでルーティングを行ってる認識で合ってますでしょうか?

  • @sinoda1114
    @sinoda1114 3 ปีที่แล้ว +5

    わかりやすいですね!
    改善点としては、最後に"まとめ"があるともっといいと思います
    Proxyの1番目の機能は今どきのNWエンジニアなら
    確実なツッコミどころですね

    • @masaru-study
      @masaru-study  3 ปีที่แล้ว +1

      しのさん
      コメントありがとうございます!
      最後に”まとめ”を作るご助言ありがとうございます。
      他の方からも、まとめが欲しいというご要望を頂いた事があり、
      現在作成しているネスペ直前対策シリーズという動画では
      必ず”まとめ”を作るように心がけています。
      しのさんからのご助言を元に、今後も”まとめ”を
      しっかり作っていこうと思いました。
      ありがとうございます(^^)
      グローバルIP節約の部分
      共感して頂けて嬉しいです♪

  • @dadadadadadadada9448
    @dadadadadadadada9448 2 ปีที่แล้ว

    さすがプロ器思惟

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      さすがプロ器思惟ですよね。

  • @user-ot6cf6hw9f
    @user-ot6cf6hw9f ปีที่แล้ว

    ありがとうございます。少しですが、理解できた気がします。
    1点教えていただきたいのですが、実演で最初にプロキシを経由しない場合にGoogleに接続できなかった理由がよくわかりませんでした。他の方にも同様のご質問されてたように、プロキシを経由しないと、、、ってご回答されてましたが、その経由しないとっていうのはどこの部分で設定していたのでしょうか?プロキシがハブのような形になっていて、プロキシに接続がこないと、インターネットにでてけない設定になっていたということでしょうか?
    でもプロキシを経由しないとインターネットに出てかせないというのは、プロキシとは違うonu直下の別途ルーター?がプロキシからの通信しか通させないみたいな設定が必要なような気がするのですが、、、
    すみません私の疑問ご理解いただけますかね?

  • @user-nk9uy3qz5p
    @user-nk9uy3qz5p ปีที่แล้ว

    思い出しメモ。(自分用に問題作成)
    フォワードプロキシのメリットは?
     1つ目ヒント:IPアドレス関連で今はそれほどメリットではない
     2つ目ヒント:動的サイトではメリットにならない
     3つ目ヒント:ユーザに対して行う行為
     4つ目ヒント:ある機器の代わりができる
    透過型プロキシを使うときの注意点は?(ヒント:証明書)
    過型プロキシの流れは?(HTTPS)(ヒント:あるメソッドから始まる、TLSトンネル作成後もプロキシにはすることがある)

  • @kazukudou
    @kazukudou ปีที่แล้ว +1

    Proxyサーバの仕組みについて大変に勉強になりました。私どもでは透過型での提案事例が多く、次のような場合でも透過型にて構成して問題ないでしょうか?
    透過型プロキシの場合にクライアントが参照しているDNSサーバと、ルータ(Proxyサーバ)が参照しているDNSが異なってもSSLセッションの接続にはIPアドレスは意識していない?ので問題ないでしょうか?
    ・・・最近はCDNやクラウドサービスなど、秒間で回答されるAレコードが異なるサイトが増えてます。その場合にそれぞれ参照しているDNSサーバが異なる場合に解決されるIPアドレスに差が生じるためです。

    • @masaru-study
      @masaru-study  ปีที่แล้ว

      くどしまさん
      コメントありがとうございます。動画がお役にたててうれしいです。
      透過型プロキシでサービスを提案しているのですね。
      クライアントとプロキシサーバで参照するDNSが異なる場合でも
      理論的にはクライアントが名前解決をするので問題ない気がしますが…
      色んなパターンがあると思うのでしっかり検証する必要があると思います。
      また下記のような別案も試せると思います。
      ※おそらく私よりくどしまさんの方が詳しい情報をお持ちだと思うので
      釈迦に説法のような気がして大変恐縮ですが…
      例えば社内にキャッシュDNSを用意して
      クライアントとプロキシのDNS参照先を同じにする
      またはHTTPSの接続先が一定固定されている場合は
      ホスツファイルで事前に情報を定義しておくことで
      DNSサーバの影響なく名前解決できるようになると思います。
      少しでも参考になれば幸いです。
      参考サイト
      milestone-of-se.nesuke.com/sv-advanced/server-software/transparent-proxy/
      nekowara.info/archives/14344586.html

    • @kazukudou
      @kazukudou ปีที่แล้ว

      @@masaru-study 回答をいただきありがとうございます。
      私のほうでも色々と調べてみました。
      透過型Proxyの場合に、クライアントからの通信先を何の疑いもなくPROXYサーバが引き継いでくれる
      場合には参照先のDNSがことなっても問題はなさそうです。
      クライアントからの通信先(FQDNに対するIPアドレス)を、ProxyサーバでもDNSを参照して解決されるIPアドレスの整合性をとるような場合に、最近のクラウドサービスやCDNにて構築されるようなサイトでは複数のIPアドレスを持っており問題となることがあるようです。非透過型より透過型のが色々と難しいようです。

  • @koichiyoshiyasu4921
    @koichiyoshiyasu4921 ปีที่แล้ว

    勉強になります。
    CDNが当たり前になってきたので、プロキシの役割も随分と変わってきましたね、、。

    • @masaru-study
      @masaru-study  ปีที่แล้ว

      Koichi Yoshiyasuさん
      コメントありがとうございます。
      そうですね、CDNがリバースプロキシ的な働きがあるので
      負荷分散の役割が強くなっていますね😊

  • @wonder3pfm
    @wonder3pfm 2 ปีที่แล้ว

    めちゃくちゃわかりやすくて感動です!!すみません、実演で最初にプロキシサーバーを経由しないとインターネットに繋がらないようになっていますが、この辺りが分からず…普通の(?)パソコンは特にプロキシサーバ設定せずとも無線や有線に繋げばインターネットは使えると思いますが、そのような設定を事前にされてるのでしょうか?無知ですみません…

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      wonder3pfm
      さん
      コメントありがとうございます。
      はい、仰る通りです。今回の実演の環境はプロキシサーバを経由させないと通信できない設定にしています。
      一般的な家庭環境の場合はDHCPによって通信の設定がされて、インターネットを使えるようになります。
      企業のような中規模~大規模な環境ではセキュリィティの観点からプロキシサーバを経由させないと
      通信できないようにする環境が良くあります。
      今回は手動でプロキシサーバの設定を行いましたが、普通はグループポリシーによって
      プロキシサーバの設定がPCに反映される事で、通信ができるようになる事が多いです。
      参考になれば嬉しいです(^^)

  • @or7253
    @or7253 2 ปีที่แล้ว +1

    お世話になっております。
    よく情報処理技術者試験で、PCからのhttps通信がプロキシサーバを経由してインターネットに出る、という記述を見ますが、Packet Tracerでプロキシサーバの動きを実現することはできますでしょうか。
    Packet Tracerにて、
    [Server]内の設定を確認しましたが、プロキシとしての設定項目はないように見えました。
    また、[PC]内の設定を確認しましたが、プロキシサーバのホスト名やIPアドレスを設定する項目がないように見えました。
    何かご存じではありませんでしょうか。

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      OR
      さん
      コメントありがとうございます
      私も過去パケットトレーサーで
      プロキシを構築できないか
      情報を探しましたが…
      現時点(2022年5月)では
      パケットトレーサーでは
      プロキシ利用できないようです。
      パケットトレーサーでも
      使るようになれば良いですよね(^^)

  • @ua6141
    @ua6141 2 ปีที่แล้ว

    AWSなどのクラウドサービスからオンプレミスを経由してproxyから出て行く構成なんですが、そのクラウドのサーバからproxyの間に問題があって通信を調べたい場合どうすればいいですか?
    問題として客先に提供してるサーバなのでキャプチャするエージェントを入れたりできず、proxy側のログを見ることくらいしか出来ずに困っております。通信する間にはファイアウォールが入っているのでそのログを見れますが、キャプチャ機能もあるので使用したいですがオンプレミスとクラウドの中心となる部分でCPU負荷を高めるため落ちると大変なことになるのでそれも使用できません。proxyのログだけでは原因まで判別がつかないのですが、どうしたらいいでしょうか。。。毎回調べて欲しいと言われますが、できない制約が多くて本当に困ってます。。。

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      コメントありがとうございます。
      制約が多いと、大変ですよね…。
      文面からどのような問題が発生しているのか
      詳細は分かりませんでしたが
      FW負荷を気にされていたので
      過剰な通信が発生しているもしくは意図しない通信が発生している事が
      問題として推察して、お話をすすめます。
      今回の場合
      FWにポートミラーリングの機能の有無を確認するのはいかがでしょうか。
      e-words.jp/w/%E3%83%9D%E3%83%BC%E3%83%88%E3%83%9F%E3%83%A9%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0.html#:~:text=%E3%83%9D%E3%83%BC%E3%83%88%E3%83%9F%E3%83%A9%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A8%E3%81%AF%E3%80%81%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF,%E3%83%9D%E3%83%BC%E3%83%88%E3%81%8B%E3%82%89%E9%80%81%E5%87%BA%E3%81%99%E3%82%8B%E6%A9%9F%E8%83%BD%E3%80%82
      別ポートから通信を送って、その内容を別機器で解析すれば、
      FW自体で解析する必要がないので
      負荷はそこまで高まらないと思います。
      私は文面から想像している状況なので、本当のU A さんの状況と違っていたら
      申し訳ないですが、何かの参考になれば幸いです(^^)

    • @ua6141
      @ua6141 2 ปีที่แล้ว

      @@masaru-study ポートミラーリングですね!ありがとうございます!
      確認したところクラウド上でもその機能がございましたので、それを使用して一度サーバー側の送信を確認したいと思います!
      色々あり少し曖昧に書いた形で分かりづらくてすみませんでした。

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      @@ua6141 お返事ありがとうございます。
      お役に立ててうれしいです(^^)
      問題解決できる事を願っております☆彡

  • @user-cv5ox2tt6e
    @user-cv5ox2tt6e 2 ปีที่แล้ว

    おすすめのproxyサーバとポート教えて欲しいです

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      どんち ピロ
      さん
      コメントありがとうございます。
      おすすめのプロキシサーバはWebプロキシであれば
      Squidがよく利用されており、情報量も多いことからオススメしたいです。
      ポート番号に関しては…特におすすめが思いつきません💦
      参考になりそうなサイトもあったのでご紹介させていただきます。
      www.designet.co.jp/ossinfo/selection/proxy-loadbalancer.html
      参考になれば幸いです。

    • @user-cv5ox2tt6e
      @user-cv5ox2tt6e 2 ปีที่แล้ว

      @@masaru-study さん
      返信ありがとうございます😊
      ありがとうございます😊

  • @Boke200210
    @Boke200210 2 ปีที่แล้ว

    俗に『串を挿す』なんて言ってましたよね。自身を守るトーチカだって。
    3重くらい重連させたことはあったけど、それ以上は自環境のパソが追いつかなかったな・・・。

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      ”串を挿す”っていう方もいますよね。
      業界用語っぽくてかっこいいのです。
      私にはかっこよすぎて
      串を挿すといった事がありません(^^;)
      3重でプロキシを使うような環境があったんですね…
      想像つかないです。
      結構通信速度遅くなりそうですね…

    • @Boke200210
      @Boke200210 2 ปีที่แล้ว

      @@masaru-study ええ、もうフリーズしたんじゃないかと思うくらいw

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว

      @@Boke200210 それは使いものにならないですね(笑)

  • @mashmash4227
    @mashmash4227 2 ปีที่แล้ว

    WAF テストでるでー

    • @masaru-study
      @masaru-study  2 ปีที่แล้ว +1

      WAFは毎年何かしら取り上げられてるイメージあります☺