サイバーセキュリティ入門　情報収集（２）NmapとWireshark

　お久しぶりです。
　３年生の就活は結構忙しい：自己PR、自己分析、グループディスーカション。。。そして会社の長期インターンもやらないといけないなど、、、ですからQIITAで記事を書くことは忘れてしまいました。
　前回OSINTを紹介すると申し上げたのですが、やはり論述的な文章が苦手で（外人だから日本語についてもう手の施ししょうがない状態　笑）、今日もNMAP復習のため、簡単なNMAPとWIRESHARKの使い方を紹介したいと思います。
 

#Namp
 WIKI、英語文献など、NMAPについての紹介が結構書いています.
NMAPの役割は大体４つ：
 **-Host dicovery
 -Servic、Version detection
 -Operating System detection
 -Network traceroute
 -Nmap Scripting Engine**

侵入の流れもこういう感じです。

**１、Host dicovery：**
　侵入する前に、相手のサーバーは「UP」(生きているか？)の状態かどうかを判断します。基本的に「PING」します。**近年「FIREWALL」結構進化しているらしいから、正直、リアルで何回PINGしても答えが得られない場合が多いです**、一応仕事の流れ見たいに、まず目標システムを「PINｇ」しましょう。ここで使うパラメータは　```-sn```です。
**例：**
ここで、192.168.135.130をスキャンする時、ターミナルに
```nmap　-sn [192.168.135.130]```入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/844c8775-9329-67c2-ab47-e4c39081a27a.png)
こんな結果が出ます。簡単なPINGだから、もらえる情報量は当然少ないです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/3c402443-f440-14b8-1b9d-1ff1ab21b2ab.png)

**2.Servic、Version detection**
 一応「PING」してから目標システムが**生きていること*（Host is up）**を確認しました。だが手に入れた情報量は足りないので、更に掘り出します。
　ここでTCP　SYNスキャンを行います。
　```nmap -sS 192.168.135.130```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/6c2f4d3f-2404-0f84-ce5f-9c2e4903570a.png)
前回より情報量が増えたでしょう。

では、このコマンドは何でSYNスキャンと呼ぶの？一回WIRESHARKの中での様子を確認します。

#WIRESHARK
 WIRESHARKの紹介も結構多いから、ここで割愛します。
WIRESHARKの起動もすごく簡単で、ターミナルに**wireshark**入力するだけです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/4b78f24a-7e0d-a45e-1f0c-19b8b6a552a9.png)
**下の図はWIRESHARKの作動画面です、「eth0」を2回クリックします！**
ethはイーサネットカードの意味で、0は0号イーサネットカードのことを指します。イーサネットカードを監視したら、自分のパソコンのプログラムはどのIPと通信してるか、すぐわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/b84f5918-65f7-10a0-0b6c-4dc9293436a2.png)

2回をクリックします：こんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/39017dc6-2591-a62d-80bc-9a0264a4dea0.png)



もう一度　```nmap -sS 192.168.135.130```入力してみます。すると：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/1a4f7b4d-6cb1-9cad-9312-3be96d021823.png)

**Sourece**の192.168.135.141はSYNパケットの送り側です。
**Destination**は（IPアドレス：192.168.135.130）SYNパケットを受け取る側です。

図のNO７番では（**赤い枠**）、**SOURCE側**は一旦Destination側に**SYNパケット**を送ります。すると、**Destination側**の返信スピードが遅いかなと考えている**SOURCE側**は、続いて別のSYNパケット（8番）を送ります。NO７の返信がまだ届いていないのに、**SOURCE側**続いて9,10,11番のSYNパケットを送ります。

そして、**Destination側**はようやくNO７番のパケットを受け取り、続いて８，９，１０のパケットも届いたということ気づきました！しかしNO７は先に来たから、すぐ**Source側**にNO７番の返信をします。その返信は【NO１２】です。図の中に赤い長方形を付けました。



**８番のお客様の返信は１４になります：**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/ae675196-9a5f-1dc8-d2a6-a0af0c904b09.png)


**「 info」**のメッセージから見ると、NO７の送り側（source 192.168.135.141）はSYNパケットだけ送りました、すると**NO１２番**の**Destination**は【RST,ACK】を返信しました。いわゆる**NMAPの-sSパラメータはsynパケットを送るだけ、そして、もし目標システムは「RST」あるいは「SYN＋ACK」を返信したら、このシステムは「生きている」とNMAPが判断します。**


ではもう一度**NO7「info」**を注目しましょう：（フィルター：tcp.portを使います。）
**５６２８２>1720 [syn]..........**
これはSOURCE側の５６２８２ポートからDestinationの１７２０ポートにSYNパケットを送ります。**相手の１７２０ポートに実行しているサービスをチェックします。**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/6db7be02-508e-5b5f-c79e-dd43c2381097.png)
しかし、Detination側は１７２０ポートで何も実行していないです：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/7e206f2a-0b71-6a91-5473-c610ec92a2e6.png)
そして Destination側は「RST,ACK」を返事しました（**申しわけないです、１７２０は何もないから、今回の握手はRESET（RST）させていただきます。**）

上図から見ると**５１２ポートはexecというサービスを実行しているらしい**。もう一度WIRESHARKで見ると：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/526362/ecb5ac91-912f-97b3-2959-b758b9456410.png)
今回は５１２にサービスが実行しているから、普通に**TCPの３回握手見たいなSYN＋ACKを返事しました**。でも通信したくないからSOURCE側はこの後何も返事なく、Destination側が仕方なくRESETを送りました。



**次回はFINスキャン、TCP-CONNECTスキャンなどを紹介したいと思います。どうぞよろしくお願いします。**