NGINX 로그가 드러낸 미확인 공격 시도 - TLS 적용

문제 배경

로컬에서 정상적으로 API를 만들고 POSTMAN으로 테스트까지 해보고 배포를 했다. 하지만 정상적으로 요청이 오질 않아(404 error) NGINX 로그를 살피던 도중 의도치 않게 다른 문제를 발견하게 되었다. (위 문제는 Reverse Proxy 설정을 잘못한거라 해결했다)

 

 

에러로그가 굉장히 많이 쌓여 있었고 그중 수상하게 용량이 매우 크고 에러로그(error.log.6.gz)가 있길래 한번 살펴봤다.

 

 

가장 첫번째 줄에

client: 124.156.187.113의 위치를 한번 검색해봤다. 무슨 홍콩 지역이 나온다.

 

 

그리고 request: "HEAD /Core/Skin/Login.aspx 이라는 요청을 보낸다.

Login.aspx 이란, https://dotnet.microsoft.com/ko-kr/apps/aspnet

ASP.NET Core | .NET용 오픈 소스 웹 프레임워크

웹 어플리케이션에서 사용되는 로그인 페이지의 파일 이름 이라고 한다.

다음 줄에서는 .env 라는 파일을 요청하고 있다.

.env 는 환경 변수(environment variables)를 저장하는 데 사용되는 파일이고 이 파일은 애플리케이션의 설정 정보를 저장하는 용도로 사용되며, 보통 데이터베이스 연결 정보, API 키, 비밀번호와 같은 민감한 정보를 포함하고 있는 파일이다.

 

하지만 내 개발스택과 전혀 관련없는 파일을 요청하고 있는 파일들을 요청하고 있었다.

현직자 분에게 물어보니 공격을 할때 얘네 서버의 기술스택이 뭐고 어떤 서비스를 하는 지 알고나서 공격하는 것이 아니라 다양한 경우의 수를 모조리 요청을 한다고 한다.

그중 얻어 걸리는 게 있다면, 예를 들어 만약 정말로 .env파일을 가지고 있었다면 .env파일을 해커는 받을 수 있을 것이다. 그리고 그 해커는 그 파일을 토대로 여러 정보를 얻게 되고 다시 그 정보를 토대로 새로운 공격을 하면서 점점 깊숙히 침투하는 것이다.

 

---

문제해결을 위한 접근

 

찾아보니 다양한 방법이 있었다.

1. WAF(Web Application Firewall) 사용: Nginx에는 ModSecurity와 같은 WAF를 통합할 수 있는 옵션이 있었다. WAF는 SQL 인젝션, 크로스 사이트 스크립팅(XSS), 파일 인클루전 공격과 같은 일반적인 웹 공격을 감지하고 차단할 수 있다. Nginx를 사용하는 김에 설정하면 좋을 것 같다.
2. 액세스 제한 설정: Nginx 설정을 사용하여 미리 정의된 IP 주소에서만 접속을 허용하거나 특정 경로에 대한 접근을 제한할 수 있다. 이를 통해 민감한 관리자 페이지나 내부 서비스에 대한 접근을 제한할 수 있다. 이는 관리자 페이지를 아직 만들 계획이 없기 때문에 특정 아이피만 허용하는 것은 해결방법에 제외했다.
3. SSL/TLS 사용: 모든 통신에 SSL/TLS 암호화를 적용하여 데이터 전송 중 정보를 보호할수 있다. Nginx는 SSL/TLS 설정을 쉽게 할 수 있으며, Let's Encrypt와 같은 서비스를 사용하여 무료 SSL 인증서를 발급받을 수 있다. 가장 자료도 많고 설정도 쉽기 때문에 이를 해결책으로 사용해보려고 한다. HTTP가 왜 위험하냐면 패킷 분석을 통해 순수 정보를 획득할 수가 있기 때문이다. (나도 할 수 있다. 저번 포스팅한 글 참조: wireshark 사용법)
4. HTTP 헤더 보안 강화: Nginx를 사용하여 보안 관련 HTTP 헤더를 설정할 수 있습니다. 예를 들어, X-Frame-Options, X-XSS-Protection, Content-Security-Policy와 같은 헤더는 클라이언트의 브라우저 보호 기능을 강화하는 데 도움이 된다.
5. 요청 속도 제한 (Rate Limiting): Nginx에서는 요청 속도를 제한하여 DoS 공격이나 브루트 포스 공격을 방지할 수 있다. 이를 통해 악의적인 사용자가 짧은 시간 내에 대량의 요청을 보내는 것을 방지할 수 있다. 나중 DOS 공격을 막는데 필요해 보이기 때문에 설정해봐야겠다.
6. 로그 관리와 모니터링: Nginx의 접근 로그와 오류 로그를 주기적으로 검토하여 비정상적인 패턴이나 가능한 보안 위협을 식별한다. 필요한 경우 로그 관리 시스템을 사용하여 로그 데이터를 분석하고 모니터링할 수 있다. 추후에 도입해 볼 예정이다.

 

---

해결 방법

 

먼저 주변 자료가 많은 SSL 적용부터 진행해봤다.

해당 글 참고: aws http https 리다이렉트(무료)

AWS Http Https 리다이렉트 (무료)

 

사전으로 해야할 것

1. 인바운드 정책은 80,443포트만 가능하도록 한다
2. 도메인 구입 후 EC2연결 및 Nginx 설정 (이미 서버는 열어둔 상태이다.)

 

SSL 인증서 발급 및 HTTPS 설정

출처: https://blog.outsider.ne.kr/1178

 

웹사이트에서 HTTPS를 활성화하려면 인증 기관 (CA)으로 부터 인증서(파일형식)을 받아야 한다.

Let's Encrypt 는 CA중 하나이고 심지어 인증서를 무료로 지급한다. (예전에는 돈주고 사용)

Let’s Encrypt에서 도메인에 대한 인증서를 받으려면 도메인에 대한 제어권을 입증해야 한다. ACME 프로토콜로 이 작업을 수행할 수가 있다. 

만약 나같이 AWS를 사용해서 쉘 액세스가 가능하다면 Certbot(https://certbot.eff.org/) - ACM 클라이언트 를 사용해서 인증서 발급 및 설치를 자동화 할 수가 있다. 

# certbot을 설치하기 위한 snap을 설치한다.
sudo apt update
sudo apt install snapd

# certbot을 설치한다.
sudo snap install --classic certbot

 

 

설치가 완료됐다면 certbot를 활용해 인증서를 자동 발급한다. 

(web-root 인증방식 사용)

# certbot을 nginx에 연결하기
sudo certbot --nginx

 

발급이 완료되면 .conf 파일에 certbot이 SSL 인증서를 적용하는 코드와 http->https 리다이렉트 코드를 적용한 모습을 확인할 수 있다.

 

 

이제 http://www.agilehub.store 으로 접속하면 https로 리다이렉트 되는 모습을 확인할 수 있다.

 

참고로 mixed-content 는 프론트엔드 코드에서 발생하는 API 호출이 http로 사용돼서 브라우저가 이를 차단한 것이다. 이 부분은 코드를 수정하면 될 것이다.

이제 80포트도 인바운드 정책에서 제거하자. 어차피 사용자가 없기 때문에 그래도 되고 개발자의 실수로 http를 사용하지 않도록 미리 제거해두자. (하지만 실수로 http://로  접속하는 사용자들도 해당 사이트로 이동시켜주야하는게 맞는 것 같기도 하다 ._.)

 

인증서 갱신 자동화

 

Let's Encrypt에서 발급해주는 인증서는 무료 인증서로 3개월의 유효기간을 가지고있다.

sudo certbot certificates 명령어로 인증서 정보 확인 가능.

 

먼저 서버시간이 UTC로 설정되있으니 한국 시간으로 설정부터 한다.

sudo timedatectl set-timezone Asia/Seoul

 

 

스케줄링을 위해 crontab에 작업을 등록.

# crontab 열기
sudo crontab -e

 

 

마지막줄에 다음 명령어를 추가해고 저장하면 매월 1일 오전 3시에 인증서가 갱신된다.

0 3 1 * * /usr/bin/certbot renew --renew-hook="sudo systemctl restart nginx"

 

이렇게 SSL 적용을 통해 공격자가 파일을 얻어와도 암호화된 파일이라 해독이 불가능 할 것이다.