서버 보안 설정 방법 단계별 실전 가이드[필수] – Ubuntu 24.04 초보자도 따라하는 10가지
서버 보안 설정 방법을 제대로 알고 시작하는 사람이 생각보다 많지 않아. 클라우드 서버를 하나 만들고 나서 대부분은 바로 웹서버 설치하거나 앱 올리는 것부터 시작하거든. 그런데 솔직히 말하자면, 그게 가장 위험한 순간이야. 보안 설정 없이 공개된 서버는 말 그대로 열린 문과 같아. 실제로 새로 만든 서버가 수분 안에 자동화된 봇의 공격 대상이 되는 경우가 비일비재해.
이 글은 Ubuntu 24.04 기준으로 서버를 처음 개설한 직후에 해야 하는 보안 설정들을 순서대로 정리한 실전 가이드야. SSH 포트 변경부터 시작해서 UFW 방화벽 설정, Fail2ban 설치, 불필요한 서비스 비활성화까지. 복잡한 이론 설명 없이 딱 따라 하면 되는 커맨드 위주로 구성했어.
예전에 처음 VPS를 구매했을 때 보안 설정을 미루다가 auth.log 파일에 수천 건의 로그인 시도 기록이 쌓인 걸 발견한 적이 있어. 그때부터는 서버 만들고 30분 안에 기본 보안 설정을 끝내는 게 습관이 됐어. 이 가이드대로 따라오면 너도 그렇게 할 수 있을 거야.
초보자도 충분히 따라할 수 있도록 각 명령어 앞에 설명을 붙였고, 왜 이 설정이 필요한지도 간단하게 같이 적어뒀어. 서버 관리가 처음이라도 걱정 말고 순서대로 따라와 봐.
운영체제: Ubuntu 24.04 LTS
접속 방식: SSH (루트 또는 sudo 권한 계정)
대상: 신규 서버 개설 직후 / 보안 설정 경험이 적은 초보자
예상 소요 시간: 30분 ~ 1시간
SSH 설정을 변경하다 보면 실수로 접속이 끊길 수 있어. 클라우드 서비스(AWS, GCP, Oracle 등)를 사용 중이라면 웹 콘솔에서 직접 접속할 수 있는 방법을 미리 열어두는 게 좋아. 작업 전에 현재 세션을 유지한 채로 새 터미널을 하나 더 열어두는 것도 안전한 방법이야.
목차
- STEP 1. 시스템 업데이트 – 첫 번째로 해야 할 일
- STEP 2. 새로운 관리자 계정 생성 – root 직접 사용 금지
- STEP 3. SSH 키 인증 설정 – 비밀번호 로그인 없애기
- STEP 4. SSH 포트 변경 및 보안 강화 – 기본 22번 포트 바꾸기
- STEP 5. UFW 방화벽 설정 – 허용된 것만 통과시키기
- STEP 6. Fail2ban 설치 – 무차별 대입 공격 차단
- STEP 7. 자동 보안 업데이트 설정 – 손 안 대도 최신 상태 유지
- STEP 8. 불필요한 서비스 비활성화 – 공격 표면 줄이기
- STEP 9. 시스템 로그 모니터링 설정 – 이상 징후 빠르게 파악
- STEP 10. 보안 설정 최종 점검 – 체크리스트로 마무리
각 단계는 순서대로 진행하는 게 좋아. 특히 STEP 2, 3, 4는 연결된 작업이라 순서를 바꾸면 접속이 끊길 수 있으니 주의해줘. 준비됐으면 STEP 1부터 시작해보자.
STEP 1. 시스템 업데이트 – 첫 번째로 해야 할 일
서버 만들고 나서 가장 먼저 해야 할 게 뭔지 알아? 바로 시스템 업데이트야. 클라우드 이미지로 서버를 생성하면 대부분 최신 패키지가 반영되지 않은 상태로 시작하거든. 이미 알려진 취약점이 있는 버전이 그대로 깔려 있을 수 있어.
사실 이게 귀찮아 보여서 나중에 하려고 미루는 경우가 많은데, 업데이트 안 된 패키지가 공격 진입점이 되는 경우를 생각하면 꼭 제일 먼저 처리하는 게 맞아. 특히 OpenSSH나 OpenSSL 같은 핵심 패키지에 보안 패치가 자주 나오거든.
apt update는 패키지 목록만 새로 받아오는 거야. 실제로 아무것도 설치하거나 바꾸지 않아.
apt upgrade가 실제로 패키지를 새 버전으로 교체하는 명령어야. 두 개를 항상 순서대로 실행해야 해.
업그레이드 중에 설정 파일 변경 여부를 묻는 화면이 나올 수 있어. 대부분은 기본값 그대로 엔터 치면 되는데, sshd_config 같은 SSH 관련 파일은 기존 설정 유지(keep the local version)를 선택하는 게 안전해. 나중에 직접 수정할 거거든.
STEP 2. 새로운 관리자 계정 생성 – root 직접 사용 금지
root 계정으로 서버에 직접 접속해서 작업하는 건 정말 위험한 습관이야. root는 시스템의 모든 권한을 가진 계정이라서, 만약 누군가 root로 접속에 성공하면 서버 전체를 통째로 가져갈 수 있거든. 그래서 일반 관리자 계정을 따로 만들고 root 직접 로그인은 막는 게 기본 중의 기본이야.
처음 서버를 받으면 root로 접속하게 되어 있는 경우가 많아. 그 상태에서 가장 먼저 해야 할 게 바로 sudo 권한을 가진 일반 계정을 하나 만드는 거야. 이름은 뭐든 상관없는데, admin, ubuntu, user 같은 너무 뻔한 이름은 피하는 게 좋아. 봇이 자주 시도하는 계정명이거든.
adduser 명령어를 실행하면 비밀번호 설정과 이름, 이메일 같은 정보를 입력하라고 나와. 비밀번호는 꼭 강력하게 설정해줘. 나중에 SSH 키 인증으로 비밀번호 로그인 자체를 막을 거지만, 그 전까지는 비밀번호가 1차 방어선이야.
새 계정으로 접속 테스트가 완료됐으면, root 계정의 SSH 로그인을 비활성화할 준비가 된 거야. 이건 STEP 4에서 SSH 설정 변경할 때 같이 처리할 거야. 순서대로 따라오면 돼.
STEP 3. SSH 키 인증 설정 – 비밀번호 로그인 없애기
SSH 키 인증은 서버 보안 설정 방법 중에서 가장 효과적인 방법 중 하나야. 비밀번호 기반 로그인은 아무리 복잡하게 설정해도 브루트포스(무차별 대입) 공격에 취약할 수 있어. 반면에 SSH 키 인증은 수학적으로 매우 강력한 암호화 방식을 사용해서, 키 파일 없이는 접속 자체가 불가능해.
방식은 간단해. 로컬 컴퓨터(내 PC)에서 공개키/개인키 쌍을 만들고, 공개키만 서버에 등록해두는 거야. 서버에 접속할 때 서버가 공개키로 암호화한 문제를 보내면, 내 PC의 개인키로 풀어서 인증하는 구조야. 개인키는 절대 서버에 올라가지 않아.
| 구분 | 비밀번호 인증 | SSH 키 인증 |
|---|---|---|
| 보안 수준 | 낮음 | 매우 높음 |
| 브루트포스 위험 | 있음 | 사실상 없음 |
| 편의성 | 비밀번호 기억 필요 | 키 파일만 있으면 자동 접속 |
| 분실 시 대처 | 비밀번호 재설정 가능 | 키 재발급 후 서버 재등록 |
먼저 로컬 PC에서 키를 생성해야 해. Windows라면 PowerShell, Mac/Linux라면 터미널에서 실행해줘.
ssh-copy-id -i ~/.ssh/id_ed25519.pub myuser@서버IP
비밀번호 로그인이 아직 열려 있는 상태에서만 가능하니까 SSH 키 등록할 때 먼저 써봐.
키 등록 후에는 반드시 새 터미널에서 키 인증으로 접속 테스트를 먼저 해봐. 접속이 정상적으로 되는 걸 확인한 다음 단계로 넘어가야 해.
STEP 4. SSH 포트 변경 및 보안 강화 – 기본 22번 포트 바꾸기
SSH 기본 포트는 22번이야. 그리고 전 세계의 수많은 봇들이 이 22번 포트를 24시간 스캔하고 있어. 포트를 바꾼다고 완전히 안전해지는 건 아니지만, 자동화된 공격의 상당수를 걸러낼 수 있어. auth.log를 보면 22번 포트에 하루에도 수천 건의 접속 시도가 기록되는 반면, 포트를 변경하면 그게 거의 사라지거든.
이 단계에서 SSH 설정 파일을 직접 수정할 거야. 포트 변경과 함께 root 로그인 금지, 비밀번호 로그인 비활성화도 같이 처리할 거야. 이게 가장 중요한 부분이라서 신중하게 따라와줘.
편집기가 열리면 아래 항목들을 찾아서 수정해줘. 없는 항목은 파일 맨 아래에 추가하면 돼.
AWS의 Security Group, GCP의 Firewall Rules, Oracle Cloud의 Security List처럼 클라우드 서비스 자체의 방화벽에서도 포트를 열어줘야 해. UFW만 설정하고 이걸 빠뜨리면 접속이 안 돼. 새 SSH 포트를 클라우드 콘솔에서도 인바운드 규칙에 추가해줘.
재시작 후에는 기존 세션은 유지되지만, 새로 접속할 때는 변경된 포트를 명시해야 해. ssh -p 2222 myuser@서버IP 형태로 접속하면 돼. 정상 접속 확인 후 기존 22번 포트는 UFW에서 닫아줘.
STEP 5. UFW 방화벽 설정 – 허용된 것만 통과시키기
UFW(Uncomplicated Firewall)는 Ubuntu에서 기본으로 제공하는 방화벽 관리 도구야. iptables를 직접 다루면 명령어가 복잡한데, UFW는 그걸 훨씬 쉽게 쓸 수 있도록 감싸놓은 거야. Ubuntu 24.04에는 기본 설치가 되어 있는데, 기본값으로는 비활성화 상태라 직접 켜줘야 해.
방화벽의 기본 원칙은 간단해. 필요한 포트만 열고, 나머지는 전부 차단. 이 원칙만 지켜도 외부에서 들어오는 공격의 대부분을 막을 수 있어. 서버에서 웹서비스를 운영한다면 80, 443 포트를 열어야 하고, 그 외에 사용하지 않는 포트는 모두 닫는 게 맞아.
STEP 6. Fail2ban 설치 – 무차별 대입 공격 차단
UFW가 특정 포트로의 접근을 통제한다면, Fail2ban은 그 포트를 통해 들어온 연결 중에서 이상한 패턴을 보이는 IP를 자동으로 차단해주는 도구야. 예를 들어 SSH에 비밀번호를 계속 틀리는 IP가 있으면 일정 횟수 초과 시 자동으로 차단 목록에 올려서 더 이상 접속 시도 자체를 막아버려.
Fail2ban은 로그 파일을 실시간으로 모니터링해서 이상 패턴을 감지하는 방식으로 동작해. SSH뿐만 아니라 Apache, Nginx, MySQL 등 다양한 서비스에 적용할 수 있어서 한번 설정해두면 여러 면에서 유용하게 써먹을 수 있어.
jail.local 파일에서 [DEFAULT] 섹션과 [sshd] 섹션을 찾아서 아래 내용으로 수정해줘.
기본값인 3600초(1시간)도 괜찮지만, 더 강하게 설정하고 싶다면 86400(24시간)이나 604800(7일)으로 늘려도 돼. 내 IP가 실수로 차단됐을 때는 sudo fail2ban-client set sshd unbanip [IP주소]로 해제할 수 있어.
Fail2ban이 제대로 동작하면 /var/log/fail2ban.log 파일에서 차단 기록을 확인할 수 있어. 설치 후 며칠 지나서 로그를 보면 얼마나 많은 공격 시도가 있었는지 실감할 수 있을 거야. 생각보다 훨씬 많아서 놀랄 수도 있어.
보안 설정 전후 위험도 비교 데이터
보안 설정이 실제로 얼마나 효과적인지 수치로 보면 동기부여가 훨씬 잘 돼. 아래 데이터는 일반적인 VPS 환경에서 보안 설정 적용 전후의 차이를 나타낸 거야. 물론 서버 환경에 따라 다를 수 있지만, 기본 보안 설정만 해도 이 정도 차이가 난다는 걸 보여주는 참고 자료로 봐줘.
10단계 보안 설정 진행 현황
이 가이드의 전체 흐름을 타임라인으로 보면 각 단계가 어떻게 연결되는지 파악하기 쉬워. 앞 단계가 뒷 단계의 기반이 되는 구조라서 순서를 지키는 게 중요해.
| 보안 항목 | 적용 전 | 적용 후 | 난이도 |
|---|---|---|---|
| 시스템 취약점 | 높음 | 낮음 | 쉬움 |
| SSH 브루트포스 | 취약 | 차단 | 보통 |
| 포트 스캔 노출 | 높음 | 낮음 | 쉬움 |
| 자동화 공격 대응 | 없음 | 자동 차단 | 보통 |
| 이상 징후 감지 | 없음 | 모니터링 | 보통 |
STEP 7. 자동 보안 업데이트 설정 – 손 안 대도 최신 상태 유지
패키지를 최신 상태로 유지하는 게 보안의 기본인데, 매번 수동으로 apt update && apt upgrade를 실행하는 건 현실적으로 꾸준히 하기 어려워. unattended-upgrades 패키지를 사용하면 보안 관련 업데이트만 자동으로 설치되도록 설정할 수 있어.
전체 패키지를 자동 업그레이드하면 서비스가 중단될 수 있어서, 보통은 보안 패치만 자동으로 적용하고 나머지는 수동으로 관리하는 방식을 써. Ubuntu는 이 기능을 기본 패키지로 제공하고 있어서 설치와 설정이 비교적 간단해.
/etc/apt/apt.conf.d/20auto-upgrades 파일에 아래 내용이 있으면 정상이야.
APT::Periodic::Update-Package-Lists “1”;
APT::Periodic::Unattended-Upgrade “1”;
STEP 8-10. 마무리 3단계 – 서비스 정리, 로그 모니터링, 최종 점검
앞의 7단계로 핵심 보안 설정은 마무리됐어. 이제 마지막 3단계를 빠르게 처리해보자. 이 부분은 서버를 더 가볍고 안전하게 유지하는 데 도움이 되는 내용들이야.
- 시스템 패키지가 최신 버전으로 업데이트됐는가
- root 계정으로 SSH 접속이 차단됐는가
- SSH 키 인증이 정상 동작하는가
- 비밀번호 로그인이 비활성화됐는가
- SSH 포트가 기본 22번에서 변경됐는가
- UFW 방화벽이 활성화되어 있고 필요한 포트만 열려 있는가
- Fail2ban이 실행 중이고 sshd 감시가 활성화됐는가
- 자동 보안 업데이트가 설정됐는가
- 불필요한 서비스가 비활성화됐는가
- 로그 모니터링 방법을 파악하고 있는가
자주 묻는 질문 (FAQ)
완전히 안전해지는 건 아니야. 포트 스캐너를 돌리면 변경된 포트도 결국 발견되거든. 하지만 자동화된 봇들은 대부분 22번 포트만 스캔하기 때문에, 포트를 바꾸는 것만으로도 자동화 공격의 상당수를 피할 수 있어. auth.log를 보면 포트 변경 전후 차이가 확연하게 보여.
포트 변경은 “보안 강화”라기보다는 “불필요한 노이즈 차단”에 가까워. SSH 키 인증과 Fail2ban이 실질적인 보안을 담당하고, 포트 변경은 거기에 더해지는 추가 방어선이라고 생각하면 돼.
클라우드 서비스를 사용 중이라면 웹 콘솔에서 직접 접속하거나 서버를 재시작해서 복구 모드로 들어가는 방법이 있어. AWS는 EC2 Serial Console, Oracle Cloud는 Cloud Shell을 통해 키 없이 접속할 수 있어.
예방 차원에서 SSH 키를 여러 군데 백업해두는 걸 추천해. 로컬 PC의 ~/.ssh 폴더를 외장하드나 클라우드 스토리지에 주기적으로 백업해두면 돼. 그리고 서버에 authorized_keys를 2개 이상 등록해두면 하나를 잃어버려도 다른 키로 접속할 수 있어.
가능하면 둘 다 설정하는 게 좋아. 클라우드 방화벽(Security Group, Firewall Rules 등)은 서버에 트래픽이 도달하기 전에 차단하는 역할을 하고, UFW는 서버 내부에서 한 번 더 필터링을 해. 이중 방어 구조가 되는 거야.
클라우드 방화벽만 쓰고 UFW를 끄는 사람도 있는데, UFW가 있으면 서버 내부에서 발생하는 비정상적인 트래픽도 통제할 수 있어서 같이 쓰는 게 더 안전해.
클라우드 콘솔이나 다른 IP에서 서버에 접속한 다음 아래 명령어로 해제할 수 있어.
sudo fail2ban-client set sshd unbanip [차단된IP주소]
이런 상황을 예방하려면 앞서 말했던 것처럼 jail.local의 ignoreip에 내 고정 IP를 미리 등록해두는 게 좋아. 고정 IP가 없다면 VPN을 사용하고 VPN IP를 등록해두는 방법도 있어.
거의 동일하게 적용돼. Ubuntu 22.04와 24.04는 같은 Debian 계열이고 명령어 구조가 거의 같거든. 다만 Ubuntu 24.04에서 SSH 설정 파일 구조가 조금 변경된 부분이 있어서, sshd_config 대신 /etc/ssh/sshd_config.d/ 디렉토리에 별도 파일로 설정하는 방식을 권장하는 경우도 있어.
Ubuntu 22.04 LTS는 2027년까지 지원이 되고, 24.04 LTS는 2029년까지 지원돼. 신규 서버라면 24.04로 시작하는 게 좋아.
거의 없어. UFW와 Fail2ban이 약간의 리소스를 쓰긴 하지만 체감할 수준이 아니야. 오히려 브루트포스 공격을 Fail2ban이 차단해주기 때문에 불필요한 SSH 연결 처리가 줄어들어서 성능에 긍정적인 영향을 줄 수도 있어.
메모리 사용량도 미미해. Fail2ban은 보통 30-50MB 정도를 사용하고, UFW 자체는 커널 수준에서 동작해서 별도 프로세스 부담이 거의 없어.
핵심 내용 요약
- root 직접 로그인 완전 차단
- SSH 키 인증으로 비밀번호 로그인 제거
- SSH 포트를 기본 22번에서 변경
- UFW로 필요한 포트만 개방
- Fail2ban으로 반복 공격 IP 자동 차단
- unattended-upgrades로 보안 패치 자동 적용
- auth.log와 fail2ban.log 주기적 확인
- 불필요한 서비스 주기적으로 정리
- SSH 키 백업 및 복구 방법 숙지
