Tại sao chặn cổng 22 ra nước ngoài?

Tôi là một lập trình viên và tôi đã làm việc cho một vài khách hàng có mạng chặn các kết nối đi trên cổng 22. Xem xét rằng các lập trình viên thường cần sử dụng cổng 22 cho ssh, điều này có vẻ như là một thủ tục phản tác dụng. Tốt nhất, nó buộc các lập trình viên phải lập hóa đơn cho công ty cho Internet 3G. Tệ nhất, điều đó có nghĩa là họ không thể thực hiện công việc của mình một cách hiệu quả.

Với những khó khăn mà điều này tạo ra, một sysadmin có kinh nghiệm có thể vui lòng giải thích lợi ích mong muốn cho những gì có vẻ như là một hành động thua lỗ không?

Tôi không thấy rằng bất kỳ ai đã nói ra rủi ro cụ thể với việc chuyển tiếp cổng SSH một cách chi tiết.

Nếu bạn đang ở trong tường lửa và có quyền truy cập SSH ra ngoài vào một máy trên internet công cộng, bạn có thể SSH đến hệ thống công cộng đó và trong quá trình tạo một đường hầm để mọi người trên internet công cộng hoàn toàn có thể ssh đến một hệ thống trong mạng của bạn bỏ qua tường lửa.

Nếu fred là máy tính để bàn của bạn và barney là một máy chủ quan trọng tại công ty của bạn và wilma là công khai, đang chạy (trên fred):

ssh -R *: 9000: barney: 22 wilma

và đăng nhập sẽ cho phép kẻ tấn công ssh tới cổng 9000 trên wilma và nói chuyện với daemon SSH của barney.

Tường lửa của bạn không bao giờ xem nó là kết nối đến vì dữ liệu đang được truyền qua kết nối ban đầu được thiết lập theo hướng đi.

Thật khó chịu, nhưng một chính sách bảo mật mạng hoàn toàn hợp pháp.

Nếu họ chặn một số lỗi của các cổng, hãy để một số thứ thông qua và chặn một số thứ khác một cách ngẫu nhiên (tôi thích câu chuyện buồn của Paul Tomblin về những người chặn SSH và cho phép Telnet) thì họ có một trường hợp rất kỳ lạ về cách họ đi về việc bảo vệ chu vi mạng của họ, hoặc chính sách bảo mật của họ, từ bên ngoài ít nhất, dường như được suy nghĩ kém. Bạn không thể hiểu được những tình huống như vậy, vì vậy hãy tính cho họ mức độ phù hợp với những người đau đớn và tiếp tục với ngày của bạn.

Nếu họ chặn TẤT CẢ các cổng trừ khi có trường hợp kinh doanh cụ thể cho phép lưu lượng truy cập qua cổng đó, tại thời điểm đó, cổng đó được quản lý cẩn thận vì họ làm việc đó vì họ có năng lực trong công việc.

Khi bạn đang cố gắng viết một ứng dụng an toàn, bạn có dễ dàng cho các quy trình khác đọc và viết thông tin cho nó khi họ muốn hay bạn có một vài API được ghi chép cẩn thận mà bạn mong đợi mọi người gọi và bạn vệ sinh cẩn thận không?

Quản lý rủi ro - nếu bạn cảm thấy lưu lượng truy cập đến hoặc từ mạng của bạn truy cập Internet là rủi ro, thì bạn nên tìm cách giảm thiểu lượng lưu lượng truy cập có thể truy cập Internet, cả về số lượng tuyến và số phương thức. Sau đó, bạn có thể theo dõi và lọc các cổng và cổng "may mắn" đã chọn này để thử và đảm bảo rằng lưu lượng truy cập đi qua chúng là những gì bạn mong đợi.

Đây là một chính sách tường lửa "từ chối mặc định" và thường được coi là một ý tưởng hay, với một vài lưu ý mà tôi sẽ đến. Điều đó có nghĩa là mọi thứ đều bị chặn trừ khi có một lý do cụ thể để bỏ chặn nó và lợi ích của lý do này lớn hơn các rủi ro.

Chỉnh sửa: Tôi nên làm rõ, tôi không chỉ nói về những rủi ro của một giao thức được phép và một giao thức khác bị chặn, tôi đang nói về những rủi ro tiềm ẩn đối với việc kinh doanh thông tin được phép truyền vào hoặc ra khỏi mạng trong một không kiểm soát đường.

Bây giờ hãy cẩn thận và có thể là một kế hoạch để giải phóng mọi thứ:

Nó có thể gây phiền nhiễu khi bạn bị chặn khỏi một cái gì đó, đó là vị trí bạn thấy mình với một số khách hàng của bạn. Rất thường xuyên, những người phụ trách tường lửa nghĩ rằng công việc của họ là nói "Không", thay vì "Đây là những rủi ro, bây giờ lợi ích là gì, hãy xem chúng ta có thể làm gì".

Nếu bạn nói chuyện với bất cứ ai quản lý an ninh mạng cho khách hàng của mình, họ có thể sẵn sàng thiết lập một cái gì đó cho bạn. Nếu bạn có thể xác định một vài hệ thống cụ thể ở cuối, bạn cần truy cập và / hoặc đảm bảo bạn sẽ chỉ kết nối từ một địa chỉ IP cụ thể, họ có thể sẽ vui hơn khi tạo ngoại lệ tường lửa cho các kết nối SSH cho các điều kiện cụ thể đó sẽ chỉ mở kết nối với toàn bộ internet. Hoặc họ có thể có một cơ sở VPN mà bạn có thể sử dụng để vượt qua tường lửa.

Một công ty lớn nào đó ở Rochester NY đã từng làm rất nhiều bộ phim bị chặn ssh khi tôi làm việc ở đó, nhưng cho phép telnet ! Khi tôi hỏi về điều đó, họ nói rằng ssh là một lỗ hổng bảo mật.

Nói cách khác, các công ty đôi khi đưa ra những quyết định ngu ngốc, và sau đó tạo ra những lời bào chữa cho baloney về bảo mật hơn là thừa nhận sai lầm của họ.

Tôi có thể hiểu việc chặn liên lạc SSH gửi đến nếu công ty không cho phép đăng nhập bên ngoài. Nhưng, đây là lần đầu tiên tôi nghe thấy một khối SSH đi.

Điều quan trọng cần lưu ý là việc tường lửa như vậy có thể sẽ chỉ giới hạn người dùng SSH thông thường. Nếu ai đó thực sự muốn SSH bên ngoài (thường là máy chủ / máy mà họ có quyền truy cập đáng kể, bên ngoài mạng doanh nghiệp), họ có thể dễ dàng chạy máy chủ SSH trên một cổng khác ngoài 22 (ví dụ, cổng 80). Các khối sẽ được bỏ qua dễ dàng.

Ngoài ra còn có một số công cụ miền công cộng sẽ cho phép bạn thoát khỏi doanh nghiệp qua HTTP (cổng 80 hoặc cổng HTTPS 443) và cung cấp proxy để cho phép bạn kết nối với cổng 22 bên ngoài.

Chỉnh sửa: Ok, đợi một chút, tôi có một ý tưởng tại sao đây có thể là một chính sách.

Đôi khi, mọi người sử dụng các đường hầm SSH để vượt qua các tường lửa bên ngoài cơ bản cho các giao thức như IM và Bittorrent (ví dụ). Điều này // có thể // đã kích hoạt một chính sách như vậy. Tuy nhiên, tôi vẫn cảm thấy rằng hầu hết các công cụ đường hầm này sẽ có thể hoạt động trên các cổng khác ngoài 22.

Cách duy nhất các đường hầm đi ra như vậy có thể bị chặn là bằng cách phát hiện giao tiếp SSH một cách nhanh chóng và (tự động) chặn các kết nối TCP này.

Đây có lẽ là một vấn đề quy định / tuân thủ. Nhà tuyển dụng của bạn muốn có thể đọc / lưu trữ tất cả các giao tiếp. Điều này rất thường xuyên là một yêu cầu trong các ngành công nghiệp như ngân hàng.

Theo tôi, có hai lý do chính để chặn cổng 22 bên ngoài.

Đầu tiên, như mọi người đã đề cập, chuyển tiếp cổng SSH có thể được sử dụng như một proxy hoặc bỏ qua các cổng và dịch vụ khác để tránh chính sách CNTT nêu rõ lưu lượng như vậy không được phép.

Thứ hai, rất nhiều phần mềm độc hại / botnet sẽ sử dụng cổng 22 vì nó thường được xem là "an toàn" và do đó được cho phép. Sau đó, họ có thể khởi chạy các quy trình ngoài cổng đó và các máy tính bị nhiễm cũng có thể khởi chạy các cuộc tấn công vũ trang SSH.

Thường xuyên hơn không phải là trường hợp chặn tất cả các kết nối đi trừ khi cần thiết và cho đến khi bạn thử, không ai yêu cầu cổng 22 có sẵn cho các kết nối đi (chỉ 80, 433, v.v.). Nếu đây là trường hợp thì giải pháp có thể đơn giản như liên hệ với IS / IT và cho họ biết lý do tại sao bạn cần thêm ngoại lệ để trạm của bạn có thể thực hiện kết nối SSH đến các máy chủ cụ thể hoặc nói chung.

Đôi khi, mọi người có thể sử dụng tiện ích này để sử dụng SSH như một cách để thiết lập proxy (thông qua chuyển tiếp cổng qua liên kết) để tránh các điều khiển khác. Đây có thể là một yếu tố rất quan trọng trong một số ngành được quy định (ví dụ như ngân hàng), nơi tất cả các thông tin liên lạc cần được giám sát / ghi lại vì lý do pháp lý (không khuyến khích giao dịch nội gián, phát hiện / chặn chuyển dữ liệu của công ty hoặc cá nhân, v.v.) là một nỗi sợ hãi lớn của rò rỉ nội bộ cho đi, vô tình hay nói cách khác, bí mật thương mại. Trong những trường hợp sử dụng liên kết 3G của bạn (hoặc các kỹ thuật khác như cố gắng tạo đường hầm SSH qua HTTP) để tránh các hạn chế có thể vi phạm hợp đồng của bạn và do đó, vi phạm pháp luật (hoặc có thể tệ hơn là vi phạm pháp luật), vì vậy hãy cẩn thận nhận được hành động của bạn đồng ý trước khi bạn cố gắng.

Một lý do khác có thể là để giảm dấu chân đi (đối với các dịch vụ nội bộ có thể truy cập được đến các máy chủ lưu trữ trong tường lửa của công ty và trên thế giới nói chung) nếu một cái gì đó không được quản lý tự cài đặt trên máy chạy của công ty. Nếu không có kết nối SSH nào trên cổng 22, nhiều bản hack đơn giản hơn, hãy thử sử dụng thông tin đăng nhập SSH mạnh mẽ vì một trong những tuyến truyền bá của chúng sẽ bị chặn. Trong trường hợp này, một lần nữa bạn có thể yêu cầu thêm một ngoại lệ để máy của bạn có thể tạo kết nối SSH, nếu những kết nối này có thể được chứng minh cho những người kiểm soát (các) tường lửa.

Khách hàng của bạn có thể đang sở hữu dữ liệu không tầm thường mà họ muốn giữ lại. SSH đi là một điều thực sự tồi tệ khi mở cho toàn bộ mạng. Thật là tầm thường khi bỏ qua các proxy, rò rỉ dữ liệu nhạy cảm và nói chung là đáng ghét.

IMO, bất cứ điều gì đi qua chu vi mạng / internet nên được hiểu và kiểm soát được. Nếu một nhóm các nhà phát triển cần truy cập vào máy chủ tại một nhà cung cấp dịch vụ lưu trữ thông qua ssh, điều đó tốt - nhưng nó cũng cần phải được ghi lại. Nói chung tại những nơi tôi đã làm việc, chúng tôi thiết lập các kết nối VPN từ trang web đến các địa điểm bên ngoài mạng của chúng tôi, (về cơ bản là mở rộng mạng nội bộ của chúng tôi) và tránh các giao thức máy khách như SSH qua internet.

Bởi vì SSH có thể được sử dụng như một VPN. Nó được mã hóa để quản trị viên mạng thực sự không biết cái gì rời khỏi mạng của họ (kết xuất cơ sở dữ liệu khách hàng, v.v.). Tôi chỉ đề cập đến những thứ này trong cột hàng tháng "Đường hầm bí mật" . Chi phí của một số internet 3G là rất ít so với việc phải lo lắng về các giao thức được mã hóa chuyển dữ liệu của bạn ra khỏi mạng. Ngoài ra, nếu bạn mặc định chặn cổng 22 đi và kiểm tra lưu lượng, bạn có thể dễ dàng tìm thấy SSH trên các cổng không chuẩn và do đó tìm thấy những người vi phạm chính sách bảo mật.

Tôi biết một vài người lạm dụng các khả năng của SSH để cài đặt proxy SOCKS thông qua SSH, do đó tránh được một số hạn chế của trang web.

Hoặc thậm chí một số chuyển tiếp cổng đơn giản ( ssh -L ....), nếu cổng thực sự bị chặn do hạn chế trang web tôi sẽ truy cập:

• quản trị viên địa phương và
• quản lý dự án của bạn

đưa họ đến một cái bàn và để họ giải thích lý do tại sao điều này bị chặn. Tất nhiên bạn cần có lý do chính đáng tại sao bạn cần quyền truy cập vào cổng SSH bên ngoài để phát triển một sản phẩm nội bộ (nội bộ: Tại sao bạn cần truy cập vào boxA.example.com khi bạn làm việc cho công ty snoil.invalid)

Nhưng tôi vẫn chưa thấy một công ty nào chặn SSH đi :)

Các câu trả lời rõ ràng đã được nêu. Đó là một giao thức được mã hóa có thể được sử dụng để phá vỡ chính sách thông qua việc tạo các đường hầm (đây là một cách tuyệt vời để vượt qua các bộ lọc web của công ty) cũng như mối đe dọa từ các kênh liên lạc trái phép (proxy ngược).

Đó là sự thật, telnet nên bị phá hủy trong bất kỳ mạng hiện đại nào. Nhưng, tôi có thể thấy cho phép telnet ra khỏi mạng trong khi cấm ssh. Telnet có khả năng kém hơn ssh và tôi luôn có thể theo dõi luồng, trong thời gian thực, thông qua những người đánh hơi của tôi. Nếu tôi không có bất kỳ thiết bị telnet nào trong mạng lõi của mình và một số người dùng muốn telnet, tôi sẽ quan tâm điều gì. Tôi có thể nhìn thấy nó, và xác minh rằng nó không phải là một mối đe dọa.

Tất nhiên, tất cả điều này phụ thuộc vào ý tưởng rằng chính sách mặc định là chặn tất cả đầu ra và chỉ cho phép các giao thức cụ thể. Điểm thưởng nếu bạn ủy quyền cho họ trước khi đạt được lợi thế.

Đây không phải là trường hợp chặn cổng 22 cụ thể vì quản trị viên có một điều chống lại SSH, hơn nữa là trường hợp chỉ mở các cổng mà họ biết họ cần mở. Nếu quản trị viên của bạn không được thông báo rằng SSH cần mở, quản trị viên của bạn sẽ chặn nó, theo cùng một nguyên tắc áp dụng để vô hiệu hóa các dịch vụ không sử dụng trên máy chủ.

Rõ ràng, một khối TCP / 22 bên ngoài rất dễ bị phá vỡ trừ khi các quản trị viên mạng đã thực hiện những nỗ lực nghiêm túc, nghiêm túc để chặn lưu lượng SSH cụ thể . Hơn nữa, các quản trị viên tài sản cần phải ở trong bóng đủ để chạy kiểm kê tài sản đủ để bắt các modem 3G và địa chỉ IP đáng ngờ trên các NIC thứ 2. Chúng tôi có dịch vụ ClearWire trong khu vực của chúng tôi, vì vậy chúng tôi thậm chí còn có WiMax như một tùy chọn kết thúc xung quanh bảo mật mạng của chúng tôi.

Chúng tôi không phải là một tổ chức chủ yếu liên quan đến rò rỉ thông tin. Nhưng nếu là chúng ta, chúng ta cần kết hợp chính sách an ninh mạng hà khắc với chính sách tài sản hà khắc, với kiểm toán. Theo hiểu biết tốt nhất của tôi, tôi không nghĩ rằng có một gói bảo mật ngoài luồng sẽ tắt giắc cắm mạng của một tài sản tồn kho với một kết nối mạng bên ngoài nào đó. Đó có thể là đến.

Trong trường hợp không có gói như vậy, quy trình kiểm kê tài sản là một trong những cách tốt nhất để bắt kết nối mạng chạy cuối như 3G hoặc WiMax.

Và cuối cùng, việc chặn TCP / 22 một cách mù quáng sẽ chỉ chặn những người dùng cuối có ý định vi phạm AUP cho mạng làm việc của họ.

Tôi đã thấy 22 bị chặn khi họ phát hiện ra rằng mọi người đang điều hướng lưu lượng truy cập http đến 22. Đó là một điểm dừng hiển thị cho những người trong chúng ta cần nó nhưng org đã đứng vững.

Hầu hết các tổ chức lớn hơn sẽ chặn mọi thứ và chỉ cho phép truy cập HTTP / HTTPS thông qua máy chủ proxy.

Tôi rất ngạc nhiên khi biết bất kỳ tập đoàn nào cho phép kết nối trực tiếp từ máy tính để bàn hoặc máy chủ trừ khi có nhu cầu cụ thể.

Không có gì ngăn bạn chạy sshd từ xa của bạn trên cổng 80. Cả ssh và sshd đều có tùy chọn -p để đặt cổng.

Tất nhiên, nếu quản trị viên của bạn thông minh, họ nên xem lưu lượng ssh, không chỉ lưu lượng truy cập cổng 22. Vì vậy, có vẻ như bạn có một vấn đề chính sách, không phải là một vấn đề công nghệ.

Như những người khác đã chỉ ra, các giao thức được mã hóa có thể gây ra chứng ợ nóng ở những người phải lo lắng về các vấn đề tuân thủ.