[정보 보안 개론] 시스템 보안 (세션 관리, 접근 제어, 권한 관리, 로그 관리)

Jin_Hahha·2024년 10월 7일
0

정보 보안 개론

목록 보기
4/17

세션 관리

  • 세션이란?
    • 사용자와 시스템 사이 or 두 시스템 사이의 활성화된 접속
  • 클라이언트 측면에서의 세션
    • 기존의 작업을 진행하다가 잠깐 다른 작업을 마치고 돌아온 후, 해당 작업에 다시 진입할 수 있으면 세션 유지 성공
    • 기존 작업에 다시 진입할 수 없고, 새로운 작업을 시작해야 한다면 세션 유지 실패
  • 서버 입장의 세션 관리
    • 클라이언트의 세션이 유효한지 확인하기 위해 특정 인증 방식을 이용하는 것
      • 이를 세션 인증 과정이라고 함

  • 여러 상황에서 세션을 유지하는 작업은 중요
  • 세션을 적절히 유지하기 위한 보안 사항은 두 가지
    1. 세션 하이재킹(Session Hijacking), 네트워크 패킷 스니핑(Network Packet Sniffing)에 대응하기 위한 암호화
    2. 세션에 대한 지속적인 인증(Continuous Authentication)

  • 지속적인 인증이란?
    • 인증 절차를 거쳐 시스템 접근에 성공한 사용자가 있을 경우, 같은 아이디로 시스템에 접근하는 사용자가 처음 인증에 성공한 그 사용자인지 확인하기 위해 재인증을 수행하는 전반적인 과정을 말함
      • 그러나 명령어를 입력할 때마다 패스워드를 입력하도록 할 수는 없음
      • 시스템에서는 해당 문제를 세션 타임아웃 설정으로 보완
      • 예시로 화면 보호기가 있음

  • 단순 화면 보호기로는 지속적인 인증을 제공하지 못하지만, 따로 설정을 하여 세션이 유휴 시간을 가진 뒤 사용자가 재접속을 시도할 때 암호를 재입력하도록 만들 수 있음
    • 윈도우는 원격 접속에서도 화면 보호기를 통해 지속적인 인증을 제공
    • 유닉스는 원격 접속을 하더라도 패스워드를 다시 묻지 않고, 세션 종료 후 재접속을 할 것을 요구함
      • 유닉스에도 세션 타임아웃이 존재하지만 기본으로 설정되어 있지는 않음
      • 시스템마다 차이가 있으나 일반적으로 /etc/default/login이나 /etc/profile과 같이 사용자의 일반 환경을 설정하는 파일에서 타임아웃 값을 명시적으로 설정

  • 데이터베이스에서는 세션에 대한 타임아웃을 적용하지 않음
  • 데이터베이스는 사람이 접근하는 경우도 있지만 대부분 시스템 간의 세션을 가지고 있기 때문
  • 타임 아웃을 적용하면 시스템 간에 통신이 없을 때는 사람이 직접 다시 연결해 줘야 함

  • 시스템이 아닌 웹 서비스에서도 지속적인 인증이 적용됨
    • 인터넷 뱅킹을 할 때 공인 인증서의 패스워드나 보안 카드의 숫자를 반복해서 물어보는 경우
    • 시스템에서 패스워드를 변경할 때 원래의 패스워드를 물어보는 경우
    • 패스워드 기간이 만료되어 재설정을 요구하는 경우

접근 제어

  • 적절한 권한을 가진 인가자만 특정 시스템이나 정보에 접근할 수 있도록 통제하는 것
  • 시스템의 보안 수준을 갖추는 데 가장 기본적인 수단이 됨
  • 시스템 및 네트워크에 대한 접근 제어의 가장 기본적인 수단은 IP와 서비스 포트

운영체제의 접근 제어

  • 일반적인 운영체제에 대한 접근 제어 인식
    • 윈도우 운영체제 관리자
      • 터미널 서비스 접근 제어
    • 유닉스 운영체제 관리자
      • 텔넷, SSH 접근 제어
  • 위의 방식 모두 운영체제에 접근하는 가장 기본적인 방법
  • 해당 방식들만으로 운영체제 접근 제어를 수행할 수 있는 건 아님

  • 적절한 운영체제 접근 제어를 위해서는 운영체제에서 어떤 관리적 인터페이스가 운영되고 있는지 파악해야 함

  • 위의 표는 일반적으로 사용되는 관리 인터페이스를 윈도우와 유닉스로 나누어 정리한 것
  • 접근 가능한 인터페이스를 확인했으면 불필요한 인터페이스는 제거해야 함
    • 접근 제어를 수행할 부분을 최소화해야 효율적인 보안 정책을 적용할 수 있기 때문

  • 불필요한 인터페이스를 제거할 때는 사용할 인터페이스에 보안 정책을 적용할 수 있는지 판단해야 함
  • 유닉스의 텔넷은 암호화되지 않은 세션을 제공하여 스니핑과 세션 하이재킹 공격 등에 취약하기 때문에 사용을 권고하지 않음
  • FTP도 스니핑 공격에 취약, 아이디/패스워드를 뺏길 수 있음
  • 가능하면 SSH나 XDMCP를 사용하는 것이 좋음
    • XDMCP?
      • X Display Manager Control Protocol
      • X Display Manager라는 그래픽 형태의 로그인 관리자 사용
      • 사용자 A와 사용자 B가 X11을 사용할 때, 이 둘을 통합 시켜줌
      • 유효 사용자 아이디와 패스워드를 입력할 경우에 세션 시작
  • 윈도우의 경우, GUI 터미널 서비스는 운영체제의 버전에 따라 다른 수준의 암호화를 수행하므로 이를 고려하여 운영 환경에 적용해야 함

  • 운영체제에 대한 접근 목적의 인터페이스를 결정한 다음, 접근 제어 정책 적용
  • 시스템에 대한 접근 제어 정책은 IP를 이용하여 접근 제어
  • 유닉스의 텔넷, SSH, FTP 등은 TCPWrapper를 통해 접근 제어

  • TCPWrapper?
    • 리눅스, 유닉스 설치 시 기본적으로 사용가능한 호스트 기반 네트워킹 ACL 시스템
    • /etc/hosts.allow, /etc/hosts.deny 파일에서 설정
      • 특정 IP 주소 또는 대역에 대한 접근을 허용 또는 거부할 수 있음
      • default는 모든 접근 허용
      • allow 파일과 deny 파일 모두에 정보가 있다면, allow 파일 설정이 우선 적용
    • 동작 원리를 이해하려면 inetd라는 슈퍼데몬 개념을 이해해야 함
  • inetd 데몬?

    • 데몬이란, 운영체제에서 사용자가 직접 제어하지 않고 백그라운드에서 돌면서 여러 작업을 처리하는 프로그램을 의미

      • 윈도우의 서비스 같은 개념

      • 일반적으로 프로세스 형식으로 실행되면서, 데몬이라는 표시를 위해 뒤에 d가 붙음

      • 결론적으로 항상 백그라운드에서 동작하며 여러 서비스를 제공하는 프로그램을 의미

      • inetd 데몬은 유닉스 시스템에서 동작하는 슈퍼 서버 데몬으로, 인터넷 서비스 제공

      • 각 설정된 서비스들을 위해서 연결된 클라이언트로부터 요청을 리슨

      • 지금까지 조사한 바로는 inetd 데몬은 유닉스 운영체제를 최초 시작할 때부터 구동되는 것으로 예상되며, TCPWrapper를 설치할 때 동작하는 tcpd와 같은 여러 특수 데몬을 연동하여 같이 동작할 수 있는 듯

    • 클라이언트로부터 inetd가 관리하는 텔넷이나 SSH, FTP 등에 대한 연결 요청을 받은 후, 해당 데몬을 활성화하여 실제 서비스를 함으로써 데몬과 클라이언트의 요청을 연결하는 역할을 함

    • inetd 슈퍼데몬 외에 xinetd, systemctl 등이 유사한 기능으로 동작

  • 위의 이미지는 기본 inetd 데몬의 동작 과정을 나타냄

  • TCPWrapper가 설치되면 inetd 데몬은 TCPWrapper의 tcpd 데몬에 연결을 넘겨줌
  • tcpd 데몬은 접속을 요구한 클라이언트에 적절한 접근 권한이 있는지 확인한 후 해당 데몬에 연결을 넘겨주며, 이때 연결에 대한 로그를 실시할 수도 있음
    • tcpd도 데몬의 일종으로, hosts.allow와 hosts.deny를 참고하여 접근 제어 실행

  • 위의 이미지는 TCPWrapper를 통한 데몬의 동작 과정을 나타냄

  • XDMCP는 TCPWrapper의 통제를 받지 않기 때문에 별도의 접근 제어 설정 파일을 통해 클라이언트 IP에 대한 접근 제어를 설정해야 함
  • 윈도우에는 자체적으로 제공하는 접근 제어가 없기 때문에 IP 기반 접근 제어를 수행하려면 시스템에 설치된 방화벽 등을 통해 접근 제어를 수행해야 함

데이터베이스의 접근 제어

  • 데이터베이스는 조직의 영업 및 운영 정보를 담고 있는 핵심 응용 프로그램

  • 데이터베이스에 대한 적절한 접근 제어는 필수지만, 모든 데이터베이스가 적절한 접근 제어 수단을 제공하는 것은 아님

  • 오라클은 일정 수준 이상의 보안 정책을 적용할 수 있음

    • $ORACLE_HOME/network/admin/sqlnet.ora 파일에서 접근 제어 설정

    • 위의 이미지는 오라클 sqlnet.ora 파일의 기본 내용

    • 200.200.200.100과 200.200.200.200이라는 IP를 접근 허용하려면 다음 명령어를 추가

      tcp.invited_nodes=(200.200.200.100, 200.200.200.200)

    • 200.200.200.150의 접근을 차단하려면 아래의 명령어를 추가

      tcp.excluded_nodes=(200.200.200.150)

    • MySQL의 경우, 특정 IP와 계정에 대한 접근에 다음과 같이 권한 부여

      GRANT (권한) ON (데이터베이스).(테이블) TO (ID)@(IP주소) IDENTIFIED BY (패스워드)

  • MS-SQL은 IP 접근 제어를 기본으로 제공하지 않음

    • 윈도우의 다른 서비스와 같이 시스템에 설치된 방화벽을 통해 접근 제어를 수행해야 함
    • MS-SQL은 윈도우 인증 모드와 함께 윈도우 인증과 SQL 인증을 모두 사용할 수 있는 혼합 인증 모드도 지원

응용 프로그램의 접근 제어

  • 응용 프로그램의 목적과 역할에 따라 접근 제어를 제공하는 경우도 있고 그렇지 않은 경우도 있음
  • IIS와 NGINX 역시 IP 접근 제어를 제공
  • SSL(Secure Socket Layer)은 클라이언트와 서버 인증서를 이용하여 접근 제어 수행

  • NGINX 웹 사이트 설정 파일에서는 아래와 같이 접근 제어 수행

네트워크 장비의 접근 제어

  • 네트워크 장비도 IP에 대한 접근 제어가 가능
    • 관리 인터페이스에 대한 접근 제어와 ACL을 통한 네트워크 트래픽 접근 제어가 있음
    • 유닉스의 접근 제어와 거의 같고, ACL을 통한 제어는 방화벽에서 수행하는 접근 제어와 기본적으로 같음

권한 관리

운영체제 권한 관리

윈도우

  • NT 4.0 이후 버전부터 NTFS(New Technology File System)를 기본 파일 시스템으로 사용

  • 임의의 디렉터리에서 마우스 오른쪽 버튼을 눌러 (등록정보)-(보안)을 선택하면 권한 설정 화면이 나타남

  • 개별 사용자에 대해 설정할 수 있는 권한의 종류는 기본적으로 6가지

    1. 모든 권한: 디렉터리에 대한 접근 권한과 소유권 변경 가능, 하위에 있는 디렉터리와 파일 삭제 가능
    2. 수정: 디렉터리를 삭제할 수 있으며 읽기, 실행, 쓰기 권한이 주어진 것과 같음
    3. 읽기 및 실행: 읽기를 수행하고 디렉터리나 파일을 옮길 수 있음(해당 권한부터 삭제 불가능)
    4. 디렉터리 내용 보기: 디렉터리 내의 파일이나 디럭터리 이름을 볼 수 있음
    5. 읽기: 디렉터리의 내용을 읽기만 할 수 있음
    6. 쓰기: 해당 디렉터리에 하위 디렉터리와 파일을 생성하고 소유권이나 접근 권한의 설정 내용을 확인할 수 있음

  • 위의 여섯 가지 권한에는 3가지 규칙이 적용됨

    1. 접근 권한이 누적된다.
      : 개별 사용자가 여러 그룹에 속하면 특정 파일이나 디텍터리에 대한 접근 권한이 누적됨

      • 읽기 권한만 허용된 그룹과 쓰기 권한만 허용된 그룹이 있을 때, 두 그룹에 모두 속하는 사용자는 읽기와 쓰기 권한을 모두 가지게 됨

    2. 파일 접근 권한이 디렉터리 접근 권한보다 우선한다.
      : 파일을 포함하고 있는 디렉터리에 대한 접근 권한보다 파일에 대한 접근 권한이 우선한다는 의미

    3. '허용'보다 '거부'가 우선한다.
      : 유닉스와 달리 윈도우에서는 허용 권한 없음이 거부를 의미하지 않음

      • 윈도우에서는 허용과 거부 중 반드시 하나만 선택할 필요가 없으며, 권한이 중첩되어 적용되기 때문에 중첩되는 권한 중 명백한 거부가 설정되어 있으면 허용보다 거부가 우선 적용됨

  • 유닉스

    • 파일과 디렉터리에 대한 권한 설정 방법이 같음
    • 임의의 디렉터리에서 ls -al 명령으로 디렉터리의 내용 확인 가능
      • ls는 list의 약자, ls 명령은 윈도우의 dir 명령과 기능이 유사

    • 디렉터리에 있는 etc 항목의 상세 내용

      • 1번 항목은 파일의 종류와 권한을 나타냄
      • 2번 항목은 파일의 소유자를 나타냄
      • 3번 항목은 파일에 대한 그룹을 나타냄

    • 1번 항목은 다시 네 부분으로 세분할 수 있음

      • a 항목은 파일 및 디렉터리의 종류를 나타냄. -는 일반 파일, d는 디렉터리, l은 링크(link)를 나타냄
      • b 항목은 파일 및 디렉터리 소유자의 권한을 나타냄
      • c 항목은 파일 및 디렉터리 그룹의 권한을 나타냄
      • d 항목은 해당 파일 및 디렉터리의 소유자도 그룹도 아닌 제3의 사용자에 대한 권한을 나타냄

    • 위에 명시된 설명들로 보았을 때, etc 항목은 일반 파일이며, 소유자에 대해서는 읽기와 쓰기 권한을 허용한 상태이고 그룹에게는 쓰기 권한만, 일반 사용자에 대해서도 쓰기 권한만 허용해 주었다는 걸 알 수 있음

  • 유닉스에서는 파일 또는 디렉터리의 소유자, 그룹, 소유자도 그룹도 아닌 사용자로 구분하여 읽기(r, read), 쓰기(w, write), 실행(x, excute) 권한을 부여할 수 있음

    • 해당 권한들은 숫자로도 표기할 수 있으며, 읽기는 4 쓰기는 2, 실행은 1로 나타내어 각 권한 세트별로 합칠 수 있음

데이터베이스 권한 관리

  • 질의문에 대한 권한 관리

    • 데이터베이스 권한 괸리를 위해서는 DB의 질의문을 알아야 함

    • DDL과 DML은 DCL에 의해 허용 또는 거부됨

    • DCL에 의한 권한 부여와 회수 과정은 아래의 그림과 같음

  • 뷰에 대한 권한 관리

    • 뷰(View)는 데이터베이스에 대한 중요한 보안 사항 중 하나

    • 참조 테이블의 각 열에 대해 사용자의 권한을 설정하는 것이 불편해서 만든 가상 테이블

    • 회사의 연봉제를 예시로 들었을 때

      • 직원의 연봉 정보는 비밀로 유지하는 것이 중요

      • 직원 정보 테이블에 이름, 주소, 전화번호, 연봉 등의 정보가 저장되어 있다면, 특정 직책의 직원 외에는 연봉 정보에 대한 접근 권한을 모두 제한해야 함

      • 직원의 이름이나 전화번호를 검색하려는 직원에게도 모두 적용한다면 불편함이 따름

      • 이러한 경우에 뷰를 사용

      • 뷰가 없다면 직원에 대한 데이터베이스의 특정 항목 각각에 대해서 접근 제한을 설정해야 함

      • 대신 뷰가 있다면 특정 항목만이 담긴 뷰에만 접근 제어를 설정하면 됨

      • 뷰에 설정된 권한 제한은 테이블에 대한 설정과 같음

응용 프로그램의 권한 관리

  • 응용 프로그램마다 조금씩 다른 형태를 보임
  • 전반적으로 운영체제나 데이터베이스와 마찬가지로 관리자 계정과 일반 사용자 계정으로 나뉨
    • 관리자 계정과 일반 사용자 계정의 권한 관리도 중요하지만, 보안 관리자 입장에서는 응용 프로그램 내부의 권한 관리보다 응용 프로그램 자체에 대한 실행 권한이 더 중요한 경우가 있음

  • 모든 응용 프로그램은 운영체제에 존재하는 어떤 한 계정에 의해 실행됨
  • 응용 프로그램은 자신을 실행한 계정의 권한을 물려받음
  • 보안상 문제가 있는 취약한 응용 프로그램의 경우, 해당 프로그램을 실행한 계정의 권한이 악용되는 문제가 발생
    • 공격자가 응용 프로그램의 보안상 취약점을 이용하여 해당 프로세스의 권한을 얻을 수 있기 때문
      • 가장 흔한 예시는 아파치 같은 웹 서버 서비스가 root로 실행되는 경우, 공격자가 웹 취약점을 이용하여 root의 권한을 획득하는 것
      • 윈도우의 IIS에서는 실행 프로세스 권한을 별도로 만들어 사용하고, 유닉스는 nobody와 같은 제한된 계정 권한을 사용해야 함

로그 관리

  • 시스템 사용자가 로그인한 후 명령을 내리는 과정에 대한 시스템의 동작은 Authentication(인증), Authorization(인가), Accounting으로 구분
    • AAA로 부르기도 함

  • Authentication(인증)

    • 자신의 신원을 시스템에 증명하는 과정
      • 아이디와 패스워드를 입력하는 과정
    • 아이디는 신원을 나타냄, 패스워드가 정상이면 인증됨

  • Autorization(인가)

    • 지문이나 패스워드 등을 통해 로그인이 허락된 사용자로 판명되어 로그인하는 과정
    • 신원이 확인되어 인증받은 사람이 출입문에 들어가도록 허락하는 과정

  • Accounting

    • 로그인했을 때, 시스템이 해당 기록을 남기는 활동
    • 객체 또는 파일에 접근한 기록을 Accounting 정보라고 함

  • AAA는 모든 시스템에 존재

    • AAA 정보는 로그가 수행되는 대상
    • 로그를 남기는 모든 시스템에 존재
      • 일반 운영체제, 방화벽, 침입 탐지 시스템
    • 어떤 정보를 남길지는 AAA의 개념에 따라 판단

  • AAA에 대한 로그 정보는 해커를 추적하는 데 많은 도움이 됨
  • 책임 추적성
    • 추적에 대한 기록의 충실도
    • 책임 추적성이 높을수록 로그가 충실하게 남아 있다고 볼 수 있음
    • 시스템에만 해당되는 것이 아님
  • 감사 추적(audit trail)
    • 보안과 관련하여 시간대별 이벤트를 기록한 로그를 말함

운영체제 로그 관리

  • 윈도우와 유닉스는 상당히 다른 로그 체계를 지님
    • 윈도우는 이벤트라고 하는 중앙 집중화된 형태로 로그 수집
    • 유닉스는 로그를 여러 곳에 산발적으로 저장
      • 윈도우가 로그 관리 측면에서 더 편하지만, 공격자가 하나의 로그만 삭제하면 되기 때문에 위험도가 높음
      • 유닉스는 초보자가 로그를 찾기도 어려울 뿐 아니라 공격자도 로그를 모두 찾아서 삭제하기 쉽지 않음, 윈도우보다 공격자 찾기가 상대적으로 더 쉬움

윈도우의 로그

  • 윈도우 서버 2012의 로깅 항목과 설정 사항은 로컬 보안 정책 대화상자의 감사 정책 메뉴에서 확인할 수 있음

  • 윈도우의 감사 정책(로깅 정책)은 기본적으로 수행하지 않게 설정되어 있음

  • 정책이 필요한 경우에 수행하도록 설정해야 함

  • 설정 시, 성공과 실패에 따라 선택적으로 로깅 수행 가능

  • 이벤트 뷰어에서 로깅 정보 확인 가능

  • 개별 로그에서는 아래의 표와 같은 항목을 확인할 수 있음

  • 윈도우가 제공하는 각 감사 정책은 아래의 표에 제시한 사항을 로깅

  • 윈도우의 모든 이벤트 로그는 엑셀로 정리된 파일 형태로 내려받을 수 있음

유닉스의 로그

  • 윈도우와 다르게 유닉스(리눅스) 시스템 로그는 중앙 집중 형태로 관리되지 않고 분산되어 생성
  • 시스템마다 로그가 저장되는 위치가 다를 수 있으나 일반적인 위치는 아래와 같음
    • /usr/adm(초기 유닉스): 데이터베이스 객체에 권한 부여
    • /var/adm(최근 유닉스): 솔라리스, HP-UX 10.x 이후, IBM AIX
    • /var/log: FredBSD, 솔라리스(/var/adm과 나누어 저장), 리눅스
    • /var/run: 일부 리눅스
  • 일반적으로 리눅스에서는 /var/log 디렉터리에 로그가 존재함

  • 유닉스의 로그 종류는 다음과 같음

  • utmp

    • 유닉스 시스템의 가장 기본적인 로그
    • 로그인 계정 이름, 로그인 환경(initab id), 로그인 디바이스(console, tty 등), 로그인 셸의 프로세스 아이디, 로그인 계정의 형식, 로그오프 여부, 시간에 대한 저장 구조를 확인할 수 있음
    • utmp는 텍스트가 아닌 바이너리 형태로 로그를 저장
    • w, who, users, whodo, finger 등의 명령어로 로그를 확인할 수 잇음

  • wtmp

    • utmp 데몬가 비슷하게 사용자들의 로그인과 로그아웃, 시스템 재부팅에 대한 정보를 담고 있음
    • last 명령어를 통해 내용 확인 가능
    • 특정 항목의 내용만 확인하고 싶은 경우
      • last reboot, last console, last (계정명)과 같이 last 명령어 뒤에 확인하려는 항목을 추가하여 명령을 실행하면 됨

  • secure(sulog)

    • 페도라, CentOS, 레드햇 등의 리눅스는 secure 파일에 원격지 접속 로그와 su(Switch User), 사용자 생성 등과 같이 보안에 직접적으로 연관된 로그를 저장
    • 일반 유닉스에서 su 로그는 /var/adm/sulog 파일에 텍스트 형식으로 남음
    • 출력된 형식은 아래와 같음

      (날짜) (시간) (+, 성공 or -, 실패) (터미널 종류) (권한 변경 전 계정 - 변경 후 계정)

  • history

    • 명령 창에서 실행한 명령에 대한 기록은 history 명령으로 확인할 수 있음

  • syslog

    • 시스템 운영과 관련한 전반적인 로그
    • /var/log/messages 파일에 하드웨어의 구동, 서비스의 동작, 에러 등의 로그를 남김

데이터베이스 로그 관리

  • 데이터베이스는 일반적으로 로그인 이외에는 데이터베이스 접근 및 데이터 처리 로그를 남지 않음
  • 데이터베이스에 대한 접근 및 데이터 처리 로그는 데이터 유출과 직접적인 관련이 있기 때문에 시스템 성능이 수용할 수 있는 범위 내에서 적절하게 로깅 정책을 적용해야 함

MS-SQL의 로그

  • MS-SQL은 Microsoft SQL Server Management Studio에서 서버를 선택한 후, 속성 대화상자의 보안 메뉴에서 일반 로그인 감사, C2 감사 추적 등을 설정할 수 있음
    • 이때의 감사 수준은 기본 설정이 Failed logins only, 실패한 로그인에 한정
  • C2 감사 추적은 데이터베이스가 생성, 삭제, 변경되는지에 대한 자세한 정보를 로그로 남김
    • 빈번한 접속이 있는 데이터베이스의 경우 대량의 로그 생성 가능
    • 이러한 경우, 시스템에 무리를 주어 데이터베이스에 이상을 초래할 수 있으므로 반드시 필요한 상황이 아니면 사용을 권고하지 않음
    • 특정 데이터베이스의 특정 명령에 한해 윈도우의 이벤트 로그와 유사한 형태로 감사 로그를 남기도록 설정할 수 있음

MySQL 로그

  • MySQL은 다섯 가지 로그 제공

  • General 로그의 경우, 아래의 명령어를 통해 현재 설정을 확인할 수 있음

    show variables like 'general%';

  • General 로그는 아래의 명령어를 통해 설정 및 해제될 수 있음

    set global general_log = ON;
    set global general_log = OFF;

오라클 로그

  • 오라클에서 감사 로그를 활성화하려면 오라클 파라미터 파일을 수정해야 함

    • $ORACLE_HOME/dbs/init.ora의 AUDIT_TRAIL 값을 DB 또는 TRUE로 지정해야 함

    • AUDIT_TRAIL 설정 가능 값은 아래와 같음

      • NONE or FALSE: 데이터베이스 감사 비활성화
      • DB or TRUE: 데이터베이스 감사 활성화
      • OS: 감사 로그를 OS상의 파일로 저장, 경로명은 audit_file_dest에 의해 저장

    • AUDIT_TRAIL 값을 지정한 다음 아래의 항목 실행

      $ORACLE_HOME\rdbms\admin\cataudit.sql

    • 감사 로그가 활성화된 후 오라클에서 남길 수 있는 데이터베이스 감사의 종류

      • 문장 감사, 권한 감사, 객체 감사

      • 각 감사는 아래의 표화 같은 감사 뷰를 통해 확인할 수 있음

데이터베이스 모니터링

  • 데이터베이스에 대한 로그를 남기는 가장 좋은 방법은 별도의 모니터링 툴을 도입하는 것
    • 네트워크 트래픽을 모니터링 할 수 있는 tapping 장비를 네트워크에 설치
      • tapping 장비: 네트워크 상의 전기적 신호를 똑같이 복제하는 장비
    • 네트워크 패킷 중에서 데이터베이스 질의문을 확인하여 이를 로그로 기록
    • 이러한 로그 방식은 DB 성능에 영향을 주지 않으면서 잘못된 접근 시도와 질의문 입력을 모두 모니터링할 수 있다는 장점이 있음

응용 프로그램의 로그 관리

  • 침해 사고 분석에서 웹 로그 분석은 매우 중요
    • 그러나 웹 해킹이 일어나는 원리를 모르면 로그 분석 자체가 어려움
    • 웹 서버 로그를 분석하기 위해서는 웹 해킹에 대한 지식이 선행되어야 함
    • 웹 취약점 분석을 통해 어떤 형태의 로그가 남는지 확인하는 것도 좋은 방법

IIS 웹 서버의 로그

  • 제어판-관리 도구-IIS 관리자-IIS 대화상자의 로깅 항목에서 확인 가능

  • 로그는 IIS 웹 서버의 기본 설정이며 가장 널리 이용되는 W3C 확장 로그 파일 형식으로 설정되어 있음

    • 이 외에는 NCSA, IIS, 사용자 지정 방식 로그 파일 형식 사용 가능
    • 실제 로그는 위의 그림의 디렉터리에 아래와 같은 형태로 남음

  • 위의 로그는 다음과 같이 구성되어 있음

    • 날짜 및 시간: 2021-06-03 08:53:12
    • 서버 IP: 192.168.137.128
    • HTTP 접근 방법과 접근 URL: GET/XSS/GetCookie.asp?Cookie=~~~
    • 서버 포트: 80
    • 클라이언트 IP: 192.168.137.1
    • 클라이언트의 웹 브라우저: Mozilla/5.0+(compatible;+MSIE+9.0;~
    • 실행 결과 코드: 200
    • 서버에서 클라이언트로 전송한 데이터 크기: 0
    • 클라이언트에서 서버로 전송한 데이터 크기: 0
    • 처리 소요 시간: 255ms

아파치 웹 서버의 로그

  • 기본 접근 로그는 access_log에 기록

  • 형식은 combined로 지정

    • 기본 로그 형식이며, httpd.conf 파일에서 combined 형식의 LogFormat을 확인할 수 있음

  • LogFormat에서 설정된 combined 형식의 각 항목은 아래의 표와 같음

네트워크 장비의 로그 관리

  • 네트워크 장비는 대량의 트래픽이 생성되고, 트래픽이 일시적으로 존재했다가 사라지기 때문에 살펴볼 수 있는 로그가 다양하지 않음

  • 네트워크 장비에서 확인할 수 있는 로그의 종류

    • 네트워크 보안 시스템의 로그
      • 침입 차단 시스템, 침입 탐지 시스템, 침입 방지 시스템 등 보안 시스템의 로그 확인 가능
      • 통합 로그 관리 시스템(Security Information and Event Management, SIEM)에 의해 수집, 관리되기도 함
    • 네트워크 관리 시스템의 로그
      • 네트워크 트래픽 모니터링 시스템(MRTG)
      • 네트워크 관리 시스템(NMS)
      • 위의 두 시스템을 통해 로그 참고 가능
    • 네트워크 장비 인증 시스템의 로그
      • 대규모 네트워크를 운영하는 곳에서는 라우터나 스위치의 인증을 일원화하기 위해 인증 서버로 TACACS+(Terminal Access Controller Access-Control System Plus)를 사용하기도 함
      • 해당 인증 서버를 통해 네트워크 장비에 대한 인증 시도 및 로그인 정보 등을 확인할 수 있음

  • 기본적으로 라우터나 스위치에는 로그를 남기는 기능이 있음

  • 대부분의 네트워크 장비에는 하드디스크와 같이 로그를 저장할 공간이 없기 때문에 별도의 로그 서버를 운영하여 그곳에 기록함

  • 각 네트워크에서 생성된 로그는 네트워크를 통해 로그 서버로 전송

  • 단순히 네트워크 장비에 관한 로그를 남길 수 있다는 장점뿐만 아니라 네트워크 공격자의 공격에서 유리함을 얻을 수 있음

    • 공격자라 로그를 삭제하려면 로그 서버의 위치를 찾아야 하지만, 그러기 위해서는 로그 서버에 대한 해킹도 성공해야 한다는 전제가 생김
    • 즉, 어떠한 형태로든 네트워크 장비에 침입한 해커의 흔적이 남게 된다는 의미
    • 위의 장점으로 네트워크 장비뿐만 아니라 운영체제를 관리할 때에도 로그 서버를 따로 운영하기도 함
profile
Jin_Hahha
이전 포스트

[정보 보안 개론] 시스템 보안 (시스템 보안의 이해, 계정 관리)

다음 포스트

[정보 보안 개론] 시스템 보안 (취약점 관리, 모바일 보안-1)

0개의 댓글