SSH 보안 강화 - 서버의 첫 번째 방어선
SSH는 Linux 서버에 원격 접속하는 가장 기본적인 방법이다. 그만큼 공격자들이 가장 먼저 노리는 지점이기도 하다. 기본 포트인 22번으로 서버를 열어두면, 하루에 수천 건의 로그인 시도가 들어온다.
드롭인 설정 파일로 하드닝하기 (Ubuntu 24.04 권장 방식)
Ubuntu 24.04 LTS부터는 /etc/ssh/sshd_config 본 파일을 직접 건드리지 않고, /etc/ssh/sshd_config.d/ 디렉터리에 별도의 드롭인 파일을 두는 방식이 표준이다. 본 파일 상단의 Include /etc/ssh/sshd_config.d/*.conf 지시문이 이 디렉터리를 읽어들이기 때문에, 패키지 업데이트로 설정이 덮어써질 걱정 없이 안전하게 관리할 수 있다. 아래처럼 99-hardening.conf 파일을 만들어 핵심 하드닝 항목을 한곳에 모은다.
PermitRootLogin no로 root 직접 로그인을 차단하고, 일반 사용자로 접속한 뒤 sudo를 쓰는 습관을 들인다. MaxAuthTries 3은 한 세션당 인증 시도를 3회로 제한해 브루트포스를 강하게 옥죈다. AllowUsers로 접속 가능한 계정을 화이트리스트로 못 박으면 공격 표면이 크게 줄어든다. 기본 포트 22를 다른 번호로 바꾸면 자동화된 스캐닝의 상당수를 걸러낼 수 있지만, 이는 보조 수단일 뿐 키 인증 전환을 대체하지는 못한다. 설정을 적용하기 전에 반드시 두 번째 터미널을 열어둔 채로 sudo systemctl reload ssh를 실행해, 새 설정으로 접속이 막히는 사고를 예방한다.
SSH 키 인증으로 전환하기 - Ed25519와 FIDO2
비밀번호 인증은 아무리 복잡하게 설정해도 브루트포스에 취약하다. 키 기반 인증으로 전환하면 이 문제를 근본적으로 해결한다. 이제는 구형 RSA 대신 Ed25519 키를 표준으로 쓴다. ssh-keygen -t ed25519 -C "deploy@server"로 키 쌍을 생성하고, 공개키를 서버의 ~/.ssh/authorized_keys(권한 600)에 등록한 뒤, 위 드롭인의 PasswordAuthentication no로 비밀번호 로그인을 완전히 차단한다.
한 단계 더 나아가려면 YubiKey 같은 하드웨어 보안 키를 결합한 FIDO2 기반 ed25519-sk 키를 추천한다. ssh-keygen -t ed25519-sk로 생성하면 개인키가 물리 장치에 묶이므로, 서버가 침해돼도 키 자체를 탈취당하지 않는다. 2026년 들어 보안 권고가 일제히 "원격·관리자 접속에는 FIDO2/WebAuthn 같은 피싱 내성 MFA를 적용하라"는 방향으로 모이고 있어, 운영 서버라면 진지하게 고려할 만하다.
Fail2Ban으로 반복 로그인 시도 차단
Fail2Ban은 SSH 로그를 실시간으로 모니터링하다가 일정 횟수 이상 로그인에 실패한 IP를 자동으로 방화벽에서 차단해주는 도구다. 5회 실패 시 1시간 차단, 재차 시도 시 24시간 차단으로 설정하면 된다. 이 위협은 추상적인 가정이 아니다. 2026년 2월에는 약한 비밀번호 SSH를 노린 SSHStalker 봇넷이 7,000여 대의 리눅스 서버를 장악한 사례가 보고됐고, GPU 클러스터와 AI 기반 워드리스트로 무장한 봇넷이 서버 공개 직후 4분 안에 스캔을 시작한다. 키 인증 전환과 Fail2Ban은 이런 자동화 공격을 막는 가장 기본적인 방어선이다.
방화벽 설정 - 불필요한 문을 닫아라
Linux 서버 보안에서 방화벽은 외부와 내부를 나누는 가장 중요한 경계다. 필요한 포트만 열고 나머지는 전부 닫는 것이 기본 원칙이다.
UFW vs iptables vs firewalld 비교
| 항목 | UFW | iptables | firewalld |
|---|---|---|---|
| 난이도 | 쉬움 (초보 친화적) | 어려움 (직접 규칙 작성) | 보통 (zone 개념) |
| 유연성 | 보통 | 매우 높음 | 높음 |
| 주요 배포판 | Ubuntu/Debian | 전 배포판 공통 | CentOS/RHEL/Fedora |
| 추천 대상 | 개인 서버, 소규모 | 고급 사용자, 대규모 | 기업 환경, RHEL 계열 |
Ubuntu 서버라면 UFW를 추천한다. 한 가지 알아둘 점은, Ubuntu 24.04 LTS의 UFW는 내부적으로 iptables를 거치지만 그 iptables 자체가 nftables 백엔드로 동작한다는 것이다. nftables는 Ubuntu 20.10부터 기본 백엔드였으므로, 24.04에서는 별도 설정 없이도 최신 커널 방화벽 위에서 돌아간다. 실무에서는 UFW 명령만 쓰면 되고, 더 복잡한 규칙이 필요할 때만 nftables를 직접 다루면 된다.
ufw default deny incoming으로 인바운드를 전부 차단한 뒤, 필요한 포트만 연다. SSH 포트를 바꿨다면 ufw enable 전에 새 포트를 반드시 열어두어야 접속이 끊기지 않는다.
아웃바운드 규칙도 신경 쓸 것
많은 사람이 인바운드만 신경 쓰는데, 아웃바운드도 중요하다. 서버가 침해당했을 때 아웃바운드가 열려 있으면, 공격자가 외부 C2 서버로 데이터를 빼돌리거나 다른 서버를 공격하는 경유지로 악용될 수 있다.
사용자 및 권한 관리 - 최소 권한 원칙
sudo 권한 세밀하게 제어하기
/etc/sudoers 파일을 visudo로 편집하여 각 사용자가 실행할 수 있는 명령어를 제한할 수 있다. 배포 담당자에게는 systemctl restart nginx만 허용하고, 데이터베이스 관리자에게는 systemctl restart mysql만 허용하는 식이다.
불필요한 서비스와 계정 정리
systemctl list-unit-files --state=enabled로 활성화된 서비스 목록을 확인하고, 사용하지 않는 서비스는 과감하게 비활성화해야 한다. 열려 있는 서비스 하나하나가 잠재적인 공격 표면이다.
시스템 업데이트와 모니터링
자동 보안 업데이트와 needrestart
Ubuntu/Debian 계열에서는 unattended-upgrades 패키지로 보안 패치를 자동 적용한다. 설치 후 sudo dpkg-reconfigure --priority=low unattended-upgrades로 활성화하고, 동작은 /etc/apt/apt.conf.d/50unattended-upgrades에서 조정한다. CentOS/RHEL에서는 dnf-automatic이 같은 역할을 한다.
Ubuntu 24.04에서 특히 중요한 변화는 needrestart 연동이다. 라이브러리가 업데이트되면 그것을 사용하던 데몬이 재시작되기 전까지는 여전히 옛 취약점에 노출된 상태로 남는데, 24.04의 needrestart는 unattended-upgrade 같은 비대화형 상황에서도 영향받은 서비스를 자동으로 재시작하도록 바뀌었다. 재시작을 피하고 싶은 서비스는 /etc/needrestart/needrestart.conf의 override_rc 항목에 등록하면 된다. 커널 패치처럼 재부팅이 필요한 경우를 대비해 50unattended-upgrades에서 Automatic-Reboot와 재부팅 시각을 설정해 두는 것도 좋다.
AppArmor로 서비스 격리
Ubuntu는 기본으로 AppArmor를 탑재해 각 프로세스가 접근할 수 있는 파일·기능을 프로파일로 제한한다. sudo aa-status로 현재 강제(enforce) 모드인 프로파일을 확인할 수 있고, nginx·MySQL 같은 외부 노출 서비스는 가급적 enforce 모드로 두어야 한다. 설령 서비스가 침해되더라도 AppArmor 프로파일이 공격자의 횡적 이동과 권한 상승을 한 겹 더 막아준다.
로그 모니터링과 침입 탐지
/var/log/auth.log, /var/log/syslog를 정기적으로 확인하는 습관을 들여야 한다. AIDE나 OSSEC 같은 호스트 기반 침입 탐지 시스템(HIDS)을 설치하면 파일 시스템의 변경을 추적하고, 의심스러운 활동이 감지되면 알림을 보내준다.
파일 무결성 검사와 백업
보안 설정을 아무리 잘 해도 100% 안전한 서버는 없다. 최소 주 1회 전체 백업, 매일 증분 백업을 수행하고, 백업 데이터는 서버 외부에 보관해야 한다.
실전 팁과 추천 대상
SSH 접속 시 2FA 적용하기. Google Authenticator PAM 모듈을 설치하면 SSH 접속에 OTP 인증을 추가할 수 있다. 키 인증 + OTP 조합이면 사실상 뚫리기 매우 어렵다.
서버 세팅 직후 즉시 스냅샷 찍기. 클라우드 환경이라면 보안 설정을 모두 마친 "클린 상태"의 스냅샷을 저장해 둬야 한다. 문제가 생겼을 때 빠르게 복원할 수 있다.
Lynis로 보안 감사 자동화하기. lynis audit system 한 줄이면 서버의 전반적인 보안 상태를 점검해 준다.
커널 파라미터 튜닝. /etc/sysctl.conf에서 역방향 경로 필터링, Smurf 공격 방지 등을 설정하면 네트워크 레벨의 보안이 강화된다.
보안 설정을 코드로 관리하기. Ansible이나 Terraform으로 서버 보안 설정을 IaC로 관리하면, 새 서버를 프로비저닝할 때마다 동일한 보안 수준을 자동으로 적용할 수 있다.
추천 대상
- 개인 프로젝트용 VPS를 처음 세팅하는 개발자
- 스타트업에서 DevOps를 겸하는 백엔드 개발자
- 온프레미스 Linux 서버를 관리하는 시스템 관리자
- 클라우드 인프라를 학습 중인 학생
마무리
Linux 서버 보안은 거창한 것이 아니다. 드롭인 방식의 SSH 하드닝, Ed25519/FIDO2 키 인증으로의 전환, ufw 방화벽, needrestart 연동 자동 보안 업데이트, AppArmor 격리 - 이 다섯 가지만 확실히 해도 2026년 현재 기승을 부리는 봇넷 브루트포스를 포함한 대부분의 자동화 공격을 막을 수 있다. 중요한 건 "완벽한 보안"을 추구하다 아무것도 안 하는 것보다, 기본적인 것부터 하나씩 적용해 나가는 것이다.
