서버 운영체제의 표준으로 자리 잡은 리눅스(Linux) 환경에서 '관리자 권한(Root)'은 신의 권한과 같습니다. 시스템의 모든 파일에 접근할 수 있고, 프로세스를 강제로 종료할 수 있으며, 흔적도 없이 전체 데이터를 삭제할 수도 있습니다.
이 막강한 권한은 시스템을 관리하는 데 필수적이지만, 동시에 해커들에게는 가장 매력적인 표적이 됩니다. 만약 공격자가 리눅스 서버의 최고 권한을 획득한다면 해당 기업의 서비스는 물론, 내부 핵심 자산까지 완전히 장악당하게 됩니다.
따라서 리눅스 보안의 출발점이자 종착지는 "어떻게 안전하게 관리자 권한을 획득(Privilege Escalation)하고, 이를 어떻게 철저하게 통제(Access Control)할 것인가"로 귀결됩니다. 실제 인프라 현장에서 발생할 수 있는 가상의 시나리오와 예시를 통해 리눅스 권한 관리의 정석을 살펴보겠습니다.
보안 사고가 발생할 때 해커가 처음부터 root 계정으로 로그인하는 경우는 드뭅니다. 대부분 보안이 취약한 일반 사용자 계정이나 웹 애플리케이션의 취약점을 통해 내부로 침투한 뒤, 시스템 내부의 허점을 노려 관리자 권한을 손에 넣는 '권한 상승' 공격을 감행합니다.
한 중소기업의 리눅스 서버에 웹 취약점(예: 파일 업로드 취약점)을 통해 일반 사용자 권한인 nobody 또는 www-data로 해커가 침투했다고 가정해 보겠습니다. 이 단계에서 해커가 할 수 있는 일은 제한적입니다. 하지만 시스템 관리자가 과거에 편리함을 위해 특정 실행 파일에 SUID(Set User ID)를 잘못 설정해 두었다면 상황은 급변합니다.
SUID는 일반 사용자가 파일을 실행할 때, 파일 소유자(예: root)의 권한으로 실행되도록 하는 리눅스의 특수 권한입니다. 대표적으로 비밀번호를 변경하는 /usr/bin/passwd 명령어가 이에 해당합니다.
Bash
# 정상적인 SUID 설정 확인 (소유자 권한에 's'가 표시됨)
-rwsr-xr-x 1 root root 68208 passwd
만약 관리자가 시스템 점검용으로 사용하는 텍스트 에디터(vim)나 시스템 탐색 도구에 무심코 SUID를 부여했다면 어떻게 될까요?
Bash
# 관리자의 실수로 vim에 SUID가 설정된 상황
-rwsr-xr-x 1 root root 1234567 vim
해커는 이 점을 놓치지 않고 침투한 일반 계정에서 다음과 같은 명령어를 실행합니다.
Bash
vim -c ':py3 import os; os.setuid(0); os.system("/bin/sh")'
이 단 한 줄의 명령어로 해커는 vim을 통해 root 권한의 셸(Shell)을 획득하게 됩니다. 일반 사용자로 들어와 단 몇 초 만에 시스템 전체를 통제하는 신의 권한을 손에 넣는 순간입니다.
이러한 위협으로부터 시스템을 보호하기 위해서는 무조건적인 차단이 아니라, 정교하게 설계된 '권한 획득 및 통제 프로세스'가 필요합니다. 리눅스 환경에서 권한을 안전하게 다루기 위한 4가지 핵심 전략은 다음과 같습니다.
su 대신 sudo를 최우선으로 사용하기전통적인 su (Switch User) 명령어는 root의 비밀번호를 알고 있는 사용자가 완전히 root 계정으로 전환할 때 사용합니다. 하지만 이 방식은 치명적인 약점이 있습니다.
책임 추적성 결여: root로 전환한 이후에 내리는 모든 명령어는 로그에 root가 실행한 것으로 기록됩니다. 즉, '누가' 그 명령어를 실행했는지 추적할 수 없습니다.
비밀번호 공유의 위험: 여러 관리자가 하나의 root 비밀번호를 공유해야 하므로, 퇴사자가 발생하거나 비밀번호가 유출되었을 때 전체 시스템이 위험해집니다.
반면, sudo (SuperUser Do)는 일반 사용자가 자신의 비밀번호를 입력하여 인증하고, 허가된 특정 명령어만 관리자 권한으로 실행하도록 돕습니다.
Bash
# su 방식 (위험)
$ su -
Password: (root 비밀번호 입력)
root@server:~# rm -rf /var/log # 누가 지웠는지 알 수 없음
# sudo 방식 (안전)
$ sudo rm -rf /var/log
[sudo] password for john: (john의 비밀번호 입력)
sudo를 사용하면 /var/log/auth.log 또는 /var/log/secure 파일에 다음과 같이 명확한 기록이 남습니다.
"User john run /usr/bin/rm -rf /var/log as root"
이를 통해 철저한 책임 추적성(Accountability)을 확보할 수 있습니다.
/etc/sudoers 설정을 통한 최소 권한 원칙(Principle of Least Privilege) 적용모든 개발자나 엔지니어에게 sudo ALL=(ALL:ALL) ALL과 같은 완전한 관리자 권한을 부여하는 것은 매우 위험합니다. 업무에 필요한 최소한의 명령어만 실행할 수 있도록 권한을 쪼개어 부여해야 합니다.
예를 들어, 웹 서버의 로그를 확인하고 아파치(Apache) 서비스만 재시작할 수 있는 권한을 웹 개발자 그룹(webdev)에게 준다면 /etc/sudoers 파일을 다음과 같이 세분화하여 설정해야 합니다.
Bash
# /etc/sudoers 설정 예시
# 변수 정의 (User_Alias, Cmd_Alias)
User_Alias WEB_DEVELOPERS = %webdev
Cmd_Alias WEB_MANAGEMENT = /usr/bin/systemctl restart httpd, /usr/bin/tail -f /var/log/httpd/*
# webdev 그룹의 사용자는 웹 서버 재시작과 로그 확인 명령어만 sudo로 실행 가능
WEB_DEVELOPERS ALL=(root) WEB_MANAGEMENT
이렇게 설정하면 webdev 그룹에 속한 직원은 시스템을 포맷하거나 다른 사용자의 계정을 삭제하는 등의 위험한 행동을 할 수 없으며, 오직 지정된 웹 서버 관리 업무만 안전하게 수행할 수 있습니다.
root 직접 로그인 전면 차단외부 인터넷에서 서버로 접속할 때 root 계정으로 바로 로그인할 수 있도록 허용하는 것은 해커에게 절반의 힌트(아이디)를 제공하는 것과 같습니다. 해커는 무차별 대입 공격(Brute Force Attack)을 통해 root의 비밀번호만 알아내면 즉시 서버를 장악할 수 있습니다.
따라서 SSH 설정 파일(/etc/ssh/sshd_config)에서 root의 직접 접속을 반드시 차단해야 합니다.
Plaintext
# /etc/ssh/sshd_config 설정 변경
PermitRootLogin no
설정 적용 후 외부 사용자는 먼저 일반 사용자 계정(예: alice)으로 로그인한 뒤, sudo를 통해서만 관리자 권한을 행사할 수 있습니다. 공격자 입장에서는 두 단계의 방어벽(일반 계정 해킹 -> sudo 권한 상승 취약점 공략)을 넘어야 하므로 공격 난이도가 비약적으로 상승합니다.
비밀번호는 복잡하게 설정하더라도 키로깅(Keylogging)이나 사회공학적 기법에 의해 유출될 가능성이 있습니다. 이를 방지하기 위해 관리자 권한을 획득하는 단계(sudo 실행 시 또는 SSH 접속 시)에 Google Authenticator 등을 활용한 OTP 인증을 결합하는 것이 안전합니다. 비밀번호가 유출되더라도 관리자의 스마트폰에 있는 일회용 인증 코드가 없으면 최종 권한을 얻을 수 없도록 만드는 궁극의 방어선입니다.
안전하게 통제 장치를 마련했다면, 그 장치들이 제대로 작동하고 있는지 감시하는 체계가 동반되어야 합니다. 리눅스 시스템은 권한 오용을 감시할 수 있는 강력한 자체 도구들을 제공합니다.
/var/log/auth.log (데비안/우분투) 또는 /var/log/secure (RHEL/CentOS): 인증 관련 모든 성공 및 실패 기록, sudo 명령어 실행 내역이 실시간으로 기록됩니다.
lastlog 및 last 명령어: 최근에 시스템에 로그인한 사용자의 IP와 시간을 확인하여 비정상적인 접근 여부를 판별합니다.
auditd (Linux Audit Framework) 활용리눅스 커널 수준에서 발생하는 이벤트를 감시하는 auditd 서비스를 활용하면, 특정 중요 파일(예: /etc/passwd, /etc/shadow)에 접근하거나 권한을 변경하려는 시도를 실시간으로 추적하고 경고를 보낼 수 있습니다.
Bash
# /etc/shadow 파일에 대한 변경 시도를 감시하는 규칙 추가
auditctl -w /etc/shadow -p wa -k shadow_changes
이렇게 설정해 두면 누군가 관리자 권한을 탈취하여 비밀번호 파일을 조작하려 할 때 즉시 로그에 기록되어 보안 관제 시스템(SIEM)으로 전송됩니다.
리눅스 서버 환경에서 관리자 권한을 안전하게 통제하기 위한 핵심 원칙을 요약하면 다음과 같습니다.
| 보안 항목 | 권장 조치 사항 | 기대 효과 |
| Root 로그인 | SSH 직접 접속 전면 차단 (PermitRootLogin no) |
외부 무차별 대입 공격 원천 차단 |
| 권한 전환 | su 사용을 금지하고 sudo로 일원화 |
명확한 행위 추적성(Audit Trail) 확보 |
| 권한 범위 | /etc/sudoers를 통한 최소 명령어 권한 부여 |
내부 직원의 실수 및 권한 남용 방지 |
| 특수 권한 | 주기적인 SUID/SGID 파일 전수 조사 및 제거 | 권한 상승 취약점 공격 루트 제거 |
| 인증 강화 | 중요 서버 접속 및 권한 상승 시 MFA(2FA) 필수 적용 | 계정 정보 유출 시 2차 방어선 구축 |
리눅스 보안은 단순히 강력한 방화벽을 세우는 것에 그치지 않습니다. 내부의 '신뢰할 수 있는 사용자'에게 권한을 부여할 때조차 의심하고 검증하는 제로 트러스트(Zero Trust) 관점이 필요합니다.
불편함과 보안성은 언제나 트레이드오프(Trade-off) 관계에 있지만, 철저하게 설계된 sudo 체계와 권한 제어 정책은 비즈니스의 연속성을 지키는 가장 확실한 투자입니다. 지금 운영 중인 리눅스 서버의 시스템 권한 설정을 다시 한번 점검해 보시기 바랍니다.