서버 보안에서 방화벽보다 먼저 점검해야 할 것들

서버 보안을 이야기하면 가장 먼저 방화벽을 떠올리는 경우가 많다.

외부에서 들어오는 포트를 차단하고 필요한 포트만 열어 두면 서버가 안전해질 것처럼 보인다. 물론 방화벽은 매우 중요한 보안 요소다.

하지만 실제 서버 보안에서 더 먼저 확인해야 하는 것은 따로 있다.

서버에서 어떤 서비스가 실행되고 있는지, 불필요한 계정은 없는지, SSH는 어떻게 열려 있는지, 운영체제와 패키지는 얼마나 오래됐는지부터 확인해야 한다.

방화벽은 외부 접근을 제한하는 장치일 뿐 서버 내부의 취약한 상태 자체를 해결해 주지는 않는다.

이번 글에서는 서버 운영자가 방화벽 설정 전에 반드시 점검해야 하는 항목을 실제 Linux 서버 운영 관점에서 살펴본다.

서버 보안 문제는 왜 방화벽만으로 해결되지 않을까?

인터넷에 연결된 서버는 지속적으로 외부 요청을 받는다.

웹서버라면 80·443 포트가 열려 있을 것이고 관리 목적으로 SSH 22번 포트를 사용하는 경우도 많다.

문제는 방화벽이 특정 포트를 허용했다고 해서 그 포트에서 실행되는 서비스까지 안전해지는 것은 아니라는 점이다.

예를 들어 SSH 포트가 외부에 열려 있는데 root 로그인이 허용돼 있고 약한 비밀번호를 사용하고 있다면 공격자는 SSH 자체를 직접 공격할 수 있다.

웹서버의 443 포트만 열어 두었더라도 오래된 웹 애플리케이션이나 패키지에 취약점이 존재한다면 방화벽은 이를 막아 주지 못한다.

즉 서버 보안은 단순히

외부 → 방화벽 → 서버

구조만 보는 것이 아니라

외부 → 네트워크 포트 → 서비스 → 프로세스 → 계정 → 파일 권한 → 운영체제

전체 흐름을 함께 봐야 한다.

방화벽은 이 구조에서 하나의 방어선일 뿐이다.

실제로 외부에 노출되는 것은 포트가 아니라 서비스다

Linux 서버에서는 프로세스가 특정 IP와 포트를 Listen 상태로 열고 외부 연결을 기다린다.

현재 서버에서 어떤 서비스가 포트를 열고 있는지 확인하려면 다음 명령을 사용할 수 있다.

ss -lntp

이 명령은 TCP 포트 가운데 현재 Listen 상태인 포트와 해당 포트를 사용하는 프로세스를 확인할 때 사용한다.

예를 들어 다음과 같은 결과가 있다고 가정해보자.

LISTEN 0 511 0.0.0.0:80    nginx
LISTEN 0 511 0.0.0.0:443   nginx
LISTEN 0 128 0.0.0.0:22    sshd
LISTEN 0 128 0.0.0.0:3306  mysqld

웹서버라면 80과 443 포트는 자연스럽다.

하지만 데이터베이스가 같은 서버에서 사용되고 있는데 MySQL의 3306 포트가 0.0.0.0으로 열려 있다면 상황이 다르다.

0.0.0.0:3306은 서버의 모든 IPv4 인터페이스에서 연결을 받을 수 있다는 의미다.

DB가 웹 애플리케이션 내부에서만 사용된다면 굳이 외부 인터페이스에서 Listen할 이유가 없다.

이 경우 방화벽에서 3306을 차단하는 것도 필요하지만 더 근본적인 방법은 MySQL 자체를 내부 주소 또는 localhost에만 바인딩하는 것이다.

예를 들어

127.0.0.1:3306

상태라면 동일 서버 내부에서만 접근할 수 있다.

보안의 핵심은 포트를 막는 것에서 끝나는 것이 아니라 애초에 불필요한 서비스가 외부 인터페이스에서 기다리지 않도록 만드는 것이다.

서버가 공격받을 때 나타나는 실제 증상

서버가 인터넷에 공개되면 SSH 로그인 시도나 웹 취약점 탐색 요청이 지속적으로 들어올 수 있다.

SSH 서버에서는 다음과 같은 로그가 반복될 수 있다.

Failed password for invalid user admin
Failed password for root
Invalid user test

배포판에 따라 SSH 인증 로그는 다음 위치에서 확인할 수 있다.

Ubuntu 계열:

/var/log/auth.log

RHEL 계열:

/var/log/secure

다음처럼 확인할 수도 있다.

grep "Failed password" /var/log/auth.log

이 명령을 사용하는 이유는 실제로 SSH 인증 실패가 얼마나 발생하고 있는지 파악하기 위해서다.

로그 몇 건이 있다고 바로 침해됐다는 의미는 아니다.

인터넷에 공개된 SSH 서버라면 자동화된 로그인 시도가 들어오는 경우가 있기 때문이다.

중요한 것은 실패 기록만 보는 것이 아니라 성공한 로그인 기록까지 함께 확인하는 것이다.

last 또는 lastlog를 이용하면 계정별 로그인 흔적을 확인할 수 있다.

평소 접속하지 않는 계정이나 알 수 없는 시간대의 접속 기록이 있다면 단순한 공격 시도가 아니라 실제 계정 접금 여부까지 조사해야 한다.

웹서버에서도 비슷한 현상이 발생한다.

존재하지 않는 관리자 페이지나 오래된 CMS 경로에 대한 요청이 Access Log에 반복적으로 나타날 수 있다.

따라서 보안 점검에서는 방화벽 설정 화면보다 서버 내부 로그를 먼저 보는 습관이 중요하다.

방화벽보다 먼저 무엇을 분석해야 할까?

첫 번째는 현재 실행 중인 서비스를 확인하는 것이다.

systemctl --type=service --state=running

서버에서 실제 실행 중인 서비스 목록을 확인할 수 있다.

여기서 중요한 것은 서비스가 실행 중이라는 사실보다 이 서버의 역할에 필요한 서비스인지 판단하는 것이다.

웹서버라면 Nginx나 Apache가 필요한 것은 자연스럽다.

하지만 사용하지 않는 FTP 서버, 테스트 목적으로 설치했던 애플리케이션, 오래된 관리 도구가 계속 실행 중이라면 공격 표면만 넓어진다.

두 번째는 계정이다.

cat /etc/passwd

를 통해 시스템에 존재하는 계정을 확인할 수 있다.

다만 /etc/passwd에 계정이 존재한다고 해서 모두 로그인 가능한 것은 아니다.

실제 로그인 Shell까지 함께 확인해야 한다.

예를 들어

/usr/sbin/nologin 이나 /bin/false

가 설정된 시스템 계정은 일반적인 대화형 로그인이 제한된다.

반대로 오랫동안 사용하지 않는 일반 계정에 /bin/bash가 설정돼 있고 SSH 접근까지 가능하다면 정리 대상이 될 수 있다.

세 번째는 SSH 설정이다.

sshd -T

는 sshd가 실제 적용하고 있는 설정을 확인할 때 유용하다.

특히 다음 항목을 확인한다.

permitrootlogin
passwordauthentication
pubkeyauthentication

설정 파일만 보는 것보다 sshd -T를 사용하는 이유는 include 파일이나 기본값까지 적용된 최종 설정을 확인할 수 있기 때문이다.

보안 설정을 점검할 때는 파일에 어떤 값을 적었는지가 아니라 실제 데몬이 어떤 설정으로 동작하고 있는지가 더 중요하다.

실제 서버에서는 어떤 순서로 보안을 강화해야 할까?

첫 번째는 불필요한 서비스를 종료하는 것이다.

사용하지 않는 서비스라면

systemctl disable --now 서비스명

처럼 실행 중지와 부팅 시 자동 실행 해제를 함께 적용할 수 있다.

단 운영 서버에서 서비스 이름만 보고 임의로 종료하면 안 된다.

다른 애플리케이션이나 모니터링 시스템이 의존하고 있을 수 있기 때문에 실제 사용 여부와 의존성을 먼저 확인해야 한다.

두 번째는 서비스의 Listen 범위를 최소화한다.

DB나 내부 관리 서비스가 외부 접근을 받을 필요가 없다면 localhost 또는 내부 네트워크 주소에만 바인딩하는 것이 좋다.

세 번째는 계정과 SSH 접근을 정리한다.

사용하지 않는 일반 계정을 제거하거나 로그인 기능을 제한하고, 운영 환경에서는 가능하면 SSH 키 기반 인증을 사용한다.

root 직접 로그인 역시 운영 방식에 따라 제한하는 것이 일반적이다.

네 번째는 패키지와 운영체제 상태를 확인한다.

오래된 패키지에 알려진 보안 취약점이 존재하는 상황에서는 방화벽을 아무리 잘 설정해도 정상적으로 공개해야 하는 서비스 포트를 통해 공격이 들어올 수 있다.

따라서 업데이트 정책과 보안 패치 적용 여부를 주기적으로 점검해야 한다.

마지막으로 방화벽을 설정한다.

이 단계에서 서버에서 실제 필요한 포트가 무엇인지 이미 파악했기 때문에 허용 규칙도 훨씬 명확해진다.

웹서버라면 일반적으로 웹 서비스 포트와 관리에 필요한 접근만 남기고 나머지는 제한하는 식이다.

즉 순서는

서비스 확인 → Listen 범위 확인 → 계정 점검 → SSH 설정 → 패치 상태 확인 → 방화벽

으로 접근하는 것이 더 합리적이다.

정리

서버 보안을 강화할 때 방화벽부터 설정하는 것은 틀린 방법은 아니다.

하지만 방화벽만 설정했다고 서버가 안전해지는 것은 아니다.

실제 공격 대상은 방화벽 자체보다 그 뒤에서 동작하는 서비스와 계정, 애플리케이션인 경우가 많다.

그래서 서버 운영자는 먼저 현재 어떤 프로세스가 실행되고 있는지, 어떤 포트를 Listen하고 있는지, 외부에서 접근할 필요가 없는 서비스까지 열려 있지는 않은지 확인해야 한다.

그다음 사용자 계정과 SSH 설정을 점검하고 운영체제와 패키지의 보안 패치 상태를 확인해야 한다.

그 이후 필요한 통신만 방화벽에서 허용하면 된다.

서버 보안에서 가장 중요한 원칙은 무엇을 막을 것인가보다 무엇이 실행되고 있고 왜 외부에 노출돼 있는지를 아는 것이다.

방화벽은 그 판단이 끝난 뒤 적용하는 방어선이다.

서버 내부 상태를 모르는 채 포트만 닫는 것보다 서버에서 필요하지 않은 서비스와 접근 경로 자체를 줄이는 것이 훨씬 근본적인 보안 관리 방법이다.