[Section 01] 시스템 기본 학습 (62 ~ 85pg)

 [04 UNIX/Linux 서버 보안] 

 (1) 시스템 보안 

사용자의 패스워드 관리

• 개요
  • 패스워드 저장 정책에는 passwd 파일 내 계정 정보와 함께 저장되는 일반 패스워드 정책과 shadow 파일에 패스워드를 별도로 저장하는 shadow 패스워드 정책이 있다.
  • shadow 파일은 root만이 접근할 수 있도록 제한한다.
• /etc/passwd 파일
  • home_directory: 홈디렉터리, 로그인에 성공한 후에 사용자가 위치할 홈디렉터리로 관리자 계정은 root 디렉터리를 사용하며 일반 사용자는 /home 디렉터리 하위에 위치한다.
  • login_shell : 로그인 쉘, 리눅스의 경우 기본 쉘로 bash쉘을 사용한다. 로그인이 불필요한 계정에 대해서는 로그인을 금지하는 것이 보안상 안전하다. 해당 계정의 로그인 쉘을 "/sbin/nologin"또는 "/bin/false"로 설정한다.
• /etc/shadow 파일
  • 패스워드를 암호화하여 저장한 파일이다. 관리자만이 읽을 수 있다
  • shadow 파일에는 계정별 암호화된 패스워드 정보와 패스워드 에이징 정보가 저장되어 있다. 패스워드 에이징 정보는 시간의 흐름에 따른 패스워드 관리 정책을 말한다.
  • 파일 형식 : user_account : encrypted_password : last_change : minlife : maxlife(90일 권장) : warn : inactive(패스워드가 만료된 이후 계정이 잠기기 전까지 비활성 일수, 유닉스는 마지막 로그인 이후 해당 비활성 일수동안 로그인을 하지 않으면 계정을 잠근다는 의미) : expires
  • encrypted_password 필드 : $ID:$Salt$encrypted_password 형식으로 구성
    • ID는 해시 알고리즘을 식별하기 위한 것이고 최근에는 SHA-256이상의 해시 알고리즘이 권장된다.
    • 솔트는 패스워드 암호화 강도를 높이기 위한 임의의 값으로 사용자가 지정한 패스워드에 서로 다른 솔트를 추가하여 암호화된 패스워드를 생성한다. 따라서 같은 패스워드를 사용하더라도 다른 솔트에 의해서 암호화된 패스워드 값이 다른 것을 확인할 수 있다.
    • 솔트를 통해 레인보우 테이블 공격에 효과적으로 대응할 수 있다. 그 이유는 레인보우 테이블 공격을 통해 암호화된 패스워드를 알아낸다고 해도 실제 패스워드가 아니기 때문이다. 따라서 크랙된 평문 패스워드로 로그인을 시도하면 패스워드 검증시 입력한 패스워드에 솔트를 조합한 해시값을 비교하기 때문에 로그인에 실패하게 된다.
    • encrypted_password 필드에 기호가 설정되거나 빈 값으로 남아있는 경우가 있다.
      * : 패스워드가 잠긴 상태로 패스워드 로그인은 불가능하지만 별도의 인증방식을 사용하여 로그인 가능
      !! : 패스워드가 잠긴 상태로 모든 로그인이 불간으하다. 기본적으로 사용자 계정을 생성하고 패스워드를 설정하지 않으면 !! 상태로 되어 있다.
      빈값 : 패스워드가 설정되지 않은 상태이다. 패스워드가 설정되어 있지 않으면 패스워드 없이 로그인이 가능하기 때문에 반드시 패스워드를 설정해야 한다.
    • 패스워드 잠금 설정 명령 : passwd -l, 해제 명령 : passwd -u 
    • 패스워드 저장 정책 변경 명령 : pwconv : shadow 파일에 저장, pwunconv : passwd 파일에 저장
• 프로세스 실행권한(SUID, SGID)
  • RUID(real) : 프로세스를 실행시킨 사용자의 UID
  • RGID(real) : 프로세스를 실행시킨 사용자의 GID
  • EUID(effective) : 프로세스가 실행중인 동안에만 부여되는 UID로 자원 접근권한을 판단하기 위한 UID
  • EGID(effective) : 프로세스가 실행중인 동안에만 부여되는 GID로 ...
  • SUID, SGID는 프로세스가 실행중인 동안에 일시적으로 해당 실행파일의 소유자, 소유그룹의 권한으로 자원에 접근할 수 있도록 하는 권한설정이다.
    • SUID, SGID가 설정되지 않은 프로세스를 실행시키면 RUID와 EUID, RGID와 EGID가 동일하게 설정된다. 즉 플세스를 실행시킨 사용자의 UID로 설정이 된다. 따라서 실행시킨 사용자의 권한으로 자원에 접근하다.
    • SUID, SGID가 설정된 프로세스를 실행시키면 RUID와 RGID는 실행시킨 사용자의 UID, GID로 설정되고 EUID와 EGID는 실행파일의 소유자의 UID로 설정된다. 따라서 실행시킨 사용자와는 무관하게 프로세스가 실행중인 동안에는 실행파일 소유자의 권한으로 자원에 접근하게 된다.
  • 특수 권한 비트 설정 : 4(suid) 2(sgid) 1(sticky-bit)
    ex) chmod 2755 a.out = chmod g+s a.out : 755 접근권한 a.out 파일에 sgid 설정
  • 만약 root 소유의 자원에 대해 일반 사용자의 직접 접근을 차단하면서 기능상 필요한 부분만을 접근하도록 허용할 필요가 있는 경우 별도의 root 소유 프로그램을 통해 SUID, SGID를 설정하여 사용하는 것이 보안적인 측면과 운영적인 측면에서 매우 효율적이다. 다만 root 권한이 필요 없는 프로그램에 소유주가 root로 되어 있으면서 setuid가 설정된 경우는 보안상으로 매우 취약한다. 이런 이유로 관리자는 주기적으로 SUID, SGID가 설정된 프로그램을 확인할 필요가 있다.
  • find . -user root -perm -4000/-2000으로 SUID 혹은 SGID 설정이 포함된 파일을 검사할 수 있다.
  • 제거 명령어 : chmod -s 실행파일명, -s 옵션을 이용하면 suid랑 sgid 권한을 모두 제거한다.
• 디렉터리 접근권한(sticky-bit)
  
  1. 일반적으로 공유 디렉터리(/tmp, /var/tmp등)은 모든 사용자가 이용할 수 있도록 user, group, other에 rwx 권한을 부여한다. 문제는 다른 사용자가 만든 파일을 누구나 삭제 또는 파일명 변경을 할 수 있다는 것이다. 따라서 자유롭게 파일을 생성하되 파일 삭제나 파일명 변경은 소유자만이 가능하도록 할 필요가 있는데 이러한 목적으로 사용되는 특수권한비트가 sticky-bit이다.
  2. sticky-bit 가 설정된 디렉터리는 시스템에 있는 모든 사용자들이 자유롭게 파일/디렉터리를 생성할 수 있지만 파일 삭제 및 파일명 변경은 소유자 또는 root만 가능하다.
  3. 스티키 비트 설정 : chmod 1777 /tmp
  4. 유닉스의 경우 user에 지정해야 하는데 리눅스는 o(other)+t로 지정한다.

 (2) 네트워크 보안 

보안 쉘(SSH)

• 개요
  1. 보안 쉘이란 암호 통신을 이용하여 네트워크상의 다른 컴퓨터에 접속하여 원격으로 명령을 실행하거나 파일을 조작하는 응용 프로그램 또는 프로토콜을 의미한다.
     • 암호화된 원격 터미널 서비스 제공
     • 암호화된 파일 송수신 서비스 제공
  2. 기존의 rsh, rlogin, telnet, ftp 등 평문 송수신 서비스의 취약점을 대체하기 위해 설계되었으며 디폴트로 22/tcp 포트를 사용한다.

슈퍼 서버(inetd 데몬)

• 개요
  1. 네트워크 서버/클라이언트 구조에서 다양한 서비스의 서버 프로세스(데몬) 동작방식은 공통점이 존재한다. 실제 서비스를 제공하는 서비스 프로세스를 제외하고는 클라이언트의 접속 요청이 있을 때까지 대기하다가 요청이 들어오면 해당 요청을 처리할 서비스 프로세스(자식 프로세스)를 실행하는 형태이다.
  2. 따라서 효율적인 서버 자원의 활용이라는 측면에서 공통적인 부분을 처리하는 슈퍼데몬(데몬의 데몬 프로세스라는 의미)을 만들어 개별 서비스를 등록하게 하여 클라이언트 요청은 슈퍼 데몬이 모두 처리하고 개별 서비스를 호출해주는 방식을 생각해볼 수 있는데 이러한 방식이 바로 슈퍼 데몬(inetd 데몬) 방식이다.
     • Stand-Alone 방식 : 개별 서비스별로 서버 프로세스(데몬)이 동작하는 방식으로 속도가 빠른 장점이 있지만 서버 리소스도 많이 점유하고 있는 단점이 있다.
     • inetd(xinetd) 방식 : 슈퍼 데몬을 이용하여 개별 서비스를 동작시키는 방식으로 상대적으로 속도가 느리지만 서버 리소스를 절약할 수 있다.
  3. inetd 데몬은 N개의 개별 서버를 하나로 통합하여 클라이언트로부터 서비스 요청이 올 때마다 해당 서비스에 관련된 실행 모듈(FTP, Telnet, SSH 등)을 실행해준다.
  4. inetd 데몬은 최초 실행 시 /etc/inetd.conf 파일의 정보를 참조하여 서비스할 프로그램들에 대한 정보를 얻는다. 시스템 관리자는 inetd 데몬으로 서비스할 프로그램의 특징을 /etc/inet.conf 파일에 정의해야 한다.
  5. TCP Wrapper 서비스(tcpd 서비스)와 연동하여 서비스별 호스트 접근제어를 수행할 수 있다.
  6. 리눅스 시스템의 경우 xinetd 데몬을 주로 사용한다. 이는 inetd에서 보안과 리소스 관리 등을 향상시킨 것이며 기능상 큰 차이는 없다.
• inetd.conf 파일의 구조
  • 파일의 구조 
    1. 서비스명 : inetd 데몬은 /etc/services 파일에 등록된 포트번호를 참조하여 서비스할 프로세스의 포트를 결정한다. /etc/inetd.conf와 /etc/services 파일은 서비스명을 인덱스로 하여 해당 서비스의 정보를 서로 연계한다.
    2. 소켓 타입 : 해당 서비스에 대한 소켓유형을 설정한다. TCP 기반 서비스는 stream을 사용하고 UDP 기반 서비스는 datagram을 사용한다.
    3. 프로토콜 : /etc/protocols 파일에 주어진 프로토콜 중 사용가능한 프로토콜을 설정한다. 또한 /etc/services 파일에 설정한 프로토콜과 일치해야 한다.
    4. 플래그 : 서비스 요청을 받은 이후에 즉시 다음 서비스 요청을 처리할 것인지(nowait) 아니면 요청처리가 완료될 때까지 대기하였다가 다음 요청을 처리할 것인지(wait) 설정한다.
    5. 사용할 사용자 계정: 프로그램을 실행시킬 사용자를 설정한다.
    6. 실행 경로명 : 해당 서비스를 처리하는 실행 모듈의 경로를 절대경로로 설정한다.
    7. 실행 인수 : 프로그램의 인수를 설정한다. 첫 번째는 응용 프로그램 자신의 이름이 된다.
  • 서비스 활성화 : inetd.conf 파일에 실행할 서비스를 활성화한 후(# 주석 제거) inetd 데몬을 재시작한다.
• 불필요한/취약한 서비스 비활성화
  1. 불필요하고 보안상 취약한 다음 서비스들은 비활성화한다.
     • DoS 공격에 취약한 Simple TCP 서비스 : echo(7/tcp), discard(9/tcp), daytime(13/tcp), chargen(19/tcp) 등
     • r 계열 서비스 : rlogin, rsh, rexec 등 r 계열 서비스는 인증 없이 관리자의 원격접속을 가능하게 하는 명령어들로 이기종 운영체제 간 백업 등의 용도로 사용되는 경우가 있으나 보안상 매우 취약하기 때문에 사용하지 말아야 한다.
     • 불필요한 rpc 서비스 : rpc.cmsd, rusersd 등 분산 환경에서 서버 응용프로그램에 접근하여 작업 호출(call)을 할 수 있는 서비스로 버퍼 오버플로우 등 다수의 취약점이 존재하여 침해사고발생 위험이 있으므로 서비스를 중지해야 한다.
     • 기타 불필요한 finger, tftp, talk 등의 서비스
  2. 불필요한/취약한 서비스 확인 및 비활성화 처리
     • inetd.conf 파일에서 취약한 서비스를 grep하여 활성화되어 있으면 이를 주석 처리하여 비활성화한다.
     • inetd.conf 설정을 적용하기 위해 inetd 서비스를 재시작한다.

접근 통제(TCP Wrapper)

• 개요
  1. TCP Wrapper는 외부에서 들어오는 클라이언트에 대해 접근통제 기능을 제공한다. 클라이언트의 IP 주소를 확인하여 시스템 관리자가 접근을 허용한 호스트들에 대해서만 서비스를 허용하기 때문에 외부의 해킹으로부터 시스템을 보호할 수 있다.
  2. 접근허용 및 차단에 대한 판단은 /etc/hosts.allow와 /etc/hosts.deny 파일에 정의된 호스트 정보(IP 정보)를 기준으로 한다. 이를 통하여 외부로부터 접근을 선택적으로 제한할 수 있다.
     • 접근 순서가 중요하다. 먼저 hosts.allow 파일을 참조하여 해당 호스트 정보가 있다면 접근을 허용한다. 없다면 host.deny 파일을 참조하여 해당 호스트 정보가 있으면 접근을 차단한다. host.deny 파일에;도 해당 호스트 정보가 없다면 default로 모든 접근을 허용한다.
  3. TCP Wrapper를 사용하기 전과 후의 Telnet 서비스에 대한 /etc/inetd.conf 파일 구조
     사용전 : Telnet stream TCP nowait root /usr/sbin/in.telnetd in.telnetd
     사용후 : Telnet stream TCP nowait root /usr/sbin/tcpd in.telnetd
     • TCP Wrapper를 사용할 경우 해당 서비스의 실행경로에 'usr/sbin/tcpd'를 명시한다. inetd 데몬은 외부로부터 서비스 요청이 올 경우 inetd.conf 파일을 참조하여 실행경로에 설정된 /usr/sbin/tcpd(TCP Wrapper 프로세스)를 실행한다.
     • tcpd는 hosts.allow 및 hosts.deny 파일을 참조하여 접근제어를 수행한 후 실행 인수로 설정된 서비스를 실행한다.
• hosts.allow(접근 허용)와 hosts.deny(접근 금지)
  • 구문 형식 : service_list : client_list (: shell_commend)
    shell_command는 일치하는 것이 있을 때 선택적으로 tcpd가 실행하는 쉘 명령이다.
  • 설정 예 : hosts.allow 파일에 in.telnetd : 192.168.1.1 in.ftpd : 192.168.1.1 192.168.1.2가 있으면 각각의 서비스에 해당 IP만 가능하고 그 외의 호스트는 어떤 서비스도 받을 수 없다.
  • 일반적인 설정이 위와 같이 hosts.allow 파일에 허용할 호스트를 명시한 후 hosts.deny 파일에서 ALL : ALL로 그 외의 모든 호스트를 차단하도록 설정한다. 결과적으로 먼저 처리되는 hosts.allow 파일에 허용하지 않는 호스트들은 모두 차단하게 된다.
  • shell_command
    • shell_command에 정의한 쉘 명령은 접근 통제 리스트(ACL)에 일치하는 것이 있으면 실행하는 명령으로 일반적으로 hosts.deny 파일에 이를 설정하여 차단된 호스트에게 즉시 통보나 경고 메시지를 보내는 용도로 사용한다.
    • 쉘 명령을 실행하는 방법으로 는 twist 또는 spawn이 있다. twist는 명령의 결과를 클라이언트에게 전송하기 때문에 클라이언트에게 메시지를 보낼 때 유용하고, spawn은 명령의 결과를 클라이언트에게 전송하지 않는다.
    • 예시 : hosts.deny 파일 중
              in.telnetd : 192.168.0.104 : twist /bin/ehco "!!! 192.168.0.104는 연결이 거부되었음 !!!"
              in.telentd : 192.168.0.104 : spawn /bin/mail -s "%a is denied" root

슈퍼 데몬(xinetd)

• 개요
  1. 기존의 inetd 슈퍼데몬의 비효율적인 리소스 관리와 보안성 문제를 극복하기 위해 나온 슈퍼데몬으로 서비스별 다양한 설정 옵션을 가지고 있다.
  2. 서비스별 접근제어를 위해 TCP Wrapper의 기능뿐만이 아니라 자체적으로 다양한 서비스별 접근제어가 가능하다.
  3. 서비스 구성은 다음과 같다.
     
     • /etc/xinetd.conf : 글로벌 xinetd 설정파일
     • /etc/xinetd.d/서비스 설정파일 : 개별 서비스에 대한 설정파일
• 서비스별 설정파일
  1. service : 서비스 이름
  2. disable : 해당 서비스의 실행 여부를 결정한다.
  3. socket_type : 서비스 소켓 유형을 설정, tcp의 경우 stream, udp의 경우 dgram을 설정
  4. wait : 서비스 요청 처리 중 다음 요청이 들어오면 이를 즉시 처리할 것인지 이전 요청이 완료될때까지 대기할 것인지 설정
  5. user : 어떤 사용자로 서비스를 실행할지 설정한다.
  6. cps : 연결 요청을 제한하기 위한 설정으로 첫 번재 인자는 초당 연결 개수를 의미하고 두 번째 인자는 초당 연결 개수를 초과하면 일시적으로 서비스가 중지되는데 서비스 일시 중지 후 재시작할 때까지 대기하는 시간을 의미한다.
     ex) cps = 50 10 : 초당연결개수 50개, 재시작 10초간 일시정지
  7. instance : 동시에 서비스할 수 있는 서버의 최대 개수를 지정한다.
  8. per_source : 동일 출발지 IP를 기준으로 최대 서비스 연결 개수를 지정한다.
  9. only_from : 특정 주소 또는 주소 대역만 접근을 허용한다.
  10. no_access : 특정 주소 또는 주소 대역의 접근을 차단한다.
  11. access_times : 지정한 시간 범위 내에서만 접근을 허용한다.
  12. log_on_failure : 서버 접속에 실패했을 경우 로그파일에 기록할 내용을 설정한다.
  13. log_on_success : 서버 접속에 성공했을 경우 로그파일에 기록할 내용을 설정한다.
• 서비스별 접근제어 실습
  • 설정파일 변경 후 xinetd 데몬을 재기동하여 서비스 설정을 적용한다.
  • 접근 차단 로그 확인 (var/log/messages)

 (3) PAM(장착형 인증 모듈, Pluggable Authentication Modules) 

개요

• PAM은 리눅스 시스템 내에서 사용되는 각종 어플리케이션 인증을 위해 제공되는 다양한 인증용 라이브러리들을 말한다.
  • 일반적으로 /lib/security 또는 /usr/lib/security 디렉터리에 해당 라이브러리가 저장되어 있다.
  • 라이브러리들은 어플리케이션 인증 목적으로 관리자에 의해 선택적으로 사용될 수 있다. 이를 통해 소프트웨어 개발 시 인증부분을 독립적으로 개발할 수 있고 필요에 따라 인증체계를 선택적으로 사용할 수 있는 장점이 있다.
• 리눅스는 로그인이나 Telnet, FTP 등 각종 프로그램 사용시 PAM을 통해 인증을 처리한다. 프로그램 개발 시 인증모듈을 별도로 개발하지 않고 플러그인 방식의 PAM을 사용함으로써 인증 방식 및 정책의 유연성과 중앙 통제가 가능하다는 장점이 있다.
• PAM은 리눅스 시스템에서 사용자 인증의 핵심이며, 각 응용 프로그램에 대한 인증 형태, 사용자 권한, 접근 자원 등을 선택할 수 있는 라이브러리이다.
• 시스템 관리자는 다양한 인증 서비스를 선택할 수 있고, 기존 응용 프로그램을 수정할 필요 없이 새로운 인증 서비스 모듈을 추가하여 사용할 수 있다.

PAM을 사용한 인증 절차

1. 각 프로그램(login, telnet, ftp 등)은 인증이 필요한 부분에 PAM 라이브러리를 호출한다.
2. PAM 라이브러리가 호출되면 해당 프로그램의 PAM 설정파일을 참조하여 등록된 여러 PAM 모듈들을 수행하고 그 결과를 응용 프로그램에 반환한다.
3. 응용 프로그램은 그 반환된 결과를 이용하여 인증 여부를 결정한다.
4. PAM 라이브러리 관련 경로는 다음과 같다.
   
   • /etc/pam.d : PAM 라이브러리를 이용하는 각 응용 프로그램 서비스의 설정 파일이 위치하는 디렉토리이다. 설정파일명은 응용프로그램명과 동일하다.
   • /lib/security : PAM 라이브러리가 제공하는 다양한 인증 모듈들이 위치한다.
   • /etc/security : PAM 모듈 실행에 필요한 추가 설정 파일이 위치한다.

PAM 설정파일(/etc/pam.d/remote 설정파일 일부)

• 형식 : type  control  module-path  module-arguments
  1. type : PAM 모듈 종류
     • account(계정) : 서비스 사용자 계정의 유효성을 검증하는 유형으로 계정의 유효기간(비밀번호 만료), 접속 가능 시간, 서비스 접근 허용여부 등이 있다.
     • auth(인증) : 서비스 사용자 계정의 패스워드 검증, 다른 인증 모듈과의 연동 등 사용자 신원확인을 수행하는 유형으로 패스워드 인증, OTP/보안카드 등이 있다.
     • password(패스워드) : 서비스 사용자 계정의 비밀번호 설정 및 변경 조건을 지정하는 유형으로 패스워드 설정/변경 시 최소길이, 복잡도 설정 등이 있다.
     • session(세션) : 서비스 사용자 계정의 인증처리 전후에 수행할 작업을 지정하는 유형으로 사용자 홈 디렉터리 마운트, 메일함 생성 등이 있다.
  2. control : 각 모듈 실행 후 성공 또는 실패에 따른 PAM 라이브러리 행동 결정
     • requisite : 인증에 실패할 경우 즉시 인증을 거부
     • required : 인증에 실패하더라도 다음 라인의 모듈을 실행하지만 최종 결과는 인증 실패
     • sufficient : 이전에 요청된 모듈이 실패하더라도 여기서 성공하면 PAM은 인증 성공(단, 이전에 위치한 requried 모듈이 모두 성공일 경우)
     • optional : 모듈의 성공, 실패 결과는 모두 무시됨
  3. module_path : PAM에서 사용할 실재 모듈파일이 위치한 경로를 의미한다. 모듈 이름만 명시할 경우 기본 PAM 모듈 디렉터리 (/lib/security)에서 해당 모듈을 찾는다.
  4. module_arguments : 모듈에게 전달되는 인수를 의미한다.

PAM 활용 예 1

• root 계정의 원격 접속 제한
  • root 계정은 시스템을 관리하는 매우 중요한 계정으로 직접 로그인이 가능하면 불법적인 침입자의 목표가 될 수 있다. 따라서 root 계정의 원격 접속을 금지한다.
  • 터미널 접속 시 /etc/securetty 파일에 등록되어 있는 터미널이 아니면 root의 접속을 허용하지 않도록 PAM 설정을 한다. /etc/securetty 파일은 pam_securetty.so 모듈이 사용하는 파일로 터미널 접속 시 root 접근 제한 설정 파일이다.
• 실습
  1. /etc/pam.d 디렉터리에 있는 remote 서비스(또는 login 서비스) 설정파일에 pam_securetty.so 모듈을 추가한다.
  2. /etc/securetty 파일에 'pts/~' 터미널을 모두 제거한다.(주석처리한다)
     • tty : 서버와 연결된 모니터, 키보드 등을 통해 사용자가 콘솔로 직접 로그인함
     • pts : telnet, 터미널 등을 통해 접속하는 가상 터미널을 의미
  3. telnet 클라이언트로 root 계정에 접근 시 거부된다.
  4. /var/log/secure를 통해 pam모듈 로그 확인
• 유닉스/리눅스 시스템별 root계정 원격 접속 제한 설정
  • 솔라리스 보안설정 : /etc/default/login 파일의 console라인을 통해 root의 원격 접속을 제한할 수 있다. 콘솔 라인에 #을 붙이면 외부에서 root 계정으로 접속이 가능하다.
  • AIX 보안설정
  • HP-UX 보안설정
• 취약점 점검
  • 'w' 명령을 통해 현재 접속중인 root 사용자 정보를 확인할 수 있다.
    • 점검 결과 중 TTY 컬럼을 살펴보면 root계정이 pts 타입으로 다수 접속한 것을 확인할 수 있는데, pts는 가상 터미널 타입으로 telnet, 터미널 등을 통해 root계정으로 접속한 것으로 판단할 수 있다.
    • root 계정의 경우 중요한 계정이므로 원격 터미널 접속을 차단하는 것이 필요하다.
  • SSH root 원격 접속 제한 설정
    • telnet 또는 ftp를 사용하여 원격 접속 또는 파일 송수신을 할 경우 평문 통신을 하기 때문에 공격자의 스니핑 공격에 매우 취약하다. 이에 대한 대안으로 ssh를 사용할 수 있는데, ssh는 암호 통신을 이용하여 네트워크상의 다른 컴퓨터에 접속하여 원격으로 명령을 실행하거나 파일을 조작하는 응용 프로그램 또는 프로토콜을 의미하며 대표적인 서비스는 다음과 같다.
      • 암호화된 원격 터미널 서비스 제공(telnet 기능 대체)
      • 암호화된 파일 송수신 서비스 제공(FTP 기능 대체)
    • root 계정의 원격 접속을 제한하기 위한 설정방법은 SSH 데몬 설정파일인 /etc/ssh/sshd_config 의 permitRootLogin 항목을 no로 설정하여 root 계정의 원격 접속을 허용하지 않도록 한다.

PAM 활용 예 2

• 계정 잠금 임계값 설정
  1. 공격자에 의한 패스워드 무작위 대입공격이나 사전 대입 공격 발생 시 암호입력 실패 횟수를 적절하게 제한하고 공격시간을 지체시켜 패스워드 유출 위험을 줄인다.
  2. 계정 잠금 임계값을 지정하여(권장 5회 이하) 초과 시 패스워드를 일정시간 잠근다.
  3. pam_tally2.so(또는 pam_tally.so)모듈 이용
• 실습
  1. 계정 잠금 임계값을 설정하기 위해 /etc/pam.d 디렉터리에 있는 system-auth 서비스 설정파일에 아래와 같이 pam_tally2 모듈을 추가한다.
     • deny = 5
     • unlock_time = 120 : 계정 잠김 후 마지막 계정 실패 시간부터 설정된 시간이 지나면 자동 계정 잠금해제(초단위)
  2. telnet 클라이언트로 5회 패스워드 입력 실패 시 계정 잠김 확인
  3. /var/log/secure를 통한 pam 모듈 로그 확인
  4. pam_tally2 명령을 통해 실패 횟수 확인 및 초기화
     • pam_tally2 -u 계정명 : 로그인 실패 횟수 확인
     • -r 까지 붙이면 : 해당 계정의 실패 횟수 초기화
• 유닉스/리눅스 시스템별 계정 잠금 임계값 설정
  • 리눅스의 pam_tally.so
    • no_magic_root : root 계정은 패스워드 잠금 설정을 적용하지 않는다.
    • reset : 접속 시도 성공 시 실패한 횟수 초기화

PAM 활용 예 3

• root 계정 su 제한
  1. 권한이 없는 일반 사용자가 su 명령을 사용하여 로그인을 시도하고 패스워드 무작위 대입공격이나 패스워드 추측 공격을 통해 root 권한을 획득할 수 있다.
  2. su 명령어 사용이 허용된 사용자만 root 계정으로 접속할 수 있도록 설정한다.
  3. pam_wheel.so 모듈 이용
• 실습
  1. wheel 그룹(su명령어 사용그룹)에 su 명령어를 사용할 사용자를 추가한다.
     • 'usermod -G(보조 그룹 변경) wheel 계정명' 명령어를 통해 새로운 계정을 wheel 그룹에 추가할 수 있다.
     • 직접 'etc/group' 파일을 수정하여 필요한 계정을 추가할수도 있다.
  2. wheel 그룹의 사용자만 su 명령을 허용하도록 /etc/pam.d 디렉터리에 있는 su 서비스 설정파일에 아래와 같이 설정(주석 해제)한다.
  3. wheel 그룹이 아닌 사용자 su명령 차단됨, 차단된 로그는 /var/log/secure 에서 찾을 수 있다.
  4. wheel 그룹 사용자는 su 명령이 허용된다.
• 유닉스/리눅스 시스템별 root 계정 su 제한 설정
• sudo 명령을 이용한 관리자(root) 권한 부여
  • 개요
    • sudo 명령은 다른 사용자계정 권한으로 명령어를 실행하고자 할 때 사용하는 명령어이다.
    • su 명령을 사용할 경우 관리자(root)의 비밀번호를 알려줘야 한다는 부담이 있으며, 최소 권한의 원칙에 따라 관리자로 로그인하는 것을 차단하고 권한이 필요한 경우에만 sudo 명령을 사용하여 제한적으로 관리자 권한의 명령어를 실행하는 것을 보안 관점에서 권장한다.
    • sudo 명령 설정 파일 : sudoers(/etc/sudoers)
  • sudo 명령어 및 sudoers 파일 설정
    • 계정명 : sudo 명령을 실행할 계정명이나 그룹명, 그룹명을 줄 경우에는 %그룹명을 사용하고 모두에게 줄경우에는 ALL 지정
    • 호스트명 : sudo 명령을 실행할 호스트의 호스트명 또는 IP, 모든 서버가 대상이면 ALL 지정
    • 실행 권한 계정명 : 명령어를 실행할 때 가질 권한의 계정명 root를 포함한 모든 계정의 권한을 부여할 경우 ALL로 지정하며 생략시 root 권한 부여
    • NOPASSWD : 해당 옵션을 설정할 경우 sudo 명령을 실행하는 계정의 비밀번호를 물어보지 않는다.
    • 명령어 : 실행을 허용할 명령어의 경로, 모든 명령어를 허용할 경우 ALL 지정
  • 실습 1
    • log_batch.sh 프로그램은 root 소유자만 실행 권한을 가지고 있기 때문에 algisa 계정으로 실행 불가
    • algisa 계정은 sudoers 파일에 sudo 명령을 실행할 수 있는 계쩡으로 등록되어 있지 않기 때문에 sudo 명령 실행 불가
    • sudoers 파일에 algisa 계정 동록, algisa 계정은 sudo 명령을 통해 모든 호스트에서 root권한으로 모든 명령을 실행할 수 있다.
    • algisa 계정으로 sudo 명령을 통해 root 소유자만 실행 권한을 가지고 있는 log_batch.sh 프로그램 실행
    • NOPASSWD 옵션 설정이 없으면 sudo 명령을 실행할 때 실행하는 계정의 비밀번호를 요구한다.
  • 실습 2
    • sudoers 파일에 algisa 계정 등록, algisa 계정은 sudo명령을 통해 모든 호스트에서 root 권한(모든 계정권한)으로 모든 명령을 비밀번호 없이 실행할 수 있다.
    • NOPASSWD 옵션이 설정되어 있기 때문에 algisa 계정의 비밀번호를 확인하지 않는다.
  • 실습 3
    • algisa 계정은 sudo 명령을 통해 192.168.56.100 호스트에서 root 권한으로 모든 명령을 실행할 수 있다.
    • algisa 계정은 sudo 명령을 통해 모든 호스트에서 root 권한으로 /was/batch/log_batch.sh 명령을 수행할 수 있다.
    • algisa 계정은 sudo 명령을 통해 모든 호스트에서 root, kiwi99, kiwi88 계정 권한으로 모든 명령을 실행할 수 있다.