rkhunter : 경고를 더 잘 처리하는 올바른 방법?


8

나는 몇 가지 구글을 검색하고 그것이 발견 된 첫 번째 링크 두 개를 체크 아웃했다.

  1. http://www.skullbox.net/rkhunter.php
  2. http://www.techerator.com/2011/07/how-to-detect-rootkits-in-linux-with-rkhunter/

그들은 그러한 경고가 발생할 경우 어떻게해야하는지 언급하지 않습니다.

Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable
Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The file properties have changed:
         File: /usr/bin/lynx
         Current hash: 95e81c36428c9d955e8915a7b551b1ffed2c3f28
         Stored hash : a46af7e4154a96d926a0f32790181eabf02c60a4

Q1 : 다른 종류의 경고를 처리하는 방법을 설명하는 확장 된 HowTo가 있습니까?

그리고 두 번째 질문입니다. 이러한 경고를 해결하기위한 조치가 충분 했습니까?

a) 의심스러운 파일을 포함하는 패키지를 찾으려면, 예를 들어 / bin / 파일의 debianutils입니다.

~ > dpkg -S /bin/which
debianutils: /bin/which

b) debianutils 패키지 체크섬을 확인하려면 :

~ > debsums debianutils
/bin/run-parts                                                                OK
/bin/tempfile                                                                 OK
/bin/which                                                                    OK
/sbin/installkernel                                                           OK
/usr/bin/savelog                                                              OK
/usr/sbin/add-shell                                                           OK
/usr/sbin/remove-shell                                                        OK
/usr/share/man/man1/which.1.gz                                                OK
/usr/share/man/man1/tempfile.1.gz                                             OK
/usr/share/man/man8/savelog.8.gz                                              OK
/usr/share/man/man8/add-shell.8.gz                                            OK
/usr/share/man/man8/remove-shell.8.gz                                         OK
/usr/share/man/man8/run-parts.8.gz                                            OK
/usr/share/man/man8/installkernel.8.gz                                        OK
/usr/share/man/fr/man1/which.1.gz                                             OK
/usr/share/man/fr/man1/tempfile.1.gz                                          OK
/usr/share/man/fr/man8/remove-shell.8.gz                                      OK
/usr/share/man/fr/man8/run-parts.8.gz                                         OK
/usr/share/man/fr/man8/savelog.8.gz                                           OK
/usr/share/man/fr/man8/add-shell.8.gz                                         OK
/usr/share/man/fr/man8/installkernel.8.gz                                     OK
/usr/share/doc/debianutils/copyright                                          OK
/usr/share/doc/debianutils/changelog.gz                                       OK
/usr/share/doc/debianutils/README.shells.gz                                   OK
/usr/share/debianutils/shells                                                 OK

c) /bin/which내가 보는 것처럼 긴장을 풀기 위해

/bin/which                                                                    OK

d)에 파일을 넣으려면 /bin/which/etc/rkhunter.conf등을SCRIPTWHITELIST="/bin/which"

e) /usr/bin/lynx체크섬을 업데이트 하는 파일에 대한 경고rkhunter --propupd /usr/bin/lynx.cur

Q2 : 이러한 경고를 올바르게 해결합니까?


US CERT-UNIX 또는 NT 시스템 손상 복구 단계 :In general, the only way to trust that a machine is free from backdoors and intruder modifications is to reinstall the operating system from the distribution media and install all of the security patches before connecting back to the network. We encourage you to restore your system using known clean binaries.
ignis

답변:


3

사용은 debsums하나의 주요 결함이 매우 영리한 아이디어 : 뭔가 루트 소유의 파일을 같은 덮어한다면 /bin/which, 그것은 또한 다시 /var/lib/dpkg/info/*.md5sums업데이트 된 체크섬과 함께. 내가 볼 수있는 한 데비안 / 우분투 서명으로 되 돌리는 양육권은 없습니다. 라이브 파일의 진위 여부를 확인하는 정말 간단하고 빠른 방법이기 때문에 부끄러운 일입니다.

실제로 파일을 확인하려면 해당 deb의 새로운 복사본을 다운로드하고 내부를 추출한 control.tar.gz다음 md5sums 파일을보고 실제 파일과 비교해야합니다 md5sum /bin/which. 고통스러운 과정입니다.

여기에서 가장 가능성이 높은 것은 시스템 업데이트 (배포 업그레이드도 포함)를 받았으며 rkhunter에게 프로필 업데이트를 요청하지 않았기 때문입니다. rkhunter는 시스템 업데이트로 인해 어떤 파일이되어야하는지 알아야합니다.

안전한 것이 확인되면 sudo rkhunter --propupd /bin/which파일 참조를 업데이트하기 위해 실행할 수 있습니다 .

이것은 rkhunter의 문제점 중 하나입니다. 신뢰할 수 있고 서명 된 패키지가 설치 될 때 rkhunter가 파일에 대한 참조를 업데이트 할 수 있도록 deb 프로세스에 긴밀하게 통합되어야합니다.


그리고 아니요, 루트킷이 뒤 따르는 종류이기 때문에 이와 같은 것을 허용하지 않습니다.


Oli에게 감사합니다. 귀하의 설명에 진심으로 감사하지만 실용적인 해결책이나 해결 방법을 선호합니다. 다른 현상금을 열고 있습니다. 필요한 것을 얻지 못하면 귀하의 답변에 현상금을 할당합니다. Ok?)
zuba

1

zuba, 화이트리스트 아이디어는 나쁜 아이디어입니다. 검사 할 파일을 할당 해제하여 사용자와 맬웨어 방지 프로그램에 표시해야하며 아이디어는 사용되지만 메시지를 보는 것은 무해합니다. 대신 쓰루 쓰루를 만들 수 있을까요? \로 시작하는 \ lines 행을 따라 어딘가에 무시됩니다. 그러나 그것은 rkhunter의 작업에 대한 코딩 경험과 친밀한 지식이 필요합니다.

bin은 프로그래밍 변경을 수용하기 위해 필요할 때 다시 작성됩니다. 일반적으로 하나의 파일이 교체되거나 재부팅 후 파일이 임시로 생성되어 변경되거나 사라질 수 있으며, 이는 rkhunter 소프트웨어를 속일 수 있습니다.

소프트웨어 / 업데이트 또는 맬웨어 방지 프로그램이 루트킷과 유사한 라인이 있는데, 이것들 중 하나라고 생각합니다.

컴퓨터 작동에 영향을 줄 수있는 프로그램이나 파일을 변경하는 경우에만 사용하는 방법이 위험합니다. 때때로 우리는 그런 점에서 우리의 기계보다 더 나쁩니다. 내가 그것을 할 수 있었기 때문에 귀하의 컴퓨터에 이것을 증명하는 것은 정말로 불공평합니다. 나는 경고와 체크섬을 문서화하고 변경이있을 때마다 메모 할 것이다.


1
예, / bin / whitelisting이 나쁜 생각이라는 것에 동의합니다
zuba
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.