เหตุใดจึงปิดกั้นพอร์ต 22 ขาออก

61

ฉันเป็นโปรแกรมเมอร์และฉันทำงานให้กับลูกค้าบางรายที่มีเครือข่ายบล็อกการเชื่อมต่อขาออกที่พอร์ต 22 เมื่อพิจารณาว่าโปรแกรมเมอร์มักจะต้องใช้พอร์ต 22 เป็น ssh ดูเหมือนว่าเป็นขั้นตอนต่อต้าน ที่ดีที่สุดมันบังคับให้โปรแกรมเมอร์เรียกเก็บเงินจาก บริษัท สำหรับอินเทอร์เน็ต 3G ที่แย่ที่สุดก็หมายความว่าพวกเขาไม่สามารถทำงานได้อย่างมีประสิทธิภาพ

ด้วยความยากลำบากในการสร้างสิ่งนี้ผู้ดูแลระบบที่มีประสบการณ์โปรดอธิบายถึงประโยชน์ที่ต้องการสำหรับสิ่งที่ดูเหมือนว่าเป็นการกระทำที่สูญเสีย?

ssh port blocking

— Runako
แหล่งที่มา

1

การปิดกั้นพอร์ตเป็นเพียงครึ่งหนึ่งของการต่อสู้ เพื่อให้ครบวงจรคุณต้องตรวจสอบให้แน่ใจว่าบริการที่คุณพยายามป้องกันนั้นไม่ได้ทำงานบนพอร์ตที่ไม่ได้มาตรฐาน

— aharden

1

คำถามควรเป็น "ทำไมบล็อกพอร์ต 22 ขาออก" เนื่องจากมีหลายล้านเหตุผลที่ดีที่ทำให้คุณต้องการให้บริการ ssh ของคุณบนพอร์ตที่ไม่ได้มาตรฐาน ขาออก ... ไม่มาก ฉันใส่ +1 ลงในคำตอบของ Robert Moir ในขณะที่เขาทำงานได้ดีมาก

— KPWINC

@KPWINC เพิ่มความกระจ่างให้กับชื่อ ขอบคุณ!

— runako

3

คิดว่าพอร์ต 22 เป็นกล่องของแพนโดร่า ผู้ดูแลระบบเครือข่ายไม่สามารถมองเห็นสิ่งที่อยู่ในทราฟฟิกและที่แย่ที่สุด ssh สามารถใช้ข้ามการรักษาความปลอดภัยเครือข่ายที่ทำให้ความสมบูรณ์ของเครือข่ายลดลง

— biosFF

1

@biosFF: พอร์ต 443

— Hello71

77

ฉันไม่เห็นว่ามีใครสะกดความเสี่ยงเฉพาะด้วยการส่งต่อพอร์ต SSH โดยละเอียด

หากคุณอยู่ในไฟร์วอลล์และมีการเข้าถึง SSH ขาออกไปยังเครื่องบนอินเทอร์เน็ตสาธารณะคุณสามารถ SSH กับระบบสาธารณะนั้นและในกระบวนการสร้างอุโมงค์เพื่อให้ผู้คนบนอินเทอร์เน็ตสาธารณะสามารถใช้ระบบในเครือข่ายของคุณได้อย่างสมบูรณ์ ข้ามไฟร์วอลล์

หาก fred คือเดสก์ท็อปของคุณและบาร์นีย์เป็นเซิร์ฟเวอร์สำคัญที่ บริษัท ของคุณและ wilma เป็นสาธารณะการเรียกใช้ (บน fred):

ssh -R *: 9000: barney: 22 wilma

และการล็อกอินจะทำให้ผู้โจมตี ssh ไปยังพอร์ต 9000 บนวิลมาและคุยกับ SSH daemon ของบาร์นีย์

ไฟร์วอลล์ของคุณไม่เคยเห็นว่าเป็นการเชื่อมต่อที่เข้ามาเพราะข้อมูลกำลังถูกส่งผ่านการเชื่อมต่อที่ก่อตั้งขึ้นในทิศทางขาออก

มันน่ารำคาญ แต่เป็นนโยบายความปลอดภัยเครือข่ายที่ถูกต้องสมบูรณ์

— เจมส์เอฟ
แหล่งที่มา

1

ขอบคุณสำหรับการตอบสนองที่ลึกซึ้งมาก นี่เป็นหนึ่งในไม่กี่คำตอบที่ตอบสนองความเสี่ยงด้านเทคนิค (เมื่อเทียบกับความเสี่ยงทางการเมือง) ของพอร์ตขาออกที่เปิดอยู่

— runako

6

+1 สำหรับการให้เหตุผลด้านเทคนิคที่ดี (อย่างไรก็ตามสิ่งนี้สามารถทำได้โดยผู้มุ่งร้ายที่สามารถใช้พอร์ตอื่นนอกเหนือจาก TCP 22 บนรีโมตโฮสต์ซึ่งเรากลับไปบล็อกบางนโยบายทั้งหมด)

— DerMike

7

ด้วยโปรโตคอลที่ปรับแต่งเองและพร็อกซีการเขียนโปรแกรมที่ชาญฉลาดบางอย่างสิ่งนี้สามารถทำได้ผ่าน HTTPS แม้ว่าจะช้ากว่าก็ตาม ตราบใดที่คุณอนุญาตการรับส่งข้อมูลที่เข้ารหัสคุณมีความเสี่ยงต่อ "การโจมตี" ประเภทนี้

— Michael Sondergaard

3

นี่คือการตอบสนองที่ดี JamesF แต่ไม่ใช่ปัญหาด้านความปลอดภัยที่ควรค่าเพราะเป็นสถานการณ์สมมติที่หายากมากและต้องการการใช้ประโยชน์จากเซิร์ฟเวอร์ / ไคลเอ็นต์ SSH ผู้ใช้ที่เป็นอันตรายจะต้องใช้ประโยชน์จากเซิร์ฟเวอร์ SSH ก่อน (บนเดสก์ท็อปของคุณ) และหาวิธีในการใช้ประโยชน์จากไคลเอ็นต์ SSH ของคุณ (บนโฮสต์ธุรกิจของคุณ) เนื่องจากคุณไม่สามารถใช้พอร์ต 22 เพื่อเข้าถึงหรือพูดคุยกับโฮสต์ไฟร์วอลล์ธุรกิจ (ซึ่งมีพอร์ตขาออก 22 เท่านั้น) หากมาตรฐานความปลอดภัยของคุณอยู่ในระดับสูงโฮสต์ธุรกิจของคุณก็ไม่ควรใช้อินเทอร์เน็ตในทุกสถานการณ์

— เด็กซ์เตอร์

1

คุณสามารถรับส่งข้อมูลผ่าน DNS (เช่นด้วยiodine) หาก HTTPS และ SSH ไม่พร้อมใช้งาน แต่มันช้ามาก

— Mark K Cowan

38

หากพวกเขากำลังบล็อกพอร์ตที่ผิดพลาดปล่อยให้บางสิ่งบางอย่างผ่านไปและปิดกั้นบางสิ่งบางอย่างโดยการสุ่ม (ฉันชอบเรื่องราวที่น่าเศร้าของ Paul Tomblin ของผู้คนที่ปิดกั้น SSH และอนุญาต Telnet) จากนั้นพวกเขามีกรณีแปลก ๆ ไปเกี่ยวกับการรักษาความปลอดภัยปริมณฑลเครือข่ายของพวกเขาหรือตำรวจรักษาความปลอดภัยของพวกเขาจากภายนอกอย่างน้อยก็คิดออกมาไม่ดีอย่างเห็นได้ชัด คุณไม่สามารถทำความเข้าใจกับสถานการณ์เช่นนั้นดังนั้นเพียงแค่คิดอัตราการไปสำหรับคนที่เจ็บปวดและดำเนินการกับวันของคุณ

หากพวกเขากำลังปิดกั้นพอร์ตทั้งหมดเว้นแต่จะมีกรณีธุรกิจเฉพาะสำหรับการอนุญาตการรับส่งข้อมูลผ่านพอร์ตนั้น ณ จุดที่จัดการอย่างระมัดระวังแล้วพวกเขากำลังทำมันเพราะพวกเขามีความสามารถในงานของพวกเขา

เมื่อคุณพยายามที่จะเขียนแอปพลิเคชันที่ปลอดภัยคุณทำให้เป็นเรื่องง่ายสำหรับกระบวนการอื่นในการอ่านและเขียนข้อมูลตามที่พวกเขาต้องการหรือคุณมี API ที่ทำเป็นเอกสารอย่างรอบคอบสองสามข้อที่คุณคาดหวังให้ผู้อื่นโทรหา

การจัดการความเสี่ยง - หากคุณรู้สึกว่าการรับส่งข้อมูลไปยังหรือจากเครือข่ายของคุณไปสู่อินเทอร์เน็ตนั้นมีความเสี่ยงคุณจึงต้องพยายามลดปริมาณการรับส่งข้อมูลที่สามารถเข้าถึงอินเทอร์เน็ตได้ทั้งในแง่ของจำนวนเส้นทางและจำนวนวิธี จากนั้นคุณสามารถตรวจสอบและกรองเกตเวย์และพอร์ต "ความจำเริญ" ที่เลือกเหล่านี้เพื่อลองและรับรองว่าทราฟฟิกที่เดินทางมานั้นเป็นสิ่งที่คุณคาดหวัง

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

แก้ไข: ฉันควรชี้แจงฉันไม่ได้แค่พูดถึงความเสี่ยงของโปรโตคอลหนึ่งที่ได้รับอนุญาตและอีกบล็อกฉันกำลังพูดถึงความเสี่ยงที่อาจเกิดขึ้นกับธุรกิจของข้อมูลที่ได้รับอนุญาตให้ไหลเข้าหรือออกจากเครือข่ายในการควบคุม ทาง

ตอนนี้สำหรับ caveats และอาจมีแผนจะเพิ่มสิ่งต่าง ๆ :

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

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

— Rob Moir
แหล่งที่มา

3

+1 สำหรับหากพวกเขากำลังปิดกั้นพอร์ตทั้งหมดเว้นแต่จะมีกรณีธุรกิจเฉพาะสำหรับอนุญาตการรับส่งข้อมูลผ่านพอร์ตนั้น ณ จุดที่จัดการอย่างระมัดระวังแล้วพวกเขากำลังทำเพราะพวกเขามีความสามารถในงานของพวกเขา

— cop1152

-1 เนื่องจาก ssh ไม่สามารถตรวจสอบโดยคนรักษาความปลอดภัย แต่ Telnet สามารถ ประเด็นของฉันคือในขณะที่มีนโยบายความปลอดภัยของเครือข่ายที่โง่เขลาการกำหนดนโยบายให้เป็น "สุ่ม" และ "whackjob" โดยที่ไม่เข้าใจความต้องการทางธุรกิจที่แท้จริง

— pcapademic

2

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

— Rob Moir

+1 สำหรับ "พอร์ตทั้งหมด"

— Ian Boyd

18

บริษัท ขนาดใหญ่แห่งหนึ่งใน Rochester NY ที่เคยทำภาพยนตร์หลายเรื่องบล็อก SSH ขาออกเมื่อฉันทำงานที่นั่น แต่อนุญาตให้telnet ! เมื่อฉันถามเกี่ยวกับเรื่องนี้พวกเขาบอกว่า ssh เป็นช่องโหว่

กล่าวอีกนัยหนึ่ง บริษัท บางแห่งตัดสินใจโง่ ๆ แล้วทำข้อแก้ตัวเกี่ยวกับความปลอดภัยแทนที่จะยอมรับความผิดพลาดของพวกเขา

— พอลทอมบลิน
แหล่งที่มา

6

TELNET เป็นช่องโหว่ด้านความปลอดภัย มันควรจะถูกแบน (นี่เป็นเพียงสำหรับคนที่จะทำให้การตัดสินใจโง่ขึ้นในอนาคต)

— nik

3

ขอผมอธิบายอย่างละเอียดที่นี่รูความปลอดภัยคืออะไรที่อยู่กับพื้นผิวที่ถูกยึดไว้ หากคุณเป็นเจ้าของเว็บไซต์พยายามเชื่อมต่อกับเซิร์ฟเวอร์ของคุณ TELNET เป็นช่องโหว่ หากคุณเป็นพนักงาน บริษัท ทางการเงินที่พยายามเชื่อมต่อกับเซิร์ฟเวอร์ภายในบ้านของคุณ (ผ่านสายที่นายจ้างตรวจสอบ) SSH คือช่องโหว่ด้านความปลอดภัยสำหรับนายจ้างของคุณ!

— nik

1

เมื่อพิจารณาว่าการปลอมแปลง telnet ในทั้งสองทิศทางนั้นง่ายเพียงใดฉันจะบอกว่า telnet เป็นช่องโหว่ด้านความปลอดภัยแม้สำหรับ บริษัท ที่อนุญาตให้ออกนอกระบบ แต่ บริษัท ที่อนุญาต แต่ไม่อนุญาต ssh จะไม่ทำการตัดสินใจด้านความปลอดภัยที่ชาญฉลาดในทุกกรณี

— Paul Tomblin

3

เทลเน็ตเป็นของขวัญที่มอบให้ มันโอเคเมื่อ 20 ปีที่แล้ว แต่ตอนนี้ฉันหวังว่ามันจะหยุด

— Rob Moir

2

ทุกอย่างขึ้นอยู่กับ POV ของคุณ พวกเขาอาจมีคนที่ต้องการเข้าถึงกระบวนการดั้งเดิมผ่าน Telnet ซึ่งเราตรวจสอบได้ง่าย OTOH คุณไม่รู้ว่าเกิดอะไรขึ้นกับ SSH ผู้คนสามารถสร้างอุโมงค์ไปยังเครือข่ายต่างประเทศและทำสิ่งที่โง่เง่าได้ทุกประเภท ไม่ควรใช้ Telnet ในทุกวันนี้ แต่ใครก็ตามที่อนุญาตให้ SSH ขาออกจำเป็นต้องหาอาชีพใหม่

— duffbeer703

6

ฉันสามารถเข้าใจการบล็อกการสื่อสาร SSH ขาเข้าหาก บริษัท ไม่อนุญาตให้ลงชื่อเข้าใช้ภายนอก แต่นี่เป็นครั้งแรกที่ฉันได้ยินบล็อก SSH ขาออก

สิ่งสำคัญที่ควรทราบคือไฟร์วอลล์ดังกล่าวอาจ จำกัด เฉพาะผู้ใช้ SSH ทั่วไป ถ้าใครบางคนต้องการ SSH ภายนอก (ซึ่งโดยทั่วไปจะเป็นเซิร์ฟเวอร์ / เครื่องที่พวกเขามีการเข้าถึงที่สำคัญนอกเครือข่ายองค์กร) พวกเขาสามารถเรียกใช้เซิร์ฟเวอร์ SSH บนพอร์ตอื่นที่ไม่ใช่ 22 (พูดพอร์ต 80) บล็อกจะถูกข้ามได้อย่างง่ายดาย

นอกจากนี้ยังมีเครื่องมือโดเมนสาธารณะหลายตัวที่จะช่วยให้คุณออกจากองค์กรผ่าน HTTP (พอร์ต 80 หรือ HTTPS พอร์ต 443) และมอบพรอกซีเพื่อให้คุณเชื่อมต่อกับพอร์ต 22 ภายนอก

แก้ไข: โอเคเดี๋ยวก่อนฉันมีความคิดว่าทำไมอาจเป็นนโยบาย

บางครั้งผู้คนใช้อุโมงค์ SSH เพื่อข้ามไฟร์วอลล์พื้นฐานขาออกสำหรับโปรโตคอลเช่น IM และ Bittorrent (ตัวอย่าง) // อาจ // นี้ได้เรียกใช้นโยบายดังกล่าว อย่างไรก็ตามฉันยังรู้สึกว่าเครื่องมือทันเนลเหล่านี้ส่วนใหญ่จะสามารถทำงานกับพอร์ตอื่นที่ไม่ใช่ 22

วิธีเดียวที่ช่องทางขาออกดังกล่าวสามารถบล็อกได้คือการตรวจจับการสื่อสาร SSH ในทันทีและ (บล็อกแบบไดนามิก) บล็อกการเชื่อมต่อ TCP เหล่านี้

— nik
แหล่งที่มา

3

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

— bandi

1

ที่เดียวที่ฉันทำงานเพื่อนร่วมงานคนหนึ่งของฉันใช้โปรแกรมที่เชื่อมช่องทางเครือข่ายทั้งหมดผ่านอุโมงค์ SSH ผ่านเว็บพร็อกซีของเราไปยังพอร์ต 80 บนคอมพิวเตอร์ที่บ้านของเขาและจากที่นั่นไปยังอินเทอร์เน็ต เขาสามารถใช้โปรโตคอลใดก็ได้ที่เขาต้องการ แต่ดูเหมือนว่ามันมาจากบ้านของเขาแทนที่จะเป็น บริษัท โชคดีที่เขารู้ว่า clueless ผู้ดูแลระบบเครือข่ายเป็นดังนั้นเขาจึงไม่เสี่ยงที่จะถูกจับ

— Paul Tomblin

1

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

— Rob Moir

4

อาจเป็นปัญหาด้านกฎระเบียบ / การปฏิบัติตามกฎระเบียบ นายจ้างของคุณต้องการที่จะสามารถอ่าน / เก็บการสื่อสารทั้งหมด นี่มักเป็นข้อกำหนดในอุตสาหกรรมเช่นธนาคาร

— โจ
แหล่งที่มา

นั่นไม่ได้หมายความว่าพวกเขาจะต้องบล็อค HTTPS ด้วยใช่ไหม

— runako

3

ไม่พวกเขาเปิดใช้งานการตรวจสอบ SSL กระบวนการนี้ถอดรหัส HTTPS จากนั้นเข้ารหัสลับอีกครั้งใน / ออกแพ็กเก็ตโดยการฉีดใบรับรองที่เชื่อถือได้ในเวิร์กสเตชันทั้งหมดตามนโยบายกลุ่ม ด้วยวิธีนี้พวกเขาสามารถกรอง / สแกนเช่นเดียวกับ HTTP อุตสาหกรรมการธนาคารเป็นหนึ่งในสภาพแวดล้อมที่เลวร้ายที่สุดในการล็อคเครือข่าย

— spoulson

4

มีเหตุผลหลักสองประการในการบล็อกพอร์ตขาออก 22 ในความคิดของฉัน

อันดับแรกตามที่ผู้คนได้กล่าวถึงการส่งต่อพอร์ต SSH สามารถใช้เป็นพร็อกซีหรือบายพาสรอบพอร์ตและบริการอื่น ๆ เพื่อหลีกเลี่ยงนโยบายด้านไอทีที่ระบุว่าปริมาณการใช้งานดังกล่าวไม่ได้รับอนุญาต

ประการที่สองมัลแวร์ / บอตเน็ตจำนวนมากจะใช้พอร์ต 22 เพราะมักถูกมองว่า "ปลอดภัย" และอนุญาตดังนั้น จากนั้นพวกเขาสามารถเปิดใช้งานกระบวนการออกจากพอร์ตนั้นและคอมพิวเตอร์ที่ติดเชื้ออาจเปิดใช้การโจมตีด้วยกำลังดุร้ายของ SSH

— jtimberman
แหล่งที่มา

3

บ่อยครั้งกว่าจะมีกรณีของการบล็อกการเชื่อมต่อขาออกทั้งหมดเว้นแต่จำเป็นและจนกว่าคุณจะไม่มีใครลองพอร์ต 22 ที่จะพร้อมใช้งานสำหรับการเชื่อมต่อขาออก (เพียง 80, 433 และอื่น ๆ ) หากเป็นกรณีนี้การแก้ปัญหาอาจง่ายพอ ๆ กับการติดต่อ IS / IT และบอกพวกเขาว่าเหตุใดคุณจึงต้องมีข้อยกเว้นในการเพิ่มเพื่อให้สถานีของคุณสามารถทำการเชื่อมต่อ SSH ขาออกไปยังโฮสต์ที่เฉพาะเจาะจงหรือโดยทั่วไป

บางครั้งมันเป็นความกังวลที่คนอาจใช้สิ่งอำนวยความสะดวกในการใช้ SSH เป็นวิธีการตั้งค่าพร็อกซี (ผ่านการส่งต่อพอร์ตผ่านลิงค์) เพื่อหลีกเลี่ยงการควบคุมอื่น ๆ นี่อาจเป็นปัจจัยที่สำคัญมากในบางอุตสาหกรรมที่มีการควบคุม (เช่นธนาคาร) ซึ่งการสื่อสารทั้งหมดจะต้องได้รับการตรวจสอบ / บันทึกด้วยเหตุผลทางกฎหมาย (กีดกันการค้าภายใน, ตรวจจับ / ปิดกั้นการถ่ายโอนข้อมูลขององค์กรหรือส่วนบุคคล เป็นความกลัวที่ยิ่งใหญ่ของการรั่วไหลภายในที่ให้ออกไปโดยไม่ตั้งใจหรืออย่างอื่นความลับทางการค้า ในกรณีเหล่านี้ใช้ลิงค์ 3G ของคุณ (หรือเทคนิคอื่น ๆ เช่นพยายามเชื่อมต่อ SSH ผ่าน HTTP) เพื่อหลีกเลี่ยงข้อ จำกัด อาจเป็นการละเมิดสัญญาของคุณและดังนั้นจึงเป็นความผิดที่ชิงทรัพย์ (หรืออาจแย่กว่านั้นคือความผิดทางกฎหมาย) รับการกระทำของคุณตกลงก่อนที่จะลอง

อีกเหตุผลหนึ่งก็คือการลดการปล่อยออก (เพื่อบริการภายในที่เข้าถึงได้โดยโฮสต์ภายในไฟร์วอลล์ของ บริษัท และต่อโลกโดยทั่วไป) สิ่งที่ไม่ควรจัดการเพื่อติดตั้งตัวเองบนเครื่องของ บริษัท หากไม่มีการเชื่อมต่อ SSH ที่เป็นไปได้ในพอร์ต 22 แฮ็กที่ง่ายกว่านั้นลองใช้การล็อกอิน SSH แบบ brute-force เนื่องจากหนึ่งในเส้นทางการแพร่กระจายจะถูกบล็อก ในกรณีนี้คุณสามารถขอเพิ่มข้อยกเว้นอีกครั้งเพื่อให้เครื่องของคุณสามารถเชื่อมต่อ SSH ได้หากการเชื่อมต่อเหล่านี้สามารถพิสูจน์ได้ว่าเป็นบุคคลที่อยู่ในการควบคุมของไฟร์วอลล์

— David Spillett
แหล่งที่มา

ใช่เป็นไปได้ค่อนข้างที่บริการขาออกทั้งหมดที่ไม่จำเป็นต้องใช้อาจถูกบล็อก (โดยค่าเริ่มต้น)

— nik

แต่การบล็อค tcp / 22 จะไม่ป้องกันการสื่อสารขาออกอย่างปลอดภัย (ซึ่งสามารถทำได้บนพอร์ตใดก็ได้ตราบใดที่ผู้ใช้มีผู้ฟังอยู่ข้างนอกซึ่งไม่ใช่เรื่องยากในปัจจุบัน)

— nik

หากเครือข่ายภายในใช้สำหรับการสื่อสาร SSH การบล็อกจะไม่ทำงานและหากไม่มีการสื่อสาร SSH ที่จำเป็นโดยทั่วไปจะไม่มีเครื่องฟัง SSH ที่มีช่องโหว่ภายในเครือข่ายเช่นกัน และการขยายพันธุ์หนอนทั่วไปไม่พยายามที่จะ SSH แรงเดรัจฉาน (ถ้าคุณมีความกังวลใจเกี่ยวกับการดูว่าในen.wikipedia.org/wiki/SSHBlock ) จะมีแนวโน้มที่จะพยายาม TCP / 445 กับเครื่องหน้าต่างของคุณ

— nik

3

ลูกค้าของคุณอาจอยู่ในความครอบครองของข้อมูลที่ไม่สำคัญที่พวกเขาต้องการเก็บไว้ SSH ขาออกเป็นสิ่งที่เลวร้ายจริงๆที่จะเปิดให้บริการสำหรับเครือข่ายทั้งหมด มันค่อนข้างง่ายที่จะหลีกเลี่ยงพร็อกซี่, ข้อมูลสำคัญรั่วไหลและเป็นที่น่ารังเกียจโดยทั่วไป

IMO สิ่งใดที่ผ่านขอบเขตเครือข่าย / อินเทอร์เน็ตควรเข้าใจและสามารถควบคุมได้ หากกลุ่ม devs ต้องการเข้าถึงเซิร์ฟเวอร์ที่ผู้ให้บริการโฮสต์ผ่าน ssh นั่นก็ใช้ได้ - แต่ก็ต้องมีเอกสารด้วย โดยทั่วไปในสถานที่ที่ฉันทำงานเราได้สร้างการเชื่อมต่อ VPN ระหว่างไซต์ไปยังสถานที่นอกเครือข่ายของเรา (โดยหลัก ๆ คือการขยายเครือข่ายภายในของเรา) และหลีกเลี่ยงโปรโตคอลไคลเอนต์เช่น SSH ผ่านอินเทอร์เน็ต

— duffbeer703
แหล่งที่มา

ขอบคุณสำหรับคำตอบ. คุณจัดการ VPNs เฉพาะสำหรับเว็บไซต์ที่อยู่นอกการควบคุมของคุณ (เช่น EC2, โฮสต์เว็บ ฯลฯ ) ได้อย่างไร โดยทั่วไปแล้วผู้ขายเหล่านี้ยินดีที่จะทำการตั้งค่าแบบกำหนดเองนี้ให้กับคุณหรือคุณมักจะต้องมีข้อผูกมัดขั้นต่ำที่ยิ่งใหญ่ในแง่ของธุรกิจเพื่อให้พวกเขาทำเช่นนั้น?

— runako

2

นอกจากนี้คุณยังกังวลว่าคุณบังคับให้คนใช้การ์ด 3G นอกเครือข่ายเพื่อทำงานให้สำเร็จหรือไม่? จากประสบการณ์ของฉันเครือข่ายที่ถูกล็อคอย่างหลีกเลี่ยงไม่ได้นำไปสู่การ์ด 3G จำนวนมากและการหลบเลี่ยงที่ซ่อนอยู่อื่น ๆ เพราะคนไม่สามารถทำงานได้ในเวลาที่กำหนดถ้าพวกเขาต้องรอให้ไอทีอนุมัติการใช้งานของพวกเขา เพื่อรับข้อยกเว้น (กรณีที่ร้ายแรงอย่างหนึ่งรวมถึงเมลเซิร์ฟเวอร์ที่ไม่ยอมรับไฟล์แนบที่เข้ามาจากอินเทอร์เน็ต Yikes!) ฉันอยากรู้ว่าคุณจัดการกับยอดเงินนี้ได้อย่างไร

— runako

1

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

— pcapademic

เรามีขนาดใหญ่พอที่อาจ 90% ของบริการของเราไม่ต้องการการบริหารขาออก โดยทั่วไปเมื่อเราทำเราทำข้อกำหนด VPN tunnel เป็นข้อกำหนดใน RFP ซึ่งมีแนวโน้มที่จะกำจัดผู้ขายที่ไม่สามารถจัดหาได้ ด้วยเหตุนี้ฉันจึงเชื่อว่าเรามีผู้ใช้ 3G เพียงเล็กน้อยและมีวิธีแก้ไขปัญหาที่คล้ายคลึงกัน

— duffbeer703

นอกจากนี้คุณไม่สามารถอนุญาตให้ผู้รักษาความปลอดภัยกำหนดการเข้าถึงได้ คุณให้การสนับสนุนแอปพลิเคชั่นและผู้ใช้เครือข่ายทำงานด้วยวิธีการที่ยอมรับได้ภายใต้การตรวจสอบความปลอดภัย หาทางแก้ปัญหาตั้งแต่เนิ่นๆไม่ใช่ตอนเช้าที่คุณต้องไปผลิต ที่ทำให้คุณอยู่ห่างจากความล่าช้าในรูปแบบ DMV ในการรับคำขอ

— duffbeer703

2

เพราะ SSH สามารถใช้เป็น VPN ได้ มันถูกเข้ารหัสเพื่อให้ผู้ดูแลระบบเครือข่ายไม่รู้ตัวเลยว่ากำลังออกจากเครือข่ายของพวกเขา (ดัมพ์ของฐานข้อมูลลูกค้า ฯลฯ ) ฉันเพียงแค่ครอบคลุมสิ่งนี้ในคอลัมน์รายเดือนของฉัน"ความลับอุโมงค์" ค่าใช้จ่ายของอินเทอร์เน็ต 3G บางอย่างนั้นน้อยกว่ามากโดยไม่ต้องกังวลเกี่ยวกับโปรโตคอลเข้ารหัสที่ส่งข้อมูลของคุณออกจากเครือข่าย ยิ่งไปกว่านั้นถ้าคุณเริ่มต้นบล็อกพอร์ตขาออก 22 และการตรวจสอบปริมาณการใช้งานคุณสามารถค้นหา SSH บนพอร์ตที่ไม่ได้มาตรฐานได้อย่างง่ายดายดังนั้นจึงพบว่าผู้คนละเมิดนโยบายความปลอดภัย

— เคิร์ต
แหล่งที่มา

ขอบคุณสำหรับความเข้าใจ ดูเหมือนว่าคุณจะไม่พิจารณา 3G อุโมงค์ลับ คุณช่วยอธิบายได้ไหมว่าทำไมการมีคนอยู่นอกเครือข่ายโดยสิ้นเชิงเมื่อสื่อสารกับอินเทอร์เน็ต ดูเหมือนว่าคุณจะชอบอุปกรณ์โกงมากกว่าเปิด 22 สำหรับขาออก

— runako

1

"... คุณสามารถค้นหา SSH บนพอร์ตที่ไม่ได้มาตรฐาน ... " จริง ๆ เหรอ? ต้องการค้นหาการเจรจา SSL / TLS บนพอร์ตอื่นที่ไม่ใช่ 443 ใช่ไหม อยากรู้อยากเห็นมาก

— Dscoduc

ถ้าคุณสามารถตรวจจับปริมาณข้อมูล ssh, Google: snort / ssh / การตรวจสอบ / เนื้อหา / กฎ, ไม่ทราบเกี่ยวกับ IDS อื่น ๆ แต่ถ้า Snort สามารถทำได้พวกเขาจะต้องถูกจับสวยที่จะไม่ทำเช่นกัน

— Kurt

1

ฉันรู้ว่ามีคนสองคนที่ใช้ความสามารถของ SSH ในทางที่ผิดเพื่อติดตั้ง SOCKS proxy ผ่าน SSH ดังนั้นจึงหลีกเลี่ยงข้อ จำกัด บางประการของไซต์

หรือแม้กระทั่งการส่งต่อพอร์ตแบบธรรมดา ( ssh -L ....) หากพอร์ตถูกบล็อกเนื่องจากข้อ จำกัด ของเว็บไซต์ฉันไปที่:

ผู้ดูแลระบบท้องถิ่นและ
ผู้จัดการโครงการของคุณ

พาพวกเขาไปที่โต๊ะและให้พวกเขาอธิบายรายละเอียดเกี่ยวกับสาเหตุที่ถูกบล็อก แน่นอนคุณต้องมีเหตุผลที่ดีว่าทำไมคุณถึงต้องเข้าถึงพอร์ต SSH ภายนอกเพื่อพัฒนาผลิตภัณฑ์ภายใน (ภายใน: ทำไมคุณต้องเข้าถึง boxA.example.com เมื่อคุณทำงานกับ บริษัท snakeoil.invalid)

แต่ฉันยังไม่เห็น บริษัท ที่ปิดกั้น SSH ขาออก :)

— serverhorror
แหล่งที่มา

ฉันเคยเห็น บริษัท หนึ่งที่บล็อก SSH ขาออก พวกเขายังปิดกั้นเกือบทุกอย่างและไวรัสตรวจสอบการถ่ายโอน HTTP ทั้งหมดโดยใช้พร็อกซี บริษัท เป็นศูนย์รับฝากหลักทรัพย์

— Esko Luontola

ฉันทำงานให้ บริษัท แบบนี้ โชคดีที่ SSH สามารถส่งสัญญาณไปที่ https ได้ แน่นอนว่าพวกเขาอนุญาตให้ https กับพอร์ต 443 ... sslh เพื่อช่วยเหลือเท่านั้น!

— Mikeage

proxytunnel FTW :)

— serverhorror

1

คำตอบที่ชัดเจนได้ถูกระบุไว้ทั้งหมด เป็นโปรโตคอลการเข้ารหัสที่สามารถใช้เพื่อหลีกเลี่ยงนโยบายผ่านการสร้างอุโมงค์ (นี่เป็นวิธีที่ยอดเยี่ยมในการผ่านตัวกรองเว็บขององค์กร) รวมถึงภัยคุกคามที่เกิดจากช่องทางการสื่อสารที่ไม่ได้รับอนุญาต (reverse proxy)

เป็นจริงแล้ว telnet ควรถูกทำลายในทุกเครือข่ายที่ทันสมัย แต่ฉันสามารถเห็นการอนุญาตให้ telnet ออกจากเครือข่ายในขณะที่ห้าม ssh Telnet มีความสามารถน้อยกว่า ssh และฉันสามารถตรวจสอบสตรีมในแบบเรียลไทม์ผ่าน sniffers ของฉันได้ตลอดเวลา หากฉันไม่มีอุปกรณ์เทลเน็ตในเครือข่ายหลักของฉันและผู้ใช้บางคนต้องการเทลเน็ตออกฉันจะสนใจอะไร ฉันสามารถดูได้และตรวจสอบว่าไม่ใช่ภัยคุกคาม

แน่นอนทั้งหมดนี้ขึ้นอยู่กับแนวคิดที่ว่านโยบายเริ่มต้นคือการปิดกั้นการส่งออกทั้งหมดและอนุญาตเฉพาะโปรโตคอลที่ระบุเท่านั้น คะแนนโบนัสหากคุณพร็อกซี่พวกเขาก่อนที่จะตีขอบ

— dr.pooter
แหล่งที่มา

0

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

— Maximus Minimus
แหล่งที่มา

0

เห็นได้ชัดว่าเป็นขาออก TCP / 22 บล็อกเป็นเรื่องง่ายที่จะหลีกเลี่ยงเว้นแต่ผู้บริหารเครือข่ายมีการดำเนินการอย่างจริงจังความพยายามอย่างจริงจังที่จะปิดกั้นการจราจร SSH ในที่เฉพาะเจาะจง ยิ่งไปกว่านั้นผู้ดูแลสินทรัพย์จะต้องมีลูกพอที่จะเรียกใช้คลังสินทรัพย์เพียงพอที่จะจับโมเด็ม 3G และที่อยู่ IP ที่น่าสงสัยใน 2 นิคส์ เรามีบริการ ClearWire ในพื้นที่ของเราดังนั้นเราจึงมี WiMax เป็นตัวเลือกในการใช้งานรอบการรักษาความปลอดภัยเครือข่ายของเรา

เราไม่ใช่สถาบันที่เกี่ยวข้องกับการรั่วไหลของข้อมูลเป็นหลัก แต่ถ้าเราเป็นเราจะต้องรวมนโยบายความปลอดภัยเครือข่าย draconian กับนโยบายสินทรัพย์ draconian กับการตรวจสอบ เพื่อความรู้ที่ดีที่สุดของฉันฉันไม่คิดว่าจะมีแพ็คเกจความปลอดภัยแบบปิดซึ่งจะปิดแจ็คเครือข่ายของสินทรัพย์ที่สินค้าคงเหลือด้วยการเชื่อมต่อเครือข่ายภายนอกบางชนิด ที่อาจจะมา

ในกรณีที่ไม่มีแพ็คเกจกระบวนการสินทรัพย์คงคลังเป็นหนึ่งในวิธีที่ดีที่สุดในการจับการเชื่อมต่อเครือข่ายแบบ end-run เช่น 3G หรือ WiMax

และในที่สุดการปิดกั้น blind ของ TCP / 22 จะบล็อกเพียงเจตนาน้อยของผู้ใช้ปลายทางที่ละเมิด AUP สำหรับเครือข่ายงานของพวกเขา

— sysadmin1138
แหล่งที่มา

คุณสามารถปรับแต่งรายงานด้วยบางอย่างเช่น SCCM เพื่อรับข้อมูลนั้น ที่ทำงานฉันใช้แล็ปท็อปส่วนตัวหรือการ์ด WAN เพื่อหลีกเลี่ยงการรักษาความปลอดภัยเครือข่ายขึ้นอยู่กับการลงโทษทางวินัย

— duffbeer703

0

ฉันเห็นบล็อก 22 รายการเมื่อพวกเขาค้นพบว่าผู้คนกำลังควบคุมปริมาณการใช้ http ผ่าน 22 มันเป็นตัวหยุดการแสดงสำหรับพวกเราที่ต้องการมัน แต่องค์กรกำลังยืนอยู่บนพื้น

— Shawn Anderson
แหล่งที่มา

0

องค์กรขนาดใหญ่ส่วนใหญ่จะบล็อกทุกอย่างและอนุญาตให้เข้าถึง HTTP / HTTPS ผ่านพร็อกซีเซิร์ฟเวอร์เท่านั้น

ฉันประหลาดใจมากที่ได้ยิน บริษัท ใด ๆ ที่อนุญาตการเชื่อมต่อภายนอกโดยตรงจากเดสก์ท็อปหรือเซิร์ฟเวอร์เว้นแต่มีความต้องการเฉพาะ

— เปโตร
แหล่งที่มา

0

ไม่มีอะไรหยุดคุณจากการรัน sshd ระยะไกลของคุณบนพอร์ต 80 ทั้ง ssh และ sshd มีตัวเลือก -p เพื่อตั้งค่าพอร์ต

แน่นอนถ้าผู้ดูแลระบบของคุณฉลาดพวกเขาควรดูปริมาณการใช้ ssh ไม่ใช่เฉพาะพอร์ต 22 ปริมาณข้อมูล ดังนั้นดูเหมือนว่าคุณมีปัญหานโยบายไม่ใช่ปัญหาด้านเทคโนโลยี

ตามที่คนอื่น ๆ ระบุไว้ว่าโปรโตคอลที่เข้ารหัสสามารถทำให้เกิดอาการแสบร้อนกลางอกในคนที่ต้องกังวลเกี่ยวกับปัญหาการปฏิบัติตามสารพัน

— Bruce ONeel
แหล่งที่มา