사용자 행동 모니터링: bash history logging 공 방

Bash 는 * nix 세계 에서 가장 광범 위 하 게 사용 되 는 셸 이 라 고 할 수 있 는데 그 특성 중 하 나 는 역사 명령 (history) 체제 이다.이 기 제 는 주로 사용자 에 게 편 의 를 제공 하 는 데 사용 된다. - 키 보드 를 몇 번 덜 두 드 려 서 업무 효율 을 높 인 다.그러나 광범 위 하 게 토론 되 는 것 은 bashhistory 는 logging 체제 로 사용자 의 활동 을 감시 할 수 있 습 니 다.이 글 은 상기 문제 에 대해 토론 하고 왜 logging 체제 가 소수의 사람들 앞에서 효력 을 잃 는 지 설명 할 것 이다.history 파일 을 보호 하기 위 한 각종 방어 조치 가 어떻게 힘 들 이지 않 거나 조금 만 힘 들 이지 않 고 돌파 되 는 지 볼 수 있 을 것 이다.토론 이 진행 되면 서 돌파 의 한계 도 더욱 엄격 해 질 것 이다. 그러나 돌파 가 더 어 려 운 것 은 아니다. 반대로 대부분의 방법 은 머리 를 쓰 지 않 아 도 된다.마지막 으로 우 리 는 bash 의 소스 코드 를 수정 하여 '무적' logging 체 제 를 실현 할 것 이 며 '무적' 이 진정한 무적 이 아니 라 는 것 을 볼 수 있 을 것 이다.
보강 bashhistory
만약 당신 이 관리 하 는 시스템 이 셸 로그 인 기능 을 제공한다 고 가정 하면 사용자 중 일부 와 얄 미 운 녀석 들 이 있 기 때문에 당신 은 그의 활동 을 감시 하고 싶 습 니 다. 왜냐하면 당신 은 그 가 한밤중 에 당신 이 보호 하 는 CPU 와 시스템 자원 을 사용 하여 악의 적 인 행 위 를 하 는 것 을 매우 의심 하기 때 문 입 니 다 (또는 다른 것, 예 를 들 어 하 모 편 등).우 리 는 잠시 그 를 둘째 형 이 라 고 부른다.
모든 사용자 가 bash 를 기본 셸 로 사용 하기 때문에 bash 설정 파일 을 수정 하기 시작 합 니 다.
첫 번 째 단계: bash 기록 파일 과 관련 파일 을 삭제 하거나 수정 할 수 없습니다.
둘째 형 이 하 는 첫 번 째 일 은 history 에서/dev/null 까지 의 링크 를 만 드 는 것 입 니 다.

bob$ rm ~/.bash_history
bob$ ln -s /dev/null  ~/.bash_history

이 는 과거 기록 파일 을 수정 하여 추가 로 만 막 을 수 있 도록 다음 명령 을 수행 하여 속성 을 변경 할 수 있 습 니 다.

# chattr +a /home/bob/.bash_history

이것 은 파일 시스템 의 추가 속성 을 사용 하여 파일 을 추가 할 수 있 습 니 다. 대부분의 파일 시스템 은 이 기능 을 지원 합 니 다 (예 를 들 어 ext 2/3, XFS, JFS).FreeBSD 에서 실행 가능:

# sappnd /home/bob/.bash_history

셸 시작 과 관련 된 다른 파일 의 이 속성 도 수정 해 야 합 니 다:

# chattr +a /home/bob/.bash_profile
# chattr +a /home/bob/.bash_login
# chattr +a /home/bob/.profile
# chattr +a /home/bob/.bash_logout
# chattr +a /home/bob/.bashrc

앞의 세 파일 은 대화 식 bash 셸 (또는 비 대화 식 sehll 사용 – login 옵션) 호출 시 읽 힙 니 다 (전체 국 설정 파일/etc/profile 을 읽 은 후).bashrc 파일 은 non - login 대화 식 셸 이 호출 될 때 만 읽 힙 니 다.이것 은 둘째 형 이 시스템 에 등 록 된 후에 다음 과 같은 방법 으로 새로운 셸 을 호출 할 때:

bob$ bash

이 때. bashrc 파일 만 읽 히 고 위 에 열 거 된 세 개의 프로필 은 다시 읽 히 지 않 습 니 다.
상기 속성 을 수정 한 후에 더욱 진일보 한 '보강' 을 하 는 이른바 보호 조치 이다.
2 단계: 설정. bash * 프로필
모든 설정 은. bashrc 파일 을 대상 으로 합 니 다. 다른 세 개의 설정 파일 자체 가. bashrc 를 호출 하기 때 문 입 니 다. 즉,. bashrc 는 어떻게 든 읽 습 니 다.
그래서 모든 수정 사항 이. bashrc 에 대한 장점 은 둘째 형 이 로그 인 한 후에 새로운 bash 셸 을 수 동 으로 호출 하여 건 너 뛰 는 것 을 방지 할 수 있다 는 것 입 니 다. bashprofile,.bash_login,. profile 세 개의 프로필 에 적 용 된 설정 옵션 입 니 다. 다른 장점 은 이 세 개의 파일 자체 가. bashrc 를 호출 하기 때문에 시스템 에 처음 로그 인 할 때. bashrc 의 설정 도 적 용 됩 니 다.

# cat >> /home/bob/.bashrc << EOF
> shopt -s histappend
> readonly PROMPT_COMMAND=”history -a”
> EOF

이 곳 에서 histappend 옵션 은 bash 에 마지막 줄 $HISTSIZE 를 $HISTFILE 파일 (보통 ~/. bash history 파일) 에 추가 하 는 역할 을 합 니 다. 대화 식 셸 이 언제 종료 되 든 간 에.기본적으로 bash 는 매번 $HISTFILE 를 덮어 서 하나의 session 만 저장 할 수 있 도록 합 니 다.
환경 변수 PROMPTCOMMAND 는 우선 실 행 될 명령 을 저장 합 니 다. "history - a"명령 은 사용자 가 명령 을 실행 하기 전에 우선 실 행 됩 니 다. 현재 명령 앞 에 무엇 을 실행 하 든 즉시 $HISTFILE 에 추 가 됩 니 다. 전체 세 션 이 끝 날 때 까지 기다 리 지 않 고 과거 명령 을 메모리 에서 하 드 디스크 로 기록 합 니 다.
이 곳 의 readonly 역할 은 두 형 에 의 해 덮어 쓰 거나 직접 차단 되 지 않도록 변 수 를 수정 할 수 없습니다.
마지막 으로 완성 해 야 할 절 차 는 모든 것 과 bashhistory 와 관련 된 환경 변 수 는 모두 readonly 로 변 합 니 다.

readonly HISTFILE
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCMD
readonly HISTCONTROL
readonly HISTIGNORE

STEP 3: 시스템 의 모든 다른 셸 을 차단 합 니 다. 일반적으로 csh, tcsh, ksh 를 포함 합 니 다.

# chmod 750 csh
# chmod 750 tcsh
# chmod 750 ksh

이것 은 둘째 형 이 bash 셸 을 다른 셸 로 전환 하 는 것 을 막 을 것 이다.
지금 기민 한 관리 자 는 위 에 있 는 것 이 모두 shit 라 고 불평 할 것 이다!
또 하나의 셸 이 우리 의 통 제 를 벗 어 났 다!네가 상술 한 서술 을 다 보고 떠 오 르 는 생각 에 뛰 어 들 기 전에, 우리 가 몇 가지 일 을 똑똑히 알 아 보 자.
아주 오래 전... (알 잖 아) 원래는 Bourne shell 이나 sh 만 있 었 는데 지금 은/bin/sh 가 실제로/bin/bash 의 링크 입 니 다.Bash 가 호출 되 었 을 때 어떤 이름 으로 호출 되 었 는 지 확인 하고 이 를 통 해 sh 를 호출 했 는 지 판단 합 니 다. 과거 버 전의 sh 행 위 를 모방 하고 POSIX 기준 과 일치 하려 고 합 니 다.
대화 식 login 셸 이나 비 대화 식 셸 테이프 - login 옵션 으로 시작 하면/etc/profile 과 ~/profile 을 읽 고 설정 을 초기 화 합 니 다.대화 식 셸 로 호출 되면 $ENV 변 수 를 설명 하려 고 합 니 다. $ENV 가 비어 있 지 않 으 면 값 을 기본 설정 으로 사용 하고 실행 합 니 다.우 리 는 본문의 다음 절 에서 이 점 을 어떻게 이용 하여 bash 의 모든 설정 을 순식간에 죽 이 는 지 토론 할 것 이다.
3. logging 메커니즘 공략
이제 둘째 형의 입장 에서 모든 문 제 를 볼 때 가 되 었 다.우 리 는 위의 방어 가 어떻게 한 걸음 한 걸음 무 너 졌 는 지 검증 할 것 이다.실천 에서 의 가능성 은 무궁무진 하 다.
아래 언급 된 돌파 bashhistory logging 메커니즘 의 기 교 는 단지 구우일모 일 뿐이다.
방법 1: Bourne shell –/bin/sh 탈출 술 사용

$ /bin/sh

sh 를 호출 하면 bash 가 앞에서 말 한 역사 버 전 sh 를 모방 하여 bash 와 직접 연 결 된 설정 파일 을 읽 지 않 습 니 다.그래서 둘째 형 은 이제 $HISTFILE 변 수 를 피 할 수 있 게 되 었 습 니 다.
더 이상 readonly 가 아니 기 때문이다.

$ unset HISTFILE

이 변 수 를 제어 하 는 과거 명령 기록 파일 이 비어 있 기 때문에 logging 메커니즘 이 현재 세 션 에서 직접 위 축 됩 니 다.
주: 호출/bin/rbash (시스템 에 존재 한다 면) 를 통 해 같은 효 과 를 실현 할 수 있 습 니 다. 제 한 된 버 전의 bash 를 모방 할 수 있 습 니 다. sh 와 마찬가지 로 bash 의 링크 이기 도 하지만 사용 하기 에는 확실히 좀 아 픕 니 다.
방법 2: bash 가. bashrc 프로필 을 불 러 오지 않도록 합 니 다.
다음 과 같은 방법 으로 실현 할 수 있다.

$ /bin/bash –norc

이렇게 하면 bash 가. bashrc 를 읽 는 것 을 금지 하고 readonly 로 설 정 된 변 수 는 writeable 로 변 한 다음 아래 와 같이 할 수 있 습 니 다.

$ HISTFILE=

$HISTFILE 변 수 를 비 웁 니 다 -> 과거 기록 이 없습니다.
4: 해 킹 bash - syslog 로그 인터페이스 사용
이상 에서 우 리 는 명확 하 게 결론 을 내 렸 다 - 전통 적 인 보강 bashhistory 의 방법 은 사실상 모두 허튼소리 다.그러나 우 리 는 한 걸음 더 나 아 갈 수 있 는 hack bash 자체 로 logging 체제 의 취약 성 을 줄 이 고 은밀 성 을 높 일 수 있 습 니 다.주의해 야 할 것 은 그래도 무 너 질 수 있다 는 것 이다.bash 와 커 널 의 차이 로 인해 로 깅 장치 로 서 충분 한 건장 함 이 아 닙 니 다. 설령 hack 이 핵심 이 라 하 더 라 도.
현재 생각 은 bash 소스 코드 를 수정 하여 사용자 가 입력 한 모든 명령 을 syslog 에 보 내 고 syslog 에서 로 그 를/var/log 디 렉 터 리 에 기록 하 는 것 입 니 다.우 리 는 이 목 표를 실현 하기 위해 빠 르 고 노 랗 고 폭력 적 인 방법 을 제공 할 것 입 니 다. - 여기 서 어떤 사용자 가 입력 한 명령 은 차별 없 이 대 접 받 을 것 입 니 다. 이것 도 실현 할 수 있 습 니 다.
우리 인터페이스의 가장 좋 은 배치 점 은 parse. y 파일 입 니 다. bash 의 Ycc 문법 으로 구성 되 어 있 습 니 다.셸 에서 명령 이 떨 어 지면 bash 해석 기 가 빠르게 호출 됩 니 다.따라서 syslog 갈 고 리 를 해석 기 가 작업 을 마치 기 전에 놓 는 것 이 좋 은 방법 인 것 같다.수정 해 야 할 것 은 두 줄 의 코드 만 추가 하 는 것 입 니 다. syslog. h 와 syslog 호출 설정 을 포함 합 니 다.우 리 는 bash - 3.2 의 소스 코드 를 사용 했다.

[ithilgore@fitz]$diff -E -b -c ~/bash-3.2/parse.y ~/hacked_bash/parse.y
*** ../../bash-3.2/bash-3.2/parse.y     Tue Sep 19 13:37:21 2006
— parse.y     Sat Jul 12 18:32:26 2008
***************
*** 19,24 ****
— 19,25 —-
Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA. */
%{
+ #include  #include “config.h” #include “bashtypes.h” *************** *** 1979,1984 **** — 1980,1986 —- shell_input_line_len = i;             /* == strlen (shell_input_line) */ set_line_mbstate (); +         syslog(LOG_LOCAL0 | LOG_CRIT, “%s”, shell_input_line); #if defined (HISTORY) if (remember_on_history && shell_input_line && shell_input_line[0])

위의 호출 에 로그 메시지 가 생 겼 습 니 다. 이 메 시 지 는 syslog 에 의 해 LOGCRIT 단 계 는 local 0 장치 에 보 냅 니 다.이 동쪽 을 적용 하려 면/etc/syslog. conf 설정 파일 에 하 나 를 추가 해 야 합 니 다:

local0.crit                /var/log/hist.log

이로써 사용자 가 내 린 모든 명령 은/var/log/hist. log 에 누 워 있 습 니 다. 이 로그 파일 은 일반적으로 루트 사용자 가 읽 을 수 있 는 권한 이 있 습 니 다.
주의해 야 할 것 은 위 에서 언급 한 hack 는 서로 다른 사용자 의 입력 여 부 를 구분 하지 않 습 니 다.이 루 려 면 더 해 야 할 일이 많다.모든 명령 이 기록 되 어 있 기 때문에 셸 스 크 립 트 가 실행 되 거나 bash 를 시작 할 때 설정 파일 이 실 행 될 때 발생 하 는 스 팸 정보 도 기 록 됩 니 다.
지금 유일 하 게 남 은 문 제 는 '위의 hack 는 어떻게 해 야 뚫 릴 수 있 습 니까?'사실 이것 은 상당히 간단 하 다.
-> 깨끗 한 bash 나 다른 셸 을 컴 파일 하거나 업로드 하면 됩 니 다.
위의 hack 는 특정 버 전의 기초 위 에 있 기 때문에 컴 파일 하거나 업로드 한 깨끗 한 bash 는 그의 시스템 에서 실 패 될 수 있 습 니 다.
총화
Bash 는 하나의 셸 일 뿐 logging 장치 가 아니 라 bashhistory 는 사용자 에 게 편리 함 을 제공 하고 키 보드 를 몇 번 덜 두 드 리 는 데 사 용 될 뿐이다.감시 장치 로 사용 하 는 모든 방법 이 헛 된 것 이 라 고 한 마디 도 강요 하지 않 았 다.만약 에 실제 시스템 관리자 이 고 사용자 의 활동 을 감시 해 야 한다 면 커 널 모듈 을 써 서 모든 사용자 의 키보드 기록 을 기록 하고 uid 나 다른 매개 변수 에 따라 걸 러 냅 니 다.이 방법 은 매우 효과 가 있 고 무 너 지기 어 려 울 것 이다.
현재 리 눅 스 는 FreeBSD 를 포함 한 감사 프레임 워 크 를 선택 할 수 있 습 니 다.FreeBSD 플랫폼 에서 Robert Watson 과 TrustedBSD 프로젝트 가 개발 한 감사 프레임 워 크 는 선택의 하나 다.