Nginx 로그 살펴보기 ( feat. 웹 스캐닝 )

 

프로젝트에 새로운 도메인을 MSA 형태로 추가하기 위해서 앞단에 Nginx를 사용해서 프록시 서버를 구축하였습니다.

잘 작동하던 서버가 어느날 안되는 것을 발견하여 로그를 살펴보고 많은 일들이 일어나고 있다는 것을 발견하고 글을 써봅니다.

 

---

아래의 글은 다음과 같은 구성으로 작성되어있습니다.

1. 현재 Nginx 설정 구성

2. 로그 살펴보기

3. 대응하기

 

 

 

1. 현재 Nginx 설정 구성

아래와 같이 conf를 구성하여서 들어오는 프록시 서버로 들어오는 요청에 대해 access_log를 남기고 매칭되는 주소로 라우팅을 진행합니다.

 

 

 

2. 로그 살펴보기

인프라 세팅 이후 로컬에서 작업을 했기 때문에 한동안 요청을 한 적이 없음에도 로그가 많이 쌓여있어서 로그를 살펴보았습니다.

 

 

gz 확장자를 갖는 로그를 살펴볼 때는 zcat을 사용하면 터미널에서 확인이 가능합니다.

$ zcat 파일명

 

 

로그를 살펴보고 적잖게 놀랐습니다. 생각보다 많은 해킹시도가 아주 빈번하게 발생하고 있는 것을 알게 되었고 해킹이라는 것이 생각보다 멀리 있는 것이 아니라는 생각이 들었습니다. 몇 가지 눈에 띄는 것들을 남겨봅니다.

 

2-1. 설정 파일

첫 번째로 눈에 들어온 것은 아래 처럼 설정파일에 접근하려는 요청입니다.

nginx의 설정 파일이 있을 법한 위치에 GET 요청으로 해당 데이터를 

 

2-2. Credential 혹은 .env

아래 남기는 스크린 샷은 aws의 credential 정보가 저장되는 파일의 위치에 대해서 GET 요청을 합니다.

만약 이런 요청에 해당 Credential 파일을 넘겨준다면 aws 가 악용될 것이 불을 보듯 뻔합니다.

aws 이외에도 /.env를 요청하는 로그도 다수 발견할 수 있었습니다.

 

2-3.  자주 사용되는 라이브러리 

js를 사용해서 웹 텍스트 에디터를 구현할 때 많이 사용하는 ckeditor라는 라이브러리가 있습니다.

아래 로그는 서비스를 해킹하기 위한 방법으로 해당 라이브러리 소스코드에 접근하는 방법을 사용하는 듯 보입니다.

 

2-4.  ETC

위의 경우를 제외하면 /admin이나 비교적 관습적으로 사용되는 파일명에 대한 접근을 찾아볼 수 있었습니다.

 

데이터 입력을 위한 input을 받는 내용을 form.html로 만드는 것은 흔히 있을 수 있는 일이라고 생각됩니다.

 

어드민 관련 데이터를 /admin 경로에서 관리하는 것도 흔히 사용되는 방법입니다.

 

 

3. 대응 하기

검색을 해보니 이와 같이 하나 걸릴 때까지 무작위로 요청을 하는 방식을 웹 스캐닝이라고 하는 것 같습니다.

보안 취약점을 찾아내는 형태로 보여집니다. 

 

방화벽 설정, IP 제한, HTTPS 설정 등 다양한 대응 방법들을 찾았습니다.

현재 서버는 개발 환경에 구축되어 있고, 불특정 다수의 클라이언트로부터 요청을 받아야하는 서버이기 때문에 IP 제한과 HTTPS 설정은 어렵다고 판단했습니다. 

 

주로 GET 요청이 임의의 경로로 오는 패턴임을 감안했을 때 허용하는 경로 외의 요청을 차단하면 되겠다는 것으로 방향을 잡았습니다.

현재 설정에서는 들어오는 요청이 location 블록에서 걸리지 않으면 시스템 root에서 찾는 흐름으로 진행이 되고 있기 때문에, 들어오는 요청이 허용된 경로가 아니라면 404를 반환할 수 있도록 location을 추가하였습니다.

location 허용된 패스1 {
	...
}

location 허용된 패스2 {
	...
}

# 위의 location에 걸리지 않는 경우 404
location / {
  return 404;
}

 

 

감사합니다.