보안 강화 및 Fail2ban 완벽 가이드

서버 보안의 핵심인 Fail2ban 설정부터 방화벽, TLS 암호화까지 메일 서버를 안전하게 지키는 방법을 알아봅니다. 초급 개발자도 쉽게 따라할 수 있는 실무 중심의 보안 가이드입니다.

---

목차

1. Fail2ban_설정_및_jail_구성
2. SMTP_인증_무차별_대입_방어
3. 포트_보안_및_방화벽_규칙
4. TLS_암호화_강화_설정
5. 헤더_정보_노출_최소화
6. 정기_보안_점검_체크리스트

---

1. Fail2ban 설정 및 jail 구성

김개발 씨는 어느 날 아침 출근해서 서버 로그를 확인하다가 깜짝 놀랐습니다. 밤새 수천 건의 SSH 로그인 시도가 있었던 것입니다.

누군가 무차별적으로 비밀번호를 대입하며 서버에 침입하려 했습니다. "이런 공격을 어떻게 막을 수 있을까요?"

Fail2ban은 한마디로 서버의 경비원입니다. 로그 파일을 실시간으로 감시하다가 수상한 행동을 발견하면 해당 IP를 자동으로 차단합니다.

마치 아파트 경비원이 수상한 사람을 발견하면 출입을 막는 것과 같습니다. 이것을 제대로 설정하면 무차별 대입 공격으로부터 서버를 안전하게 보호할 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/fail2ban/jail.local 설정 파일
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400

# Fail2ban 서비스 시작 및 상태 확인
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

김개발 씨는 입사 6개월 차 주니어 시스템 관리자입니다. 어느 날 서버 모니터링을 하던 중 이상한 점을 발견했습니다.

인증 로그에 실패한 SSH 접속 시도가 수천 건이나 기록되어 있었습니다. "이게 다 뭐죠?" 김개발 씨가 당황하며 물었습니다.

옆자리의 박시니어 씨가 모니터를 들여다봅니다. "아, 이건 브루트포스 공격이에요.

봇이 무작위로 비밀번호를 대입하는 거죠." 그렇다면 Fail2ban이란 정확히 무엇일까요? 쉽게 비유하자면, Fail2ban은 마치 은행의 보안 시스템과 같습니다.

누군가 ATM에서 비밀번호를 여러 번 틀리면 카드가 자동으로 잠기잖아요? Fail2ban도 마찬가지입니다.

누군가 서버에 로그인을 여러 번 실패하면 그 IP 주소를 자동으로 차단해버립니다. Fail2ban이 없던 시절에는 어땠을까요?

관리자들은 로그를 일일이 확인하며 수상한 IP를 수동으로 차단해야 했습니다. 밤새 공격이 들어와도 출근해서야 알 수 있었습니다.

더 큰 문제는 공격자들이 수백, 수천 개의 서로 다른 IP로 공격해 온다는 점이었습니다. 인력으로 대응하기엔 한계가 명확했습니다.

바로 이런 문제를 해결하기 위해 Fail2ban이 등장했습니다. Fail2ban을 사용하면 24시간 자동으로 서버를 감시할 수 있습니다.

또한 정해진 규칙에 따라 일관되게 대응합니다. 무엇보다 관리자가 잠든 밤에도 서버가 스스로를 지킬 수 있다는 큰 이점이 있습니다.

위의 설정 파일을 한 줄씩 살펴보겠습니다. 먼저 [DEFAULT] 섹션은 모든 jail에 적용되는 기본 설정입니다.

bantime = 3600은 차단 시간이 3600초, 즉 1시간이라는 뜻입니다. findtime = 600은 10분 동안의 시도 횟수를 기준으로 판단합니다.

maxretry = 5는 5번 실패하면 차단한다는 의미입니다. ignoreip 설정은 매우 중요합니다.

여기에 적힌 IP는 절대 차단하지 않습니다. 자기 자신과 내부 네트워크를 적어두면 실수로 자신이 차단되는 불상사를 막을 수 있습니다.

[sshd] 섹션은 SSH 서비스에 대한 개별 설정입니다. enabled = true로 활성화하고, maxretry = 3으로 기본값보다 더 엄격하게 설정했습니다.

SSH는 서버의 관문이니까요. bantime = 86400은 24시간 차단을 의미합니다.

실제 현업에서는 어떻게 활용할까요? 웹 서비스를 운영한다면 SSH뿐만 아니라 웹 서버, 메일 서버 등 다양한 서비스에 Fail2ban을 적용합니다.

특히 공개된 서버는 항상 공격에 노출되어 있으므로 필수적입니다. 클라우드 환경에서도 Fail2ban은 기본으로 설치하는 보안 도구 중 하나입니다.

하지만 주의할 점도 있습니다. 초보 관리자들이 흔히 하는 실수 중 하나는 ignoreip에 자신의 IP를 넣지 않는 것입니다.

비밀번호를 몇 번 잘못 입력하면 자기 자신이 차단되어 서버에 접속할 수 없게 됩니다. 이런 상황이 되면 서버 콘솔에 직접 접근해야만 해제할 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 도움으로 Fail2ban을 설정한 김개발 씨는 다음 날 로그를 확인했습니다.

여전히 공격 시도는 있었지만, 대부분 3번 만에 차단되어 더 이상 진행되지 않았습니다. "이제 좀 안심이 되네요!"

실전 팁

💡 - fail2ban-client status 명령으로 현재 차단된 IP 목록을 확인하세요

• 정상적인 사용자가 차단되었다면 fail2ban-client set sshd unbanip [IP]로 해제할 수 있습니다
• jail.local 파일은 jail.conf를 복사해서 만들고, 원본은 건드리지 마세요

---

2. SMTP 인증 무차별 대입 방어

박시니어 씨가 김개발 씨에게 다급하게 말했습니다. "메일 서버 로그 좀 봐봐요.

SMTP 인증 실패가 비정상적으로 많아요." 확인해보니 공격자들이 메일 계정을 탈취하기 위해 수천 개의 비밀번호를 시도하고 있었습니다. 메일 서버도 보호가 필요했습니다.

SMTP 인증 공격은 메일 서버에 무차별로 로그인을 시도하여 계정을 탈취하려는 공격입니다. 마치 도둑이 아파트의 모든 현관문 비밀번호를 하나씩 눌러보는 것과 같습니다.

이 공격이 성공하면 스팸 메일 발송에 악용되거나 중요한 업무 메일이 유출될 수 있습니다. Fail2ban으로 SMTP 서비스도 보호해야 합니다.

다음 코드를 살펴봅시다.

# /etc/fail2ban/jail.local에 추가
[postfix-sasl]
enabled = true
port = smtp,ssmtp,submission
filter = postfix-sasl
logpath = /var/log/mail.log
maxretry = 3
bantime = 86400
findtime = 300

[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps
filter = dovecot
logpath = /var/log/mail.log
maxretry = 3
bantime = 86400

# 설정 적용 후 확인
sudo fail2ban-client reload
sudo fail2ban-client status postfix-sasl

김개발 씨는 회사의 메일 서버 관리도 맡게 되었습니다. SSH는 Fail2ban으로 잘 보호하고 있었는데, 메일 서버는 미처 신경 쓰지 못했습니다.

어느 날 스팸 메일 신고가 들어오기 시작했습니다. "우리 회사 메일 주소로 이상한 메일이 왔어요." 직원들의 항의가 빗발쳤습니다.

조사해보니 누군가 직원 한 명의 메일 계정을 탈취해서 스팸을 보내고 있었습니다. 박시니어 씨가 설명합니다.

"SMTP 무차별 대입 공격을 당한 거예요. 메일 서버도 SSH처럼 보호해야 해요." 메일 서버 보안이 왜 중요할까요?

메일은 업무의 핵심입니다. 계약서, 견적서, 내부 기밀 문서가 메일로 오갑니다.

메일 계정이 탈취되면 단순히 스팸 발송 문제로 끝나지 않습니다. 중요한 거래처와의 대화 내용이 유출될 수 있고, 사칭 메일로 금전적 피해를 입을 수도 있습니다.

공격자들은 왜 메일 서버를 노릴까요? 첫째, 메일 서버는 외부에 열려 있어야 합니다.

메일을 주고받으려면 어쩔 수 없죠. 둘째, 많은 사용자들이 약한 비밀번호를 사용합니다.

셋째, 한번 탈취에 성공하면 스팸 발송 인프라로 악용할 수 있습니다. 스패머들에게 메일 서버는 황금알을 낳는 거위입니다.

위의 설정을 자세히 살펴보겠습니다. **[postfix-sasl]**은 메일 발송(SMTP) 인증을 보호합니다.

port = smtp,ssmtp,submission은 메일 발송에 사용되는 포트들입니다. 25번(smtp), 465번(ssmtp), 587번(submission)이 여기에 해당합니다.

findtime = 300은 5분으로 설정하여 SSH보다 더 민감하게 반응합니다. **[dovecot]**은 메일 수신(IMAP/POP3) 인증을 보호합니다.

메일을 가져가는 것도 보호해야 합니다. 계정 정보가 탈취되면 모든 메일을 읽어갈 수 있으니까요.

filter 항목은 어떤 로그 패턴을 감지할지 정의합니다. Fail2ban에는 이미 postfix-sasl과 dovecot용 필터가 내장되어 있습니다.

/etc/fail2ban/filter.d/ 디렉토리에서 확인할 수 있습니다. 실무에서 추가로 고려해야 할 점이 있습니다.

메일 클라이언트가 비밀번호를 잘못 저장한 경우, 계속 실패 시도가 발생할 수 있습니다. 이런 경우 정상 사용자가 차단될 수 있으므로 ignoreip에 신뢰할 수 있는 IP 대역을 추가하는 것이 좋습니다.

또한 차단 알림을 메일이나 슬랙으로 받도록 설정하면 문제를 빠르게 인지할 수 있습니다. 김개발 씨는 설정을 완료하고 며칠간 모니터링했습니다.

하루에도 수백 건의 SMTP 인증 공격이 시도되었지만, 모두 3번 만에 차단되었습니다. "메일 서버가 이렇게 많이 공격받는 줄 몰랐어요." 김개발 씨가 감탄했습니다.

실전 팁

💡 - /var/log/mail.log를 정기적으로 확인하여 공격 패턴을 파악하세요

• 사용자들에게 강력한 비밀번호 정책을 적용하고, 가능하면 2단계 인증을 도입하세요
• fail2ban-client status postfix-sasl로 차단 현황을 모니터링하세요

---

3. 포트 보안 및 방화벽 규칙

"서버에 열린 포트가 너무 많은 것 같아요." 보안 감사에서 지적을 받은 김개발 씨는 당황했습니다. 필요한 포트만 열어두어야 한다는 것은 알지만, 어떤 포트가 꼭 필요한 건지 정확히 몰랐습니다.

박시니어 씨가 방화벽 설정의 기본 원칙을 알려주기로 했습니다.

방화벽은 서버로 들어오고 나가는 네트워크 트래픽을 제어하는 보안 시스템입니다. 마치 공항 보안검색대처럼 허가된 것만 통과시키고 나머지는 차단합니다.

기본 원칙은 **"모두 차단하고, 필요한 것만 허용"**입니다. 이것을 화이트리스트 방식이라고 합니다.

다음 코드를 살펴봅시다.

# UFW(Uncomplicated Firewall) 기본 설정
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 필수 서비스 포트만 허용
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 25/tcp comment 'SMTP'
sudo ufw allow 587/tcp comment 'SMTP Submission'
sudo ufw allow 993/tcp comment 'IMAPS'
sudo ufw allow 443/tcp comment 'HTTPS'

# 특정 IP에서만 관리 포트 허용
sudo ufw allow from 192.168.1.0/24 to any port 22

# 방화벽 활성화 및 상태 확인
sudo ufw enable
sudo ufw status verbose

김개발 씨가 서버에 접속해서 열린 포트를 확인했습니다. SSH, HTTP, HTTPS는 물론이고 MySQL, Redis, 그리고 이름 모를 여러 포트가 외부에 열려 있었습니다.

박시니어 씨가 고개를 저었습니다. "이건 마치 집 현관문뿐만 아니라 모든 창문을 활짝 열어둔 것과 같아요.

도둑이 어디로 들어올지 몰라요." 방화벽의 기본 원칙을 이해해야 합니다. 보안에서는 최소 권한의 원칙이 중요합니다.

필요한 것만 허용하고 나머지는 모두 차단하는 것이죠. 이것을 화이트리스트 방식이라고 합니다.

반대로 특정 위험 요소만 차단하는 것은 블랙리스트 방식인데, 보안 관점에서는 화이트리스트가 더 안전합니다. 왜 화이트리스트가 더 안전할까요?

새로운 취약점이나 공격 방식은 계속 발견됩니다. 블랙리스트 방식은 새로운 위협을 목록에 추가해야만 막을 수 있습니다.

하지만 화이트리스트는 기본적으로 모든 것을 차단하므로, 새로운 위협에도 자동으로 대응됩니다. 설정 명령어를 하나씩 살펴보겠습니다.

sudo ufw default deny incoming은 들어오는 모든 연결을 기본적으로 차단합니다. 이것이 화이트리스트의 시작점입니다.

sudo ufw default allow outgoing은 나가는 연결은 허용합니다. 서버가 업데이트를 받거나 외부 API를 호출해야 하니까요.

이제 필요한 포트를 하나씩 열어줍니다. 22/tcp는 SSH 접속용입니다.

25/tcp는 외부에서 메일을 받기 위한 SMTP 포트입니다. 587/tcp는 인증된 사용자가 메일을 보내기 위한 포트입니다.

993/tcp는 암호화된 IMAP 접속을 위한 포트입니다. 특히 주목할 부분이 있습니다.

sudo ufw allow from 192.168.1.0/24 to any port 22는 SSH 접속을 특정 IP 대역에서만 허용합니다. 회사 내부 네트워크나 VPN에서만 SSH 접속이 가능하도록 제한하는 것입니다.

이렇게 하면 외부의 SSH 공격을 원천 차단할 수 있습니다. 많은 사람들이 놓치는 부분이 있습니다.

POP3(110번) 대신 IMAPS(993번)를 사용하고, SMTP(25번)는 서버 간 통신용으로만 열어두세요. 사용자들의 메일 발송은 587번 포트를 통해야 합니다.

또한 HTTP(80번)는 HTTPS로 리다이렉트만 하고, 실제 서비스는 HTTPS(443번)로만 제공하세요. 김개발 씨는 불필요한 포트를 모두 닫고, 꼭 필요한 포트만 열어두었습니다.

다음 보안 감사에서 "포트 관리가 잘 되어 있네요"라는 칭찬을 들었습니다.

실전 팁

💡 - sudo ufw status numbered로 규칙 번호를 확인하고, sudo ufw delete [번호]로 삭제할 수 있습니다

• 원격 서버에서 방화벽 설정 시 SSH 포트를 먼저 허용하세요. 실수로 차단하면 접속이 불가능해집니다
• sudo netstat -tlnp로 현재 열린 포트와 프로세스를 확인할 수 있습니다

---

4. TLS 암호화 강화 설정

"요즘 TLS 1.0이나 1.1은 안전하지 않대요." 김개발 씨가 보안 뉴스를 읽다가 말했습니다. 박시니어 씨가 고개를 끄덕입니다.

"맞아요. 오래된 암호화 방식은 이미 깨졌어요.

TLS 1.2 이상만 허용하도록 설정해야 해요."

**TLS(Transport Layer Security)**는 네트워크 통신을 암호화하는 프로토콜입니다. 마치 중요한 편지를 암호화된 금고에 넣어 보내는 것과 같습니다.

하지만 오래된 버전의 TLS는 자물쇠가 낡아서 열쇠 없이도 열 수 있게 되었습니다. 최신 버전만 사용해야 통신이 안전합니다.

다음 코드를 살펴봅시다.

# /etc/postfix/main.cf - Postfix TLS 설정
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4

# /etc/dovecot/conf.d/10-ssl.conf - Dovecot TLS 설정
ssl = required
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5

# TLS 인증서 경로 설정
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem

김개발 씨는 암호화에 대해 잘 몰랐습니다. "어차피 HTTPS 쓰면 되는 거 아니에요?" 하고 생각했습니다.

하지만 박시니어 씨의 설명을 듣고 생각이 바뀌었습니다. "TLS 버전마다 보안 강도가 달라요.

오래된 버전은 이미 취약점이 발견되어서 공격자가 통신 내용을 엿볼 수 있어요." TLS의 역사를 간단히 알아봅시다. SSL 2.0과 3.0은 이미 오래전에 폐기되었습니다.

TLS 1.0과 1.1도 2020년에 공식적으로 지원이 중단되었습니다. 현재는 TLS 1.2와 TLS 1.3만 안전하다고 인정받습니다.

특히 TLS 1.3은 더 빠르고 더 안전합니다. 설정 파일을 자세히 살펴보겠습니다.

Postfix 설정에서 smtpd_tls_protocols의 느낌표(!)는 "사용하지 않음"을 의미합니다. !SSLv2, !SSLv3, !TLSv1, !TLSv1.1은 이 네 가지 프로토콜을 비활성화한다는 뜻입니다.

결과적으로 TLS 1.2와 TLS 1.3만 사용됩니다. smtpd_tls_ciphers = high는 강력한 암호화 알고리즘만 사용하겠다는 설정입니다.

smtpd_tls_exclude_ciphers에서는 알려진 취약한 알고리즘들을 명시적으로 제외합니다. MD5, DES, 3DES, RC4는 모두 이미 깨진 알고리즘입니다.

Dovecot 설정도 비슷합니다. ssl = required는 암호화 없이는 접속할 수 없게 합니다.

평문 통신을 완전히 차단하는 것입니다. ssl_min_protocol = TLSv1.2는 최소 TLS 버전을 1.2로 지정합니다.

ssl_cipher_list에서는 사용할 암호화 방식을 구체적으로 나열합니다. 인증서 설정도 중요합니다.

Let's Encrypt의 무료 인증서를 사용하면 됩니다. fullchain.pem은 인증서 체인 전체를 포함하고, privkey.pem은 개인 키입니다.

인증서는 90일마다 갱신해야 하므로 자동 갱신 스크립트를 설정해두세요. 실무에서 주의할 점이 있습니다.

너무 엄격한 설정은 오래된 메일 클라이언트와의 호환성 문제를 일으킬 수 있습니다. 하지만 보안을 위해서는 어느 정도 감수해야 합니다.

오래된 클라이언트 사용자에게는 업그레이드를 권고하세요. 김개발 씨가 설정을 적용한 후 SSL Labs의 테스트 도구로 점검했습니다.

A+ 등급이 나왔습니다. "이제 안심이 되네요!"

실전 팁

💡 - testssl.sh 도구로 TLS 설정을 점검할 수 있습니다

• Let's Encrypt 인증서 자동 갱신은 certbot renew --quiet을 크론에 등록하세요
• TLS 1.3을 지원하는 최신 소프트웨어 버전을 사용하세요

---

5. 헤더 정보 노출 최소화

"메일 헤더에 서버 정보가 다 노출되어 있어요." 보안 컨설턴트의 말에 김개발 씨는 깜짝 놀랐습니다. 메일 헤더를 확인해보니 서버 소프트웨어 버전, 내부 IP 주소까지 모두 드러나 있었습니다.

공격자에게 좋은 정보를 제공하고 있었던 것입니다.

메일 헤더는 편지 봉투에 적힌 정보와 같습니다. 보내는 사람, 받는 사람, 경유지 등이 기록됩니다.

문제는 여기에 서버 소프트웨어 버전, 내부 네트워크 구조 같은 민감한 정보까지 포함될 수 있다는 것입니다. 이런 정보는 공격자에게 취약점을 찾는 힌트가 됩니다.

다음 코드를 살펴봅시다.

# /etc/postfix/main.cf - 헤더 정보 최소화
smtpd_banner = $myhostname ESMTP
mail_name = Mail Server

# 헤더 검사 설정
header_checks = regexp:/etc/postfix/header_checks

# /etc/postfix/header_checks 파일 생성
# 내부 IP 주소 제거
/^Received:.*\[10\..*\]/     IGNORE
/^Received:.*\[192\.168\..*\]/     IGNORE
/^Received:.*\[172\.(1[6-9]|2[0-9]|3[01])\..*\]/     IGNORE
# 클라이언트 정보 제거
/^X-Originating-IP:/     IGNORE
/^X-Mailer:/     IGNORE
/^User-Agent:/     IGNORE

# 설정 적용
sudo postmap /etc/postfix/header_checks
sudo systemctl reload postfix

김개발 씨는 자신이 보낸 메일의 원본 헤더를 처음 확인해봤습니다. 생각보다 많은 정보가 담겨 있었습니다.

서버 소프트웨어 이름과 버전, 메일이 거쳐온 모든 서버의 IP 주소, 심지어 사용한 메일 클라이언트 정보까지. "이게 왜 문제인가요?" 김개발 씨가 물었습니다.

박시니어 씨가 설명합니다. "공격자 입장에서 생각해봐요.

Postfix 3.5.6을 사용한다는 걸 알면, 그 버전의 알려진 취약점을 바로 시도해볼 수 있어요. 내부 IP 구조를 알면 네트워크 구성을 파악할 수 있고요." 이것을 정보 노출 취약점이라고 합니다.

보안에서는 불필요한 정보는 숨기는 것이 원칙입니다. 공격자가 아는 정보가 적을수록 공격 성공 확률이 낮아집니다.

이것을 "Security through Obscurity"라고 하는데, 그 자체로는 완벽한 보안이 아니지만 다른 보안 조치와 함께 사용하면 효과적입니다. 설정을 하나씩 살펴보겠습니다.

smtpd_banner는 메일 서버에 접속했을 때 보여주는 인사말입니다. 기본값에는 Postfix 버전이 포함되어 있는데, 이것을 최소한의 정보만 표시하도록 변경합니다.

$myhostname ESMTP만 표시하면 충분합니다. header_checks는 정규표현식으로 헤더를 검사하고 수정합니다.

IGNORE는 해당 헤더를 삭제한다는 의미입니다. 내부 IP 주소를 제거하는 규칙을 보겠습니다.

**10.***로 시작하는 IP는 사설 IP 대역입니다. **192.168.***도 마찬가지입니다.

**172.16.***부터 **172.31.***까지도 사설 IP입니다. 이런 내부 네트워크 정보가 외부로 나가면 안 됩니다.

X-Originating-IP, X-Mailer, User-Agent 헤더는 메일을 보낸 클라이언트의 정보를 담고 있습니다. 발신자의 IP 주소나 사용 중인 프로그램 정보가 노출되면 개인정보 침해는 물론 표적 공격에 활용될 수 있습니다.

하지만 주의할 점이 있습니다. Received 헤더를 모두 제거하면 메일 추적이 불가능해집니다.

스팸 신고나 문제 해결 시 어려움이 생길 수 있습니다. 따라서 내부 IP만 선택적으로 제거하는 것이 좋습니다.

외부 공개 IP는 남겨두세요. 김개발 씨는 설정을 적용한 후 테스트 메일을 보내고 헤더를 확인했습니다.

불필요한 정보가 깔끔하게 제거되어 있었습니다. "이제 공격자에게 힌트를 주지 않겠네요!"

실전 팁

💡 - 테스트 메일을 보내서 헤더가 제대로 정리되었는지 확인하세요

• Gmail에서 "원본 보기"로 메일 헤더를 쉽게 확인할 수 있습니다
• 너무 많은 헤더를 제거하면 메일이 스팸으로 분류될 수 있으니 주의하세요

---

6. 정기 보안 점검 체크리스트

"보안 설정은 한 번 하고 끝이 아니에요." 박시니어 씨가 강조했습니다. 시스템은 계속 변하고, 새로운 취약점은 매일 발견됩니다.

김개발 씨는 정기적으로 점검할 항목들을 체크리스트로 만들기로 했습니다.

보안 점검은 건강검진과 같습니다. 아무리 건강한 사람도 정기적으로 검진을 받아야 숨은 질병을 발견할 수 있습니다.

서버도 마찬가지입니다. 정기적인 점검으로 새로운 취약점, 설정 오류, 이상 징후를 조기에 발견해야 합니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# /usr/local/bin/security-check.sh - 보안 점검 스크립트

echo "=== 보안 점검 시작: $(date) ==="

# 1. Fail2ban 상태 확인
echo "[1] Fail2ban 상태"
fail2ban-client status | grep "Jail list"

# 2. 현재 차단된 IP 수 확인
echo "[2] 차단된 IP 현황"
fail2ban-client status sshd | grep "Currently banned"
fail2ban-client status postfix-sasl | grep "Currently banned"

# 3. 방화벽 규칙 확인
echo "[3] UFW 방화벽 상태"
ufw status | head -20

# 4. 열린 포트 확인
echo "[4] 외부 열린 포트"
ss -tlnp | grep LISTEN

# 5. SSL 인증서 만료일 확인
echo "[5] SSL 인증서 만료일"
openssl x509 -enddate -noout -in /etc/letsencrypt/live/mail.example.com/cert.pem

# 6. 최근 로그인 실패 시도
echo "[6] 최근 SSH 로그인 실패 (최근 24시간)"
grep "Failed password" /var/log/auth.log | tail -10

echo "=== 보안 점검 완료 ==="

김개발 씨는 이제 서버 보안에 자신감이 생겼습니다. Fail2ban도 설정하고, 방화벽도 구성하고, TLS도 강화했습니다.

하지만 박시니어 씨가 한 가지를 더 강조했습니다. "보안은 지속적인 과정이에요.

설정하고 잊어버리면 안 돼요." 왜 정기 점검이 필요할까요? 첫째, 새로운 취약점은 매일 발견됩니다.

어제까지 안전했던 설정이 오늘 취약해질 수 있습니다. 둘째, 시스템이 변합니다.

업데이트, 설정 변경, 새로운 서비스 추가 등으로 보안 구멍이 생길 수 있습니다. 셋째, 공격자들도 진화합니다.

새로운 공격 기법이 계속 개발됩니다. 점검 스크립트를 살펴보겠습니다.

Fail2ban 상태 확인은 보안 시스템이 제대로 작동하는지 확인합니다. 서비스가 중지되어 있으면 큰일입니다.

차단된 IP 수를 보면 공격이 얼마나 들어오는지 감을 잡을 수 있습니다. 방화벽 규칙 확인도 중요합니다.

누군가 임시로 포트를 열었다가 닫지 않은 경우가 있을 수 있습니다. 열린 포트 목록과 방화벽 규칙이 일치하는지 확인해야 합니다.

SSL 인증서 만료일은 놓치기 쉬운 항목입니다. 인증서가 만료되면 메일 송수신이 안 될 수 있습니다.

자동 갱신을 설정했더라도 제대로 작동하는지 확인이 필요합니다. 로그인 실패 시도는 공격 패턴을 파악하는 데 도움이 됩니다.

특정 IP에서 집중적으로 시도한다면 해당 대역을 영구 차단하는 것을 고려해야 합니다. 이 스크립트를 어떻게 활용할까요?

크론에 등록해서 매일 자동 실행하고, 결과를 메일로 받아보세요. 또는 주간 정기 회의 전에 수동으로 실행해서 상태를 확인하세요.

이상 징후가 발견되면 즉시 조치해야 합니다. 추가로 점검해야 할 항목들이 있습니다.

시스템 업데이트 상태를 확인하세요. apt list --upgradable로 보안 패치가 대기 중인지 확인합니다.

디스크 용량도 점검하세요. 로그가 쌓여서 디스크가 가득 차면 서비스가 중단될 수 있습니다.

백업이 제대로 되고 있는지도 확인해야 합니다. 김개발 씨는 이 스크립트를 크론에 등록하고 매일 아침 결과를 메일로 받아봅니다.

"이제 서버가 어떤 상태인지 매일 확인할 수 있어서 안심이 돼요." 박시니어 씨가 마지막으로 덧붙입니다. "보안은 기술만이 아니라 습관이에요.

꾸준히 점검하고 관심을 가지는 것이 가장 중요해요."

실전 팁

💡 - 점검 스크립트를 크론에 등록해서 자동화하세요: 0 9 * * * /usr/local/bin/security-check.sh | mail -s "Security Report" admin@example.com

• 보안 뉴스레터를 구독해서 새로운 취약점 정보를 받아보세요
• 연 1회 이상 외부 보안 전문가의 감사를 받는 것도 좋습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!