대상 OS: Ubuntu Server 24.04 LTS

권한 점검은 범위를 크게 잡는 순간 “이번 달에는 하다가 다음 달에 포기”로 끝나기 쉽습니다. 현실적으로는 사고가 자주 나는 지점부터 좁게 시작해야 지속 가능합니다. 아래는 Ubuntu 24.04 기준으로 “작게 시작해서 운영 루틴으로 만드는” 방식입니다.

0) 원칙: ‘중요 경로 3개 + 위험 속성 3개’만 먼저 본다

  • 중요 경로 3개: /etc, 서비스 데이터(예: /var/www, /srv, /opt), 사용자 홈(특히 ~/.ssh)
  • 위험 속성 3개: world-writable(누구나 쓰기), SUID/SGID(권한 상승), 잘못된 소유자(root/서비스계정 혼재)


1) /etc에서 “world-writable”부터 찾기

/etc는 설정이 모이는 곳이라, 여기서 world-writable 파일이 나오면 우선순위가 높습니다.

# /etc 내부에서(다른 파일시스템으로 넘어가지 않게 -xdev)
sudo find /etc -xdev -type f -perm -0002 -print

# 디렉터리까지 보고 싶으면
sudo find /etc -xdev \( -type f -o -type d \) -perm -0002 -print

발견되면 “왜 쓰기 권한이 열렸는지”를 먼저 확인하고, 정상 사유가 없다면 닫습니다.

# 예: others write 제거(상황에 따라 그룹 쓰기도 함께 조정)
sudo chmod o-w /etc/문제파일.conf


2) SUID/SGID 파일을 ‘증분’으로 관리하기

SUID/SGID 자체가 무조건 악은 아니지만, 예상치 못한 SUID는 사고 표면을 키웁니다. “전체를 한 번에”가 아니라, 목록을 저장해두고 변경분만 보는 방식이 유지에 유리합니다.

# 최초 1회: SUID/SGID 목록 스냅샷 저장
sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -print 2>/dev/null | sort | sudo tee /root/suid_sgid.baseline.txt >/dev/null

# 이후: 변경분 비교
sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -print 2>/dev/null | sort | sudo diff -u /root/suid_sgid.baseline.txt - || true

변경분이 나오면 “어떤 패키지 설치/업데이트로 생겼는지”를 확인합니다.

# 해당 바이너리가 어떤 패키지 소속인지
sudo dpkg -S /path/to/binary 2>/dev/null || true


3) SSH 키 권한은 ‘정답’이 거의 정해져 있다

SSH 키 권한은 오탐이 적고 효과가 큽니다. 특히 운영자가 여러 명인 환경에서 자주 틀립니다.

# 현재 사용자 기준 점검
ls -al ~/.ssh 2>/dev/null || true
find ~/.ssh -maxdepth 1 -type f -print -exec stat -c '%a %U:%G %n' {} \; 2>/dev/null || true

일반적인 기준(환경에 따라 조정): 디렉터리 700, 개인키 600, authorized_keys 600.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_* ~/.ssh/authorized_keys 2>/dev/null || true


4) 서비스 디렉터리(/var/www, /srv 등)에서 ‘소유자 혼재’ 찾기

웹/애플리케이션 서비스 디렉터리는 “배포 스크립트가 root로 떨어뜨린 파일” 때문에 권한/소유자가 뒤섞이기 쉽고, 그게 곧 업로드 취약점/웹쉘의 발판이 됩니다.

# 예: /var/www에서 root 소유 파일이 너무 많은지 확인
sudo find /var/www -xdev -type f -user root -print | head

# 예: www-data 소유가 아닌 파일(혼재)을 확인
sudo find /var/www -xdev -type f ! -user www-data -print | head

정상 소유자를 정한 뒤, 배포/업로드 경로만 예외로 관리하는 방식이 안전합니다.

# 예시(주의: 운영 중 서비스 구조에 맞게 적용)
sudo chown -R www-data:www-data /var/www/서비스디렉터리


5) “작게 시작”을 운영 루틴으로: 주 1회 3개 명령만

아래 3개만 정기 실행해도, 권한 사고의 많은 부분을 조기에 잡습니다.

# (1) /etc world-writable
sudo find /etc -xdev -type f -perm -0002 -print

# (2) 신규/변경 SUID/SGID
sudo find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -print 2>/dev/null | sort | sudo diff -u /root/suid_sgid.baseline.txt - || true

# (3) SSH 키 권한
stat -c '%a %U:%G %n' ~/.ssh ~/.ssh/* 2>/dev/null || true


사례(현장에서 자주 겪는 상황)

  • 배포 스크립트가 root로 파일을 떨굼 → /var/www에 root 소유 파일이 섞이고, 서비스 계정이 쓰기 가능한 경로가 넓어져 웹쉘/변조 위험 증가.
  • 운영자가 여러 명이라 ~/.ssh 권한이 흔들림 → sshd가 키를 무시하거나(접속 실패), 반대로 키 파일이 과도하게 열려 보안 위험이 됨.
  • “일단 되게 하자”로 /etc에 777 → 장애는 해결되지만, 이후 공격/오남용 경로가 남아 장기 리스크가 됨.

트러블슈팅(증상→원인→해결)

  • 증상: SSH 키가 있는데도 공개키 인증이 안 됨
    원인: ~/.ssh 또는 키 파일 권한이 너무 열려 sshd가 무시
    해결: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys 적용 후 재시도(서버 쪽 /var/log/auth.log도 확인)
  • 증상: 서비스가 설정 파일을 읽지 못하고 Permission denied 발생
    원인: 소유자/그룹 변경 과정에서 서비스 계정 권한이 사라짐(특히 /etc 아래 파일)
    해결: 서비스 계정 확인(systemctl cat, ps -ef) 후 최소 권한으로 소유자/그룹/모드 복구
  • 증상: SUID/SGID 목록이 갑자기 늘어남
    원인: 패키지 설치/업데이트로 권한 비트가 추가됨(정상일 수도, 정책 위반일 수도)
    해결: 변경된 파일의 패키지 소속(dpkg -S) 확인 → 필요성 검토 → 불필요 시 제거/대체 또는 정책 예외로 문서화

운영 팁: “전체 권한 점검”은 분기/반기 과제로 잡고, 평소에는 위의 작은 루틴(주 1회)로 ‘변화’를 추적하는 쪽이 실제 보안 수준을 더 빨리 올립니다.

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -