저는 프로그래머이고 포트 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 연결을 수행 할 수 있도록 예외 추가를 다시 요청할 수 있습니다.
