ICMPプロトコル
ICMPは、TCP / IPスタック（伝送制御プロトコル/インターネットプロトコル）のコンポーネントの1つであり、IPプロトコルがデータ配信を保証できないことを補います。 同時に、ICMPはIPデータ送信の信頼性を排除しません。 配信に問題があったことをデータの送信者に通知するだけです。
この図は、TCP / IPモデルでのICMPの場所を示しています。
ICMPは、IPのエラー報告メカニズムです。
データグラムの配信中にエラーが発生した場合、ICMPはこれをデータグラムの送信者に報告します。 たとえば、次の図に示すPC1がPC4データグラムを送信するとします。 ボーダールーターの対応するインターフェイスに障害が発生した場合、このルーターはICMPを使用して、データグラムの配信ができなかったことを示すメッセージをPC1に送信します。 ICMPは、ネットワークで発生する問題を解決しません。
ICMPメッセージはIPを使用して配信されます。
ICMPメッセージは、IPを介して配信される通常のデータと同様に、データグラムにカプセル化されます。 この表は、IPデータグラムのデータフィールドでのICMPパケットのカプセル化を示しています。 フレームヘッダーは、イーサネットなどのLANプロトコル、またはHDLCなどの分散ネットワークプロトコルを使用して形成できます。
フレームヘッダーIPデータグラムヘッダーICMPヘッダーICMPデータ
フレームヘッダーIPデータグラムヘッダーIPデータグラムデータフィールド
フレームヘッダー IPデータグラムデータフィールド
フレームヘッダーフレームデータフィールド
データがネットワーク層に到着すると、データグラムにカプセル化されます。 その後、データグラムとその中にカプセル化されたデータは、データリンク層のフレームに再びカプセル化されます。 ICMPメッセージには、ヘッダーに独自の情報が含まれています。 ただし、この情報とICMPプロトコルデータはデータグラムにカプセル化され、他のすべてのデータと同じ方法で送信されます。 したがって、エラーメッセージも送信中に失われる危険があります。 したがって、エラーメッセージ自体が新しいエラーを作成できる状況が発生する可能性があります。これは、すでに障害を処理しているネットワークの輻輳によって状況を複雑にするだけです。 このため、ICMPメッセージによって生成されたエラーは、独自のICMPメッセージを生成しません。 したがって、データグラムの配信中にエラーが発生しても、データ送信者にエラーが報告されない場合があります。
WinpCapとの突き合わせとpingの送信
誰もがpingコマンドを知っています。このコマンドは、エコー要求を送信し、エコー応答を受信するように設計されています。 システムのpingでは不十分であると判断し、pingプログラムの実装を試みました。
実装ツールはC ++コンパイラと
WinPcapライブラリでした。 WinPcap-ネットワークインターフェイスドライバーと対話するための低レベルライブラリ。
そして、ICMPパケットのアセンブリを開始します。
ICMPパケット形式は、
Wikiから正常に取得されました。
| オクテット | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29日 | 30 | 31 |
|---|
| 0-3 | 種類 | コード | チェックサム |
| ... | データ（形式は「コード」および「タイプ」フィールドの値に依存します） |
u_char packet[1514]; // //MAC- packet[0]=0x08; packet[1]=0x00; packet[2]=0x27; packet[3]=0x4c; packet[4]=0x18; packet[5]=0xDA; ////MAC- packet[6]=0x08; packet[7]=0x00; packet[8]=0x27; packet[9]=0xca; packet[10]=0xb8; packet[11]=0x44; // IP- packet[12]=0x08; packet[13]=0x00; packet[14]=0x45; packet[15]=0x00; // *(WORD *)&packet[16] = htons(1500); packet[18]=0x11; //id packet[19]=0x22; packet[20]=0; // packet[21]=0; packet[22]=0x80; //ttl packet[23]=1; //icmp packet[24]=0; // packet[25]=0; // packet[26]=192; packet[27]=168; packet[28]=1; packet[29]=1; // packet[30]=192; packet[31]=168; packet[32]=1; packet[33]=128; chS=ComputeIPChecksum(&packet[14],20); // printf("%x\n", chS); *(WORD *)&packet[24] = chS; //**************************************************** packet[34]=8; //icmp packet[35]=0; packet[36]=0x29; //csum packet[37]=0x31; packet[38]=0x11; //icmp packet[39]=0x11; packet[40]=0x22; //csum packet[41]=0x22; chS=ComputeIPChecksum(&packet[34],8); printf("%x\n", chS); for(i=42; i<1514; i++) { packet[i]= 'A'; } // if (pcap_sendpacket(fp, // Adapter packet, // buffer with the packet 1514 // size ) != 0) { fprintf(stderr,"\nError sending the packet: %s\n", pcap_geterr(fp)); return 3; }
次の図に結果を示します。
要求と応答が表示されます。 すべてがOKです。
しかし、送信者の左のMACアドレスを入力するとどうなりますか？
しかし、送信者の左のIPアドレスを入力するとどうなりますか？
しかし、MAC = FF-FF-FF-FF-FF-FFの場合はどうでしょうか？Wikiにアクセスして、以下を確認できます。
ネットワークの輻輳（いわゆる「ブロードキャストストーム」）を引き起こさないように、ブロードキャストまたはマルチキャストアドレスを持つIPパケットに応答してICMPパケットが生成されることはありません。このルールを破ろうとしてみましょう。 IP 192.168.1.2のマシンから、192.168.1.3にpingを送信します。送信者のIPは192.168.1.1に等しく、送信者のMACはFF-FF-FF-FF-FF-FFです。
192.168.1.3が192.168.1.1を応答することを強制したことが判明しましたが、後者はこれを望んでいませんでした。 最も興味深いのは、pingがブロードキャストされ、合格したことです！
他のマシンでそれを見ます。
他のマシンでは、ブロードキャスト要求をキャッチします。
もしそうなら、それは、while（1）プログラムを書いてDOS攻撃を楽しむ機会です。
参照：Odom W.-CISCO公式認定試験準備ガイドCCENTCCNA ICND1-2010
ru.wikipedia.org