tl,dr:
- 사용자에게는 자신과 동료가 SSH를 통해 액세스하는 홈 서버가 있습니다. 최근 동료들이 예상과 다른 SSH 키를 발견하면서 연결 문제를 경험하기 시작했습니다.
- 로컬 네트워크의 사용자에게는 NAT 루프백이 가능하기 때문에 이러한 문제가 발생하지 않습니다.
- 그들은 동료들이 예상한 OpenSSH가 아닌 Dropbear SSH 서버를 보고 있다는 사실을 발견했는데, 이는 모뎀/라우터가 간섭하고 있음을 시사합니다.
- ISP가 제공하는 모뎀/라우터 RTF8115VW에는 설정을 쉽게 조정할 수 없으므로 잠재적인 해킹/보안 침해 또는 구성 문제에 대한 불확실성이 있습니다.
- 사용자는 다음 단계에 대한 조언을 구합니다.
전체 내용:
집에 SSH(로컬 네트워크)를 통해 연결하는 서버가 있고 동료들도 내 IP를 통해 직접 SSH(인터넷)를 통해 해당 서버에 액세스합니다.
며칠 전, 동료들이 연결 문제를 겪기 시작했고, 터미널에서 공개 키가 동일하지 않다고 불평했습니다. 우리는 조사를 시작했습니다.
로컬 네트워크를 통해 접속할 때 서버에 직접 연결하면 서버가 보고하는 것과 동일한 지문이 로 시작되는 것을 발견했습니다 yury4. 외부 IP에 액세스하더라도 이런 일이 발생합니다. 모뎀/라우터가 일종의 NAT 루프백 변환을 수행하고 모든 것이 작동하는 것 같습니다. 하지만 동료에게 로 시작하는 다른 지문이 XyTk/지속적으로 표시되어 더 이상 연결할 수 없습니다.
조금 더 관찰한 결과 다른 SSH 서버인 Dropbear가 보고되는 것을 발견했습니다. 내가 본 것은 OpenSSH였습니다. 조사를 하면서 저는 Dropbear가 임베디드 시스템에 이상적이라는 사실을 발견했고, 이로 인해 모뎀/라우터를 의심하게 되었습니다. 빙고: 모뎀/라우터에 지문이 무엇인지 물어보면 로 시작하는 지문으로 응답합니다 XyTk/.
문제는 무슨 일이 일어나고 있는지 확인할 수 없다는 것입니다. 제가 기본적으로 이해하고 있는 것은 모뎀/라우터가 패킷을 망쳐서는 안 되며, 그냥 전달하면 된다는 것입니다. 그렇죠? 또한 문제를 해결하는 방법을 모르겠습니다. 모뎀/라우터는 액세스 공급자로부터 제공되며 일부 설정에는 액세스할 수 없는 것 같습니다. 사실, 이 작은 일이 침입을 당했는지, 중간자가 발생하고 있는지, 아니면 단지 구성 문제인지조차 알 수 없습니다.
다음 진단 단계는 무엇입니까?
편집: 장치는 RTF8115VW입니다.
답변1
원인을 찾는 것도 좋은 연구일 수 있습니다. 하지만 당신이 쓴 글을 보면 당신이 해킹당했을 가능성이 있다고 의심됩니다.
그렇다면 그러한 경우에 가장 먼저 해야 할 일은 무엇인지 자문해 보십시오.
- 잃을 것이 없다면 발견된 문제의 방법과 위치에 대한 훌륭한 법의학 및 조사를 수행할 수 있습니다.
- 중요한 것이 있다면 격리와 즉시 백업을 고려하되 기존 백업 미디어는 건드리지 않는 것이 좋습니다. — 최악의 경우는 현재 랜섬웨어가 자동으로 파일을 암호화하고 있으며 몇 시간 또는 며칠 후에 돈을 요구하는 팝업이 나타날 것이라는 점입니다.
- 그리 공격적이지 않은 시나리오는 라우터가 봇넷의 일부가 되어 악의적인 사람들이 손가락 끝으로 접근하여 다른 웹사이트에 불쾌한 작업을 수행할 수 있다는 것입니다.
해킹을 고려하는 이유는 무엇입니까?
첫 번째 주목할만한 힌트는 SSH 표준 포트를 인터넷 측으로 열었다는 것입니다.
내 의견: 올인원 라우터에서는절대로SSH 또는 기타 네트워크 서비스용 표준 포트에 이 작업을 수행합니다. – (이 라우터나 전달하는 서버 내에서) 구현 버그나 구성 버그가 있는 경우 해킹을 당할 수 있습니다. 적어도 표준 포트는 마치 끝없는 비처럼 전 세계적으로 밤낮으로 악당에 의해 지속적으로 완전 자동화되어 검사됩니다.문제는 정기적으로 작동한 후 얼마 후에 나타났습니다. 그렇다면 이 기능이 왜 변경되어야 할까요?
라우터의 SSH 데몬은 분명히 인터넷 측에 서비스를 제공하고 있습니다. (아니면 포트포워딩이 서버가 아니라 라우터에서 끝나네요. 그런데 왜일까요?) 갑자기 이런 현상이 발생했는데, 라우터의 SSH 포트를 활성화하는 방법도 모르시는군요.
귀하(및 귀하의 동료)가 아무 것도 변경하지 않았다고 말했듯이(확실합니까?) 다음 사항 중 하나를 고려해야 합니다.
- 라우터의 펌웨어 또는 구성 업데이트가 잘못되었을 수 있습니다.
- 인터넷 제공업체의 서비스 기술자가 무언가를 잘못 구성했습니다.
- 해킹이 발생했습니다.
나는 최악의 시나리오를 택할 것이며 그것이 거짓으로 판명되면 기뻐할 것입니다.
다음은 무엇입니까?
Dropbear가 실제로 라우터에서 호스팅되는지 다시 확인하세요. 이 진술의 진실 여부에 따라 전체 시나리오가 바뀔 수 있습니다.
만약 사실이라면:
나는 귀하의 라우터와 서버가 (적어도) 손상되고 승인되지 않은 누군가가 SSH 포트를 연 것으로 의심합니다.
정보를 수집하다
- 트래픽 분석을 수행할 수 있고 수행하고 싶다면 지금 수행한 다음 인터넷에서 시스템 연결을 끊으십시오.
- 특히 기능이 변경된 기간에 의심스러운 항목(그러나 조작되었을 수 있음)이 있는지 로그(라우터, 서버, 클라이언트)를 확인하십시오.
- 데이터와 설치를 확인하세요.
잠재적 위험 제거
맬웨어 검사기와 같은 일부 전문 도구를 참조하는 것이 좋습니다.
- 아직 완료되지 않은 경우 인터넷 연결을 끊습니다.
- 긴급 백업을 수행합니다(일반 백업 미디어를 사용하지 않고 오프라인으로 유지).
- 라우터를 재설정하고 펌웨어를 설치(재설치)하는 것이 좋습니다. 백도어에 대해 더 많은 것을 할 수는 없습니다.
라우터 구성을 복사할 수 있지만 "구성을 저장"하지 말고 재설정 후 "파일로 구성 복원"을 수행하지 마십시오. 원치 않는 설정을 다시 적용할 수도 있습니다. - 서버로 무엇을 해야 할지 생각해 보세요. 포트 포워딩을 통해 잠재적인 해커가 직접 접촉하여 먼저 해킹한 다음 전체 LAN을 손상시킬 수 있습니다.
- 귀하의 클라이언트(동료의 클라이언트 포함!)가 손상될 수 있는 위험에 대해 생각하고 결정하십시오.
재설정 후 고려해야 할 사항
- 개인 구성을 적용하기 전에 라우터에서 인터넷 측과 LAN 측에서 열려 있는 SSH 포트를 확인하세요. 이를 어떻게 활성화/비활성화할 수 있는지 알아보세요.
- 동료에게 외부 SSH 액세스가 필요한 경우 번호에 "22"를 사용하지 말고 일반적이지 않은 포트(10000~65535 사이)를 선택하는 것이 좋습니다.
- 무엇을 구성하고 있는지 확인하십시오. 그냥 행동하는 중"아 이제 되는구나"나쁜 생각입니다. — 시행착오가 남아있는 만큼 정확하게 정리하세요.
- LAN에서 인터넷에 액세스할 수 있는 서버를 격리하는 실제 방화벽에 대해 생각해 보십시오.
- 인터넷에 노출된 서버를 강화하세요
- 동적 DNS 공급자를 사용해야 하는 경우 라우터 제조업체에서 제공하는 서비스를 선택하지 마세요. 이는 특정 하드웨어 해킹을 위한 허니팟입니다.
- 해커의 데이터베이스 연결을 끊으려면 다른 DNS 이름을 선택하십시오. 고정된 외부 IP 주소가 있는 경우 가능하면 변경하도록 선택하세요.
답변2
문제는 무슨 일이 일어나고 있는지 확인할 수 없다는 것입니다. 제가 기본적으로 이해하고 있는 것은 모뎀/라우터가 패킷을 망쳐서는 안 되며, 그냥 전달하면 된다는 것입니다. 그렇죠?
글쎄요, 정확히는 아닙니다.
우선, 라우터가보통IP 수준 이상에서 패킷을 망칠 필요가 없습니다(IP TTL을 줄이는 것 제외). 일반 라우팅 외에도 NAT도 있으며 NAT는 L3(IP) 모두를 다시 작성하는 것과 관련되므로 말 그대로 "패킷 망하기" 형식입니다. 및 L4(TCP/UDP) 헤더. (그리고 이는 "NAT 도우미"라고도 불리는 ALG에 들어가기 전의 이야기입니다. 예를 들어 라우터는 실제로 FTP를 다시 작성합니다.명령과 응답NAT를 통해 작동하게 하려면…)
하지만 귀하의 경우에는 패킷을 망친 것이 아니라그것의 부족그로 인해 차이가 발생합니다.
외부에서 연결할 때는 외부에 연결된다는 점을 기억하세요.라우터의공용 IP 주소. "포트 리디렉션" 규칙이 활성화되면(기본적으로 DNAT) 라우터는 각 패킷을 전달하기 전에 각 패킷의 "대상 IP" 필드를 다시 작성하여 서버의 내부 IP 주소로 라우팅됩니다.
"포트 리디렉션" 규칙이 다음과 같은 경우~ 아니다활성 상태이지만 아무 것도 다시 작성되지 않습니다. 따라서 라우터의 IP 주소에 연결하면 실제로는 라우터에 연결되는 것입니다.
라우터가 자체 SSH 서버를 갖는 것은 매우 일반적인 현상입니다. 그러나 일반적으로 외부 연결은 1) 라우터의 일반 방화벽 규칙에 의해 거부되고 2) "포트 리디렉션" DNAT 규칙에 의해 무시되므로 라우터는 해당 연결을 인바운드로 간주하지도 않습니다. 그러나 귀하의 경우에는 해당 규칙 중 어느 것도 올바르게 작동하지 않는 것처럼 들립니다. DNAT 재작성이 발생하지 않습니다.그리고방화벽 필터가 인바운드 연결을 차단하지 않습니다.
따라서 추측해야 한다면(내부 "NAT 루프백"이 있다는 사실을 기반으로)하다작동하는 것처럼 보임) 일종의 구성 문제입니다. 아마도 ISP가 밤새 새 구성을 배포할 수도 있습니다. 이로 인해 필터와 NAT 규칙 모두가 "수신 인터페이스"와 다른 인터페이스를 예상하게 됩니다. (예를 들어 WAN 인터페이스는 eth0.3이지만 규칙에서는 WAN이 eth0.4일 것으로 예상합니다...)
- 라우터를 재부팅하거나 포트 리디렉션 규칙을 삭제하고 다시 추가한 후에 문제가 사라지는지 확인하세요.
- 평소와 다른 포트에 포트 리디렉션을 설정한 경우에도 문제가 발생하는지 확인하세요. (문제가 해결되지는 않습니다.
- 라우터는 ISP에 의해 잠겨 있으므로 실제로는 ISP의 문제입니다. 기술 지원팀에 전화해서 라우터 교체 등을 요청하세요.