第9回ゼロから始めるセキュリティ入門 勉強会

weeyble-security.connpass.com

ゼロから始めるセキュリティ入門 勉強会のセミナーレポートです
その中でもWAFの話しが印象に残ったので、それをレポートします

WAFを入れれば良いってもんじゃないんだぜ？

この発表をして頂いた方は、脆弱性の診断や解析を仕事としているらしく、

ある企業の脆弱性診断を行った際に、次の面白い現象が起きたみたいです

・攻撃方法

SQLインジェクション

・防御方法

WAF

・現象

同様のWebアプリケーション＆DBにSQLインジェクションをhttpとhttpsでそれぞれ実行

そうすると片方では成功し、もう片方では失敗

皆さんは、httpとhttpsのどっちがSQLインジェクションに成功したか分かりますか？（理由も）

正解は・・・

httpsです！！

httpsだと通信内容が暗号化されている為、WAFがSQLインジェクションを検知できずにスルーしてしまったことが原因だろうとのことでした

まあそもそもWebアプリケーションに脆弱性があるのが問題な感は否めないけど

WAFの設定とか仕様にもよる現象だとは思いますが、WAFに通信を通す時はプロキシサーバとか使って、httpsをhttpに落とし込むのがベストプラクティスみたいです

わりと大きな企業でも、WAF入れてりゃあ大丈夫だろうと思っているとこがあるらしいです

そうではなく、WAFはあくまでも最終防衛ラインで考えることが大事とことでした

DDosとかはWAFや下位レイヤーのセキュリティ装置に頼るのも仕方ない感はあるけど

SQLインジェクションとかクロスサイトスクリプティングとかはWebアプリ側の対策が重要だと思います（それするの開発側だけどな！）

開発屋さんマジリスペクト

CloudWatchアラームをLINEに投げてみた

AWS CloudWatchアラームをLINE Notifyを使用して、LINEに通知できる仕組みを構築してみました 

使用ツール

今回活躍してくれるツールはこの二つです

・LINE Notify
・AWS Lambda

手順

①LINE Notifyの設定

1.https://notify-bot.line.me/ja/にアクセス、自分のLINEアカウントを使ってログインしてマイベージへGO!

2.トークンを発行するをクリック

3.トークン名、通知を送信するトークルームを指定し、発行するをクリック

グループにだって通知できちゃいます！

4.表示されたトークンを φ(・ω・ )かきかき

5.自分のLINEにトークン発行しましたとかなんとかっていう通知が届くはず

LINE Notifyを友達登録する必要あるかも

この記事を書いたのが一回検証し終えた後だったので、忘れました(笑)

②SNSの設定

1.SNSコンソールの左ペインにあるTopicsをクリックし、Create new topicをクリック

2.Topic nameに適当な名前を入力し、Create topicをクリック

③CloudWatchの設定

1.CloudWatchコンソールの左ペインにあるアラームをクリックし、アラームの作成をクリック

2.好きなメトリクスを選択し、次へをクリック

ここではテスト用に作成したカスタムメトリクスを選択します

3.アクションの通知の送信先に②で作成したTopicsを指定

名前や判定条件はお好みで

④Lambdaの設定

Lambda関数作成のときって

・Lambdaのコンソールで直接コードを記述

・コードをローカル端末からアップロード

・コードをS3からアップロード

この三つがあるんですが、コードで外部モジュールを使っている場合はそれごとアップロードする必要があるので、↑の下二つの方法どちらかでする必要があります

今回私はPythonでコード書いているんですが、そのコードの中でHTTP POSTをするのにrequestsという外部モジュールを使っていた為、アップロードの方法を取ってます

④の手順は結構色々やり方あると思うので、私が紹介する手順はその中の一つになると思います

1.EC2上のLinuxサーバにログイン

2.作業用ディレクトリの作成

mkdir line_alarm

3.作業ディレクトリに移動

cd line_alarm

4.ライブラリのインストール

tオプションをつけることで、ライブラリのインストール場所を指定

今回はカレントディレクトリ（line_alarm）にインストール

pip install requests -t .

5.Lambda関数の作成

ファイル名は lambda_function.py

関数名は lambda_handler

ファイル名と関数名は後で使用するのでφ(・ω・ )かきかき

別にファイル名と関数名が、これでないといけない理由はないけど、Lambadaの設定する際に、ハンドラっていう項目の初期値と一致するから

この方が楽かも

vi lambda_function.py

#coding:UTF-8

import requests

def lambda_handler(event, context):

    url = "https://notify-api.line.me/api/notify"

    token = "CH9wwDm7N6zt2WooZoorKccgMT06rkdYbLVbduXCJ2D"

    message = "test"

    stickerPackageId = 2

    stickerId = 144

    headers = {"Authorization": "Bearer " + token}

    payload = {"message" : message , "stickerPackageId" : stickerPackageId, "stickerId" :stickerId}

    r = requests.post(url, headers = headers, data = payload)

変数補足

・url

→このままでオネシャス

・token

→①でメモったやつを代入

・message

→LINEで通知したいメッセージを代入

・stickerPackageId&stickerId

→LINEで通知したいスタンプを指定する番号を代入

番号はhttps://devdocs.line.me/files/sticker_list.pdfを参照

ちなみにstickerPackageId = 2 stickerId = 144だと↓のスタンプになる

6.zipで圧縮

zip コマンドを使ってline_alarm内のすべてのファイルを圧縮する

そう麻呂が大好きなzipです

zip -r LINE_Alarm.zip *

 

7.zipファイルをS3にアップロード

AWS CLIを使ってアップロードを行うんですが、CLIの設定は省きます(´・ω・`)

aws s3 cp LINE_Alarm.zip s3://hayato-s3/ --acl public-read --profile=hayato

8.Lambdaコンソールの左ペインの関数をクリックし、Lambda関数の作成をクリック

9.Blank Functionを選択 

10.トリガーをSNS、SNSトピックを②で作ったやつを指定、トリガーの有効化にチェックを入れ、次へをクリック

11.名前を適当に入力、ランタイムをPython 3.6にし、コードエントリタイプでアップロード方法を指定

なんか今回S3からのアップロードが上手く行かなかったので、ローカルからアップロードしました(笑)

12.ハンドラはデフォルトで、ロールをテンプレートから新しいロールを作成、ロール名を適当に入力し、次へをクリック

ちなみに④-5で作成した関数名とファイル名をハンドラと一致させる必要あります

13.関数の作成をクリック

⑤アラートテスト

1.Lambdaコンソールの左ペインの関数をクリックし、④で作成した関数を選択し、アクション→関数のテストをクリック

2.サンプルイベントテンプレートをSNSにし、保存してテストをクリック

コードが正しければ、自分のLINEに通知が届きます

3.③で作ったアラートが警告状態になった時に正常にLINEに通知されるか確認

このアラートで使っているカスタムメトリクスは既に作ってあったスクリプトを何回か叩くと、警告状態になるようにしてあります

アラートの状態が現在はデータ不足の状態

この状態ではLINEに通知は飛びません

スクリプト実行

アラートの状態が警告に変わったと同時にLINEに通知が届きました

検証結果

LINE Notifyは簡単にLINEに通知を送れるサービスですね

今回はCloudWatchのアラートを飛ばしましたが、いくらでも応用できそうですね

ちなみに私は、AWSの利用料金閾値オーバで通知が飛ぶようにしています

通知の内容に芸がないのは許してください

しかも通知内容に誤字あるし(笑)

第42回「ネットワークパケットを読む会（仮）」

pa.hebikuzure.com

 「ネットワークパケットを読む会（仮）」のセミナーレポートです
今回はSMBがピックアップされたんですが、聞くだけでは身にならないので、実際に家でSMBパケットを解析してみました

前回レポート

raptor-falcon.hatenablog.com

今回のテーマ

主催者 hebikuzureさんによる

「SMB パケットを解析する」

常連ととろさんによる

「MacでPS4」

特にSMBはWannaCryで耳にはしていたけど、なんやねんそれ？

って感じだったので、非常に良い勉強になりました！

情報共有の為、SMBについてまとめとくんで、是非見て下さいね(*´ω｀*)

SMBってなんぞや？！

SMB【Server Message Block】

Windowsに搭載されているネットワーク共有プロトコル

具体的には、Windowsの共有ファイルなどにアクセスする時や、市販NASにアクセスする時に使われています

例↓

SMBはMicrosoftが開発したプロトコルですが、オープンなプロトコルである為、MacOSやLinuxでもsmbfsといった名前で、Windowsとファイル共有する時とかに使われています

SMBのバージョン

SMB

初期バージョン

実装OS：WindowsNT 3.X／etc

CIFS

SMBをベースにオープン規格化されたものだが、現在ではSMBの方をMicrosoftがオープンにしているので、なんか可哀想な子

実装OS：Windows 9x／Windows Me／Windows NT 4.x

SMB 1.0

Kerberos認証やActive Directoryに対応

実装OS：Windows 2000／Windows XP／Windows Server 2003／Windows Server 2003 R2

SMB 2.0

このバージョンからプロトコルの中身ががらっと変わったらしい

実装OS：Windows Vista／Windows Server 2008

SMB 2.1

ブランチキャッシュ（WAN経由のファイルサーバとかにアクセスにする時、クライアント側にキャッシュあるなら、わざわざサーバに取りにいかず、高速なファイルアクセスを可能にす機能）に対応

実装OS：Windows 7／Windows Server 2008 R2

SMB 3.0

ここら辺から大きな機能改変は無い

実装OS：Windows 8／Windows Server 2012

SMB 3.1

現在の最新バージョン

実装OS：Windows 10／Windows Server 2016

ちなみにWannaCryでお祭り騒ぎの火付け役になってくれたバージョンは・・・

 SMB 1.0！！

こいつです

実のところWannaCryは、WindowsXPなんていうサポート切れたく●OS何時迄も使ってんじゃねーよ！

っていうゲイツからのメッセージだったりして（笑）

WannaCryの対策として、OSがWindows Vista／Windows Server 2008以上のものはSMB 1.0無効にする方法がありますが

例↓（Windows8.1／2012 R2以上のOS、それ以前はsc.exeコマンド使用）

これやるとWindows XPとかが

ってなります（このネタしってる人は古参ニコ厨確定）

噂ではありますが、次回の大型WindowsUpdateでSMB 1.0はもう使えなくなるとかなんとか

SMBの前提

L4のネットワーク接続

TCP/IPかNetBEUI

名前解決

NetBIOSかDNS

Port

NetBIOS:137(TCP/UDP)、138(UDP)、139(TCP)

Direct Hosting SMB(Windows 2000以降のTCP/IPを使用したSMB):445(TCP/UDP)

SMBパケットキャプチャ

LAN内のPCにある共有ファイルにコマンドプロンプト経由でアクセスしたところをキャプチャ

なんでコマンドプロンプトなのかって？

GUIだとフォルダ更新監視する為にセッション張りっぱなしになるし、視覚情報やファイル一覧とかの情報も取ってくるので、ノイズががががぁぁってなるからだからです

また、キャプチャ取る時に注意して欲しいのがSMBのバージョンです

SMB2を使っている環境なのに、SMBでフィルタかけてもなにも表示されません

キャプチャしたパケット

かなり通信の過程が省略されしまっているので、解説に使うキャプチャはWiresharkWikiにあるサンプルパケットを使います（笑）

通信手順

1.TCP sessionの確立

3WayハンドシェイクでTCP sessionを確立している

2.NetBIOS sessionの確立

Negotiate Requestの段階で、TCP sessionの中にNetBIOS sessionを確立するようなんですが、パケットの中身を見てみたところ

ほとんど情報をやり取りしてませんでした

どうもNetBEUI使用時代の名残であるだけのセッションらしく、TCP/IP環境下では正直いるのか？

ってなりますが、ないと上手くいかないとかなんとか

3.Negotiate Request&Negotiate Response

クライアントとサーバの機能レベルのすり合わせ、サーバからの認証要求的なことをやってるっぽい

Negotiate Responseパケットの中を覗いてみると

DFSをサポートしてますよ～だとか

暗号化はサポートしてませんよ～とか

クライアントに認証おねしゃす！ってかんじの中身が見て取れる

4.SMB sessionの確立

ここから認証情報のやり取りをしてSMB sessionを確立しているっぽい

Session Setup Requestの中を覗いてみると

ドメイン名だけ入れて、User nameがNULLなんで匿名アクセスでもしてるんですかね

Session Setup Responseの中を覗いてみると

STATUS_SUCCESSになっとる

セキュリティェ・・・

正しいかどうか分からないけど、WannaCryはサーバ側に管理者権限でSMB sessionを張って、ウイルス送りつけて実行とかなんとかってどっかで見た気がしたから、SMBの脆弱性って、穴をつけばAdministratorのパスワード無しでSMB session張れる的な感じなのかな？

だとしたら恐ろしすぐる

5.Tree sessionの確立

SMB sessionの中にTree sessionを確立しているっぽい

フォルダパス指定してそのフォルダ自体にsession確立するんっすね

Tree Connect Requestの中を覗いてみると

アクセスしたいフォルダのパス指定してますね

Tree Connect Responseの中を覗いてみると

STATUS_SUCCESSとなっているので、指定したフォルダパスあったんですね

6.Create Request&Create Response

ここから先程sessionを張ったフォルダに対してアクションを行っています

Create Requestの中を覗いてみると

Disposition：Open（if file exists open it, else fail）となっているので、

指定したfileがあればOpenして、なければfailを返せってことですね

場合によってはここをelse createとして、指定したfileがなければcreateとかもあるらしいです

てかこのCreate Request、Filenameが空だぞ？

Create Responseの中を覗いてみると

Create Action：The file existed and was openedとなっているので

指定したfileあったらしいっす

ようわからん(笑)

fileがCreateされた時刻とかもここでクライアントにResponseしてますね

7.GetInfo Request&GetInfo Response

ここで追加のfile情報の要求をしてるっぽい

GetInfo Responseの中を覗いてみると

なんか色々な情報をResponseしてますが、見るのたるいんでスルーで（笑）

検証結果

SMBのセキュリティの要はやはりSMB session確立時の認証だと思います（まあ当然な気もするが）

ここをAdministratorで認証された日には＼(^o^)／ｵﾜﾀ

最後に未だにWindosXP使ってるやつ

LinuxからCloudWatchカスタムメトリクスを取得してくる

検証用途だと、EC2を止め忘れをやっちゃう人って結構居ませんか？
今回は一定時間操作が無かったEC2（linux）を自動停止する仕組みを構築してみました

前回検証

raptor-falcon.hatenablog.com

検証内容

前回検証のLinux版になります。

使用ツール

・CloudWatch

・IAM

・AWS CLI

・EC2

注意点

今回紹介する手順は、AmazoneLinuxを使用することを前提とした手順です

他のディストリビュージョンだとAWS CLIがデフォルトで入っていないので、CLIをインストールする必要があります

手順

①CloudWatchにカスタムメトリクスを送るためのIAMユーザ作成

1.IAMマネジメントコンソールのユーザをクリック

2.ユーザを追加をクリック

3.ユーザ名に適当な名前を入力し、プログラムによるアクセスにチェックを入れ、次のステップ：アクセス権限をクリック

4.既存のポリシーを直接アタッチをクリックし、ポリシーの作成をクリック

5.Policy Generatorを選択（新しいタブで表示されます）

6.次のようにパラメータを指定し、ステートメントの追加

効果：許可

AWSサービス：Amazone CloudWatch

アクション:PutMetricData

7.適当なポリシー名を入力し、ポリシーの作成をクリック

8.元のタブに戻り、更新→フィルターをユーザによる管理する→①.7で作成したポリシーを選択→次のステップ：確認をクリック

9.ユーザ作成内容を確認し、ユーザの作成をクリック

10.アクセスキーID シークレットアクセスキーをメモする

②AWS CLIで使うユーザの認証設定する

1.認証情報の設定

aws configure --profile CloudWatch

AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX 　←ここに①.10でメモしたアクセスキーIDを入力

AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXX　←ここに①.10でメモしたシークレットアクセスキーを入力

Default region name [None]: us-east-1　←リージョンを指定

Default output format [None]:

2.設定の確認

aws configure list --profile CloudWatch

③カスタムメトリクス送信用シェルスプリクトの作成

1.フォルダの作成

mkdir /home/ec2-user/cloudwatch

2.シェルスプリクトの作成

vi /home/ec2-user/cloudwatch/custom_metrics.sh

3.シェルの中身

#!/bin/bash

############ACTIVESESIONS############

#VariableDefine

PROFILE=CloudWatch

METRIC_NAME=ActiveSessions

NAMESPACE=Test

VALUE=$(who | wc -l)

UNIT=Count

INSTANCE_ID=$(curl -s XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)

#CLI

aws cloudwatch put-metric-data --profile ${PROFILE} --metric-name ${METRIC_NAME} --namespace ${NAMESPACE} --value ${VALUE} --unit ${UNIT} --dimensions "InstanceId=${INSTANCE_ID}"

##################################

4.シェルスプリクト動作確認

sh /home/ec2-user/cloudwatch/custom_metrics.sh

CloudWatchマネジメントコンソールで、値が取得できていることを確認

④cronの設定

1.シェルスプリクトに実行権限を付与

sudo chmod 755 /home/ec2-user/cloudwatch/custom_metrics.sh

2.作成したシェルスプリクトを5分毎に実行するように設定

crontab - e

*/5 * * * * /home/ec2-user/cloudwatch/custom_metrics.sh

3.cronが正常に動作していることを確認

sudo tail -f /var/log/cron

正常に動作している場合下記のログが確認できる

CROND[3068]: (ec2-user) CMD (/home/ec2-user/cloudwatch/custom_metrics.sh)

⑤自動停止アラートの作成

1.CloudWatchマネジメントコンソールでアラーム→アラームの作成をクリック

2.カスタムメトリクスで名前空間を選択

3.メトリクスを選択し、次をクリック

4.各パラメータを設定し、アラームの作成をクリック

補足

AWS CLIの勉強も兼ねての検証だったので、CLIを使用する方法でカスタムメトリクス取得の検証を行いましたが、SSMエージェントをインストールしてEC2 Systems Managerで一括設定するほうが、良いかもしれません

WindowsServerからCloudWatchカスタムメトリクスを取得してくる

検証用途だと、EC2の止め忘れを結構やっちゃう人って結構いませんか？
今回は一定時間操作が無かったEC2（Winsows）を自動で停止する仕組みを構築してみました

検証内容

カスタムメトリクスとしてActiveSessionsを取ってきて、それを元に自動でインスタンスを停止する仕組みを構築してみます。

登場するAWSサービス

・CloudWatch

・EC2

・IAM

・Amazon EC2 Systems Manager

サーバ環境

・OS

→WindowsServer2012

・EC2Config

→4.7Ver

作業上の注意

WindowsServerからカスタムメトリクスを取得してくる方法は、私が紹介する方法以外にもいくつかありますが、

WindowsAMIに初期インストールされているEC2ConfigのVerによって、できる方法とできない方法があります。

今回私が検証した方法は、EC2Config 4.XXVerでの方法ですので、EC2Config 3.XXVerのWindowsServerだと、正常に動作するか分かりません

手順

①対象のインスタンスにアタッチするIAMロールを作成する

1.IAMマネジメントコンソールの左ペインのロールをクリックし、新しいロールの作成をクリック

2.AWSサービスロールのAmazon EC2を選択

3.フィルターにCloudWatchFullAccessと入力し、出てきたポリシーを選択し、次のステップをクリック

4.適当なロール名を入力し、ロールの作成をクリック

5.先ほど作成したロールをクリック

6.ポリシーのアタッチをクリック

7.フィルターにAmazonEC2RoleforSSMと入力し、出てきたポリシーを選択し、ポリシーのアタッチをクリック

②対象のインスタンスに①で作成したIAMロールをアタッチ

※ちなみに昔は既に作成済みのインスタンスにIAMロールをアタッチすることができなかったとかなんとか

面倒だね～ (*´・д・)(・д・`*)ﾈｰ

1.EC2マネジメントコンソールの左ペインのインスタンスをクリックし、対象のインスタンスにチェックを入れ、

アクション→インスタンスの設定→Attach/Replace IAM roleをクリック

2.①で作成したIAMロールを選択し、Applyをクリック

3.正常にアタッチできたことを確認し、Closeをクリック

③Systems Manager Run Command を使用してインスタンスを CloudWatch と統合する

1.EC2マネジメントコンソールの左ペインのState Managerをクリックし、関連付けの作成をクリック

2.AWS-ConfigureCloudWatchにチェックを入れる

3.ドキュメントのバージョン、ターゲントインスタンス、スケジュールに適切な値を設定

※ターゲントインスタンス以外は、とりあえずはデェフォルトでも構いません

4.パラメータのステータスをEnableにし、PropertiesにJSON形式でパラメータを指定し、関連付けの作成をクリック

5.関連付けの作成が成功したことを確認し、閉じるをクリック

6.③の5で作成した関連付けのステータスが成功になっていることを確認、ステータスが保留中の場合は、関連付けを今すぐ適用をクリック

④CloudWatchで正常に値の取得ができているか確認

⑤今回作成したカスタムメトリクスを使用し、自動停止アクションを設定

※注意事項

Winodws側の設定で、切断されたセッションを自動終了するように設定しとかないと、セッション保持し続けるので、要設定

また、アラートを作成したCloudWatchがあるリージョンと、対象のEC2があるリージョンが異なると、自動停止アクションが失敗するみたいなので要注意

補足

今回はカスタムメトリクスのパラメータの指定を、Systems Manager Run Commandで行いましたが、

直接対象のEC2にログインし、JSONファイルを編集することでも可能です。

しかし、一台一台設定していくのは手間なのでSystems Manager Run Commandを使用することをオススメします

今回使用したJSONパラメータの補足

・③の4で記載したJSONパラメータが適応された、JSONファイルの場所

C:\Program Files\Amazon\SSM\Plugins\awsCloudWatch\AWS.EC2.Windows.CloudWatch.json

・JSONファイルの中身抜粋（分かり辛いと思うけど、許してね (・ω<) てへぺろ）

・赤枠

IsEnabled を true に設定すると、SSMエージェントを起動または再起動した直後に、エージェントから CloudWatch にデータ送信が開始される。

・青枠

ID名をFlowsで指定することによって、どの値をカスタムメトリクスとして送るかを指定している

・黄枠

Windowsのパフォーマンスモニタで取得したい値に対応するパラメータを確認し、それを指定

今回はアクティブなターミナルセッション数を取得したいので、図のようなパラメータを指定している

当然取得したい値によって、指定するパラメータは変動する

・紫枠

RegionでどこのリージョンのCloudWatchにカスタムメトリクを送るか指定する

なんで東京リージョンじゃないかっていうと、東京リージョンは対応していないからです

Amazonがジャッブを仲間外れにしてます(つд⊂)ｴｰﾝ

ハマリポイント

初めに見つけてきたネット上に転がっている方法が、EC2Config 3.XXVerの方法だったので、いくらやってもうまく行かずにハマリました

検証結果

この方法での自動停止、オススメですよ！

第41回「ネットワークパケットを読む会（仮）」

pa.hebikuzure.com

「ネットワークパケットを読む会（仮）」のセミナーレポートです
参加した中で、ARPスプーフィングというパケットキャプチャ方法が印象に残ったので、実際にWiresharkとNightawkを使って、ARPスプーフィングをしてみました

検証

今回の勉強会で、パケットキャプチャ方法の紹介が何個かあったんですが、その中の一つにARPスプーフィングというパケットキャプチャ方法がありました。

ARPスプーフィングってなに？おいしいの？って方はググｒｙ

具体的な方法などの解説はなかったんですが、技術的にそう難しそうに聞こえなかったので、家で検証してみました！

(画像が見辛いですゴメンネ･ﾟ･(PД`q｡)･ﾟ･)

検証内容

PC-Aの通信内容（http）をPC-Aに気づかれないように、PC-Bでパケットキャプチャする

使用ツール

Wireshark

Nightawk

Virtual Box（2つある物理PCの一つがLinuxなので、ツールのインストールとかが面倒だったのじゃ）

ネットワーク情報

PC-A

IPアドレス：192.168.11.4　デフォルトゲートウェイ：192.168.11.1

PC-B（仮想マシン）

IPアドレス：192.168.11.7

ネットワーク図

検証手順

まずはARPスプーフィング無しでパケットキャプチャを行います

①PC-BでWiresharkを使いパケットキャプチャ開始

②PC-Aでyahooに接続

PC-Aが送信元で宛先が239.255.255.250のパケットをキャプチャしていますが（このパケットが何か気になる人はググｒｙ）、それ以外はなにも表示されません。

※ここでは分かりやすくする為に、PC-AのIPアドレスとhttpリクエストでソートを掛けています。

次にNightawkを使い、ARPスプーフィングを行います

①Target(s) 1に盗聴相手であるPC-AのIPアドレスを選択

②Target 2に偽造先であるルータのIPアドレスを選択

③Start ARP spoofingクリックでARPスプーフィング開始

簡単ですね

再び、パケットキャプチャを行います

①PC-BでWiresharkを使いパケットキャプチャ開始

②PC-Aでyahooに接続、ついでに2chにも接続

PC-Aがyahooと2chに接続していることが分かるパケットがキャブチャできましたね。

検証結果

今回のARPスプーフィングは盗聴相手が同一ネットワークであり、盗聴相手のIPアドレスと偽装先のIPさえ分かっていれば、小学生でも盗聴できてしまう位簡単でした。

簡単だからといって悪用したらだめですよ！

気になる隣のあのｋ（ ‘ ^‘c彡☆))Д´） ﾊﾟｰﾝ 

もちろん企業に使われているようなスイッチとかにはARP防御機能がありますけどね

CiscoであればDynamic ARP Inspectionとかとか

悪い子の皆さん残念だったね！

ですが裏を返せば、家庭用の安物ルータには搭載されていない物が多いでしょうし、家庭でARPスプーフィングの対策している人なんてまずいないでしょう。

私達はプロとして、こういった攻撃方法があることを知り、注意を払っていきたいですね。