<aside> 🔑

요약

배포 서버에 러시아·중국 IP 등에서 비정상적인 트래픽과 .env, phpUnit 공격 시도가 발생했었다. 이는 원격 코드 실행과 정보 유출 시도로 판단되었다.

유효하지 않은 도메인이나 IP 직접 접근을 차단하기 위해 Nginx에 catch-all 기본 server 블록을 설정하였다. 해당 블록은 매칭되지 않는 요청에 대해 403 Forbidden 을 반환하도록 구성되었다.

이를 통해 서버 접근을 사전에 차단하고 불필요한 리소스 낭비를 줄일 수 있었다. 보안 로그를 통해 실제 공격 시도를 체감하면서 보안의 중요성을 절실히 느끼게 되었다.

특히 HTTPS 미적용 시 정보 유출 위험이 크다는 점을 다시금 인식하게 되었다. 결과적으로 실서비스 환경에서는 철저한 보안 대비가 필수임을 깨달은 경험이었다.

</aside>

보안 이슈| 비정상적인 IP 차단하기

문제 배경

유독 러시아와 중국에서 트래픽이 몰리는 경우가 있었다. 이 경우에 대해서 찾아보니 자동화된 크롤링 봇들로 인해 그럴 수 있다고 하여 대수롭지 않게 넘어 갔었다.

그러던 중, 2025년 05월 13일 경, nginx의 access 로그를 살펴볼 일이 있어서 보았더니, phpUnit 이라는 단위테스트 도구를 이용해서 여러 요청을 온 것을 확인 하였다. 이는 PHPUnit이 설치된 서버에서 특정 파일을 통해 원격 코드 실행을 시도하려는 정황이라고 한다.

또한, .env 파일에 대한 접근을 시도하는 움직임도 보였다.

여기서 POST 요청도 여러 건 보이는데, 이는 외부에서 악의적인 스크립트를 주입하려는 행위라고 한다.

추가로 확인된 것은 유효한 도메인이 아닌 IP 직접 접근 방식으로 이루어지고 있고, 유효한 도메인이 아닌 이 외의 요청 방법으로는 접근하지 못하도록 막는 것이 보안상 좋은 사안으로 판단되었다.

해결방법

Nginx의 default.conf 에서 80 포트와 443 포트로 요청이 가기전에 거름망으로서 실행할 server 블록을 추가하고 아래 코드를 추가한다. 즉, catch-all 보안용 기본 서버를 만들어 두는 것이다.

server {
    listen 80 default_server;
    listen 443 ssl default_server;

    server_name _;  # 모든 매칭되지 않는 도메인

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    return 403;
}

<aside> 🔑

어떻게 동작하는가?

앞서 설정한 서버의 동작을 나눠서 설명해보면 아래와 같다.

• listen 80 default_server;

  → 포트 80(HTTP)에서 도메인 매칭이 되지 않을 경우, 이 블록이 기본으로 선택

• listen 443 ssl default_server;

  → 포트 443(HTTPS)에서도 마찬가지로 기본 서버 역할을 하며, ssl 키워드로 SSL 연결 허용

• server_name _;

  → underscore(_)는 관례적으로 "catch-all" 역할을 하지만 정확히는 정확한 도메인 매칭이 안 되면 사용

• ssl_certificate, ssl_certificate_key

  → HTTPS 요청을 처리하기 위해 TLS 인증서 및 키 설정

• return 403

  → 어떤 요청이 오든 403 Forbidden 응답 반환

이를 요약하자면,

1. 클라이언트가 api.example.com 외의 도메인으로 요청을 보낼 경우 (www.abc.com 등)
2. 다른 server 블록과 도메인이 매칭되지 않으면 이 블록이 선택되고,
3. 악의적인 클라이언트는 403 Forbidden 응답 받는다. </aside>