Linux

리눅스 서버 포트 점검 가이드

리눅스 서버 포트 점검 가이드입니다. ss, lsof, fuser, firewalld/UFW/nftables, nc, curl, nmap을 로컬 listen과 외부 도달성 관점으로 정리했습니다.

devmes

• 조회 122

리눅스 서버 포트 점검은 “포트가 열려 있다/닫혀 있다”만 보는 작업이 아닙니다. 로컬 프로세스가 listen 중인지, 방화벽에서 허용되는지, 외부에서 실제로 도달 가능한지, 애플리케이션 프로토콜 응답이 정상인지까지 나눠 봐야 합니다.

로컬에서 listen 포트 보기

현재 서버에서 어떤 TCP/UDP 포트가 listen 중인지 확인합니다. 요즘 리눅스에서는 netstat보다 ss를 먼저 씁니다.

sudo ss -lntup
sudo ss -lntp '( sport = :22 or sport = :80 or sport = :443 )'

주요 옵션은 다음과 같습니다.

  • -l: listen 상태만 출력
  • -n: 포트와 주소를 숫자로 출력
  • -t: TCP
  • -u: UDP
  • -p: 프로세스 정보 출력

특정 포트를 사용하는 프로세스 찾기

포트 충돌이나 예상하지 못한 서비스가 떠 있을 때는 프로세스를 직접 확인합니다.

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo fuser -v 8080/tcp
ps -fp <PID>

lsof가 없다면 설치하거나 ss -lntp만으로도 대부분 확인할 수 있습니다.

# Ubuntu/Debian
sudo apt install -y lsof psmisc

# RHEL 계열
sudo dnf install -y lsof psmisc

방화벽에서 허용되는지 확인

프로세스가 listen 중이어도 서버 방화벽이 막으면 외부 접속은 실패합니다. 어떤 방화벽을 쓰는지에 따라 확인 명령이 달라집니다.

# firewalld
sudo firewall-cmd --state
sudo firewall-cmd --list-all

# UFW
sudo ufw status verbose

# nftables
sudo nft list ruleset

# legacy iptables
sudo iptables -S

예를 들어 8080/TCP를 firewalld에서 임시로 열어 테스트하려면 다음처럼 합니다.

sudo firewall-cmd --add-port=8080/tcp
sudo firewall-cmd --list-ports

재부팅 후에도 유지해야 할 정책이면 --permanent와 --reload를 사용합니다.

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

외부에서 TCP 도달성 확인

서버 내부에서만 확인하면 중간 방화벽, 보안 그룹, 로드밸런서, NAT 문제를 놓칠 수 있습니다. 반드시 다른 호스트에서 확인합니다.

nc -vz -w 3 server.example.com 443
curl -I --connect-timeout 3 https://server.example.com/

nc는 TCP 연결 자체를 보기에 좋고, curl은 HTTP/HTTPS 응답까지 확인하기 좋습니다. 포트는 열렸는데 curl이 500이나 502를 받는다면 네트워크가 아니라 웹 애플리케이션이나 프록시 문제로 봐야 합니다.

nmap 사용 범위

nmap은 유용하지만 허가된 서버와 네트워크에서만 사용해야 합니다. 내 서버의 단일 포트나 좁은 범위를 확인하는 용도로 제한합니다.

nmap -Pn -p 22,80,443 server.example.com
nmap -Pn -p 8000-8100 server.example.com

-Pn은 ping 응답이 없어도 포트 스캔을 진행하게 합니다. 클라우드나 방화벽 환경에서는 ICMP가 막혀 있는 경우가 흔하기 때문에 포트 점검에서는 유용합니다.

LISTEN과 ESTABLISHED 구분

서비스가 대기 중인지와 실제 연결이 붙었는지는 다릅니다. 접속 중인 세션을 보려면 상태를 나눠 확인합니다.

sudo ss -ant state listening
sudo ss -ant state established
sudo ss -ant '( dport = :443 or sport = :443 )'

웹 서비스 장애에서 listen은 정상인데 established가 쌓이고 응답이 늦다면 애플리케이션 처리 지연, 백엔드 DB 지연, 커넥션 고갈을 의심해야 합니다.

점검 순서

실무에서는 다음 순서가 빠릅니다. 서버에서 ss -lntup으로 프로세스 listen을 확인하고, lsof로 프로세스를 특정하고, 서버 방화벽을 확인한 뒤, 외부 호스트에서 nc/curl/nmap으로 실제 도달성을 봅니다. 이 순서를 지키면 포트 충돌, 방화벽 차단, 애플리케이션 오류를 서로 섞지 않고 판단할 수 있습니다.

BGM EVER