왜 포트 22 아웃 바운드를 차단해야합니까?

저는 프로그래머이고 포트 22에서 네트워크가 나가는 연결을 차단하는 일부 클라이언트에서 근무했습니다. 프로그래머가 종종 ssh에 포트 22를 사용해야한다는 점을 고려하면 이는 비생산적인 절차처럼 보입니다. 기껏해야 프로그래머가 회사에 3G 인터넷 요금을 청구하도록 강요합니다. 최악의 경우, 효과적으로 업무를 수행 할 수 없다는 의미입니다.

이것이 어려운 점을 감안할 때 숙련 된 sysadmin이 유실 조치처럼 보이는 것에 대한 이점을 설명해 주시겠습니까?

SSH 포트 포워딩에 대한 특정 위험을 자세히 알고있는 사람은 없습니다.

방화벽 내부에 있고 공용 인터넷의 머신에 대한 아웃 바운드 SSH 액세스 권한이있는 경우 해당 공용 시스템에 SSH를 사용하여 프로세스 중에 터널을 작성하여 공용 인터넷 사용자가 네트워크 내부의 시스템에 완전히 ssh 할 수 있습니다. 방화벽을 우회합니다.

fred가 데스크탑이고 barney가 회사의 중요한 서버이고 wilma가 공개 (fred)에서 실행중인 경우 :

ssh -R * : 9000 : barney : 22 윌마

그리고 로그인하면 공격자가 ssh가 wilma의 포트 9000에 접속하고 barney의 SSH 데몬과 통신 할 수 있습니다.

데이터는 원래 발신 방향으로 설정된 연결을 통과하기 때문에 방화벽은 들어오는 연결로 인식하지 않습니다.

성가 시지만 완전히 합법적 인 네트워크 보안 정책입니다.

포트의 엉망을 막고 일부 물건을 무작위로 차단하고 다른 물건을 임의로 차단하는 경우 (SSH를 차단하고 Telnet을 허용 한 사람들에 대한 Paul Tomblin의 슬픈 이야기를 좋아합니다.) 외부에서 네트워크 경계를 확보하거나 보안 정책을 제대로 파악하지 못하는 것 같습니다. 당신은 그런 상황을 이해할 수 없으므로 고통을 겪고 하루 종일 계속하는 사람들에게 요금을 부과하십시오.

포트를 통한 트래픽을 허용하는 특정 비즈니스 사례가없는 한 모든 포트를 차단 하는 경우 신중하게 관리되는 시점 에서 업무 수행 능력이 뛰어나므로 수행중인 것입니다.

보안 응용 프로그램을 작성하려고 할 때 다른 프로세스가 정보를 쉽게 읽고 쓸 수있게하거나 사람들이 전화를 걸고 조심스럽게 위생 처리 할 수 ​​있도록주의 깊게 문서화 된 API가 있습니까?

위험 관리-네트워크를 통한 인터넷 트래픽이 위험하다고 생각되면 경로 수와 방법 수 측면에서 트래픽이 인터넷에 도달 할 수있는 방법의 양을 최소화하려고합니다. 그런 다음 선택된 "복수"게이트웨이 및 포트를 모니터링하고 필터링하여 해당 트래픽이 예상되는 트래픽인지 확인하십시오.

이것은 "기본 거부"방화벽 정책이며 일반적으로 몇 가지 경고 사항이 있습니다. 의미하는 것은 차단을 해제해야 할 특별한 이유가없는 한 모든 것이 차단되고 그 이유의 이점이 위험보다 중요하다는 것입니다.

편집 : 나는 분명히 하나의 프로토콜이 허용되고 다른 프로토콜의 위험에 대해 이야기하는 것이 아니라 통제되지 않은 상태에서 네트워크로 들어 오거나 정보가 유출되는 정보 비즈니스에 대한 잠재적 위험에 대해 이야기하고 있습니다. 방법.

이제주의 사항과 가능한 것들을 자유롭게 계획하십시오.

당신이 무언가에서 차단되면 성 가실 수 있습니다. 방화벽을 담당하는 사람들은 "여기 위험이 있습니다. 이제 어떤 이점이 있습니까? 우리가 할 수있는 일을 보도록하십시오"대신 "아니오"라고 자신의 일을 생각합니다.

클라이언트의 네트워크 보안을 관리하는 사람과 대화 할 경우 고객을 위해 무언가를 설정해야 할 수 있습니다. 마지막에 액세스해야하는 특정 시스템을 식별하고 특정 IP 주소에서만 연결을 보장 할 수있는 경우 특정 조건에 대한 SSH 연결에 대한 방화벽 예외를 생성하는 것보다 훨씬 더 좋을 수 있습니다 인터넷 전체에 연결하는 것입니다. 또는 방화벽을 통해 터널링하는 데 사용할 수있는 VPN 기능이있을 수 있습니다.

로체스터 NY의 많은 대기업이 내가 그곳에서 일할 때 나가는 ssh를 차단했지만 telnet은 허용했습니다 ! 내가 그것에 대해 물었을 때, 그들은 ssh가 보안 구멍이라고 말했다.

다시 말해, 회사는 때때로 어리석은 결정을 한 다음 실수를 인정하기보다는 보안에 대한 변명을 변명합니다.

회사에서 외부 로그인을 허용하지 않는 경우 인바운드 SSH 통신 차단을 이해할 수 있습니다. 그러나 이것이 아웃 바운드 SSH 블록에 대해 처음 듣는 것입니다.

주목해야 할 것은 그러한 방화벽은 아마도 일반 SSH 사용자 만 제한한다는 것입니다. 누군가 외부에서 SSH를 원할 경우 (일반적으로 엔터프라이즈 네트워크 외부에서 상당한 액세스 권한을 가진 서버 / 컴퓨터에 연결됨) 22 이외의 포트 (예 : 포트 80)에서 SSH 서버를 쉽게 실행할 수 있습니다. 블록은 쉽게 우회됩니다.

HTTP (포트 80 또는 HTTPS 포트 443)를 통해 엔터프라이즈를 종료하고 외부의 포트 22에 연결할 수있는 프록시를 제공하는 여러 공개 도메인 도구도 있습니다.

편집 : 좋아, 잠깐만, 왜 이것이 정책 일 수 있는지에 대한 아이디어가 있습니다.

때때로 사람들은 SSH 터널을 사용하여 IM 및 Bittorrent와 같은 프로토콜에 대한 기본 아웃 바운드 방화벽을 우회합니다 (예 :). 이것은 // 그런 정책을 유발했을 수도 있습니다. 그러나 여전히 이러한 터널 도구 대부분이 22 이외의 포트에서 작동 할 수 있다고 생각합니다.

이러한 아웃 바운드 터널을 차단할 수있는 유일한 방법은 SSH 통신을 즉시 감지하고 이러한 TCP 연결을 (동적으로) 차단하는 것입니다.

규제 / 규정 준수 문제 일 수 있습니다. 고용주는 모든 대화 내용을 읽거나 보관할 수 있기를 원합니다. 이것은 종종 은행과 같은 산업에서 요구되는 사항입니다.

제 생각에는 아웃 바운드 포트 22를 차단해야하는 두 가지 주요 이유가 있습니다.

첫째, 사람들이 언급했듯이 SSH 포트 전달은 프록시로 사용되거나 다른 포트 및 서비스를 우회하여 그러한 트래픽이 허용되지 않는다는 IT 정책을 피할 수 있습니다.

둘째, 많은 악성 코드 / 봇넷은 종종 "보안"으로 간주되어 허용되기 때문에 포트 22를 사용합니다. 그런 다음 해당 포트에서 프로세스를 시작할 수 있으며 감염된 컴퓨터도 SSH 무차별 대입 공격을 시작할 수 있습니다.

필요한 경우가 아니면 모든 나가는 연결을 차단하는 경우가 많으며, 아무도 나가기 전에는 나가는 연결에 사용할 포트 22를 요청하지 않았습니다 (80, 433 등). 이 경우 솔루션은 IS / IT에 연락하여 예외 추가가 필요한 이유를 알려주는 것만 큼 간단합니다. 스테이션이 특정 호스트 또는 일반적으로 SSH 연결을 발신 할 수 있습니다.

때로는 사람들이이 기능을 사용하여 다른 컨트롤을 우회하기 위해 (링크를 통한 포트 전달을 통해) 프록시를 설정하는 방법으로 SSH를 사용할 수 있습니다. 이는 법적인 이유로 (내부자 거래 감지, 회사 또는 개인 데이터의 전송 감지 / 차단 등) 모든 회사의 의사 소통 / 모니터링이 필요한 일부 규제 산업 (예 : 은행) 또는 회사가있는 경우 매우 중요한 요소가 될 수 있습니다. 내부 유출로 인해 우발적으로 또는 기타 방식으로 영업 비밀이 유출되는 것을 두려워합니다. 이러한 경우, 3G 링크 (또는 HTTP를 통해 SSH를 터널링하는 등의 다른 기술)를 사용하여 제한을 우회하는 것은 계약 위반으로 인한 약탈 위반 (또는 아마도 더 나쁜 법적 위반) 일 수 있습니다. 시도하기 전에 행동에 동의하십시오.

또 다른 이유는 회사 실행 시스템에 자체적으로 설치하기 위해 관리 할 수없는 무언가가있을 경우 발신 발자국 (회사 방화벽 내의 호스트 및 일반적으로 세계에 액세스 할 수있는 내부 서비스로)을 줄이는 것입니다. 포트 22에서 SSH 연결이 가능하지 않은 경우 전파 경로 중 하나가 차단 될 때 무차별 SSH 로그인을 사용하는 많은 간단한 해킹이 발생합니다. 이 경우 방화벽을 제어하는 ​​사람들에게이 연결을 정당화 할 수있는 경우 시스템에서 SSH 연결을 수행 할 수 있도록 예외 추가를 다시 요청할 수 있습니다.

고객이 보유하고 싶은 사소한 데이터를 소유하고있을 수 있습니다. 아웃 바운드 SSH는 전체 네트워크에 대해 개방하기가 정말 나쁜 것입니다. 프록시를 우회하고 민감한 데이터를 유출하며 일반적으로 눈에 띄지 않는 것은 매우 사소한 일입니다.

IMO는 네트워크 / 인터넷 경계를 통과하는 모든 것을 이해하고 제어 할 수 있어야합니다. 개발자 그룹이 ssh를 통해 호스팅 제공 업체의 서버에 액세스해야하는 경우에는 문제가 없지만 문서화해야합니다. 일반적으로 내가 일한 곳에서 네트워크 외부 (본질적으로 내부 네트워크 확장)에 대한 사이트 간 VPN 전용 연결을 설정하고 인터넷을 통한 SSH와 같은 클라이언트 프로토콜을 피합니다.

SSH는 VPN으로 사용될 수 있기 때문입니다. 네트워크 관리자는 문자 그대로 네트워크를 떠나는 것이 무엇인지 (고객 데이터베이스의 덤프 등) 알지 못하도록 암호화되어 있습니다. 방금 월간 "비밀 터널" 열에서이 내용을 다뤘습니다 . 일부 3G 인터넷의 비용은 네트워크 외부로 데이터를 채널링하는 암호화 된 프로토콜에 대해 걱정할 필요가 없습니다. 또한 나가는 포트 22와 트래픽 검사를 기본적으로 차단하면 비표준 포트에서 SSH를 쉽게 찾을 수 있으므로 보안 정책을 위반하는 사람들을 찾을 수 있습니다.

SSH를 통해 SOCKS 프록시를 설치하기 위해 SSH의 기능을 악용하는 일부 사람들이 사이트 제한을 우회한다는 것을 알고 있습니다.

또는 ssh -L ....사이트 제한으로 인해 포트가 실제로 차단 된 경우 간단한 포트 전달 ( )도 있습니다.

• 로컬 관리자 및
• 프로젝트 관리자

그것들을 테이블로 가져 가서 이것이 차단 된 이유에 대해 자세히 설명하도록하십시오. 물론 내부 제품을 개발하기 위해 외부 SSH 포트에 액세스해야하는 적절한 이유가 있어야합니다 (내부 : 회사 snakeoil.invalid에서 작업 할 때 boxA.example.com에 액세스해야하는 이유).

그러나 나는 나가는 SSH를 차단하는 회사를 아직 보지 못했다 :)

명백한 답변이 모두 언급되었습니다. 터널 생성을 통해 정책을 우회하는 데 사용할 수있는 암호화 된 프로토콜 (회사 웹 필터를 통과하는 좋은 방법 임)과 무단 통신 채널 (역 프록시)로 인한 위협입니다.

텔넷은 모든 현대 네트워크에서 파괴되어야합니다. 그러나 ssh를 금지하면서 네트워크에서 텔넷을 허용하는 것을 볼 수 있습니다. Telnet은 ssh보다 기능이 적으며 항상 스니퍼를 통해 실시간으로 스트림을 모니터링 할 수 있습니다. 코어 네트워크에 텔넷 장치가없고 일부 사용자가 텔넷을 사용하려는 경우 어떻게해야합니까? 볼 수 있고 위협이 아닌지 확인합니다.

물론이 모든 것은 기본 정책이 모든 발신을 차단하고 특정 프로토콜 만 허용한다는 아이디어에 달려 있습니다. 당신이 가장자리에 충돌하기 전에 그들을 프록시 경우 보너스 포인트.

관리자가 SSH에 대해 문제가 있기 때문에 포트 22를 구체적으로 차단하는 경우는 아닙니다. 포트가 열려 있어야한다는 사실 만 알고 있습니다. 관리자에게 SSH가 열려 있어야한다는 메시지가 표시되지 않으면 관리자는 서버에서 사용하지 않는 서비스를 비활성화하는 것과 동일한 원칙으로 SSH를 차단합니다.

네트워크 관리자가 SSH 트래픽 을 구체적 으로 차단하기 위해 진지하고 진지한 노력을 기울이지 않는 한, 아웃 바운드 TCP / 22 블록은 우회하기 쉽습니다 . 또한 자산 관리자 는 3G 모뎀을 포착하기에 충분한 자산 인벤토리를 실행하고 두 번째 NIC에서 의심스러운 IP 주소를 충분히 확보 할 수 있어야합니다. 우리는 해당 지역에 ClearWire 서비스를 제공하므로 네트워크 보안에 대한 최종 실행 옵션으로 WiMax도 있습니다.

우리는 정보 유출에 주로 관심을 가지는 기관이 아닙니다. 그러나 만약 그렇다면, 감사와 함께 draconian 네트워크 보안 정책과 draconian 자산 정책을 결합해야합니다. 내가 아는 한, 기성품 보안 패키지가 존재한다고 생각하지 않습니다. 어떤 종류의 외부 네트워크 연결로 재고를 가진 자산의 네트워크 잭을 끌 것입니다. 다가올 수도 있습니다.

이러한 패키지가없는 경우 자산 인벤토리 프로세스는 3G 또는 WiMax와 같은 최종 네트워크 연결을 포착하는 가장 좋은 방법 중 하나입니다.

마지막으로, TCP / 22의 블라인드 차단은 업무용 네트워크에서 AUP를 위반하려는 최소한의 최종 사용자 만 차단합니다.

나는 사람들이 22를 통해 http 트래픽을 유도하고 있음을 발견했을 때 22가 차단되는 것을 보았습니다. 그것은 그것을 필요로했지만 조직이 자신의 입장을 고수 한 사람들에게는 쇼 스토퍼였습니다.

대부분의 대규모 조직은 모든 ​​것을 차단하고 프록시 서버를 통한 HTTP / HTTPS 액세스 만 허용합니다.

특별한 필요가없는 한 데스크탑이나 서버에서 직접 외부 연결을 허용하는 회사에 대해 매우 놀랐습니다.

포트 80에서 원격 sshd를 실행하는 것을 막을 수있는 것은 없습니다. ssh와 sshd 모두 -p 옵션을 사용하여 포트를 설정합니다.

물론 관리자가 똑똑하면 포트 22 트래픽뿐만 아니라 ssh 트래픽도 감시해야합니다. 따라서 기술적 인 문제가 아니라 정책 문제가있는 것 같습니다.

다른 사람들이 지적했듯이 암호화 된 프로토콜은 여러 규정 준수 문제에 대해 걱정 해야하는 사람들에게 가슴 앓이를 일으킬 수 있습니다.