소개: 왜 testssl.sh인가?
서버의 HTTPS, 메일, 데이터베이스 등 다양한 서비스들이 TLS/SSL로 암호화되어야 하는 시대입니다. 하지만 “내 서버가 안전하게 설정되어 있을까?”라는 질문에는 즉답하기 어렵습니다. 이때 가볍고 강력한 오픈소스 스캐너인 testssl.sh가 빛을 발합니다. testssl.sh는 Bash 스크립트 하나로 원격 서버의 TLS/SSL 설정, 지원 프로토콜, 암호군, 인증서 체인, 알려진 취약점(Heartbleed, ROBOT, POODLE 등)을 빠르게 진단합니다.
이 글은 Ubuntu Server 24(예: 24.04 LTS)에 testssl.sh를 설치하고, 바로 실전 측정까지 진행하는 단계별 튜토리얼입니다. 초보자도 따라 하기 쉬운 명령 예시와 함께, 결과를 해석하고 보안 설정을 개선하는 방법까지 안내합니다.
- 누구를 위한 글인가요?
- Ubuntu Server 24 운영자, DevOps, SRE, 보안 담당자
- HTTPS/Nginx/Apache/Postfix 등을 운영하며 TLS 보안을 점검하고 싶은 분
- 얻을 수 있는 것
- testssl.sh를 빠르게 설치하는 3가지 방법
- 실제 서버/포트/서비스를 대상로 한 측정 명령어 모음
- 결과를 읽고, 실질적으로 보안을 강화하는 설정 예시
- 자동화/리포팅까지 연결하는 베스트 프랙티스
주의: 본문에서 소개하는 스캔은 반드시 소유하거나 허가받은 시스템에서만 수행하세요. 무단 스캔은 법적/정책적 문제가 될 수 있습니다.
사전 준비 사항
- Ubuntu Server 24.x (권장: 24.04 LTS)
- sudo 권한의 계정
- 인터넷 연결
- 기본 유틸리티: bash, curl, git, openssl (Ubuntu 24에는 기본적으로 포함되어 있으나, 부족 시 설치)
필요하면 다음으로 보완합니다:
sudo apt update
sudo apt install -y git curl openssl ca-certificates jq
- jq: JSON 결과를 후처리할 때 유용합니다.
- ca-certificates: 인증서 검증을 위한 루트 CA 번들을 최신으로 유지합니다.
testssl.sh 설치 방법 3가지
방법 1: APT로 간단 설치(가장 쉬움)
Ubuntu 24 리포지토리에는 보통 testssl.sh 패키지가 포함됩니다. 버전은 최신 GitHub 릴리스보다 약간 느릴 수 있지만, 안정적이고 간편합니다.
sudo apt update
sudo apt install -y testssl.sh
설치 확인:
testssl.sh --version
장점
- 설치/업데이트가 apt로 간편
- 의존성 자동 처리
주의
- 최신 취약점 체크가 필요하다면 Git 설치(방법 2)나 Docker(방법 3)로 최신 릴리스를 쓰는 것이 더 낫습니다.
방법 2: GitHub에서 최신 버전 설치(권장)
최신 기능과 시그니처로 스캔하려면 GitHub의 원본 저장소를 클론하는 방법이 좋습니다.
cd /opt
sudo git clone --depth 1 https://github.com/drwetter/testssl.sh.git
sudo chown -R $USER:$USER /opt/testssl.sh
편의상 PATH에 심볼릭 링크를 걸어 전역에서 호출 가능하게 만듭니다:
sudo ln -s /opt/testssl.sh/testssl.sh /usr/local/bin/testssl.sh
버전 확인 및 자체 업데이트:
testssl.sh --version
# 자체 업데이트(깃 설치 버전에서만):
/opt/testssl.sh/testssl.sh -U
# 또는 디렉터리에서 git pull:
cd /opt/testssl.sh && git pull
장점
- 최신 테스트 시그니처, 버그픽스 반영
- 고급 옵션 사용 시 호환성 우수
방법 3: Docker 컨테이너로 실행(환경 분리)
서버에 아무것도 설치하기 부담스럽거나, 실행 환경을 격리하고 싶다면 Docker 이미지 사용이 간단합니다.
docker run --rm -ti drwetter/testssl.sh --version
docker run --rm -ti drwetter/testssl.sh https://example.com
장점
- 호스트에 의존성 설치 없이 실행
- 재현성 높은 환경
주의
- 컨테이너에서 네트워크 접근이 가능해야 합니다(방화벽, DNS 등).
기본 사용법: 첫 스캔부터 결과 저장까지
testssl.sh는 기본적으로 “풀 스캔”을 수행합니다. 최소한의 인자로 시작해 보세요.
1) 가장 간단한 실행
testssl.sh https://example.com
# 또는
testssl.sh example.com:443
- URL 또는 호스트:포트 형식을 모두 지원합니다.
- 기본 포트는 443이므로 https:// 없이 도메인만 지정하면 :443으로 해석되기도 합니다.
2) 빠른 점검 모드(--fast)
시간을 줄이고 대략적인 상태만 보려면:
testssl.sh --fast example.com
- 운영 중인 대규모 호스트 리스트를 순회할 때 유용합니다.
3) 결과 저장(JSON, HTML, CSV)
리포팅/자동화에 활용하려면 결과 파일로 남겨두는 것이 좋습니다.
# 날짜를 붙여 저장
DATE=$(date +%F_%H%M)
testssl.sh --jsonfile results_$DATE.json --htmlfile results_$DATE.html --csvfile results_$DATE.csv example.com
- JSON: 후처리/알림 자동화에 최적
- HTML: 경영진/외부 공유에 보기 좋음
- CSV: 스프레드시트로 요약 분석
예: 취약점이 하나라도 발견되면 경고를 띄우는 간단한 체크
# vulns 배열에서 "VULNERABLE" 상태가 있는지 찾기
jq '.scanResult[]?.finding | select(.severity=="VULNERABLE")' results_$DATE.json
데이터 구조는 버전에 따라 조금 달라질 수 있으니, 스키마를 먼저 확인한 뒤 조건을 조정하세요.
4) IP 대상 + SNI 지정
같은 IP에 여러 도메인이 호스팅되어 있고 가상호스팅(SNI)을 쓰는 경우:
testssl.sh --sni www.example.com 203.0.113.10:443
- IP만 입력하면 기본 SNI가 없거나 틀릴 수 있어, 의도한 인증서/설정이 나오지 않을 수 있습니다. 반드시 --sni로 대상 호스트명을 지정하세요.
5) 커스텀 포트 테스트
HTTPS가 8443 등 비표준 포트에 있는 경우:
testssl.sh example.com:8443
서비스별 측정 예시
testssl.sh는 단순 웹서버 외에도 StartTLS를 포함한 다양한 프로토콜을 검사할 수 있습니다.
HTTPS(웹서버)
- 443 기본 포트:
testssl.sh https://www.example.com
- 프록시/관리콘솔 등 비표준 포트:
testssl.sh admin.example.com:8443
SMTP(메일 서버)
- SMTP StartTLS(기본 포트 25 또는 587):
# 25 포트 - 서버 간 전송(MTA)
testssl.sh --starttls smtp mail.example.com:25
# 587 포트 - 클라이언트 제출(SUBMISSION)
testssl.sh --starttls smtp mail.example.com:587
- SMTPS(암묵적 TLS, 465 포트):
testssl.sh mail.example.com:465
IMAP/POP3(메일 클라이언트 프로토콜)
- IMAP StartTLS(143 포트):
testssl.sh --starttls imap mail.example.com:143
- IMAPS(993 포트):
testssl.sh mail.example.com:993
- POP3 StartTLS(110 포트):
testssl.sh --starttls pop3 mail.example.com:110
- POP3S(995 포트):
testssl.sh mail.example.com:995
LDAP/LDAPS
# StartTLS
testssl.sh --starttls ldap ldap.example.com:389
# LDAPS
testssl.sh ldap.example.com:636
데이터베이스(PostgreSQL 예)
# PostgreSQL의 StartTLS
testssl.sh --starttls postgres db.example.com:5432
그 외 FTP, XMPP, RDP 등 여러 프로토콜에 대한 StartTLS 스위치를 지원합니다. 필요 시 testssl.sh --help로 지원 목록을 확인하세요.
출력 결과 해석 포인트
testssl.sh 결과는 항목이 많습니다. 초점을 맞추면 다음을 빠르게 판단할 수 있습니다.
-
인증서(Certificate)
- 유효기간(만료 예정일), 발급자, 체인(중간 인증서 포함), 키 타입(RSA/ECDSA), 키 길이, SAN 목록
- 자가서명, 체인 불완전, 만료 임박 등은 즉시 개선 필요
-
프로토콜 지원(SSL/TLS)
- 허용: TLS 1.2, TLS 1.3 권장
- 비활성화 권장: SSL 2.0/3.0, TLS 1.0/1.1
- TLS 1.3이 활성화되어 있다면 최신 모던 스택에 가까움
-
암호군(Cipher Suites) 및 서버 우선순위
- 약한 암호(3DES, RC4, EXPORT, NULL, aNULL, MD5 등)는 비활성화
- ECDHE 기반의 Forward Secrecy 제공 확인
- 서버가 암호 우선순위를 존중하도록 설정(서버가 강한 암호를 먼저 제시)
-
서명 알고리즘/곡선
- ECDSA 인증서 사용 시 P-256/P-384, X25519 등 모던 곡선 사용 권장
- RSA의 경우 2048비트 이상
-
확장/특성
- ALPN/NPN, HTTP/2 지원 여부
- HSTS 설정, OCSP Stapling 여부
-
취약점 검사
- Heartbleed, ROBOT, POODLE, BEAST, CRIME, BREACH, FREAK, DROWN, Logjam, Sweet32, Lucky13, CCS, Ticketbleed, 세션 재협상 취약성 등
- “VULNERABLE” 표기가 하나라도 있으면 즉시 조치
결과에 따른 보안 강화 가이드
아래는 testssl.sh 결과를 바탕으로 가장 자주 하는 개선 작업과 설정 예시입니다. 서비스에 맞게 조정하세요.
Nginx(HTTPS) 예시
# /etc/nginx/conf.d/ssl.conf 등 공통 포함 파일
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
# 모던 암호군(예시): 배포 환경에 맞게 최신 권고안 참조
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
# 곡선/키교환
ssl_ecdh_curve X25519:P-256:P-384;
# 세션/스테이플링
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
# HSTS (HTTPS 완전 강제)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# 권장 보안 헤더(참고)
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
- 인증서 파일/키 설정은 server 블록에서 ssl_certificate, ssl_certificate_key로 지정합니다.
- HTTP/2를 켜려면 listen 443 ssl http2; 옵션을 사용합니다.
- 변경 후 nginx -t로 문법 체크 → systemctl reload nginx
Apache(HTTPS) 예시
# /etc/apache2/mods-available/ssl.conf 또는 가상호스트
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder on
SSLCipherSuite TLSv1.2 HIGH:!aNULL:!MD5:!3DES:!RC4
# TLSv1.3 암호군은 OpenSSL 기본 사용(별도 설정 불필요한 경우 많음)
SSLOpenSSLConfCmd Curves X25519:P-256:P-384
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache "shmcb:/var/run/ocsp(128000)"
# HSTS
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
- a2enmod ssl headers http2 후, 사이트 설정에서 Protocols h2 h2c http/1.1 고려
- apachectl configtest → systemctl reload apache2
Postfix(SMTP) 예시
# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
# 프로토콜 제한
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
# 암호군(현대적)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
# Forward Secrecy 강화
smtpd_tls_eecdh_grade = strong
# 보안 레벨
smtpd_tls_security_level = may
smtp_tls_security_level = may
# OCSP Stapling(필요시)
tls_ssl_options = NO_RENEGOTIATION
- mail 서버는 클라이언트/상대 서버 호환성을 고려해야 합니다. 운영 환경에 맞는 절충이 필요합니다.
- 변경 후 systemctl reload postfix
운영 팁: 여러 호스트 자동 검사, 스케줄링, 알림
호스트 목록 대량 스캔
testssl.sh 자체에 목록 파일 옵션이 있는 버전도 있지만, POSIX 도구로 범용적으로 처리하는 방법을 추천합니다.
# hosts.txt에 한 줄당 one target 형식(예: example.com:443)
while read -r TARGET; do
[ -z "$TARGET" ] && continue
echo "Scanning $TARGET ..."
testssl.sh --fast --jsonfile "out_${TARGET//[:\/]/_}.json" "$TARGET"
done < hosts.txt
- 파일명에 콜론/슬래시가 들어가면 저장이 어려우니 치환합니다.
- --fast 대신 풀 스캔을 원하면 옵션을 빼세요.
cron으로 매일 리포트 생성
crontab -e
아래 예시 추가(매일 새벽 3시):
0 3 * * * /usr/local/bin/testssl.sh --jsonfile /var/reports/testssl_$(date +\%F).json https://www.example.com >/var/reports/testssl_$(date +\%F).log 2>&1
- 결과 파일의 증분을 Git으로 관리하면 추세 분석이 쉬워집니다.
- jq로 취약점만 추려 Slack/Webhook 알림을 보낼 수도 있습니다.
취약점 감지 시 간단 알림 예시
RESULT_JSON="/var/reports/testssl_$(date +%F).json"
if jq -e '.scanResult[]?.finding | select(.severity=="VULNERABLE")' "$RESULT_JSON" >/dev/null; then
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"[ALERT] testssl 취약점 발견: $RESULT_JSON\"}" \
https://hooks.slack.com/services/XXX/YYY/ZZZ
fi
문제 해결(Troubleshooting)
-
권한/경로 문제
- testssl.sh가 PATH에 없다면 절대경로로 실행하거나 /usr/local/bin에 링크를 둡니다.
- Docker 사용 시 네트워크 접근 허용 여부를 확인하세요(방화벽, 네임서버).
-
OpenSSL 버전 충돌/기능 부족
- Ubuntu 24는 OpenSSL 3.x 기반입니다. testssl.sh가 자체 바이너리 또는 시스템 openssl을 사용합니다.
- 특정 기능이 안 보이는 경우 testssl.sh --help에서 --openssl 옵션으로 다른 바이너리 경로를 지정할 수 있는지 확인하세요.
-
SNI/가상호스팅 이슈
- IP로 테스트 시 기대한 인증서가 보이지 않으면 --sni로 정확한 호스트명을 지정하세요.
-
내부망/자가서명 인증서
- 내부 PKI를 쓰면 체인 검증 경고가 날 수 있습니다. 기능 관점 테스트는 가능하지만, 신뢰 경로를 별도로 관리하거나, 검사 목적을 구분해 해석하세요.
-
속도/부하
- 풀 스캔은 서비스에 큰 부하를 주진 않지만, 광범위한 반복 스캔은 회선/장비에 영향을 줄 수 있습니다. --fast 또는 스케줄 간격을 조정하세요.
-
최신 취약점 반영
- Git 설치 버전은 /opt/testssl.sh/testssl.sh -U 또는 git pull로 주기적으로 갱신하세요.
- APT 설치 버전은 sudo apt update && sudo apt install --only-upgrade testssl.sh로 갱신합니다.
보안 구성 베스트 프랙티스 요약
- 프로토콜: TLS 1.2, TLS 1.3만 허용
- 암호군: ECDHE 기반, AEAD(GCM/ChaCha20-Poly1305) 우선, RC4/3DES/EXPORT/MD5/NULL 불허
- 인증서: 유효기간 관리, 2048비트 이상(RSA) 또는 ECDSA, SAN 정확성
- 곡선: X25519, P-256, P-384
- 서버 우선순위: on
- HSTS: 활성화(사전 테스트 후 preload 검토)
- OCSP Stapling: 가능하면 활성화
- HTTP/2: 최신 스택에서 활성화(호환성 확인)
- 취약점: testssl.sh 스캔에서 VULNERABLE 항목 즉시 조치
- 자동화: 정기 스캔 + 리포팅/알림 파이프라인 구축
실전 체크리스트
- 설치 확인
- testssl.sh --version로 동작 확인
- 첫 측정
- testssl.sh https://yourdomain.example
- 결과에서 취약점, 약한 프로토콜/암호군 탐지
- 안전한 설정 적용
- Nginx/Apache/Postfix 등 서비스 설정에 반영
- 재시작/재로드 후 testssl.sh로 재검증
- 레포팅/모니터링
- JSON/HTML 저장
- cron/jq로 일일 점검 + 알림
- 주기적 업데이트
- Git pull 또는 apt upgrade
- 인증서 만료, 프로토콜 정책 변경 주기적 확인
마치며: 작은 습관이 큰 보안을 만든다
testssl.sh는 “설치 → 실행 → 해석 → 조치”까지 흐름이 간단하면서도 강력한 도구입니다. Ubuntu Server 24 환경에서 몇 줄의 명령으로 도입하고, 정기 스캔과 자동 알림 체계를 붙이면 TLS/SSL 보안의 기본 방어선을 크게 끌어올릴 수 있습니다.
이제 바로 여러분의 서버를 점검해 보세요.
- 빠른 시작: testssl.sh --fast yourdomain.example
- 풀 스캔 + 리포트: testssl.sh --jsonfile out.json --htmlfile out.html yourdomain.example
- 메일/LDAP 등 비HTTP 서비스: --starttls 프로토콜 옵션으로 손쉽게 검사
보안은 한 번의 점검으로 끝나지 않습니다. testssl.sh를 운영 루틴에 녹여, 변화하는 위협과 설정 드리프트를 빠르게 포착하는 습관을 들이세요. Ubuntu Server 24와 testssl.sh의 조합으로, 신뢰할 수 있는 TLS 환경을 계속 유지할 수 있을 것입니다.