[여기보기]는 “여기서 보안의 기본을 챙기고 가자”의 약자로, 개발 과정에서 꼭 최소한으로 챙기면 좋을 보안 기초 설정을 앞으로 하나씩 공유할 예정입니다. 기초 내용이 주를 이루겠지만, 혹시라도 빼먹고 계신 것이 없는지 가끔 한 번씩 둘러봐 주세요.
안녕하세요, 넷마블 보안실 보안개발팀 이석진입니다.
요즘 ChatGPT가 화제입니다. 가끔 뜬금없는 답변도 하지만 IT 관련으로는 꽤 정확한 내용을 알려줍니다. 심지어 간단한 프로그램 코드를 보여줄 정도니 앞으로 검색 엔진이나 사전 서비스에 큰 변화를 불러일으킬 것으로 생각합니다.
그래서 궁금증이 생겼습니다. ChatGPT에게 이번 글의 주제를 물어보았습니다. 질문은 다음 두 가지입니다.
- WAS 설정 파일에 적절한 권한을 부여해야 하는 이유는 무엇인가요?
- WAS의 세션 타임아웃이 중요한 이유는 무엇인가요?
결과는 어땠을까요?
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-001-1024x586.png)
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-002-1024x600.png)
어떤가요? 정확한 답변에 꽤 놀랐습니다(약간의 맞춤법 오류와 설명 중단은 애교로 받아주기 바랍니다). 기본 개념을 거의 그대로 알려주었다고 해도 과언이 아닙니다.
이 글에서는 기특한 ChatGPT의 답변에 이어서 WAS의 보안에 필요한 설정 파일과 세션 타임아웃 관리 방법을 살펴보겠습니다.
설정 파일의 권한 관리하기
WAS의 설정 파일(주요 소스 코드 파일이나 설정 파일)에 아무나 접근할 수 있다면 서비스가 비정상적으로 동작하거나 중지될 우려가 있습니다. 혹은 WAS의 위조나 변조, 백도어 삽입 등의 피해도 발생할 수 있죠.
이러한 일을 막으려면 전용 서비스 계정 혹은 서비스 그룹에만 필요한 권한을 부여하는 것이 좋습니다.
조치 방안
‘[여기보기]’를 꾸준히 살펴본 분이라면 ‘WAS 프로세스가 다진 마음은 루트와 헤어질 결심에서 서비스 계정과 서비스 그룹의 루트 사용자를 특정 사용자로 바꾸는 일을 살펴봤을 것입니다. 여기서 소개한 명령을 응용하면 설정 파일에 원하는 사용자만 접근하도록 권한을 설정할 수 있습니다.
윈도우의 설정 파일 권한 변경하기
윈도우 기반 WAS는 설정 ‘파일 관리’라기보다 ‘사용 권한 관리’입니다. 이 포스트에서 소개하는 WAS 대부분의 설정 과정이 다음과 같으니 기억하기 바랍니다. 참고로 해당 설정 과정을 한 번에 알지 못하겠다면 파일 탐색기에서 ‘[WAS Dir]\소스 및 설정 디렉터리’를 오른쪽 마우스로 클릭한 후 나타나는 바로 가기 메뉴에서 [속성]을 선택합니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-003-1024x854.png)
‘파일 혹은 디렉터리 속성’ 창에서 [보안] 탭을 선택한 후 맨 아래에 있는 [고급]을 클릭해 ‘고급 보안 설정’ 창을 엽니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-004.png)
‘고급 보안 설정’ 창에서 먼저 왼쪽 위에 있는 소유자를 바꿔야 합니다. ‘소유자’ 항목 옆에 있는 [변경]을 클릭한 후 ‘[여기보기]’ 글 중, “WAS 프로세스가 다진 마음은 루트와 헤어질 결심”의 조치 방안을 참고해 소유자를 WAS 서비스 계정으로 변경합니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-005.png)
WAS 서비스 계정에 [모든 권한]이 부여되었는지 확인한 후 합니다. 모든 권한이 부여되지 않았다면 [사용 권한 항목] 아래에 있는 [편집]을 클릭합니다. ‘권한 항목’ 창이 열리면 [기본 권한] 항목에서 모든 권한을 선택하고 [확인]을 클릭합니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-006-1024x650.png)
‘권한 항목’ 창을 열고 Users 그룹에 속한 일반 사용자가 설정 파일을 수정할 수 없도록 쓰기 권한이 해제됐는지 확인합니다. 쓰기 권한이 있다면 해제해줍니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-007-1024x650.png)
Users는 시스템 서비스를 시작하거나 종료할 권한이 없는 일반 계정이 속하는 그룹입니다.
‘고급 보안 설정’ 창에서 Everyone 그룹이 있다면 아래에 있는 [제거]를 클릭해 없앱니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-008.png)
Everyone은 해당 서버에 접근하는 모든 로컬 및 원격 사용자를 포함하는 그룹입니다.
윈도우에서는 아파치 HTTP 서버, 톰캣, NGINX, 스프링 부트, Node.js 모두 앞에서 설명한 방식으로 설정 파일이나 디렉터리의 권한을 변경하면 됩니다. 다음 소개하는 WAS별 설정 파일 위치를 참고해 권한을 바꿔주기 바랍니다.
- 아파치 HTTP 서버: [Apache Dir]/conf/httpd.conf
- 톰캣: [Tomcat Dir]/conf/server.xml
- NGINX: [NGINX Dir]/conf/nginx.conf
- 스프링 부트 & Node.js: 해당 프로젝트 디렉터리
리눅스의 설정 파일 권한 변경하기
리눅스는 chown과 chmod 명령어를 사용해 각 WAS의 설정 파일이나 디렉터리의 권한을 변경하면 됩니다. 해당 명령은 다음과 같습니다.
$ chown [서비스 계정]:[서비스 그룹] [설정 파일 혹은 디렉터리]
$ chmod 750 [설정 파일 혹은 디렉터리]
# 혹은
$ chmod 640 [설정 파일 혹은 디렉터리]
이는 설정 파일이나 디렉터리를 정해진 서비스 계정과 그룹에 속하게 한 후, 서비스 계정과 서비스 그룹에는 보안 규칙에서 정한 권한을 주고 그 이외에는 권한을 주지 않는다는 설정입니다.
예를 들어 아파치 HTTP 서버에서 서비스 계정이 iamironman, 서비스 그룹이 httpd, 설정 파일의 경로가 [Apache Dir]/conf/httpd.conf라고 하겠습니다. 다음 그림처럼 설정 파일의 권한을 바꿀 수 있습니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-009.png)
WAS별 설정 파일 혹은 디렉터리 위치는 다음과 같습니다. 설치 방법에 따라 설정 파일 위치가 다르므로 참고하면 좋습니다.
- 아파치 HTTP 서버 컴파일 설치: [Apache2 Dir]/conf/httpd.conf
- 아파치 HTTP 서버 apt 설치: /etc/apache2/apache2.conf
- 아파치 HTTP 서버 yum 설치: /etc/httpd/conf/httpd.conf
- 톰캣 다운로드 설치: [Tomcat Dir]/conf/server.xml
- 톰캣 apt 설치: /etc/tomcat버전번호/server.xml
- 톰캣 yum 설치: /etc/tomcat/server.xml
- NGINX 컴파일 설치: [NGINX Dir]/nginx.conf
- NGINX 패키지 관리 도구: /etc/nginx/nginx.conf
- 스프링 부트 프로젝트 설정 파일: [Project Dir]/src/main/resources/application.properties or application.yml
- Node.js 프로젝트 설정 파일: [Project Dir]/index.js or app.js(npm init의 엔트리 포인트)
참고로 톰캣에서 설정 파일 권한을 관리할 때는 다음도 같은 수준의 권한 관리를 해주기 바랍니다.
- ‘[Tomcat Dir]/conf/server.xml’ 이외에 conf 디렉터리에 있는 *.xml, *.properties, *.policy 파일
- ‘[Tomcat Dir]/conf/server.xml’의 <host appBase=””>에 설정된 경로를 확인해 WAR이나 JAR 파일, 별도의 서버 관련 설정 파일
NGINX와 Node.js에서 설정 파일 권한을 관리할 때는 파일 업로드 폴더 또는 게시판(DBMS가 연동되지 않았을 때)만 쓰기 권한을 부여하기 바랍니다.
세션 타임아웃 변경하기
설정 파일의 권한을 변경했더라도 세션이 오랫동안 유지되면 헛일입니다. ChatGPT가 설명한 것처럼 어떤 작업 후 해당 세션이 유지된다면 관리자가 아닌 사람이 시스템에 접근해서 관리자 권한 등을 획득할 수 있습니다. 따라서 설정 파일에서는 권한 변경과 함께 세션 타임아웃 시간도 변경하는 것이 좋습니다.
조치 방안
세션 타임아웃은 기본적으로 WAS별 제시하는 기본값으로 설정된 시간보다 더 짧은 시간으로 설정하는 것을 권장합니다. WAS별 세션 타임아웃 변경 방법은 다음과 같습니다.
ASP
IIS 관리자에서는 ASP의 세션 타임아웃 값을 변경할 수 있습니다. ‘실행’ 창에서 ‘InetMgr.exe’를 입력해 ‘IIS(인터넷 정보 서비스) 관리자’를 실행합니다. 오른쪽 ‘홈’에서 [IIS] → [ASP]를 선택한 후 [서비스] → [세션 속성] → [시간 제한]을 선택해 hh:mm:ss를 기본값인 00:20:00보다 낮게 설정(보통 00:10:00 정도로 설정)합니다.
![](https://netmarble.engineering/wp-content/uploads/2022/12/03-010.png)
아파치 HTTP 서버
아파치 HTTP 서버의 세션 타임아웃 기본값은 300(기준시간은 초)입니다. httpd.conf 혹은 apache2.conf 안의 Timeout 값을 기본값보다 낮춰줍니다.
Timeout 240
만약 기존 Timeout 설정이 없다면 설정 파일 안에 새로 Timeout 설정을 추가하면 됩니다.
톰캣
톰캣의 세션 타임아웃 설정은 server.xml이 아닌 같은 디렉터리에 있는 web.xml를 수정해야 합니다. 다음 XML 코드를 찾고 <session-timeout>의 값을 기본값인 30(분)보다 낮은 값으로 변경합니다.
<session-config>
<session-timeout>10</session-timeout>
</session-config>
NGINX
nginx.conf에서 ‘http’ 항목을 찾은 후 다음 코드를 참고해 프락시와 관련된 네 가지의 타임아웃 관련 파라미터값을 추가합니다.
http {
server {
// 이전 생략
location / {
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
send_timeout 60s;
}
}
}
네 가지 설정은 다음과 같은 의미입니다(출처: NGINX Module ngx_http_proxy_module, Module ngx_http_core_module).
- proxy_connect_timeout: 프락시 서버와 연결을 맺는데 설정한 타임아웃 시간입니다. 75초를 초과할 수 없습니다. 기본값은 60초입니다.
- proxy_send_timeout: 프락시 서버로 요청을 전송하는 데 설정한 타임아웃 시간입니다. 전체 요청 전송이 아닌 연속적인 쓰기 작업 2개 사이에만 설정이 적용됩니다. 해당 설정에 지정한 시간 안에 프락시 서버가 아무것도 수신하지 못하면 연결이 닫힙니다. 기본값은 60초입니다.
- proxy_read_timeout: 프락시 서버에서 응답을 읽는 데 설정한 타임아웃 시간입니다. 전체 응답 전송이 아닌 연속적인 읽기 작업 2개 사이에만 설정이 적용됩니다. 해당 설정에 지정한 시간 안에 프락시 서버가 아무것도 전송하지 않으면 연결이 닫힙니다. 기본값은 60초입니다.
- send_timeout: 클라이언트에 응답을 전송하는 데 설정한 타임아웃 시간입니다. 전체 응답 전송이 아닌 연속적인 쓰기 작업 2개 사이에만 설정이 적용됩니다. 해당 설정에 지정한 시간 안에 클라이언트가 아무것도 수신하지 못하면 연결이 닫힙니다. 기본값은 60초입니다.
스프링 부트
application.properties 혹은 application.yml에 다음 코드를 추가해 세션 타임아웃 값을 변경합니다. 기본값인 3600보다 낮은 값을 설정하면 됩니다.
# 스프링 부트 1.x
server:
session:
timeout: 600
# 스프링 부트 2.x
server:
servlet:
session:
timeout: 600
Node.js
Node.js는 세션 관리용 미들웨어인 express-session의 cookie.maxAge 속성값(ms 기준)을 설정해 세션 타임아웃을 제어하는 것을 권장합니다. 프로젝트의 엔트리 포인트 파일인 index.js 혹은 app.js에 다음 소개하는 코드를 추가합니다. express-session 제시하거나 권장하는 기본값은 없으며, 10분보다 짧게 설정할 것을 권장합니다.
var session = require('express-session');
app.use(session({
secret: '비밀키 입력',
resave: false,
saveUninitialized: true
cookies: {
maxAge: 600000 // 1000 * 60 * 10과 같은 방식으로 설정해도 됨
}));
// 세션 초기 설정
app.get('/', function(req, res) {
sess = req.session;
});
// 세션 변수 설정
app.get('/login', function(req, res) {
sess = req.session;
sess.username = "사용자 ID"
});
// 세션 변수 사용
app.get('/', function(req, res) {
sess = req.session;
console.log(sess, username);
});
산타 할아버지가 서버에 들어올 수 없을 정도여야 합니다
산타 할아버지가 크리스마스에 세계 어린이 20억 명에게 선물을 전달하려면 시차를 포함해 34시간 동안 31억 2,500만km를 2,600km/s의 속도로 이동해야 한다고 합니다. 사실 인간이 만든 교통수단으로는 불가능한 속도죠. 그런데 광섬유 케이블의 빛의 속도는 약 20만km/s라고 합니다. 네트워크는 광섬유 케이블을 중심으로 이동하니까, 보안 위협의 순간은 산타 할아버지의 이동 속도보다 더 빠른 건지도 모릅니다. 즉, 설정 파일과 세션 타임아웃 관리는 산타 할아버지도 내가 운영하는 서버에 들어오지 못할 정도의 상태를 유지하는 것이 기본 아닐까 생각합니다.
이 글을 공개하는 시점이라면 산타 할아버지도 이미 선물을 주고 가셨을 겁니다. 오늘은 관리하는 서버의 설정 파일 관리와 세션 타임아웃 시간을 다시 점검해보기 바랍니다. 내년에는 산타 할아버지가 선물을 어떻게 주어야 하나 고민할 정도가 되도록 말이죠.