해킹관련, 이거 어떻게 해야 하나요?
pop3에서 특정 계정의 로그인이 계속 거부되어 서버를 이리 저리 살펴보았습니다. 그런데....
증상1: 쉘에서 segmentation fault가 계속 난다.
증상2: ssh로 접속하여 누군가 root권한으로 작업을 하고 있다.
증상3: perl ... 로 시작하는 프로세들이 십 수개 떠 있다. crond로 역시...수십개
증상4: chkrootkit으로 검사해본 결과 rpcinfo가 Infected로 나온다
대응1: 우선 root로 접속하고 있는 ip를 iptables를 이용하여 Input Output 채널에서 Drop시켰습니다. iptables -A INPUT -s 200.217.18.230 -j DROP , iptables -A OUTPUT -s 200.217.18.230 -j DROP
하지만 요 아이피에서 접속한 sshd프로세스는 계속 살아있더군요.
대응2: 그래서 그냥 의심되는 sshd프로세스를 강제로 죽였습니다.
하루 후....
다시 그 놈으로 추측되는 놈이 ip를 달리하여 ssh로 접속했습니다. 이 번에도 앞의 방법으로 우선은 접속을 끊었지요. 그리고 Infected로 나온 rpcinfo파일을 지우고 다른 서버에서 파일을 복사하여 붙여놓았습니다. 후후후 물론 그 놈은 이후에도 곧바로 다시 다른 아이피로 접속하였습니다. T.T
허허허.. 고수님들에게 질문 몇 가지.
1. 크랙커가 어느 통로로 침입했는지를 추적하려면 어디서 부터 시작해야 합니까? 모든 로그를 다 뒤질 수도 없고...
2. 떠 있는 프로세스 중 egrep도 있는 것으로 보아 아마 pop3 등에서 패스워드를 스니핑했을 듯 합니다. 이럴 경우 사용자들에게 모두 pass를 바꾸라 해야 하나요? 사용자가 한 30여명 되는데...
고수님들의 도움 부탁드립니다.
서버에 루트킷이 깔린 상태로 보입니다.루트킷을 제거하기 이전에는 어떤
서버에 루트킷이 깔린 상태로 보입니다.
루트킷을 제거하기 이전에는 어떤 대처를 하셔도 공격자가 접속하는 것을 막을 수 없습니다. 그냥 손쉽게 말하자면 현재 root 보다도 더 막강한 root 권한을 공격자가 갖고 있다고 생각하시면 되겠습니다.
서버 사용자가 30명 정도면 다른 곳들에 비해 상대적으로 적은 사용자로 보입니다. 이 사용자들의 패스워드를 일괄 변경하심이 좋습니다. 물론 그 와중에 다양한 피곤한 일이 발생하는 것을 각오해야 하는데... 답답한 일이죠.
물론 세부적인 상황에 따라 대응이 달라질 수 있습니다만, 다음과 같은 방법을 한번 생각해보심은 어떨지요?
1. 테스트 박스에 새로 OS 및 S/W 설치
2. 테스트 박스에 신규 보안 패치 및 보안 설정 강화
3. 테스트 박스로 사용자 계정 및 환경 설정 이전
4. 기존의 해킹당한 박스를 언플러그
5. 테스트 박스로 대체
심플해보이지만, 조직 내부의 정치적 상황에 따라 매우 피곤해질 수도 있습니다. 해킹에 대한 대처는 기술적인 측면도 중요하지만, 조직의 정치적 상황을 감안하는 것이 무엇보다 중요합니다.
기술적 대처만으로는 한계가 있어서 결국 유사한 문제가 되풀이 될 확률이 높아집니다.
----
LUX ET VERITAS | Just for Fun!
서버 자체를 교환하기는 좀... ^^;우선 log를 좀 뒤지다 발
서버 자체를 교환하기는 좀... ^^;
우선 log를 좀 뒤지다 발견하건데, 크랙커는 luci, luci2라는 계정을 만들었고, 그곳에 c4, kmod, wipe라는 파일을 만들어 두었습니다. 물론 모두 root로 되어있지요. kmod로 떠있는 것이 사실 rootkit 중에 하나였던 겁니다.
허허 이런 식으로 몰 어디다 또 만들어 두었는지...
---- m( @.@)m -----------
rpm -Va를 사용해 보세요..
rpm -Va를 사용해 보시면 변형된 파일을 확인하실수 있습니다.
변형된 파일을 지우고 다시 설치 하시면 되죠.
아니면 rpm 패키지를 가져다가 다시 설치를 하시던지요.
1. 무조건 새로 깝니다.2. 무조건 최신버젼으로 업데이트 합니다.
1. 무조건 새로 깝니다.
2. 무조건 최신버젼으로 업데이트 합니다.
3. 무조건 안쓰는 써비스는 내립니다.
( 안쓰는 서비스가 먼지 모르시면 업체에서 지원을 받으시거나 전문가를 고용해서 쓰십시오 )
4. 옴깁니다 -_-; ( 메일 데이터와 유저만.. )
5. 문제 전혀 없습니다 -_-;;
------------------------------------------------------------------------------------------------
Life is in 다즐링
음, 업데이트 & 서비스 제한 하는 방법은 알겠습니다.조언 고
음, 업데이트 & 서비스 제한 하는 방법은 알겠습니다.
조언 고맙습니다.
그런데 제가 알고 싶은 것은 크랙커가 어떤 경로로 들어왔는지입니다.
우선 제가 확인한 것은 secure Log에서 크랙커가 만든 유저와 그 유저의 폴더에서 발견한 rootkit 파일들입니다. 그 프로세스들을 모두 죽이고 유저를 삭제하고 root의 비밀번호를 바꾸고 의심되는 서비스들의 rpm을 업데이트하는 것 까지는 했습니다.
하지만 이 또한 크랙커가 들오온 경로를 추적하지 못한다면 결국 임시방편일 수밖에 없지 않나요?
---- m( @.@)m -----------
http//www.krcert.org/ 에 신고하시고, 관련 지원을 받
http//www.krcert.org/ 에 신고하시고, 관련 지원을 받는것도 방법일것 같습니다.
현재 서버가 서비스 되는 서버라면 우선은 복구하는게가장 우선이겠죠..
현재 서버가 서비스 되는 서버라면 우선은 복구하는게
가장 우선이겠죠...크래킹 당한 서버를 덤프 뜨셔서
보관하시고 새롭게 서버를 인스톨하셔서 복구하신다음
천천히 분석하는것이 순서라고 생각되네요...
때때로 로그만을 가지고 분석하기가 어려울때도
있습니다.
우선 자신이 사용하는 프로그램, 커널 버젼을 확인하시고
보안 버그가 있는 버젼은 아닌지...
또는 로컬 유저가 있다면 암호가 쉬운 사용자가 있지는
않은지...(외부에서 크래킹하는것과 내부로 들어와서
크래킹하는것은 천지차이입니다.)
그리고 로그에서 의심되는 부분을 하나씩 찾아나가야
할듯하네요...
by P.C.Harley
Re:
침입경로 알아내기가 실상을 제일 힘들죠 -_-;;
몇가지 경로가 있는데...
1. telnet 이나 ftp 같은 id/pw 가 plain text 로 날라다니는 프로토콜의 스니핑.
-> LAN 상에 같은 크래커에게 공격당해 뚫린 PC 가 있다는 가정하에 가능하죠.
2. 떠 있는 데몬의 버그.
-> 이 방법으로 의외로 많이 당합니다.
일단 한번 셋팅한 서버의 경우에는 데몬 역시 잘 업데이트 하지 않는게 일반적인데,
remote exploit 이 특정 데몬에 대해서 공개가 된다면,
크래커라고도 부르기 열받는 script-kid 에게도 당할 수 있죠.
해결법은 먼저 답글 단 분의 말씀대로 모든 데몬을 최신버젼으로 올리는 방법이
가장 무난합니다. 이런 경우에는 어떤 데몬의 버그를 이용했는지도
잘 파악하기 힘듭니다.
3. Local User
-> 의외로 많이 당합니다 -_-;
4. 웹 페이지의 논리적(?) 버그
-> 업로드 디렉토리에 스크립트 실행권한이 있다면,
그걸 이용해서 백도어를 생성해 낼 수 있습니다.
그 다음 local exploit 를 이용하면 root 가 떨어지죠.
제가 당해본 방법은 이 정도군요..
2 번 방법이 제일 많고... 그 다음이 1번, 3번, 4번 정도네요.
(4번은...딱 한번 당해봤네요. 제 실수인 셈이라 흔한 방법이라고 할수 없지만,
찾는데 꽤나 많이 고생했었네요.)
일단은 최대한 열린 포트의 갯수를 줄이는 것이 좋구요..
그리고 rpc 관련 데몬은 버그가 많은 편이니,
rpc 관련 서비스를 사용하지 않는다면 필히 내리세요.
(어짜피 rpc 관련 서비스라고 해도, 요새는 NFS 제외하면 쓰는것도 없죠.)
local exploit 의 경우에는, 완전히 불가능하게 막으려고 보면
시스템 전체를 다 갈아엎어야 하는 경우도 생기니...
remote exploit 이 가능한 데몬을 찾아서 막는게 훨씬 쉽습니다.
댓글 달기