2016-07-15 8 views
0

AWS에서 사용자 (시스템 관리자)는 로컬 방화벽 제한없이 SSH 터널링을 사용하여 내부 영역 DB 서버에 액세스 할 수 있습니다. 아시다시피 내부 노드에 액세스하려면 먼저 공용 영역 게이트웨이 서버를 통과해야합니다. 게이트웨이가 실제로 통로이기 때문에 게이트웨이 서버의 터널링 된 사용자의 트래픽을 제어하고 싶습니다. 예를 들어, 모든 클라이언트의 현재 연결된 IP 주소를 얻으려면 사용자가 액세스 한 내부 경로 (예 : DB 서버 IP)를 idendify하려면 권한이 부여되지 않은 사용자의 연결을 제어하고 싶습니다.AWS에서 ssh proxy + sshd로 액세스 제어

내 꿈을 실현하려면 아래 아이디어가 실제로 이상적이라고 생각합니다. 1) sshd 포트를 22가 아닌 다른 것으로 변경하십시오. sshd 데몬을 다시 시작하십시오. 2) sshd 이전에 ssh proxy (nginx, haproxy 또는 기타)를 찾아 프록시가 클라이언트로부터 모든 ssh 트래픽을 얻게하십시오. 3) ssh 프록시가 sshd에 트래픽을 라우팅합니다. 4) 그러면 ssh 프록시 로그를 분석하여 모든 사용자의 활동을 볼 수 있습니다. 그게 전부 야.

꿈이 가능한가?

답변

0

영리하지만 치명적인 결함이있는 경우 : 새로운 정보를 얻지 못할 수도 있습니다.

왜? SSH의 첫 번째 S : "안전합니다."

당신이 상상하는 "ssh 프록시"는 터널이 협상되는 곳인 SSH 연결 내부에서 일어나는 일에 대해 말할 수 없습니다. 연결은 물론 암호화되어 있으며 SSH의 중요한 점은 스 니프 될 수 없다는 것입니다. ssh 프록시가 동일한 시스템에 있다는 사실은 아무런 효과가 없습니다. 냄새를 맡을 수 있다면 안전하지 않을 것입니다.

모든 SSH 프록시는 클라이언트 컴퓨터에서 인바운드 연결이 이루어 졌다는 것을 알 수 있으며 syslog는 이미이를 알려줍니다.

실제 의미에서는 "ssh 프록시"가 아예 없습니다. 인바운드 연결에서 순진한 TCP 연결 프록시 일뿐입니다.

따라서이 방법으로는 새로운 정보를 습득 할 수 없습니다.

ssh 데몬 (아마도 openssh)이 연결하는 사용자가 설정 한 터널 연결을 기록하는 것이 필요한 것 같습니다.

볼 때 올바르지 않은 SSL 인증서를 우회해야 함)는 at Server Fault으로 언급되었으며 원하는 정보를 기록하기 위해 openssh 소스 코드를 간단히 수정 한 것으로 표시됩니다. who set 터널을 올라가고 어디로.

또는 enable some debug-level logging on sshd.

내게는 여분의 TCP 프록시가 불필요한 것처럼 보입니다. 실제 터널 (sshd)을 수행하는 프로세스가 필요하거나 수행해야하는 작업을 기록하기 만하면됩니다.