해킹당한듯 합니다
글쓴이: 익명 사용자 / 작성시간: 토, 2011/06/11 - 11:12오후
ssh 가 해킹당한듯 합니다. 도움이 필요합니다.
ssh 클라이언트로 접속은 되지만, 접속할때마다 입력한 id/password가 서버 어딘가에 저장되고 메일을 통해 id/pw파일내용의 발송을 시도합니다. (현재는 메일발송을 막아놓은 상태가 실제로 발송되지는 않고 mail queue에 대기합니다)
id/password이 저장된 파일을 찾으려고 시도했지만 찾지 못했습니다. (혹시 찾는 방법이 있나요?)
아래에서 보시다시피, ssh 파일과 의심되는 shs 파일이 동일한 날짜입니다. ssh 설치 날짜와 다른 것으로 미루어 ssh가 변형되었다고 추측됩니다. root소유의 SetUID 파일 shs 프로그램이 문제를 일으키는 것으로 생각되는데요..
$ ll /usr/bin/ssh
-rwxr-xr-x 1 root root 196536 11월 23 2010 /usr/bin/ssh
$ ll /sbin/shs
-rwsr-sr-x 1 root root 8601 11월 23 2010 /sbin/shs
어떤 상황인지, 어떻게 해결해야 할 지 도움이 필요합니다.
Forums:
ssh이외에 어떤 파일들이 변조되었는지 파악하기
ssh이외에 어떤 파일들이 변조되었는지 파악하기 힘드니
네트워크 차단후 재구축 하는게 제일 안전하지 않을까 싶은데요.
재구축이 최선입니다만; 명확하게 규명할려면, 일단
재구축이 최선입니다만;
명확하게 규명할려면,
일단 어떤 프로세스가 그렇게 하는지 확인하시는게 좋을것 같습니다.
스크립트나 모니터링 툴로, ps aux 결과, netstat -anlpt 결과 등을 기록하게 해서, 프로세스를 추적하세요. pid만 나오다면 lsof 명령등으로 관련된 파일을 알수 있습니다.
프로세스 동작없이 무슨일을 하지는 못하니깐요.
접속할때마다라고 하셨으니, .profile이나 /etc/profile .bash_profile, inittab 등의 부트 스크립트나 로그인과 관련한 환경변수 스크립트가 숨겨져있을수 있습니다.
chkrootkit이나 rkhunter 같은 것을
chkrootkit이나 rkhunter 같은 것을 돌려 보시기 바랍니다. 이미 늦었기 때문에 파일 변조를 검증하는 것은 쉽지 않겠지만, key logger 같은 것은 찾을 수 있을 겁니다. 특히 lmk 같은 것이 있을 확률이 높을테니까요.
문제는 어떻게 뚫렸느냐를 확인하는 것이 가장 중요하기는 합니다만.. (rootkit에 의한 증상은 결과일 뿐이기 때문이죠.)
몇가지 분석..
1. 이진파일에서 text 만 읽어서 내용중에 의심갈만한게 있는지 보시구요
strings /usr/bin/ssh
strings /sbin/shs
2. os설치 재설치가 가장좋지만, 감염된 파일만 복구하려면 맞는배포판 가상os로 깔아서 그 파일만 복사하는것도 방법입니다.
3. 비번이 "1234asdf" 라면, 10일이내로 용량작은것들만 찾아볼수있겠네요
=> find / -type f -mtime -10 -size -5M -exec egrep -rH '1234asdf' {} \;
그외, 프로세스랑 네트웍상태열린포트 확인하는건 기본이고 그외에도 다양한 작업들이 필요하겠네요;;
우선 rpm 무결성 검사를 이용해 보세요. rpm
우선 rpm 무결성 검사를 이용해 보세요.
rpm -V openssh-server.
ps, netstat 명령이 변조 되었는지도 검사 해 보세요.
rpm 자체가 변조 되었을 경우도 있습니다.
정상 시스템의 rpm 명령의 해쉬값과 비교해 보세요.
해킹 피해를 당했을 경우 대처 절차에 대해 잘 모르시는 것 같아 정리해 봅니다.
1. 해킹을 인지했다면 ps, top, netstat, lsmod 등의 명령으로 실행중인 프로세스에 대한 정보를 기록합니다.
2. 피해 시스템을 shutdown 시킵니다.
3. 해킹을 당하지 않은 시스템으로 디스크를 옮겨서 dd 등의 명령으로 디스크 이미지를 덤프 합니다.
- 이때 원본은 별도로 잘 보관하고 덤프 이미지로 해킹 경로, 방법, 데이터 유출 여부 등을 확인합니다.
4. 시스템을 새로 설치 해서 서비스를 복구 합니다.
5. 사이버 수사대 또는 KISA 등에 신고하여 해킹경위, 기법등에 대해 분석을 요청 합니다.
6. 재발 방지를 위한 방안을 기획하고 조치를 취합니다.
물론 위의 내용은 원론적인 절차 입니다. 조직의 상황에 따라 위의 절차를 따를 수 없는 경우도 있을 겁니다.
하지만 해킹 사고에 놀라서 우선 복구먼저 시도하게 되면 더 큰 사고가 발생하게 될 겁니다.
댓글 달기