วิธีการตรวจสอบว่าไฟร์วอลล์เปิดสำหรับพอร์ต แต่ไม่ฟังพอร์ต

เราจะปรับใช้แอปพลิเคชันใหม่ไปยังเซิร์ฟเวอร์และแอปพลิเคชันจะรับฟังพอร์ต 8443 เราได้ขอให้ทีมเครือข่ายเปิดไฟร์วอลล์สำหรับพอร์ต 8443 บนเซิร์ฟเวอร์นั้นก่อนที่จะปรับใช้แอปพลิเคชัน ไม่มีแอปพลิเคชันที่กำลังฟังพอร์ตเฉพาะบนเซิร์ฟเวอร์ในขณะนี้

มีอยู่แล้วฉันสามารถตรวจสอบให้แน่ใจว่ามีการเปิดไฟร์วอลล์สำหรับพอร์ต 8443

ระบบปฏิบัติการ: Linux / Windows

หากคุณต้องการดูว่าคุณสามารถสร้างการเชื่อมต่อ TCP จากเครื่องระยะไกลได้หรือไม่รับ OpenCSW ที่ติดตั้งบนเครื่องนั้นและเครื่องเป้าหมายและติดตั้ง netcat ทั้งคู่ นี่เป็นไวยากรณ์สำหรับการใช้ netcat เพื่อทดสอบการเชื่อมต่อ TCP:

nc -vz targetServer portNum

ตัวอย่างเช่นเพื่อตรวจสอบ SSH ใน "homeServer1":

nc -vz homeserver1 22

ที่ช่วยให้คุณทดสอบการเชื่อมต่อระดับ TCP จากระบบระยะไกล Netcat ยังสามารถกำหนดค่าให้ฟังบนพอร์ตแทนที่จะทำหน้าที่เป็นไคลเอนต์ วิธีรับฟัง TCP / 8443:

บนเซิร์ฟเวอร์ที่จะติดตั้งแอปพลิเคชัน: nc -l homeserver1 8443

บนเครื่องที่อยู่นอกไฟร์วอลล์: nc -vz homeserver.fqdn 8443

นี่คือตัวอย่างของการดำเนินการที่ประสบความสำเร็จ:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!

การดำเนินการล้มเหลว:

[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused

ไฟร์วอลล์ควรตอบกลับด้วยข้อความ ICMPเมื่อบล็อคการร้องขอ อย่างไรก็ตามนี่ไม่ใช่กรณี (คุณจะสนใจในบทความที่ดีนี้ )

คุณสามารถทดสอบจากภายนอกเพื่อดูว่าพอร์ตนั้นสามารถเข้าถึงได้ผ่านไฟร์วอลล์หรือไม่และหากเป็นเช่นนั้นจะมีสิ่งใดรับฟังหรือไม่ ต่อไปนี้เป็นสถานการณ์ที่แตกต่างกันสามสถานการณ์ที่เกี่ยวข้องกับคำขอ tcp ซึ่งคุณสามารถสังเกตwiresharkหรือแพ็คเก็ตดมกลิ่นอื่น ๆ และสิ่งที่คุณจะเห็น:

1) ไฟร์วอลล์ปฏิเสธคำขอ

คุณได้รับข้อความ ICMP กลับมาและเครื่องมือที่ส่งคำขอควรแจ้งบางอย่างให้คุณทราบถึงผลกระทบนี้ทันที ("ไม่สามารถเข้าถึงผู้ดูแลระบบต้องห้าม" เป็นต้น) โดย "เครื่องมือ" ฉันหมายถึงลูกค้าที่คุณใช้ในการส่งคำขอ (ฉันใช้telnet) รายละเอียดของข้อความ¹ขึ้นอยู่กับการกำหนดค่าไฟร์วอลล์ แต่ "พอร์ตที่เข้าไม่ถึง" อาจเป็นสิ่งที่พบได้บ่อยที่สุด

"ไม่มีเส้นทางสู่โฮสต์" อาจบ่งบอกถึงสิ่งนี้ แต่ก็อาจบ่งบอกถึงปัญหาการกำหนดเส้นทางที่ละเอียดยิ่งขึ้น

2) ไฟร์วอลล์หล่นแพ็กเก็ต

ไม่มีการตอบกลับดังนั้นเครื่องมือจะรอจนกว่าจะหมดเวลาหรือคุณเบื่อ

3) ไฟร์วอลล์อนุญาตให้ใช้แพ็กเก็ต (หรือไม่มีไฟร์วอลล์) แต่ไม่มีสิ่งใดฟังบนพอร์ต

คุณได้รับข้อความ TCP RST / ACK กลับมา ฉันคิดว่าโปรโตคอล TCP ต้องการสิ่งนี้ กล่าวอีกนัยหนึ่งถ้าไม่มีอะไรฟังพอร์ต, OS ตัวเองส่งคำตอบนี้ มันอาจเป็นเรื่องยากที่จะแยกความแตกต่างนี้จาก # 1 เพียงแค่ขึ้นอยู่กับสิ่งที่เครื่องมือรายงานเพราะมันอาจพูดในสิ่งเดียวกันทั้งสองกรณี (อย่างไรก็ตามส่วนใหญ่อาจแยกความแตกต่างนี้เป็น "การเชื่อมต่อปฏิเสธ" กับ # 1 ) พบในแพ็คเก็ตดมกลิ่นบนเครื่องไคลเอนต์สถานการณ์ # 1 (ข้อความปฏิเสธ ICMP) และ # 3 (ข้อความ TCP RST / ACK) จะแตกต่างกันอย่างชัดเจน

ตัวเลือกอื่นเท่านั้นที่นี่คือแพ็คเก็ตที่ได้รับอนุญาตผ่านไฟร์วอลล์และสิ่งที่ฟังดังนั้นคุณจะได้รับการเชื่อมต่อที่ประสบความสำเร็จ

กล่าวอีกนัยหนึ่ง: การสันนิษฐานว่าเครือข่ายของคุณโดยทั่วไปทำงานได้อย่างถูกต้องหากคุณได้รับ # 1 หรือ # 2 หมายความว่าไฟร์วอลล์กำลังป้องกันการเข้าถึงพอร์ตอย่างแข็งขัน # 3 จะเกิดขึ้นหากเซิร์ฟเวอร์ของคุณไม่ทำงาน แต่พอร์ตนั้นสามารถเข้าถึงได้และแน่นอน (โดยนัย) # 4 เป็นการเชื่อมต่อที่สำเร็จ

1. เช่น "พอร์ตที่เข้าไม่ถึง", "โฮสต์ต้องห้าม", ชุดค่าผสมอื่น ๆ ของโฮสต์ / พอร์ต / ผู้ดูแลระบบและไม่สามารถเข้าถึง / ห้ามได้ ; มองหาสิ่งเหล่านี้ในข้อความเนื่องจากเป็นตัวบ่งชี้ที่ชัดเจนของไฟร์วอลล์ IP ที่กำลังเล่นอยู่

คุณสามารถใช้คำสั่งnetstatเพื่อดูว่าพอร์ตเปิดอยู่และกำลังฟังอยู่หรือไม่

ตัวอย่าง

$ netstat -anp | less
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:41716               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      -                   
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      -                   
tcp        0      0 0.0.0.0:17500               0.0.0.0:*                   LISTEN      3034/dropbox        
tcp        0      0 0.0.0.0:17501               0.0.0.0:*                   LISTEN      3033/dropbox        
tcp        0      0 127.0.0.1:2143              0.0.0.0:*                   LISTEN      3191/ssh                       
tcp        0      0 127.0.0.1:2025              0.0.0.0:*                   LISTEN      3191/ssh 

ผลลัพธ์แสดงกระบวนการ(คอลัมน์ที่อยู่ด้านขวาสุด)ที่กำลังฟังบนพอร์ต TCP หมายเลขพอร์ตคือตัวเลขที่ตามหลังเครื่องหมายจุดคู่หลังจากที่อยู่ IP (0.0.0.0:111 จะเป็นพอร์ต 111 เป็นต้น)

ที่อยู่ IP แสดงท้องถิ่นและที่อยู่ต่างประเทศ Localจะเป็นระบบของคุณในขณะที่Foreignจะเป็นที่อยู่ใด ๆ ไม่ว่าจะเป็นการเชื่อมต่อกับพอร์ต TCP ของคุณหรือคุณเชื่อมต่อกับหนึ่งในพอร์ต TCP ของพวกเขา

ดังนั้นในกรณีของพอร์ต 22 นั่นคือ ssh daemon ที่รันบนระบบของฉันนั่นคือLISTENINGสำหรับการเชื่อมต่อ เมื่อมีคนพยายามที่จะเชื่อมต่อกับsshภูตมันจะลอกสำเนาของตัวเองและผลักดันการเชื่อมต่อนั้นออกไปยังพอร์ตอื่นทำให้พอร์ต TCP 22 เปิดสำหรับการเชื่อมต่อเพิ่มเติมตามที่พวกเขาเข้ามา

การกำหนดค่าและสถานะของการกำหนดค่าไฟร์วอลล์เป็นเฉพาะไฟร์วอลล์ / ระบบปฏิบัติการ

สิ่งที่คุณสามารถทำได้คือลองจาก server2:

nmap server1

เมื่อเร็ว ๆ นี้ฉันได้รับคำขอเดียวกันและมาถึงเธรด ฉันสามารถสแกนพอร์ตที่เปิดอยู่บน FW ด้วยคำสั่ง nc เช่นนี้เมื่อฉันค้นหาผลลัพธ์:

nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open

โดยทั่วไปถ้าฉันได้รับ 'หมดเวลา' ก็หมายความว่าพอร์ตไม่ได้เปิดใน FW

คุณสามารถใช้เครื่องมือออนไลน์เช่น www.firewallruletest.com เพื่อดูว่าโฮสต์ภายนอกสามารถสร้างการเชื่อมต่อ tcp ได้หรือไม่